【Agent】 别再让你的 Agent 靠直觉写代码了：四种 Planning 架构的工程选型与落地陷阱

别再让你的 Agent 靠直觉写代码了四种 Planning 架构的工程选型与落地陷阱声明本文中提到的「CloudMart」为虚构电商教学系统仅用于串联知识点。目录一、戳破 ReAct 的完美幻觉你造的究竟是 Agent还是 Token 永动机二、思考范式的演进从「即兴表演」到「运筹帷幄」三、规划架构落地Planner 与 Executor 的「军政分离」四、防线与红线如何避免你的 Planner 跑飞五、总结一、戳破 ReAct 的完美幻觉你造的究竟是 Agent还是 Token 永动机这几天我翻了挺多 AI Agent 相关的教程。开源框架的上手文档看了各路博主的技术拆解也看了一圈——然后发现一个很有意思的现象大家像商量好了一样都在讲同一个万能公式。Agent LLM PromptReAct Tools。按照这个叙事Agent 应该是这样的遇到问题就自动推理Reasoning发现缺数据就自己去调工具Acting一个完美的 ReAct 闭环跑起来行云流水。但这里有一个残酷的事实一旦你离开「天气查询」和「算术口算」这种玩具 Demo让 Agent 去处理哪怕只是稍微复杂一点的工程任务——它大概率会翻车而且翻得很彻底。来看 CloudMart 这个场景。你给 Agent 下了一个任务「去 CloudMart 后端仓库里把order_service.py里那段十几层 if-else 的订单状态机逻辑重构掉然后跑通单元测试。」满载 ReAct 框架的 Agent 跑起来往往是下面这副名场面[Thought]: 我需要查看 order_service.py 的结构和报错信息。 [Action]: read_file(order_service.py) [Observation]: (返回了 500 行代码混杂着复杂的依赖引用和类型注解) [Thought]: 看来核心问题是 line 42 到 line 187 的状态机需要拆分。我用 replace 替换它。 [Action]: replace_code(order_service.py, line42, text...(新代码)...) [Observation]: (报错SyntaxError: invalid syntax还引用了未导入的模块) [Thought]: 坏了我漏掉了依赖注入。让我重新读一下文件。 [Action]: read_file(order_service.py) ... (以上过程重复 15 次直到触发 context window 上限或 API 限流)这就是无数开发者午夜梦回时的噩梦Agent 陷入了死循环。走一步看一步的 ReAct本质上是在用高昂的 Token 成本来掩盖架构上全局规划能力的缺失。大模型在单步推理时就像一个手里只有手电筒的盲人——只能看清眼前这一个工具的输入与输出。当工具返回了一个符合预期的结果时它表现得像个天才可一旦工具返回了 unexpected 的底层报错LLM 就会瞬间被眼前的局部错误带偏顺着错误的逻辑一路狂奔在两三个工具之间反复横跳直到把你的 Token 烧光。复杂的工程任务需要的是导演而不是只会即兴表演的戏子。ReAct 这种把「规划」和「执行」高度绑定在每一个 Step 里的做法最大的问题就在于它太缺乏大局观了。因为大模型在吞下前一步工具返回的巨量 Observation往往是冗余的 JSON 或堆栈日志后它的注意力已经被严重污染。在下一轮 Thought 中它几乎丧失了对最初目标的掌控力。核心洞察ReAct 的每一步推理都在被上一步的工具返回「重新塑造」。工具返回越嘈杂Agent 偏离原始目标越远。这不是推理能力的问题——这是架构层面的信息污染。要解决这个问题我们就必须把 Agent 的「大脑」解耦为它注入真正的「思考骨架」——也就是从 ReAct 走向更高级的 Planning 架构。二、思考范式的演进从「即兴表演」到「运筹帷幄」为了打破 ReAct 的局部最优解陷阱业界在工程实践中演进出了另外三种主流的规划架构。它们的核心逻辑、优缺点以及适用场景我用一张表来对比规划模式核心逻辑优点缺点适用场景ReAct想一步做一步极度灵活能应对高度动态的环境Token 消耗极大极易迷路和死循环简单的探索性任务、短平快的工具调用ReWOO预先规划工具流水线斩断中间观察零等待省 Token执行效率极高无法处理工具之间的条件分支If-Else工具依赖明确、需要并行处理的批处理场景Plan-and-Execute先画全局地图再出发途中动态重规划兼顾大局观与灵活性抗挫折能力强架构复杂重规划时对大模型要求高复杂的长文本处理、多步骤软件自动化Self-Discover让 LLM 先从原子模块池里自选推理结构逻辑极其严密深度定制思考路径首字延迟TTFT高不适合简单任务复杂的数学证明、代码重构、科学推演下面逐一拆解每种架构的核心机制。2.1 效率至上主义ReWOO 架构如果一个任务需要调用 5 次 API传统的 ReAct 需要等 LLM 思考 5 次、吐 5 次 Token大把的时间全死在了网络 IO 和首字延迟上。ReWOOReasoning Without Observation提出了一个极其优雅的解法斩断中间观察。它让大模型在出发前直接交出一份完整的「工具流水线依赖表」。回到 CloudMart 的场景Planner 会一次性输出计划 Step 1: 调用 read_file(order_service.py)获取完整代码 Step 2: 将 Step 1 的输出传给 analyze_code()识别需重构的状态机段落 Step 3: 将 Step 2 的分析结果传给 run_tests(tests/order/)获取当前测试覆盖率 Step 4: 基于 Step 1-3 的全部结果生成重构方案然后 Worker 节点批量并行执行这些工具调用——Step 1 到 Step 3 如果彼此不依赖外部结果可以同时发射。等全部工具返回后Solver 一次性汇总所有结果输出最终的解决方案。把思考和执行解耦最好的规划不是在终点前不断修正而是在出发前就把所有的炮火编排好批量发射。ReWOO 的核心魅力在于它用一轮推理换取了工业级的零等待执行效率。但 ReWOO 有它的硬伤它假设工具之间的依赖关系是静态的、可预知的。如果 Step 2 的结果告诉你「这个文件根本不存在你应该去读order_service_v2.py」ReWOO 没有办法在流水线中途拐弯——它的工具依赖表在出发前就锁死了。2.2 稳健派Plan-and-Execute当面对极度复杂的任务时我们需要的是 Plan-and-Execute——先规划再执行。它拥有一个独立的 Planner先将大目标拆解为 Plan A包含 Step 1, 2, 3…。Executor 独立去跑这些步骤。关键的是第三步如果中途 Step 2 报错了信息会回传给 Planner 触发Replan重规划重新修正后面的路线。回到 CloudMartPlanner 先规划「读取代码 → 分析状态机 → 重构 → 运行测试 → 验证覆盖率」。Executor 跑到第三步时发现重构引入了循环依赖。这个信息回传给 PlannerPlanner 重规划先拆解循环依赖再继续重构。Plan-and-Execute 相比 ReWOO 多了一个「重规划」环节这带来了极强的容错能力但也引入了新的风险——如果 Planner 反复在同一节点失败它可能陷入和 ReAct 一样的问题只不过这次烧的不是单步 Token而是一整轮规划 执行的 Token。2.3 深度推理派Self-DiscoverSelf-Discover 走的是另一条路。它不让开发者预设推理结构而是让 LLM自己从原子模块池里挑选最适合当前任务的思维框架。原子模块池里放的是一些通用的推理模式比如批判性思维这个假设站得住脚吗有没有反例首要原则拆解这个问题的最底层约束是什么逆向推导从期望的最终状态反推需要的前置条件类比推理这个问题和哪个已知问题结构相似面对 CloudMart 的订单状态机重构任务Self-Discover 可能自己选出一套组合「首要原则拆解 → 批判性思维 → 逐步细化」——先用首要原则搞清楚状态机的核心约束订单状态流转的不可逆规则再用批判性思维检查现有实现是否违反了这些约束最后逐步细化出重构方案。Self-Discover 的优势在于它不假设任何通用的推理结构适用于所有任务——它让 Agent 自己诊断问题的类型然后为自己量身定做一条推理路径。代价是首字延迟TTFT更高因为 LLM 需要先「思考如何思考」再开始真正的推理。2.4 四种架构的决策指南这么多架构实际工程中怎么选我用一个 2×2 矩阵来帮你快速定位任务简单 工具依赖明确直接 ReWOO别浪费 Token 在即兴表演上任务简单 工具依赖不明确ReAct 够用探索成本可控任务复杂 工具依赖明确Plan-and-Execute先画地图再出发任务复杂 工具依赖不明确Self-Discover让 Agent 自己选择合适的推理路径三、规划架构落地Planner 与 Executor 的「军政分离」在将这些 Planning 架构落地到代码层面时大部分开发者会犯同一个错误用同一个大模型上下文Context Window既当大脑又当四肢。当你把规划逻辑、工具描述、工具返回的几百行原始 JSON 混在同一个聊天历史里时大模型很快就会不堪重负。不要让干脏活的工具返回值污染了将军的战略沙盘。在工程实现上优秀的 Planning 架构必须做到「军政分离」这套架构的核心要义只有一句话Planner 永远只能看到被清洗过的、高度抽象的状态摘要而不是原始的报错日志。回到 CloudMart 的场景当 Executor 执行run_tests(tests/order/)后发现 12 个测试挂了 11 个它不会把 500 行 pytest 堆栈直接甩回给 Planner。它会先做摘要[Executor → Planner 摘要] 任务运行 tests/order/ 单元测试 结果12 个测试1 通过11 失败 关键失败集群 - test_state_transition (3个)状态机循环依赖导致 ImportError - test_payment_integration (5个)Mock 对象接口不匹配 - test_edge_cases (3个)边界值处理逻辑缺失 建议优先修复状态机循环依赖阻塞后续所有测试再处理 Mock 接口Planner 拿到这份摘要后清楚地知道「先修循环依赖再修 Mock」而不是在 500 行堆栈里迷失方向。四、防线与红线如何避免你的 Planner 跑飞无论你选择了哪种规划架构只要引入了动态重规划机制你就必须在代码层面上建立硬性的安全边界。永远不要相信 Agent 能自己停下来。一个没有硬编码max_replan_steps的 Agent不是人工智能而是一个随时准备刷爆你信用卡的 Token 永动机。以下三条红线每一条都来自真实的工程血泪教训4.1 强行硬编码截断在你的控制循环里必须写死截断逻辑。不要指望在 Prompt 里写「如果你找不到答案就请停止」能百分之百生效——LLM 在陷入局部循环时这个提示词大概率会被它自己忽略。classPlanningAgent:MAX_STEPS12# 硬上限全局总步数MAX_REPLAN_ROUNDS3# 硬上限同一节点的重规划次数defrun(self,goal):step_count0replan_count0whilestep_countself.MAX_STEPS:ifreplan_countself.MAX_REPLAN_ROUNDS:returnself.escalate_to_human(goal)# ... 正常执行逻辑 ...step_count1returnself.timeout_handler(goal)MAX_STEPS和MAX_REPLAN_ROUNDS必须是硬编码的常量不能从配置文件动态读取更不能让 LLM 自己决定何时停止。这不是不信任模型——这是防御性工程的基本素养。4.2 状态隔离与回滚当 Planner 连续 3 次 Replan 都指向同一个失败节点时必须触发早停机制或者引入人工介入。defreplan(self,failure_node):self.failure_count[failure_node]1ifself.failure_count[failure_node]3:# 早停这个节点在现有能力下无法解决returnHumanInterventionRequest(nodefailure_node,attemptsself.failure_count[failure_node],suggestion建议人工介入或重新定义目标)# 正常重规划绕开失败节点returnself.generate_alternative_plan(exclude[failure_node])这条红线的底层逻辑是如果一个节点连续 3 次失败问题大概率不在执行层面而在规划层面——要么目标本身在当前工具集下达不到要么缺少关键信息。4.3 剪枝与摘要前面讲「军政分离」时已经提到了信息清洗的重要性。这里补充一个具体的工程建议Executor 执行完工具后使用一个极其轻量、便宜的模型截至 2026 年 6 月如 GPT-4o-mini 或 Claude 3.5 Haiku对结果进行缩减摘要只把关键结论喂回给 Planner。原始工具返回500 行堆栈日志 │ ▼ [轻量摘要模型] │ ▼ 结构化的 3 行摘要 - 成功/失败状态 - 关键数据数字、路径、错误类型 - 对下一步的建议这样做有两个好处一是保护核心模型截至 2026 年 6 月如 GPT-4o / Claude Opus的注意力不被垃圾信息污染二是大幅降低 Token 成本——500 行堆栈日志压缩成 3 行摘要单轮消耗从几千 Token 降到几十 Token。五、总结从 ReAct 的「即兴表演」走向 Planning 的「运筹帷幄」是 Agent 从玩具走向工业级应用的必经之路。在设计你下一款 Agent 时不妨先慢下来问自己三个问题我的任务真的需要它每一步都即兴发挥吗工具之间的依赖关系是静态可预知的还是动态变化的我有没有在代码里为它写好硬性的安全红线规划架构的选择没有银弹但有清晰的决策逻辑。关键是别让你的 Agent 在黑暗中摸索——给它一张地图一盏灯和一条随时可以踩刹车的红线。感谢看到这里评论关注比点赞更有价值。