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-difflinv0.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。Antigravityagy什么都没有。没有--append-system-prompt没有配置文件式 hook。因此 Antigravity 的接入走了一条提供商专属路径协议注入 一个把 Antigravity 生命周期事件归一化到既有管线中的原生 hook 桥。Codex 也没有 Claude 式 hook。v0.2.3 时它使用协议注入 空闲收件箱唤醒轻推idle inbox-wake nudge——可用但并非真正的 hook 桥。v0.2.4 改变了这一点Codex 现在拥有与 Antigravity 相同的生命周期 hook 桥两者走同一条统一分发路径。在源码层这种按提供商声明接入方式的设计沉淀在 agentProvider.ts 中AgentProvider联合类型涵盖claude | codex | grok | kimi | gemini | antigravity | qwen | opencode | crush | pi | copilot | cursor | custom而AgentProviderPreset用结构化字段描述每个提供商如何构建 spawn 命令auto 模式 flag、模型 flag、如何注入协议、如何接收收件箱邮件。值得注意的是两个被刻意区分的概念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 的 stdinhook_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_HOMEdir/.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.tsCHANGELOG.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.tsScheduledMission含id、label、intervalMs、可选的weekly天数组 分钟存在且有效时取代intervalMs因为固定间隔无法表达工作日早晨这类会随时钟漂移的节奏intervalMs故意保留在记录上以便切回、to、body、enabled、autoCompact、lastFiredAt、kinddispatch | 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 Webhooktunnelmole 替换 localtunnelSlack 与 webhook 的入口路径此前用localtunnel/loca.lt把本地服务器暴露到公网。这让 Slack 的 URL 验证握手得以成功也保证入站 webhook 投递正常工作。问题在于loca.lt开始对所有出站请求提供浏览器插页browser interstitial。对人类浏览 URL 来说插页烦人但尚可导航但对 Slack 的url_verificationPOST——一种携带特定载荷、要求严格响应格式的机器对机器请求——它是致命的。握手静默失败已保存的 webhook URL 悄悄失效。更糟的是应用此前会报告tunnel started却毫无迹象表明它给出的 URL 将拒绝所有入站请求。slack.ts 与 webhook.ts 现在都改用tunnelmoleMIT 许可。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。使用新提供商的步骤安装相应 CLIAntigravity 的agy、OpenAI Codex 的codex并加入PATH。在 Add Agent 对话框添加工人时选择提供商蜂巢会处理其余一切。Munder Difflin 免费、开源、本地优先支持 macOS、Windows 与 Linux。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考