任务编排与长程推进

一句话：任务的本质不是“多轮对话”，而是把模型的离散判断组织成有状态、有预算、可恢复、由证据决定结束的过程。模型只能申请完成，Harness 才提交完成。

对应原书：第 4 章《任务：编排、长程推进与协作流转》。

为什么需要

一次调用能回答的问题，不需要任务模型。一旦任务跨越多步、多个工具、多个请求，三件事会同时失效：

• 过程丢了：进程重启、上下文窗口切换之后，不知道做到哪一步；
• 结束失控：模型说“完成了”，但环境里什么都没变；或者循环停不下来，预算悄悄烧完；
• 责任不清：委派给子 Agent 之后，失败算谁的，产物算不算数。

消息历史解决不了这些问题——它记录“说过什么”，不记录“事实是什么”。任务模型要解决的是后一件事。

核心机制

一、Agent Loop 五阶段

五个阶段里最容易被做薄的是 Verify：很多实现把它交给模型自评，等于让考生自己判卷。原书的要求是“用环境事实或规则验收”——测试过没过、文件变没变、接口返回什么，都要能查。

二、权威状态与十态状态机

消息历史不是任务状态。权威状态必须可机读，至少包含：目标、当前阶段、Plan/Todo、已确认事实、阻塞项、子任务、Artifact、剩余预算、等待原因、完成依据。

状态	含义	关键出边
CREATED	已创建	→ RUNNING
RUNNING	推进中	→ 三种 WAITING / PAUSED / VERIFYING / FAILED / CANCELLED
WAITING_INPUT	等用户输入	收到输入 → RUNNING
WAITING_APPROVAL	等人工审批	批准 → RUNNING；拒绝 → 结束
WAITING_EVENT	等外部事件	事件到达 → RUNNING；超时 → 结束
PAUSED	主动暂停	恢复 → RUNNING
VERIFYING	验收中	通过 → COMPLETED；不通过 → RUNNING/FAILED
COMPLETED / FAILED / CANCELLED	终态	—

两个区分决定了系统的可运维性：WAITING 不是失败，它让运行时释放资源、界面说清在等什么、监控区分“执行慢”和“审批慢”；PAUSED 不是结束，它是可以恢复的中间态。

三、预算与计划

预算必须是多维的：步骤数、总时长、Token、费用、工具调用并发、高风险动作次数。只设一个最大步数，会漏掉“步数没到但钱烧完了”和“步数没到但一直原地打转”。预算耗尽要给明确终态和未完成清单，不能悄悄截断。

计划的控制强度分三档：

• 轻量 Todo：目标明确、步骤少，列出来防遗漏即可；
• Plan Mode：影响大、需要审阅，先只读探索，写出计划，人工确认后再执行；
• Planner-Executor：长任务、多依赖、可并行，计划本身是一等对象。

阶段门禁的写法值得固定下来：每个阶段回答“输出是什么、证据在哪里、谁来确认”。计划允许修订，但修订要说明触发事实、保留已完成项，不能靠改写目标来掩盖失败。

四、委派：七字段契约

子 Agent 的价值来自三件事：上下文隔离（只加载相关材料）、能力隔离（不同模型、指令、权限）、并行执行（缩短墙钟时间）。任务很短、步骤强依赖、共享对象频繁变化时，委派反而亏本。

委派必须是可机读的契约，七个字段缺一不可：目标与边界、已知上下文、能力与权限、预算、输出与证据、失败语义、验收条件。失败策略四选：FAIL_FAST、BEST_EFFORT、RETRY_OR_REASSIGN、ESCALATE。

还要分清两种关系：

• Delegation：父任务保留责任，子任务产物是新的 Observation；
• Handoff：控制权转移，接收者成为当前责任人。

两者都不能只靠一条自然语言消息。子任务返回的自然语言答案，必须过 Schema 校验和父任务验收，才能进入权威状态。

五、长程续行与失败处理

跨请求、跨进程、跨上下文窗口续行，靠的是三件东西：稳定的 task_id、事件游标、Continuation。Session 存在共享存储里，任意实例都能接续。恢复的动作顺序很关键：先重查目标、外部条件、权限与剩余预算，再决定继续。 直接重放对话会恢复出一个越权或已经失效的执行现场。Context Reset 只控制语义——旧窗口形成一个一致的继续点，新窗口从权威状态重建，不重放聊天记录。

失败要先分类，再决定动作：

失败类型	处理
瞬时错误	有界退避重试
参数错误	修正参数
环境缺失	重建环境
权限拒绝	等待授权或终止
重复探索	重新规划
业务条件不满足	明确缺口，转人工

“Agent 失败了”不是可执行诊断。另外，有副作用的重试前必须先回答“上一次到底有没有发生”：幂等键、记录请求结果、优先查询状态，三件事至少做两件。

六、完成由证据决定

验证强度要和风险匹配：内部工具调用做到 A/B 即可，对外交付要做到 C，不可逆操作才需要 E。验证失败本身就是一条新的 Observation，不是异常退出。还有一条分工要记牢：Verifier 是单次任务的门禁，Evaluation 是跨版本的好坏判断。 把两者混在一起，会出现“为了过门禁而调评估集”的退化。

最小上手

task:
  state_fields: [goal, phase, plan, facts, blockers, artifacts, budget, waiting_for, completion_evidence]
  budget: {steps: 40, minutes: 30, tokens: 200000, cost: 2.0, high_risk_actions: 2}
  pause:
    before_pause: [stop_new_actions, save_state, save_cursor]
    on_resume: [recheck_goal, recheck_external, recheck_permission, recheck_budget]
delegation:
  contract: [goal, context, capability, budget, output, failure_semantics, acceptance]
  failure_policy: ESCALATE
completion:
  verifier: [schema, environment, tests]
  model_can_only_request: true

验收看四件事：进程重启后能接着跑；等待态能被正确识别而不是被超时重试；委派产物必须过验收才进状态；完成时能指出证据在哪。

生产动作

• 把“无进展”做成检测器。五个信号：同参重复调用、反复同一错误、计划长时间不变、没有新事实、在少数行动间循环。只靠最大步数，循环早就发生了，预算还没到。
• 等待态要有超时语义。等输入、等审批、等事件都要定义超时后的动作，且超时不等于批准。
• 取消要沿父子传播，收尾要记录原因。取消父任务时子任务一起取消，已发生的外部副作用保留事实、需要时走补偿；每次结束记下终态、未完成清单、剩余预算与最后一条证据，这四项决定事后能不能复盘。

边界

• 状态机不是越细越好。十态是为了区分资源占用与等待原因；小系统可以合并 WAITING，但不能把等待混进 RUNNING。
• Plan Mode 不是万能。探索成本高的任务，先规划反而拖慢；短任务用轻量 Todo 即可。
• 委派不能消除责任。Delegation 与 Handoff 只是责任归属不同，都不能让“发起方不知道子任务做了什么”。
• 证据也有成本。每级验证都要花时间和算力，验证强度应随风险递增，而不是一律做到 E。
• 恢复不等于重放。重放对话只恢复语义，恢复事实要重查环境；已经发出的副作用，重放不会撤销。

讲清楚

任务模型解决的是“过程可恢复、结束有证据”。Agent Loop 五阶段里，Verify 必须用环境事实，而不是模型自评；权威状态要和消息历史分开，用十态状态机区分运行、等待、暂停与验收。

长任务靠三件东西续行：稳定的任务标识、事件游标、Continuation。恢复时先重查目标、外部条件、权限和预算，再继续；直接重放对话会恢复出失效现场。

委派要有七字段契约（目标、上下文、能力、预算、输出、失败语义、验收），子任务产物必须过验收才能进父状态。完成由证据分级决定，模型只能申请完成，Harness 才提交完成。

适用：长任务、异步任务与多步 Agent 的编排设计 | 初稿 2026-10