模型: openai/gpt-5.4
生成日期: 2026-04-01
书名: Claude Code VS OpenCode：架构、设计与未来
章节: 第10章 — Oh-My-OpenCode的创新
Token用量: 约 4,300 input + 1,120 output
10.6 41钩子5层体系
OMO 的 hook 系统，是它“为什么不像一个普通插件，而像一个运行时中层系统”的最好证明之一。内部上，OMO 把 41 个 hooks 组织成 5 个层级：
- Session：19 个
- Tool-Guard：9 个
- Transform：4 个
- Continuation：7 个
- Skill：2 个
这些分组可以直接从 create-session-hooks.ts、create-tool-guard-hooks.ts、create-transform-hooks.ts、create-continuation-hooks.ts、create-skill-hooks.ts 中读出来。
为什么这件事重要？因为 OMO 已经不只是“多注册一些工具”“多拼一些 prompt”了，而是在 agent 生命周期的多个阶段写入行为控制。所谓 hook，本质上就是一个拦截点：在某个事件、某个阶段、某类输入输出经过时，系统可以插入额外逻辑。OMO 正是靠这些拦截点，把行为、质量、安全、续跑、技能提醒、上下文变形都变成了可编程策略。
这里有一个非标准术语需要解释：multiplex（复用复接）。在通信和系统领域，multiplex 指的是“多个逻辑通道共用较少的物理通道”。OMO 做的事情与此很像。OpenCode 作为宿主，只暴露了有限的 plugin hook points；但 OMO 却把几十种逻辑行为通过这少数入口复接进去。也就是说，宿主入口不多，但 OMO 在每个入口背后挂了很多逻辑子层。这就是“41 个 hooks 复接到 OpenCode 的 5 个 hook points”这句话真正的含义。
先看 Session 层。它主要处理会话级生命周期与运行状态，例如 context-window monitor、session recovery、think mode、Ralph Loop、delegate-task retry、start-work、notepad 注入、preemptive compaction 等。这一层控制的是 session 的节奏、恢复、推理姿态和长期运行状态。
再看 Tool-Guard 层。这一层守在工具边界上。因为工具边界是 LLM 意图真正接触外部世界的地方，所以这里特别重要。comment-checker、rules-injector、write-existing-file-guard、hashline-read-enhancer、tasks-todowrite-disabler 等都在这一层。它们有的负责防止 AI 风格注释污染代码，有的负责把项目规则自动带入上下文，有的负责限制危险文件写操作，有的则是在工具结果级别做增强与约束。
Transform 层处理的是消息变换，尤其是在模型真正看到消息之前。典型成员包括 keyword-detector、context injection、Claude Code hooks 兼容层、thinking-block validator。这个层级非常强，因为它意味着 OMO 可以在不修改宿主核心的前提下，改变模型的有效输入上下文。
Continuation 层则是 OMO “干活不准半途而废”理念的集中体现。stop-continuation-guard、compaction-context-injector、compaction-todo-preserver、todo-continuation-enforcer、unstable-agent-babysitter、background-notification、atlas hook 都在这里。这个层级直接决定了 OMO 为什么比普通 agent 更像“带监督的执行系统”。
最后是 Skill 层。数量不多，但非常战略化。category-skill-reminder 和 auto-slash-command 让 skill 不再只是静态文档，而是在运行时参与提示、指导和命令触发。
如果看具体 hook，几个例子特别能体现 OMO 的成熟度。
comment-checker 很有意思。它专门防止低价值、AI 味很重的注释污染代码。很多系统默认把注释看成无害输出，但 OMO 认为这其实是质量问题，值得系统性拦截。这个判断很细，但很对。
rules-injector 让仓库级规则自动进入工作上下文。这意味着 agent 更可能遵守本地规范，而不是每次都要用户手工再解释一次。
think-mode 则处理推理强度和 token 预算。它提醒我们：agent 的质量并不只取决于用了哪个模型，也取决于系统在什么时候分配了多少思考预算。某种意义上，think-mode 是在管理“思考成本”。
另一个关键点是：hooks 都可以通过配置启用或停用。如果一个 41-hook 系统不能配置，那几乎一定会失控。OMO 在这一点上是清醒的。它把 hook 体系做成了一个可裁剪的策略图，而不是刚性开关全开。
更高层地看，这套系统说明了一个重要趋势：未来 agent 架构的竞争点，不只在模型，更在生命周期控制面。一旦宿主平台给出了足够强的 hook surface，插件就可以长成一整套 policy engine。它能控制质量、安全、上下文、续跑、技能提醒、消息变形，而这些都远远超出“改改 prompt”所能达到的效果。
也正因此，OMO 看起来越来越像一个操作层，而不是薄扩展。41-hook 体系其实就是它的神经系统：它在监视、拦截、提醒、重试、保护、注入和保留状态。没有这套体系，OMO 仍会有一些有趣 agent；有了它，OMO 才真正成为一个编排运行时。