模型: openai/gpt-5.4
生成日期: 2026-04-01
书名: Claude Code VS OpenCode：架构、设计与未来
章节: 第16章 — 可扩展性对比
Token用量: 约 5,000 input + 1,260 output

16.4 钩子系统

Hook system 是扩展能力中最接近“生命周期控制”的一层。所谓 hook，本质上就是一个拦截点：某个事件发生前后、某个阶段开始结束时，系统允许额外逻辑插入。很多真正关键的 agent 行为，不是在 prompt 里决定的，而是在这些边界处决定的。

OpenCode 暴露的宿主 hook 点并不算多，但位置都非常关键。大致可以看成五类重要入口：配置、消息处理、参数/消息变换、事件处理、工具执行前后。这种设计的优点，是宿主 hook surface 虽小，但杠杆很大。开发者不需要面对几十个零碎钩子，也照样能做出非常强的扩展。

OMO 在这个基础上做了一个极其有代表性的动作：它把 41 个内部 hooks 复接到 OpenCode 的 5 个 hook points 上。这句话几乎概括了 OMO 的整个中层设计。宿主层只给出少量生命周期入口，OMO 则在这些入口后面挂出一个更丰富的策略图谱：session hooks、tool-guard hooks、transform hooks、continuation hooks、skill hooks。也就是说，OMO 不是简单“使用了宿主钩子”，而是在宿主钩子之上又构造出了一套二级 hook 语言。

Claude Code 也有 5 个 hooks，但风格明显不同。它们更强调产品生命周期与安全相关节点，例如 session_start、pre_compact、post_compact、post_sampling、file_changed 等。这个设计取向很清楚：给出少量高价值节点，支持自动化与定制，但不把宿主运行时主导权大规模交给扩展层。

所以三者的 hook system 可以这样理解：

这里需要区分两个层次：host hooks（宿主钩子） 和 policy hooks（策略钩子）。这两个词不是传统教材里的固定二分法，但很适合分析这里的结构。宿主钩子，是系统本身暴露给扩展层的原生入口；策略钩子，则是扩展作者在宿主钩子之上再抽象出来的二级行为插点。OpenCode 给的是前者，OMO 在其上构建了后者，Claude Code 则更谨慎地暴露前者的一部分。

为什么 hook system 如此重要？因为很多 hardest problems（最难的问题）都发生在边界上。例如：工具执行前，是否要检查目标文件危险性？消息送进模型前，是否要注入仓库规则？上下文压缩后，是否要恢复 todo 状态？这些都不是“多写两句 prompt”能解决的，而是标准的 hook 型问题。

OpenCode 的哲学是：给少量强钩子，其他留给开发者组合。Claude Code 的哲学是：给少量经过挑选的钩子，保证产品边界和安全主权。OMO 的哲学则是：把钩子升级为一整套运行时治理系统。

OMO 的 tool-guard hooks 是这个思路最好的例子。file guard、comment checker、rules injector、continuation enforcer 等，说明 hook 并不只是为了“改一下数据流”，而是为了做质量控制、安全控制、行为约束和状态保留。换句话说，hook-rich architecture 的价值，在于它能把“prompt 做不到的运行时纪律”写进系统。

但 hook 越多，也越难调试。钩子系统最大的隐患，是交互复杂度。一个消息在 A 阶段被改写，在 B 阶段触发了新的规则，在 C 阶段又被恢复，你很难第一时间知道问题到底来自哪里。所以 hook 的力量和调试成本是成正比的。

对未来平台设计者来说，一个重要结论是：应该明确区分“给宿主多少原生 hook surface”和“允许扩展层在其上构造多复杂的策略图谱”。OpenCode 证明小 hook 面也能很强，OMO 证明二级 hook 体系能撑起一个中层运行时，Claude Code 则证明商业产品可以通过较少的 hooks 保持稳定和可控。

如果说插件是“能加什么能力”，那 hooks 解决的是“在什么时候、以什么边界条件加这份能力”。OpenCode 把门打开，OMO 把门后修成了走廊和房间，Claude Code 则在门口装了更严格的门禁。