Gartner 报告 multi-agent 咨询量暴增 1445%。每个人都在谈 CrewAI、LangGraph、A2A 协议。但没有人讲：当你真的组建了一个 12 agent 团队，日常协作到底是什么样的。
框架给你架构，不给你组织
CrewAI 的文档会告诉你怎么定义 agent 角色、怎么串联 task、怎么设置工具。
但它不会告诉你：
- 可乐（设计师）做视觉审查时，说”摆件有水印”——实际上没有。怎么防止这种误判？
- 芋泥（架构师）拆任务时，手痒自己写代码——导致其他任务的调度被阻塞。怎么约束？
- 三个 agent 同时给奶茶（PM）发审查请求——奶茶上下文窗口溢出。怎么排队？
这些不是框架问题。这些是组织设计问题。
角色不是 Prompt，是知识库
V1（3/29）：一句话角色描述
你是架构师，负责系统设计和代码审查。效果：agent 知道自己”是”架构师，但不知道架构师”怎么想”。输出的架构决策正确但泛泛——没有判断力、没有取舍、没有”根据 Fowler 的演进式设计原则，这里不应该过早拆分”。
V2（4/10）：ANTI-PATTERNS 收窄边界
OPC 文章启发：给每个 agent 定义”不该做什么”。
- 奶茶：不越界到技术/视觉，不做空洞分析
- 可乐：不越界到代码/产品逻辑
- 芋泥：不越界到视觉/产品，review 不能只看架构不看细节
- 汤圆/饺子：不越界到架构决策/产品/设计
- 牛奶：不越界到修代码/产品/设计判断
效果：比 V1 好。agent 不再随意越界。但输出质量仍然是”通用水平”。
V3（4/14）：领域专家 Skill（78 文件，924KB）
Coraline 分享了 buffett-skills 项目后提出的方向：不是让 agent 抽自己的经验，而是把现实世界顶级专家的思维框架给 agent 用。
一天之内完成 8 套 skill，每套融合 2-3 个权威知识源。芋泥加载 Martin Fowler + Uncle Bob + Google SWE Book。奶茶加载俞军 + Cagan + 张小龙。
效果：输出从”正确但泛泛”变为”有依据、有判断、有取舍”。
教训：角色定义经历了三次迭代——“你是什么” → “你不做什么” → “你用谁的方法论思考”。每一次都比上一次更有效。
上下文隔离是组织设计的核心约束
Agent 团队最大的架构约束不是算力，是上下文窗口。
每个 agent 的上下文窗口是有限的。如果协调者（PraestoClaw）同时做调度和写代码，两件事的上下文会互相挤占。3 月 29 日之前，PraestoClaw 经常在做竞品分析的时候漏回消息——因为分析任务占满了上下文。
由此产生的三条组织规则：
规则 1：协调者不写码
4 月 1 日 Coraline 定了硬规则：PraestoClaw 不再亲自执行任何长任务。只做拆任务、派工、验收、对话、决策。
这和人类团队里”技术经理不写代码”是同一个逻辑——但原因不同。人类经理不写代码是因为时间不够。Agent 协调者不写代码是因为上下文不够。
借鉴来源：OC Wiki 的 M2 管理模式——“主线程应保持越干净、越聪明、越能做好决策”。
规则 2：一人一活
4 月 4 日建立。每个 agent 同一时间只做一个任务。并行发生在 agent 之间，不在 agent 内部。
人类可以在等待 review 时切到另一个任务。Agent 不行——切换上下文意味着丢失当前任务的所有状态。
规则 3：MEMORY.md 只在主 session 加载
主 session（和 Coraline 的直接对话）加载完整 MEMORY.md。群聊、共享 session、和其他人的对话不加载。
这是安全考虑——MEMORY.md 包含组织内部信息。但也是性能考虑——不是每个 session 都需要 265 行的规则文件。
三方审查是组织设计，不是技术方案
为什么需要三个 reviewer 而不是一个更强的 reviewer？
因为视角不可替代。PM 看到的产品问题，设计师看不到。设计师看到的视觉问题，QA 看不到。QA 看到的功能问题，PM 看不到。
4 月 2 日的”22/22 全绿”误判证明了这一点：一个 reviewer 无论多”强”，都有盲区。
我们的三方审查不是串行的——三个 reviewer 并行审查，互不影响。串行审查的问题是后一个 reviewer 会被前一个的结论影响。
审查完成后，架构师（芋泥）做问题合并和去重。这个节点的价值不是”再审一遍”，而是消除重复工作——PM 说”首页加载慢”和 QA 说”API 响应超 3 秒”可能是同一个根因。
Agent 组织 vs 人类组织
| 维度 | 人类组织 | Agent 组织 |
|---|---|---|
| 角色定义 | 职位描述 + 文化浸染 | SKILL.md + 924KB 知识库 |
| 边界维护 | 社交规范 + 默契 | ANTI-PATTERNS.md（文件化硬约束） |
| 沟通方式 | 口头 + 文字 + 肢体 | 字段注释 + 产出物 + 统一 schema |
| 协调成本 | 会议 + 聊天 | L0 中转一切（瓶颈但也是保障） |
| 质量保证 | Code review 文化 + 社交压力 | 三方交叉审查 + pre-push hook + 协调者抽查 |
| 演化速度 | 周/月级（需要培训、适应） | 即刻生效（改文件 = 改行为） |
| 裁员/招人 | 周/月级 | 分钟级（增减 agent 只需改配置） |
最后一行是 agent 组织最大的优势：规则是文件，改了立刻生效。 人类团队建立新的工作习惯需要几周。Agent 团队改一个 AGENTS.md 就完成了。
但也是最大的风险：改错了也立刻生效。没有”试运行期”。
未解决的问题
跨 agent 状态共享
Agent 之间不原生共享上下文。汤圆改了 router.py 但饺子不知道——必须靠协调者中转。当并行任务数增加时，协调者变成信息瓶颈。
协调者的上下文窗口
所有信息汇聚到 PraestoClaw 一个 session。12 个 agent 的进度、问题、产出，加上 Coraline 的指令、群聊消息——上下文窗口压力巨大。精简（MEMORY.md 从 436 行到 265 行）缓解了部分问题，但根本矛盾没解决。
信任校准
何时信任 agent 的判断、何时抽查？目前靠经验——“审查结果一律抽查""agent 说完成不算完成”。但这些规则的粒度太粗。未来可能需要基于历史准确率的动态信任级别。
核心结论
Agent 时代的团队协作不是”把框架跑起来”就能解决的。框架解决的是 agent 之间怎么通信；组织设计解决的是 agent 之间怎么分工、怎么审查、怎么演化。
- 角色定义需要三层：你是什么 → 你不做什么 → 你用谁的方法论
- 上下文隔离是硬约束：不是 preference 是 constraint——违反就会崩
- 三方审查是组织设计：不是让一个更强的 reviewer 覆盖更多，而是让不同视角的 reviewer 各看各的
- agent 组织的最大优势是即刻演化——但也意味着错误即刻生效
- 协调者是瓶颈——目前无解，只能通过精简上下文和分层规则来缓解
行业在关注”agent 能不能协作”。我们已经在回答”agent 协作后，组织管理怎么做”。