把 Agent Harness 做成可克隆办公室:Munder Difflin 给多 Agent 协作的一份工程化样本 2026 年 8 月 22 日,一个名为 Munder Difflin 的开源项目登上了 GitHub Trending 当日榜首,三天之内被 Product Hunt 与 Reddit 推上各自的前列。它把自己描述为 "Agent harness to run an offic
把 Agent Harness 做成可克隆办公室:Munder Difflin 给多 Agent 协作的一份工程化样本
2026 年 8 月 22 日,一个名为 Munder Difflin 的开源项目登上了 GitHub Trending 当日榜首,三天之内被 Product Hunt 与 Reddit 推上各自的前列。它把自己描述为 "Agent harness to run an office of your clones"——一个用 Agent 跑出你自己克隆体的办公室。这个名字出自美剧《办公室》里那家业绩最差的纸业公司 Dunder Mifflin 的谐音梗,项目的所有插画也是像素风的办公场景:每个 Agent 都是坐在工位上的虚拟员工,envelope 在桌子之间飞来飞去,主调度 Agent 坐在 Michael 那把椅子上。
看起来只是又一层 Agent 框架包装?不是。Munder Difflin 真正值得拆解的,是它把 "多 Agent 长生命周期协作" 这个老难题,工程化到可以被克隆、被可视化、被恢复的程度。它不是又一个 LangChain 风格的编排库,也不是 Claude Code 的图形外壳;它是在 已经存在 的命令行编码 Agent——Claude Code、Codex、Cursor、Gemini CLI、Grok、Qwen、OpenCode、Copilot CLI 等十二个——之上,再加一层调度、记忆、协作、可视化和控制。本文把 Munder Difflin 作为样本,再叠加同一时期出现的另一个工程化样本 OpenRig,试图回答:当一名工程师想要同时调度多 Agent 完成一个长期任务时,今天我们离 "可工程化" 还有多远。
一、为什么单 Agent 仍然不够
过去半年里,几乎所有主流编码 Agent 都把重点放在单 Agent 长任务的稳定性上:更长的 context window、更聪明的工具调用、更可靠的子任务分解。但 2026 年初 HN 上一个 53 票的项目 lean-collab(Mutable State,2 月 12 日发布)已经把这个问题点破:单 LLM Agent 在长跑复杂任务时,会陷入循环、停摆或生成不可编译的代码。他们的解法是把任务拆给多个 Agent,让它们在共享上下文上协同工作。这并不是 Munder Difflin 的首创,但 Munder Difflin 把这条路推到了工程化的尽头。
OpenRig 的作者在 4 月 14 日的 Show HN 里也讲了同样的故事:他每天同时跑 Claude Code 和 Codex,后来用 tmux 让它们彼此对话,再后来他意识到 "你搭建的 Agent 拓扑本身就应该是一种可以被命名、被保存、被恢复的形状",于是写出了 OpenRig。两份独立工作,在三个多月里,从两个不同方向收敛到同一个结论:多 Agent 协作不是脚本拼接,而是一种需要持久化、可视化、可恢复的运行时结构。
二、Munder Difflin 的工程结构:Hive + GOD Agent + 可视化 Floor
Munder Difflin 的核心抽象叫 Hive——一个本地 Git 仓库,所有 Agent 通过它交换信息。每个 Agent 拥有自己的 outbox,路由层把消息投递到对方的 inbox;任何 Agent 都 不直接 操作 Git,所有写操作都由中央 router 完成,这是 single-committer 设计,避免多 Agent 并行时常见的 index.lock 损坏。Hive 之上有四件套:每 Agent 的本地记忆、原子文件邮箱、共享黑板、仅追加的事件日志。
用户不直接指挥十二个 Agent。Munder Difflin 引入了 GOD Agent(在 UI 里化身为 Michael,坐在自己的办公室里):它是用户的唯一对话入口,接收任务、做常规路由、自己处理可以自动决策的事情,只在涉及开销、破坏性操作、范围变更时把请求推送到一个审批队列。这个设计背后有一个非常朴素的工程直觉:用户应该只对一个 Agent 说话,而不是同时给十二个 Agent 下达相互冲突的指令。
可视化层是 Munder Difflin 最容易被低估的部分。它用 Pixi.js 渲染出一间像素风办公室,每个 Agent 是一个坐在工位上的虚拟人偶,Agent 调用工具时人偶走向对应的工作站,Agent 之间传递消息时 envelope 在桌子之间飞起来。点击任何工位,你看到的是这个 Agent 真实的 xterm.js 终端,可以直接键入指令。Avatar 的状态——表情、动作、颜色——由真实的 hook 事件驱动,而不是装饰层。这种 "可视化的运行时" 的意义不在美学,而在于:当十二个 Agent 同时在跑、用户又不可能逐个查看它们的输出时,一个能反映真实事件流的视觉地图,是判断系统是否在按预期工作的唯一现实手段。
三、控制与安全:Human Gates、Circuit Breaker、Telemetry 三件套
把十二个 Agent 放在一起跑,最现实的风险不是它们不够聪明,而是它们会在不该花钱的地方花钱、在不该删东西的地方删东西。Munder Difflin 在控制层放了三道防线:
第一道是 Human Gates:开销、范围、破坏性操作三类事件被强制升级到用户,用户可以中途转向或优雅停止。这是一组明确的、可配置的策略,而不是 "Agent 自己判断什么时候该问"。第二道是 Circuit Breaker:当 Agent 陷入错误循环、工具风暴或预算超支时,系统按 steer → constrain → stop 的阶梯逐步收紧权限。第三道是 Budgets & Telemetry:每 Agent 有 token 上限,实际花费从会话转录里折算,持久化到一个不可篡改的账本里,加上 OTel span 和工具调用瀑布图。Telemetry 文档明文声明:它只统计桶和固定词,不收集 email、account id、payment id、用户输入文本;并且 DO_NOT_TRACK 开关随时可以关掉。
这种设计哲学呼应了 Munder Difflin 项目页上反复强调的一句话:"Private by architecture, not just by promise."(私密性靠架构保证,而不只是承诺。) 具体落地是四件事:本地优先——代码、密钥、个人上下文永远不离开机器;每设备密封——消息在你的设备上签名,在对方的设备上解密,中继只搬运打不开的盒子;线路上没有任何可以扣费的内容——订阅、席位、卡片、发票都跑在 console 里,App 本身从不发送支付标识符;开源——MIT 协议,节点、协议、加密层的每一行代码都在 GitHub 上。
四、OpenRig 的另一条路:YAML 拓扑 + Snapshot/Restore
如果 Munder Difflin 走的是 "桌面应用 + 可视化办公室" 的路径,OpenRig 则走的是 "CLI + tmux + 本地守护进程" 的更轻量路径。它的核心抽象是 RigSpec——一份 YAML 文件,声明 pods(边界上下文组)、members、edges(连接关系)、continuity policies(连续性策略)和 culture(协作文化)。一份 spec 描述一支 Agent 团队,而不是一支脚本。
关键工程动作是 Snapshot/Restore。当用户执行 rig down --snapshot 时,整个拓扑被冻结——所有 tmux 会话、Agent 配置、上下文状态都被序列化;当用户用 rig up <name> 恢复时,系统按节点报告每个 Agent 是 resumed、fresh 还是 failed。这是把 "Agent 团队" 当成一种可持久化的工作负载在对待,而不仅仅是临时跑起来的脚本。
OpenRig 还内置了几个 starter rig:first-project(两个 Codex 节点:一个 owner、一个 checker)、conveyor(最小可交付软件工厂,横跨 intake、planning、build、review)、product-team(完整产品研发拓扑,包含 orchestrator HA 对)、adversarial-review、research-team、secrets-manager(由专门 Agent 运营的 HashiCorp Vault 实例)。最后一个例子很有趣:它演示了一个 rig 可以 打包真实的软件 一起被管理,而不是只调度 Agent 自己。这意味着 OpenRig 在尝试回答的不只是 "怎么用 Agent",还有 "怎么用 Agent 管理一个真实的运行时系统"。
五、共性提炼:多 Agent 长生命周期协作的四件工程要件
把 Munder Difflin 和 OpenRig 并排看,会发现它们各自独立地收敛到了同一组工程要件:
1. 持久化的协作结构,而不是临时拼接。 两份方案都把 Agent 之间的拓扑、记忆、消息、上下文当作可命名、可保存、可恢复的对象,而不仅仅是进程。Munder Difflin 用本地 Git 仓库做 Hive,OpenRig 用 SQLite + tmux 做 Snapshot。本质相同:Agent 团队是一种工作负载,而不是一段会话。
2. 单一调度入口,避免指令分裂。 Munder Difflin 的 GOD Agent、OpenRig 的 orchestrator pod,都在做同一件事:把多 Agent 协作收敛成一条对话线。用户不应该同时对十二个 Agent 下指令,这是控制论意义上的稳定性前提。
3. 强制的可视化与可观察性。 没有可视化的多 Agent 系统是不可运维的。Munder Difflin 用像素办公室,OpenRig 用 topology graph;两者都把 hook 事件接到 UI 层,让用户能看到 envelope 飞、节点切换、circuit breaker 触发。这是 "让长跑任务可被监督" 的唯一现实方式。
4. 强控制 + 强恢复的并行设计。 两份方案都内置了 human gates(开销/范围/破坏性操作升级)、circuit breaker(异常循环中断)、telemetry(不可篡改的账本)和 snapshot/restore(崩溃后能回到同一支团队)。这些不是 "未来计划",是已经写入 0.5.x 版本的基础能力。
六、对企业落地的启示
把这两份工程化样本抽出来,放到企业 AI 落地的语境里,可以读出三条不那么显眼但很重要的结论。
第一,多 Agent 协作不是 "再买一套框架",而是引入一种新的运行时对象。当一家企业希望让多个 Agent 协同完成一个长跑任务(比如一个季度的财务关账、一个产品迭代周期的代码评审、一个跨部门的数据治理)时,真正要解决的问题不是 "用哪家的 SDK",而是 "这支 Agent 团队的工作状态能不能被保存、能不能被恢复、能不能被中途接管"。Munder Difflin 的 Hive 和 OpenRig 的 RigSpec 都在正面回答这个问题。
第二,本地化与可审计不是营销词,是默认架构。Munder Difflin 显式声明代码、密钥、个人上下文永远不离开机器;OpenRig 默认在本地守护进程上跑,可以接 cmux、Claude Code、Codex 的本地 CLI 实例。对那些受合规约束的企业(金融、医疗、政务、跨境数据),这种 "默认本地、按需出网" 的架构,比云端托管的多 Agent 服务更接近它们的真实诉求。
第三,可视化的运行时是长跑任务的必要条件。一间办公室里,如果没有可被观察的 Agent 状态,用户就只能凭 Agent 的文字输出猜测它在做什么,这是不可持续的。两份方案都把 "可视化" 当作核心特性而不是附加功能,这一点对企业的运维团队尤其重要——他们需要的不只是 "Agent 跑了",而是 "Agent 跑到哪一步了、在哪个文件上、用了多少 token、被谁审批过"。
2026 年的多 Agent 工具栈正在从 "能不能跑" 切换到 "能不能被工程化地跑"。Munder Difflin 用一个像素办公室,OpenRig 用一份 YAML 文件,从两个方向给出了各自的答案。它们都不完美:Munder Difflin 还在 pre-release,OpenRig 的 web UI 已经进入维护模式,两条路都有大量未完成的工程债。但它们共同证明了一件事——多 Agent 长生命周期协作不是一个研究问题,而是一个已经被多个独立团队用工程手段正面回答过的问题。下一步要看的是,这些工程实践能不能从开源样例走进行业生产系统。
主要参考来源:Hacker News 上 Munder Difflin 项目公告(objectID 49398152,2026-08-22,312 票)、OpenRig 项目公告(objectID 47772935,2026-04-14)、Mutable State 的 lean-collab 项目(objectID 46990733,2026-02-12,53 票);以及 Munder Difflin GitHub 仓库 chaitanyagiri/munder-difflin 的 README、TELEMETRY.md、SECURITY.md 与 OpenRig 仓库 mvschwarz/openrig 的 README。