Specimen No. 03 · Three-Layer System

三层系统

一句话是怎么变成一段能跑、能提交的代码的？靠三层分工：OmX 翻译、OmO 开会、clawhip 传话。读完本页约 12 分钟（03/04/05 技术核心合计约 35–40 分钟）。

关键词：OmX · clawhip · OmO · 上下文窗口 · 事件路由

整体视图

三层系统示意：人 → OmX 拆解 → OmO 协调多个 agent → 完成；clawhip 在旁边监听事件并把通知/汇报移出上下文窗口。

OmX —— 翻译官 / 工头（工作流层）

它把一句模糊的话变成一份"施工计划"：规划关键词、执行模式、持续验证循环、并行多 agent 工作流。你说"把这个登录模块改成异步的"，它不直接埋头写代码，而是先回答：改哪些文件？先做哪一步？做完怎么验收？

技术落地：在仓库里，OmX 的产物是看得见的——.omx/ultragoal/goals.json（目标级联）、.omx/cc2/board.md（732 项 CC2 看板）、scripts/generate_cc2_board.py 等生成/校验脚本。计划不是留在聊天记录里，而是结构化落盘，供后续 worker 与验证环节读取。

clawhip —— 传话员 / 大管家（通知路由层）

它盯着 git 提交、tmux 会话、GitHub 的 issue 与 PR、agent 生命周期事件，负责把"谁完成了、谁失败了、该通知谁"送出去。关键设计：监控与通知被移出 agent 的上下文窗口，让 AI 把有限的"工作记忆"全部花在写代码上，而不是状态格式化与消息投递。

技术落地：事件被写成追加式账本（.omx/ultragoal/ledger.jsonl），每条带时间戳与来源；目标状态有专门 JSON（get-goal-*.json）与质量门记录（quality-gate-*.json）。"路由"的产物同样留在仓库里，可审计、可回放。

OmO —— 会议室主持人（协调层）

它处理多 agent 之间的规划、交接、分歧解决与验证循环。当"架构师"说该这样写、"执行者"动手写了、"评审者"说不行——三个 AI 意见不一致时，OmO 提供让讨论收敛的结构，而不是让它们僵住或乱套。

技术落地：在运行时层面，对应的是 task_registry.rs（任务生命周期：create/get/stop/update/output）、policy_engine.rs（策略规则：And/Or/GreenAt/StaleBranch 条件，MergeToDev/RecoverOnce/Escalate 动作）、recovery_recipes.rs（7 种失败场景的恢复配方 + 尝试账本）。分工由 worker/leader 结构承载：worker 并行执行，leader 负责合并与验证。

上下文窗口：为什么"把通知搬出去"是对的

上下文窗口（context window）是 agent 一次能"记住"的 token 上限——Claude 系列约 200K，部分模型支持 1M。它是最稀缺的资源之一，因为：

成本：API 按 token 计费，上下文越长每次调用越贵；
质量：上下文过满会触发压缩（compaction），压缩会丢细节，模型行为可能漂移；
延迟：超长上下文降低首 token 速度。

所以成熟产品都在做"省上下文"：Claude Code（对照 ccleaks 泄露源码）有 auto-compact、context collapse、CLAUDE_CODE_MAX_CONTEXT_TOKENS 等机制；claw-code 则提供会话持久化、--resume、token/成本统计。clawhip 把通知外置，是同一思路在架构层面的体现——谁先学会给 agent 省上下文，谁就拿到了免费的算力。

哲学原文 · 三部分系统PHILOSOPHY.md▶

The Three-Part System 1. OmX (oh-my-codex) — the workflow layer. It turns short directives into structured execution: planning keywords, execution modes, persistent verification loops, parallel multi-agent workflows. 2. clawhip — the event and notification router. It watches git commits, tmux sessions, GitHub issues and PRs, agent lifecycle events, channel delivery. Its job is to keep monitoring and delivery outside the coding agent's context window. 3. OmO (oh-my-openagent) — multi-agent coordination. This is where planning, handoffs, disagreement resolution, and verification loops happen across agents. When Architect, Executor, and Reviewer disagree, OmO provides the structure for that loop to converge instead of collapse.

来源：claw-code/PHILOSOPHY.md

参考对照 · 上下文管理机制ccleaks.com/leaks（外部参考）▶

泄露源码分析列出的上下文相关机制（节选 + 中文注释）： · REACTIVE_COMPACT / CONTEXT_COLLAPSE / HISTORY_SNIP / CACHED_MICROCOMPACT —— 自动压缩、折叠旧上下文、历史摘要、缓存微压缩 · CLAUDE_CODE_MAX_CONTEXT_TOKENS —— 覆盖上下文上限 · AUTOCOMPACT_PCT_OVERRIDE —— 覆盖压缩触发阈值对照：claw-code 提供会话持久化 + --resume + compaction + token/成本统计，思路同源。

来源：https://ccleaks.com/leaks · 外部参考，教学引用（节选 + 中文注释）

延伸学习资源（选读，不计入 40 分钟）

想深入三层系统背后的通用原理，按下面顺序读/看，每项 10–30 分钟：

🎬 视频 · Andrej Karpathy: Software Is Changing (Again)（YC AI Startup School，2025-06-17，约 40 分钟）——为什么"LLM 是新的计算机、提示词是新的程序"，以及 Iron Man 类比（增强 vs 代理）。
youtube.com/watch?v=LCEmiRjPEtQ
📄 文章 · Anthropic: Building Effective Agents——五种 agent 设计模式（prompt chaining / routing / orchestrator-workers / evaluator-optimizer），其中 orchestrator-workers 正是 OmO 的抽象。
anthropic.com/research/building-effective-agents
📄 综述 · Lilian Weng: LLM Powered Autonomous Agents——agent 架构参考级深度文：规划 / 记忆 / 工具三件套。
lilianweng.github.io/posts/2023-06-23-agent/
📄 标准 · Anthropic: Introducing MCP——"MCP 之于 LLM 工具集成，就像 USB-C 之于外设"；claw 的 mcp 子命令对接的就是这个标准。
anthropic.com/news/model-context-protocol
📄 教程 · Andrew Ng: Agentic Design Patterns——四种基础模式：反思 / 工具使用 / 规划 / 多智能体协作。
deeplearning.ai/the-batch/how-agents-can-improve-llm-performance/

思考题

Q1 · 如果通知路由不搬出去、让 agent 自己处理全部消息，最可能出什么故障？请从"上下文被占满"推导一个具体失败场景。

提示：agent 上下文溢出后会发生什么（遗忘早期指令、重复劳动、行为漂移）？

Q2 · 三层的划分（工作流/路由/协调）可以类比到人类组织。如果让你把一个小团队也这样分层，你会怎么分？

提示：项目经理（OmX）、行政/通知（clawhip）、跨组协调会（OmO）。

Q3 · 参照 ccleaks：Claude Code 用"自动压缩 + 折叠旧上下文"省 token，claw-code 用"外置通知 + 会话持久化"省上下文。两种策略各自的取舍是什么？

提示：前者在"同一上下文内瘦身"，后者在"上下文之外分流"；哪个更容易丢信息？