多 Agent 组织化设计：角色体系与协作协议
一、角色体系（Role System）
1. 本质定义
角色体系的本质：
给每个 Agent 颁发一张“职业执照”，明确：
- 能做什么（职责边界）
- 不能做什么（权限约束）
- 积累的经验归属谁（记忆归属）
2. 为什么必须有角色体系
在没有角色体系时，常见做法是：
所有 Agent 都是“通才”
表面灵活，实际会在生产中必然崩溃。
3. 通才模式的三大崩溃
崩溃一：Context Window 无法承载通才
表现
- 所有能力堆在一个 Agent 上
- Skill / SOP / 知识库不断膨胀
- 调用效率下降，最终失效
本质
- 上下文资源有限
- 能力越多 → 注意力越分散
崩溃二：记忆混乱，无法积累
表现
- 不同角色的经验混在一起
- 无法复用历史决策
- 记忆变成噪声
示例
- 研发写单测 vs QA 写单测
- 决策逻辑无法统一复用
本质
记忆必须“方向性积累”，而不是“堆积”
崩溃三：决策风格冲突
表现
- 同一个 Agent 在不同决策中摇摆
- 输出不稳定
- 易被 prompt 引导
根因
- 缺乏稳定“价值观”（Soul）
示例
- 研发：效率优先
- QA：风险优先
- 产品：体验优先
→ 通才会出现“人格冲突”
4. 结论
多个通才 Agent < 少量专业化 Agent
核心原因：
- 上下文更干净
- 记忆更聚焦
- 决策更稳定
5. 角色体系设计核心
每个角色必须明确三件事：
1. 职责（Responsibility）
- 我负责什么任务
2. 权限（Permission）
- 我可以访问哪些数据 / 工具
3. 记忆归属（Memory Ownership）
- 我的经验存在哪里
- 是否可被他人使用
6. 角色体系本质总结
角色体系 = 能力隔离 + 记忆隔离 + 决策风格固化
二、协作协议（Collaboration Protocol）
1. 本质定义
协作协议解决两个独立问题：
1）状态共享（State Sharing）
谁能看到什么？
2）任务触发（Task Triggering）
谁告诉谁做什么？
2. 两大核心机制
1. 状态共享 → 公共工作区（Workspace）
特点
- 结构化数据
- 权限控制
- 可持久化
管理方式
- 由 Manager（调度者）定义规则
- 明确：
- 数据结构
- 可见范围
- 更新策略
2. 任务触发 → 消息系统（Message / Mailbox）
特点
- 解耦 Agent
- 异步执行
- 可追踪
核心能力
- 谁发送任务
- 谁接收任务
- 谁反馈结果
3. 没有协作协议的三大崩溃
崩溃一：上下文驱动通信 → 上下文爆炸
表现
- 所有信息靠 prompt 注入
- 上下文不断膨胀
- 最终溢出
崩溃二：硬编码流程 → 无动态能力
表现
- 固定执行顺序
- 无法根据情况调整
- 不具备真实“协作”
崩溃三：无持久化 → 结果不可复用
表现
- 执行结果无法共享
- 无法沉淀资产
- 每次从头开始
4. 协作协议设计模型
1. 共享工作区（Workspace）
解决问题
- 数据在哪里？
- 谁可以访问？
特点
- 结构化存储
- 权限隔离
- 状态可追踪
2. 消息系统（Message Queue / Mailbox）
解决问题
- 谁触发任务？
- 如何通知？
3. 消息状态机（关键设计）
解决两个核心问题：
- 不重复（Exactly-once / At-least-once）
- 不丢失（可靠传递）
5. 通知机制设计
1. 同步触发
- 实时执行
- 低延迟
2. 后台轮询
- 容错机制
- 防止遗漏任务
3. 推荐组合
同步触发 + 轮询兜底
6. 协作协议本质总结
协作协议 = 状态共享机制 + 任务触发机制
三、整体架构总结
1. 三层抽象
第一层：角色体系
- 定义“谁做什么”
第二层：协作协议
- 定义“怎么协作”
第三层：执行系统（Agent）
- 实际执行任务
2. 核心设计原则
- 能力必须拆分（避免通才）
- 记忆必须隔离（避免污染）
- 通信必须结构化（避免混乱）
- 状态必须持久化（避免丢失）
3. 一句话总结
角色体系解决“谁适合做这件事”，协作协议解决“他们如何高效一起做这件事”