AI 团队怎么协作的?居然靠＂文件夹通信＂

如果让你设计"多个 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.json

5 秒搞定。

调试 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——是因为：

1. 文件持久化——崩了不丢
2. 直接调试——cat 一下就行
3. 天然支持远程——挂个 NFS 就跨机器了
4. 零依赖——文件系统是 OS 原生的

简单的设计，往往撑住更大的规模。

我现在写工具——每次想用复杂方案的时候——会问自己——

"用文件能做吗？"

很多时候答案是——能。

而且能得很好。

Part 6 进度

这是系列第 22 篇。 进入了 Part 6 的第二章——多 Agent 协作。

下一篇会讲 Ch20c——

Ultraplan：远程多代理规划——把 AI 团队从本地扩展到云端。

之后还有：

• Effort、Fast Mode 与 Thinking
• 技能系统——从内置到用户自定义
• 插件系统——从打包到市场
• 89 个 Feature Flag 背后的产品路线图
• 跨会话记忆——AI 怎么"记住"之前的会话