一个真实的 AI Agent 长任务案例：从需求到发布的动态工作图
通过生产级 CSV 导出案例，展示 AI Agent 如何用 Goal、动态工作图、并行 Agent、验收和续跑完成一次完整产品交付。
本文内容
图 1：同一个客户交付任务中，Goal、工作项、依赖和最终验收共同组成动态工作图。任务和结果为示例数据。
“增加一个 CSV 导出按钮”听起来像一个小时就能完成的小需求。真正交付给客户时，问题会迅速变多：谁有权限？数据量大时会不会卡死？导出的中文是否能打开？失败后用户如何重试？审计记录写在哪里？文档和版本说明有没有同步？
这篇文章用一个生产级批量导出功能，完整走一遍 Nexus 的 Goal、动态工作图、Agent Loop 和验收机制。重点是一个复杂交付如何拆开并行，怎样处理返工与阻塞，最后如何收口；CSV 格式本身不在讨论重点内。
需求先变成 Goal
用户希望交付完整的导出能力，仅修改某个导出函数还不够。目标如下。
为客户上线可靠的批量 CSV 导出能力。只有有权限的角色可以导出；十万条记录不能让界面失去响应；中文在目标表格软件中正常打开；取消、空数据和失败都有反馈；每次导出可追溯；文档与发布说明同步更新。
Nexus 先把这段要求保存为 Goal，并记录完成条件。此时还没有直接把它变成六个可执行节点，因为模型提出的计划还需要宿主检查范围、依赖和交付边界。
再把 Goal 变成责任图
当宿主检查并写入计划后，一次 Execution 会形成以下 Work Item：
| Work Item | 负责人 | 交付物 | 解锁条件 |
|---|---|---|---|
| 需求与权限边界 | Coordinator | 字段契约、角色矩阵、审计规则 | 产品和安全边界确认 |
| 服务端导出 | Backend Agent | 接口、权限校验、流式处理、审计写入 | 依赖需求边界，接口验证通过 |
| 客户端交互 | Frontend Agent | 选择、进度、下载、取消和错误反馈 | 依赖接口契约，交互测试通过 |
| 兼容性与规模验证 | Verification Agent | 编码、软件、规模和中断场景记录 | 服务端与客户端交付均已验收 |
| 文档与发布准备 | Documentation Agent | 使用说明、变更记录、升级提示 | 功能范围和限制已经冻结 |
| 集成验收 | Reviewer | 可发布构建、完整验收报告 | 所有前置 Submission 已接受 |
这张图不是简单的顺序清单。服务端和客户端可以并行，但它们都等待需求与权限边界；兼容性验证要等待两边的已验收交付；集成验收还要等待验证记录和发布文档。
可以把其中几条关键依赖单独列出来：
| 上游交付 | 下游工作 | 为什么必须等 |
|---|---|---|
| 字段、权限和错误契约 | 服务端与客户端实现 | 两边需要基于同一份边界开发 |
| 服务端与客户端 Acceptance | 兼容性和规模验证 | 验证必须针对可以交付的组合，而不是临时半成品 |
| 验证记录与限制说明 | 集成验收 | Reviewer 需要知道通过了什么、还没覆盖什么 |
| 最终 Acceptance | Goal 收口 | 计划完成仍需回到客户目标逐项核对 |
这六项工作组成的图因此比待办列表更有信息量。它不仅列出任务，还把“结果怎样才能被别人使用”写进了依赖。
第一轮：先完成一部分，并留下事实
Coordinator 将服务端 Work Item 分配给 Backend Agent。宿主签发只属于这份 Work Item、Assignment 和 Attempt 的执行绑定。
Backend Agent 在本轮中完成：
- 读取现有导出接口和权限中间件；
- 实现流式响应，避免一次性把十万条记录放进内存；
- 写入导出人、范围和时间的审计记录；
- 运行接口、权限和大数据量测试；
- 提交代码、测试结果和限制说明。
这时可以创建 Submission，但服务端 Work Item 还不能自动宣布整个功能完成。Reviewer 需要检查提交是否对应正确的 Attempt，测试是否覆盖完成条件，权限规则是否与需求边界一致。
并行工作不是互相覆盖
Frontend Agent 可以同时实现选择、进度和取消按钮，但它不能自行猜测接口行为。它依赖已经确认的字段和错误契约。
如果前端先做出了临时字段，后端后来修改了响应结构，工作图应该显示一个依赖或版本问题，而不是让两个 Agent 通过聊天继续互相覆盖。重新规划时，系统保留旧 Plan revision 和已经产生的 Attempt，新的结构使用新的 Plan revision。
这正是工作图和 Skill 的差别：Skill 可以分别告诉前端 Agent 怎样做下载按钮、告诉后端 Agent 怎样写流式接口；WorkGraph 负责记录二者是否基于同一份契约、哪些结果已经可以交给验证 Agent。
第二轮：验证发现问题，沿原责任返工
两边交付后，Verification Agent 开始检查真实场景：
- 一万条、十万条记录的响应时间和内存；
- 中文、混合语言和特殊字符；
- 空结果、权限不足、网络中断和用户取消；
- 目标表格软件的打开结果；
- 审计记录是否与当前用户和导出范围一致。
检查发现：文件下载成功，但中文在目标软件中出现乱码。Reviewer 提交 changes_requested，并把问题绑定到兼容性验证对应的 Submission。
此时不需要重新画一张工作图。责任仍然是“兼容性与规模验证”，依赖也没有改变。负责人创建新的 Attempt，补充编码处理和复现测试，再产生新的 Submission。第一份提交、退回意见和第二份提交都保留。
如果发现的是“还需要一名独立安全 Reviewer”，情况就不同了。它改变了责任结构，需要在新的 Plan revision 中增加安全复核 Work Item，并让集成验收等待新的 Acceptance。
第三轮：信息不足时停下来
如果客户没有说明支持哪种表格软件，Verification Agent 不应该凭经验选择一个版本然后宣布通过。它应当记录 blocker：
阻塞：缺少目标表格软件与版本
需要输入：软件名称、版本、目标平台
解除后：继续兼容性验证并重新提交结果
Goal continuation 会因此暂停。用户补充信息后，新一轮读取同一个 Goal、当前 Plan 和未完成 Work Item，从兼容性验证继续，而不是重新执行已经验收的服务端和客户端工作。
第四轮：完成验收，再收口 Goal
当服务端、客户端、兼容性、文档和发布准备都产生被接受的 Submission 后，Reviewer 进行集成验收：
- 从客户目标重新核对字段、权限、性能、兼容性、反馈和审计；
- 检查当前 Plan 中的必需 Work Item 是否全部收口；
- 确认没有 blocker、unknown 或未处理的 changes requested；
- 检查发布构建和文档是否对应同一版本；
- 记录最终 Acceptance，并请求结束 Goal。
这里仍然有两个不同的问题：工作图问“计划里的责任是否都交付并验收”，Goal 问“客户最初要的产品能力是否真的闭合”。
最终收口时，可以使用一张简单的证据表避免把“全部节点完成”当成产品完成：
| 客户要求 | 对应交付 | 最终证据 |
|---|---|---|
| 只有有权限的角色可以导出 | 服务端权限边界 | 越权测试与审计记录检查 |
| 大数据量不让界面失去响应 | 流式接口与客户端进度 | 规模测试、内存和取消记录 |
| 中文在目标软件中正常打开 | 兼容性验证 | 指定软件和版本的打开结果 |
| 失败、空数据和取消有反馈 | 客户端交互 | 各分支的界面验证 |
| 变更可以交接和发布 | 文档、版本与集成验收 | 同版本构建和发布清单 |
如果某一行没有对应的证据，Reviewer 应该提出补充或退回，而不是因为其他节点已经变绿就结束 Goal。这种收口方式把文章开头的产品问题重新接回执行器的持久状态。
这个案例说明了什么？
一个 Skill 可以很好地完成局部专业工作：写流式接口、实现下载交互、检查编码、整理发布说明。但生产级交付还需要持续回答：
- 哪些工作可以并行，哪些必须等待；
- 结果属于哪个负责人和哪次尝试；
- 退回以后从哪里返工；
- 什么是等待，什么是失败，什么是外部状态未知；
- 哪些交付已经验收，哪些只是“看起来完成”；
- 用户改了目标以后，旧结果是否仍然有效；
- 什么时候可以安全地结束整个任务。
这些关系就是动态工作图存在的理由。它把一个模型可能完成的局部步骤，组织成一条跨 Agent、跨轮次、可恢复、能验收的交付链。
继续阅读AI Agent 的 Goal 是什么，了解目标和工作图的边界；也可以阅读AI Agent 如何判断任务完成，查看验收与恢复机制。
本文是 Nexus WorkGraph 的机制案例，所有任务、Agent、反馈和验收结果均为示例数据，不代表客户生产环境的测评结果。