Munder Difflin v0.2.4 特性深入解析：Codex 生命周期 Hook 桥与多提供商蜂巢平权之路-港品优选

Munder Difflin v0.2.4 特性深入解析：Codex 生命周期 Hook 桥与多提供商蜂巢平权之路

【免费下载链接】munder-difflinA local multi-agent harness that works with your existing Claude Code, Codex subscriptions, allows you to run an office of agents项目地址: https://gitcode.com/GitHub_Trending/mu/munder-difflin

v0.2.4 是 Munder Difflin 多提供商故事的收官版本：本指南逐项拆解该版本的每一个改动，从把 Codex 提升到"完整蜂巢参与者"（full hive parity）的Codex 生命周期 hook 桥、Antigravity 的agy-hook 桥、面向无 hook 提供商的WORK ORDER FROM HIVE 终端工作订单模式，到新的Schedules 标签页与tunnelmole 取代 localtunnel的入口切换，并下沉到源码层面说明每项机制的真实调用链。读完你将掌握：多引擎"同一办公室"的三种接入范式各自的适用前提、hook 桥在仓库中的实际落点（agentProvider.ts、hive.ts），以及升级 v0.2.4 后需要处理的迁移事项（如更新保存的 Slack webhook URL）。

该版本的发布说明见 launching-munder-difflin-v0-2-4.md；本文聚焦的是"它怎么工作"——每个功能背后的机制、代码实际做了什么，以及日常使用中意味着什么。

多提供商挑战：三种 CLI、三种控制面、一条收敛路径

目标是让 Claude Code、Antigravity（通过agy使用 Gemini 模型）和 Codex 在同一间办公室里都成为"一等公民"蜂巢参与者。难点在于：每个 CLI 暴露的控制面完全不同，因此每个提供商需要不同的接入方式——而且这些方式应当向"平权"收敛，而不是停留在"能用就行"。

Claude Code 是基线。它拥有--append-system-prompt、--settings以及完整的 hook 生命周期：PreToolUse、PostToolUse、Stop、SubagentStop、PreCompact等等。蜂巢从设计之初就围绕这套控制面构建：hook 信号驱动实时状态、熔断器（circuit breaker）、收件箱排空（inbox drain）与压缩（compaction）。

Antigravity（agy）什么都没有。没有--append-system-prompt，没有配置文件式 hook。因此 Antigravity 的接入走了一条提供商专属路径：协议注入 + 一个把 Antigravity 生命周期事件归一化到既有管线中的原生 hook 桥。

Codex 也没有 Claude 式 hook。v0.2.3 时它使用协议注入 + 空闲收件箱唤醒轻推（idle inbox-wake nudge）——可用，但并非真正的 hook 桥。v0.2.4 改变了这一点：Codex 现在拥有与 Antigravity 相同的生命周期 hook 桥，两者走同一条统一分发路径。

hiveAware：只表示该 CLI 是否接受 Claude 专属的身份注入（--append-system-prompt+ hook--settings），不等于"参与蜂巢"；
canReceiveInbox：是否允许路由把收件箱邮件投递给该提供商——这要求能感知生命周期状态、只在安全空闲提示符处投递（Claude 原生支持，Antigravity/Codex/Grok 经 hook 桥获得），无 hook 的custom提供商邮件会被弹回给 GOD。

Antigravity：初始提示注入 + agy-hook 桥

Antigravity 的接入包含两部分。

协议注入。因为agy不提供--append-system-prompt的等价物，蜂巢身份与协议就作为会话的初始提示进入——即 agent 终端启动后由 harness 键入的第一段文本。这与 Claude Code agent 通过--append-system-prompt收到的内容相同，只是投递方式不同。在 agentProvider.ts 中，这由initialPromptFlag字段描述：Antigravity 通过-i "<prompt>"接收初始提示以定位会话，然后继续。对应地，resumeFlag: '--conversation'让重生成时能以会话 ID 续接之前的对话。

agy-hook 桥。Antigravity 确实会发出自己的生命周期事件，但其形态与 Claude Code 的 hook 不同。agy-hook桥把这些事件归一化到既有 hook 管线中——把 Antigravity 的信号翻译成系统其他部分已经理解的PreToolUse、PostToolUse、Stop事件。在 hive.ts 的installAgyHooks()中可以读到具体实现：harness 把翻译 shim 写入<hive>/bin/agy-hook.cjs，然后向~/.gemini/config/hooks.json与~/.gemini/antigravity-cli/hooks.json两个位置（best-effort、幂等，只覆写自己的munder-hive组）写入PreToolUse/PostToolUse/PreInvocation/PostInvocation/Stop五类 hook 命令，且使用打包内置的 Node 而非裸node（因为 agy 的 hook 运行在一个被剥离过 PATH 的环境中）。

实际结果：一个 Antigravity 工人在楼层（Floor）上获得与 Claude Code 工人相同的实时状态更新、相同的收件箱排空行为、相同的熔断器信号。提供商不同，参与方式相同。

Codex：完整生命周期 Hook 桥（v0.2.4 核心亮点）

v0.2.3 中的 Codex 是"非蜂巢感知、但具备收件箱能力"的：spawn 时注入协议，通过空闲收件箱唤醒轻推投递邮件——一个可用的兜底方案，但不是原生 hook 路径。

v0.2.4 给 Codex 装上了真正的生命周期 hook 桥。这是本版本的头条改动。

该桥统一了agy与codex的分发：两个 CLI 现在走同一条 hook-bridge 代码路径——与归一化 Antigravity 事件的同一条。当 Codex 发出生命周期事件时，桥将其翻译成系统其余部分理解的 hook 管线。实时状态、收件箱排空、发件箱路由——全部走原生路径，而非绕行方案。

实现上的一个关键优势是零翻译。在 hive.ts 的installCodexHooks()注释中明确写出：Codex 的 hook 契约本身就是 Claude 形态的——snake_case 的 stdin（hook_event_name/tool_name/tool_input/session_id/cwd）与匹配的响应契约，且其Stop的{decision:'block',reason}语义正好就是"继续，并把 reason 作为下一条提示"——这正是drainForStop()返回的内容。因此 Codex 直接逐字复用Claude 的cth-hookshim，不需要像 agy 那样的翻译器。

同时注意隔离设计：installCodexHooks()不污染用户全局的~/.codex（那里还存放着登录态），而是为每个工人创建一个 per-agent 的CODEX_HOME（<dir>/.codex），把自己的[hooks]表写进其中的config.toml；用户的auth.json被符号链接（Windows 上降级为复制）进来以继承登录，packages目录同样共享，避免为每个 agent 复制二进制。这样 hook 只对蜂巢工人生效，用户自己的codex命令行使用完全不受影响。

实际效果：

Codex 在楼层上的状态实时更新——运行中、思考中、空闲——来自 hook 信号而非轮询；
邮件进入 Codex agent 的收件箱，并在其空闲时通过与 Claude Code、Antigravity 相同的收件箱排空路径被取走；
发件箱消息照旧由提供商无关的路由器拾取。

Codex 不再是带星号的第三提供商，而是完整的蜂巢参与者。

终端工作订单：WORK ORDER FROM HIVE 模式

Antigravity 与 Codex 现在都有完整的 hook 桥，但多提供商工作引出了一个更宽泛的问题：如果未来的提供商完全没有收件箱排空路径——没有 hook 桥、没有空闲唤醒轻推——而你仍需要把蜂巢邮件送达它，该怎么办？

答案是结构化的兜底：蜂巢直接把一条WORK ORDER FROM HIVE消息键入 agent 的终端。消息带有清晰标签，以终端输入形式投递，任何能读取自己终端内容的 CLI 都可执行。若邮件到达时渲染器（renderer）不可用，路由器把消息弹回给 GOD agent，而不是静默丢弃。

这个模式诚实地面对提供商能做什么、不能做什么：如果一个 CLI 不暴露邮箱路径，往终端里键入正是人类操作员会做的事。工作订单模式把这件事系统化、可审计化，而不是临时拼凑。它至今仍是任何尚无 hook 桥的提供商的兜底通道。

源码佐证随处可见：WORK ORDER FROM HIVE作为常量出现在渲染层 useHive.ts，CHANGELOG.md 则记录该特性（#53）："无收件箱排空路径的提供商，通过键入其终端的WORK ORDER FROM HIVE接收蜂巢邮件；仅当渲染器不可用时才回退为 god-bounce。"从 agentProvider.ts 可以看到约束的另一面：无 hook 的自定义提供商无法暴露安全的空闲状态，因此邮件一律弹回给 GOD，绝不冒险投递。

Schedules 标签页

计划任务（scheduled missions）自 v0.1.6 起就是 Munder Difflin 的一部分。调度器按可配置间隔触发周期性任务——每小时站会、PR 审查、压缩周期、对安静工人的重新参与检查。到 v0.2.3 为止，这些内容还藏在 Floor 标签页的内嵌区段里。

迁移到 Command Center 的独立 Schedules 标签页是一个小的界面变更，却带来实实在在的日常影响。当你运行一个持久化办公室、同时挂着多个周期任务——大多数正经的配置都如此——这些任务需要一个不嵌套在 agent 名册视图里的安身之所。Schedules 标签页现在拥有：

周期性自动分发任务：你定义的每个任务及其间隔、目标与上次触发时间；
自适应心跳（adaptive heartbeat）：楼层对安静或空闲 agent 的重新参与信号，此前与上述任务挤在同一内嵌区段；
老板办公室日历快捷入口：从 Command Center 头部快速访问调度总览。

底层ScheduledMission数据结构与调度器逻辑没有变化——间隔触发、消息落入目标的收件箱、agent 像处理任何其他邮件一样取走它。这次变更的意义在于把"调度"从次级控制面升级为一级控制面。

数据结构的完整面貌定义在 config.ts：ScheduledMission含id、label、intervalMs、可选的weekly（天数组 + 分钟，存在且有效时取代intervalMs，因为固定间隔无法表达"工作日早晨"这类会随时钟漂移的节奏；intervalMs故意保留在记录上以便切回）、to、body、enabled、autoCompact、lastFiredAt、kind（'dispatch' | 'heartbeat' | 'compact'）以及心跳专用的quietThresholdMs。weekly的具体换算逻辑（下次触发时间、追赶窗口等）集中在 weeklySchedule.ts。内置任务同样定义于此：每小时站会 OPS_STANDUP_MISSION（默认启用，3 600 000 ms 间隔，投递给 god）与 HEARTBEAT_MISSION（默认关闭、需显式开启，因为心跳会向 god 的 PTY 键入内容，120 000 ms 基准间隔，且调度器会在 agent 看起来卡住时收紧节拍、在重新参与后放慢）。

心跳重新参与修复

GOD 编排器的自适应心跳现在会在存在未读的可操作收件箱条目（unread actionable inbox items）时重新参与（re-engage）。此前，心跳按计划触发，但可能漏掉这种情况：god 已有等待中的邮件，却没有任何东西触发重新参与——可操作条目一直未读，直到下一个计划周期。

修复很直接：心跳在循环（cycle）之前检查是否有未读的可操作收件箱条目，若有则重新参与。GOD 不再需要外部触发器来注意到心跳周期之间到达的邮件。从 config.ts 的注释可以看到心跳的设计意图：每个节拍观察实时楼层状态，仅当楼层真正安静时，把一份摘要投进 god 的收件箱，并在 god 的 PTY 确实空闲时轻推它去重新参与任何停滞的 agent；同一节拍同时驱动熔断器。

终端侧边栏默认打开

GOD 编排器现在启动时就显示 Terminal 侧边栏。你一直都可以手动打开它——现在不必再记得去做。对大多数工作流而言，一启动就看到 god 的终端输出是正确默认。

Slack + Webhook：tunnelmole 替换 localtunnel

Slack 与 webhook 的入口路径此前用localtunnel/loca.lt把本地服务器暴露到公网。这让 Slack 的 URL 验证握手得以成功，也保证入站 webhook 投递正常工作。

问题在于：loca.lt开始对所有出站请求提供浏览器插页（browser interstitial）。对人类浏览 URL 来说，插页烦人但尚可导航；但对 Slack 的url_verificationPOST——一种携带特定载荷、要求严格响应格式的机器对机器请求——它是致命的。握手静默失败，已保存的 webhook URL 悄悄失效。更糟的是，应用此前会报告"tunnel started"，却毫无迹象表明它给出的 URL 将拒绝所有入站请求。

slack.ts 与 webhook.ts 现在都改用tunnelmole（MIT 许可）。tunnelmole 直通 POST 请求，不插入任何插页。另外两个行为也变了：

启动失败呈现为真实错误。若 tunnelmole 无法绑定或没有返回 URL，应用现在记录一条可操作的错误，而不是静默报告一次成功（实则损坏）的启动——见 slack.ts 的 start()：openTunnel()返回空 URL 即抛出tunnelmole returned empty URL，最终返回{ ok: false, error: 'tunnel unavailable: …' }；而本地 HTTP 处理器（安全边界）在listen解析的瞬间就已存活，隧道随后才打开且是非致命的。
URL 每会话稳定。tunnelmole 给出的 URL 就是 Slack 或外部系统应当调用的真实地址——POST 落地前没有任何浏览器质询。

实现细节值得注意：tunnelmole 是纯 ESM 包，而 Electron 主进程以 CommonJS 打包，静态import会被外部化为require('tunnelmole')从而抛出ERR_REQUIRE_ESM。因此 slack.ts 与 webhook.ts 都在openTunnel()内部改用动态import()加载tunnelmole({ port })（对应的类型声明见 tunnelmole.d.ts）。tunnelmole 没有文档化的关闭句柄，因此拆除（teardown）是 best-effort 的；依赖清单中 tunnelmole 版本为^2.4.0（见 package.json）。

升级提醒：如果你保存的 Slack webhook URL 指向的是 loca.lt 地址，升级后请更新为新的 tunnelmole URL。应用会在启动时给出正确地址。

Windows spawn 修复

Windows 上的 agent spawn 在 v0.1.x 与 v0.2.x 各版本中被反复打磨——从 v0.1.8 最初的 ENOENT 二进制解析修复，到 v0.2.0 的锁屏冻结修复。本次一个进一步的 Windows spawn 修复（#22）针对 GOD 编排器在 Windows 上启动的一个特定 spawn 失败路径。如果你此前在 Windows 构建中看到 GOD 无法初始化，本版本已解决。

任务看板卡片上的 Dismiss（✕）按钮

任务看板（Command Center → Tasks）的每张卡片现在都有一个 dismiss 按钮。此前，done列的卡片会无限累积——对审计有用，但在繁忙的办公室里越来越吵。✕ 按钮把卡片从视图中移除，但不删除底层任务记录。干净的看板更容易协作；这个按钮让保持整洁变成一键操作。

v0.2.4 随附内容与上手方式

v0.2.4 包含从 v0.2.0（可观测性、熔断器、舰队监控、持久化）、v0.2.1（队列感知压缩、收件箱驱动心跳）、v0.2.2（上下文仪表、人类分发全部经由 GOD、社区修复）到 v0.2.3（多提供商基础、Schedules 标签页、tunnelmole）的全部内容。完整日志见 CHANGELOG.md。

使用新提供商的步骤：安装相应 CLI（Antigravity 的agy、OpenAI Codex 的codex）并加入PATH。在 Add Agent 对话框添加工人时选择提供商，蜂巢会处理其余一切。Munder Difflin 免费、开源、本地优先，支持 macOS、Windows 与 Linux。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析