模式矩阵/模式白皮书/Collaboration
ADPS Agent 设计模式白皮书 · 模块总纲
协作模块 · 多个参与者怎样共同完成一项工作
任务、上下文、权限、证据和责任在参与者之间的流动方式。
协作带来的收益通常来自任务规模、专业分工、审查独立性或故障隔离。参与者增加以后,交接损耗、资源冲突和目标漂移也会一起增加。协作模块负责说明这些边界,以及不同模式如何组成一套可运行、可验收的系统。
三类协作关系
| 关系 | 典型问题 | 主要工程对象 |
|---|---|---|
| Agent 与 Agent | 怎样拆分、并行、交接、复核和隔离 | topology、role、artifact、handoff、workspace、trace |
| 人与 Agent | 人在何处给目标、补信息、批准、接管和验收 | intent、interrupt、checkpoint、approval、acceptance |
| Agent 环境中的人与人 | 决策与责任怎样被下一位成员和 Agent 继承 | RFC、ADR、runbook、decision record |
第三类关系经常留在会议、聊天和个人经验里。会影响后续判断的决定、证据和边界应进入可版本化资产;没有必要把全部聊天原样写进仓库。
设计语义与运行原语
复杂协作在运行图上大多可以分解为串行、并行和路由。它们描述边怎样连接。循环、层级和编排保留更高层的控制语义,说明谁持有全局状态、怎样复验、谁负责重新分派与最终验收。
层级委派可以编译成路由、并行调用与聚合;对抗评审可以编译成生成、评审、裁决和条件回路。低层边相似,高层责任并不相同。ADPS 将从设计模式到运行原语的过程称为拓扑降阶。运行时应保存 design_pattern、角色、合同和验收引用,便于事故后还原设计意图。
协作模式的四层结构
| 层次 | 条目 | 设计范围 |
|---|---|---|
| 协作关系 | C1 层级委派、C2 扇出聚合、C3 对抗评审、C4 交接链 | 谁与谁协作,全局状态和责任在哪里 |
| 协作约束 | C5 子 Agent 隔离 | context、工具、凭证、预算、工作区和失败传播 |
| 分布式候选 | C6 编舞 | 没有中央 Orchestrator 时的事件协作 |
| 实现机制 | Hook、Skill、事件总线、解释器、Agent 协议 | 为多个模式提供运行能力,本身不自动构成模式 |
订单系统可以在运行时由模型选择付款、库存和通知 Agent;只要一个解释器仍保存完整计划并汇总结果,它就是动态编排。只有当付款发布事件、库存和通知按各自本地规则订阅并继续发布,且没有节点掌握完整流程时,才进入 C6 编舞。分类取决于完整计划由谁持有,与流程是否预先写死无关。
拓扑治理矩阵
| 运行结构 | 身份 | 权限流转 | 防护与质控 | 溯源 |
|---|---|---|---|---|
| 串行 | 每一跳说明代表关系 | 逐段授权,交接后回收 | 节点门禁阻止错误下传 | 线性责任链与前后状态 |
| 并行 | 分片角色与责任域独立 | 分片隔离,聚合默认只读 | 分支校验,汇聚总检 | 统一 trace ID 与子链路 |
| 路由 | 分支匹配身份和风险 | 高风险分支收紧权限 | 前置筛选与差异控制 | 路由依据与完整路径 |
拓扑说明控制怎样展开,不能替代授权与审计。一个发起人的长期凭证不应传给所有子 Agent。有效权限按用户、本次任务、Agent 角色、工具和资源范围逐层取交集。
交接合同
完整 conversation history 无法稳定表达已定决策、否决路径、可用权限和验收标准。一次可恢复、可追责的交接至少包含:
handoff_id: h_01K...
goal: 当前仍然有效的目标
from_role: requirements-agent
to_role: implementation-agent
artifacts:
- uri: artifact://spec/417
version: sha256:...
decisions:
- choice: 保留兼容接口
evidence: adr://23
rejected_paths: []
open_questions: []
authority:
allowed_tools: [repo_read, patch_write]
resource_scope: repo://service-a
acceptance:
checks: [unit_tests, contract_tests]
next_required: 可评审补丁与测试证据
交接合同转移目标、产物、决定、责任、权限和验收。接收方显式接受或拒绝,交接后回收上一段的临时权限。
同构、异构与跨 Session 协作
同一个 Session 中的主从 Agent 共享运行时,通信简单,仍要限制子 Agent 继承的上下文和工具。多个 Session 或 worktree 并行时,文件隔离不能消除需求编号、配置、数据库和外部环境的竞争;调度前要声明写入冲突域。
异构 Agent 常见两种连接方式:上层中央协调,或通过能力发现与消息转发进行分布式协作。前者容易控制,后者便于独立演进。两者都需要能力描述、身份、状态、超时、幂等和可追踪的交接协议。
独立评审与反馈回路
生成者与评审者分离可以减少自评偏好,也可能切断执行反馈。评审产物需要包含依据、风险、适用条件和复验要求;执行阶段发现的新约束进入证据链,并返回下一轮评审。C3 给出条件,C4 传递条件,X1 与 X2 验证实际结果。
Hook 组合
Hook 可以承担四种职责:推动阶段流转、执行治理裁决、记录观测事件、保存现场并触发恢复。它是确定性执行位置,具体职责由组合决定。G5 保留历史编号,治理页面聚焦不可绕过的执行点;跨模块用法见Hook 组合。
从开放探索到生产固化
开发环境允许临时拆任务与尝试拓扑。测试和预发布逐步固定 Agent、模型、工具、策略与主要运行图;生产只在评测过的范围内保留动态性。版本变化后重新评测,不能沿用旧证据。
什么时候拆成多个 Agent
- 长任务使单一 context 膨胀,早期细节干扰当前判断。
- 子任务需要不同能力、工具、数据或权限。
- 高风险产物需要结构独立的复核。
- 任务可安全分片,墙钟收益高于通信与聚合成本。
一个 Agent 加清晰的 Skill 就能完成时,单体通常更稳。多 Agent 没有天然的成熟度优势。
验证指标
| 指标 | 观察内容 |
|---|---|
| 目标保持 | 多次交接后,产物是否仍满足原始目标与 non-goals |
| 交接损耗 | 决定、证据、权限或未决问题在哪一跳丢失 |
| 资源冲突 | 并行运行对文件、编号、配置和外部状态造成的冲突 |
| 聚合质量 | Gatherer 如何处理矛盾、重复、部分失败与证据等级 |
| 隔离效果 | Worker 失败或越权时,影响是否停在局部边界 |
| 协作开销 | 相比单 Agent 增加的 token、时延、费用和人工审查 |
研讨会记录
本总纲吸收了 2026-08-25 协作模块第一次研讨会。主持人:张海立、黄佳;核心研讨嘉宾:张栋、王伟。
阅读完整研讨记录 · 人与 Agent 的协作边界 · 抽象—还原
引用建议:ADPS,《协作模块 · 多个参与者怎样共同完成一项工作》,Agent 设计模式白皮书 v0.9,2026-08-26。
本页为公开评审稿。具名实践另见案例库;研讨中的内部实例采用脱敏表述。
溯源记录
- 来源记录
- 协作模块第一次研讨会(2026-08-25);Deep Agents 动态协作研究
- 来源日期
- 本页首次公开