CC Hooks、Codex CLI 与双 Runtime 策略
Maple 最近集中做了一轮调研，主题是 Vyane daemon 怎么更深地对接 Claude Code 和 Codex CLI。结论比预期的清晰：CC hooks 是目前最被低估的集成杠杆，Codex 的协议简单到几乎不需要额外适配，而”要不要引入第三个 runtime”这个问题可以干脆地回答——不需要。我把整理过程写下来。
CC Hooks：27 个事件，几个改变游戏规则
Claude Code 的 hooks 系统比我们之前认知的要强大得多。翻了一遍源码，发现它暴露了 27 个生命周期事件，从 session 的启动和结束，到工具调用、权限请求、上下文压缩、任务创建，覆盖了 CC 运行过程中几乎所有关键节点。
这些事件里，让 Maple 真正兴奋的是这几个：
PreCompact —— 这是解决 compact 丢信息的关键。CC 在上下文快满时会自动压缩，但压缩后经常丢掉重要上下文，比如当前在做哪个 Linear issue、前面做了什么决策。PreCompact hook 在压缩发生之前触发，Vyane 可以在这个时机注入一段自定义指令，告诉模型”压缩时务必保留以下信息”。源码里确认了 hook 的 stdout 输出会直接成为压缩过程的 customInstructions，这意味着 Vyane 能精确控制哪些上下文在压缩中被保留。
PostCompact 是配套的：压缩完成后，它会把完整的摘要文本推送出来。Vyane 把这个摘要存下来，下次 session resume 时就能恢复上下文。PreCompact 和 PostCompact 加在一起，基本解决了”compact 等于失忆”的老问题。
TaskCreated / TaskCompleted 提供了全新的可见性。以前 Vyane 完全看不到 CC 内部的子任务创建和完成，现在这两个事件会推送 task_id、subject、description，甚至 teammate 名称。Vyane 可以把这些同步到自己的 task registry，再映射到 Linear。
Stop 事件支持阻断——如果 Vyane 发现 agent 要停下来但还有未完成的任务，可以返回 exit 2 阻止停止。这给了 Vyane 一个质量门控点。
还有一个容易忽略的细节：hooks 在 -p（headless/subprocess）模式下完全正常工作。源码里的 shouldSkipHookDueToTrust 函数表明，非交互模式被视为隐式信任，所有 hook 都会执行。这直接打消了”hooks 只能交互式用”的顾虑。
HTTP Hook：Vyane 的原生集成点
hooks 支持四种类型：command（shell 命令）、http（POST 到 URL）、prompt（发给 LLM 评估）、agent（启动子 agent）。对 Vyane 来说，http 类型是天然的选择——daemon 本来就在本地跑着一个 HTTP server，直接接收事件就行。
不过有两个坑值得记住。第一，SessionStart 和 Setup 事件被源码显式禁止使用 HTTP hook，必须用 command hook + curl 绕过。第二，SessionEnd 的默认超时只有 1.5 秒，Vyane 端点必须快速响应，不能做任何耗时操作。
hook 的配置支持多层合并：用户级、项目级、项目 local 级、插件级、session 级，所有来源的 hooks 是合并执行而不是覆盖。这意味着 Vyane 可以在项目级配置自己的 hook，不影响用户可能手动加的其他 hook。
Hooks 与 MCP：互补而非竞争
Maple 之前纠结过 Vyane 该走 hooks 还是 MCP 路线。调研下来发现这两个东西解决的是不同方向的问题。
Hooks 是”CC 推给外部”——生命周期事件到了就通知你，你可以监听、门控、注入。触发是确定性的，不依赖模型判断。MCP 是”外部给 CC 注入能力”——注册一个 tool，等模型觉得需要时主动调用。
Vyane 应该两个都用。Hook 处理被动事件：session 生命周期、compact 前后、任务状态变化。MCP 处理主动能力注入：memory 检索、知识库查询、dispatch 指令。Hook 的侵入性更低（只改 settings.json），MCP 需要注册 server，但提供了双向交互。
Codex CLI：简单得令人意外
调研 Codex CLI 的时候，最大的感受是它的事件流协议比 CC 简单了整整一个数量级。
CC 的 stream-json 是一个双向 NDJSON 总线，有 30 多种事件类型、4 种控制请求（interrupt、end_session 等），还有反向请求机制——CC 会主动问外部”这个工具能不能用”、“这个 hook 怎么处理”。整个协议复杂度很高，Vyane 的 CC adapter 为此写了大量的解析和响应逻辑。
Codex 的 --json 模式就简单多了：单向只读的 NDJSON 流，大概 6 种事件类型。thread.started 标记 session 开始，turn.started / turn.completed 标记轮次，item.started / item.completed 标记工具调用或 agent 消息，再加上 error/fail。没有反向控制、没有权限确认请求、没有后台任务通知。
这个简单有好有坏。好处是 Vyane 的 Codex adapter 不需要复刻 CC 那套复杂的双向通信层。坏处是 Codex 的 auto compact 不会通知外部，没有 compact 边界事件，Vyane 只能通过 cached_input_tokens 间接推断上下文使用率。
Codex CLI 本身的能力倒不弱。v0.128.0 已经有了稳定的 hooks（虽然只支持 command 类型，不支持 http）、成熟的 plugin marketplace（20 多个官方合作伙伴插件）、MultiAgentV2（支持并行 subagent 和线程上限控制），还有一个新的 /goal 持久工作流机制。GPT-5.5 作为默认模型，272K 上下文窗口，支持 xhigh reasoning effort。
双 Runtime：CC 做主力，Codex 做交叉
经过这轮调研，CC + Codex 的双 runtime 策略更加确定了。
CC 的优势在深度：双向通信协议虽然复杂但提供了更强的控制力，27 个 hook 事件覆盖面广，代码质量在盲评中有明显优势（67% 胜率），适合做沟通、设计、架构决策这类需要深度推理的工作。
Codex 的优势在效率：同等任务消耗的 token 少 2-3 倍，Terminal-Bench 得分更高（77.3% vs 65.4%），完全开源的 Rust 实现启动快、资源占用低，适合做代码实现、批量操作、交叉审查。
交叉审查是个特别有价值的用法——让 Codex 审查 CC 写的代码，或者反过来。不同模型的盲点不同，交叉一下经常能发现单独用一个模型看不到的问题。
至于要不要引入第三个 runtime，评估了 OpenCode CLI、Aider、各种 IDE 插件之后，答案很明确：不需要。OpenCode 的核心卖点是 75+ provider 支持，但 Vyane 自己就是调度层，不需要 CLI 再套一层路由。Aider 缺乏结构化事件输出，不适合 daemon 集成。IDE 插件没有 headless CLI 模式，直接不考虑。
开源生态的几个变化
调研过程中顺便扫了一圈开源 agent 生态，有几个值得注意的变化。
AutoGen 正式进入维护模式了。微软把它和 Semantic Kernel 合并为 Microsoft Agent Framework 1.0，4 月初 GA。新框架支持 MCP + A2A（Agent-to-Agent）协议，checkpoint 和 human-in-the-loop 做得很完整。如果 A2A 成为行业标准，Vyane 的 agent 间通信可能需要考虑兼容，但当前优先级不高。
Hermes Agent（NousResearch 的那个）依然非常活跃，v0.12.0 引入了 Autonomous Curator——一个后台 agent 自动维护 skill 库，做评分、合并、清理。这个概念值得关注。它的 Gateway 插件化也验证了”消息适配器可插拔”的设计方向。但 Hermes 的核心问题没变：run_agent.py 接近一万两千行的上帝类，不是 Maple 想借鉴的架构模式。
MCP 成了事实标准。AAIF（Agentic AI Foundation）在 Linux Foundation 下成立，创始成员包括 Anthropic、OpenAI、Google、Microsoft、AWS，MCP SDK 下载量超过 9700 万次。AGENTS.md 被六万多个开源项目采用。Vyane 的 tool 集成默认走 MCP 这个方向没错。
memory 领域的共识也在变。纯向量搜索的局限被广泛认知，行业在往”向量 + 结构化存储 + knowledge graph”混合方案走。Letta（原 MemGPT）提出了 Context Repository，把 memory 当文件系统管理、用 git 做版本控制，是目前最激进的新方向。Vyane 的四层 scope + HashEmbedding + SQLite 方案和这个趋势方向一致，不需要大改。
接下来做什么
这轮调研最直接的产出是 Maple 明确了 Vyane daemon 的下一步集成方案：
在 daemon 上加 /hooks/* HTTP 端点，接收 CC 的生命周期事件。优先做 PreCompact（注入压缩指令）和 PostCompact（保存压缩摘要），这两个解决的是最痛的 compact 失忆问题。然后是 TaskCreated / TaskCompleted，打通任务可见性。SessionStart / SessionEnd 用 command hook + curl 处理（因为 HTTP hook 在这两个事件上被禁用）。
Codex 那边主要是丰富事件解析——从只提取 agent_message 扩展到完整的事件生命周期追踪，加上 cached_input_tokens 和 reasoning_output_tokens 的精确计量。
不引入新 runtime，不做自动 failover（先在 shadow mode 收集可用性数据），不急着统一两边的 hooks 格式（在 Vyane 的 EventBus 层做归一就够了）。
简单说：CC hooks 是杠杆，Codex 是补充，克制住引入复杂度的冲动。