最近把多 Agent 阶段协作接到外部工作项上，最容易画出的流程是开发、评审、测试、回写完成。可“开发完成”这句话没有说明交付的是哪个版本，也没有说明下一阶段能相信哪些检查。
接收者如果还要翻完整聊天、找最新文件、猜批准范围，这次交接只传了消息，没有交付一份可接续的工作。我的设计把任务要求、执行资格、产出和验证关系放在平台记录里，成员围绕这些记录协作。
下面以修复一个筛选切换问题为例：用户快速从 A 切到 B，晚到的 A 响应覆盖 B。任务目标是交付一份可合并的修复包，不包括未经批准的生产发布。场景用于推演方案，不表示这些故障已经全部在线上复现。
多个成员分别承担什么
开发处理实现，验证独立读取产出并检查行为，协调者分派与汇总。协调者可以建议重做或补查，不能凭聊天中的结论绕过平台检查推进阶段。
这类分工是否值得采用，要和配置充分的单 Agent 比较。独立取证通常容易并行，修改同一接口与共享状态则需要频繁沟通。如果协调与合并消耗大于收益，串行工作流更合理，不必为了多角色而拆任务。
在这条修复链中，开发与验证的上下文可以分开，写入所有权却明确：开发修改自己的工作区，验证只读固定产出，集成由一个阶段持有。独立评审增加检查机会，不保证几个模型不会有共同盲点，所以确定性检查仍不可缺少。
集中协调也会有瓶颈。原始文件和证据不由协调者反复转述，成员直接读取受授权的固定引用。持久状态不放在协调者的聊天记忆里，它重启以后仍能从记录恢复。
任务要求需要固定版本
示例任务的验收条件是：B 的选择不被 A 的迟到结果覆盖；当前 B 查询失败时显示 B 的错误；旧请求不能结束新请求的 loading；已有正常筛选行为保持兼容。
这些条件与允许修改范围构成任务说明版本。开发、验证和批准都引用同一版本。外部工作项改了标题或补了要求，平台计算变更影响；影响验收或授权范围，就暂停旧流程并重新确认，不能让两位成员各读各的最新描述。
外部评论与标签属于输入数据，不能因为写着“已批准”就允许执行。可信身份的用户动作生成批准记录，绑定任务要求、动作、环境与资源范围。机器账号能改标签，也不能代表某个人同意发布。
任务、阶段和尝试各有记录。任务保存目标与当前阶段，阶段固定输入与验收，尝试记录具体执行者、代次、租约和结果。一次失败不会把之前的记录覆盖成最终成功。
一次交接提交哪些内容
平台采用下面的内部结构，具体字段不属于通用协议标准：
type Handoff = {
handoffId: string;
taskId: string;
taskVersion: number;
stageRevision: number;
attempt: {workerId: string; epoch: number};
fromStage: string;
toStage: string;
artifact: {ref: string; digest: string; baseRevision: string};
evidence: Array<{ref: string; artifactDigest: string; check: string}>;
unresolved: string[];
approvalRefs: string[];
};handoffId 用于去重，taskVersion 与 stageRevision 固定要求和前置阶段，attempt 证明哪次执行提交。artifact 指向不可变文件及基线，evidence 说明对哪一版做了什么检查，unresolved 保存缺口，approvalRefs 对应必要授权。
字段齐全只说明结构完整。产出必须实际可读，摘要必须一致，证据属于同一版本，提交者仍有资格，必要批准仍有效，平台才接受交接。检查记录写“测试通过”，却没有执行对象与证据，不能替代这些条件。
完整聊天保留作排查，不默认传给所有成员。下一阶段得到任务要求、关键决定、固定产出与必要证据；缺什么按引用补取。只发摘要容易抹去限制，复制所有历史又会夹带过时讨论与无关指令。
工作区隔离和版本合并解决不同问题
开发尝试使用独立工作区，记录基线与修改范围。两个成员可以处理独立模块，但共享接口要有共同约定。目录隔离防止互相覆盖文件，不能保证合并后的语义兼容。
示例修复包包含代码变更、基线、测试与必要说明。开发发布为产出 A 后，验证读取 A，不读取一个仍在变的目录。发现缺口就针对 A 记录失败，开发创建新尝试和产出 B，不能继续修改验证正在使用的 A。
合并进入集成环境以后，整体验证重新执行。各自分支通过的结果不自动代表合并版本通过，验证证据始终关联实际产出摘要。
无权读取的依赖、缺失工具和超出改动范围也作为具体失败返回，不让成员靠搜索其他路径绕开约束。
失联尝试怎样重新派发
租约反映执行者是否持续报告，epoch 反映当前哪一代拥有提交资格。租约过期不证明进程已停止，新的尝试开始后，旧执行者仍可能回来。
领取任务提升代次，续租与提交都比较执行者、代次、阶段版本和有效租约，时间使用权威时钟。旧结果可以存入诊断记录，不能改变当前状态或当前产出。
数据库拒绝旧结果，也挡不住已经发出的外部请求。工具入口检查当前资格；下游支持 fencing 时，采用受保护资源自身的单调令牌。任务 epoch 只约束本任务的提交，不能冒充跨任务共享资源的全局顺序。其他动作使用稳定操作键，并保留实际结果核对。
| 情况 | 恢复行为 |
|---|---|
| 读取失败，确认无副作用 | 按预算创建新尝试 |
| 进程失联但可能仍在写入 | 隔离并核对，不立即重复派发 |
| 外部动作已确认生效 | 补齐记录，不重做动作 |
| 明确未生效 | 使用原操作键按规则重试 |
| 无法确认结果 | 保持 outcome_unknown，交给人工 |
重试不是把旧尝试改回运行中。新尝试保留与前一轮的关系，失败证据继续存在，已用预算不被清零。
验证拒绝的是具体产出
验证读取固定版本，逐条检查任务的行为条件。针对筛选修复，主动制造 A 晚到、B 失败、取消失败和快速切换，检查状态而不只读开发总结。能够自动测试的使用确定性测试，视觉与业务含义由适当评审补充。
失败记录给出产出摘要、复现条件、实际与预期差异。返回开发时不随意增加任务目标，新需求另行更新说明版本。这样返工有明确对象，不会变成永远在追加改进的讨论。
通过后固定验证结果。任务说明或产出变更，原证据失效到什么范围由检查依赖决定，不能把 A 的通过回执套给 B。
若同一个模型既实现又复述自己为何正确，独立性很弱。验证成员至少读取真实产出与结果；多位成员意见一致也不是最终依据，裁决仍回到验收条件和可检查事实。
人工批准约束外部写入
只读分析和工作区内修改可以在委托范围连续执行，合并、发布或对外通知按策略检查批准。批准内容包括目标、参数、环境、任务版本及期限，任何实质变化都要重新判断适用性。
执行前检查用户是否被撤权、批准是否过期、资源状态是否改变。一次性批准与操作记录在同一事务中消费，避免两个执行者都拿同一条批准写入。
外部请求超时不恢复成未消费。对方可能已成功，恢复批准再执行一次会扩大影响。进入核对流程以后，确认结果或明确安排补偿；补偿也有自己的授权，不能因为在恢复任务就默认允许删除和撤销。
阶段完成和通知保存到同一事务
交接接受时，数据库共同保存交接记录、阶段变化和待发送事件。投递器随后通知验证成员。上传文件在事务外完成，数据库仅接受已经可读的固定引用，不为网络上传长时间持锁。
发送成功后确认丢失，事件仍可能重复。接收端按 handoffId 去重，并检查当前任务版本与阶段。Outbox 处理漏发窗口，业务副作用仍依赖操作键和核对，不能承诺所有外部接口恰好执行一次。
内部验收完成、外部工作项回写超时，只进入待同步。恢复时补写或查询外部状态，不退回开发重新修一遍。外部接口无法识别上次操作，就保留未确认项给用户处理。
一次修复怎样结束
任务版本 3 产生 A，验证发现问题，开发新尝试提交 B。A 的迟到通过回执不能推进任务，B 重新验证。验证通过后的通知发两遍，只建立一份有效阶段关系；外部回写超时，只补同步，不重跑开发。
这条任务以可合并修复包为交付范围，所以完成条件是：B 可读取且摘要固定，规定检查针对 B 通过，未解决事项按约定处理，相关写入有确定结果，用户能找到交付位置与证据。生产发布属于另一项获准动作，不能在这里偷偷执行，也不阻止一个本来只要求修复包的任务结束。
状态未知的动作保留明确待处理项。取消会阻止新动作，执行资源确认结束后才释放预算；已经交付的文件和已生效业务操作不会被取消状态抹掉。
协作是否划算，用同一批任务比较
比较单 Agent 与多 Agent，采用同一验收条件，记录完成率、人工介入、总等待、运行成本与重做次数。协调、上下文传递、合并和恢复也计入，不能只统计成员各自说成功的次数。
拆分有效，应当体现在任务真正完成得更好或更快，并且成本可接受。没有这个收益，就缩减角色或回到固定工作流。对我来说，可扩展的协作由可验证的交接构成：每个阶段知道接收哪项要求、哪个版本，失败交给谁处理，什么证据足以结束。