七个空钩子为何拖慢命令近一秒

每次让 AI 编程工具执行终端命令，真正的命令还没开始，七个 hook 就先花掉了 945ms。作者实测发现，时间主要耗在解释器启动上，合并入口确实有用。但另一次审计更刺眼：没有一个 hook 能被确认与当前规则一致。

这篇文章值得读的地方，是把「提速」和「治理」拆开了。对同时使用 Claude Code、Codex，或自己维护工具调用检查脚本的团队来说，执行更快只是第一步，还得确认规则有效、事件不重复、旧入口已经退出。

945ms 花在启动进程，合并入口才有针对性

Anton 想把约 70 个 hook 收拢到一个 dispatcher，也就是统一接收事件、分派检查的调度入口。作者没有直接附和，而是先测了自己所在的小型笔记本节点。

这台机器的 settings.json 注册了 36 个 hook，磁盘上有 92 个 hook 文件，其中 8 个会匹配每一条 Bash/PowerShell 命令。作者挑了其中 7 个，用模拟载荷跑空执行路径，结果如下：

122ms  blackbox_session_guard.cmd
141ms  av_spawn_guard.cmd
141ms  dr_start_guard.py
170ms  block_dangerous_bash.py
120ms  public_tg_shell_gate.py
116ms  radical_order_gate.py
135ms  onair_fleet_guard.py
-----
945ms  total, per terminal command

要看最后一行：七个脚本累计 945ms，但它们在测试中只是解析少量 JSON，然后退出，没有执行实际检查。

统一入口的直接收益，是减少重复启动解释器的次数。

它不会自动让检查逻辑更快。作者据此估算，hub 节点每条命令触发约 19 个 hook，启动开销可能达到约 2.5 秒。这是按本机结果推算的数字，原文没有提供 hub 的同条件实测。

跑得慢还能测，规则过期却可能没人知道

hook 通常负责守住一条规则。麻烦在于，规则文档更新后，脚本可能继续执行旧要求，直到它拦住正常工作，团队才发现两者已经脱节。

他们在 8 月 4 日建立了检查工具 hook_canon_lag.py --census：读取 hook 头部的 rule-slug 和 rule-date，再与对应规则的最后编辑时间比较。11 月 11 日的输出是：

LAG      (rule newer than hook): 6
UNLINKED (nothing to ask with): 28
OK:       0
PINNED:   0

关键是 OK: 0。它表示没有 hook 能被工具确认与当前规则一致，并不表示全部规则都执行错了。

其中 28 个连机器可读的规则关联都没有，工具无从比较。8 月是 37 个里有 29 个未关联，占 78%；现在是 34 个里有 28 个未关联。作者认为，三个月过去，问题没有实质进展。不过，审计总数为什么与注册数、磁盘文件数不同，原文没有解释。

另外 6 个 hook 的记录日期都早于规则日期 2026-09-05。其中三个守护同一条「创建会话前必须掌握会话状态」的规则；blackbox_session_guard 和 onair_fleet_guard 还属于每条命令都会触发的那组。

这让它们成为优先复核对象，但日期差只能提示风险。规则文件改过，不代表规则含义变了，最终仍要拿真实案例验证。

还有一个更直接的故障：SessionStart 调用了不存在的 scripts\sync_conflict_watch.cmd，每次会话启动都静默失败。它说明审计还必须检查入口是否真的可执行。

dispatcher 还得解决重复副作用和部署残留

作者团队早有相关任务：task-2026-08-19-codex-hook-dispatcher-phase2，自 8 月 19 日开放，9 月 22 日应复核，已经逾期 50 天。

这个任务最初要解决的并非速度，而是 Claude Code 和 Codex 同时操作同一个工作树时，一次事件可能产生两次副作用。验收要求很具体：故意让两套执行环境触发同一事件，用计数器证明副作用只发生一次。

因此，dispatcher 从第一天就需要考虑幂等性，即重复收到同一事件，结果也只生效一次。原文列出的标识维度是 harness / session / turn / event / tool-call，但没有给出去重键的完整构造方式。跨环境的同一事件如何关联，还需要实现者补齐。

另一个 P0 任务 task-2026-08-29-hooks-rootfix-not-started 已开放 74 天。修复交接在 8 月 26 日就写好了，却一直没人开启执行会话；只需在 hub 的新会话粘贴一行即可推进。偏偏自动创建会话的机制正是待修对象，因此不能靠它自动启动修复。

部署也有类似的闭环问题。作者引用 7 月 30 日的观察：部署涉及三层，只有第一层会同步，但没有完整展开三层分别是什么。文中明确的一点是，脚本文件能同步，注册配置却属于各台机器。

如果只把 dispatcher 发到 6 台机器，旧 hook 可能仍然并行运行。先做金丝雀发布是对的，验收要看实际注册和触发情况，不能只确认文件到了。

我的判断

我赞同作者把两件事分别验收：统一入口是否减少开销，以及现存检查是否仍然正确。前者有七个脚本的本机计时支撑；后者有规则关联审计和失效入口作为证据。

但 945ms 不是所有团队都会付出的固定成本。原文没有交代硬件配置、重复测量次数或波动范围，也没有给出合并前后的对照。约 2.5 秒更是外推结果，不能直接套到 Node 项目或其他系统。

合并入口也不是唯一做法。对于检查很少的团队，先收窄 hook 的匹配范围、让无关命令跳过检查，也可能更省事。常驻进程则是另一条减少冷启动的路线，但原文没有比较这些方案。

我更看重作者的验收标准：耗时下降、重复副作用消失、规则能够追溯，应该各自有证据。日期检查适合排复核优先级，不能替代行为验证。

能拿来做什么

• 如果你的 AI 编程流程每条终端命令都明显停顿，先记录触发的 hook 数、进程数和总耗时，再用模拟载荷测启动成本，判断是否值得合并入口。
• 给自建 hook 补上可读取的规则标识和日期，同时检查注册路径是否存在；对日期落后的检查，用实际案例确认行为是否需要更新。
• 如果 Claude Code 和 Codex 共用工作树，先设计同一事件的关联与去重，再用计数器验证重复触发只产生一次副作用。
• 在一台机器先部署 dispatcher，核对旧注册是否移除，并比较每条命令耗时、触发数、进程数及规则审计结果，通过后再扩大范围。