DeepSeek Harness vs Codex Harness：两条 Agent Runtime 路线的选型分析

小小怪当码农

409人浏览 · 2026-08-21 13:45:23

小小怪当码农 · 2026-08-21 13:45:23 发布

当模型逐渐具备长时间推理、工具调用、代码修改和多 Agent 协作能力后，真正决定 Agent 能否进入生产环境的，已经不只是模型能力，而是模型外部的 Harness 如何管理上下文、状态、工具、权限、恢复与验收。

摘要

DeepSeek Harness 与 OpenAI Codex Harness 都在尝试解决同一个问题：如何让大模型从一次性的问答工具，转变为能够在真实工程环境中持续执行任务的 Agent。

但两者选择了明显不同的技术路线。

DeepSeek Harness 采用 Framework First 的思路，以 Cordis 和“Everything is a Plugin”为核心，将模型适配器、Agent Loop、工具注册表、会话日志、持久化和沙箱等能力设计为可替换插件，更接近一套通用 Agent Runtime。

Codex Harness 则采用 Product First 的思路，将已经支撑 Codex CLI、App 和 IDE 体验的 Agent Loop，通过 Codex Exec、SDK 和 App Server 开放给开发者，更接近一个经过产品验证、可直接嵌入现有系统的 Coding Agent 平台。

本文将从架构开放性、状态管理、长程任务、工具权限、产品集成、安全边界、开源范围和工程成本等方面，分析两者各自的优势、局限与适用场景。

关键词： DeepSeek Harness、Codex Harness、Agent Runtime、Agent Engineering、Cordis、App Server、Event Sourcing、Coding Agent

一、先澄清：Codex Harness 并不是“整个 Codex 产品全部开源”

截至 2026 年 8 月 21 日，OpenAI 并不是在当天突然将整个 Codex 产品全部开源。

OpenAI 于 2026 年 8 月 19 日发布《Codex as a platform: build on the open agent harness》，正式将 Codex 背后的开放式 Agent Harness 定位为可以嵌入现有产品和工作流的运行基础设施。官方明确说明，开源范围主要包括：

Codex CLI；
Codex App Server；
Codex SDK；
Harness 与产品之间的集成接口。

模型访问和托管服务仍然属于独立层；Codex IDE 扩展和 Codex Cloud 也不在当前开源组件列表中。

因此，更准确的理解是：

OpenAI 开放的是 Codex 的 Agent Harness 与集成面，而不是将 Codex 的全部产品、模型和云服务完整开源。

Codex CLI 所在仓库当前采用 Apache-2.0 许可证。DeepSeek Harness 当前采用 MIT 许可证。两者都属于较宽松的开源许可证，但 DeepSeek Harness 在项目定位上更加接近可自由组合的通用 Agent Runtime。

二、什么是 Harness，为什么它开始比 Prompt 更重要

最简单的 Agent 系统通常是：

用户任务
   ↓
模型推理
   ↓
调用工具
   ↓
返回工具结果
   ↓
模型继续执行

这套循环可以让模型连续工作，但无法自动解决以下问题：

Agent 应该在什么条件下停止？
模型声明“完成”是否可信？
上下文过长后，早期约束是否会丢失？
执行过程中断后，任务能否恢复？
哪些工具可以被模型看到？
哪些操作需要人工审批？
Agent 能否访问网络、凭证和生产系统？
如何限制 Token、耗时和调用成本？
如何重建模型某次错误决策时看到的真实上下文？

所以，一个完整 Agent 系统更接近：

Agent System
    =
Model
    +
Agent Loop
    +
Context Management
    +
Persistent State
    +
Tool Runtime
    +
Permission Boundary
    +
Verification

模型负责理解任务和选择行动。

Harness 负责确保这些行动可以持续、可以恢复、可以约束，也可以被观察和审计。

DeepSeek Harness 与 Codex Harness 的真正区别，不是谁拥有更多工具，而是：

两者将哪些能力交给开发者自行设计，又将哪些能力做成了已经可以直接使用的产品化组件。

三、核心结论：一个偏“构建 Runtime”，一个偏“嵌入 Runtime”

可以先用一句话概括：

DeepSeek Harness 更强调“如何让开发者构建自己的 Agent Runtime”，Codex Harness 更强调“如何把一个成熟的 Agent Runtime 嵌入现有产品”。

两者的核心路线可以表示为：

DeepSeek Harness
        ↓
开放内部结构
        ↓
允许替换模型、Loop、工具、状态和执行后端
        ↓
开发者构建自己的 Agent 平台
Codex Harness
        ↓
开放成熟 Agent Loop 与集成协议
        ↓
通过 Exec、SDK、App Server 嵌入已有系统
        ↓
开发者围绕 Codex 构建产品

这意味着：

DeepSeek Harness 提供的是更大的架构修改权；
Codex Harness 提供的是更短的产品接入路径。

四、整体能力对比

对比维度	DeepSeek Harness	Codex Harness
核心定位	通用 Agent Runtime	Coding Agent 平台与集成层
设计中心	Framework First	Product First
核心理念	Everything is a Plugin	Open Agent Harness + App Server
扩展方式	Cordis 插件、Service、Provider、Capability Seam	SDK、App Server、MCP、配置与 Hook
状态模型	Append-only SessionEvent + Context Projection	Thread / Turn / Item + 流式事件
Agent Loop	可作为插件替换	Codex 核心 Loop，通过协议暴露
模型适配	Model Adapter 可替换	公共接口主要围绕 Codex 模型行为
长程任务	Goal、Ralph、Workflow、Subagent、Jobs	Thread、Goal、Resume、Fork、Compaction
产品集成	需要较多二次开发	Exec、TypeScript/Python SDK、App Server
权限控制	Tool Guard、Approval、Sandbox、Allow/Deny	Sandbox、Approval、文件变更和网络审批
开源边界	Runtime、Web、插件和基础能力集中在公开仓库	CLI、SDK、App Server 开源，IDE 与 Cloud 不开源
许可证	MIT	Apache-2.0
学习成本	较高	相对较低
最适合	自研 Agent 平台、多模型平台、Agent 研究	Coding Agent 集成、IDE、CI/CD、研发工具

五、DeepSeek Harness 的优势

1. 内部架构开放程度更高

DeepSeek Harness 最鲜明的设计理念是：

Everything is a Plugin。

它基于 Cordis 构建，插件可以向共享 Context 中注册 Service、Typed Event 和可撤销 Effect。

官方架构文档明确指出，包括以下能力在内的核心部分都属于插件：

Model Adapter；
Tool Registry；
Session Log；
Agent Loop；
Persistence；
Sandbox；
Approval Policy；
Telemetry。

系统不存在一个必须通过修改源码才能扩展的“特权核心”。开发者可以通过挂载新插件、替换 Provider 或修改 Profile 来改变运行时行为。

这种结构更接近微内核：

Cordis Runtime
      │
      ├── Model Provider
      ├── Agent Loop
      ├── Tool Registry
      ├── Session Provider
      ├── Persistence Provider
      ├── Sandbox Provider
      └── Workflow Provider

对企业的价值

企业可以选择：

使用 DeepSeek 模型；
接入 GPT、Claude 或自研模型；
替换默认持久化；
将 Shell 从本地切换到远程沙箱；
自定义审批规则；
自定义 Agent Loop；
自定义多 Agent 调度方式。

这意味着平台不会被某个固定模型、某个固定执行环境或某个固定产品交互方式完全绑定。

2. Session Event Sourcing 更适合恢复、回放和审计

DeepSeek Harness 将 Session 设计成类型化、只追加的 SessionEvent 日志。

会话日志不是单纯保存用户消息和助手回复，而是整个 Agent 交互历史的唯一真源。模型消息历史从日志中派生，不单独存储；Replay 本质上也是对同一批事件重新进行投影。

可以表示为：

Session Event Log
        │
        ├── Model Context
        ├── Web UI
        ├── Replay
        ├── Resume
        ├── Fork
        ├── Telemetry
        └── Audit

DeepSeek Harness 还提出：

Model-visible means logged。

凡是进入模型请求的信息，都应当能够从日志中重建。模型看到的上下文不再是无法追踪的临时对象，而是持久状态的一个可重建投影。

这种设计的优势

当 Agent 在第 50 个 Step 做出错误决策时，系统可以追溯：

当时使用的 System Prompt；
当时暴露的 Tool Schema；
此前有哪些工具结果；
哪些历史已经被压缩；
当前 Goal 状态；
当时是否发生了权限拒绝。

对于金融、企业内部平台、自动运维和高风险代码自动化，这种可追溯能力非常重要。

3. 长程任务策略更加多样

DeepSeek Harness 并没有把所有长任务都强行塞进同一种 Loop，而是提供了多种机制。

Goal：同一 Session 持续执行

Goal 在当前 Session 中保存目标状态，通过后续 Round 继续推进。

它适合需要保留完整上下文和连续推理过程的任务。

Ralph：使用 Fresh Agent 接力执行

Ralph 每一轮都会启动一个全新的子 Agent。

新的 Agent 不继承上一轮完整对话，只获得：

不可变目标；
当前轮次；
共享工作区；
上一轮结构化交接报告。

官方将共享工作区作为跨轮长期记忆，而不是依赖无限增长的聊天记录。Ralph 的完成状态也被明确标记为 Worker Report，而不是独立认证。

可以表示为：

固定目标
   ↓
Fresh Agent 1
   ↓
结构化 Handoff
   ↓
Fresh Agent 2
   ↓
结构化 Handoff
   ↓
Fresh Agent 3

Ralph 的价值在于主动处理上下文污染：

丢弃失败尝试；
丢弃过时推断；
丢弃模型生成的大量解释性噪声；
保留代码、文件、Git 和结构化进度。

这是一种比较典型的“外部状态优先”策略。

4. 工具能力、可见性和执行权限被明确分离

DeepSeek Harness 并不认为“系统注册了某个工具”，就等于“所有 Agent 都能调用这个工具”。

其设计可以拆成：

Capability
系统是否拥有该能力
        ↓
Visibility
当前 Agent 是否能看到
        ↓
Authorization
本次调用是否允许执行

例如：

系统拥有 deploy_production
        ↓
代码审查 Agent 看不到该工具
        ↓
发布 Agent 可以看到
        ↓
真正执行前仍需 Approval 和 Guard

工具注册表、作用域限制和 Guarded Execution Pipeline 共同形成了较清晰的能力控制模型。DeepSeek 的 Approval 机制在处理器缺失或异常时采用 fail-closed，而不是默认放行。

这种架构特别适合构建：

多角色 Agent；
不同权限等级的 Agent；
多租户 Agent；
企业内部工具平台。

5. 模型和基础设施中立性更强

DeepSeek Harness 将模型适配器、文件系统、Shell、Subagent 和持久化等能力设计为可替换 Provider。

这意味着它更容易被用作企业统一 Agent 中台：

统一 Agent Runtime
      │
      ├── DeepSeek
      ├── GPT
      ├── Claude
      ├── 本地模型
      └── 自研模型

企业可以根据：

成本；
数据合规；
推理能力；
任务类型；
网络条件；

选择不同模型，而不必重新设计完整 Agent Runtime。

六、DeepSeek Harness 的缺点

1. 架构复杂度较高

高度可扩展的代价，就是需要理解更多概念：

Cordis；
Context；
Effect；
Service；
Provider；
Consumer；
Profile；
Bundle；
Scope；
Session Event；
Surface Projection；
Capability Seam。

对于一个只需要“调用模型，再执行一个 API”的简单项目，这套架构可能明显过重。

开发者不仅需要理解 Agent，还需要理解一套插件化运行时、事件模型和依赖注入体系。

2. 开发者获得更多控制，也承担更多平台建设责任

DeepSeek Harness 提供了较大的内部替换空间，但不会自动替企业完成全部产品工作。

企业仍然需要自行建设：

统一用户界面；
权限管理后台；
凭证管理；
多租户隔离；
运行监控；
成本统计；
评测平台；
版本兼容策略；
插件质量治理。

因此：

DeepSeek Harness 降低的是架构受限程度，而不是所有研发成本。

对于没有专门 Agent 平台团队的公司，过多的可配置能力反而可能成为维护负担。

3. 独立完成验证仍不完善

DeepSeek Goal 当前主要提供 Round 数量限制，并未统一计算 Token、费用、实际耗时和 Provider 配额。

官方文档还明确指出，Goal 和 Ralph 当前都没有独立 Evaluator；完成与阻塞状态主要由执行模型或 Worker 声明，基于评估器的完成认证仍属于延后能力。

也就是说：

Agent：任务已经完成

不自动等价于：

独立验证器：测试、构建和运行检查全部通过

生产化时仍需要补充：

Acceptance Criteria；
Test Runner；
Deterministic Verifier；
Review Agent；
Human Approval Gate。

4. Sandbox 主要约束文件系统，不是完整安全边界

DeepSeek Harness 的 Sandbox Mode 包括：

read-only
workspace-write
danger-full-access

但官方文档明确指出，当前 SandboxMode 主要管理文件系统影响，网络访问和进程可见性不属于这一抽象的保证范围。

因此：

workspace-write

并不意味着：

Agent 已经被完整隔离

企业仍需自行增加：

网络出口控制；
IAM；
Secret Manager；
短生命周期 Token；
API Gateway；
数据脱敏；
行为审计。

七、Codex Harness 的优势

1. 已经经过多个真实产品入口验证

Codex Harness 并不是单纯从设计文档开始构建的框架。

同一套底层 Harness 已经服务于：

Codex App；
Codex CLI；
IDE 体验；
Codex Web 等不同入口。

OpenAI 将这套 Harness 定义为负责管理对话状态、流式执行、工具调用、Sandbox、Approval 和跨 Turn 工作延续的执行系统。

这意味着 Codex Harness 的优势更多来自：

已经运行过真实开发流程；
已经处理客户端断线和重连；
已经支持流式进度；
已经处理文件变更、Shell 和审批；
已经适配桌面端、CLI、IDE 和 Web。

从企业接入角度，这种产品验证往往比架构上的完全自由更加重要。

2. 提供了清晰的三层集成方式

Codex 当前提供三种主要集成方式。

Codex Exec

适合：

一次性脚本；
CI/CD；
非交互任务；
后台批处理。

Codex SDK

适合：

应用代码启动 Agent；
恢复已有 Thread；
服务器端工作流；
内部研发工具。

当前官方同时提供 TypeScript 和 Python SDK。TypeScript SDK 可以启动、继续和恢复本地 Codex Thread；Python SDK 通过 JSON-RPC 控制本地 App Server，并已提供稳定版本。

Codex App Server

适合：

Agent 成为产品的一部分；
自定义前端；
IDE；
运维平台；
研发看板；
安全调查系统。

App Server 通过双向 JSON-RPC 暴露完整 Agent 生命周期，客户端可以创建 Thread、启动 Turn、接收事件、处理中断和响应审批。

这种分层明显降低了接入门槛。

3. Thread / Turn / Item 协议更适合产品客户端

Codex App Server 对外暴露了三个核心对象：

Thread
   ↓
Turn
   ↓
Item

Thread

表示一个持续存在的 Agent 会话。

支持：

Start；
Resume；
Fork；
Read；
Archive；
Delete；
Compact。

Turn

表示一轮具体执行。

支持：

Start；
Steer；
Interrupt；
Completed；
Failed；
Interrupted。

Item

表示 Turn 中的执行单元，例如：

Agent Message；
Reasoning；
Command Execution；
File Change；
Tool Call；
Context Compaction。

每个 Item 都有 item/started 和 item/completed 生命周期事件，完成事件被定义为最终权威状态。

这种协议对于前端和 IDE 非常友好。

客户端不需要理解 Agent 内部所有插件，只需要消费稳定的生命周期事件。

4. 最新 Codex 已经具备较完整的长任务能力

过去容易将 Codex 简单理解为“一个不断延续的 Thread”。

但当前 App Server 已经支持：

Thread Resume；
Thread Fork；
手动 Compaction；
持久 Goal；
Goal Token Budget；
Token Usage；
Time Usage；
Turn Interrupt；
分页读取 Turn 和 Item。

例如，App Server 的 thread/goal/set 可以设置目标和 Token Budget，并返回 tokensUsed 和 timeUsedSeconds。

这说明 Codex Harness 已经开始从单纯 Coding Agent 发展为较完整的长任务执行平台。

与 DeepSeek 相比：

DeepSeek 在执行策略多样性上更激进；
Codex 在 Thread 生命周期和客户端控制上更加产品化。

5. 审批交互更贴近真实产品

Codex App Server 可以直接向客户端发起审批请求。

当前覆盖的审批场景包括：

Shell 命令执行；
文件修改；
MCP 工具副作用；
网络访问。

客户端可以在自己的产品界面中展示操作原因、目标资源和风险，再返回 Accept、Decline 或 Cancel。

这种方式很适合企业现有审批流程：

Agent 提议操作
      ↓
App Server 发起审批请求
      ↓
企业系统展示风险和影响
      ↓
用户审批
      ↓
Agent 继续执行

与单纯在终端中询问“是否允许执行”相比，这更容易嵌入实际业务系统。

八、Codex Harness 的缺点

1. 开源范围不是完整 Codex 产品

虽然 Codex Harness 和主要集成组件已经开源，但当前官方组件列表明确显示：

IDE Extension 不开源；
Codex Cloud 不开源；
模型访问和托管服务独立于开源 Harness。

因此，开发者可以检查和修改 Agent Loop 与集成层，但不能仅依赖开源仓库完整复刻所有 Codex 产品体验。

这与 DeepSeek Harness 的“Runtime 本身就是主要产品”有所不同。

2. 公共接口仍然以 Codex 为中心

Codex Harness 虽然开放，但它的核心抽象仍然是：

Codex Thread；
Codex Turn；
Codex Item；
Codex Sandbox；
Codex Approval；
Codex 模型行为。

官方 SDK 文档也将其定位为面向 Coding-focused Codex Threads；当 Codex 只是更大工作流中的一个专业 Agent 时，官方建议通过 MCP Server 和 Agents SDK 进行上层编排。

这意味着 Codex Harness 并不是以“任意模型可互换”为第一设计目标。

企业如果需要：

GPT
+
DeepSeek
+
Claude
+
本地模型

形成统一底层 Runtime，仍然需要在 Codex 外部再建立一层模型和 Agent 抽象。

3. 内部可替换程度不如 DeepSeek Harness

Codex 开放了 Agent Harness 与集成接口，但其公开设计重点是：

Application
      ↓
App Server / SDK
      ↓
Codex Runtime

开发者可以控制：

UI；
Context；
MCP 工具；
Approval；
Sandbox；
运行位置；
结果如何回写业务系统。

但官方并没有将“Agent Loop、Session Log、Model Adapter 全部可以任意替换”作为核心设计承诺。

因此：

在 Codex 内部扩展产品能力更方便；
重新定义 Codex Runtime 本身，通常不如 DeepSeek 自由。

4. App Server 仍然存在集成与运维成本

App Server 虽然提供完整能力，但接入方仍需要处理：

JSON-RPC 客户端；
双向事件流；
进程生命周期；
断线重连；
Thread 状态；
Approval 请求；
版本兼容；
客户端与服务端版本固定。

OpenAI 也明确指出，使用 App Server 的主要成本是集成工作，客户端需要在自己的语言中实现 JSON-RPC 连接。

此外，部分能力仍处于实验状态。例如 App Server 的 WebSocket 传输目前被标记为 experimental and unsupported，远程暴露时还需要自行配置认证和网络边界。

所以 Codex Harness 虽然比自研 Runtime 更快，但也不是一个无需工程建设的黑盒 API。

5. Turn Completed 仍然不等于业务 Verified

Codex App Server 的 turn/completed 表示某一轮执行进入：

completed；
interrupted；
failed。

它是运行时生命周期状态，而不是业务验收证明。

例如：

turn.status = completed

可能只表示 Agent 正常停止，并不一定表示：

全部测试通过
业务功能符合需求
数据没有被错误修改
上线结果符合预期

因此，Codex Harness 同样需要在外部补充：

测试；
构建；
静态分析；
浏览器验证；
API Probe；
独立 Review；
人工验收。

在这一点上，两套 Harness 都还不能替代企业自己的质量体系。

九、关键维度下，谁更有优势

1. 架构可扩展性：DeepSeek Harness 更强

DeepSeek 允许替换：

Agent Loop；
Model Adapter；
Session；
Tool Registry；
Persistence；
Sandbox；
Subagent Provider。

适合希望构建长期 Agent 基础设施的团队。

2. 产品接入效率：Codex Harness 更强

Codex 提供：

Exec；
TypeScript SDK；
Python SDK；
App Server；
JSON-RPC 协议；
Thread / Turn / Item 生命周期。

适合希望快速在现有研发工具和业务系统中嵌入 Coding Agent 的团队。

3. 状态与审计：两者都强，但方向不同

DeepSeek 更偏：

Event Sourcing
      ↓
Context Projection
      ↓
Replay / Audit / Recovery

Codex 更偏：

Thread
   ↓
Turn
   ↓
Item
   ↓
Client Event Stream

DeepSeek 更利于研究内部执行事实。

Codex 更利于构建面向用户的 Agent 产品。

4. 长程任务：DeepSeek 策略更多，Codex 生命周期更成熟

DeepSeek 提供：

Goal；
Ralph；
Workflow；
Subagent；
Jobs。

Codex 提供：

Persistent Thread；
Goal；
Token Budget；
Resume；
Fork；
Compaction；
Interrupt。

DeepSeek 更关注：

应该使用同一个 Agent，还是定期启动 Fresh Agent？

Codex 更关注：

客户端如何稳定创建、控制、恢复和观察一个长期 Agent？

5. 模型中立性：DeepSeek Harness 更强

DeepSeek 将模型适配器作为插件。

Codex 的公开集成面则围绕 Codex Thread 和 Codex 模型行为构建。

如果企业需要统一接入多个模型，DeepSeek 更接近理想底座。

6. Coding Agent 开箱能力：Codex Harness 更强

Codex Harness 背后的能力已经用于实际 Codex 产品。

在以下场景中，Codex 路径更直接：

代码修改；
IDE 集成；
CI/CD；
Code Review；
研发工作台；
Shell 和文件操作。

DeepSeek Harness 则需要平台团队进一步组合适合自己的 Agent Preset 和产品界面。

十、企业应该如何选择

场景一：建设统一 Agent 中台

如果目标是构建：

模型管理
工具管理
Agent 管理
权限管理
工作流管理
会话管理
审计与评测

更适合选择：

DeepSeek Harness。

原因是它允许从 Runtime 内部重新定义能力和 Provider。

场景二：在现有研发系统中快速嵌入 Coding Agent

例如：

IDE；
DevOps 平台；
工单系统；
代码审查系统；
CI/CD；
安全调查平台。

更适合选择：

Codex Harness。

原因是 Exec、SDK 和 App Server 已经覆盖不同接入层次。

场景三：需要多模型动态调度

例如：

简单任务使用低成本模型
复杂 Coding 使用 Codex
中文分析使用 DeepSeek
高风险审查使用另一模型

更适合以：

DeepSeek Harness 或企业自建控制平面作为上层 Runtime。

Codex 可以作为其中一个专业 Coding Agent，而不是整个平台唯一的底层。

场景四：高风险生产自动化

例如：

自动发布；
数据库修改；
财务操作；
资金交易；
生产运维；
云资源变更。

两者都不建议直接裸用。

必须额外增加：

Policy Engine
      +
IAM
      +
Credential Broker
      +
Network Gateway
      +
Deterministic Verifier
      +
Human Approval
      +
Audit System

Harness 可以帮助 Agent 执行，但不能自动替代企业的生产权限和验收责任。

十一、一个更现实的方案：通用控制平面 + 专业 Agent

企业未必需要在 DeepSeek Harness 和 Codex Harness 之间完全二选一。

更合理的架构可能是：

企业 Agent 控制平面
        │
        ├── 通用任务 Agent
        ├── 财务分析 Agent
        ├── 数据 Agent
        ├── 运维 Agent
        └── Codex Coding Agent

其中：

上层负责身份、权限、路由、审计和业务状态；
DeepSeek Harness 或自研 Runtime 负责通用 Agent 编排；
Codex 作为 Coding 专业 Agent；
MCP 或内部 API 负责连接业务系统；
独立 Verifier 负责最终验收。

这种方案能够同时利用：

DeepSeek 的可扩展架构；
Codex 的 Coding 产品能力；
企业自己的权限和数据体系。

十二、最终结论

DeepSeek Harness 和 Codex Harness 并不是简单的同类产品替代关系。

它们代表了两种不同的 Agent 工程路线。