# 第 1 章 为什么要把 Claude Code 和 Codex 放在一起看

## 1.1 因为它们比较的是对模型的不信任

如果把 Claude Code 和 Codex 当作两个“会写代码的助手”，那比较就会很无聊。无非是谁支持更多工具、谁的终端体验更顺手、谁的配置项更细。这些东西当然有用，但它们不解释为什么系统会呈现出今天这种形态。

真正值得比较的地方，是它们都承认了一件对产品宣传不太友好的事实：模型不能直接拿来当执行体。它会误判，会忘记上下文，会把语气里的自信和结论里的正确性混为一谈。一旦这种东西接上 shell、文件系统和多轮状态，问题就不再是“答得对不对”，而是“它做过的事以后谁来收拾”。

Claude Code 在这一点上表现得很像一个做过事故复盘的系统。你看 `query.ts`、`toolOrchestration.ts`、`compact.ts` 以及 Bash 相关 prompt，就会发现它对失败、膨胀、中断和误操作的想象力很丰富。一个系统如果老是预设好几种失败路径，通常是因为它见过太多乐观主义留下的烂摊子，而不只是因为悲观。

Codex 则是另一种诚实。它把“不信任模型”落实为显式模块边界。`core/src/lib.rs` 里把 `instructions`、`skills`、`sandboxing`、`exec_policy`、`rollout`、`state_db_bridge`、`thread_manager` 等器官明明白白列出来，等于是在说：秩序不能靠模型自己领会，得靠系统把职责拆出来。

所以比较这两者，是为了看两种不同的驯化路线，而不是为了看谁更会调用命令。

## 1.2 Claude Code 代表一种运行时优先的驯化路线

Claude Code 的很多精华，发生在主循环附近。这不是偶然。因为它的问题意识本来就很强烈地围绕“会话如何连续”展开。系统不只是要回答，还要在回答之后继续存在；不只是要执行，还要在执行之后保留秩序。这种压力会让架构自然向运行时编排倾斜。

因此它的关键词是：

- query loop
- compact
- tool orchestration
- interrupt
- permission ask/allow/deny
- forked agent lifecycle

这些词看上去都不像品牌文案，更接近值班表。可一个系统到了真的要干活的时候，值班表往往比愿景更重要。

Claude Code 的长处也因此很鲜明。它对“连续工作中的脏活”特别敏感：消息膨胀、输出截断、工具结果回灌、上下文裁剪、子代理状态隔离、验证阶段独立、hook 生命周期收口。这些东西不是光靠一套漂亮接口定义就能解决的，必须经过运行时一轮轮摔打。

## 1.3 Codex 代表一种显式控制面优先的驯化路线

Codex 的气质不太一样。它当然也有运行时，但更引人注目的，是它把控制层尽量做成显式结构。

在 `instructions/src/fragment.rs` 和 `user_instructions.rs` 里，用户指令和 skill 指令会以带有清楚 marker 的 contextual fragment 进入 prompt，而不是随便拼接。`AGENTS.md` 的内容会被包装成明确边界的用户消息，skill 也会以 `<skill>` 片段注入。这说明 Codex 对控制面有一种近乎文书工作的偏爱：它并不拒绝灵活，但不愿让灵活失去边界。

同样，`tools/src/lib.rs` 和 `local_tool.rs` 也很说明问题。工具是一组 schema 化的构造结果，而不只是一堆运行时对象。`exec_command`、`shell`、`write_stdin`、`request_permissions`、`spawn_agent`、`wait_agent` 等工具，在系统里首先是接口定义，其次才是执行动作。

再看 `execpolicy/src/lib.rs`，审批和执行限制甚至被做成单独 crate，包含 `Policy`、`Rule`、`Evaluation`、`Decision`、parser 等概念。这种做法其实很少见。很多系统也有权限策略，但往往散落在运行时各处；Codex 则把它往“可解析的政策语言”那一边推了一步。

## 1.4 两者都在回答同一个问题，但起笔位置不同

从更高处看，这两套系统都在回答同一个问题：

如何让一个会说话、会调工具、但本质不可靠的模型，在工程环境里做出可接受的事？

Claude Code 的起笔位置更接近：

“模型已经在循环里了。我们怎样保证它这一轮不会把下一轮弄坏？”

Codex 的起笔位置更接近：

“模型会接触很多控制信息。我们怎样把这些信息做成显式、可组合、可策略化的结构？”

前者强调流转，后者强调分层。前者把秩序安在 runtime heartbeat 上，后者把秩序安在 typed substrate 上。两者都不轻信模型，但它们把“不信任”安放在不同地方。

## 1.5 为什么这种差异值得团队认真看

因为一个团队以后会形成什么样的工作方式，常常取决于它最先把秩序放在哪。

如果你先强调运行时连续性，团队自然会更关注：

- 错误恢复
- 中断响应
- 状态污染
- 工具编排
- 长会话可靠性

如果你先强调显式控制面，团队自然会更关注：

- 指令边界
- 配置层级
- tool schema
- policy 语言
- thread state 与持久化

两种方向都没有错。错的是混着用，最后既没有运行时纪律，也没有清楚的控制层，只剩一堆可以演示、但不好维护的聪明把戏。

## 1.6 本文的基本判断

这一章先把全文立场摆明：

> Claude Code 和 Codex 代表的是两种 harness 设计哲学，而不只是两个“谁功能更全”的产品。

它们殊途同归，是因为都知道模型不可信，真正可信的只能是约束结构。

它们各表一枝，是因为一个更接近从现场经验里塑出来的运行时系统，另一个更接近由类型、策略和线程模型塑出来的控制系统。

下面的章节，就沿着这条判断往下拆。