# 第 7 章 殊途同归，还是各表一枝

## 7.1 先说“同归”的部分

要是只问结论，我会先说：它们确实殊途同归。

原因很简单。Claude Code 和 Codex 都不把模型当作值得直接托付的执行体。它们都承认：

- prompt 不等于控制全部
- 工具必须受约束
- 长会话一定需要状态治理
- 本地规则必须进入系统
- 多代理必须有分工和验证

换句话说，它们都已经越过了那种“只要模型更强，系统问题就会自动消失”的幼稚阶段。谁能走到这一步，谁就已经不再把 agent 当成聊天机器人带几把工具那么简单。

所以从总体方向看，它们确实在同一个目的地上会合：把 harness 当成真正的控制层，把模型当成这层控制之下最不稳定、但也最有生产力的部件。

## 7.2 再说“各表一枝”的部分

但要是因此说它们本质一样，那就太粗糙了。

Claude Code 的主轴更像这样：

- 从 query loop 出发
- 在运行时处理连续性
- 用 compact、工具编排、中断和恢复维持秩序
- 用技能、hook、验证把现场规则和团队制度接进来

Codex 的主轴更像这样：

- 从模块边界和控制层显式化出发
- 把 instruction 做成 fragment
- 把工具做成 schema
- 把执行边界做成 policy
- 把会话做成 thread / rollout / state
- 把本地规则与 hook 做成结构化资产和事件系统

前者像从机械经验里塑出来的系统。

后者像从制度设计里塑出来的系统。

这就是“各表一枝”的地方。差别不在目的，而在骨架。

## 7.3 如果非要给它们起一个更难听但更准确的名字

我甚至愿意把它们叫作两种不同的 harness 政体。

Claude Code 比较接近运行时共和制。很多权力集中在主循环和现场调度上，秩序通过不断的现实协商来维持。它并不是不讲制度，只是制度往往服务于会话现场。

Codex 比较像控制面立宪制。很多权力首先被写进类型、片段、策略、线程和事件系统里，运行时当然还要做判断，但那套判断更倾向于在明确框架下展开。

这么说当然有点夸张，不过有助于看清一件事：harness 从来不只是技术组件堆积，它也是一种权力分配方式。谁定义边界，谁解释状态，谁拥有最后的执行解释权——这些事情最后都会体现在架构里。

## 7.4 对后来者的启发

如果团队准备做自己的 coding agent，这份比较真正有用的地方，是帮你少犯两类错误，而不是让你选边站。

第一类错误，是误以为只要学一套功能表就够了。其实不够。你得先决定自己的主要矛盾是什么。是长会话里容易失控，还是规则来源太散、权限边界不清？不同矛盾，会把你推向不同 harness 形态。

第二类错误，是试图把两者最顺眼的特性不加判断地拼在一起。工程上最危险的往往不是取舍，而在没有取舍。你既想要完全动态的运行时灵活性，又想要彻底显式的结构化控制面，最后多半会得到两头都不彻底的系统。

更合理的做法是：

- 如果你更怕现场失控，就先把 runtime heartbeat 做扎实
- 如果你更怕制度失真，就先把 instruction、tool、policy、state 显式化
- 等主矛盾稳住，再逐步补另一边

这里还可以多加一个提醒。现实里很多后起系统既没有把运行时纪律做扎实，也没有把控制层显式化到位，而是走向第三种更容易上手、也更容易失控的路线：把越来越多的 bootstrap 文件、角色设定、技能说明和工作区文本堆进 prompt，试图靠“信息更全”弥补骨架不足。这类系统短期里常常显得能跑，长期里却容易同时暴露两类问题：token 烧得快，工作语义又不够稳。

## 7.5 最终判断

书名里的问题，现在可以正式回答。

它们是殊途同归。

也是各表一枝。

“同归”说的是最终承认的现实一致：模型不可靠，harness 才是秩序来源。

“各表一枝”说的是实现这个现实的政治经济学不同：Claude Code 更信运行时纪律，Codex 更信显式控制层。

而那些主要靠 prompt 堆叠来维持上下文的系统，则更像还停在中间地带。它们已经意识到模型会忘、会漂移，所以开始加 memory、加 skills、加 compact；但如果上下文治理仍然主要依赖“先注入，再抢救”，那就还没有真正决定把秩序放在哪一层。

这两种路径没有谁天然更高明。真正的问题是，你的系统准备把不确定性关进哪一层笼子里。

笼子的位置，决定了系统以后会演化成什么样。