夜雨聆风
如果让你设计"多个 AI 互相协作"的系统，你会怎么做？
我的Teamflow用的其实是比较朴素的DB存储消息, Agent接入我自己的MCP来query chat history然后stdin注入到当前Agent的上下文。
跟着这本书读到第 20b 章——讲 Teams 与多进程协作那一章——我才知道：
Anthropic 在 Claude Code 里做这件事，居然没用任何"现代"的通信技术。
他们用的是——文件。
队友的"邮箱"，是一个 JSON 文件
先看看 Claude Code 是怎么做"AI 团队协作"的。
它有一种功能叫 Teams——你可以创建一个团队—— 比如：
researcher@my-team —— 负责调研 tester@my-team —— 负责测试 leader@my-team —— 负责协调
四个 Agent 同时在跑（在不同的进程里）。
它们怎么通信？
每个 Agent 有一个"邮箱"——本质上就是一个 JSON 文件：
~/.claude/teams/{teamName}/inboxes/researcher.json
~/.claude/teams/{teamName}/inboxes/tester.json
~/.claude/teams/{teamName}/inboxes/leader.json
Agent A 想给 Agent B 发消息？
Agent A 把消息追加到 inboxes/B.json 文件里。
Agent B 怎么收消息？
它周期性读自己的 B.json 文件——把里面的消息处理一下。
就这。
我读完这段第一反应——
这不就是 1970 年代的 Unix 邮件系统吗？
不是 IPC、不是 RPC、不是消息队列、不是 WebSocket、不是 gRPC——
是文件。
为什么 Anthropic 选"文件通信"——四个理由
源码注释里有一句话总结这个反直觉的选择——
"Teams 的通信设计做了一个反直觉但务实的选择：用文件系统而非 IPC/RPC 做跨进程通信。"
为啥？四个理由——
理由 1：进程崩溃后消息不丢
传统消息队列、WebSocket、Redis pubsub——
消息存在内存里、连接里。 某个进程崩了——重启之后——对它发出去的消息没法接到——丢了。
文件不一样——
消息持久化在磁盘上。 进程崩了重启——inbox.json 还在那儿——读一下就知道之前收过啥。
理由 2：直接 cat 看消息
如果用 Redis pubsub 做 AI 团队通信。 需要调试—— "Agent A 这个时候到底有没有收到 B 发的那条消息？"
没法直接看。 得：
起一个 Redis 客户端 订阅相应的频道 重新触发那次场景 看监听到啥
至少 30 分钟——而且很多时候没法重现。
如果是文件——
cat ~/.claude/teams/my-team/inboxes/agent-a.json5 秒搞定。
调试 AI 系统这件事——透明性比性能重要 100 倍。
理由 3：Lockfile 解决并发
多个进程同时往一个文件写——会冲突啊？
源码用了 async lockfile + 指数退避——
写入前申请锁 失败了等 5-100 ms 最多重试 10 次 都失败了报错
简单、可靠、没坑。
而且 lockfile 是文件系统原生支持的——不需要额外服务。
理由 4：对 Agent 崩溃友好
AI 应用最大的特点——Agent 经常崩。 模型 API 502 了、上下文超了、超时了、内存溢出了—— 都是常态。
文件邮箱系统对崩溃天然友好——
A 挂了——不影响 B/C/D 给 A 发消息（消息累积在 A 的邮箱） A 重启——读 inbox.json 就知道这段时间收到了啥 调度系统能看到 "A 长时间没读消息"——可以发告警
如果是 WebSocket——
A 挂了——其他人发的消息到 WebSocket 服务器——A 不在线——丢了 A 重启——不知道自己挂掉那段时间错过了啥
自动 Claim ——AI 调度的精妙设计
讲到通信只是 Teams 的一半——另一半是任务分配。
Claude Code 的任务分配机制让我看完叫绝——
Task 不是 Todo——是 DAG（有向无环图）节点：
{
id: string,
owner?: string, // 谁在做（空 = 没人做）
status: 'pending' | 'in_progress' | 'completed',
blocks: string[], // 这个任务阻塞哪些任务
blockedBy: string[], // 这个任务被哪些任务阻塞
}
自动 Claim 机制—— 每个空闲的队友定期扫描任务图——找"可工作的任务"：
可工作任务 =
status === 'pending'
AND owner 为空
AND blockedBy 中的任务都已完成
找到一个——抢占（claim）这个任务的 owner——开始干。
为啥这套设计妙？
源码里有一句金句——
"调度和推理分离——模型不需要在自然语言中判断
'哪个任务现在没被别人做'。
运行时先把候选工作缩到明确任务。"
什么意思？ 传统做法——主 Agent 用自然语言判断—— "嗯，task A 已经被 B 做了，task C 被阻塞着，那 task D 我可以做……"
模型推理这件事——贵、慢、可能错。
新做法——调度逻辑写成代码：
谁的任务、谁的阻塞——存在 JSON 里 "找可工作任务"——纯代码遍历——一毫秒搞定 模型只需要做"接到任务后怎么干"——真正适合 AI 的事
让 AI 干 AI 的事——让代码干代码的事。
这是工程上一个永恒的智慧——
能用代码解决的，别用 AI 解决。
队友不能派队友——平面结构的智慧
第三个让我服气的设计——
源码里写得很死——
"Teammates cannot spawn other teammates
— the team roster is flat."
队友不能派生其他队友——团队名册是平面的。
为啥？
直觉上多 Agent 系统就是树形结构——
主 Agent 派 Agent A A 派 A1、A2 A1 派 A1.1、A1.2 ……
听起来很灵活对吧？
实际上很难管：
一个 Agent 死了——它派的子 Agent 还在跑——孤儿进程 想中断整棵树——不知道树到底多深 调试某个深层 Agent 的问题——得追踪 5 层调用链
Anthropic 直接砍掉这套——
所有队友都是 Leader 的直接下属——
不允许嵌套。
这种设计叫——平面结构。
它的好处——
中断 Leader——所有队友立刻可控（最多 N 个，没有未知深度） 调试某个队友的问题——只用看一层关系 任务分配——Leader 一个人说了算——不会有奇怪的派系 永远不会出现"无限递归派生"的事故
简单的拓扑——简单的故障模式。
权限同步——文件夹也能做
最后一个设计——权限怎么同步。
队友 A 想跑一个危险命令—— 按权限系统的规则——这事得让用户审批。
但队友 A 是在自己的进程里跑——它没法弹个对话框给用户。
怎么办？
Claude Code 的解法——还是文件夹：
~/.claude/teams/{teamName}/permissions/
├── pending/ # 等待审批的请求
│ └── req-xxx.json
└── resolved/ # 已处理的请求
└── req-xxx.json
流程是这样的——
1. 队友 A 遇到危险命令
2. 创建 SwarmPermissionRequest
3. 写入 pending/{requestId}.json
4. 在 Leader 的邮箱里写一条消息："有审批请求"
5. Leader 看到 → 弹对话框给用户 → 用户决定
6. 写入 resolved/{requestId}.json
7. 队友 A 轮询 resolved/{requestId}.json → 获取结果 → 继续
整个流程——没用任何 IPC——纯文件操作。
这套设计的妙处——
哪怕队友 A 在远程机器上——只要 NFS 共享文件夹就能跑 Leader 死了重启——pending/ 里的请求还在——继续审 用户能直接 cat pending/*.json 看队友请求了啥——透明
所有危险操作——人类还是终审。
文件夹只是"消息载体"，不是"决策者"。
这一章给我的最大启发
读完这一章我有一个反思——
我们这个时代的工程师太喜欢"复杂的解决方案"。
要做多进程通信？必须用 gRPC。 要做消息队列？必须用 Kafka 或 Redis Streams。 要做协调？必须用 Zookeeper 或 etcd。
但这些复杂工具的代价是什么？
多一个依赖——多一个故障点 多一份运维——多一份调试痛苦 多一份学习成本——团队入职时间翻倍
Anthropic 用文件夹做 AI 团队协作——
不是因为他们没钱用 Redis——是因为：
文件持久化——崩了不丢 直接调试——cat 一下就行 天然支持远程——挂个 NFS 就跨机器了 零依赖——文件系统是 OS 原生的
简单的设计，往往撑住更大的规模。
我现在写工具——每次想用复杂方案的时候——会问自己——
"用文件能做吗？"
很多时候答案是——能。
而且能得很好。
Part 6 进度
这是系列第 22 篇。 进入了 Part 6 的第二章——多 Agent 协作。
下一篇会讲 Ch20c——
Ultraplan：远程多代理规划——把 AI 团队从本地扩展到云端。
之后还有：
Effort、Fast Mode 与 Thinking 技能系统——从内置到用户自定义 插件系统——从打包到市场 89 个 Feature Flag 背后的产品路线图 跨会话记忆——AI 怎么"记住"之前的会话
