规划与状态

本页是 Agent 核心 里“规划与执行范式”的展开，对应 主线 第 4 站：拿到制度证据以后，决定先查什么、再做什么、什么时候停。

不只是生成一份计划

计划是准备要做的步骤，状态是已经发生的事实。工具调用失败了，状态里却还写着“完成”，计划写得再漂亮也没用。

最小的状态集合可以是：等待、执行中、等待确认、完成、失败、取消。任务重启后能不能接着跑，要靠程序真的支持，光在文案里承诺不算。

举个例子：create_reimbursement_ticket 调用时超时了，状态应该停在“执行中（结果未知）”。如果这时把它标成“失败”，重启后系统会再建一张；标成“完成”，员工会收到一条“已提交”的回复，系统里却可能根本没有 R-55821。

计划长什么样

一份能执行的计划，每一步至少要写清：做什么，依赖哪些前置步骤，什么算完成，失败了怎么办。拿报销案举例（示意）：

步骤	依赖	完成判据	失败时
T1 查制度	无	找到带出处的现行条款	说明没找到依据，转人工
T2 查发票	无	拿到上周打车发票列表	追问是否用了其他账户
T3 查已有报销单	无	确认没有同行程的单	有则停止，提示可能重复
T4 判定	T1 到 T3	得出可报金额与所需材料	证据冲突则转人工
T5 确认	T4	员工确认事由与金额	拒绝则取消任务
T6 建单	T5	工单系统返回单号	超时先对账再决定重试

T1 到 T3 彼此不依赖，可以并行跑：search_policy、query_invoices、query_tickets 同时发出去，三个结果都回来再进 T4。T6 必须等 T5，这条依赖要写进程序，不能只靠模型“记得”。

计划谁来做

• 模型负责生成计划的内容，遇到意外时提出新计划。
• 运行时负责计划的数据结构、步骤状态的推进、依赖调度、重规划的触发和预算。
• 能写死的部分就直接写死。“建单前必须确认”“必须先查重复”这类约束，不需要模型每次重新规划一遍。

ReAct 可以看成“每一步只规划一步”，Plan-and-Execute 是“先把全程规划好，遇到阻碍再改”。步骤能预见的任务适合后者；信息高度不确定的探索任务适合前者。实际系统里常见的是外层一份计划、内层逐步决策。报销案就是这样：外层是 T1 到 T6 这张表，到了 T2 发现发票查不到时，内层再一步步决定是换个日期范围重查，还是去问员工。

什么时候重规划

重规划的触发条件要事先定好，常见的有三类：某一步失败了，而且重试解决不了；观测推翻了计划的前提，比如 T3 发现这趟行程已经有一张报销单；用户补充或者改了信息。重规划时只重排受影响的步骤，已经完成且仍然有效的结果直接保留。员工中途说“等下，那趟其实是上上周”，T1 查到的第 4.2 条仍然有效，不用重查；T2 和 T3 要按新日期重跑。

不设触发条件的话，系统要么从不改计划，一条路走到黑；要么每一步都重新规划，变成更慢、更贵的逐步决策。

状态要存在模型之外

计划和状态都要写进持久化存储，每个有外部副作用的步骤前后各写一次。这样中断以后能从断点接着跑：已经完成的步骤直接读结果；处在“执行中”的写操作先对账，再决定要不要重试，具体做法见 可靠执行。等人确认也是状态的一部分，确认点怎么设计见 人在回路。

常见失败

• 计划和状态混在一起：模型在回复里写了一句“第三步已完成”，系统就当它完成了，实际工具调用失败了。完成没完成，只能由工具结果和外部状态来定。
• 漏掉条件依赖：“能报的话帮我提单”里，提单的前提是“能报”。拆任务时把这个条件丢了，就会出现还没判定就先建单。
• 粒度失衡：一步里又查又写，失败后说不清是哪部分出的问题；或者拆得太碎，十几次调用才办完一件小事。
• 计划过期还在执行：员工中途改了出差日期，计划却照旧去查原来那一周的发票。
• 没有收口：计划里每一步都写“尽力而为”，没有任何一步写明失败时该停下来告诉员工。

面试里怎么讲

先把两个概念分开：计划是“打算做什么”，状态是“实际做到哪”。再讲分工：模型出计划内容，运行时管状态推进、依赖和预算，硬约束直接写死。然后拿一个例子画出依赖图，指出哪些步骤能并行、哪个写操作前面有确认。最后讲重规划的触发条件和中断后怎么恢复。照这个顺序讲，比只背 ReAct 和 Plan-and-Execute 的定义更能让人相信你做过系统。

待验证

在 研究 Agent 里记录：检索失败以后，是补一次查询、请用户帮忙，还是明确停下来；每个分支都留下理由。

同样的问题放到报销案里：发票查不到时，三种分支各自的触发条件是什么？能不能在评测集里各放一个用例，检查 Agent 走的是预期那一支？比如“日期范围写错”应该补查，“员工用的是私人账户打车”应该去问员工，“发票系统整体故障”应该停下来并告诉员工稍后再试。