很多团队开始使用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 Versionv1.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需要接收的结论、文件和未解决问题。结语任务分层解决的是谁来做哪一部分工作。Agent Task Contract解决的是每一部分应该在什么边界内做到什么程度并用什么证据交付。当团队只有一个开发者和一个Agent时很多信息可以留在人的脑子里。当多个Agent开始并行工作任务需要跨线程、跨阶段甚至跨团队传递时隐含信息就会变成返工、冲突和风险。未来的软件团队不能只管理任务列表还需要管理任务契约。真正成熟的Agent系统应该做到目标清楚输入可信范围明确依赖可见权限受控失败可停结果有证据交付能验收。AI写代码的能力会继续提高但决定多Agent工程是否可靠的不只是模型有多强而是团队能否把模糊需求转化成一份可执行、可监督、可传递的任务契约。当团队已经完成任务分层却仍然频繁遇到Agent跑偏、重复排查、交付不完整和审查困难时下一步通常不是继续增加Agent而是先建立Agent Task Contract。