⚠️ 别和 Agent Teams（Anthropic 官方 feature） 搞混 本条目讲的是陈彬自己用 subagent 机制搭出来的多 agent 协作体系——Meta / Architect / Nightwatch 三角 + 按需调用的专科 subagent。 Anthropic 官方那个 experimental “Agent Teams” feature 陈彬完全没用。两个东西只是同名，机制和哲学都不同。
一句话
陈彬的多 agent 协作，不是一个”团队”，是一套”角色分工 + 文件通信”的 MD-based 系统——每个 agent 一个 md 文件，通过关键词触发，按场景用，彼此靠共享文件通信（不直接对话）。
为什么陈彬社群”用的极多”
陈彬本地至少跑这几层 agent：
全局层（~/.claude/agents/）：
- Meta（人类系统架构师）：看懂生命系统、设计 AI 扩展、做 PO3 与蓝图
- Architect（施工大师）：把 Meta 的蓝图变成可运行系统——agent md、skill 包、CLAUDE.md 配置
- Nightwatch（守夜人）：独立评估——Meta/Architect 产出完，他上来找盲点
- Scholar（全局学者）：跨项目知识编译 + 研究调度
- 等等
项目层（每个 workspace 自己的 .claude/agents/）：
- PK 里：Alfred、Sheep、Jung、Jarvis、Tyrion、Ken…
- AIBuilder 里：AI 学者（编译 raw → wiki）、AI 学习者（对话探索 → 素材项目）
- RL（做研究）里：Scout、Lens、Sentinel
每个 agent 都是一个 md 文件。关键词一触发，对应文件加载，Claude 就”变成那个角色”回应。
三个关键设计原则（从配置反编译）
原则 1：角色分工靠”触发词”，不靠”实时对话”
陈彬没有让一堆 agent 同时在线互相喊话。他的做法是：
- 说”Architect” → 读
architect.md→ 以施工大师身份回 - 说”Meta” → 读
meta.md→ 以人类系统架构师身份回 - 说”Nightwatch” → 读
nightwatch.md→ 以独立评估者身份回
同一时刻只有一个角色在台上。切换靠关键词，不靠多路复用。
这和 Anthropic 官方 “Agent Teams”（多实例同时跑、互相发消息）是完全相反的哲学。陈彬选的是”单人多面”，不是”多人同台”。
原则 2：跨角色通信靠文件，不靠消息总线
Nightwatch 协议里有一条硬规则（nightwatch.md:20-24）：
“我不看设计过程。不读 Meta 的推理链、Blueprint 的设计笔记、Architect 的思考过程。只看最终产出 + PO3 + 系统现状。”
意思：Nightwatch 和 Meta/Architect 的通信只通过”产出物”——他们不在对话里协商。Meta 产 Blueprint，Architect 产施工计划，Nightwatch 读这些落地的 md 文件来评估。
好处：
- 上下文隔离——评估者不被设计者的推理污染
- 可追溯——每次通信都留下了 md 文件
- 可重放——今天 Nightwatch 给的意见，明年回来看 md 还在
AIBuilder 内部的两个 agent 也是这个套路：AI 学习者不直接调 AI 学者，而是写 ai-xueze_pending.md（单向追加），AI 学者每周读一次这个文件消化。
原则 3：主协调靠人（陈彬自己），不靠 meta-agent
陈彬没有搭一个”总指挥 agent”去调度其他 agent。他自己就是那个总指挥——他决定什么时候叫 Meta、什么时候叫 Architect、什么时候让 Nightwatch 上场。
**为什么不让 AI 自动调度？**因为”什么时候该切换角色”本身是判断题——这是陈彬保留给自己的价值判断。
这呼应 Karpathy 的 program.md 方法论 里那句：判断 / 价值 / 方向 → 留给人，不交给 agent。
典型协作流（以 AIBuilder 本项目为例）
陈彬要建 AIBuilder 社群知识库时，流程大概是：
1. 陈彬（with Meta）
对话感知需求 → 画出系统图 → 写 PO3 → 写 Blueprint v1.7
输出 → Blueprint_v1.7.md
2. 陈彬（with Architect）
读 Blueprint → 分解 T1-T17 施工任务
建 CLAUDE.md / agent md / skill 包 / 目录结构
输出 → ~/AIBuilder/ 整棵目录
3. 陈彬（with Nightwatch）
Blueprint 和施工产出分别喂给 Nightwatch
Nightwatch 读 PO3 + 产出，不看推理，给"四透镜"评估
输出 → 盲点列表、未覆盖 Objective
4. Architect 改，再喂 Nightwatch 复审（循环）
5. 上线后运营期：
AI 学者 / AI 学习者（本项目内 subagent）常态运行
陈彬每周一次策展，调 AI 学者编译 → 审 → 发布
每一步切换的触发都是陈彬说一句话。没有自动化的 agent 编排器。
和 “Agent Teams（官方 feature）” 的对照
| 维度 | Anthropic Agent Teams | 陈彬式多 Agent 协作 |
|---|---|---|
| 运行形态 | 多个 Claude 实例同时在线 | 同一时刻一个 agent 在台上 |
| 切换机制 | 自动 spawn teammate | 人说关键词手动切换 |
| 通信机制 | 实例之间直接发消息 | 只通过文件（md）间接通信 |
| 上下文 | 每个 teammate 独立 context | 每次切换就是一次重加载 md |
| 主协调者 | 共享任务列表，自协调 | 人（陈彬本人） |
| Token 成本 | 高（多实例并行） | 低（串行，且只加载所需 md） |
| 心智负担 | 需要信任自协调质量 | 陈彬自己要判断什么时候叫谁 |
结论：两套完全不同的哲学。陈彬这套更像”角色剧本切换 + 文件留痕”，不是”团队协同”。
这套能不能照抄
可以。前提是：
- 你能先写出每个角色的 md——写不出 “Architect 应该长什么样”、“Meta 应该长什么样”，agent 就立不起来。这要求你先把自己的工作流想清楚。
- 你愿意当那个总指挥——不要幻想 AI 替你调度 AI。你得亲自按需叫人。
- 你接受文件通信的节奏——不是实时协作。是 A 干完留下 md，B 下次上来读 md 接着干。这比”多人聊天”慢，但每一步都留痕，且不会污染彼此 context。
不适合的场景：需要 < 1 秒响应的实时决策（那种得用 Anthropic 官方那套或其他编排框架）。
陈彬视角（占位——可扩）
- 为什么这套比官方”Agent Teams”更扎实：因为它是被逼出来的——陈彬一开始只有一个 Claude Code 窗口，要管 PK + DG + CR + AIBuilder + RL 五六个系统。要么分心要么分角色。分角色活下来了。
- 一个反直觉的观察：agent 越多，反而越需要人手动协调——自动协调的幻觉只在 agent < 3 时成立。到了 10+ agent，你必须自己当 CEO。
- 这条日后陈彬可以亲笔展开：“陈彬是怎么在两年里从 0 agent 长到 20+ agent 的”——有故事。
关联
- 紧邻：Subagent 完全解读（本条目大量使用 subagent 机制）
- 对照：Agent Teams（Anthropic 官方 feature）（不要搞混）
- 前置：什么是 MD-based System · Agent vs Skill vs Workflow
- 相关：raw → wiki 知识沉淀机制（AIBuilder 内部的 AI 学习者→AI 学者就是这套通信的实例）
needs_sources（明确待补）
- 陈彬用这套失败的案例（目前读到的都是成功面）
- 其他好朋友的多 agent 用法（社群里有没有人自己长出不同形态）
- 更大规模（50+ agent）时这套是否仍然成立