《AI Agent 核心机制》第三篇：Agent 怎么“想清楚该干嘛”：规划与 ReAct 循环

引子第三轮聊怎么想前两轮拷问记忆、工具之后对方又约了第三次。这回连寒暄都省了落座直接开问“上次你说循环跑起来才叫 Agent。那我问你你们的 Agent 接到’把上季度销售数据整理成一份报告’这种活它是怎么知道第一步该干什么的”我心想这题有准备“让模型先把任务拆解成子任务列表生成一个计划然后按计划一步步执行。”对方点点头“听起来很对。那我换个问法——你的计划是刻在石碑上的还是写在沙滩上的”我愣了一下没接住。然后熟悉的连环追问第三次开始了“为什么’先把计划想全再动手’在真实任务里反而容易翻车”“ReAct 这个词你们天天挂嘴边它到底解决了什么”“一个模糊的大目标怎么变成第一步能动手的具体动作”“执行到第三步查出来的结果把第一步的假设推翻了怎么办”“你的 Agent 怎么知道自己做完了它说做完就做完了”“Agent 卡在循环里空转你怎么发现、怎么兜底”“上了线这套循环踩过什么坑”还是七问还是从会说术语一路钻到真会实现。而石碑还是沙滩这个问题恰好就是整套规划机制的题眼——这篇文章照旧把七问补完作为全文的路线图。第一章先拆那个直觉——想清楚再动手为什么会翻车面试官为什么先把计划想全再动手在真实任务里反而容易翻车谋定而后动是刻在工程师骨子里的教养计划做得越细执行越稳。把这个直觉搬到 Agent 上就是Plan-then-Execute先规划后执行模式先让模型一次性生成完整计划——第 1 步干什么、第 2 步干什么、一直排到第 N 步——然后进入执行阶段逐条照做执行时不再动脑。早期的 Agent 框架大多是这个思路它也确实有真实的好处计划可预审、行为可预测、执行阶段便宜。但它有一个致命的结构性弱点计划的质量取决于规划那一刻的信息完备度而 Agent 任务的关键信息恰恰要到执行中才会逐步揭示。还是那个销售报告的例子。模型信心满满地生成计划第 1 步读取数据库 sales 表第 2 步按区域汇总……执行第 1 步才发现这家公司的表叫orderssales表是三年没人维护的废表。第 1 步的假设一塌后面九步全是沙上楼阁——而一个不再动脑的执行器会面无表情地把错误的计划执行到底。静态计划有三宗罪信息不完备没打开抽屉之前你不知道抽屉里有什么。计划做得越细押上的未验证假设越多——细节不是稳健是赌注。环境会变文件被人挪了位置、接口临时超时、文档和数据对不上——真实世界不是棋盘规则不会等你落完子再变。误差会复利第一步的小偏差没有修正机制就一路放大。上一篇说过金额单位是分不是元能一路错到底静态计划就是这种错误最好的温床。艾森豪威尔有句名言“计划本身一文不值但规划这件事就是一切。”Plans are worthless, but planning is everything.翻译成工程语言计划名词随时会作废规划动词必须持续发生。Agent 设计的分水岭正在这里——把规划当成任务开始前的一次性编译期动作还是贯穿全程的运行时动作。不过话不能说死Plan-then-Execute 并没有被扫进垃圾堆。步骤确定、环境稳定、执行中不会冒出新信息的任务——批量格式转换、固定流程的数据搬运——静态计划又便宜又稳上一篇讲的编程式工具调用本质上就是这个逻辑的极端形态整段脚本一口气跑完中间根本不回头。翻车的从来不是模式本身而是把静态计划用在了探索性任务上。 开发者视角判断任务该用哪种模式有一条实用的分界线——执行过程中会不会产生改变后续做法的新信息会就需要动态规划不会静态流水线更便宜。很多团队的问题是用同一个万能 Agent 循环包打天下简单任务白白付循环的钱复杂任务又指望一段写死的提示词能预见所有意外。先分类再选模式比调提示词有用得多。第二章ReAct——想一步、做一步、看一步面试官ReAct 这个词你们天天挂嘴边它到底解决了什么ReAct 是 Reason Act 的缩写出自 2022 年普林斯顿和 Google 的论文《ReAct: Synergizing Reasoning and Acting in Language Models》。它今天已经不是一个可选技巧而是 Agent 循环的默认运行形态——但正因为人人都在说它到底修正了什么反而很少有人讲清。机制本身极简单就是让模型交替产出三样东西循环往复Thought想基于目前已知的一切推理下一步该干什么、为什么Action做执行一个具体动作——通常就是上一篇讲的一次工具调用Observation看拿到动作的真实结果更新自己对局面的认知进入下一轮。它的价值要放在两种失败模式中间才看得清只想不做纯推理如链式思考整条推理链闭门造车每个中间结论都来自模型的参数记忆无法核实——一步幻觉步步幻觉还说得头头是道。只做不想盲目执行埋头连续动作不从结果里提炼任何东西同一个坑能踩五遍。而 ReAct 让两者互相纠偏推理为行动导航行动的观察结果为推理供弹——想让做不盲目看让想不悬空。图 1左边一次性把计划排满现实一偏离就全盘作废右边每走一步都用真实观察校准下一步——差别不在想得多细而在想的时机。把它和上一篇的图 1 接起来看Function Calling 闭环里⑤→②那条回边每转一圈恰好就是一次 Thought第⑤步消化结果、决定下一步→ Action第②步输出调用意图→ Observation第④步工具结果回填。所以准确地说ReAct 不是一个需要额外引入的框架而是 Agent 循环天然的样子。论文的原始形态是提示词工程——用few-shot 示范教模型输出 “Thought: … / Action: … / Observation: …” 的文本格式今天你不需要照抄那套格式了原生的工具调用加上模型的思考能力现代推理模型里Thought 往往藏在 thinking 块里未必显式打印出来已经把这个循环内化了。要学的是思想不是抄它的提示词。那 ReAct 是不是就够了不是。纯 ReAct 有个天生短板每一步都只看眼前缺一张全局地图。两种典型病症走着走着忘了最初的目标目标漂移每一步局部都合理连起来却绕了一个大圈局部贪心。要治这个病就得把全局用某种方式钉住——这正是下一章的主题显式计划。 开发者视角调试 Agent先看轨迹里 Thought 的质量。常见坏味道是 Thought 沦为空洞的动作复述——“我现在要调用搜索工具”——而不是真正的决策推理——“上一步返回为空说明表名假设错了先列出所有表确认结构”。前者等于没想。Thought 普遍空洞时病根往往不在模型而在上下文里缺少可供推理的素材工具结果被过度截断、错误信息太含糊上一篇错误信息是写给模型看的 UX那条在这里结账。第三章任务分解——把整理个报告变成第一步能动手的事面试官一个模糊的大目标怎么变成第一步能动手的具体动作从帮我整理个销售报告到第一步列出数据库里所有表确认数据源中间其实要过两道工序先把目标弄清楚再把目标拆开。第一道工序目标澄清。整理个报告缺的东西太多了——给谁看管理层要一页结论分析师要完整明细。什么口径自然季度还是财年季度。什么格式截止什么时候在模糊目标上直接开跑是 Agent 世界里性价比最低的勤奋——方向错了执行越卖力浪费越彻底。所以成熟的做法是关键歧义主动问用户能从上下文合理推断的自己定但把假设显式写进计划“假设按自然季度输出 Markdown”让错误的假设有机会被尽早看见、尽早推翻而不是藏在执行细节里到最后才炸。第二道工序分解并且把计划写下来。注意关键词是写下来——这里有一个容易被忽视的分野隐式规划计划只存在于模型的脑中每一轮临时想下一步。短任务没问题长任务必漂。显式规划计划作为一个真实的文本产物被输出——一份 todo 清单、一个计划文件——每轮循环都能重读、勾选进度、修订内容。显式计划的价值是三重的分别服务三个受众对模型把计划在每轮循环里读回上下文等于把北极星反复钉在注意力的最近处。系列第一篇讲过中间信息丢失——几十轮之后最初的目标早沉到上下文深处的注意力盲区了把计划不断复述到上下文末尾是对抗目标漂移最便宜的手法。Agent 产品 Manus 分享过他们把这招用成招牌的做法维护一个 todo.md每完成一步就重写一遍全文件——看似笨拙的重复实际是在持续刷新模型对全局的注意力。对代码显式计划是结构化的状态。总步数、当前进度、卡在哪一步全都可以被外层代码监控——第六章的空转检测原料就从这里来。对人计划可审计、可干预。执行前先让人扫一眼计划高风险任务在计划确认处设一个审批点比事后追责便宜一万倍护栏设计是 04 篇的主菜。图 2目标先补齐验收标准和显式假设再拆成一句话说得清的子任务——计划锚定要什么把怎么拿留给执行。分解粒度有一条实用标准每个子任务要一句话说得清、做完能验证。太粗“分析数据”等于没拆执行时还是无从下手太细把每一次工具调用都排进计划则失去弹性——记住计划锚定的是要什么怎么拿的自由度要留给执行循环。结构上线性清单足够覆盖九成场景只有子任务间依赖真的复杂到需要并行调度时才值得上任务图DAG——先搭一个任务图引擎再开始写 Agent是这个领域最常见的过度设计。 开发者视角计划放在哪短任务放在对话消息里就行。长任务把计划外置成文件——这是系列第一篇记忆外置思想的直接翻版而且有一个专门的理由长任务会触发上下文压缩compaction压缩摘要最容易牺牲的恰恰是最初的需求细节。真实事故长这样压缩之后Agent 后半程非常努力做完的却是一个很合理但不是用户要的东西。所以计划 验收标准 关键约束必须放进压缩的保留白名单或者干脆存在文件里每轮重读。第四章Replanning——计划写在沙滩上面试官执行到第三步查出来的结果把第一步的假设推翻了怎么办现在可以回答开头那个问题了计划写在沙滩上。但随时会被浪冲掉不等于不用写——恰恰相反正因为会被冲掉发现被冲掉、马上重写这个动作才是核心能力。重写就是重新规划Replanning。什么信号该触发重规划生产系统里主要是四类观察与预期不符计划第 1 步假设sales表可用查询发现根本没这张表新约束浮现数据量比预想大两个数量级原定全量拉取再汇总的方案根本跑不完用户中途变更“对了只要华东区的就行”——目标本身变了战术自愈失败升级上一篇讲的错误喂回连修几次都没修好——单步修不动说明问题出在计划层。触发之后重规划分三档粒度幅度由小到大修当前步换个参数、换个工具再试一次。这其实就是上一篇的错误自愈属于战术层计划本身不动修剩余计划当前步的失败改变了后续步骤的前提——已完成的保留剩余步骤重排、增删。这是最常用的一档推倒重来根本假设崩了数据源整个不可用带着已经获得的新认知从头规划。注意新计划不是旧计划的复读——它必须吸收这一路踩坑换来的情报。这里有一个决定重规划质量的工程细节失败必须作为情报显式写进新计划。比如在计划文件里记一行已确认sales表废弃数据源改用orders。不写这一行会怎样眼下没事——模型的上下文里还留着失败记录但等上下文一压缩、失败轨迹被清掉上一篇 context editing 干的活下一次重规划就可能兴冲冲地再撞一遍同一堵墙。上下文里的记忆会蒸发计划文件里的结论才是资产。图 3第 3 步的观察推翻了第 1 步的假设——已完成的保留失败结论记为情报剩余步骤基于新认知重排。新计划不是旧计划的复读。最后是一个平衡问题响应变化很好但每一步都全量重规划是灾难——方向反复摇摆、任务永远在重启、成本爆炸工程上管这叫颠簸thrashing。实用的做法是分层触发小偏差走战术修补改参数重试只有连续 N 次战术修补无效、或关键假设被明确推翻时才升级到战略重规划并且重规划本身也要计入预算——它每次都要烧一轮昂贵的深度思考次数封顶预算机制下一章展开。 开发者视角两条实操建议。一让重规划可见轨迹里显式记录第 N 步触发重规划、原因、计划 v1→v2 的差异——排查这 Agent 为什么绕了远路时计划的版本历史是最快的入口可观测性是 06 篇的主题。二重规划时把旧计划连同失败原因一起喂给模型而不是只给目标让它重新想一个——上下文里没有旧计划的尸体它大概率会想出一模一样的新计划。第五章什么时候算完——完成是设计出来的不是模型悟出来的面试官你的 Agent 怎么知道自己做完了它说做完就做完了最天真的答案模型不再请求工具、输出了一段任务已完成的总结循环自然结束。机制上没错——但把完成的判定权完全交给模型的自我感觉上线后你会遇到一个高频病症宣布胜利倾向。长任务后半程模型会把接近完成说成完成把我执行了动作当成我达成了效果——报告写了三节里的两节、测试还有一个没过它已经在热情地总结成果了。这不是撒谎是训练偏好使然给出完整、自信的答案在训练里被奖励而承认还没做完看起来像失败。治它靠两条设计原则第一验收标准前置。“怎么算完不能等到最后一刻靠感觉要在计划生成时就写成可逐条核对的条款报告包含总览/分区/趋势三节每个数字能对回源数据文件已写入指定路径。第三章的目标澄清在这里兑现价值——验收标准越具体完成就越不依赖模型的自我评价。判定完成 逐条打勾而不是通读一遍觉得差不多了”。第二完成要过验证步而不是听宣告。能自动验证的一律自动验证代码任务跑测试文件产出检查存在且非空数据任务抽几行和源头核对。验证不过就带着差在哪的具体信息回到循环——这一下就把完成判定从主观感觉变成了又一轮 Thought-Action-Observation。让模型自查self-check有没有用有能捞回一部分低级遗漏但自己给自己打分天然乐观关键任务需要独立的验证信号测试、schema 校验或者干脆换一个检查者来审——多 Agent 的评审模式05 篇和系统化的评估06 篇都从这里生长出来。还有第三种经常被忘记设计的结局做不了也是合法终点。缺权限、缺关键信息、几条路都试过走不通——这时候最有价值的输出不是硬编一个看起来完成的结果而是如实报告卡在哪、已经试了什么、需要什么才能继续。Agent 最贵的失败不是死循环——死循环你看得见是自信地交付了错误结果——它要等下游炸了才暴露。给做不了设计一个体面的出口是在给整个系统买保险。 开发者视角给完成留证据。要求 Agent 收尾时输出一份核对清单每条验收标准 达成证据文件路径、测试输出、核对过的数据行数。你抽查证据比重读全程轨迹快一个数量级而且这份标准 证据清单直接就是 06 篇评估集的现成原料——现在多要一句话将来省一套标注。第六章死循环与预算——空转是怎么发生的面试官Agent 卡在循环里空转你怎么发现、怎么兜底先认识敌人。线上的空转主要是三种形态各有画面感复读机同一个工具、同一组参数反复调用期待出现不同的结果。病根往往在上一篇讲烂的那件事——错误信息写得太糊模型不知道该怎么改只好原样再试钟摆方案 A 失败换方案 BB 失败换回 A再失败再换 B……在两个状态之间永久震荡意识不到还存在第三条路永远差一步最隐蔽的一种。每步都有进展——又读了一个文件、又搜了一轮资料、又核对了一遍——单步看全都合理但离真正的产出永远差一步。收集癖式的完美主义循环轨迹好看产出为零。对付它们要三道防线由粗到细第一道硬预算。最大步数、最大 token、最大耗时、最大金额超了就停。粗暴但必须有——它不能阻止空转发生只能给损失封顶作用等同于保险丝。上限怎么定不该拍脑袋按任务类型的历史步数分布取个高分位比如 P95 再留余量让正常任务几乎不会撞线异常任务撞线即暴露。第二道无进展检测。比硬预算聪明一点不看跑了多久看有没有变化。工程做法是给每一步算一个状态指纹——工具名 规范化后的参数 结果摘要取哈希——短窗口内指纹重复超过 N 次判定空转钟摆则表现为两个指纹交替出现的 A-B-A-B 模式。更语义化的版本每隔 K 步让模型自评一次离目标的实际进展连续几轮说不出新进展同样触发。第三道干预升级。检测到空转别急着一枪毙掉——先干预往上下文里注入一条提示你已经用相同参数调用 X 三次了换一个思路或者明确说出你缺什么。“相当于给循环里的模型递一张纸条很多时候真能拽出来。干预无效再熔断熔断时保存已完成的部分checkpoint如实上报卡在哪、试了什么”——正是上一章做不了的体面收尾。长任务分段存档还有一个好处人工解决卡点之后可以从断点续跑不用从零再来。图 4复读机、钟摆、永远差一步——三种空转三道防线逐级兜底预算封顶损失检测发现异常干预先救后杀。最后把预算这件事再抬高一层预算不只是止损手段它是产品决策。用户愿意为这个任务等几分钟这个任务的商业价值撑得起多少推理成本把Agent 能跑多远交给预算参数而不是模型心情才能对不同任务给出稳定一致的服务承诺。 开发者视角空转率是最值得放进监控大盘的指标之一。按任务类型统计步数分布凡是 P99 远远甩开 P50 的类型点进去看轨迹——几乎总能顺藤摸瓜找到一个错误信息写得稀烂的工具或者一条含糊到没法判定完成的验收标准。病根经常埋在上一篇工具层症状发作在这一篇循环层跨层排查是常态。第七章上线踩坑清单——循环这东西坑都在细节里面试官上了线这套循环踩过什么坑照系列惯例最后一章交坑。以下六条条条来自真实事故。思考预算错配。现代推理模型的深度思考extended thinking不是白给的——思考的 token 又贵又慢。两个方向都能翻车简单任务开满思考预算延迟翻倍、账单翻倍答案没变好复杂规划舍不得给预算计划质量直接塌方。原则是把昂贵的想花在刀刃上规划步、重规划步、验证步多想机械执行步少想甚至不想。自适应思考模型按难度自己决定想多久就是为这个权衡而生的而工具调用之间也保留思考interleaved thinking在长循环里价值最大——它保证每个 Observation 都被真正消化而不是扫一眼就过。压缩弄丢计划。第三章预告过的事故这里以症状复述一遍长任务中途触发上下文压缩最初的需求细节和验收标准被摘要糊掉Agent 后半程非常努力地做完了一个不是用户要的东西。药方计划外置成文件 压缩保留白名单 每轮把计划读回来。判断你有没有踩这个坑的信号任务越长产出偏题越严重。人工检查点的位置错了。全自动等于让高风险动作裸奔步步审批用户体验归零Agent 存在的意义也归零。性价比最高的两个审批位计划确认后、执行开始前拦截方向性错误成本最低的时刻和不可逆写操作之前上一篇操作分级的续集。中间的只读探索过程放心让它自己跑。子任务并行的竞态。计划里互不依赖的子任务可以并行执行探索类任务同时调研三个候选方案收益巨大但共享可变状态的并行是灾难——两个执行流同时改同一个文件、操作同一个账户竞态和普通后端并发一模一样而模型不懂加锁。铁律读并行随意写并行必须隔离。至于并行的执行者本身也是一个个 Agent这个方向怎么走是 05 篇多 Agent 协作的主题。换模型后步数分布漂移。升级或更换模型同样的任务集平均步数、重规划频率、思考 token 用量都会变——更强的模型可能步数更少但单步更贵也可能更谨慎导致验证轮次变多。你的预算阈值、空转检测参数、成本估算全都基于旧分布标定。所以把步数/成本分布纳入模型升级的回归评估清单上一篇说 Schema 变更要跑回归模型变更同理别让保险丝在升级后变成天天误熔断的裁员名单。把循环控制全托付给提示词。系统提示里写请不要陷入死循环“最多执行 20 步”然后就认为有了防线——这是最常见也最危险的错觉。提示词是建议代码才是约束第六章的三道防线每一道都必须实现在循环外层的代码里。模型不可能自己熔断自己就像程序不能指望靠注释来限制自己的资源占用。上一篇立过的那条分界线在规划层原样成立判断力归模型控制权归代码。结语规划不是玄学是控制论的老熟人回头看这七问按系列惯例把玄学拆成老熟人ReAct 循环是控制论讲了七十年的反馈回路——军事上叫 OODA 循环观察-判断-决策-行动自动化上叫闭环控制本质都是用真实观测不断校正下一步动作任务分解是分治显式计划是把状态外置的状态机重规划是异常处理加补偿逻辑终止条件是收敛判定空转检测是看门狗定时器预算是资源配额。没有魔法——把自动化工程做了一百年的开环改闭环原样搬给了大模型这个新的控制器。再回收开头那个问题计划是刻在石碑上还是写在沙滩上写在沙滩上——而且要紧挨着浪写。正因为随时会被冲掉发现被冲掉、立刻重写的能力才是规划的全部要义。石碑式的计划不是稳健是把赌注一次押完。但 Agent 能自己想清楚该干嘛之后一个更让人睡不着的问题立刻浮出来它现在会自己拆任务、自己纠偏、失败了还会锲而不舍地换路再试——如果有人往它的知识库里塞了一句恶意指令这份坚韧会不会被用在错误的方向上权限怎么分级、沙箱怎么隔离、注入怎么防、哪些动作必须过人——下一篇聊安全护栏与权限设计。这个系列会持续更新也欢迎把你被问住的问题丢过来说不定就是下一篇的选题。本文是《AI Agent 核心机制》系列第三篇。第一篇《Agent 记忆与 RAG 怎么做一场把我问到哑口无言的技术面试》讲怎么记得住事第二篇《Agent 怎么动手工具调用与 Function Calling 的工程真相》讲怎么操作外部世界想从头搞懂大模型本身怎么思考请看《别再把 AI 当黑盒万字拆解大语言模型的底层暴力美学》与《自注意力中的 QKV 详解》系列。