源码级拆解：平台生态 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 Harness deepseek-ai/deepseek-harness TypeScript / Node.js（Cordis 元框架） 2026-08-15（v0.1 开发者预览，GitHub 星标已破 9.6 万） OpenAI Codex Harness openai/codex （codex-rs，Rust 内核 ~120 crate） Rust（早期 TS 原型已重写为 Rust 多入口 harness） CLI 前端 2025-04 开源；Rust 控制引擎与 App Server 后续开源 生产级 Coding Agent 的核心控制引擎 / Runtime
注意一个细节：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 用五个底层问题定义了插件运行时必须回答的契约，这也是理解整个框架的钥匙：
能力坐标 依赖激活 效果撤回 每个插件实现 mount() / unmount() 生命周期，保证可回滚 组合形态 preset 是一组插件配置的快照，可保存、分享、恢复 自省演化 Cordis 暴露自身 API，插件可查询/修改其他插件状态
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 思路）； 动态创建一个新工具并注册 ——文档里的例子是 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） 。模型在每次会话中看到的一切——系统提示、推理过程、每一次工具调用与返回、子任务调度、上下文注入——都被完整记录在一个只追加的日志里。它带来的四个能力直接对标行业痛点：
对比 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（消息、命令、文件变更、工具调用等单元） 三级结构，并在此之上实现生产级的状态控制：
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 靠反向扫描器避免全文件读——管理状态时要分清两层。 生态属性弱 ：它要的是你"用它"，不是"在它上面长东西"。 四、深度硬碰硬：源码级关键维度对比矩阵 把前面拆到的源码事实收敛成一张可直接拿来汇报的矩阵：
本质定位 开源平台与可扩展生态（Framework & Platform） 高可用控制引擎与 Runtime（Core Engine） 架构模式 微核（Microkernel）：Cordis 容器 + 插件拓扑 状态机 / 控制管线（Pipeline）：Rust 引擎 + JSON-RPC 协议层 设计核心 上下文工程 基于 Hook / 轨迹日志的动态注入与全量可回放 基于 Memory Stream 的精细化压缩（compaction）+ 上下文预算管控 可扩展性 极高（Loop、UI、上下文注入都能动态换；Creator Mode 运行时热加载） 偏固化（重点透出标准协议：JSON-RPC、 thread/turn/item 、MCP/plugin 接口） 长程状态控制 轨迹日志 + preset 快照：可恢复、可搜索、可回放 thread/fork / resume / rollback + sessionId 会话树：可分支、可回退、不污染主干 安全模型 工作区级权限（write/read/full）+ 逐条审批对话框 沙盒策略分级 + 服务端发起的审批决策树（Human-in-the-Loop） 已知故障面 dsh doctor 扫描出 9 类静默失败 （P5 日志序号跳号静默损坏、P6 环境变量静默剥离、P9 跨实例删 file_id）；缺原生 TUI（社区 dsh-desktop 补位） OpenAI 自承请求体 O(n²) 增长；MCP 工具 不受沙箱保护 ；PR #2611 缓存雪崩 bug；早期 WAL 写爆 SSD（ rust-v0.142.0 修复） 运行闭环 App Server（JSON-RPC 2.0）串起引擎与客户端 适用场景 追求极致执行力的单体 Coding Agent 产品（IDE/CLI/CI） 类比
下面两张时序图，直观对比两者的"运行轨迹"差异——一个是 插件事件流转 ，一个是 JSON-RPC 消息处理管道 ：
五、实践落地建议：你的团队到底该抄哪家作业？ 论文 Code as Agent Harness 在"开放挑战"一节点名了几个真问题：超越最终任务成功的评估、不完整反馈下的验证、无回归的 harness 改进、多 agent 间一致共享状态、安全关键动作的人的监督、以及多模态扩展。这两份开源物，恰好是其中两条不同解题路径的"参考答案"。
5.1 选型决策树 → 选 DeepSeek 的插件化平台路线，如果你：
需要兼容多种异构 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 那颗把上下文压榨到极致的引擎，更适合已经想清楚"只打磨一款极致产品"、且能接受核心不可替换的团队。
当然，这只是我们的判断。你所在的团队，主战场在"平台生态"还是"控制引擎"？
粤ICP备14082021号
免费POC，
零成本试错
