项目里的 Modular Agent ，你能讲讲它是如何实现多步规划的吗
P1 · rag
🏷 标签：agent, modular-agent, planning, react
1️⃣ 考察意图
面试官想考察你对模块化 Agent 架构中“规划”模块的工程实现细节，而非仅仅背诵 ReAct 流程。这是 P1 进阶题，刁钻点在于：区分“简单 ReAct 循环”与“真正的多步规划”——前者是 LLM 在每一步随机应变，后者是显式生成子目标、依赖图并支持回溯。答好了能展示你对规划器设计、状态管理、错误恢复的实战理解，以及能否在复杂任务中平衡灵活性与可控性。
2️⃣ 标准答
Modular Agent 的核心是将规划（Planning）、工具调用（Tool Use）、记忆（Memory）解耦为独立模块。多步规划不是让 LLM 在每一步自由发挥，而是通过一个显式的规划模块来生成、维护和执行子目标序列。
1. 规划模块的两种主流实现
- ReAct 模式：规划与执行交织。LLM 在每一步输出“Thought → Action → Observation”循环。优点是简单、无需额外模块；缺点是缺乏全局视角，容易陷入循环或遗忘长期目标。实际项目中，我通常用
max_steps=10和early_stop条件（如连续 3 步无进展）来兜底。 - Plan-and-Solve 模式：先由规划模块生成完整子目标列表（如
[“搜索公司财报”, “提取营收数据”, “计算增长率”]），再逐步执行。规划模块可以是独立 LLM 调用（如gpt-4-turbo带system prompt: “你是一个规划器，输出 JSON 格式的子目标列表”），或专用规划器（如基于 PDDL 的符号规划器）。工程取舍：Plan-and-Solve 更可控，但子目标可能因环境变化而过时；ReAct 更灵活，但容易跑偏。我通常采用混合策略：先 Plan 生成骨架，执行中允许 ReAct 动态调整。
2. 关键设计：子目标依赖与状态管理
多步规划需要维护一个依赖图（DAG）。例如，子目标 A 的输出是子目标 B 的输入。我使用一个 TaskGraph 数据结构（Python networkx 实现），每个节点是 (subgoal_id, status, result)，边是依赖关系。执行时，规划模块检查哪些子目标已满足（status=completed），哪些可并行执行（无依赖），哪些需要重试（status=failed）。
3. 错误恢复与循环检测
这是实际落地的最大坑。LLM 规划器常生成无效子目标（如调用不存在的工具）或陷入死循环。我的解法：
- 错误恢复：当子目标执行失败（如工具返回空结果），规划模块自动插入一个“修正子目标”（如
“尝试替代搜索词”），并标记原子目标为retry，最多重试 3 次。超过则回退到上一个依赖节点。 - 循环检测：维护一个
visited_states哈希集，记录每一步的(当前子目标, 上下文摘要)。如果新状态与历史状态相似度 > 0.9（用sentence-transformers计算），则触发break并输出“无法完成”。实际坑：相似度阈值太严会误杀，太松会漏判。我通过 A/B 测试调参，最终用cosine_similarity > 0.85配合max_loop_count=3。
4. 优化点：反思机制（Reflexion）
引入反思模块，在每一步执行后评估当前进度。例如，如果子目标“搜索营收数据”返回了 2022 年数据，但任务要求 2023 年，反思模块会生成反馈 “数据年份错误，需要重新搜索”，并让规划模块调整后续子目标。这比单纯重试更智能，但增加了 1 次 LLM 调用开销——trade-off：在任务成功率上提升约 15%，但延迟增加 20%。
5. 评估指标
- 任务完成率：最终目标是否达成（如 HotpotQA 答案准确率）。
- 平均规划步数：子目标数量，理想值 3-5 步。
- 错误恢复次数：重试和回退次数，越低越好。
- 循环率：触发循环检测的比例，目标 < 5%。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，规划模块的实现方式，我采用 Plan-and-Solve 与 ReAct 混合策略，先生成子目标骨架再动态调整；第二，关键设计包括依赖图管理、错误恢复和循环检测，比如用
TaskGraph维护子目标状态，用visited_states哈希集防死循环；第三，优化点如 Reflexion 反思机制，能提升成功率但增加延迟。总结一句：多步规划的核心是平衡全局可控性与局部灵活性，通过显式子目标、状态管理和错误兜底来实现。”
4️⃣ 高频追问 & 应对
追问 1：如果子目标依赖外部 API 返回结果，但 API 延迟很高，你怎么优化？
采用异步执行和缓存。对于无依赖的子目标，用
asyncio.gather并行调用 API。对于有依赖的，用functools.lru_cache缓存相同 API 请求（如相同搜索词）。另外，引入“预测性执行”：如果规划模块预测子目标 B 大概率需要子目标 A 的结果，可以提前发起 A 的请求。工程取舍：缓存可能返回过时数据，需要设置 TTL（如 5 分钟）；异步执行增加代码复杂度，但能减少 30-50% 的总延迟。
追问 2：你怎么保证规划模块生成的子目标不会遗漏关键步骤？
使用“验证器”模块。在规划模块生成子目标列表后，验证器（另一个 LLM 调用或规则引擎）检查子目标是否覆盖任务的所有必要条件。例如，对于“计算增长率”，验证器检查是否包含“搜索营收数据”和“搜索成本数据”两个子目标。如果遗漏，规划模块自动补全。实际坑：验证器可能过度纠正，导致子目标膨胀。我设置
max_subgoals=7作为硬限制，超出则触发规划模块重新生成更紧凑的列表。
追问 3：如果规划模块本身（LLM）输出格式错误，你怎么处理？
使用
pydantic定义输出 schema（如List[SubGoal]），并设置max_retries=3和fallback策略。如果 LLM 输出无法解析，第一次重试时在 prompt 中强调格式要求；第二次提供错误示例；第三次回退到 ReAct 模式（让 LLM 自由输出）。工程取舍：重试增加延迟，但能避免因格式错误导致整个任务失败。我通过监控发现，95% 的格式错误在第一次重试后解决。
5️⃣ 避坑 · 常见错误答法
- ❌ 说“多步规划就是让 LLM 一步步思考，用 ReAct 就行” → ✅ 正确切入：区分 ReAct 和显式规划，强调子目标生成、依赖管理和错误恢复，展示对架构设计的理解。
- ❌ 说“我用 LangChain 的 AgentExecutor 直接实现，不用自己写规划模块” → ✅ 正确切入：指出 LangChain 的 AgentExecutor 是 ReAct 实现，缺乏显式规划能力；展示如何自定义规划模块（如
PlanAndSolveAgent）或使用langgraph的StateGraph实现更精细的控制。 - ❌ 说“规划模块用 LLM 就行，不需要额外设计” → ✅ 正确切入：指出 LLM 规划器的局限性（如幻觉、循环），并给出工程解法（如验证器、循环检测、反思机制），体现实战经验。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“多跳问答”切入，说明如何用 Modular Agent 实现多步检索（如先搜索实体，再搜索关系），并展示错误恢复（如检索结果为空时自动调整查询词）。
- 如果你只做过传统 NLP：用“任务分解”类比，比如将“文本摘要”分解为“提取关键句→合并→去重”，说明规划模块就是显式定义这些子步骤，并处理依赖关系。
- 如果你是校招无项目：聚焦论文复现，比如复现 ReAct 或 Plan-and-Solve 论文，在 HotpotQA 上跑通 demo，并记录规划步数和错误率，展示对实现细节的理解。
- 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)
- Reflexion: Language Agents with Verbal Reinforcement Learning (Shinn et al., 2023)
- LangGraph: Building Stateful, Multi-Actor Applications with LLMs (LangChain 官方博客)
- TaskGraph: A Graph-Based Approach for Multi-Step Task Planning (通用知识，可参考相关论文)