前两篇我们做了两件事。

第一篇讨论了：

为什么模型越来越强以后，Harness 反而越来越重要。

第二篇进一步把 Agent Harness 拆成了六个基本问题：

Agent Loop · Context · Tool · Session · Sandbox · Permission

有了这套坐标，我们终于可以开始比较具体系统了。这一篇选三个很有代表性的样本：DeepSeek Harness、Claude Code、Codex。

它们表面上都具备 LLM、Tool、Agent Loop、Context、Skill、SubAgent、Permission、Sandbox。如果只做功能对比，很容易得到一张"大家都有"的表格。

真正有意思的是：

三个系统面对同一个 Agent 问题，为什么会选择不同的架构？

这背后对应三种不同的设计哲学。先给出高度概括的判断：

Claude Code     怎样把一个 Agent 做得更强、更好用
Codex           怎样让一个 Agent 在真实计算环境中安全、自主地工作
DeepSeek Harness 怎样构建一个可以自由组合不同 Agent 能力的 Runtime

它们没有绝对的高低——它们在优化不同的问题。

一、共同起点：都是一个循环

无论 Claude Code、Codex 还是 DeepSeek Harness，最底层都有一个类似结构：

图 1 · Claude Code、Codex、DeepSeek Harness 的共同骨架

Claude Agent SDK 官方明确把自己的运行机制描述为 Claude Code 所使用的自主 Agent Loop：模型收到 Prompt、System Prompt、工具定义和历史信息后，根据任务选择工具、获得执行结果并继续循环。

OpenAI 对 Codex 的公开架构解释也把 Agent Loop 定义为 Codex Harness 的核心——它负责协调用户、模型以及模型调用的工具，并作为 Codex CLI、Cloud 和 IDE 等体验背后的执行逻辑。

DeepSeek Harness 的核心同样包含 Agent、Agent Loop、Session、System Prompt、Tool 和 LLM，只不过它把这些能力进一步拆成了 Cordis Plugin。

所以三者的基本原理并没有神秘差异。真正的差异发生在：

这套 Loop 的周围，应该怎样组织。

二、比较框架，先看"中心在哪里"

很多软件架构看起来模块差不多，但只要问一个问题，很快就能看出哲学差异：

整个系统最稳定、最重要的中心是什么？

先画三张极简图。

图 2 · 三张极简图：中心在哪里，哲学就在哪里

Claude Code 的中心很明显是一只 Claude Agent，外围能力都在增强它。

Codex 的中心依然是 Agent，但执行边界（Sandbox / Approval）非常突出。

DeepSeek Harness 的中心不再是一只 Agent，而更接近 Plugin Composition Runtime——连 Agent Loop 本身都只是一个可替换的实现。

模块列表相似不重要，"什么处在系统的中心、什么不可替换"才决定架构哲学。

三、Claude Code：先把一个 Agent 做到极致

如果把 Claude Code 的设计哲学浓缩成一句话：

围绕一个高能力模型，不断提供更好的上下文、更强的工具、更专业的经验和更精细的控制。

1、增强一个聪明人，而不是搭建一个系统

想象一个非常聪明的软件工程师。希望他工作得更好，你会给他什么？Claude Code 的扩展体系几乎可以一一对应：

图 3 · Claude Code 的增强体系：给聪明工程师配上整套工作系统

所以 Claude Code 很容易形成一种 Agent-centric Architecture：以一个核心 Agent 为中心，不断增强它。

2、Skill：能力正在从"代码模块"变成"经验包"

为什么 Claude Code 越来越强调 Skill？因为随着模型变强，很多问题已经无需重新开发一个软件功能。

过去想实现"自动做 Code Review"，可能需要写一个程序。现在可能只需要提供一套稳定的方法：先看 diff → 检查 API 兼容性 → 检查安全问题 → 检查测试覆盖 → 按固定格式输出。

这些东西本质是 Knowledge + Workflow + Instruction。官方文档中，Skill 被定义为可复用知识和可调用工作流，并且可以由 Claude 根据上下文自动使用。

未来很多 Agent 能力，可能更像"经验包"，而不是传统代码模块。

3、Hooks：把确定性控制重新插回 Agent

纯 Agent 有一个问题：模型决定"下一步干什么"非常灵活，但企业系统需要一些事情绝对确定——运行测试后必须检查结果、执行危险命令之前必须审批、结束任务之前必须执行校验、调用某工具时必须记录审计日志。这些逻辑不适合全部交给 LLM。

于是 Claude Code 提供 Hooks，可以挂载在 UserPromptSubmit、PreToolUse、PostToolUse、Stop、SubagentStart、SubagentStop、PreCompact 等生命周期节点上，阻止工具执行、修改输入、记录审计或注入上下文。

这意味着 Claude Code 并没有走向"所有事情都让模型决定"，而是越来越像：

Probabilistic Agent  +  Deterministic Hooks

这很可能是一种长期会保留下来的 Agent 架构形式。

4、SubAgent：真正有价值的是隔离，不是角色扮演

以前谈 Multi-Agent，容易变成"产品经理 Agent → 架构师 Agent → 程序员 Agent"几个角色互相聊天。Claude Code 的 Subagent 思路更实用：独立 Context、独立 Tool、独立 Permission、独立任务，最后只把结果返回主 Agent。

图 4 · SubAgent：一种上下文和执行隔离机制

主 Context 不需要装下所有中间搜索过程。这比单纯模拟角色有工程价值。

四、Codex：让 Agent 安全进入真实计算环境

如果 Claude Code 给人的感觉是"Agent 能力增强"，Codex 让我更关注另外一个词：Execution。

怎样让 Agent 真正进入一个开发环境，自主执行任务，同时把风险限制在明确边界里。

1、Agent 变得危险，是从"能说"变成"能做"开始的

一个 Coding Agent 可以修改文件、执行 Shell、安装软件、访问网络、读取凭据、操作 Git、调用外部服务。于是 Codex 非常强调 Sandbox + Approval。这两者的区别非常重要：

Sandbox   定义：技术上做得到什么
Approval  定义：当前被允许做什么

OpenAI 介绍内部部署 Codex 的安全架构时，把沙箱定义为 Agent 的技术执行边界（允许写入哪些路径、是否可以联网、哪些区域受保护），Approval Policy 则决定 Agent 什么时候必须停下来请求授权。

2、能力最小化：不是给权限再叮嘱，而是先受限再放行

Agent 安全的常见错误思路是"先给所有权限，然后告诉模型请小心使用"。更合理的方式是默认处在受限环境，允许常规低风险动作，遇到越界请求由策略判断、必要时审批：

图 5 · Codex 的能力最小化：Sandbox 先划边界，Approval 决定放行

OpenAI 当前公开的 Codex 安全实践还包括网络策略、身份与凭据管理、规则以及 Agent-native telemetry——都是围绕执行治理建立的。

3、Agent 正在获得自己的"操作系统"

早期 Coding Agent 更像 LLM + Terminal。现在越来越像：Agent 之上有一个 Runtime，管理 Sandbox、Rules、Approval，再往下才是 File / Git / Shell / Network。

这和操作系统解决的问题非常类似：进程能访问什么资源、有什么权限、如何隔离、如何调度。Agent Runtime 正在逐渐解决同样的问题。

4、治理开始进入 Runtime，观测也是

当 Agent 真正进入企业，问题不再只是"任务完成了吗"，还要回答：它做了什么？访问了什么？为什么触发审批？出了问题如何追溯？

图 6 · Observability 正在变成 Agent Runtime 的基础能力

Codex 并没有停留在"安全执行器"——它也在吸收 Skill 和 Plugin：Plugin 针对某类工作流打包能力，可以包含 Skills，也可以依赖连接数据和动作的 Apps。它的演进路径大致是：

Coding Agent → Safe Execution Agent → Extensible Agent Runtime → General Work Agent

五、DeepSeek Harness：把问题提到"Runtime 怎么组成"

DeepSeek Harness 和前两个系统最明显的差别，是它一开始就把自己命名成 Harness，并直接提出：

Everything is a Plugin。

这不是普通的插件系统——它连 LLM Adapter、Tool Registry、Session Log、Agent Loop 都插件化了。传统插件架构是"稳定核心 + 扩展插件"；DeepSeek Harness 里核心本身也被拆解，官方文档的描述非常直接：There is no privileged core to patch. 系统通过 Plugin 向共享 Context 提供 Service、Typed Event 和可逆 Effect，Agent Loop 本身也只是默认驱动实现。

1、Capability Seam：能力接缝

DeepSeek Harness 中另一个值得学习的概念是 Capability Seam。它把能力拆成 Service Definition、Service Provider、Consumer 三层。以文件系统能力为例：

图 7 · Capability Seam：Service Definition → Provider → Consumer

这对企业 Agent 平台很有吸引力：开发环境用 Local Process，生产要求 Container，某些客户要求 Remote Sandbox——如果上层 Agent 依赖的是 Shell Service 而底层 Provider 可替换，平台扩展性会非常强。

2、它在优化的是"组合自由度"

为什么这样设计？因为它假设未来 Agent Runtime 的形态不会只有一种。今天的 Coding Agent 可能采用 React Loop；明天的企业 Agent 可能是 Workflow + Agent；另一个可能是 Planner + Worker；长期 Agent 可能是 Goal + Schedule + Background Job。

于是 DeepSeek Harness 不希望 Agent Loop 成为永远不可变化的核心：

图 8 · 组合自由度：同一 Runtime 组装不同形态的 Agent

这是一种非常偏"平台架构师"的思路。

3、但自由度的代价同样明显

软件架构的规律：自由度越高，需要管理的复杂度通常也越高。

Claude Code 需要理解的大致是 Agent + Skill + Hook；DeepSeek Harness 需要理解 Cordis、Context、Service、Provider、Consumer、Effect、Event、Waterfall、Bundle、Profile、Patch、Scope……很容易出现"Runtime 非常优雅，使用者理解成本非常高"。它在解决平台级组合问题，这种复杂度不一定适合所有 Agent 产品。

六、把三者放在一起：一张表看清三种哲学

维度	Claude Code	Codex	DeepSeek Harness
核心中心	Claude Agent	Agent + 执行 Runtime	Composition Runtime
主要优化目标	Agent 能力与体验	安全自主执行	能力可组合性
Agent Loop	明确核心	明确核心	可替换 Plugin
Context	强调体验与自动管理	强调有界上下文	Context Service + Plugin
Tool	内置 Tool + MCP	Tool + MCP + Apps	Tool Registry + Seam
Skill	核心扩展方式之一	正在成为重要扩展方式	独立 Skill Capability
SubAgent	独立 Context 执行	向多 Agent 扩展	Provider 化的能力
Hook	非常丰富	Runtime 扩展机制	Event / Waterfall
Session	持续会话	Agent 运行状态	Event-sourced Session
Sandbox	Coding Environment	非常核心	可替换 Capability
Permission	丰富规则	Sandbox + Approval + Policy	Interaction / Policy Plugin
架构倾向	Agent-centric	Execution-centric	Runtime-centric

这张表最重要的不是具体功能，而是最后一行。Agent-centric、Execution-centric、Runtime-centric——三种倾向，对应三种哲学。

问"哪种设计最好"其实问错了——它们优化的目标不同，没有绝对赢家。

七、没有赢家：三类产品与两条路线

1、你的目标决定你该学谁

做体验极好的专业 Agent（Coding Agent、Research Agent、Data Agent、专业助手这类"一个主 Agent 完成复杂工作"的产品）——Claude Code 的思路很值得学：强模型 + 高质量 Context + 少而强的 Tool + Skills + SubAgents + Hooks + Permission。用户模型简单、能力边界清晰、容易围绕 Agent 建立体验。

Agent 要大量操作真实系统（改代码、操作数据库、调用生产接口、修改业务状态）——Codex 的思路更值得学。一旦 Agent 能行动，真正的架构难点就会从"模型够不够聪明"迅速变成"模型做错了怎么办"。重点放在 Sandbox、Approval、Network Policy、Credential Boundary、Execution Trace、Telemetry。

做 Agent 平台——不同模型、不同 Tool、不同 Sandbox、不同 Agent Loop、不同执行环境要共存时，DeepSeek Harness 的 Composable Runtime 思想非常有吸引力，那些看起来很重的抽象（Service / Provider / Plugin / Event）开始变得合理。

2、Agent 产品的三种层级

图 9 · 三类产品会长期共存

3、Product First 还是 Platform First

图 10 · Product First 与 Platform First 是另一个重要分叉

这里需要保持一点警惕。软件领域反复发生一件事：大家试图做一个万能平台，最后往往变成"平台能力很丰富，但真正的产品体验很弱"。一个支持 100 种配置的灵活平台，未必比"只把 Coding Agent 做好"更有价值。

4、三条路线正在互相吸收

今天我们把它们分成三种哲学，但未来它们很可能不断吸收彼此的思想：Claude Code 越来越强调 Hooks / Permission / SubAgent / Plugins；Codex 正在扩展 Skills / Plugins / Apps / Multi-Agent；DeepSeek Harness 已经提供 Skill / SubAgent / Workflow / Sandbox / Session / Goal / Jobs。

未来真正成熟的 Agent Runtime，很可能同时拥有优秀的 Agent Experience + 安全的 Execution Runtime + 可组合的能力架构：

图 11 · 三条路线的汇合点：未来 Agent Runtime 的雏形

八、从三者各学一件最重要的事

1、再往深一层：都在回答"控制权给谁"

把三个框架再抽象一层，会发现它们实际上都在回答同一个问题：模型究竟应该拥有多少控制权？

Claude Code 倾向于"模型拥有较强动态决策能力 + Hook / Permission 约束关键节点"；Codex 强调"模型自主行动 + Sandbox / Approval 定义执行边界"；DeepSeek Harness 则把控制机制本身也做成可组合能力。它们共同指向五类控制权的分配——理解权、规划权、路由权、执行权、终止权，分别属于 Model、Program、Policy 还是 Human：

环节	LLM	程序 / Runtime	Policy	人
理解问题	✓
生成计划	✓
选择工具	✓
参数校验		✓
权限判断			✓
高风险审批			✓	✓
工具执行		✓
超时终止		✓

这比"单 Agent 还是多 Agent"重要得多。而 Claude Code、Codex、DeepSeek Harness，其实只是对这张"控制权地图"给出了不同实现。

2、评价一个新框架，先问四个问题

以后再看到新的 Agent 项目，先别数它支持多少模型、多少 Tool、有没有 MCP 和 Multi-Agent。先问：

① 它把什么东西当作架构中心？

Agent？Workflow？Runtime？Event？Graph？中心决定了它的哲学。

② 它把哪些东西交给模型动态决定？

理解？规划？路由？执行？终止？交给模型的越多，灵活性越高，确定性越低。

③ 它怎样限制模型？

Workflow / Hooks / Permission / Sandbox / Human Approval——限制手段越靠近执行层越可靠。

④ 它如何面对未来变化？

增加新 Tool、更换模型、替换 Sandbox、增加 SubAgent、更换 Agent Loop——哪一件容易，哪一件困难？

回答完这四个问题，基本就能看出一个 Agent 框架真正的设计水平。

结语、从"怎么调用模型"到"怎么设计一个智能系统"

DeepSeek Harness、Claude Code 和 Codex 表面上非常相似，都有 LLM、Tool、Skill、SubAgent、Sandbox、Permission。但从架构哲学看，它们分别强调了 Agent 系统的三个侧面：

Claude Code       如何让一个 Agent 越来越强、越来越好用
Codex             如何让一个 Agent 安全进入真实计算环境
DeepSeek Harness  如何让不同 Agent 能力自由组合和替换

三个方向都很重要。把它们合在一起，已经能隐约看到未来 Agent Runtime 的形态——Agent Experience、Execution、Composition 三者兼备的一层中间软件。

所以研究这些框架的意义，不应该停留在"DeepSeek Harness 和 Claude Code 谁更先进"。更有价值的问题应该是：

未来一个真正成熟的 Agent Runtime，究竟应该同时具备哪些能力？不同业务场景下，我们究竟应该把多少控制权交给模型，又保留多少确定性在软件系统中？

到了这里，我们研究 Agent 框架的视角，就已经从"怎么调用模型"，逐渐走向"怎么设计一个智能系统"。

而这，可能才是 Agent 架构真正开始变得有意思的地方。