148 lines
15 KiB
JSON
148 lines
15 KiB
JSON
|
{
|
|||
|
|
"topic": "ai-engineering",
|
|||
|
|
"type": "short_answer",
|
|||
|
|
"schema_version": "1.0.0",
|
|||
|
|
"generated": "2026-09-09T10:00:00+08:00",
|
|||
|
|
"questions": [
|
|||
|
|
{
|
|||
|
|
"id": "sa-001",
|
|||
|
|
"type": "short_answer",
|
|||
|
|
"difficulty": 3,
|
|||
|
|
"tags": [
|
|||
|
|
"context-engineering",
|
|||
|
|
"llm-ops"
|
|||
|
|
],
|
|||
|
|
"question": "Context Engineer 在 AI 工程体系中的核心职责是什么？请从信息组织、上下文窗口管理、动态检索策略三个维度阐述其工作范围，并说明它与传统 Prompt Engineering 的关键区别。",
|
|||
|
|
"answer": "Context Engineer 的核心职责是设计和管理 LLM 的输入上下文，确保模型在推理时获得最相关、最精炼的信息。具体包括三个维度：(1) 信息组织：构建结构化的上下文体系，包括系统提示、用户对话历史、检索文档、工具调用结果等多源信息的编排与优先级排序；(2) 上下文窗口管理：在有限的 token 预算内进行信息压缩、截断、摘要，处理长上下文场景下的注意力衰减问题，必要时实施分块策略；(3) 动态检索策略：根据用户意图实时决定何时检索、检索什么、检索多少，实现 RAG 管线的精准触发与结果融合。与传统 Prompt Engineering 的关键区别在于：Prompt Engineering 关注单次调用的提示词措辞优化，而 Context Engineer 关注的是一个持续的、系统性的上下文生命周期管理——涵盖信息的采集、筛选、组织、缓存、刷新和评估，是一种工程化而非手艺化的思维方式。",
|
|||
|
|
"keywords": [
|
|||
|
|
"信息组织",
|
|||
|
|
"上下文窗口",
|
|||
|
|
"token 预算",
|
|||
|
|
"动态检索",
|
|||
|
|
"RAG",
|
|||
|
|
"Prompt Engineering 区别",
|
|||
|
|
"上下文生命周期",
|
|||
|
|
"信息压缩",
|
|||
|
|
"分块策略",
|
|||
|
|
"优先级排序"
|
|||
|
|
],
|
|||
|
|
"scoring_rubric": "满分10分。信息组织维度（2分）：需提及多源信息编排和优先级排序。上下文窗口管理维度（2分）：需提及 token 预算、压缩/摘要、注意力衰减等概念。动态检索策略维度（2分）：需提及 RAG 管线和实时触发。与 Prompt Engineering 的区别（2分）：需明确对比单次措辞优化 vs 系统性生命周期管理。整体表达（2分）：逻辑清晰、术语准确。",
|
|||
|
|
"explanation": "Context Engineering 是 2024-2025 年 AI 工程领域兴起的核心概念，由 Andrej Karpathy 等人推广。它标志着 AI 应用开发从「调提示词」到「管上下文」的范式转变。传统 Prompt Engineering 像是编辑一篇文章的措辞，而 Context Engineer 则像是设计整个信息管道——决定什么信息在什么时候以什么形式进入模型的视野。这一角色在 RAG 系统、多轮对话、Agent 系统中尤为重要，因为这些场景下上下文的质量直接决定了输出的质量。",
|
|||
|
|
"source": null,
|
|||
|
|
"related": []
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"id": "sa-002",
|
|||
|
|
"type": "short_answer",
|
|||
|
|
"difficulty": 4,
|
|||
|
|
"tags": [
|
|||
|
|
"ai-agent",
|
|||
|
|
"harness-engineering",
|
|||
|
|
"tool-calling"
|
|||
|
|
],
|
|||
|
|
"question": "请对比 ReAct 与 Plan-and-Execute 两种 Agent 执行模式的核心差异，分别说明它们的执行流程、适用场景和各自的优缺点，并给出在实际项目中选择这两种模式的决策依据。",
|
|||
|
|
"answer": "ReAct（Reasoning + Acting）模式采用「思考-行动-观察」的交替循环：每一步先推理下一步该做什么，执行工具调用，获取结果后再推理下一步。其执行流程是线性的、即时决策的。优点是实现简单、对简单任务响应快、每步都有充分的环境反馈；缺点是缺乏全局规划，在多步骤复杂任务中容易偏离目标、陷入循环或重复无效操作。Plan-and-Execute 模式分为两阶段：先由 Planner 生成完整的执行计划（任务分解），再由 Executor 按计划逐步执行，执行过程中可反馈修正计划。优点是对复杂任务有全局视野、可预估资源消耗、支持并行执行子任务；缺点是计划生成本身消耗额外 token、初始计划可能不准确需要修正机制、对动态变化的环境适应性较弱。选择决策依据：(1) 任务步骤少于 3-4 步且逻辑简单时选 ReAct；(2) 任务可清晰分解、有明确子目标时选 Plan-and-Execute；(3) 需要实时适应环境变化的场景选 ReAct；(4) 对执行成本和时间有预算约束时选 Plan-and-Execute（可提前预估）。",
|
|||
|
|
"keywords": [
|
|||
|
|
"ReAct",
|
|||
|
|
"Plan-and-Execute",
|
|||
|
|
"思考-行动-观察",
|
|||
|
|
"任务分解",
|
|||
|
|
"执行计划",
|
|||
|
|
"全局规划",
|
|||
|
|
"循环执行",
|
|||
|
|
"并行执行",
|
|||
|
|
"token 消耗",
|
|||
|
|
"决策依据"
|
|||
|
|
],
|
|||
|
|
"scoring_rubric": "满分10分。ReAct 模式描述（2分）：需提及交替循环和即时决策特征。Plan-and-Execute 模式描述（2分）：需提及两阶段分离和计划修正机制。优缺点对比（3分）：双方各至少一个优点和一个缺点，共需覆盖至少4个对比维度。选择决策依据（2分）：需给出至少2条具体的决策条件。整体表达（1分）：逻辑清晰、术语准确。",
|
|||
|
|
"explanation": "ReAct 来自 Yao et al. 2022 年的论文，将 CoT 推理与工具调用交替进行，是当前大多数 Agent 框架（如 LangChain AgentExecutor）的默认模式。Plan-and-Execute 则参考了人类「先想后做」的策略，LangGraph、AutoGPT 等框架支持这种模式。在实际工程中，很多成熟的 Agent 系统会混合使用：对顶层任务使用 Plan-and-Execute 做全局规划，对子任务内部使用 ReAct 做灵活执行。选择时还需考虑 LLM 的能力——较弱的模型可能无法生成可靠的全局计划，此时 ReAct 的逐步决策反而更稳健。",
|
|||
|
|
"source": null,
|
|||
|
|
"related": []
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"id": "sa-003",
|
|||
|
|
"type": "short_answer",
|
|||
|
|
"difficulty": 3,
|
|||
|
|
"tags": [
|
|||
|
|
"ai-agent",
|
|||
|
|
"pluggable-config"
|
|||
|
|
],
|
|||
|
|
"question": "在智能体架构设计中，单 Agent 与多 Agent 架构分别适用于什么场景？请从任务复杂度、系统可靠性、开发维护成本、扩展性四个方面进行对比分析，并举出一个适合采用多 Agent 架构的典型业务场景。",
|
|||
|
|
"answer": "单 Agent 架构适用于：任务逻辑清晰、工具调用链路短、领域单一的场景。多 Agent 架构适用于：任务涉及多个专业领域、需要角色分工协作、工作流复杂的场景。四维度对比：(1) 任务复杂度：单 Agent 适合步骤少于 5-7 步的线性任务；多 Agent 适合需要并行处理、条件分支、多轮协商的复杂工作流。(2) 系统可靠性：单 Agent 故障点集中，一个环节出错影响整体；多 Agent 通过职责隔离降低级联故障风险，但引入了 Agent 间通信的故障点。(3) 开发维护成本：单 Agent 开发周期短、调试简单；多 Agent 需要设计通信协议、状态同步、错误恢复机制，维护成本显著更高。(4) 扩展性：单 Agent 功能扩展受上下文窗口限制，新工具增加会稀释已有能力；多 Agent 可通过新增专业 Agent 实现水平扩展，各 Agent 独立迭代。典型多 Agent 场景：企业级代码审查系统——由代码分析 Agent 负责静态检查、安全审计 Agent 负责漏洞扫描、架构评审 Agent 负责设计模式评估、报告生成 Agent 汇总结果，各 Agent 并行工作后由编排器合并输出。",
|
|||
|
|
"keywords": [
|
|||
|
|
"单 Agent",
|
|||
|
|
"多 Agent",
|
|||
|
|
"职责隔离",
|
|||
|
|
"角色分工",
|
|||
|
|
"通信协议",
|
|||
|
|
"上下文窗口",
|
|||
|
|
"水平扩展",
|
|||
|
|
"编排器",
|
|||
|
|
"故障点",
|
|||
|
|
"级联故障"
|
|||
|
|
],
|
|||
|
|
"scoring_rubric": "满分10分。单 Agent 适用场景（1分）。多 Agent 适用场景（1分）。四维度对比（各1.5分，共6分）：需覆盖任务复杂度、可靠性、成本、扩展性。典型场景举例（2分）：需具体且合理。整体表达（1分）。",
|
|||
|
|
"explanation": "架构选择的核心原则是「够用就好」——单 Agent 能解决的问题不要过度设计为多 Agent。多 Agent 的优势在于专业化分工（每个 Agent 的 prompt 更聚焦、工具集更精简），但代价是协调开销。在实际工程中，很多团队采用「混合架构」：核心流程用单 Agent，特定子流程拆分为独立 Agent。编排方式也有多种选择——中心化编排器（Orchestrator）、去中心化协商（Chat/Debate）、流水线（Pipeline）等，需要根据业务特点选择。",
|
|||
|
|
"source": null,
|
|||
|
|
"related": []
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"id": "sa-004",
|
|||
|
|
"type": "short_answer",
|
|||
|
|
"difficulty": 4,
|
|||
|
|
"tags": [
|
|||
|
|
"mcp",
|
|||
|
|
"tool-calling",
|
|||
|
|
"permission"
|
|||
|
|
],
|
|||
|
|
"question": "MCP（Model Context Protocol）协议在设计时需要考虑哪些安全问题？请从身份认证、权限控制、数据隔离、传输安全、防注入攻击五个方面阐述 MCP 的安全考量与设计原则，并说明 MCP Host、MCP Server、MCP Client 三者在安全责任上的分工。",
|
|||
|
|
"answer": "MCP 协议的安全考量涵盖五个核心方面：(1) 身份认证：MCP Client 与 MCP Server 之间需要建立双向身份验证，通常基于 OAuth 2.0 或 API Key，确保只有授权的 Client 能访问 Server 暴露的工具和资源。(2) 权限控制：MCP Server 应遵循最小权限原则，每个工具声明所需的权限级别，Host 层面实施用户确认机制（human-in-the-loop），对敏感操作（如文件写入、数据库修改）要求用户显式授权。(3) 数据隔离：不同 Client 的会话数据应严格隔离，Server 不得在未授权情况下跨会话共享数据；Server 本地存储的凭证和配置文件需要加密保护。(4) 传输安全：所有 MCP 通信应使用 TLS/HTTPS 加密传输，本地 stdio 传输模式需确保进程间通信不被第三方窃听。(5) 防注入攻击：MCP Server 需要对 LLM 生成的工具调用参数进行严格校验和转义，防止 Prompt Injection 通过工具参数传递到下游系统；Server 不应盲目执行未经验证的指令。安全责任分工：MCP Host（如 IDE、聊天应用）负责用户身份管理、权限策略制定和 human-in-the-loop 审批；MCP Client（协议客户端）负责建立安全连接、传输层加密和会话隔离；MCP Server（工具提供方）负责输入校验、权限边界执行和数据保护。",
|
|||
|
|
"keywords": [
|
|||
|
|
"MCP",
|
|||
|
|
"身份认证",
|
|||
|
|
"OAuth 2.0",
|
|||
|
|
"最小权限",
|
|||
|
|
"human-in-the-loop",
|
|||
|
|
"数据隔离",
|
|||
|
|
"TLS",
|
|||
|
|
"Prompt Injection",
|
|||
|
|
"输入校验",
|
|||
|
|
"安全责任分工"
|
|||
|
|
],
|
|||
|
|
"scoring_rubric": "满分10分。五个安全方面（各1.2分，共6分）：每方面需给出具体的安全措施或设计原则。安全责任分工（2分）：需清晰区分 Host、Client、Server 的职责。整体表达（2分）：术语准确、逻辑清晰。",
|
|||
|
|
"explanation": "MCP 协议由 Anthropic 于 2024 年底提出并开源，旨在为 LLM 应用提供标准化的工具和资源访问协议。安全是 MCP 生态的核心关注点——因为 MCP Server 本质上是让 LLM 代理用户执行操作，一旦被恶意利用（如通过 Prompt Injection 诱导 LLM 调用危险工具），后果可能很严重。MCP 规范中推荐的 OAuth 2.0 PKCE 流程、工具的 annotation 标注（如 readOnlyHint、destructiveHint）以及 Host 层的用户确认机制，都是为了在便利性和安全性之间取得平衡。在企业场景中，还需要额外考虑审计日志、操作回滚、沙箱隔离等措施。",
|
|||
|
|
"source": null,
|
|||
|
|
"related": []
|
|||
|
|
},
|
|||
|
|
{
|
|||
|
|
"id": "sa-005",
|
|||
|
|
"type": "short_answer",
|
|||
|
|
"difficulty": 4,
|
|||
|
|
"tags": [
|
|||
|
|
"guardrail",
|
|||
|
|
"llm-ops",
|
|||
|
|
"tool-calling",
|
|||
|
|
"permission"
|
|||
|
|
],
|
|||
|
|
"question": "请描述一个生产级 LLM 应用中 Guardrail（护栏）系统的完整实现方案，包括输入侧护栏和输出侧护栏各自承担的职责、具体的技术实现手段，以及 Guardrail 系统在整体架构中的位置和与主 LLM 调用链路的关系。",
|
|||
|
|
"answer": "生产级 Guardrail 系统分为输入侧和输出侧两道防线，包裹在主 LLM 调用链路的前后。输入侧护栏职责：在用户输入到达 LLM 之前进行安全过滤和预处理。具体技术手段包括：(1) Prompt Injection 检测——使用分类器或规则引擎识别恶意指令注入尝试；(2) 敏感信息脱敏——正则匹配或 NER 模型识别并替换手机号、身份证号等 PII 数据；(3) 输入长度和格式校验——防止超长输入导致 token 溢出；(4) 意图分类和话题限制——识别超出系统能力范围或不在授权领域内的请求。输出侧护栏职责：在 LLM 响应返回用户之前进行质量和安全审核。具体技术手段包括：(1) 幻觉检测——将输出与检索到的源文档交叉验证，检测无据可依的事实陈述；(2) 有害内容过滤——使用毒性分类模型检测仇恨、暴力、违法内容；(3) 格式合规检查——验证 JSON Schema、工具调用格式等结构化输出是否合规；(4) 敏感信息防泄露——检测模型输出中是否包含训练数据泄露或内部系统信息；(5) 事实一致性校验——确保多轮对话中的输出不与已确认的事实矛盾。架构位置与关系：Guardrail 系统作为独立的中间件层，以管道（Pipeline）模式嵌入主调用链路——输入护栏在用户请求之后、LLM 调用之前执行，输出护栏在 LLM 返回之后、用户接收之前执行。两者都采用异步可选的执行模式：拦截到高风险问题时直接拒绝并返回安全提示，低风险问题可标记后放行。在高吞吐场景下，Guardrail 可使用轻量级模型（如 BERT-based 分类器）以控制延迟。",
|
|||
|
|
"keywords": [
|
|||
|
|
"Guardrail",
|
|||
|
|
"输入护栏",
|
|||
|
|
"输出护栏",
|
|||
|
|
"Prompt Injection 检测",
|
|||
|
|
"PII 脱敏",
|
|||
|
|
"幻觉检测",
|
|||
|
|
"有害内容过滤",
|
|||
|
|
"格式合规",
|
|||
|
|
"管道模式",
|
|||
|
|
"分类器",
|
|||
|
|
"human-in-the-loop"
|
|||
|
|
],
|
|||
|
|
"scoring_rubric": "满分10分。输入侧护栏（3分）：需涵盖至少3种具体技术手段。输出侧护栏（3分）：需涵盖至少3种具体技术手段。架构位置与关系（2分）：需说明管道模式和独立中间件层。整体表达（2分）：结构清晰、技术细节准确。",
|
|||
|
|
"explanation": "Guardrail 是 LLM 应用从实验走向生产的必备组件。业界常用的实现方案包括：NVIDIA NeMo Guardrails（开源，支持对话流控制和主题限制）、Guardrails AI（专注输出校验和自动修复）、Lakera Guard（专注 Prompt Injection 检测）。在实际工程中，Guardrail 的设计需要权衡安全性和延迟——过严的过滤会降低用户体验，过松则可能放行有害内容。最佳实践是分层防御（Defense in Depth）：轻量级规则引擎做快速拦截，重量级模型做精细判断，结合人工审核处理边界案例。此外，Guardrail 系统本身也需要监控和迭代——通过 A/B 测试和人工标注持续优化检测模型的准确率和召回率。",
|
|||
|
|
"source": null,
|
|||
|
|
"related": []
|
|||
|
|
}
|
|||
|
|
]
|
|||
|
|
}
|