终端 AI 编程工具横评：Codex CLI（Rust）vs Claude Code（TypeScript）——实现架构、安全模型、多模型桥接全方位对比

2025 年以来，终端 AI 编程工具成为开发者社区最热门的方向。OpenAI 的 Codex CLI 和 Anthropic 的 Claude Code 是目前最受关注的两款产品。两者定位相似，但技术架构差异很大。本文从实现语言、Agent Loop、安全模型、上下文管理、MCP 集成、多模型支持六个维度做逐一对比。

一、实现语言与运行时

Claude Code 用 TypeScript 编写，运行在 Node.js 22+ 上。作为 npm 包分发，安装后直接通过 claude 命令调用。Codex CLI 最初也是 Node.js/TypeScript 项目（2025 年中），2025 年底用 Rust 重写了约 95% 的代码（即 codex-rs crate），npm 安装包只是一个下载器，实际运行的是预编译的 Rust 静态二进制。

这个差异带来的实际影响：

二、Agent Loop 架构

两者都采用经典的 ReAct（推理-行动）循环，但在 API 层和协议设计上有明显差异。

Claude Code 基于 Anthropic 的 Messages API。每次循环构建 messages 数组，调用 API，解析 tool_use 块，本地执行后将 tool_result 追加回 messages，再次调用。支持 streaming 和 non-streaming 两种模式，Claude 的 extended thinking 功能让模型可以先输出思考链再输出工具调用。

Codex CLI 基于 OpenAI 的 Responses API（不是 Chat Completions）。每次循环构建结构化 prompt（instructions + tools + input），调用 Responses API，通过 SSE 流式返回。Responses API 的工具调用是原生能力，不需要像 Chat Completions 那样手动解析 tool_calls 字段。input 列表的优先级排序（system > developer > user > assistant）也给了客户端更精细的控制。

关键差异：Responses API 是 OpenAI 专门为 Agent 场景设计的接口，prompt caching、compaction、ZDR 等企业级功能都绑定在这个 API 上。Messages API 同样是 Anthropic 的原生接口，但协议层面对 Agent 场景的专门优化不如 Responses API 深入。

三、安全模型（最大差异点）

这是两者架构差异最大的地方。

Claude Code：应用层钩子

Claude Code 在客户端进程内设置了 17 个拦截点（hooks），包括 PreToolUse、PostToolUse、PreCompact、SessionStart、PermissionRequest 等。通过 settings.json 配置规则，可以精细控制每条命令的执行权限：

{
  "permissions": {
    "allow": ["Bash(git *)", "Read"],
    "deny": ["Bash(rm -rf *)"]
  }
}

优点：灵活，可针对单条命令做精细控制。缺点：拦截在应用层执行，理论上存在绕过可能。

Codex CLI：操作系统内核层沙箱

Codex 在操作系统内核层执行安全策略，而非应用层：

1. macOS：通过 sandbox-exec 使用 Apple Seatbelt 框架
2. Linux：Bubblewrap 文件系统命名空间 + seccomp 系统调用过滤 + Landlock LSM
3. Windows：通过 WSL 运行 Linux 沙箱

配合三级沙箱模式（read-only / workspace-write / danger-full-access）和三级审批模式（ask / auto / never），安全限制在操作系统层面执行，模型输出无法绕过。

安全模型对比

四、上下文管理与 Compaction

长会话中上下文窗口耗尽是 Agent 工具的普遍问题，两者的处理方式不同。

Claude Code 的 auto-compact 是客户端逻辑。当上下文接近上限时，将早期对话压缩为摘要。支持的上下文窗口取决于模型（Claude Sonnet 4.5 为 200K）。CLAUDE.md / AGENTS.md 作为持久化系统指令注入每轮对话。

Codex CLI 的 compaction 是 API 端能力。调用专用的 /responses/compact 端点，返回列表替换原始输入，其中包含加密的特殊 compaction 项，服务端在推理时解密。这种方式支持 Zero Data Retention（ZDR）模式——OpenAI 存储解密密钥而非对话数据。GPT-5.4 默认上下文 272K，可扩展至 1M tokens。

关键差异：Codex 的 compaction 在 API 服务端完成，支持 ZDR 企业合规。Claude Code 的 compaction 在客户端完成，实现更简单但无法提供同等级别的数据隔离保证。

五、MCP 集成

两者都支持 MCP（Model Context Protocol），但角色不同。

Claude Code 仅作为 MCP Client 连接外部 MCP 服务器，扩展工具能力。配置在 .claude/settings.json 中，支持 stdio 和 HTTP 两种传输。

Codex CLI 支持双重角色：MCP Client 连接外部服务器，MCP Server（实验性）将 Codex 自身暴露为工具供其他 Agent 调用。v0.120.0 新增 outputSchema 支持，使 MCP 工具在代码模式下能输出结构化结果，便于 Agent 串联。

关键差异：Codex 的双重 MCP 角色使其可以嵌入更大的 Agent 编排体系，Claude Code 目前仅作为消费者。

六、多模型支持（重要差异）

这是两者生态策略的根本分歧。

Claude Code：封闭生态

Claude Code 官方仅支持 Anthropic 模型，不提供 base_url 配置，不支持 Ollama、vLLM 等本地推理服务，也不支持通过代理转发到其他模型端点。认证方式仅限 Anthropic API Key 或 Claude 订阅。

Codex CLI：开放 provider 框架

Codex CLI 原生支持自定义 provider 配置。通过 config.toml 中的 model_providers 块，可以将请求指向任何兼容 OpenAI Responses API 的端点：

model = "deepseek-chat"
model_provider = "deepseek"

[model_providers.deepseek]
name = "DeepSeek"
base_url = "https://api.deepseek.com"
env_key = "DEEPSEEK_API_KEY"
wire_api = "responses"

已验证可用：DeepSeek、OpenRouter、Ollama、LM Studio、Azure OpenAI、LiteLLM 等。环境变量方式更简单：

export OPENAI_API_KEY="***"
export OPENAI_BASE_URL="https://your-endpoint.example/v1"
codex

注意事项：目标端点必须支持 Responses API（wire_api = "responses"），仅支持 Chat Completions 的端点需要通过 LiteLLM 或 OpenRouter 做协议转换。模型必须支持 tool calling，否则 Codex 无法编辑文件。

七、综合对比

八、选型建议

需要精细的命令级安全控制、已深度使用 Anthropic 模型、需要成熟的多 Agent 协作——选 Claude Code。

需要 OS 级不可绕过沙箱、低资源占用和快速启动、企业 ZDR 合规、需要桥接 DeepSeek 等多模型、需要将 Codex 嵌入更大 Agent 编排体系——选 Codex CLI。

两者都是目前最先进的终端 AI 编程 Agent，架构选择反映了两家公司的工程哲学：Anthropic 偏向灵活可配置，OpenAI 偏向安全和开放生态。

如果你觉得本文有用，请点赞，收藏，转发

你有什么问题，请留言，我来帮你解答。