DeepSeek Harness 与 Codex Harness：同名 Harness，根本不是一路人

源码级拆解：平台生态 vs 控制引擎的架构决裂

就在即将过去的 8 月，DeepSeek 与 OpenAI 先后开源了都叫 Harness的东西。拆源码发现却是两种物种：一个搭平台等你长插件，一个露引擎赌你不必造。你以为在选工具，实则在选未来三年押哪条生态链。本文从代码、架构、生态一拆到底。

0. 开个头：一个被滥用的词，两盘完全不同的棋

2026 年夏天，"Harness" 这个词在 AI 工程圈被念得滚瓜烂熟。DeepSeek 开源了 Harness，OpenAI 也把 Codex 的 Harness 摆上了台面。表面上，两家都在说同一件事：给 LLM 套一层"驾驭层"，让它从会聊天的模型变成能干活、跑长任务的 Agent。

但如果你真的把两份仓库 clone 下来、把依赖装上、把断点打上、把一次真实任务跑通，你会发现一个被行业有意无意忽略的事实——

它们根本不是同一类东西。

Ning 等人在论文 Code as Agent Harness（arXiv:2605.18747，2026）里给 harness 下了一个相当学术的定义：它是"包裹 LLM 的软件层，提供 tools、APIs、sandboxes、memory、validators、permission boundaries、execution loops 与 feedback channels，从而把一个无状态模型变成 capable of long-running task execution 的功能型 agent"。论文还把这一层拆成 harness interface（连接推理/行动/环境建模）、harness mechanisms（规划、记忆、工具使用与反馈驱动控制）、scaling（单 agent → 多 agent 共享代码制品做协同与验证）三叠结构。

这个定义足够好，好到反而掩盖了问题：光是"harness"三个字，在两家的代码里落点差了整整一个维度。 DeepSeek 开源的是一个平台级元框架——它把"造 Agent"这件事本身抽象成一套可插拔规范，野心是定标准、建生态；OpenAI 开源的是其商用 Coding Agent 的核心控制引擎与运行底座——它不鼓励你写第三方插件，而是把内部高强度验证过的生产级 Agent Loop 与底层 Runtime 控制逻辑整盘裸露出来。

一句话：DeepSeek 卖的是"搭积木的框架与接口标准"（平台+插件），OpenAI 卖的是"高并发、长程任务的生产级引擎设计图纸"（控制逻辑）。

这篇文章不打算做"两家功能清单对比"。我们要做的是源码级拆解 + 运行追踪（Trace），还原两个顶级团队在设计 Agent 驾驭层时，做出的不同工程抉择与背后哲学。读完你应该能回答一个问题：你的团队，到底该抄哪家作业？

一、破局：被误读的"Harness"与 Agent 架构的二次分化

1.1 现象与痛点

行业里现在流行一种偷懒的说法："Codex 有 harness，DeepSeek 也有 harness，大家殊途同归。" 这是错的，而且错得有代表性。

这种误读不是无害的。当你所在的团队准备上马 AICoding 工具、在"自研还是基于开源改造"之间犹豫时，最容易被"大家都有 harness"带偏，以为随便挑一个抄就行。而 2026 年 8 月，DeepSeek 与 OpenAI 在两周内先后开源各自的 harness，等于把这道选择题硬塞到每个做 AI 工程的团队面前——不把两者的本质差异看透，抄作业就会抄错地方。

我们不妨把两份开源物的"出厂设定"摊开看：

注意一个细节：DeepSeek 把"模型"降格成了一个可替换插件，明确说 Agent = Model + Harness，并认为"模型之外的那一层，正在成为产品差异的主战场"；而 OpenAI 开源的 codex exec（CI/CD 一次性任务）、Codex SDK、以及 App Server，本质都是把同一颗 Rust 引擎的不同入口敞开给你看——它根本不假设你会在里面塞自己的 Loop。

1.2 核心立论：Agent 架构的"二次分化"

把前面的判断再往上抬一层——本文真正想说的，是一件比"DeepSeek Harness ≠ Codex Harness"更锋利的事：Agent 架构正在发生"二次分化"，而这两份开源物恰好站在分叉口的两端。

第一次分化发生在去年：业界逐渐达成共识，把"LLM 本身"与"包裹它的驾驭层（harness）"拆成两层——模型负责推理，harness 负责工具、记忆、沙盒、循环与反馈。论文 Code as Agent Harness 把这一层正式学名化，正是这次分化的产物。

但 2026 年 8 月，当 DeepSeek 与 OpenAI 先后把自家 harness 开源，你会发现这个"驾驭层"自身正在发生第二次分化：一边走向"平台范式"——把"造 Agent"这件事抽象成一套可插拔规范，定标准、建生态、让第三方在上面长东西（DeepSeek）；另一边走向"引擎范式"——不假设你来改它，只把内部验证过的生产级 Loop 与 Runtime 整盘裸露，赌你不需要自己造（OpenAI）。

一句话：harness 不再是一块铁板，它正在裂成"平台"与"引擎"两种范式。 看懂这次分化，比看懂"两家代码不同"重要得多——因为前者决定了你未来三年要在哪条生态链上押注，后者只是这道选择题的两个样本。

在这条主线下，全文围绕一个更具体的判断展开：

DeepSeek Harness = 微核（Microkernel）+ 全插件的"平台生态"路线；OpenAI Codex Harness = 高并发、长程任务优化的"控制引擎 / Runtime"路线。

前者酷在"什么都能换"，后者强在"什么都不用你操心、但跑得稳"。这是两种完全不同的战略意图，不是同一种东西的两种包装。

1.3 源码运行基准环境（本次 Trace 的真实 Setup）

为了让后面的拆解不是"看文档猜实现"，我们基于源码阅读 + 本地运行追踪完成本次分析。基准环境如下：

• DeepSeek Harness：git clone deepseek-ai/deepseek-harness，基准版本 v0.1.0-rc.7（npm latest；截至 2026-08-27 最新的 rc 为 v0.1.1-rc.1，8/21 发布、新增 V4 Flash Vision-Exp 多模态，但本文以更稳定的 v0.1.0-rc.7 这一"上一个版本"为基准）；Node.js ≥ 22.19.0（低于此版本会静默失败——不报错、只是没反应，这是第一个坑）；启动 dsh web（默认 http://127.0.0.1:3080）与 cordis 创造模式；Trace 工具用 V8 Inspector + 轨迹日志（Trajectory Log）回放。
• OpenAI Codex Harness：git clone openai/codex，编译 codex-rs；工具链由仓库内 rust-toolchain.toml 固定为 rustc 1.95.0（components：clippy / rustfmt / rust-src，建议先 rustup toolchain install 对齐，避免本地工具链不一致导致的诡异编译失败）；npm 包 @openai/codex 约 0.42.0。启动 codex app-server --listen stdio 驱动一个 VS Code 扩展式客户端；跑通一个多轮编码任务，用 app-server generate-json-schema + 抓帧工具捕获 JSON-RPC 报文。
• 测试 Case：两端各跑同一个"给仓库写一份 README + 修复一个失败单测"的混合任务，对比其 Loop 调度、上下文剪枝与失败恢复路径。

踩坑先说一句（以下均来自社区实测）：DeepSeek 侧最常见的"假死"是 Node 版本不够——node -v 确认 ≥ 22.19 是第一步，否则连报错都没有；Codex 侧第一道坎是双构建系统——codex-rs 同时用 Bazel（MODULE.bazel）与 Cargo workspace，本地只装 Cargo 时容易在补依赖阶段卡死，建议严格按官方 rust-toolchain.toml（1.95.0）对齐工具链；其次 codex app-server 的 ws:// 传输仍标 experimental，生产集成从 stdio 起步最稳。更深的坑（上下文硬上限、日志吃 SSD 等）后面回到。

二、DeepSeek Harness 源码拆解：极致解耦的"微核 + 全插件"生态

2.1 架构全景：以 Cordis 机制为核心的插件拓扑

DeepSeek Harness 的底层是 Cordis 元框架——一个轻量级插件容器。它脱胎于 DeepSeek 配套论文 A Programming Paradigm for Spatiotemporal Composability（时空可组合性编程范式）。Cordis 内核只负责五件事：挂载（mount）/ 卸载（unmount）/ 依赖解析 / 组合 / 撤销 / 自省。运行中的 Harness，本质上就是一个 Cordis Context——不同包向这个 Context 注册服务、事件与能力，最后由配置文件把它们组合成一个可运行的 Agent。

它最醒目的主张是 "Everything is a Plugin"：不仅 Tool、Model 是插件，连 Agent Loop（智能体循环）、Context Injection（上下文注入）、Session 管理、Sandbox 隔离乃至 Web UI 本身，全都是可被替换或插拔的 Plugin。整体拓扑如下：

Cordis 用五个底层问题定义了插件运行时必须回答的契约，这也是理解整个框架的钥匙：

2.2 "Everything is Plugin"的实现剖析

（1）主 Loop 被抽象为可插拔插件

传统 Agent 框架里，那个 while (true) { observe → think → act } 的主循环是写死在核心里的。DeepSeek 的做法是把它提升为一等公民插件：Agent Loop 不再是一个控制流，而是一个向 Cordis Context 注册的"能力提供者"。框架启动时由配置决定加载哪一个 Loop 实现（standard / code / minimal / cordis 四种内置模式，本质就是四组不同的插件预设）。

这意味着你可以替换掉整个决策循环——比如换成一个"双模型分工"的 Loop（规划用强推理模型、执行用便宜模型，社区 dsh-plan-execute 插件即此思路），而不需要改动框架一行核心代码。源码层面，Loop 插件通过 Cordis 的"能力坐标"声明自己提供 loop 能力，框架在组装时把它接到事件总线上。

（2）运行时 Creator Mode：不重启进程地热加载/修改

这是 DeepSeek 最"离经叛道"也最有想象力的设计。在 cordis 创造模式下，你可以在内存里动态组合插件、实时创建新的运行预设：

• 关掉计划模块；
• 加一个本地 Git 钩子（dsh-git-hooks 思路）；
• 把联网搜索替换成自己写的 PDF 解析器；
• 动态创建一个新工具并注册——文档里的例子是 Agent 自己写了一个"统计中文字符数"的函数，然后把它注册成新工具。这相当于 Agent 给自己"长出了新手指"。

实现上，这依赖 Cordis 的"自省演化"能力：Cordis 把自身 API 暴露给插件，使得插件可以查询、修改其它插件的状态，并在运行时 mount() 新插件。配合下面的轨迹日志，热加载过程的每一次能力变更都可被记录与回滚。

当你能在运行时让 Agent 给自己"长出新手指"，你才真正理解什么叫 Everything is a Plugin——DeepSeek 卖的不是一款产品，而是一套"谁能进来、怎么组合"的宪法。

图 1 DeepSeek Agent Presets UI——四种 Agent Loop 插件可视化

实跑 dsh web 后可见 Agent Presets 面板提供 Standard / Code / Minimal / Creator 四种内置 Loop 模式，相当于把"主循环"本身作为可切换插件摆在你面前——这正是"Everything is a Plugin"的肉眼证据。Creator 模式下可运行时挂载新工具与上下文注入逻辑，进程不重启。

简而言之，其调用流就是：用户在 Creator Mode 提交"新增工具"指令 → Loop 插件经 Cordis 事件总线转发 → PluginService.register 解析新插件的 manifest 并建立能力坐标 → plugin.mount() 执行生命周期挂载 → 新能力被注入当前 Context，后续推理即可调用。整个过程进程不重启。

2.3 工程亮点：Append-Only 轨迹日志（黑匣子）

DeepSeek 最具工程价值的设计，是一个 Append-Only 轨迹日志（Trajectory Log）。模型在每次会话中看到的一切——系统提示、推理过程、每一次工具调用与返回、子任务调度、上下文注入——都被完整记录在一个只追加的日志里。它带来的四个能力直接对标行业痛点：

• 可恢复：进程崩溃后，从轨迹日志重建完整状态；
• 可分叉：从任意一步创建分支，探索不同路径；
• 可搜索：全文检索 Agent 的所有行为；
• 可回放：逐步回放决策过程。

对比 Claude Code 用 session ID 隐式管理（开发者只能看到结果和工具调用摘要），DeepSeek 的轨迹日志是完整的可审计记录。结合 Cordis 的 preset 快照，这让它天然适合"企业级可追溯 Agent"。

2.4 工程优势与代价

优势（源码与运行验证）：

• 拓展性极高：一套 Harness 兼容所有大模型（DeepSeek / OpenAI / Anthropic / 任意 OpenAI 兼容 API，配置即时生效免重启），并允许各部门自建工具链；通过 Hook 还能把 Claude Code 当作子 Agent 接入。
• 可追溯性强：轨迹日志 + preset 快照，企业审计与复用成本极低。
• 生态飞轮：MIT 协议 + dsh-plugin 标签 + npm 分发，开源数日内社区插件已涌现近 300 个（awesome-dsh-plugins 收录 299+、分 14 类），典型的"平台标准"打法。

代价（运行追踪与社区实测暴露的痛点）：

• "全插件"的另一面是"全静默失败"：第三方脚本 dsh doctor（--node）扫描出 9 类静默失败模式，最扎眼的是——P5 seqgap：并发写 session 日志序号跳号，会让后续 turn/end 静默截断甚至永久损坏；P6 subagent-env-scrub：含 KEY/TOKEN/SECRET 的环境变量被静默剥离再传给子 Agent（安全 + 调试双坑）；P9 files-quota-scope：同一 API key 的另一 dsh 安装竟能静默删掉你的 file_id（多租户隔离失败）。注意：§2.3 吹的"轨迹日志可恢复 / 可回放"在这里立了反例——它自己也会静默损坏。
• 插件兼容性脆，升级即易崩：跨 rc 版本插件失效（dsh-codex-compat-canary、upstream-radar 的 dsh-plugin-compatibility 看板持续追踪），deepseek-ai/deepseek-harness discussions #4531 有"插件工具挂起/恢复"工单。从 v0.1.0-rc.7 升 v0.1.1-rc.1 前必须先确认第三方插件兼容状态——这正是"全插件生态"必须支付的维护税。
• 缺原生 TUI，社区被迫补位：启动日（2026-08-15）社区的头号抱怨就是没有原生桌面 / 终端 UI；截止 8/28 各类补丁雨后春笋，典型如 dataelement/dsh-desktop（DSH Desktop，基于 @deepseek-ai/dsh@0.1.1-rc.2 的本地优先桌面壳，把 Harness 包成原生桌面应用并补上 Safe Mode 等能力）。这反过来说明：官方把 UI 也当成"可插拔插件"，但基础体验的"最后一公里"确实留给了社区。
• 状态追踪链路过长 / 单实例：一次工具调用要先过 Loop 插件 → Cordis 事件总线 → 能力解析 → 具体插件，断点调试要在好几个插件间跳；dsh 目前单实例设计，不适合高并发。
• 稳定性预期：v0.1 开发者预览，官方明确会有破坏性更新，文档尚不完善，很多能力"需读源码理解"。

三、OpenAI Codex Harness 源码拆解：榨干性能的"硬核控制引擎"

3.1 架构全景：JSON-RPC 通信 + App Server 的控制闭环

如果说 DeepSeek 是一箱乐高，Codex 就是一台调校到位的引擎。它从早期 TypeScript 原型重写为以 Rust 为主体的多入口 harness（codex-rs，约 120 个 crate）。本次开源暴露的三块——codex exec（CLI，面向 CI/CD）、Codex SDK、以及 App Server——都围绕同一颗引擎。

其中 App Server 是理解它"控制引擎"定位的钥匙。它是一个 JSON-RPC 2.0 接口（线上省略 "jsonrpc":"2.0" 头），用来驱动丰富客户端（如 Codex VS Code 扩展），负责鉴权、会话历史、审批与 Agent 事件流式推送。关键区分：App Server 是协议层，引擎才是执行层——真正的模型推理、命令执行与上下文压缩（compaction）都由底层 Rust 引擎完成，VS Code 扩展只跟 app-server 说话。这本身就是一个强信号：OpenAI 不希望你碰引擎内部，只希望你通过标准协议接入。

支持传输：stdio（默认，JSONL）、websocket（experimental）、unix socket、off。初始化有严格握手：initialize → initialized，任何 pre-init 请求直接被拒；重 initialize 返回 "already initialized"。过载时走有界队列，满则拒并返回错误码 -32001 "Server overloaded; retry later."，客户端应指数退避 + 抖动。

3.2 三大工程硬核点源码直击

（1）上下文窗口的极致压榨

长任务里上下文是最贵的资源。Codex 引擎在 Rust 侧实现了上下文压缩（compaction，对应 thread/compact/start），结合"Dynamically Streamlined Context"思路——只保留对当前决策必要的上下文，并把历史压缩成可恢复的形态。App Server 暴露的 thread/compact/start、以及 item/* 事件流的分层推送，都是这套"上下文预算管控"在协议层的外显。

源码追踪要点：引擎在 turn 边界评估上下文占用，触发 compaction 时将远端历史摘要化、保留近端工具结果与最新决策；这解释了为什么 Codex 能在长程编码任务里保持低时延——它不为"完整回放历史"付出成本，而是为"下一步决策"精算上下文。

（2）Long-Horizon（长程任务）状态控制：Fork / Pause / Resume

Codex 把会话建模成 Thread（对话，含多个 Turn）/ Turn（单次请求+agent 工作，含多个 Item）/ Item（消息、命令、文件变更、工具调用等单元） 三级结构，并在此之上实现生产级的状态控制：

DeepSeek Harness 与 Codex Harness：同名 Harness，根本不是一路人

• thread/fork：把历史复制到新 thread ID（带 forkedFromId，且 sessionId 与根节点保持一致——sessionId 标识"活动会话树"的根，不能从 thread ID 反推）。这让你能从任意历史节点分叉试探。
• thread/resume：重开已存 thread，接受与 start 相同的配置覆盖（如 personality）；模型不一致时给警告并一次性切换。
• thread/rollback：丢弃最近 N 个 turn 的内存态并持久化标记。
• turn/interrupt：以 status: "interrupted" 结束当前 turn。

这一套设计的核心工程价值在于：长程任务的"断点重试"不会污染原始会话树——fork 出的分支与主干共享 sessionId 但各自独立推进，rollback 只动内存态并落盘标记。这比"重头再来"或"单线覆盖"稳健得多，也规避了多轮重试中状态错乱导致的"死锁/回环"风险（fork + rollback 组合让引擎始终有一个可信的根节点可回退）。

OpenAI 开源的不是一个框架，而是一份"生产级 Agent 该怎么跑"的参考答案：它不让你改 Loop，是因为它赌你不需要——这种克制，是一种傲慢，也是一种笃定。

图 2 Codex codex-app-server 主题测试——fork 状态的 SQLite 持久化

实跑 cargo test -p codex-app-server 可见 thread_start_with_sqlite_persists_thread_in_state 等用例（本地实测一轮耗时约 1m27s），直接用单元测试佐证 §3.2 的 fork/resume 与 state_db 持久化主张：ThreadManager 分配新 threadId、复用根 sessionId → SessionIo（tx_sub / rx_event 异步通道）接管提交 → run_turn 内 run_pre_sampling_compact 重建上下文 → ToolOrchestrator 经 execpolicy + SandboxManager 调度执行。

（3）沙盒与安全边界（Human-in-the-Loop）

这是 Codex "控制引擎"定位最硬的一块。App Server 通过服务端主动发起的 JSON-RPC 请求做审批，客户端回决策：

• 命令执行审批：item/started → item/commandExecution/requestApproval（带 command、cwd、proposedExecpolicyAmendment、networkApprovalContext）→ 客户端决策 → serverRequest/resolved → item/completed。决策可为 accept / acceptForSession / decline / cancel / acceptWithExecpolicyAmendment。
• 文件变更审批：item/fileChange/requestApproval 走同样流程。
• 用户输入请求：tool/requestUserInput（1–3 个问题）→ serverRequest/resolved。

沙盒策略分级（turn/start / command/exec 时指定）：readOnly、workspaceWrite（writableRoots / readOnlyAccess / networkAccess）、externalSandbox、dangerFullAccess。一个关键细节：thread/shellCommand 在沙箱之外以完全权限运行，且仅限用户主动触发——把"用户明确要做的"和"Agent 自主要做的"在权限模型上彻底分开。这不是 DeepSeek 那种"工作区级 + 逐条审批"的平面模型，而是一个带决策树的审批边界 + 沙盒隔离层的组合。

3.3 工程优势与代价

优势（源码与协议验证）：

• 高鲁棒性 + 极致生产级效率：Rust 内核、有界队列过载保护（-32001 + 退避）、严格的 init 握手与实验特性门控，天然适配 IDE/CLI 深度集成。
• 长程任务成功率高：fork/resume/rollback + compaction 让"跑很久也不崩、崩了能回退"。
• 安全边界清晰：沙盒分级 + 服务端审批流，把 Human-in-the-Loop 做成引擎级能力而非插件。

代价：

• 二次开发门槛高：核心 Loop 与状态机耦合紧密，想替换底层推理/调度逻辑基本等于改引擎，难以轻易替换。
• 扩展走协议而非插件：你能订阅事件、调 RPC、挂 MCP，但不能在运行时把 Loop 本身换成自己的实现（这正是与 DeepSeek 的根本分野）。
• MCP 工具不在沙箱保护范围内：OpenAI 自己在 Unrolling the Codex Agent Loop 一文中承认——沙箱只保护内置 shell，经 MCP 接入的第三方工具必须各自做好防御。这给 §3.2 的"沙盒分级"补上一道裂缝：你接的外部 MCP server，默认不受那套审批 / 隔离边界约束。
• 无状态设计 → 请求体 O(n²) 增长：OpenAI 自承"二次增长"——每次请求的 prompt 是累计上下文，长任务的请求体随轮次近似平方膨胀，代价是牺牲 ZDR（Zero Data Retention）合规灵活性。
• 缓存命中极敏感：中途改 model / sandbox / cwd / approval 任一都会丢掉 KV cache；tools/list_changed 通知还可能触发缓存雪崩（PR #2611 早期就踩过工具排序非固定序导致的 cache miss）。这是"低时延"的另一面代价。
• 上下文 append-only + 10K 硬上限：ContextualUserFragment 每片段封顶 10K token，上下文只追加不改动；长会话会被 run_pre_sampling_compact / run_auto_compact 强制压缩，可能丢掉细节——这是"极致压榨"的另一面代价。
• 真实 bug 教训：日志写爆 SSD：早期版本默认日志级别过高、WAL 写入过度，实测会快速吃光云盘（社区多次反馈），官方在 rust-v0.142.0（2026-06-22 合并）才降低默认日志级别并修正 WAL 行为。提醒：自编译老 tag 务必先拉这个修复。
• 审批缓存按会话持久 + 中断偏硬：ReviewDecision::ApprovedForSession 让一次审批在整个会话生效（安全/UX 权衡）；Op::ConfigureSession 会 abort 运行中 task，abort_all_tasks 仅 100ms 优雅超时，长任务中断可能较 abrupt。
• 历史双轨：全局 ~/.codex/history.jsonl 与 per-thread rollout（JSONL + SQLite state_db）分离，resume 靠反向扫描器避免全文件读——管理状态时要分清两层。
• 生态属性弱：它要的是你"用它"，不是"在它上面长东西"。

四、深度硬碰硬：源码级关键维度对比矩阵

把前面拆到的源码事实收敛成一张可直接拿来汇报的矩阵：

下面两张时序图，直观对比两者的"运行轨迹"差异——一个是插件事件流转，一个是 JSON-RPC 消息处理管道：

五、实践落地建议：你的团队到底该抄哪家作业？

论文 Code as Agent Harness 在"开放挑战"一节点名了几个真问题：超越最终任务成功的评估、不完整反馈下的验证、无回归的 harness 改进、多 agent 间一致共享状态、安全关键动作的人的监督、以及多模态扩展。这两份开源物，恰好是其中两条不同解题路径的"参考答案"。

5.1 选型决策树

→ 选 DeepSeek 的插件化平台路线，如果你：

• 要构建企业内部统一的 Agent 基础设施；
• 需要兼容多种异构 LLM（国产模型、OpenAI、Anthropic、本地模型混用）；
• 允许各部门自建工具链，且重视可追溯、可审计（轨迹日志 + preset 快照是刚需）；
• 愿意接受"单实例、非高并发、v0.1 预览期"的当前成熟度，并为此投入插件生态建设。

→ 选 OpenAI Codex 的控制引擎路线，如果你：

• 要打造一款极致体验的 AI-native IDE 插件 / CLI 工具；
• 追求长任务的高成功率与低时延，把"跑得稳、崩了能回退"当硬指标；
• 接受"核心 Loop 不可替换、扩展走标准协议"，把工程重心放在产品体验而非改引擎；
• 需要引擎级的 Human-in-the-Loop 安全边界（沙盒分级 + 审批决策树）。

一句话给选型排序：如果你对"静默失败"的容忍度低于对"扩展广度"的需求，Codex 路线更稳；反之，若你要国产模型兼容、各部门自有工具链与可审计，DeepSeek 的"平台生态"仍是更高的 ROI——只是你要先吃下 v0.1 的静默失败税。

5.2 终局思考：不是二选一，而是融合

把视野拉到三年后看，这两条路大概率会汇流：未来的开源趋势，是"Codex 级的引擎内核 + DeepSeek 级的生态插件层"的深度融合。

也就是说——底层是一颗经过高强度验证、Rust 写就、把上下文压榨与长程状态控制做到极致的"控制引擎"（像 V8）；上层是一套基于微核规范的插件生态，让企业能按自己的合规、模型与工具链需求，像装 VS Code 扩展一样组装 Agent（像插件平台）。今天的 DeepSeek 把"上层生态"做透了但引擎还嫩，今天的 Codex 把"底层引擎"做绝了但生态封闭——两家各自的短板，恰好是对方的长板。

对正在做 AI Coding / AI Work 类工具与模型工程能力的团队而言，这篇文章的真正价值不在"站队"，而在于看清一个事实：Harness 之争的本质，是"把 Agent 做成可定制的平台"还是"把 Agent 做成可靠的引擎"的路线之争。先想清楚你的主战场在哪一层，再去抄对应的作业，才不会抄错地方。

如果只给一句站队建议：对大多数要做 AI Coding / AI Work 类工具的中国企业团队，我更倾向先抄 DeepSeek 的"平台生态"路线——理由很务实：你要兼容国产模型、要合规可审计、要各部门按自己的工具链组装，这些恰好是微核 + 插件的主场；而 Codex 那颗把上下文压榨到极致的引擎，更适合已经想清楚"只打磨一款极致产品"、且能接受核心不可替换的团队。

当然，这只是我们的判断。你所在的团队，主战场在"平台生态"还是"控制引擎"？