当前位置：首页 > news >正文

ChatGPT、Codex方法论：任务分层之后，为什么还要建立Agent Task Contract？

news 2026/8/5 10:22:31

很多团队开始使用Codex之后，很快就学会了任务拆分。

一个复杂需求不再直接交给单个Agent从头做到尾，而是拆成代码探索、方案设计、功能实现、测试验证和代码审查。不同任务还可以交给不同Agent并行执行。

但真正运行一段时间后，新的问题会出现：

探索Agent找到的问题，没有完整传给实现Agent；
实现Agent修改了计划之外的目录；
测试Agent不知道应该验证哪些业务场景；
审查Agent指出风险，却没人决定是否允许合并；
每个Agent都完成了自己的任务，最终结果却无法交付。

这说明，仅仅把任务拆开还不够。

多Agent系统还需要一种机制，明确每个任务的目标、输入、边界、依赖、证据和停止条件。

这就是Agent Task Contract，也就是Agent任务契约。

它解决的不是“怎样让Agent开始工作”，而是：

怎样让不同Agent围绕同一套交付标准协作，并且让每个结果都能被检查、传递和验收。

一、为什么任务已经拆分，Agent仍然会跑偏？

任务拆分主要解决工作量问题。

例如一个支付状态异常，可以拆成：

调查支付回调；
检查订单状态更新；
修改后端逻辑；
补充测试；
审查最终Diff。

从表面看，职责已经很清楚。

但每个任务仍然可能存在大量未说明的信息。

调查Agent不知道应该只看测试环境，还是也可以读取生产日志；实现Agent不知道能不能修改数据库结构；测试Agent不知道“测试通过”是只跑单元测试，还是必须验证完整支付流程。

这些没有写清的地方，最后都需要Agent自己猜。

任务越复杂，猜测越多；参与的Agent越多，猜测之间越容易冲突。

所以真正的问题不是任务有没有拆开，而是每个任务是否具备一份可以执行和验收的契约。

二、Agent Task Contract到底是什么？

Agent Task Contract不是法律合同，也不是一篇很长的需求文档。

它是一份结构化任务说明，用来约定：

Agent要实现什么结果；
可以使用哪些输入；
允许读取和修改什么；
开始前需要满足哪些条件；
必须提交什么证据；
哪些情况需要暂停；
哪些操作需要人工批准；
最终怎样判断完成。

可以把它理解为三个角色之间的协议：

任务系统负责定义要求；
Agent负责执行并提交证据；
人类或下游Agent负责验收结果。

普通提示词关注“请做什么”。

任务契约还要回答：

做到什么程度？
在什么范围内做？
出现什么情况不能继续？
用什么证据证明已经完成？

三、一份任务契约需要包含哪些字段？

完整的Agent Task Contract可以包含八个核心部分。

1. Objective：目标

说明任务最终要解决什么问题。

错误写法：

优化支付模块。

更好的写法：

修复支付回调重复到达时，订单状态被重复更新的问题，保证同一回调被多次处理后，订单和账务结果保持一致。

目标应该具体、可观察，并且只解决一个主要问题。

2. Inputs：输入

列出Agent可以依赖的信息：

Issue描述；
错误日志；
相关文件；
接口文档；
测试数据；
上游Agent的调查结论。

如果关键输入缺失，Agent应当暂停，而不是自行编造。

3. Scope：范围

明确允许读取、修改和禁止触碰的范围。

例如：

可以读取services/payment和services/order；
只允许修改支付回调处理器和相关测试；
不修改数据库表结构；
不更换消息队列；
不升级第三方依赖。

Scope是防止小任务扩展成大重构的主要边界。

4. Dependencies：依赖

说明任务开始前必须满足什么条件。

例如：

根因调查已经完成；
支付回调协议已经确认；
测试环境能够接收模拟回调；
上游接口没有同时进行不兼容修改。

依赖未满足时，任务状态应该是“阻塞”，而不是“执行失败”。

5. Evidence：证据

规定Agent交付时必须提供什么：

修改文件列表；
关键Diff说明；
测试命令；
测试输出；
复现前后对比；
未验证风险；
回退方式。

没有证据的“已完成”，只是Agent的自我判断。

6. Stop Conditions：停止条件

说明什么时候必须暂停执行。

例如：

需要修改计划外目录；
发现问题根因与任务假设不同；
测试环境不可用；
连续两次修复仍然失败；
需要访问生产数据；
预计修改公共接口。

停止不是任务失败，而是把重大决策交还给人类。

7. Approval：审批节点

规定哪些动作必须得到人工确认：

新增生产依赖；
修改数据库；
删除数据；
更改权限规则；
访问外部网络；
合并或部署；
扩大任务范围。

提示词中的“请谨慎”不能代替真正的权限边界。

8. Done：完成标准

Done用于定义任务什么时候可以结束。

例如：

原问题能够稳定复现；
修复后相同场景通过；
重复回调不会产生重复结果；
相关测试和类型检查通过；
没有无关Diff；
剩余风险已经明确记录。

四、任务契约和提示词有什么区别？

提示词通常服务于一次对话。

任务契约服务于完整任务生命周期。

一个Agent可能先接收提示词，执行一段时间后交给测试Agent，测试失败后再返回实现Agent。如果只有最初那段自然语言提示，信息在多次传递后很容易丢失。

任务契约则应该始终跟随任务。

无论任务交给哪个Agent，它们看到的都应该是同一份：

目标；
边界；
当前状态；
已有证据；
剩余要求。

提示词是交互入口。

Task Contract才是跨Agent、跨线程和跨阶段传递的任务对象。

五、Task Contract、AGENTS.md和Skill怎样分工？

这三个概念不能混在一起。

AGENTS.md：保存长期规则

适合记录仓库长期有效的约束，例如：

修改JavaScript后必须运行什么测试；
支付金额禁止使用浮点数；
不得擅自增加生产依赖；
公共接口变化必须说明兼容性。

这些规则不属于某个具体任务，而是每次工作都要遵守。

Skill：保存重复流程

适合封装稳定工作方法，例如：

创建规范Bug Issue；
执行版本发布检查；
生成迁移报告；
运行安全审查；
整理CI失败结果。

Skill回答的是“这类任务通常怎么做”。

Agent Task Contract：描述当前任务

它记录本次任务的具体目标、输入、范围、依赖和完成状态。

可以记成一句话：

AGENTS.md规定长期不能违反什么；
Skill规定一类工作应该怎么执行；
Task Contract规定这一次到底要交付什么。

六、为什么停止条件比完成条件更重要？

很多任务只写Done，却没有Stop Conditions。

这会让Agent形成一种错误倾向：

只要还没达到完成条件，就继续尝试。

假设Agent修复支付Bug时发现，需要修改共享订单状态机。

如果没有停止条件，它可能直接扩大范围，因为这是完成目标的一条可行路径。

但共享状态机可能同时被退款、发货和售后系统使用。一次未经审批的修改，风险远高于当前Bug。

合理契约应该明确：

如果需要修改共享状态机，立即暂停；
输出影响模块、推荐方案和替代方案；
等待人工批准后再继续。

高质量Agent系统，不是让Agent永远不停地工作，而是让它知道什么时候必须停下来。

七、完整案例：支付状态Bug怎样进入任务契约？

假设线上出现一个问题：

用户完成支付后，订单偶尔仍显示“处理中”。

如果直接交给Codex：

修复支付状态不同步问题。

Agent可能同时检查前端轮询、订单服务、支付回调、缓存和数据库，最后产生一个很大的Diff。

采用任务契约后，可以先建立主任务。

任务名称： 修复支付完成后订单状态未及时更新的问题 Objective： 确认支付回调到订单状态更新之间的失败点， 修复后确保支付成功订单能够稳定进入“已支付”状态。 Inputs： - Bug Issue - 测试环境日志 - 支付回调协议 - 最近七天相关提交 - 当前订单状态机说明 Scope： 允许读取payment、order和相关测试目录。 调查阶段禁止修改代码。 实现阶段只允许修改已经确认存在问题的模块。 禁止修改数据库结构、支付协议和公共接口。 Dependencies： 测试环境能够模拟支付回调。 产品已确认正确状态流转规则。 Evidence： 根因说明、调用链、修改文件、测试命令、 测试结果、剩余风险和回退方式。 Stop Conditions： 需要读取生产敏感数据； 需要修改公共状态机； 根因与原假设不一致； 连续两次修复后测试仍失败。 Approval： 数据库修改、公共接口变更、生产发布必须人工批准。 Done： 支付成功场景通过； 重复回调场景通过； 回调延迟场景通过； 相关单元和集成测试通过； 不存在无关Diff。

这份主契约还可以继续拆成多个子契约。

八、多个Agent怎样围绕同一份契约协作？

第一阶段：探索Agent

任务：

复现问题；
绘制支付回调到订单状态的调用链；
比较正常请求和异常请求；
输出根因候选。

它没有修改代码的权限。

交付格式固定为：

已确认事实： 根因候选： 相关文件： 未确认问题： 推荐下一步：

第二阶段：实现Agent

只有在探索结论被接受后才开始。

输入包括：

主任务契约；
探索Agent报告；
被批准的修改方案。

它不能重新定义业务规则，也不能自行扩大范围。

第三阶段：测试Agent

测试Agent不只执行已有测试，还要对照Done条件检查：

正常支付；
回调重复；
回调延迟；
状态查询失败；
修复后的兼容性。

第四阶段：审查Agent

审查Agent重点回答：

修改是否超出Scope；
是否真正解决根因；
测试证据是否充分；
是否存在安全和兼容风险；
是否夹带无关重构。

第五阶段：人工审批

涉及支付核心流程，最终合并仍由人类决定。

Agent负责准备证据，人类负责接受风险。

九、多Agent任务为什么必须规定返回格式？

只写“请调查这个问题”，不同Agent可能返回完全不同的内容。

有的输出长篇分析，有的只给一句结论，有的直接修改代码。

当主Agent需要汇总多个结果时，大量资源会消耗在重新理解和整理上。

所以子任务契约还应规定返回格式。

例如探索任务统一返回：

结论： 证据： 影响范围： 可信度： 未解决问题： 建议动作：

测试任务统一返回：

测试命令： 覆盖场景： 通过项： 失败项： 未执行项： 风险判断：

返回格式越稳定，Agent之间的衔接成本越低。

十、任务执行过程中，契约能不能修改？

可以，但修改必须留下记录。

软件任务经常随着调查出现新信息。真正的问题不是契约发生变化，而是变化没有被显式管理。

建议为契约增加：

Contract Version：v1.2 Changed By：人工负责人 Change Reason：发现问题来自共享缓存，而非前端轮询 Approved Scope：允许读取cache目录，但暂不允许修改

每次扩大范围、调整完成条件或增加依赖，都应更新版本。

否则测试Agent可能仍按旧标准验证，审查Agent也不知道某项修改是否已经批准。

契约不是静态文档，而是任务状态的可信来源。

十一、最常见的五种契约失败

目标仍然过大

“完成支付系统重构”不适合作为单个契约。

应该继续拆成独立可验收阶段。

范围写得过死

只允许修改一个文件，但真正根因在另一个模块。

正确做法不是让Agent偷偷修改，而是触发停止条件并申请扩大范围。

完成标准只有“测试通过”

测试可能覆盖不完整。

Done还应包含业务行为、修改范围和剩余风险。

没有区分阻塞和失败

等待上游接口不是任务失败。

错误状态会导致无意义重试。

契约只是写出来，没有真正执行

如果任务系统不检查Scope、审批和Evidence，契约就会退化成另一份没人看的文档。

十二、团队怎样建立最小可用版本？

第一阶段不需要开发复杂平台。

可以先在Issue模板中加入七个字段：

Objective： Scope： Inputs： Dependencies： Evidence： Stop Conditions： Done：

高风险任务再增加Approval。

第二步，把长期不变的规则放进AGENTS.md。

第三步，把重复执行的验证流程整理成Skill。

第四步，要求每个Agent结束时更新：

当前状态；
已完成内容；
证据；
阻塞项；
下一步。

第五步，在Pull Request模板中检查：

□ 修改没有超出任务范围 □ 完成标准全部满足 □ 测试证据已经提供 □ 高风险操作已经批准 □ 剩余风险已经记录

团队先连续执行两周，就能看出哪些字段真正有用，哪些需要调整。

Agent Task Contract通用模板

任务名称： 契约版本： Objective： 本次任务需要实现的结果。 Inputs： 允许使用的文档、日志、代码、数据和上游结论。 Scope： 允许读取范围： 允许修改范围： 明确禁止范围： Dependencies： 开始前必须满足的条件。 Execution Plan： 调查、实现、测试和审查阶段。 Evidence： 必须提交的Diff、命令、日志、测试和风险说明。 Stop Conditions： 必须停止并请求人工判断的情况。 Approval： 需要人工批准的操作。 Done： 可验证的完成标准。 Status： 待处理 / 执行中 / 阻塞 / 等待验证 / 等待审批 / 完成 / 失败 Handoff： 下一名Agent需要接收的结论、文件和未解决问题。