AI代理团队的委托合同：范围、验收与故障处理
为何代理角色的职位名称无法避免交接失误，以及如何测试带有强制策略、独立验收与失败处理规则的委托合同。
想象一下由三个模块共同处理的一次产品变更：在 API、调用该 API 的客户端以及测试用例中都添加了分页游标功能。这三个模块都报告处理成功，但客户端却无法解析 API 返回的数据。API 模块会输出 next_cursor，客户端模块期望的是 nextCursor，而测试模块则依据客户端的假设来验证模拟数据。每个单独的任务看似都已完成，但当真正发起请求时，整个变更方案就会出问题。
将智能体标记为工程师、客户专家和审核员，并不能说明哪种接口会胜出或由谁来批准结果。这些决策应体现在授权协议中，即明确列出输入内容、允许的范围、所需的输出结果、验收标准以及出现故障时的处理方式。该协议的价值在于系统如何依据它来运作，而非仅仅多出一份文档而已。
可以将其视为多层结构：角色决定了智能体处理工作的方式，而协议则明确了哪些贡献是可接受的。运行时策略决定了智能体实际能够做什么，而验收环节则决定这些贡献是否会被转化为最终产品状态。
专业化使得交接流程仍存在不确定性
角色描述了一种视角，比如寻找安全问题、构建客户端或质疑设计。任务契约则描述具体的工作内容：使用此接口版本、修改这些文件、提供此类证据。运行时权限决定了工作者真正可以读取、修改或运行的内容。
将二者分开可以让有用的角色保持其作用，而无需承担所有责任。审核者能够发现会破坏现有功能的变更，但无权批准它；工程师可以提出改进后的接口方案，却无权使其成为最终采用的版本。
Anthropic在2026年8月开展的多智能体研究让依赖性问题变得具体可见。在其游戏构建实验中，既定的角色分工及类似CEO的层级结构几乎未发生变化，即便某些模型在协调性指标上表现更好，游戏质量依然较差。同一份报告还指出存在行为关联与错误关联现象。这些结果源自特定实验，无法对所有智能体团队做出最终结论；而且其脆弱性检测对比在范围和资源使用上存在差异，因此原始输出数据总览无法单独体现协调作用所带来的影响。
存在反例。Anthropic对其研究系统的工程化描述指出，并行研究能够带来收益，并说明了那些包含目标、输出格式、工具指引及边界条件的任务。该描述还提到了更高的资源消耗，并警告了涉及大量依赖关系的任务处理问题。这些表明应当认真对待任务分解，但并不能证明在共享代码库中，研究架构能够原封不动地应用于工程实践。
此处的提议涉及委托任务与已确认任务之间的界限问题。明确划定这一界限是否值得付出相应成本，还有待验证。
围绕依赖关系来设计任务
对于分页功能的变更，首先由产品负责人确定期望的行为，再由API负责人批准相关接口。假设该接口使用next_cursor字段，其中null表示最后一页。之后API和客户端代码都可以基于同一版本进行开发，而验收测试则用于验证合并后的结果。
以下的YAML文件展示了客户端代码的接口规范示例。其中的路径、版本名称及校验标识仅用于演示，并非标准格式，也不属于任何框架的API组成部分。
task_id: pagination-client-17
objective: Fetch successive pages using next_cursor; stop at null.
inputs:
repository:
ref: product-repo
revision: base-42
requirement:
ref: pagination-behavior
revision: r3
interface:
ref: api/pagination.yaml
revision: r7
scope:
writable:
- client/pagination.ts
- tests/client/pagination.test.ts
non_goals:
- interface_changes
- api_changes
- deployment
deliverable:
- patch_against_base-42
- check_results_bound_to_patch_and_input_revisions
acceptance:
checks:
- client-pagination-unit
- pagination-api-client-e2e
owner: product-maintainer
policy_ref: client-worker-v2
failure:
stale_or_conflicting_input: stop_and_report_to_owner
missing_evidence: return_incomplete
authority_required: request_owner_decision
max_attempts: 2
exhausted: return_unaccepted_to_owner
这些检查名称必须对应到运行器所控制的注册表中的实际命令和断言。在本例中，它们分别代表针对光标处理的单元测试，以及针对实际候选 API（包括结束时的 null）对多个页面进行的端到端测试。客户端工作进程可以自行运行单元测试，而集成运行器则在两个补丁都存在时生成综合验证结果。
同样，policy_ref仅用于指定策略名称。调度器需将已批准的分配任务绑定到经过身份验证的工作进程，并在该工作进程无法编辑的配置中查找对应策略。未知的参考标识或对更严格策略的请求必须导致验证失败，且修改 YAML 文件绝不应授予额外的访问权限。
将工作次数限制为两次是一种局部设计选择，旨在控制修复循环的规模，但与可靠性无关。由负责人设定的有限执行预算可确保任何单次尝试都不会无限持续。
结构化任务并非授权边界。YAML可以描述预期的范围，但运行时仍需强制执行该范围。
让契约得以实现的步骤路径
在各个工作节点周围存在着一系列步骤。这里的调度工具仅仅是用于启动工作节点、协调其工具并记录相关事件的软件。
- 审批依赖项：产品负责人和API负责人需对需求及接口进行确认。
- 验证任务分配：任务创建者需提供契约及确定的修订版本。
- 按照既定策略进行调度：调度器会启动独立的API工作节点和客户端工作节点。
该任务可以由人类或其他智能体来完成。随后会进行两项检查：确定性验证器会确认结构正确且所有引用都能正常解析，而负责人员则会确认文本确实反映了产品需求。之后调度器会等待所有依赖项获得批准，加载固定的输入数据，并在各自范围内启动相应的工人进程。
有四个问题需要分别处理。模式有效性用于检查所需字段是否存在且格式正确；语义充分性则用于判断分配的内容是否对应正确的任务；权限执行机制用于确认工作人员是否不会越权操作；结果验证则用于判断最终产物是否符合要求。结构上有效的文档仅能回答第一个问题。
为确保执行力度，可写入路径列表必须成为真正的运行时限制，并通过集成阶段的文件变更检查来加以支撑。Shell访问权限绝不能为绕过文件或网络控制提供另一条途径。单独的检出机制虽然可以将不同提案分开，但其本身并不构成授权边界。
GitHub在9月9日发布的关于权限管理的公告中，说明了那些被集中阻止、需要审批或已被允许的操作，同时明确了工作区设置无法放宽的各类限制。其在“代理工作流”相关文档中描述的架构则体现了隔离执行以及分阶段、经过审核后的写入操作。这两者都属于强制机制的示例，但都无法证明这种授权设计能够提升交付效率或确保变更的正确性。
合并结果的归属问题
在分页功能的示例中，集成运行器会在一个临时候选工作区中合并API和客户端的修改方案。它会检查权限范围，验证输入的修订内容，并针对该候选工作区运行已注册的验收检查。随后，验收负责人会查看相关证据，并对那些检查无法决定的问题做出产品层面的判断。
独立验收意味着执行任务的工作者无法独自决定标准与证据。端到端的断言和固定装置均不受工作者的写入权限影响，且结果会与候选者摘要相关联。验收过程可结合确定性检查与人工维护人员，也可选择使用另一款大型语言模型。将某个模型命名为“监督者”并不会赋予其权威性，也无法使其判断结果更可信。
只有获得授权的所有者才能修改验收标准，且必须记录更改原因并生成新的任务修订版本。执行代理可以提出修改请求，但不得将失败的测试从测试套件中遗漏，也不得在完成一页后便将分页状态定义为已完成。
最终，经过授权的集成者会通过已设置的受保护合并路径来提交被接受的候选版本。该接受记录会明确标注具体的候选版本及其所覆盖的输入修订版本。如果目标分支在集成之前就有所进展，那么该候选版本需要被重新构建，并首先根据新的基准进行再次检查。
出现冲突的输出结果会返回给负责处理该争议边界的人。即便两种接口看似可行，它们依然属于不兼容的接口；因此在相关责任人做出选择之前，无论哪个方案先出现，都不会自动成为共享的标准定义。
故障处理也应纳入同一工作流程
这些情况都应单独在分页式工作流程中进行测试，明确预期的响应结果以及负责执行该规则的角色。
当两名开发者同时尝试修改该接口时，调度器会拒绝出现重叠的所有权情况，而运行时限制则会阻止未经授权的编辑。集成系统会拒绝任何超出其指定范围的补丁，具体的修改请求则由接口所有者来决定。
如果在工作进行过程中接口版本发生了变化，依赖关系检查会将该提案标记为过时。所有者需要决定是否根据新版本重新提交该提案，而集成系统也可能不会接受为旧版本收集的检测结果。
当出现看似合理的代码却没有相应证据时，验收机制会将其记录为不完整状态。只有经过信任的运行程序执行了必要的检查后，才能给出确定的完成状态信息，单凭主观判断无法替代实际检测结果。
当工作者在半途停止时，安全带机制会记录此次中断，并将未完成的提案单独保存。在开始替换工作之前，旧的尝试会被撤销，以避免其日后提交已被接受的结果。
如果重试可能导致相同的预览环境被创建两次，外部动作适配器会首先处理之前的请求。在提供方支持去重功能的情况下，会使用稳定的操作键，而那些仍不确定的效果则会交由负责人审核。
如果集成需要工作者不具备的权限，工具策略会阻止该操作，并将请求发送给相应的负责人。在该决定下达之前，该提案将保持未被接受的状态。
预览环境场景是该示例的可选附加组件，由集成服务负责管理，其部署工作不在客户端处理器的职责范围内。一个操作键用于指定所有重试次数的统一目标效果，尝试标识符则用于区分不同的执行实例，而且重试时不得仅为应对模糊的响应而创建新的操作。
Temporal早期的Agent Harness方案描述了围绕内部代理循环的持久化执行与控制点，以及相应的恢复和等待机制。这只是一个仍在发展的供应商项目，并不能作为独立的对比依据。对于外部操作而言，仍需要针对不同提供商实现去重或对账功能，因为仅靠持久化编排无法在任意服务中确保恰好执行一次的效果，而且Temporal自身的重试文档也要求在重试时进行下游重复检测。
每次修复都会消耗既定的尝试次数和资源预算。一旦这些资源用尽，工作流会返回一个未被接受的结果，并附上相关证据及负责人的姓名。对于需要升级处理的任务，也必须设定截止时间或取消方式，以避免责任在被搁置的对话中丢失。
合同可能使错误的工作正规化
成本过高是最主要的反对理由。当单个开发人员负责修改某个独立功能时，问题描述加上现有的测试往往已足以实现足够的范围控制与验收标准。对于一次性使用的原型或低风险的独立研究任务，可能只需要明确的指令即可。仅仅为了给这类安排重新贴上合同标签而建立专门的合同服务是毫无意义的。
合同也无法创造原本不存在的产品意图或模型能力。糟糕的分解方式依然会导致问题，相关错误会持续存在，而用于判断输出是否正确的测试或评估机制也会存在缺陷。假如端到端测试重用了客户端有缺陷的模拟对象，那么其通过的测试结果就会完全掩盖原有的故障。
正因如此，这种设计值得与更简单的方案进行比较，包括单一智能体或确定性工作流。关键在于额外的协调机制能否提升输出质量，或真正控制当前工作负载所面临的风险。
如何进行测试
针对这一方案尚未开展新的实验。有三种配置值得比较：单一智能体（A）、根据角色分配的多智能体（B），以及使用明确委托合同及上述流程的多智能体（C）。
公平性要求为A、B和C提供相同的任务信息与验收标准、可比较的工具与安全限制、一致的初始环境以及统一的资源预算。B和C共享模型与工作者数量，而A在可行的情况下也会使用相应的模型。本研究的核心变量是任务分配与协调机制，不得存在额外的功能要求或隐藏条件。
B应保留常规的安全措施和清晰的任务描述。如果其自然形成了明确的交接协议，应记录该行为而非加以禁止。需公开真实的配置，以避免比较变成用经过优化的实现去对比刻意设计的薄弱基准。
选择能够体现真实场景组合的任务：有些任务包含独立的部分，有些存在顺序依赖关系，还有些需要多个工作节点共享接口或资源。测试会在重置后的环境中以随机顺序重复进行，普通任务与刻意注入的故障情况会被分开处理。经过初步测试后，配置将被固定下来，留出的特殊任务用于实际对比，并且会根据不同的依赖结构来报告不确定性。
Anthropic的评估方法会将文本输出与它所处环境的状态区分开来，同时会对模型及其配套工具进行综合评估。这才是正确的衡量标准：在整合后的环境中分页功能是否正常？仅仅有三个智能体宣布任务已完成并不能说明任何问题。
有三种主要衡量标准：被接受的端到端结果、每个被接受结果的总成本，以及从开始到被接受所经历的时间。成本包括失败的试验、协调工作、重试次数、审核费用、准备工作以及合同撰写成本。初始设置费用会单独列出，重复性成本也会明确标注，同时会如实记录人工耗时。如果没有任何结果被接受，则应说明总支出和零次成功，而非显示一个看似合理实则具有误导性的单位成本。
除此之外，还需追踪集成失败、重复工作、过时输入导致的失败、人工干预情况、范围违规问题，以及被标记为已完成却遭拒绝的结果。尝试过的违规行为与实际成功的违规行为会分别记录，未完成的试验和超时情况也会保留，这样就不会因为快速成功的案例而掩盖长时间的失败问题。
正确地拒绝过时的补丁能够证明控制机制的有效性，但除非在预算范围内得到有效结果，否则该产品任务仍视为失败。早期的试点结果仅能指示方向。如果合同会增加成本，却无法带来更好的成果或显著降低风险，那么对于这类工作量而言，明智的做法是放弃使用这些合同。
从可检查的交接流程开始
一个合理的起点是选择一个现有的工作流，其中包含两名工作人员以及一名指定的结果验收负责人。集成测试仍不在工作人员的控制范围内，在扩大范围之前，每个故障场景都需要单独进行测试。可以给编码人员发送如下简报：
Add the minimum delegation contract to [WORKFLOW].
Acceptance owner: [OWNER].
Preserve existing safety boundaries.
1. Inspect current delegation, inputs, permissions, and acceptance.
Exit: map who assigns, executes, checks, accepts, and commits.
2. Identify missing boundaries; reuse existing issues and checks.
Exit: owner-approved scope, revisions, deliverable, and criteria.
3. Wire the minimum contract into dispatch and result handling.
Exit: references resolve; proposals cannot accept themselves; unauthorized operations are blocked by the actual runtime.
4. Exercise valid and invalid handoffs in isolated fixtures.
Exit: demonstrate acceptance, conflict rejection, stale-input detection, missing-evidence rejection, interruption recovery, bounded retries, and authority escalation. Mock external effects.
5. Report changed files, commands run, outcomes, and remaining gaps.
Exit: distinguish implemented controls from unverified behavior.
不得更换编排平台或修改无关的工作流程，亦不得发布、部署内容或扩大权限范围。
API、客户端及测试仍需依赖功能完备的工作者。变化仅在于围绕它们的运行规则。在整体工作被视为完成之前，必须明确每项贡献的具体要求、谁有权限接受它，以及无法被接受时该如何处理。职位名称无法界定这些界限。