Q35: Agent整体流程是怎么做的？包括哪些模块？**

P1 · agent_architecture

🏷 标签：agent-architecture, planning, execution, memory

1️⃣ 考察意图

面试官想考察你对 Agent 系统架构的全局掌控力，而非背诵 LangChain 文档。这是典型的系统设计 + 工程取舍题，刁钻点在于：多数人只会罗列“感知-规划-执行”流水账，但面试官真正想看的是模块间如何解耦、失败如何恢复、记忆如何分层。答好了能展示你从 Demo 到生产环境的架构思维，包括对 ReAct、Plan-and-Solve、Tool-Use 等范式的理解，以及处理幻觉、工具调用失败、长上下文管理等实际坑的落地经验。

2️⃣ 标准答

Agent 整体流程可抽象为 6 个核心模块 + 1 个控制循环，下面按执行顺序拆解，并给出每个模块的工程取舍。

2.1 感知模块（Perception）

职责：接收用户输入，做意图识别和实体抽取。典型做法是用 LLM 直接解析（如 system prompt: "提取用户意图和关键参数"），或前置一个轻量级分类器（如 BERT 微调）过滤高频意图。
取舍：LLM 解析灵活但延迟高（200-500ms），小模型快（<50ms）但泛化差。生产环境常用级联架构：小模型先做粗分类，LLM 做细粒度实体补全。
坑：用户输入可能包含多意图（如“查天气并订机票”），需用 parallel tool calls 或 sub-task decomposition 拆解，否则单次 LLM 调用会遗漏。

2.2 规划模块（Planning）

职责：将复杂任务分解为可执行的子任务序列。主流范式：ReAct：交替“思考-行动-观察”，每一步由 LLM 生成 Thought 和 Action，适合动态环境。
Plan-and-Solve：先一次性生成完整计划（如 Plan: 1. 查天气 2. 查航班 3. 生成行程），再逐步执行，适合确定性任务。
Tree-of-Thoughts：维护多个候选计划分支，通过 BFS/DFS 搜索最优路径，适合需要探索的场景（如代码调试）。取舍：ReAct 灵活但 token 消耗大（每步都需 LLM 调用），Plan-and-Solve 高效但无法应对中途变化。生产常用混合策略：先 Plan 生成骨架，执行中若失败则 fallback 到 ReAct 局部重规划。坑：LLM 生成的计划可能包含幻觉步骤（如“调用不存在的API”），需用工具注册表（Tool Registry）做合法性校验，只允许执行已注册的工具。

2.3 执行模块（Execution）

职责：调用具体工具/API 执行子任务。工具类型包括：代码解释器：如 Python REPL，用于计算、数据处理。
数据库查询：如 SQL 执行器，需做 SQL 注入防护。
外部 API：如天气、搜索、邮件，需处理认证和限流。取舍：工具调用结果可能非结构化（如 API 返回 HTML），需用输出解析器（Output Parser）提取关键字段，否则 LLM 后续推理会混淆。坑：工具执行可能超时或返回错误。生产环境需设置超时阈值（如 10s），超时后标记为失败，触发重试或回滚。

2.4 记忆模块（Memory）

职责：维护对话上下文和历史信息。分层设计：短期记忆：当前对话的完整消息列表（通常用滑动窗口，如最近 20 轮）。
长期记忆：向量数据库（如 Chroma、FAISS）存储历史关键信息，通过语义检索召回。
工作记忆：当前任务中产生的中间结果（如 SQL 查询结果），用 key-value store 暂存。取舍：短期记忆太长会超 LLM 上下文窗口（如 128K tokens），需用摘要压缩（如 LLM summarize 每 5 轮）或 RAG 检索替代。长期记忆的检索精度依赖 embedding 质量，常用 text-embedding-3-small 或 bge-large。坑：记忆污染——历史错误信息可能被后续步骤误用。解法：给每条记忆打置信度标签（如 source: tool_result vs source: llm_hallucination），检索时过滤低置信度条目。

2.5 反思模块（Reflection）

职责：对执行结果做校验，决定下一步动作。典型逻辑：成功：继续执行下一子任务。
失败：重试（最多 3 次）或重新规划（调用规划模块）。
部分成功：如 SQL 查询返回空结果，需判断是数据不存在还是查询错误，触发 LLM 修正 SQL。取舍：反思粒度需平衡。每步都反思（如 ReAct）增加延迟，只在关键节点反思（如工具调用后）更高效。生产常用事件驱动：工具返回错误码时触发反思，否则跳过。坑：LLM 自我反思可能陷入循环（如反复重试同一错误）。需设置最大重试次数和计划深度限制（如最多 10 步），超限后上报人工。

2.6 输出模块（Output）

职责：整合所有子任务结果，生成最终回复。需做：去重：多个工具返回相似信息（如天气和日历都包含日期）。
格式化：按用户偏好输出（Markdown、JSON、语音）。
安全过滤：屏蔽敏感信息（如密码、API key）。取舍：直接拼接工具输出可能冗长，需用 LLM 做摘要生成，但摘要可能丢失关键细节。生产常用模板化输出：对常见任务（如天气查询）预定义回复模板，LLM 只填充变量。

控制循环（Control Loop）

上述模块通过事件循环串联：用户输入 → 感知 → 规划 → 执行（循环）→ 反思（条件触发）→ 输出。每次循环由 Agent Runtime 调度，维护状态机（如 WAITING_INPUT, PLANNING, EXECUTING, REFLECTING）。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从流程、模块、工程取舍三个层面回答。流程上，Agent 遵循‘感知-规划-执行-反思-输出’的循环，由控制循环调度。模块上，核心是感知（意图识别）、规划（ReAct/Plan-and-Solve）、执行（工具调用）、记忆（短期+长期+工作记忆）、反思（失败重试/重规划）、输出（整合+安全过滤）。取舍上，关键在规划策略（ReAct 灵活但 token 贵，Plan-and-Solve 高效但僵化）和记忆管理（滑动窗口 vs 向量检索）。总结一句：生产级 Agent 不是流水线，而是带失败恢复和记忆分层的状态机。”

4️⃣ 高频追问 & 应对

追问 1：如果 Agent 在规划阶段生成了错误的计划（如步骤顺序颠倒），怎么处理？

分两层：1）执行前校验：用工具注册表做合法性检查，只允许调用已注册工具，非法步骤直接拒绝并触发重规划。2）执行中修正：使用 ReAct 的“观察-思考”循环，每步执行后让 LLM 判断结果是否符合预期，若偏差超过阈值（如 SQL 返回空结果），则局部重规划（只修正当前步骤及后续步骤，不重做整个计划）。实际落地中，我们设置最大重规划次数为 3，超限后上报人工。

追问 2：Agent 的长期记忆如何避免检索到无关信息导致幻觉？

核心是检索质量 + 过滤机制。1）检索质量：使用混合检索（BM25 + 稠密向量），BM25 保证关键词匹配，稠密向量保证语义相似，两者加权（如 0.3 BM25 + 0.7 DPR）。2）过滤机制：检索结果按相关性分数排序，只取 top-k（如 k=5），且设置最低分数阈值（如 0.6），低于阈值直接丢弃。3）后处理：让 LLM 在生成回复时，显式引用记忆来源（如“根据历史记录，你上次提到…”），若 LLM 无法找到对应来源，则输出“未找到相关信息”而非编造。

追问 3：如何评估 Agent 系统的性能？有哪些指标？

分三个维度：1）任务完成率：端到端成功率，需人工标注 ground truth（如“查询天气并安排行程”的预期输出）。2）效率指标：平均步骤数（理想值 3-5 步）、平均延迟（含 LLM 调用和工具执行，目标 <5s）、token 消耗（每任务 <10K tokens）。3）鲁棒性指标：失败恢复率（重试后成功比例）、幻觉率（LLM 编造工具结果的比例，通过人工抽检 100 条评估）。生产环境还需监控工具调用错误率和用户反馈满意度（如 thumbs up/down 比例）。

5️⃣ 避坑 · 常见错误答法

❌ 只罗列模块名称（“感知、规划、执行、记忆、反思、输出”），不解释交互逻辑 → ✅ 强调控制循环和状态机，说明模块间如何通过事件驱动（如“执行失败触发反思，反思决定重试还是重规划”）。
❌ 把 Agent 等同于 LLM 调用链（“就是调几次 LLM 然后拼结果”） → ✅ 区分 LLM 作为推理引擎和 Agent 作为系统架构，强调工具调用、记忆管理、失败恢复等非 LLM 组件。
❌ 忽略工程取舍，只说“用 RAG 做记忆” → ✅ 给出具体 trade-off（如“短期记忆用滑动窗口 vs 摘要压缩，前者简单但 token 浪费，后者省 token 但可能丢失细节”）。

6️⃣ 简历呼应

如果你有 RAG 项目：从“记忆模块”切入，对比 RAG 的检索-生成流程与 Agent 的记忆分层（短期 vs 长期），强调 Agent 需要更精细的置信度管理和失败恢复，而非简单拼接检索结果。
如果你只做过传统 NLP：用“规划模块”类比传统任务分解（如 NLU 的意图-槽位填充），说明 Agent 的规划是动态的（ReAct），而非静态的 pipeline，并强调工具注册表对执行安全的重要性。
如果你是校招无项目：聚焦“控制循环”设计，用状态机（如 WAITING_INPUT → PLANNING → EXECUTING → REFLECTING → OUTPUT）作为 Demo 核心，展示对系统架构的理解，而非依赖现成框架。

7️⃣ 延伸阅读

《ReAct: Synergizing Reasoning and Acting in Language Models》（Yao et al., 2022）
《Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models》（Wang et al., 2023）
《Tree of Thoughts: Deliberate Problem Solving with Large Language Models》（Yao et al., 2023）
LangGraph 官方文档：StateGraph 与 Agent 控制循环实现
《Toolformer: Language Models Can Teach Themselves to Use Tools》（Schick et al., 2023）

—— 本场面试完 ——