为什么需要独立的 Planner Agent
1️⃣ 考察意图
面试官想看你是否真正理解 Multi-Agent 系统中角色分离的工程必要性，而非仅仅背诵“规划能力独立”的套话。考察类型是系统设计 + 工程取舍，刁钻点在于：为什么不能用一个 Agent 既规划又执行？背后涉及上下文窗口竞争、推理模式冲突、错误隔离三个硬核原因。答好了能展示你对 Agent 架构的深度洞察——知道何时拆分、如何拆分，以及拆分带来的具体收益与代价。
2️⃣ 标准答
核心论点：Planner Agent 的独立性源于规划与执行在认知负载、资源消耗、错误模式上的根本冲突。下面从三个层面展开。
1. 上下文窗口竞争（Context Window Contention）
- 规划需要全局视野：Planner 必须加载整个任务描述、历史状态、约束条件（例如“写一篇 5000 字技术博客，分 5 个章节，每个章节引用 3 篇论文”），这通常占用 4K-8K tokens。
- 执行需要局部聚焦：Executor 在写第一章时，只需当前章节的上下文和工具调用结果（如搜索 API 返回的论文摘要），若强行塞入全局规划，会导致：
- 上下文窗口被规划细节稀释，执行时注意力分散，产生幻觉（如重复写已完成的步骤）。
- 工具调用时，历史规划 token 挤占工具返回的可用空间，导致关键信息被截断。
- 实际落地的坑：某项目用单一 Agent 做“多步骤数据分析”，Agent 在规划阶段生成 10 步计划，执行到第 3 步时，因上下文窗口被计划占满，工具返回的 CSV 数据被截断，导致后续计算全错。解法：Planner 只输出精简计划（步骤 ID + 目标 + 输入输出接口），Executor 按需从共享存储（如 Redis）拉取详细上下文。
2. 推理模式冲突（Reasoning Mode Conflict）
- Planner 需要发散-收敛模式：先发散生成多种路径（如“方案 A：用 BM25 检索；方案 B：用 DPR 检索”），再收敛到最优解。这依赖高温度采样（temperature=0.7-0.9）和长链推理（CoT）。
- Executor 需要精确-稳定模式：按计划执行时，必须低温度（temperature=0.1-0.3）保证输出确定性，避免随机偏差导致步骤失败。
- 为什么不能混用：若用同一模型实例，切换温度会破坏缓存（KV cache 需重建），且模型在两种模式间切换时，注意力分布会震荡（例如执行时突然“灵光一现”想改计划，导致死循环）。独立 Planner 可以单独使用高算力模型（如 GPT-4o）做规划，Executor 用低成本模型（如 GPT-4o-mini）做执行，实现成本与质量的 trade-off。
3. 错误隔离与可观测性（Error Isolation & Observability）
- 规划错误 vs 执行错误：若一个 Agent 既规划又执行，当任务失败时，你无法判断是“计划错了”（如步骤顺序颠倒）还是“执行错了”（如工具调用参数写错）。独立 Planner 让错误可追溯：
- Planner 输出计划后，可被人类或自动校验器（如基于 PDDL 的验证器）检查逻辑一致性。
- Executor 失败时，可回滚到 Planner 重新生成子计划（如“步骤 3 失败，重新规划步骤 3-5”），而非全盘重来。
- 实际落地的坑：某电商客服系统用单一 Agent 处理“退货+退款+换货”多步骤流程，Agent 在规划时漏了“检查退货资格”步骤，执行时直接调用退款 API，导致财务损失。解法：Planner 输出计划后，先经过规则引擎（如 Drools）校验步骤完整性，再交给 Executor 执行。
4. 扩展性与复用性（Scalability & Reusability）
- Planner 可复用：一个 Planner 可以管理多个 Executor 实例（如 10 个 Executor 并行处理不同子任务），实现任务级并行。
- Executor 可复用：同一个 Executor（如“调用 SQL 查询”的 Executor）可以被不同 Planner 的任务调用，无需重复训练。
- 工程取舍：独立 Planner 增加了系统延迟（规划阶段需 1-3 秒），但换来了整体吞吐量提升（并行执行可减少 50% 以上总耗时）。对于延迟敏感场景（如实时对话），可引入“缓存规划”或“预规划模板”来缓解。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，上下文窗口竞争——规划需要全局上下文，执行需要局部聚焦，混用会导致注意力稀释和工具调用截断；第二，推理模式冲突——规划需要高温度发散，执行需要低温度精确，独立后可以分别用不同模型实现成本优化；第三，错误隔离——独立 Planner 让失败可追溯，支持局部重规划而非全盘重来。总结一句：独立 Planner 不是架构冗余，而是解决认知负载冲突、提升系统鲁棒性的必要设计。”
4️⃣ 高频追问 & 应对
追问 1：那 Planner 和 Executor 之间如何通信？如果 Planner 生成的计划有错，Executor 怎么处理？
通信采用结构化协议：Planner 输出 JSON 格式计划，包含步骤 ID、依赖关系（DAG）、输入输出 schema。Executor 执行时，若某步骤失败（如工具返回错误码），会向 Planner 发送“步骤 N 失败，原因：XXX，建议：重试/跳过/替换”。Planner 根据失败类型决定：重试（最多 3 次）、跳过（若步骤非关键）、或重新规划后续步骤（如“步骤 3 失败，重新生成步骤 3-5”）。关键取舍：Planner 不实时监控执行，而是通过事件驱动异步通信，避免阻塞。
追问 2：如果任务很简单（比如“查天气”），还需要 Planner 吗？独立 Planner 会不会过度设计？
不需要。独立 Planner 的引入条件是：任务复杂度超过单一 Agent 的上下文窗口或推理能力。具体阈值：步骤数 > 3、依赖关系 > 2 层、或涉及外部工具调用 > 2 次。对于“查天气”这种单步任务，直接用 Executor 即可。工程上，可以设计一个路由层：先判断任务复杂度，简单任务直通 Executor，复杂任务才调用 Planner。这样既避免过度设计，又保留扩展性。
追问 3：Planner 本身也会出错，比如生成不可执行的计划，怎么保证 Planner 的可靠性？
三层保障：第一，输出校验：Planner 输出计划后，经过规则引擎（如检查步骤是否重复、依赖是否完整流程）和格式校验（JSON schema 验证）。第二，回退机制：若校验失败，Planner 自动重试（temperature 调高 0.1 以增加多样性），最多 3 次。第三，人类兜底：对于高风险任务（如金融交易），计划需经人工审批后才交给 Executor。实际项目中，Planner 的首次正确率通常在 70-80%，通过校验和重试可提升到 95% 以上。
5️⃣ 避坑 · 常见错误答法
- ❌ “因为规划能力很重要，所以需要独立 Agent。” → ✅ “因为规划与执行在上下文窗口、推理模式、错误隔离上存在根本冲突，独立 Agent 是解决这些冲突的工程方案，而非单纯的能力分层。”
- ❌ “独立 Planner 可以提升效率，因为规划更快。” → ✅ “独立 Planner 会引入额外延迟（1-3 秒），但通过并行执行和错误隔离，整体吞吐量提升 50% 以上。这是用单步延迟换系统鲁棒性的 trade-off。”
- ❌ “Planner 和 Executor 可以用同一个模型，只是 prompt 不同。” → ✅ “同一模型实例切换温度会破坏 KV cache，且模型在两种推理模式间切换时注意力分布震荡，导致输出不稳定。独立实例或不同模型才是正确做法。”
6️⃣ 简历呼应
- 如果你有 Multi-Agent 项目：从“实际项目中 Planner 与 Executor 的通信协议设计”切入，强调你如何用 JSON schema 和事件驱动机制解决计划错误回滚问题，并给出具体延迟和吞吐量数据。
- 如果你只做过传统 NLP：用“流水线架构”类比——Planner 相当于流水线的调度器，Executor 是具体工位，独立调度器才能避免资源竞争和错误传播。强调你理解角色分离的通用工程原则。
- 如果你是校招无项目：聚焦论文复现，如引用“Plan-and-Solve”或“ReAct”论文中规划与执行分离的设计，并说明你理解为什么 ReAct 在复杂任务上会失败（上下文窗口竞争），而独立 Planner 能解决。
- 《Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models》
- 《ReAct: Synergizing Reasoning and Acting in Language Models》
- 《AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation》
- 《CrewAI: Framework for Orchestrating Role-Playing AI Agents》
- 《PDDL (Planning Domain Definition Language) for Automated Planning》