1.1 问题背景与面试切入
面试官高频开场:"你做过 Agent 吗?Demo 和生产级 Agent 的核心差距是什么?"
答题框架(5 句话):
Demo 关心 happy path,生产关心异常路径
生产级 = P-P-A-O-R 完整循环 + 持久化状态 + 沙箱 + 审计
关键能力:可恢复、可降级、可审计、可治理
参考 Anthropic 2026 内部数据:Claude Code 多 Agent 架构比单 Agent 性能高 90%,但 token 多 15x
工业界主流:Plan-and-Execute + Reflexion + 状态机约束
1.2 2026 年 Agent 范式演进最新图景
| 范式 | 提出 | 核心思想 | 适用 | 局限 |
|---|---|---|---|---|
| ReAct | Yao 2022 | Thought-Action-Observation 交替 | 通用工具调用 | 易循环、无规划 |
| Plan-and-Execute | 2023 | Planner + Executor 分离 | 复杂多步 | 规划僵化 |
| Reflexion | Shinn 2023 | 失败后反思重试 | 迭代任务 | 反思可能也错 |
| ToT | 2023 | 树形探索 | 数学/博弈 | 成本高 |
| LATS | 2023 | ToT + MCTS | 复杂决策 | 计算成本极高 |
| Plan-and-Execute + Reflexion | 2024-2026 主流 | 动态规划 + 失败反思 + 工具重试 | 生产级通用 | 工程复杂 |
| Multi-Agent + Orchestrator | 2026 主流 | Lead Agent 调度 Sub-Agent | 复杂业务 | token 成本 15x |
| Agent + Skill (progressive disclosure) | Anthropic 2026 推广 | Agent 按需加载 Skill 工具 | 企业级 | Skill 治理 |
2026 年关键引用(Anthropic 2026-01 工程实践):
90% 任务在 L1 单 Agent 完成,但 10% 复杂任务需多 Agent
多 Agent token 多 15x,但任务完成率提升 90%
因此2026 工业界默认架构= L1 单 Agent + 显式升级到多 Agent
1.3 P-P-A-O-R 核心循环(面试必背)
Perception → Planning → Action → Observation → Reflection ↑ │ └──────────────────────────────────────────────────┘
工程约束(面试常追问):
最大循环次数:默认 25,硬上限(防止恶意 Prompt 致无限循环)
单步超时:单 LLM 调用 30s,单工具调用 60s
总预算:Token 预算 + 时间预算 + 步骤预算
循环检测:相同 State 出现 ≥3 次强制终止
Anthropic 2026-04 经验值:
Claude Code 平均任务 8-12 轮循环
90% 任务在 15 轮内完成
超 25 轮几乎都是 Prompt 漏洞
1.4 主流 Agent 框架对比(2026 年 7 月终极版)
| 框架 | 厂商 | 最新版 | 范式 | 流式 | 多 Agent | MCP | A2A | 适用 | 面试高频 |
|---|---|---|---|---|---|---|---|---|---|
| LangChain | LangChain | 0.3.x | ReAct | 弱 | 弱 | ✓ | ✗ | 通用 | 入门 |
| LangGraph | LangChain | 1.2.7(2026-06-30) | 状态图 | 强 | 强 | ✓ | 1.0+ | 复杂工作流 | ★★★★★ |
| LlamaIndex | LlamaIndex | 0.12.x | ReAct | 中 | 中 | ✓ | ✗ | RAG | ★★★ |
| AG2(AutoGen) | 社区(Microsoft 原) | 0.9.8 | 对话 | 中 | 强 | 社区 | 实验 | Multi-Agent | ★★★ |
| CrewAI | CrewAI | 1.15.1(2026-06-27) | 角色+Process | 中 | 强 | ✓ | ✓ | 团队协作 | ★★★★ |
| OpenAI Agents SDK (Python) | OpenAI | 0.17.7(2026-06-24) | Handoff | 强 | 强 | ✓ | ✗ | 通用+沙箱 | ★★★★★ |
| OpenAI Agents SDK (JS) | OpenAI | 0.11.4(2026-05-12) | Handoff | 强 | 强 | ✓ | ✗ | Node 生态 | ★★★★ |
| Anthropic Agent SDK | Anthropic | 1.x(内置 Claude) | 内置 Sub-agent | 强 | 强 | ✓ | ✗ | Coding | ★★★★ |
| Microsoft Agent Framework (MAF) | Microsoft | 1.0 GA(替代 SK) | 多 Agent 编排 | 强 | 强 | ✓ | ✓ | .NET/Azure | ★★★★ |
| Pydantic AI | Pydantic | 0.5.x | 类型驱动 | 强 | 中 | ✓ | ✗ | Python 生态 | ★★★ |
| Google ADK | 2.2.0 GA(2026-06-18) | A2A 优先 | 强 | 强 | ✓ | ✓ 原生 | Google Cloud | ★★★★ | |
| OpenAgents | 社区 | 0.6.x | 网络协议 | 强 | 强 | 原生 | 原生 | 互操作 | ★★ |
| Claude Code | Anthropic | v2.1.193(2026-06-26) | Dynamic Workflow | 强 | 强(嵌套5层) | ✓ | ✓ | 代码+编排 | ★★★★★ |
| MJ Nexus OS 自研 | MJ Nexus | v0.5.0 | P-P-A-O-R | 强 | 强 | 兼容 | 原生 | 桌面 | ★★★★★ |
关键框架生态变化:
Semantic Kernel → MAF:PyPI 已明确宣布 SK 被 Microsoft Agent Framework(MAF)1.0 取代,新项目应直接选 MAF
Google ADK 2.0 GA(6 月 18 日):从 1.33.0 跃升至 2.2.0,确立为 Google Cloud 生产级默认选择
OpenAI Agents SDK SandboxAgent:0.14.0 引入沙箱内执行文件操作和命令,0.17.x 加入 SandboxManifest 安全边界
Claude Code v2.1.193:Dynamic Workflows 可编排数百个子 Agent,/cd 切换工作目录,嵌套子 Agent 最多 5 层,fallbackModel 支持 3 个备选模型
1.5 面试高频追问与答题模板
Q1.1:ReAct、Plan-and-Execute、Reflexion 的区别?
ReAct:边想边做(适合探索型)
Plan-and-Execute:先想后做(适合确定性多步)
Reflexion:失败后反思(适合易错任务)
生产级:Plan-Execute 做骨架 + Reflexion 兜底 + ReAct 填细节
Q1.2:生产级 Agent 如何防止死循环?
硬上限(max_iterations、timeout)
循环检测(state hash 相同 N 次)
成本熔断(token 超阈值)
外部观察者(Trace 平台告警)
Q1.3:LLM Router 如何选模型?
任务分类 → 规则路由(简单/复杂/代码/视觉)
成本敏感度 → 便宜模型优先
性能关键 → 强模型兜底
实际做法:意图分类器 + 模型池 + 实时反馈
Q1.4:Agent 与 Copilot 的本质区别?
Copilot:辅助人类决策,AI 提议、人确认
Agent:自主执行,AI 决策+执行+反馈
工业界 2026 趋势:Copilot 2.0 = 弱 Agent(保留人类确认环节)
Q1.5(PM 题):你如何衡量 Agent 的"智能"?
任务成功率(Task Success Rate)
平均完成任务轮数(Avg Steps)
单任务成本(Cost per Task)
人类干预率(Human Intervention Rate)
用户满意度(CSAT / 点赞率)
工具调用准确率(Tool Call Accuracy)
---------------------------------------------------------------------------------------------------------------------------------
2. Agent 状态机与工作流引擎
2.1 三种执行模型(面试必问)
| 模型 | 灵活性 | 可控性 | 可恢复 | 可审计 | 适用 |
|---|---|---|---|---|---|
| 自由循环(Free Loop) | 极高 | 极低 | 难 | 难 | Demo |
| 状态机(FSM) | 中 | 高 | 易 | 易 | 客服、审批 |
| DAG 工作流 | 中 | 高 | 易 | 易 | 数据处理 |
| 状态机 + LLM 节点 | 高 | 高 | 易 | 易 | 生产级主流 |
2026 主流选择:状态机骨架 + LLM 节点决策转移,参考 LangGraph 范式。
2.2 任务定义(DAG / State Machine)
# LangGraph 示例(2026 主流范式) from langgraph.graph import StateGraph, END from typing import TypedDict, Annotated import operator class AgentState(TypedDict): messages: Annotated[list, operator.add] plan: list[str] current_step: int tool_results: dict retry_count: int # 节点:纯函数 def planner(state): ... def executor(state): ... def reflector(state): ... # 图 workflow = StateGraph(AgentState) workflow.add_node("plan", planner) workflow.add_node("execute", executor) workflow.add_node("reflect", reflector) workflow.add_conditional_edges( "execute", lambda s: "reflect" if needs_retry(s) else END, ) workflow.add_edge("plan", "execute") workflow.add_edge("reflect", "plan") ```text ### 2.3 持久化 Checkpoint(生产级必备) **Anthropic 2026 推荐**:所有 Agent 状态必须可 Checkpoint,支持 **time-travel debugging**。 ```python # LangGraph 内置 Checkpoint from langgraph.checkpoint.postgres import PostgresSaver checkpointer = PostgresSaver(conn_string="...") graph = workflow.compile(checkpointer=checkpointer) # 恢复 config = {"configurable": {"thread_id": "user_123_session_456"}} graph.invoke({"messages": [...]}, config=config)2.4 故障恢复机制
| 故障 | 恢复策略 |
|---|---|
| LLM API 抖动 | 重试 + 指数退避(3 次) |
| LLM API 不可用 | 切换备用模型 |
| 工具超时 | 重试 + 切换备用工具 |
| Checkpoint 写入失败 | WAL 日志 + 异步持久化 |
| Worker 崩溃 | K8s 自动拉起 + 从 Checkpoint 恢复 |
| 用户主动中断 | cancel() 协作中断 + 保存进度 |
2.5 确定性 Replay(高级题)
Q2.1:Agent 调试为什么难?怎么解决?
答:非确定性 + 多步依赖 + 工具副作用
解决:固定随机种子 + Mock 工具 + Trace 完整记录 + Replay 模式
Q2.2:什么是 HITL?怎么实现?
Human-in-the-Loop:关键决策点插入人工确认
实现:状态机设置"等待人类"节点,UI 推送 + Webhook 回写
适用:删除、转账、发送邮件等高风险操作
3. 长对话上下文管理与压缩
3.1 "三层危机"(面试必背)
| 危机 | 现象 | 数据 |
|---|---|---|
| Cost Crisis | 长对话 Token 成本飙升 | 200K token 上下文成本 $1/次 |
| Latency Crisis | 上下文越长,推理越慢 | 4K → 200K,延迟 1s → 5-10s |
| Lost-in-Middle Crisis | 中间信息被忽略 | 32K 时,70% 中间信息被丢失 |
引用:Liu et al. 2023 "Lost in the Middle"
3.2 主流压缩策略对比
| 策略 | 压缩率 | 信息保留 | 适用 |
|---|---|---|---|
| 滑动窗口 | 1:1 | 保留最近 N 轮 | 通用 |
| 摘要压缩 | 10:1 | 语义保留 | 长对话 |
| 抽取式压缩 | 5:1 | 关键事实 | 结构化对话 |
| 分段压缩 | 8:1 | 主题分段 | 多主题对话 |
| 分层上下文 | 15:1 | 系统+用户+任务+历史 | 生产级主流 |
3.3 分层上下文(2026 主流)
┌──────────────────────┐ │ Layer 1: System │ 角色定义、规则、输出格式(不变) ├──────────────────────┤ │ Layer 2: User Profile│ 用户偏好、历史画像(慢变) ├──────────────────────┤ │ Layer 3: Task State │ 当前任务进度、变量(快变) ├──────────────────────┤ │ Layer 4: Recent Dialog│ 最近 N 轮对话(滑动窗口) ├──────────────────────┤ │ Layer 5: Memory │ 检索召回的相关记忆(按需) └──────────────────────┘
Anthropic 缓存优化:将不常变化的 Layer 1-2 启用 Prompt Caching,可节省 90% 成本。
3.4 长程依赖保持
关键事实外提:将"用户是产品经理"等关键事实存入 Layer 2
实体引用表:维护 (实体, 最新值) 表,Prompt 中只插引用
Context Summary:每 N 轮生成"对话摘要"放在 Layer 4 头部
4. Agent 流式响应与中断控制
4.1 流式协议对比
| 协议 | 方向 | 优势 | 劣势 | 适用 |
|---|---|---|---|---|
| SSE | 服务器→客户端 | 简单、HTTP 友好 | 单向 | Chat UI |
| WebSocket | 双向 | 全双工 | 协议重 | 协作场景 |
| gRPC Stream | 双向 | 高性能 | 复杂 | 内部服务 |
| HTTP/2 Stream | 双向 | 现代 | 浏览器支持 | 混合 |
2026 主流:SSE(前端)+ gRPC(后端内部)。
4.2 流式数据结构(Anthropic 规范)
// event stream data: {"type":"message_start","message":{...}} data: {"type":"content_block_start","index":0,"content_block":{"type":"text","text":""}} data: {"type":"content_block_delta","index":0,"delta":{"type":"text_delta","text":"Hello"}} data: {"type":"content_block_delta","index":0,"delta":{"type":"text_delta","text":" world"}} data: {"type":"content_block_stop","index":0} data: {"type":"message_delta","delta":{"stop_reason":"end_turn"}} data: {"type":"message_stop"} data: [DONE] ```text ### 4.3 中断机制 | 中断类型 | 实现 | 协议 | |---|---|---| | **用户主动中断** | 前端发送 cancel_event | WebSocket 控制帧 | | **系统超时** | 服务端 timeout | gRPC deadline | | **优雅中断** | 协作式:检查 ctx.is_cancelled() | 应用层 | | **强制中断** | 断开连接 | 传输层 | | **Kill Switch** | 全局标志位 | 共享状态 | ### 4.4 用户打断(Barge-in) **语音 Agent 关键能力**: - 用户在 Agent 说话时打断 - Agent 立即停止 TTS + 保留已生成内容 - 切换到 ASR 接收新输入 **实现**:VAD(语音活动检测)+ 流式 ASR + cancel token。 ### 4.5 面试高频追问 **Q4.1:为什么用 SSE 不用 WebSocket?** - SSE:HTTP 友好、自动重连、简单 - WebSocket:双向但复杂、需要独立服务 - 大多数 Chat 场景单向够用,SSE 是首选 **Q4.2:流式中如何实现"边生成边工具调用"?** - Anthropic API:`tool_use` 块在 `content_block` 中 - 前端收到 `tool_use` 时暂停渲染 → 调用工具 → 注入结果 - OpenAI 同理(tool_calls 字段) **Q4.3:流式中断后如何保证前端不丢消息?** - 每个 delta 携带 sequence_id - 客户端记录已接收的最大 sequence - 中断后重连,从 sequence+1 续传 - Anthropic prompt caching 可减少重连成本