摘要：把Claude Code、Codex、Kimi Code等终端智能体放进同一个办公室之后，多智能体系统开始面对任务分工、消息路由、共享记忆、代码隔离、成本预算和人工审批等组织问题。
同时启动十个 Coding Agent，看起来像突然多了十个程序员。
实际用起来，场面往往没那么美好。
Agent A 和 Agent B 同时改了同一个文件；Agent C 花二十分钟调查的问题，Agent D 刚刚已经解决；一个 Agent 建了新接口，另一个还按旧接口写测试；第三个任务一直卡着，因为它需要的信息在另一个 Agent 的终端里，谁也没有主动传过去。
最后，人类从“自己写代码”变成“处理十个 AI 的冲突”。
这也是多智能体系统进入工程阶段后越来越明显的一件事：把模型数量从 1 加到 10 很容易，让 10 个 Agent 稳定协作却涉及任务划分、消息传递、共享记忆、代码隔离、权限、预算、冲突处理和人工审批。
最近在开发者社区走红的 Munder Difflin 做了一件挺有意思的事。它把 Claude Code、OpenAI Codex、Kimi Code、Gemini CLI、Qwen、Copilot CLI、Cursor 等终端智能体塞进一个二维办公室，给每个 Agent 一张桌子、一个头像、一份记忆和一个邮箱，再放一个总调度 Agent 管理整个“办公室”。
UI 有点像游戏，底层却值得仔细看。
它把多智能体最麻烦的那部分，放到了模型之外。
它没有重新造一个Agent，而是直接接管真实CLI进程
Munder Difflin 的第一层设计很朴素。
Claude Code 还是 Claude Code，Codex 还是 Codex，Kimi Code 还是 Kimi Code。系统通过 node-pty 启动真实的终端进程，再用 xterm.js 把终端渲染出来。
每个 Agent 都是独立进程，有自己的工作目录、身份和 Provider 生命周期。
多智能体的第一件正事，是把“共享上下文”从Prompt里搬出去
很多早期 Multi-Agent Demo 的协作方式非常直接：Agent A 的结果拼进 Agent B 的 Prompt，B 再把结果传给 C。
任务一长，问题就出现了。
Prompt 越来越大；同一份背景被反复复制；Agent 不知道哪些内容已经过时；所有东西混在一条对话里，很难审计，也很难恢复。
Munder Difflin 做了一个叫 Hive 的协作层，里面包含 Memory、Mailbox、Blackboard、Event Log 和 Git。
Agent 之间发消息，不需要把所有历史塞进共享上下文。每个 Agent 向自己的 outbox/ 写消息，Router 再投递到目标 Agent 的 inbox/。共享信息可以写入 Blackboard；长期知识进入 Memory；事件写入 append-only log。
这看上去像把办公室里的邮件、公告栏、知识库和日志系统搬给了 Agent。
工程上却很重要。
LLM Context Window 再大，也不适合承担数据库、消息队列和审计日志的全部职责。上下文适合提供当前任务所需的信息，不适合无限保存整个组织的全部历史。
Blackboard和Mailbox解决信息，Task Ledger解决责任
Munder Difflin 的 GOD Agent 处于整个调度层中心。它维护 roster、routing、blackboard 和 task ledger，把任务分给不同 Agent，再处理升级和冲突。
用户主要和它对话。例如：
“把这个项目升级到新的前端框架，同时不要影响现有支付流程。”
调度 Agent 可以把工作拆成依赖分析、前端迁移、支付回归测试、文档更新几个子任务。每个专业 Agent 只拿到自己需要的上下文。一个任务完成后，结果进入共享区域，后续 Agent 再继续。
这比十个 Agent 同时读一段总 Prompt 然后各自自由发挥稳定得多。
多智能体系统如果要进入企业生产环境，Supervisor/Worker 这类层级关系大概率会越来越常见。因为组织本身就是一种降低复杂度的机制：角色负责限定能力边界，流程负责限定动作顺序，审批负责控制风险。
Git并行是一个小问题，却很能说明工程化差距
让多个 Coding Agent 同时操作一个仓库，很快会遇到 Git 冲突。
如果两个 Agent 同时碰 index，index.lock 就可能互相打架；同时改一条 Branch，文件内容也容易覆盖。
Munder Difflin 的做法是 single-committer 设计：Hive 由一个提交者管理，Agent 自己不直接争抢 Git index。同时可以给不同 Agent 分配独立 Git Worktree，让并行任务在各自工作树里进行。
这个设计没什么“智能”，却非常实用。
很多 Agent Demo 在单任务下看起来不错，一进入并行代码生产就暴露出传统软件工程问题。模型能写代码，不代表共享文件系统天然支持十个模型同时改代码。
数据库需要事务，分布式系统需要锁和一致性，Coding Agent 也绕不开版本隔离和合并策略。
类似问题放到工业场景会更明显。多个 Agent 如果同时修改工艺参数、设备配置或知识库规则，没有对象锁、版本号、审批和回滚机制，风险远高于 Git 冲突。
Agent会循环，所以系统里必须有熔断
Munder Difflin 专门设计了 Circuit Breaker，采用 steer → constrain → stop 的阶梯式干预。
先给 Agent 新指令纠偏；还不行就缩小权限或任务范围；继续异常则停止。系统还维护 per-agent Token Budget、真实成本 Ledger，并通过 OpenTelemetry 记录 Span 和 Tool Waterfall。
把这些概念放在一起看，多智能体平台已经很接近分布式系统的工程范式。
分布式系统里早就有超时、限流、熔断、重试、Tracing、幂等、权限、队列和人工补偿。Agent 只是把不确定性进一步放大：传统服务相同输入通常得到稳定结果，LLM 每一步都有概率性和长链路误差。
Agent 系统因此需要更强的外部控制和运行时约束。
人工审批应该放在哪些节点
Munder Difflin 把 Spend、Destructive Ops、Scope Change 等动作送入人工 Approval Queue。
这个划分很值得企业借鉴。
如果什么都要求人确认，Agent 退化成一个高级表单；如果什么都自动执行，出了问题又很难追责。更合理的方式是按风险分层。
读取日志、搜索文档、跑测试，可以自动。
新建临时分支、生成报告、提交草稿，可以自动或事后审查。
删除资源、修改生产数据库、增加支出、调整项目范围、向外部客户发消息，最好进入审批。
工业智能体还可以进一步加入设备安全边界：查看 PLC 数据和读取报警自动执行；改设定值需要审批；触发停机、旁路联锁一类高风险动作，可能根本不该开放给通用 Agent。
当智能体开始“做事”而不只是“答题”，权限模型和审批模型的重要性会迅速超过 Prompt 技巧。
“办公室”这个隐喻，其实点中了数字员工的核心
Munder Difflin 最吸引眼球的地方是像素风办公室，Agent 会走来走去，信封在桌子间飞。
更值得观察的是，它把 Agent 放进了一个组织结构中：有个人记忆，有公共知识，有邮箱，有任务账本，有主管，有预算，有版本隔离，有异常熔断，有人工升级。
未来一家制造企业完全可以有质量 Agent、工艺 Agent、设备 Agent、CAE Agent、采购 Agent、售后 Agent。它们未必需要使用同一个模型。某些角色跑本地开放模型，某些高难任务临时调用闭源前沿模型。上面再放一层 Factory Supervisor，负责拆任务、路由、合并结果和发起审批。
到那时，衡量平台能力的方式也该改变。
“支持多少个 Agent”没什么意义。创建一百个进程并不难。
更值得问的是：一百个 Agent 同时工作时，会不会重复劳动？会不会争抢同一份资源？任务失败能不能恢复？成本能不能封顶？谁改了数据能不能追溯？某个 Agent 发疯以后多久能被熔断？人在什么地方能接管？
这些问题解决以后，多智能体才有可能成为一套生产系统。
但它提供了一个很好的观察窗口。
多智能体开发正在从“让几个模型互相聊天”，走向一门更传统、也更麻烦的工程学：如何组织一群能力不错、行为带有不确定性的数字工作者。
这类平台最后比拼的，很可能是任务组织、协作治理和运行时控制的质量。
参考资料
- Munder Difflin 官方网站及项目 README，2026-08
- Munder Difflin GitHub：HIVE / SPEC / DESIGN 等项目资料
- Horizon Daily：2026-08-23 技术资讯汇总