面试 · 对比辨析型
考察目标：说清楚边界和取舍，避免概念混淆 约 10 题，覆盖 AI Agent 工程核心对比 说明：每题分「题干」（标题）与「参考答案」两段。
Q1：RAG vs Agent：知识获取 vs 任务执行；何时只需 RAG？何时必须 Agentic RAG？#
参考答案
| RAG | Agent | |
|---|---|---|
| 本质 | 知识获取（检索 + 生成） | 任务执行（决策 + 工具调用） |
| 决策 | 一次性（检索完就生成） | 多步（思考→行动→观察→再思考） |
| 工具 | 通常无 | 必有 |
| 状态 | 无任务状态 | 有任务状态、会话状态 |
何时只需 RAG：
- 知识问答（"公司请假政策是什么"）
- 文档总结（"总结这份 PDF"）
- 单跳检索（答案在一个文档里）
何时必须 Agentic RAG：
- 多跳问题（"对比 A 和 B 公司 Q3 营收" → 多次检索）
- 需要决策（"信息够了吗？要不要再查"）
- 跨源整合（RAG + SQL + Web）
- 任务导向（"帮我订机票" → 不只查，还要执行）
Q2：Workflow vs Autonomous Agent：可控 vs 灵活；企业为何先做 workflow？全自主的风险？#
参考答案
| Workflow | Autonomous Agent | |
|---|---|---|
| 流程 | 固定步骤 | 模型自主决策 |
| 可控性 | 高 | 低 |
| 灵活性 | 低 | 高 |
| 可预测 | 强 | 弱 |
| 可审计 | 强 | 弱 |
企业为何先做 workflow：
- 可预测、可审计（合规要求）
- 失败可定位（每步明确）
- 可灰度（按比例切流量）
- 风险可控（每步有边界）
全自主的风险：
- 跑飞了不知道干啥去了
- 出 bug 难定位（决策路径不可预测）
- 越权风险（自主决策可能调不该调的工具）
- 成本不可控（无脑烧 token）
实战策略：先 workflow 把可控场景做扎实，再逐步引入 Agent 自主决策到"受控区"（权限+预算+审批）。
Q3：LangChain vs LangGraph：组件 vs 状态图编排；复杂 Agent 为何需要 graph/state machine？#
参考答案
| LangChain | LangGraph | |
|---|---|---|
| 抽象 | 组件链（Chain） | 状态图（Graph） |
| 流程 | 线性 / 简单分支 | 复杂分支、循环、并行 |
| 状态 | 弱 | 强（stateful） |
| Checkpoint | 无 | 内置 |
| 适用 | 简单 LLM 应用 | 复杂 Agent 工作流 |
复杂 Agent 为何需要 graph/state machine：
- Agent 流程不是线性的（有分支、循环、并行）
- 需要状态持久化（断点恢复）
- 需要 HITL（人工审批插入点）
- 需要 multi-agent 协作（多个节点）
LangChain 的 Chain 抽象无法表达这些复杂度，LangGraph 的 Graph + State 才能。
Q4：Claude Code vs Codex：coding agent 为何需要文件编辑/shell/测试/git diff？两者的托管形态与扩展机制各解决什么？#
参考答案
Coding Agent 必备能力：
- 文件编辑（read/write/edit）— 改代码
- Shell 执行 — 跑测试、装依赖、git 操作
- 测试循环 — 客观验证改对了
- Git diff — 让人 review 改了什么
没有这些能力的"coding agent"只是聊天机器人，不能真的改代码。
先破一个常见误区：git worktree 隔离不是 Codex 独有——Claude Code 也原生支持 worktree，两边都能"多任务/多 Agent 并行不冲突"。真正的差异在托管形态和扩展机制：
| 维度 | Claude Code | Codex |
|---|---|---|
| worktree 隔离 | 支持 | 支持（不是差异点） |
| 托管形态 | 本地为主 + 远程混合 | 更偏 cloud / remote execution environment（云端容器里跑，跑飞了不碰本地） |
| 扩展机制 | hooks / subagents / skills（本地强控制、可编程拦截） | 更偏云端沙箱化的托管执行 |
Claude Code 扩展机制解决什么：
- Hooks：PreToolUse/PostToolUse 拦截，用代码强制规则（如阻止删生产代码）
- Subagents：context 隔离，主上下文不被子任务污染
- Skills：技能扩展，第三方能力（如 code-review 技能）
Codex 云端环境解决什么：
- 云端执行环境：任务跑在托管容器里，隔离性强、可规模化并行、跑飞了不影响本地机器
一句话：两者都能做隔离，取舍在"本地可编程控制（hooks/subagents/skills） vs 云端托管执行"这条主轴上。
Q5：MCP vs Function Calling：机制 vs 协议；FC 为何不足以解决企业级工具生态？#
参考答案
| Function Calling | MCP | |
|---|---|---|
| 本质 | 模型能力（决策调用） | 协议（标准化通信） |
| 范围 | 单次调用 | 工具发现、调用、资源暴露、双向原语 |
| 标准 | 厂商私有 | 开放标准（Linux Foundation / AAIF 治理） |
| 跨平台 | 否（OpenAI/Anthropic 格式不同） | 是 |
FC 为何不足：
- 每个平台的 schema 格式不同，同一工具要写多遍适配
- 没有"工具发现"机制（Agent 不知道有哪些工具可用）
- 没有"资源"概念（无法暴露只读数据源）
- 没有反向原语（Server 无法回过头请求宿主采样/追问用户）
- 工具生态被平台割裂
MCP 在 FC 之上加了：标准化 schema、工具发现、Resources/Prompts、Client 端原语（Sampling/Roots/Elicitation，见 1-概念 Q5）、跨平台兼容。
Q6：Skills vs Tools vs Plugins：知识包 vs 可执行能力 vs 打包分发；边界怎么划？#
参考答案
| Tool | Plugin | Skill | |
|---|---|---|---|
| 本质 | 一个动作 | 一组相关工具打包 | 完整任务方案 |
| 形态 | 函数 | 包/模块 | 文件包 |
| 内容 | 代码 | 代码 + 配置 | 知识 + 工具 + 流程模板 |
| 例子 | get_weather(city) | "Jira 工具包"（5 个 tool） | "代码 review"技能 |
边界判断口诀：
- Tool 是"一个动作"
- Plugin 是"一组相关动作打包"
- Skill 是"做某类任务的完整方案"（含知识/工具/流程）
举例：
read_file(path)— Tool- "文件操作包"（read/write/list/delete）— Plugin
- "代码 review"技能（含 review_checklist 知识 + 文件读写工具 + review 流程模板）— Skill
Q7：Agent Trace vs 普通日志：决策链 vs 系统事件；粒度过粗/过细各有什么问题？#
参考答案
| 普通日志 | Agent Trace | |
|---|---|---|
| 内容 | 系统事件 | 决策链（思考+行动+结果） |
| 粒度 | request 级 | step 级、call 级 |
| 用途 | 系统排查 | Agent 决策排查、转 eval case |
粒度过粗（只记"任务失败"）：
- 无法定位失败原因（哪一步错了？模型还是工具？）
- 无法转 eval case（不知道 input/output 对应关系）
- 无法做 trajectory eval
粒度过细（记每个 HTTP 包、每个函数调用）：
- token 爆炸、存储成本高
- 信噪比低，关键信息被淹没
- 隐私风险（可能记录敏感数据）
实战策略：按 Run → Step → LLM·Tool Call 三层结构，关键节点必记，细节按需采样。
Q8：Guardrail vs Permission：行为风险 vs 资源访问；为何只做一个都不够？#
参考答案
| Guardrail | Permission | |
|---|---|---|
| 防什么 | 行为风险（有害内容、违规主题） | 资源访问（越权、误操作） |
| 时机 | 输入/输出阶段 | 工具调用阶段 |
| 维度 | 内容合规 | 操作权限 |
| 例子 | 拦截 prompt injection | 阻止删除生产库 |
为何只做一个都不够：
- 只做 Guardrail：能拦有害内容，但拦不住"权限内的恶意操作"（用户有删文件权限，被注入后真删了）
- 只做 Permission：能拦越权操作，但拦不住"权限内的不当内容"（用户有发邮件权限，被注入发了有害邮件）
正确做法：两者结合——Guardrail 管"内容对不对"，Permission 管"操作能不能做"，外加审计兜底。
★ Q9：MCP vs A2A：agent↔工具 vs agent↔agent；为什么两者都需要？#
参考答案
| MCP | A2A | |
|---|---|---|
| 通信方 | agent ↔ 工具/上下文 | agent ↔ agent |
| 解决 | 工具调用标准化（垂直） | agent 协作标准化（水平） |
| 类比 | 人 ↔ 工具 | 人 ↔ 人 |
| 提出方 | Anthropic | Google（现由 Linux Foundation 治理） |
| 状态（2026-07） | 事实标准，属 AAIF | v1.0 stable、150+ 生产组织、签名 Agent Card + AP2 支付扩展，独立 LF 项目 |
两者同处 Linux Foundation 治理下（MCP 属其旗下 AAIF、A2A 为独立 LF 项目），构成"MCP 接工具（垂直）+ A2A 接 agent（水平）"两层栈，是企业 Agent 部署的默认架构。别再把 A2A 描述成"私有 / 待补齐"。
为什么都需要：
- 没有 MCP：工具生态被平台割裂，每个平台工具不能复用
- 没有 A2A：多 Agent 协作只能靠私有协议，Agent 间无法跨系统协作、无法标准化能力发现与支付授权
判断口诀：调用的是"工具"（无自主决策）用 MCP；调用的是"另一个 Agent"（有自主决策、自己的上下文）用 A2A。
举例：
- Agent 调
search_web()工具 — MCP - Agent 委托另一个 "code-reviewer" Agent 做 review — A2A
★ Q10：ReAct vs Plan-and-Execute vs Reflexion vs Tree-of-Thought：四种编排范式机制、适用、取舍？#
参考答案
这是资深必考的"编排范式谱系"。核心区别在于规划时机（边走边想 vs 先想好）与学习/搜索方式（是否跨尝试反思、是否单步内多路径搜索）。
| 范式 | 机制 | 适用 | 主要取舍 |
|---|---|---|---|
| ReAct | 交错 Reasoning + Acting：每步"思考→行动→观察"再决定下一步，无全局计划 | 动态、需实时反馈的工具型任务（问答+检索、客服） | 灵活、对意外自适应；但易跑偏/循环、步数不可预测、无全局视野 |
| Plan-and-Execute | 先一次性规划全部步骤，再逐步执行（可在偏离时重规划） | 步骤较确定、可预先分解的任务（报表流水线、批处理） | 有全局视野、规划只调一次 LLM 省钱；但对中途意外适应差、计划错则满盘错 |
| Reflexion | 执行后自我反思失败原因，把教训写入记忆，下次重试改进（verbal self-critique / 语言化强化学习） | 可多次尝试、有明确成败信号的任务（coding、可判定 QA） | 显著提升成功率；但多轮反思增加成本/延迟，依赖"反思信号"可靠 |
| Tree-of-Thought | 把推理展开成树：多分支探索 + 评估打分 + 回溯选优 | 需搜索/多路径的推理难题（规划、谜题、数学） | 质量高；但 token 爆炸、需评估函数、延迟高 |
一条取舍主线：反应式（ReAct，无计划）→ 有计划弱适应（Plan-and-Execute）→ 跨尝试学习（Reflexion）→ 单步内搜索（ToT）。越往后能力越强、也越贵。
追问·为什么不永远选最强的 ToT/Reflexion：因为成本/延迟随之爆炸——多分支或多轮重试会把单任务 token 翻几倍（呼应 3-原理 Q10 的 token 硬约束）。工程上按"任务是否可预先分解、是否有可判定成败信号、错误代价多大"来选，且常组合使用：外层 Plan-and-Execute 定骨架、子步用 ReAct 执行、失败用 Reflexion 重试。
追问·如何验证选型有效：同一批任务用不同范式跑，比较 pass@1、平均步数、平均成本/延迟、循环率；而不是只看"感觉更聪明"。