AIKnowledge Base

INTERVIEW PLAYBOOK

面试专项

从知识理解切换到表达训练：回答框架、追问路径、临场速览与自检清单集中在这里。

复习路径定义 → 取舍 → 案例
训练方式追问 · 速答 · 自检
访问范围全部公开

AI / LLM / Agent 面试专项#

面试专项是知识库的复习视图，不替代正文。这里集中整理定义模板、追问路径、回答框架与临场检查清单；需要理解原理时，请回到 知识库首页。

推荐顺序：一句话定义 → 关键机制 → 工程取舍 → 失败案例 → 可量化结果。不要只背术语，要能解释为什么这样设计。

1.8 面试怎么答#

Q：什么是 AI Agent？它和传统 LLM 应用有什么区别？

Agent 是能感知环境、调用工具、根据反馈迭代决策的 LLM 程序。传统 LLM 应用大多是「输入 → 输出」的单轮模式；Agent 是「输入 → 思考 → 行动 → 观察 → 再思考」的循环模式。它的核心优势是能处理目标明确但路径不确定的任务，比如代码修改、多步骤调研、复杂故障排查。

1.9 面试追问与深挖回答#

追问 1：Agent 循环里哪一步最容易出问题？

最容易出问题的通常是执行后的反馈。模型可能忽略负面结果、在错误方向上继续推进，也可能因为工具输出过长导致上下文稀释。工程上需要结构化错误返回、截断/摘要工具输出、在上下文中保留任务目标摘要。

追问 2：Agent 和 Workflow 的边界在哪里？

边界在于步骤是否预先确定。Workflow 是编译期确定的有向图，适合审批、ETL 等确定性流程；Agent 是运行期根据观察动态决策，适合调试、研究、故障排查。实际中常常混合：外层 Workflow 保证关键节点，内层 Agent 处理弹性子任务。

追问 3：怎么防止 Agent 无限循环？

设置多维预算：最大步数、最大工具调用次数、最大 Token 消耗、最大执行时间。同时加终止条件识别：任务完成、连续多次相同动作、成本超过阈值、模型返回 final_answer。

2.7 面试怎么答#

Q：ReAct 和 Plan-and-Execute 有什么区别？

ReAct 是「边想边做」，每一步根据观察结果决定下一步，适合路径不确定、需要灵活调整的任务；Plan-and-Execute 是「先规划再执行」，适合目标明确、步骤可预先拆分的任务。实际工程中经常结合使用：高层用 Plan-and-Execute 拆阶段，每个阶段内部用 ReAct 执行具体工具调用。

2.8 面试追问与深挖回答#

追问 1：Plan/Step/Type 里的 Type 有什么用？

Type 是 Step 的能力标签，决定由哪个执行器或 Agent 处理。例如 websearch 走检索器、research 走分析 Agent、coding 走 Coder Agent、processing 走汇总节点。它让复杂 Plan 可以被专业化分工执行，并支持按类型做并行度控制、失败隔离和成本归因。

追问 2：任务执行中 Step 失败怎么处理？

常见策略：重试（幂等步骤）、跳过（非关键步骤）、替换等价 Step、触发 replan。需要在设计时给每个 Step 定义失败语义和回退方案，并在 Plan 中显式标记关键路径和非关键路径。

追问 3：并行 Step 怎么保证正确性？

先分析 Step 间的依赖关系，构建 DAG；只有无依赖的 Step 才能并行。对于读写共享状态的 Step，需要加同步或拆成串行。工程上可以通过 dependencies: ["s1", "s2"] 这样的字段描述依赖。

3.6 面试怎么答#

Q：多 Agent 协作有什么优势和挑战？

优势是可以把复杂任务按能力拆分，每个 Agent 负责自己擅长的子任务，比如一个负责检索、一个负责编码、一个负责审查。挑战在于状态同步、上下文管理、失败传播和成本爆炸。工程上需要明确的编排协议、状态共享机制和停止条件。

3.7 面试追问与深挖回答#

追问 1：Orchestrator 和 Worker 的上下文怎么共享？

常见做法是把任务状态、中间结果、全局约束写入共享存储（Redis、数据库、消息队列）。Orchestrator 发布任务时附带上下文摘要，Worker 完成后把结果写回。需要注意上下文不要无限膨胀，关键信息做摘要，非关键历史做归档。

追问 2：多 Agent 协作会不会比单 Agent 更慢更贵？

会。多 Agent 带来额外的通信、状态同步和模型调用开销。只有在任务本身适合拆分、单 Agent 上下文无法承载、或者需要专业化分工时才值得。成本控制手段：小模型做路由/简单 Worker，大模型只做复杂推理；对常见路径做缓存；限制并行度和最大轮数。

追问 3：Cross-review 怎么避免两个 Agent 互相附和？

让两个 Agent 扮演不同角色（如「安全审查员」vs「性能审查员」），给出不同的评估维度；或者引入第三方仲裁 Agent。关键是让审查标准显式化，而不是泛泛地问「这个好不好」。

4.9 面试怎么答#

Q：MCP 和 Function Calling / Tool Calling 有什么区别？

两者不是替代关系。**Function Calling（当前更通用的叫法是 Tool Calling）**是模型 API 的调用层：模型根据 JSON Schema 返回“调用哪个工具、参数是什么”，应用执行后把结果回填。MCP是工具接入层：Host 用统一协议发现并连接外部 Server 的 tools、resources、prompts，再把可用工具提供给模型。常见链路是：MCP tools/list → Host 适配为 provider tools → 模型 tool call → Host tools/call → tool result 回填。所以 Function Calling 没有过时；它仍是 Agent runtime 的核心控制环，MCP 解决的是跨客户端、跨服务复用工具的问题。

4.10 面试追问与深挖回答#

追问 1：stdio 和 Streamable HTTP 怎么选？

本地、低延迟、强隔离场景用 stdio，凭据走环境变量注入，网络暴露面为零；需要团队共享、远端部署、Gateway 聚合、审计入口时用 Streamable HTTP，并接入 OAuth 或服务端令牌策略。SSE 是它可选的流式能力，不是第三条平行协议线。

追问 2：怎么防止 MCP server 被 prompt injection 滥用？

三层防御：Host 层工具白名单 + 预授权/用户确认；Server 层参数 schema 校验 + 业务权限校验 + 输入过滤；进程/网络层独立进程、最小权限凭据、输出脱敏。不能把安全完全交给模型提示词。

追问 3：MCP server 的凭据应该怎么管理？

凭据由 server 进程持有，通过环境变量或 secret 注入，绝不出现在 prompt、工具描述或返回结果中。读工具用只读账号，写工具用受限账号，生产环境定期轮换。

更新参考（2026-08）：OpenAI Function Calling / Tool Calling 指南｜MCP Architecture｜MCP Python SDK（FastMCP）

5.8 面试怎么答#

Q：RAG 和 Agentic RAG 有什么区别？

传统 RAG 是「检索 → 拼接上下文 → 生成」的固定管道，适合简单事实查询；Agentic RAG 把检索控制权交给 Agent，能根据问题动态决定检索策略、多次检索、交叉验证，适合复杂多跳问题和企业知识库问答。

5.9 面试追问与深挖回答#

追问 1：Agentic RAG 一定会比普通 RAG 好吗？

不一定。简单 FAQ、单次检索就能回答的问题没必要引入 Agent；复杂多跳、跨源验证、需要动态补充信息的场景才收益明显。引入 Agent 会带来延迟和成本上升，需要评估投入产出。

追问 2：怎么控制 Agentic RAG 的延迟和成本？

设置最大迭代次数、使用小模型做路由/反思、对常见查询走缓存、用 rerank 减少传入大模型的片段数、对检索失败走快速 fallback。

追问 3：ReAct RAG 和 Self-RAG 有什么异同？

ReAct 是通用决策-行动循环，适合规划检索路径；Self-RAG 是生成阶段插入反思 token 的特定训练/推理方案，需要模型原生支持或微调。两者可结合：ReAct 负责规划，Self-RAG 负责每一步生成后的自评。

6.8 面试怎么答#

Q：什么是 Harness Engineering？为什么它比 Prompt Engineering 更重要？

Harness Engineering 是 AI 原生软件工程的新范式，核心思想是「工程化驾驭 AI」。Prompt Engineering 只优化单次输入，无法应对长链路、多轮迭代；Harness Engineering 通过意图解构、过程约束、评测体系，把 AI 嵌入复杂工程的完整流程中，让它可预测、可评测、可回溯。论文实证表明，很多时候只改 Harness 不改模型，带来的提升远超换模型。

6.9 面试追问与深挖回答#

追问 1：ETCLOVG 为什么要拆成七层？

前三层（E/T/C/L）是运行底座，回答 Agent 能不能动、会不会动；后三层（O/V/G）是管控平面，回答动起来后可不可见、可不可靠、可不可控。把 Observability 和 Governance 独立出来，是因为它们有独立工具栈和责任主体（安全团队、SRE），不应混在生命周期里。

追问 2：最小可用 Harness 怎么设计？

顺序：定义任务边界与成功标准 → 准备可重置执行环境 → 暴露少量高质量工具 → 建立上下文预算 → 设置编排循环和停止条件 → 打开追踪与成本归因 → 把失败变成回归测试 → 加权限和审计。

追问 3：Harness 和 Agent 框架是什么关系？

Agent 框架是具体实现（如 LangGraph、AutoGen、Claude Code），Harness Engineering 是设计这些实现的工程方法论。好的框架会在内部自然映射到 ETCLOVG 七层。

7.7 面试怎么答#

Q：Agent 沙箱为什么重要？

Agent 会运行代码、读写文件、访问网络，没有沙箱时每个风险动作都要人工确认，导致权限疲劳和不可复现。沙箱通过最小权限、资源预算、网络白名单把风险关进边界，使低风险动作自动执行、高风险动作显式审批，同时保证评测环境可重置。

Q：Agent governance 中 H1–H4 分别是什么？

H1 是输入护栏，检查 prompt 注入和敏感内容；H2 是动作执行前的权限判断和风险分级；H3 是执行后的信息流控制，防止敏感结果污染上下文；H4 是人在回路审批，针对高风险动作。

7.8 面试追问与深挖回答#

追问 1：沙箱和治理是什么关系？

沙箱是治理策略的物理执行边界，解决「能不能做」；治理策略是沙箱规则的抽象表达，解决「允不允许做」。两者互补：沙箱限制资源访问范围，治理决定什么动作需要审批、什么动作直接拒绝。

追问 2：评估器本身也会出错，怎么保证评估可信？

定期做元评估（evaluating the evaluator）：人工抽检、对抗样本、交叉评估。软失败（分数在 0.5-0.8 之间）应作为率指标跟踪，当 ≥33% 试验落入软失败区间时暂停发布并调查根因。

追问 3：低风险动作自动执行会不会导致批量事故？

会，所以必须满足三个条件：动作在沙箱内、权限最小、有完整审计日志。即使低风险，也不能跨出沙箱边界。同时通过 rate limit 和熔断防止批量异常。

8.8 面试怎么答#

Q：LLM Wiki 和向量 RAG 各适合什么场景？

向量 RAG 适合海量非结构化文档的模糊检索；LLM Wiki 适合高价值、需要结构化、可追溯的知识。它的优势是人类可读、git 可版本、冲突可发现，适合长期维护的个人或团队知识库。实际中两者可以互补：Wiki 做结构化知识骨架，RAG 做海量文档召回。

8.9 面试追问与深挖回答#

追问 1：LLM Wiki 怎么保证知识不漂移？

四原则：每条知识链回来源、关键数字标源、冲突显式标注、没有出处写 (?)。另外通过定期 lint 发现孤儿页、过期页、缺来源页，由 librarian agent 或人工维护。

追问 2：LLM Wiki 和 GraphRAG 有什么区别？

GraphRAG 用图结构做实体关系推理，适合复杂关联查询但工程重；LLM Wiki 用轻量 markdown + wikilink，强调人类可读和可维护。两者可以互补：Wiki 做主体知识，GraphRAG 做关系推理增强。

追问 3：LLM Wiki 的检索效果会不会不如向量 RAG？

在模糊语义匹配上确实不如向量 RAG，但在结构化、可追溯、冲突发现上更强。实际落地通常是双轨：高频简单查询走向量 RAG，高价值复杂知识走 LLM Wiki，必要时由 Agent 决定从哪检索。

12.10 面试追问与回答框架#

下面列出面试官高频深入问题，以及可以直接套用的回答框架：

Q2：Agent 调用工具失败了，怎么优雅处理？

三步：

  1. 工具返回统一错误契约，带 retryable 字段。
  2. Agent 看到 retryable=true 自动重试，并在 prompt 里提示「可以重试」。
  3. 如果重试失败或 retryable=false，返回「当前进展 + 未完成项 + 建议人工介入」。 对高风险写操作，必须人工审批。

Q3：怎么防止 Agent 无限循环或失控？

多层保险：

  1. max_turns / max_tool_calls 硬限制。
  2. 循环检测：连续相同 tool_call 直接截断。
  3. Guardrails 对每次调用做授权。
  4. 超时/熔断：单步超时、整体超时。
  5. 成本上限：单请求 token 或费用阈值。

Q4：Agent 的记忆怎么设计才能不爆炸？

三层记忆 + 预算管理：

  1. 工作记忆只保留最近 N 条 + 系统提示。
  2. 短期记忆用 ThreadState 存 todo/产物，老消息自动总结。
  3. 长期记忆只存高价值、结构化、去重后的知识，不要全量日志。
  4. 工具返回做摘要，大结果用 summary + detail_url。

Q5：怎么评估一个 Agent 的好坏？

用 Task Success Rate、Tool Accuracy、Hallucination Rate、Latency、Cost 五个核心指标；离线跑测试集，在线 shadow + A/B，人工 review 失败案例并沉淀回归用例。LLM-as-judge 只做辅助，关键字段用规则校验。

Q6：MCP Server 和内部微服务怎么衔接？

MCP Server 是「适配层」：内部微服务保持原样，MCP Server 做协议转换、鉴权、参数校验、错误包装。一个 MCP Server 可以聚合多个微服务，但不要把业务逻辑写进去。部署上独立发布，Agent 通过 registry 发现。

AI Agent 通识补遗（源自 ai-agent-guide）#

13.8 Token 成本速查（面试常用锚点）#

开源 vs 闭源模型选型五维度：数据隐私（敏感场景必须开源自部署）、成本（高频开源长期划算，低频闭源按量省）、能力上限（闭源推理/工具调用通常领先）、可控性（要微调选开源）、生态（闭源 API 更稳定）。常见混合策略：关键场景闭源、辅助场景开源。

补遗 · AI 编码 CLI / Agent 工具生态（hook · subagent · workflow）#

T.7 面试速答#

面试前 30 分钟速览#

11.6 面试前检查清单#

临场冲刺#

面试高频问题与回答思路#

Q1：什么是 Agent？最小循环是什么？#

思路：定义 + 最小循环 + 与 LLM 应用的区别。

Agent 是能感知环境、调用工具、根据反馈迭代决策的 LLM 程序。最小循环是感知 → 推理 → 执行 → 反馈。传统 LLM 应用是单轮输入输出，Agent 是多轮循环。

Q2：ReAct / Plan-and-Execute / Reflexion 有什么区别？#

思路：三种模式的核心循环 + 适用场景 + 工程上如何结合。

ReAct 边想边做，适合路径不确定；Plan-and-Execute 先规划再执行，适合步骤清晰；Reflexion 增加执行后反思，适合迭代优化。工程上常结合：高层 Plan-and-Execute 拆阶段，阶段内 ReAct 执行，执行后 Reflexion 复盘。

Q3：MCP 是什么？和 Tool Calling / Function Calling 有什么区别？#

思路：USB-C 接口比喻 + 完整生命周期 + 权限模型。

MCP 是 Host ↔ Client ↔ Server 的工具接入协议，负责发现能力、交换 tools/resources/prompts 与传输鉴权；Tool Calling 是模型 API 的调用机制，Function Calling 是最常见的 JSON Schema 工具形态。两者互补：Host 可将 MCP 的工具 schema 提供给模型，模型返回 tool call 后再由 Host 受控地调用 MCP Server 并回填结果。

Q4：RAG 和 Agentic RAG 有什么区别？#

思路：固定管道 vs 动态检索控制 + 典型模式（ReAct RAG / Self-RAG / CRAG）。

传统 RAG 是检索 → 拼接 → 生成的固定管道；Agentic RAG 把检索控制权交给 Agent，能动态决定检索次数、来源、查询改写，并能交叉验证。典型模式有 ReAct RAG、Self-RAG、CRAG、Multi-Agent RAG。

Q5：什么是 Harness Engineering？ETCLOVG 七层是什么？#

思路：范式演进 + 七层名称/定位 + 论文实证。

Harness Engineering 是工程化驾驭 AI 的新范式，超越 Prompt Engineering 和 Context Engineering。ETCLOVG 七层是 Execution、Tooling、Context、Lifecycle、Observability、Verification、Governance。论文实证显示只改 Harness 不改模型，编码基准最高提升 10 倍。

Q6：Agent 沙箱设计要点是什么？#

思路：三大价值 + 最小权限 + 资源预算 + 网络/密钥隔离。

沙箱提供安全隔离、可复现性、提升自主性。设计要点：最小权限、资源预算、网络白名单默认拒绝、密钥隔离、快照与回滚。

Q7：Agent 治理中 H1–H4 是什么？#

思路：输入护栏 → 动作护栏 → 人审 → 执行 → 信息流控制。

H1 输入护栏，检查 prompt 注入和敏感内容；H2 动作护栏，做权限判断和风险分级；H4 高风险人审；H3 执行后信息流控制，防止敏感结果污染上下文。

Q8：LLM Wiki 和向量 RAG 怎么选？#

思路：适用场景对比 + 互补思路 + 四原则。

向量 RAG 适合海量非结构化文档模糊检索；LLM Wiki 适合高价值、结构化、可追溯知识。两者互补：Wiki 做骨架，RAG 做海量召回。LLM Wiki 四原则：可追溯、标来源、显式冲突、不编造。

Q9：你们公司/团队的 AI 工程化落地了哪些东西？#

Q10：如果让你设计一个企业内部 AI 助手，你会怎么设计？#

思路：

  1. 明确场景和边界（HR/IT/法务？）；
  2. 知识库建设（RAG / LLM Wiki / 向量库）；
  3. 工具封装与调用层（MCP 接入 + Tool Calling）；
  4. 权限与治理（H1–H4、沙箱、审计）；
  5. 可观测与评估（trace、失败分类、回归测试）。

我会先明确业务边界，然后建知识库（向量 RAG + LLM Wiki 互补），把内部系统封装成 MCP 工具，按角色做动态权限。治理上走 H1-H4 四层护栏，执行放沙箱。最后加 trace 和评估闭环，把失败分类沉淀成回归测试。

Q11：怎么防止 Agent 调用危险工具？#

思路：三层防御 + 风险分级 + 人审。

Host 层工具白名单 + 预授权/用户确认；Server 层 schema 校验 + 业务权限校验 + 输入过滤；进程/网络层独立进程 + 最小权限 + 输出脱敏。同时按风险分级：低风险自动、中风险限制、高风险人审、禁止类拒绝。

Q12：Agent 评估和普通 LLM 评估有什么不同？#

思路：Episode 级评估 + 失败分类 + 轨迹评估。

Agent 评估不能只看最终答案，要看整个 episode：最终答案、执行轨迹、评估器可信度。失败要分类为规划失败、工具选择失败、上下文失败、环境失败、安全失败、评估失败，并沉淀为回归测试。

Q13：Context Engineering 和 Prompt Engineering 的区别？#

思路：单轮优化 vs 多轮信息流管理。

Prompt Engineering 优化单次输入；Context Engineering 优化多轮交互中模型每一步看到什么，包括上下文预算分配、摘要、记忆、检索结果注入。

Q14：Agentic RAG 的延迟和成本怎么控制？#

思路：预算 + 缓存 + rerank + 小模型路由。

设置最大迭代次数、使用小模型做路由和反思、对常见查询走缓存、用 rerank 减少传入大模型的片段数、检索失败走快速 fallback。

Q15：多 Agent 系统如何保持一致性？#

思路：共享状态 + 约束广播 + 版本化上下文。

通过共享状态存储（Redis/DB/消息队列）同步进度，Orchestrator 定期广播全局约束，每个 Agent 的上下文包含任务目标摘要和最新状态快照，避免长任务中遗忘目标。

Q19：你怎么设计一个稳定的 prompt？#

思路：模板 + System/User 分离 + 反面教材 + 输出格式约束。

固定段落模板：身份 → 任务 → 约束 → 步骤 → 异常处理 → 输出格式。System 负责“你是谁、能做什么、不能做什么”，User 负责“现在用户想问什么”。把测出来的错误答法写成反面教材 EXAMPLES，比只给正确模板更能防幻觉；复杂输出要求 JSON Schema / 字段说明 / 枚举值，并要求“仅输出 JSON”。

Q20：上下文工程的核心是什么？怎么防止上下文过长导致成本飙升？#

思路：分层、截断、摘要、传递，而不是塞得多。

上下文工程的核心是管理模型每一步看到什么。短期记忆用滑动窗口存最近 N 轮；长期记忆走向量检索；工具返回先摘要再注入；跨 Agent 节点用结构化 JSON handoff，而不是继承完整会话历史。对常见查询走缓存，只在异常诊断时触发大模型，能从源头控制 token 消耗。

Q21：在 multi-agent pipeline 里上下文怎么在节点间传递？#

思路：结构化 handoff + 链路分层 + 共享状态。

每个节点输出约定 JSON，例如 classify 输出 {"type": "dead_dependency", "files": [...]}；下一节点只读取必要字段，不继承完整对话。任务级上下文（项目名、目标版本）写进每个 Agent 的 User 头部；节点级上下文只放当前 handoff；共享状态存到文件 / Redis，不塞进 LLM 上下文。这样支持并行、支持审计、失败也能从产物恢复。

Q22：实际项目中怎么控制 AI 成本？#

思路：模型分层 + 规则短路 + 缓存复用 + 降级兜底。

小模型做路由/分类/验证，大模型做生成/异常诊断，专用模型做 embedding/OCR。能用规则 + prompt 解决的，不新增服务；能用 websearch 规则化解决的，不做大模型微调。对常见路径做缓存，把一次性经验沉淀成 skill 和错误案例库；router 失败直接 fallback 或人工介入，不强行调用贵模型。

Q23：你怎么看待 AI 在工程里的作用？#

思路：放大器而非替代者 + 人在回路。

面试前 30 分钟速览#

本章是前面全部章节（核心技术 + 进阶工程 + 项目实践 + 高频问答）的「脱水版」。目标是：进面试间前 30 分钟快速过一遍，把术语、项目话术、高频问答重新激活。

11.1 核心概念一句话#

概念 一句话
Agent 能感知环境、调用工具、根据反馈迭代决策的 LLM 程序
ReAct 边推理边行动，每步输出 thought + action
Plan-and-Execute 先整体规划，再按步骤执行，适合步骤明确的任务
MCP Host ↔ Client ↔ Server 之间的工具协议，含完整生命周期
Tool Calling / Function Calling 模型输出结构化调用意图、宿主执行并回填结果的机制；与 MCP 互补，不存在“谁是谁子集”
RAG 检索增强生成，检索 → 拼接 → 生成
Agentic RAG 把检索控制权交给 Agent，能动态改写查询、交叉验证
Self-RAG 生成后自我评估是否需要检索或修正
CRAG 检索结果质量差时主动纠错或换源
Harness Engineering 工程化驾驭 AI 的范式，关注 Execution/Tooling/Context/Lifecycle/Observability/Verification/Governance
LLM Wiki 用结构化 Markdown + wikilink 管理高价值知识，强调可追溯和显式冲突
沙箱 给 Agent 执行提供隔离、可复现、可回滚的环境
Guardrails 按策略对 tool call 做授权判断，失败默认 closed
AIDC Agent 开发生命周期：Assess / Instrument / Develop / Curate
三层记忆 工作记忆（prompt）/ 短期记忆（ThreadState）/ 长期记忆（向量/Wiki）
Trace/Span/Event 请求链路 → 阶段 → 关键事件，Agent 可观测的三层语义
LLM-as-judge 用 LLM 给输出打分，必须配合规则校验和人工校准

11.2 关键技术对比表#

对比 A B C 选型依据
Prompt vs Workflow vs Agent 单轮优化 固定步骤 自主循环 确定性高 → Workflow；路径不确定 → Agent
Tool Calling vs MCP 模型调用层 工具接入层 MCP 负责发现/互联，Tool Calling 负责模型选择/回填；通常一起用
向量 RAG vs LLM Wiki 海量非结构文档模糊检索 高价值结构化知识 互补：Wiki 做骨架，RAG 做海量召回
Local Sandbox vs Docker Sandbox 开发便捷 生产隔离 本地用 Local，生产用 Docker
H1 vs H2 vs H3 vs H4 护栏 输入过滤 动作授权 信息流控制 高风险人审
ReAct vs Plan-and-Execute 边推理边执行 先规划再执行 路径依赖外部反馈 → ReAct；步骤可预枚举 → Plan
Shadow vs A/B vs Canary 并行影子验证 流量对照实验 渐进放量 新 prompt/模型/工具先用 shadow，再 A/B，再全量

11.4 高频问题速答#

Q1：什么是 Agent？

能感知环境、调用工具、根据反馈迭代决策的 LLM 程序。最小循环：感知 → 推理 → 执行 → 反馈。

Q2：MCP 和 Tool Calling / Function Calling 区别？

Tool Calling 是模型返回结构化调用意图、应用执行并回填结果的循环；Function Calling 是其常见 JSON Schema 形态。MCP 是 Host-Client-Server 的工具接入协议，负责发现、上下文原语、传输和鉴权。二者不是替代关系：MCP 接工具，Tool Calling 让模型选择并驱动工具。

Q3：RAG 和 Agentic RAG 区别？

RAG 是固定检索 → 拼接 → 生成；Agentic RAG 把检索控制权交给 Agent，可动态决定查几次、改查询、换来源、交叉验证。

Q6：LLM Wiki 和向量 RAG 怎么选？

向量 RAG 适合海量非结构化模糊检索；LLM Wiki 适合高价值、结构化、可追溯知识。两者互补。

Q8：Multi-Agent 协作有哪些模式？

Orchestrator-Worker、Cross-review、Competition、Hierarchical。关键是状态同步和职责边界。

Q10：AI 会替代工程师吗？

AI 加速规则明确、上下文可结构化的任务，但不能替人做业务判断。我们的原则是：AI 给方案，人判断；AI 执行，人验收。

Q11：Agent 工具失败了怎么办？

工具返回统一错误契约（含 retryable），Agent 自动重试可重试错误；不可重试或重试失败时返回「当前进展 + 未完成项 + 建议人工介入」，高风险写操作必须人工审批。

Q12：怎么防止 Agent 无限循环？

max_turns / max_tool_calls 硬限制 + 循环检测（连续相同 tool_call 截断）+ Guardrails 授权 + 单步/整体超时 + 成本上限。

Q13：怎么把 Agent 从 demo 推到生产？

按 ETCLOVG 七层检查：Execution（超时/重试/熔断）、Tooling（Schema/幂等/版本）、Context（窗口/记忆/RAG）、Lifecycle（ThreadState/Checkpoint）、Observability（Trace/Metric）、Verification（离线/在线/人工）、Governance（护栏/审计/沙箱）。

11.5 技术栈关键词索引#

面试时把这些词自然地带进回答，能显著提升专业感：

11.6 面试前检查清单#

授权内容#

企业内部项目案例不在公开面试页展示。获得授权后，可进入 企业项目实践。