经过前几篇我们已经实现了一个完整的 Planning AgentUser Goal │ ▼ Planner │ ▼ Task Queue │ ▼ Tool Router │ ▼ Executor │ ▼ Monitor │ ▼ RePlan很多人做到这里会觉得Planning Agent 已经完成了。事实上这只是开始。真正进入生产环境后你会发现大多数问题都不是不会写代码而是Agent 为什么越来越笨 为什么一直规划 为什么任务越来越多 为什么 Token 暴涨 为什么最终答案反而更差这些问题本质上都来自Planning Runtime的设计。这一篇我们就专门讨论生产环境中最常见的 Planning Agent 问题以及对应的优化策略。为什么 Planning Agent 比 ReAct 更容易出问题ReActThink ↓ Tool ↓ Observe一次循环。PlanningGoal ↓ Plan ↓ Task1 ↓ Task2 ↓ Task3 ↓ RePlan ↓ Task4...整个生命周期长得多。所以状态更多 任务更多 Token更多 错误更多这也是为什么Planning Agent 的重点不是 Planner而是 Runtime。一、幻觉计划Hallucinated Plan这是最常见的问题。例如用户分析 LangGraph 最新能力Planner1. 阅读官方文档 2. 分析源码 3. 联系作者确认设计 4. 统计全球企业使用情况问题来了Planner 并不知道有没有源码 有没有联系方式 有没有这个 ToolLLM 只是觉得这样比较合理。这就是幻觉计划Hallucinated Plan为什么会产生Planner不知道Tool Capability也不知道Runtime Environment它只能猜。工程解决方案Planner 必须知道 Tool Catalog不要你自由规划。应该可用工具 Search Browser Python SQL 请基于这些工具规划。甚至Planner Prompt只能规划当前系统支持完成的任务。效果会明显提升。二、计划过长Over Planning很多人第一次做 Planner特别喜欢把所有事情一次规划完。例如50 个 Task然后Executor 一直跑看起来很专业。实际上生产环境非常差。为什么因为计划越长越容易错例如Task18 已经建立在 Task3 正确的前提上。但Task3早就失败了。后面的Task18 Task19 Task20全部失效。工程建议不要一次规划到底而是Rolling Planning例如先规划 3~5步 执行 再规划 继续执行这也是OpenAI Deep Research采用的方法。三、任务爆炸Task Explosion这是 Planning Agent 最大的问题之一。例如Planner分析 LangGraphRePlan增加 分析 LangSmith下一轮增加 分析 LangChain下一轮增加 分析 MCP最后100 Task越来越多。为什么因为Planner总觉得再查一点 会更好。LLM 天生倾向补充信息所以任务越来越长。解决方案必须限制最大 Task 数例如max_tasks20超过直接Summary 或者 Merge另一种方案Priority Queue低优先级直接丢弃。四、重复规划Duplicate Planning例如第一次搜索 LangGraph第二次再次搜索 LangGraph第三次搜索 LangGraph 最新版本其实几乎一样。原因Planner不知道哪些已经完成。工程方案PlannerPrompt必须加入Completed Tasks例如已经完成 1. 2. 3. 不要重新规划。更好的方式Planner直接读取Task State而不是Observation。五、上下文污染Context PollutionPlanning Agent生命周期很长。例如50 Task每个Observation1000 token最后50000 tokenPrompt越来越大。解决方案Observation Summary。例如Observation ↓ Compress ↓ Summary ↓ Archive不要一直append。六、RePlan 死循环经典Planner ↓ Executor ↓ 失败 ↓ RePlan ↓ 失败 ↓ RePlan永远结束不了。解决方案增加max_replan例如5次达到直接Fallback七、工具选择错误Planner搜索网页RouterCalculator结果失败。为什么RouterPrompt太简单。工程方案不要只写Search Calculator而要写适用场景 输入格式 输出格式 成本 是否联网 是否支持中文Tool Metadata越完整Router越稳定。八、工具失败立即 RePlan很多 Demo只要Tool Error马上RePlan。其实非常浪费。因为很多Timeout只是网络问题。正确顺序Retry ↓ Fallback Tool ↓ RePlan不要一失败就Planner九、Planner 与 Executor 职责混乱这是很多项目都会出现的问题。例如Planner直接调用 ToolExecutor又开始规划。最后两个 Agent都在Planning建议职责固定Planner ↓ 只负责 TaskExecutor只负责 Action不要互相越界。十、Token 成本失控Planning最大的成本不是LLM。而是Planner 重复运行。例如Task 5 个。 Planner 调用 10次。成本直接翻倍。解决方案Planner不要每一步都运行。而是事件驱动。例如只有失败 发现新信息 任务完成才重新规划。十一、缺少执行监控很多 Demo最后只有Answer没有Execution Trace实际上真正重要的是Task1 Success ↓ Task2 Retry ↓ Task2 Fallback ↓ Task3生产环境必须记录Task Timeline Tool Timeline Retry Timeline Latency Cost Token否则根本没法调试。十二、Planner Prompt 过于开放很多 Prompt请规划任务。Planner自由发挥。结果非常随机。更推荐请生成 3~5个 可执行 可验证 可以由现有 Tool 完成 不要重复 不要超过 5步。Planner稳定性提升很多。十三、为什么 LangGraph 更适合 Planning现在你应该理解Planning真正管理的是Task ↓ State ↓ Retry ↓ RePlan ↓ Monitor而不是PromptLangGraph提供的是State Machine Workflow Runtime所以Planning几乎天然适合LangGraph。生产级 Planning Agent Checklist建议在文章最后给一个可以收藏的 Checklist。检查项是否建议Planner 是否知道 Tool Catalog✅ 必须是否限制最大 Task 数✅ 必须是否限制 RePlan 次数✅ 必须是否支持 Retry✅ 必须是否有 Tool Metadata✅ 推荐是否有 Task Status✅ 必须是否记录 Execution Log✅ 必须是否压缩 Observation✅ 推荐是否支持 Fallback Tool✅ 推荐是否统计 Token 与 Cost✅ 推荐是否支持 Timeout✅ 推荐是否区分可重试/不可重试错误✅ 推荐本篇总结这一篇最大的认知升级应该是Planning Agent 的复杂度不在 Planner而在 Runtime。一个生产级 Planning Agent本质上不是一个会规划的大模型而是一个围绕Task、State、Tool、Retry、Monitor、RePlan构建的运行时系统Agent Runtime。至此你的 Planning 系列已经形成了一条完整的工程主线为什么需要 Planning │ ▼ Plan-and-Execute │ ▼ Dynamic RePlanning │ ▼ Tool Integration │ ▼ Retry Monitor │ ▼ Planning Runtime Optimization这条主线与后续的Supervisor、多 Agent、Deep Research Agent、企业级 Agent Runtime可以自然衔接不会出现知识断层。一个 Planning Agent 企业级框架https://github.com/flower-trees/regnexe-agent
