AI Agent 如何判断任务完成？WorkGraph 的提交、验收与失败恢复
AI Agent 说完成以后为什么还要验收？本文解释 WorkGraph 的 Submission、Review、Acceptance、返工、阻塞和未知状态恢复。
本文内容
图 1：一份结果需要经过提交、评审和验收，才能成为下游可以依赖的交付。图中为机制示意。
AI Agent 说“完成”以后，任务真的完成了吗？在短对话里，用户可能直接查看结果；在多 Agent、跨轮次的长任务里，这个判断需要一条可检查的证据链。
Nexus 把交付拆成 Submission、Review 和 Acceptance 三个阶段。它们分别回答：交了什么，谁检查了，结果是否被接受。这样可以把“运行过一次”“产生了结果”和“交付成立”区分开。
Submission：把结果交出来
Agent 完成一次 Attempt 后，可以提交一份结果。Submission 可以关联代码变更和文件，也可以关联测试记录、数据或说明，但它必须属于明确的 Work Item 和 Attempt。
提交把结果变成其他人可以检查的对象，尚不代表结果获得认可。提交后，原来的 Attempt 可以结束，但 Work Item 仍然可能处于等待评审的状态。
Review：检查交付是否满足要求
Review 需要知道检查的对象和标准。比如 CSV 导出交付至少需要检查：
- 角色没有权限时不能导出；
- 选中记录、字段和顺序正确；
- 大数据量处理不会让界面失去响应；
- 中文在目标软件中能正常打开；
- 空数据、取消和失败路径有明确反馈；
- 审计记录能关联到正确的用户和导出操作。
Reviewer 可以是负责人、独立 Agent 或人工参与者，但它需要有明确的 ReviewBinding，也就是“由谁、按哪项责任、检查哪份提交”的绑定记录。读过同一份 Skill 或看见同一条聊天消息，不等于完成了独立 Review。
一份可验收的 Submission 应该包含什么？
Submission 是让 Reviewer 能够复现判断的交付候选，仅说一句“已经改好了”还不够。不同工作项的字段会不同，但至少要能把结果和责任、执行、完成条件连起来。
| 证据 | 说明 | CSV 导出中的例子 |
|---|---|---|
| 交付范围 | 这份结果解决了哪项责任 | 服务端导出接口与权限校验 |
| 变更对象 | Reviewer 应该检查什么 | 代码变更、接口契约和审计写入 |
| 验证记录 | 运行了哪些检查，结果怎样 | 权限、十万条数据、空数据测试 |
| 已知限制 | 哪些环境还没有覆盖 | 尚未确认目标表格软件版本 |
| 归属引用 | 结果属于哪个 Attempt 和 Work Item | 服务端 Work Item 的第二次 Attempt |
这些信息不要求 Agent 预先知道所有答案。明确写出“尚未覆盖”比制造一个看似完整的通过结论更有用：Reviewer 可以据此提出 changes requested 或 blocker，Goal continuation 也能知道下一轮应该补什么。
Acceptance：决定下游能否继续
Review 结束后，系统记录 Acceptance。只有对应 Submission 被接受，依赖它的下游 Work Item 才能解锁。
| 当前状态 | 代表什么 | 下游能否使用 |
|---|---|---|
| Attempt succeeded | 这次执行没有失败 | 不能直接使用 |
| Submission created | 有结果可以检查 | 仍需评审 |
| changes requested | 结果需要返工 | 不能使用旧结果替代 |
| Acceptance accepted | 这份交付被明确接受 | 可以按依赖继续 |
| unknown | 外部状态尚未确认 | 必须先对账 |
这条规则会让工作图看起来比待办列表严格，但它解决了长任务里最容易出错的地方：下游不再把一个 Agent 的局部成功误认为整个系统已经具备前置条件。
Acceptance 也不是对业务质量的无限担保。它确认的是：在当前范围、当前标准和当前证据下，这份 Submission 被相应的 Reviewer 接受。目标环境后来变化，或者新的完成条件加入，旧 Acceptance 仍然可以保留，但 Goal 需要重新判断它是否覆盖当前目标。
失败、返工和重新规划有什么区别？
返工：责任没变
例如中文兼容验证发现乱码。原来的 Work Item 仍然是“验证中文兼容”，依赖关系没有改变。系统保留第一份 Submission 和退回意见，负责人创建新的 Attempt，修正后再提交。
重新规划：责任结构变了
如果发布前新增独立安全复核，原计划没有这项责任，就需要新的 Plan revision。新版本增加安全复核 Work Item，并规定发布验收要等待它。
阻塞：条件还不具备
如果用户没有说明目标软件，Agent 无法完成兼容性验收。此时应记录 blocker 和所需输入，等待用户补充，而不是反复执行同一套测试。
未知：外部结果还没有确认
外部系统超时并不代表操作一定失败。请求可能已经生效，也可能没有生效。系统需要使用 request identity 或接收端查询进行 reconciliation，在确认之前保留 unknown 状态，不能为了“继续推进”而自动重复一个可能有副作用的动作。
完成审计为什么还要回到 Goal？
即使所有 Work Item 都通过 Acceptance，Goal 仍然需要检查最终要求是否完整。例如计划包含了接口、客户端和兼容性验证，却没有包含“审计记录可追溯”。工作图可以完成，Goal 仍然没有闭合。
完成审计至少要重新读取：
- 当前 Goal objective 和 completion criteria；
- 已确认的 Goal/Execution binding；
- 当前 Plan revision 和必需 Work Item；
- 每个关键交付对应的 Acceptance；
- blocker、unknown、预算和终止条件。
工作图证明责任已经收口，Goal 证明最终目标没有被局部结果替代。
这套验收机制带来的实际变化
它让系统可以在断连、重启、换负责人和多 Agent 协作后继续判断：
- 哪项责任还没有提交；
- 哪份提交正在等待评审；
- 哪份结果被退回，应该从哪里返工；
- 哪些下游依赖已经解锁；
- 哪个外部动作还处于未知状态；
- Goal 是否具备最终结束的证据。
如果想先了解整条责任链，可以阅读Graph Engineering 与动态工作图；如果想看完整案例，可以继续看从需求到发布的动态工作图案例。
本文描述 Nexus 的交付与恢复边界。Acceptance 是系统记录的交付结论，不自动证明业务内容在所有外部环境中都正确；真实环境仍需单独验证。