Claude Code、OpenAI Codex 与 DeepSeek Harness 架构对比

对比Claude Code、OpenAI Codex与DeepSeek Harness架构，揭示Coding Agent能力上限的关键——Harness而非模型。
核心内容：
1. 三者技术路线差异（Claude Code、Codex、DeepSeek Harness的不同定位）
2. Harness的核心作用及关键职责（决定能力上限的架构设计）
3. 共同的Agent Loop执行流程（循环机制与工程问题处理）

Coding Agent 的竞争经常被理解成模型能力的竞争：Claude、GPT、DeepSeek 谁写代码更强，谁的推理更稳定，谁能一次完成更大的仓库级任务。

但如果真正去研究 Claude Code、OpenAI Codex 和 DeepSeek Harness 的架构，会发现决定 Coding Agent 能力上限的因素已经不只是 Model，而是 Model 外面的 Harness。模型负责理解问题、推理和生成动作，

一个裸模型的执行过程通常只是 Input → Model → Output，而真正的 Coding Agent 则需要持续完成 Context Construction → Model Inference → Tool Call → Tool Execution → Tool Result → Context Update → Model Again 的循环，同时还要处理 Session、Memory、Permission、Sandbox、Skills、MCP、Subagent、Context Compression、Background Job 和 Observability 等大量工程问题。DeepSeek Harness 甚至直接把 Agent 概括为 Model + Harness，这其实很好地解释了为什么今天即使使用同一个模型，不同 Coding Agent 的实际体验和任务完成率仍然可能存在明显差异。

框架都有 Agent Loop

无论 Claude Code、Codex 还是 DeepSeek Harness，底层都绕不开一个基本的 Agent Loop。用户提出任务以后，Harness 首先构造模型上下文，然后调用模型；模型如果直接给出最终答案，当前 Turn 就可以结束，如果模型产生 Tool Call，Harness 就执行对应工具，将执行结果重新加入上下文，再次调用模型，直到模型认为任务已经完成。

如果用伪代码表示，这个过程并不复杂：

while True:
    context = build_context()

    response = model(
        context=context,
        tools=tools,
    )

    if response.is_final:
        break

    tool_result = execute(response.tool_call)

    append_to_context(
        response,
        tool_result,
    )

OpenAI 在介绍 Codex Agent Loop 时公开描述的基本流程也是如此：Harness 负责向模型发起 inference，模型可能返回最终回答，也可能产生工具调用；如果产生工具调用，Harness 执行工具，再把结果加入下一轮模型上下文。因此，一个用户 Turn 往往并不对应一次模型请求，一个复杂的 Coding Task 内部可能包含几十次甚至更多 Model、Tool 和 Context 更新。

真正拉开三者差异的，并不是有没有这个循环，而是谁控制 build_context()、execute_tool()、persist_session()、check_permission()、run_sandbox()、spawn_agent() 和 compact_context()，以及最重要的 agent_loop() 本身能不能重新定义。Claude Code、Codex 和 DeepSeek Harness 的核心架构差异，基本都可以从这个问题展开。

Claude Code：把 Harness 做成完整的开发者工作台

Claude Code 最初给人的印象很像一个运行在 Terminal 中的 Coding Agent，但它现在已经明显超过了“Claude + Shell”这个简单组合。Anthropic 在同一套 Claude Code Engine 周围逐渐建立了 CLAUDE.md、Memory、Skills、MCP、Hooks、Permission、Sandbox、Subagents、Background Agents 和 Agent SDK 等能力，并把同一套 Engine 延伸到 Terminal、IDE、Desktop 和 Web 等不同使用环境。

从架构上看，Claude Code 的核心思路并不是让开发者重新定义 Harness 内核，而是在一个相对稳定、成熟的 Agent Engine 周围提供越来越多的扩展层。开发者通常不需要关注 Agent Loop 本身是如何实现的，而是通过项目指令、Skill、Tool、Hook、Subagent 和 SDK 去影响这个 Loop 的行为。

可以把它简化为：

Claude Code Engine
        │
        ├── Context
        │   ├── CLAUDE.md
        │   ├── Memory
        │   ├── Skills
        │   └── Conversation
        │
        ├── Tools
        │   ├── Bash
        │   ├── Files
        │   └── MCP
        │
        ├── Hooks
        ├── Permission
        ├── Sandbox
        └── Subagents

CLAUDE.md

Claude Code 通过 CLAUDE.md 和 Memory 把这类信息放到 Harness 的 Context Construction 阶段。换句话说，Repository 不再只有面向人的 README 和 Source Code，还开始出现专门面向 Agent 的工程说明。模型每次进入项目时，可以重新获得项目结构、代码规范、测试方式和操作边界，而不是完全依赖当前聊天记录。

Claude Code 中的 Context 并不只是 Conversation History，而是由 System Instructions、Project Instructions、Memory、Skills、Tool Description、当前文件内容、Tool Result 和 Subagent Result 等多种来源共同构成。这个变化非常重要，因为复杂 Agent 的能力越来越取决于 Harness 能否持续构造一个高质量 Context，而不是单纯依赖模型一次性理解全部仓库。

Skill

Skill 的价值并不只是保存 Prompt。更重要的是，它把 Instructions、References、Scripts 和 Assets 组织成一个可复用能力，而且这些内容不需要全部从会话开始就常驻 Context。Harness 可以先让模型知道有哪些 Skill，在真正需要某个 Skill 时再读取对应的 SKILL.md 和辅助文件。

随着 Coding Agent 中 Tool、Skill 和知识库越来越多，这种按需加载会越来越重要，因为如果所有说明文档、工具 Schema 和开发规范从一开始全部放进上下文，Context Window 很快就会被低价值信息占满。

Hook

Hook 的价值就在于把这些行为从 LLM Decision 移到 Deterministic Program 中。模型依然负责理解任务和决定大部分行动，但 Formatter、Validation、Audit 和 Policy Enforcement 可以由 Harness 在固定生命周期节点中强制执行。

Claude Code 实际上形成了一种分层执行模型：需要智能判断的事情交给 LLM，需要固定执行的事情交给 Hook，需要操作系统级安全边界的事情则交给 Sandbox。不同可靠性要求的任务被放到不同层，而不是全部依赖 Prompt。

Permission

Claude Code 的另一个重要设计是把 Permission 和 Sandbox 分开。Permission 主要回答“模型提出的这个动作是否允许执行”，而 Sandbox 回答的是“即使允许执行，这个动作最多能够访问什么资源”。

Coding Agent 的安全已经逐渐从简单的“允许 Shell / 禁止 Shell”演变成 Permission、Approval、Filesystem Isolation 和 Network Isolation 等多层机制。

Subagent

Claude Code 的 Subagent 允许不同 Agent 拥有自己的 Context、System Prompt、Tool Access 和 Permission。Explorer Agent 可以负责大量阅读代码，Tester Agent 可以运行测试，Reviewer Agent 可以专门检查 Diff，而主 Agent 最终只需要接收这些 Agent 的结果摘要。

Subagent 并不只是“多开几个模型进行并行计算”，它更重要的意义是通过任务边界建立 Context Boundary。主 Agent 不需要保存 Explorer 阅读过的所有文件，只需要知道 Explorer 最终得出了什么结论。这也是为什么 Multi-Agent 与 Context Engineering 实际上高度相关。

Codex：把 Coding Agent 做成可复用的 Runtime

相比 Claude Code 强烈的开发者产品属性，OpenAI Codex 的架构给人的感觉更像一个正在逐渐独立出来的 Agent Runtime。Codex 开源仓库主体使用 Rust 实现，核心能力并不只服务于一个 Terminal UI，而是逐渐形成了 Codex Core、Thread、App Server、Tool Runtime、Sandbox 和 Approval Policy 等相对清晰的边界。

可以粗略理解成：

CLI / IDE / App / Other Client
            │
            ▼
        App Server
            │
            ▼
        Codex Core
            │
      Agent Loop
            │
     Tool Runtime
            │
  Approval / Sandbox
            │
      Local System

Codex Core

Codex Core 负责的并不只是模型 API 调用，而是完整的 Agent Logic，包括上下文构造、Model Inference、Tool Execution、Thread Persistence 和多轮 Agent Loop。于是 Codex Model 和 Codex Agent 实际上是两个完全不同的概念：Model 提供推理能力，而 Agent 则是 Model 加上 Core、Tool Runtime、Context、Sandbox、Policy 和 Session 形成的完整系统。

AGENTS.md 与 CLAUDE.md

Codex中的AGENTS.md和Claude Code中的CLAUDE.md在功能上极为相似，均用于解决代码仓库向Agent描述长期工程规则的问题。在项目的AGENTS.md中，可以记录架构约束、开发规范、测试命令、目录职责以及代码修改规则等内容。Codex在构建Context时会读取这些信息，并结合当前Session和其他输入生成模型Prompt。

Codex Skill

Codex 当前同样支持 Skill，并且它对 Context Cost 的考虑非常明显。系统不会简单把所有 Skill 的完整内容全部塞进模型上下文，而是先提供名称、描述和路径等少量信息，在模型真正选择某个 Skill 后，再进一步读取完整 SKILL.md 和Supporting Resources。

Claude Code 和 Codex 在这一点上已经出现明显趋同，因为两者面对的是同一个问题：当 Agent 拥有几十个甚至几百个可复用能力以后，Context 不可能长期保存每个能力的完整 Instructions。能力必须首先可以被发现，然后在需要时再被展开。

App Server

Codex 架构中非常值得关注的是 App Server。它提供一个独立的协议层，让不同 Client 通过接口驱动 Agent Runtime，而不是要求所有 UI 直接嵌入 Codex Core。

例如 Thread 的启动、恢复和分叉，可以通过类似 thread/start、thread/resume 和 thread/fork 的接口完成。这样 UI 层只需要负责用户交互和状态呈现，而真正的 Agent Execution、Thread Management 和 Tool Runtime 则由后面的 Core 负责。

Thread

Codex 另一个明显特点是把 Thread 当作一等对象来管理。Thread 不只是聊天消息列表，而是一个完整的 Agent Execution Context，内部包含多个 Turn、工具执行、状态和历史信息。系统围绕 Thread 提供 Start、Resume、Fork、Read、List、Persistence 和 Compaction 等能力。

如果把代码仓库中的 Git Branch 理解成 Code State 的分叉，那么 Thread Fork 某种程度上就是 Agent State 的分叉。这个能力对于复杂调试、方案探索和多 Agent 并行都非常有价值。

DeepSeek Harness：把 Harness 自己变成 Framework

DeepSeek Harness 是三者中架构思路最激进的一个。它并不只是希望实现一个“DeepSeek 版本的 Claude Code”，而是直接把 Agent Harness 本身作为主要研究对象。官方给出的核心思想是 Everything is a plugin，也就是说 Model、Tool、Skill、Session、Sandbox、Storage、Agent Loop、Scheduling 和 UI 等能力尽可能都通过插件参与 Runtime，而不是全部写死在一个不可替换的 Agent Core 中。

DeepSeek Harness 当前仍处于 Developer Preview，因此如果单纯从产品成熟度、日常 Coding 体验和生态完整度进行比较，它还不能简单和 Claude Code 或 Codex 放在同一个评价尺度上。但如果关注的是 Agent Runtime 架构本身，它反而非常值得研究，因为它把很多通常隐藏在 Coding Agent 内部的机制直接变成了显式抽象。

Cordis

DeepSeek Harness 底层使用的 Cordis 并不是一个普通 Plugin Manager，而更接近一套用于 Runtime Composition 的基础框架。插件可以向共享 Context 中贡献 Service、Typed Event 和 Reversible Effect，Model Adapter、Tool Registry、Session Log，甚至 Agent Loop 本身都可以通过插件参与组合。

Claude Code 和 Codex 同样允许通过 Skill、MCP、Hook 或其他机制扩展能力，但它们背后仍然存在一个相对明确的 Stable Agent Engine 或 Codex Core。DeepSeek Harness 则进一步尝试把这个 Core 拆成一组可组合 Capability。

Agent Loop

如果 Agent Loop 被写死在 Core 中，实验新结构通常意味着 Fork Runtime，然后维护一套自己的核心代码。DeepSeek Harness 的思路则是把 Loop 自己也放到可组合层，通过替换 Agent Loop Plugin 改变整个 Agent 的运行模式。

这也是 DeepSeek Harness 与 Claude Code、Codex 最本质的架构差异之一。Claude Code 主要让用户扩展一个已经设计好的 Agent，Codex 主要让开发者围绕一个相对稳定的 Runtime 构建 Client 和 Workflow，而 DeepSeek Harness 则更接近允许开发者重新定义“这个 Agent 到底应该怎样运行”。

Profile、Bundle 和 Plugin

DeepSeek Harness 并不是简单启动一个固定 Agent，而是先通过 Profile、Bundle、Plugin 和 Patch 组合一个 Runtime。Profile 可以决定使用哪个模型 Provider、加载哪些 Tool、选择哪种 Sandbox、使用什么 Session Store、运行哪种 Agent Loop，以及是否启用 Subagent 和 UI。

Tool Execution

DeepSeek Harness 对 Tool 的处理也体现了同样的设计思路。Tool Execution 不只是简单调用 tool(args)，而是存在 Pre、Execute 和 Post 等生命周期事件。

于是一次工具调用可以经历：

Tool Call
   ↓
Pre Event
   ↓
Permission / Policy
   ↓
Execute
   ↓
Post Event
   ↓
Tool Result

这样 Logging、Tracing、Permission、Caching、Retry、Metrics、Evaluation 和 Security 等横切能力就可以统一插入 Tool Runtime，而不需要每个工具分别重复实现。

Runtime Mode

DeepSeek Harness还设计了多种不同的运行模式，具体如下：

• Standard
  ：这种模式更接近完整的Coding Agent，它包含了Files、Shell、Search、Skills、Plan、Goals和Subagents等功能模块。

• Minimal
  ：此模式保留了更基础的执行能力，主要方便用于测试最小的Agent Runtime。

• Creation
  ：该模式更加强调Runtime Inspection（运行时检查）、Plugin Experiment（插件实验）和Preset Creation（预设创建）。

三种框架综合对比

Claude Code 的路线可以概括成“先把 Agent 做好，再让开发者扩展它”。它首先提供一个完整、成熟、面向软件开发的 Agent Engine，然后通过 CLAUDE.md、Skill、MCP、Hook、Subagent 和 Agent SDK 让开发者逐渐增加能力。这种路线最大的优势是产品体验好，开发者不需要理解 Harness 内核，也能直接完成真实代码修改、Debug、测试和重构。

Codex 的路线更接近“先建立稳定 Runtime，再让不同客户端和工作流围绕 Runtime 构建”。Codex Core、Thread、App Server、Sandbox 和 Approval Policy 形成了比较明确的系统边界，使 CLI、IDE、Desktop、Automation 和其他 Agent Client 可以建立在同一套底层 Runtime 上。这种架构很适合未来构建 Coding Agent Platform，而不仅仅是一个命令行工具。

DeepSeek Harness 的路线则更接近“不要过早定义唯一的 Agent Core，而应该提供组合 Agent Runtime 的机制”。它尝试把 Model、Tool、Session、Sandbox、Prompt、Agent 和 Agent Loop 等组件全部放入可组合体系，让研究者能够重新定义 Agent 的执行逻辑，而不是只扩展一个已经固定的 Agent。

Claude Code 使用 CLAUDE.md、Memory、Skills 和 Subagent Context 管理它；Codex 使用 AGENTS.md、Skills、Thread 和 Compaction 管理它；DeepSeek Harness 更进一步，通过 Session Event Stream 派生 Model Messages，把 Context Construction 本身纳入 Runtime。

Claude Code 通过 MCP、Permission、Sandbox 和 Hooks 管理这些能力，Codex 把 Tool Execution 与 Approval 和 Sandbox 纳入 Runtime，DeepSeek Harness 则进一步把 Tool Registry 和 Tool Lifecycle Event 本身设计成可组合能力。虽然三者具体实现方式不同，但最终都在说明同一个趋势：Agent Tool 已经不再只是一个函数，而是一套受 Runtime 管理的执行能力。

登录查看剩余 70% 内容