DeepSeek Harness 和 Codex 都能让 AI 在代码仓库中读取文件、调用工具、执行命令并持续完成任务，但它们的产品目标不同。DeepSeek Harness 把 Agent Runtime 本身变成可重组的工程对象；Codex 则提供一套已经集成好的编程 Agent 工作流，并允许团队在其上扩展规则、工具和自动化。
因此，这不是 DeepSeek 模型与 OpenAI 模型之间的简单对比。真正的问题是：团队想构建和研究自己的 Agent Runtime，还是希望用较少配置完成代码修改、测试、审查和交付。
核心结论
| 问题 | 结论 |
|---|---|
| 哪个更适合日常编码？ | Codex。它提供较成熟的本地、IDE、桌面和云端工作流，适合直接处理代码库任务。 |
| 哪个更适合构建 Agent Runtime？ | DeepSeek Harness。模型、工具、会话、沙箱、存储、执行循环、调度和 UI 都可以替换。 |
| 两者是开放与封闭的对立吗？ | 不是。两者都有开放组件；差异在于 DeepSeek 强调重组 Runtime，Codex 强调在完整产品工作流中扩展 Agent。 |
| 哪个模型选择更灵活？ | DeepSeek Harness。它把 Provider 可移植性作为核心能力；Codex 更紧密地围绕 OpenAI 模型与 Codex 生态设计。 |
| 可以同时使用吗？ | 可以。Codex 可作为日常交付基线，DeepSeek Harness 用于 Provider 实验、轨迹研究或定制 Runtime 验证。 |
为什么 Harness 不只是模型
编程 Agent 的结果不仅由模型决定。Harness 还负责向模型提供代码库上下文，并管理以下能力：
- 文件读取、搜索、编辑与命令执行。
- 工具定义、调用结果和失败重试。
- 沙箱、网络、凭据与审批策略。
- 会话状态、上下文压缩和任务恢复。
- 计划、执行、验证与停止条件。
- 日志、diff、事件流和人工监督界面。
同一个模型放进不同 Harness，可能产生完全不同的修改范围、工具使用方式和恢复表现。反过来，不同模型在相同工具循环中的差距，也可能小于产品名称给人的印象。
DeepSeek Harness 和 Codex 分别是什么？
DeepSeek Harness：可组合的本地优先 Runtime
DeepSeek Harness 是采用 MIT 许可证、目前处于 developer preview 阶段的 Agent Harness。它的核心设计是“一切皆插件”：Cordis 内核负责挂载模型、工具、会话、沙箱、存储、循环、调度和界面，开发者可以通过配置重新组合完整系统。
系统使用 append-only 会话日志记录提示词、推理、工具调用、结果、子 Agent 调度和上下文注入。Trajectory 视图可以用于检查、搜索、恢复、分叉和回放执行过程。这种设计适合研究 Agent 为什么作出某项决定，也便于复现实验。
DeepSeek Harness 提供多种 Runtime 模式：
| 模式 | 侧重点 |
|---|---|
| Standard | 面向一般编程任务的默认模式 |
| Code | 使用生成的 TypeScript 编排工具 |
| Minimal | 只保留 Shell 和编辑器等基础能力 |
| Creator | 用于组合和定制 Runtime |
它支持 DeepSeek、预置 Provider 目录，以及自定义 OpenAI-compatible endpoints。团队可以在保持工具循环基本一致的情况下切换模型或私有网关。
Codex：开放组件与集成式编程工作流
Codex 从较明确的默认执行循环出发，负责管理对话状态、工具、沙箱与审批策略、流式事件，以及跨多轮保持工作状态。Codex CLI 和 SDK 提供开放的本地集成路径，应用还可以通过 SDK 启动、继续或恢复线程，并为线程配置不同的沙箱权限。
在核心执行能力之外，Codex 提供 CLI、IDE、桌面和云端入口。任务可以在本地项目、隔离的 Git worktree 或已配置的云环境中运行。项目指令、规则、Skills、Plugins、MCP、审批和子 Agent 可以扩展工作流，而无需先重新设计 Agent 循环。
Codex SDK 适合把本地编程 Agent 嵌入内部工具。它能够创建、继续和恢复线程，并以事件流返回进度。对于需要更深层协议控制的产品，还可以通过 app server 与 Codex Runtime 通信。
关键差异一览
| 对比项 | DeepSeek Harness | Codex |
|---|---|---|
| 主要用途 | 构建、研究或重组 Agent Runtime | 使用集成式 Agent 工作流交付代码 |
| 架构 | Cordis 内核与全插件化 Runtime | 开放本地组件，加产品与集成层 |
| 模型策略 | DeepSeek、预置 Providers、自定义兼容端点 | 以 OpenAI 模型和 Codex 生态为中心 |
| 主要界面 | 本地 Web UI、专用 Runtime 模式 | CLI、IDE、桌面、云端、SDK、app server |
| 隔离方式 | 可替换 Sandbox 插件 | 本地沙箱、worktree、云环境与审批策略 |
| 可观测性 | Append-only trajectory，可搜索、分叉、恢复、回放 | 线程事件、执行进度、diff 和审批请求 |
| 自定义深度 | 可替换 Provider、会话、存储、循环和 UI | 通过指令、Skills、Plugins、MCP、SDK 扩展 |
| 当前成熟度 | Developer preview，可能破坏兼容性 | 多界面产品较成熟，具体新功能成熟度不一 |
Runtime 自定义能力
DeepSeek Harness 暴露的替换边界更深。Provider、Sandbox、Storage、Session、Tool、Loop、Scheduler 和 Interface 都属于同一插件体系。这种设计适合以下团队：
- 正在构建内部 Agent 平台。
- 需要比较不同上下文注入或恢复策略。
- 希望替换沙箱、存储或调度实现。
- 正在研究子 Agent、工具调用和执行轨迹。
- 需要面向特定业务设计专用 UI。
Codex 的扩展点更靠近开发工作流。团队可以通过项目指令、规则、Skills、Plugins、MCP Server、子 Agent 和宿主权限控制来改变行为，也可以用 SDK 或 app server 把线程能力嵌入其他产品。
两者的分界不是“能否定制”，而是定制发生在哪一层：DeepSeek Harness 允许重组整个循环；Codex 让团队扩展一个已经可以使用的循环。
模型与 Provider 策略
Provider 可移植性是 DeepSeek Harness 的核心能力。团队可以配置 DeepSeek 或其他预置 Provider，也可以连接兼容端点和内部网关。这便于用同一套工具与轨迹机制测试多个模型，并比较成本、延迟和可靠性。
Codex 围绕 OpenAI 模型和自身产品能力设计。紧密集成减少了 Provider、协议和工具兼容方面的配置决策，也让官方模型、沙箱、线程与产品界面形成统一体验；代价是 Provider 自由度不如 DeepSeek Harness。
模型评测不能脱离 Harness。一次任务的结果共同反映模型、系统指令、上下文策略、工具、权限、执行循环和失败恢复。比较时必须固定能够固定的变量，而不是把不同产品中的一次成功或失败归因于模型名称。
日常执行界面与交付效率
DeepSeek Harness 最直接的入口是本地 Web UI：选择工作区，配置 Provider 与模式，然后运行任务。它适合需要看清 Runtime 内部发生了什么的开发者，但团队也要承担初始化配置、插件组合和 preview 版本迁移。
Codex 为同一开发任务提供更多现成入口：
- 在 CLI 或 IDE 中直接处理当前代码库。
- 在桌面端管理本地项目和并行任务。
- 使用 worktree 隔离高风险或并发修改。
- 把任务交给配置好的云环境执行。
- 通过 SDK 启动、继续和恢复本地线程。
- 通过 MCP、Skills、Plugins 和子 Agent 复用工作流。
对于缺陷修复、多文件重构、测试生成、PR 审查、CI 恢复和工单到补丁等日常任务，Codex 的集成界面通常能减少团队自己搭建基础设施的工作。
轨迹、可观测性与恢复
DeepSeek Harness 的 append-only trajectory 是其显著特点。开发者可以查看模型得到的上下文、工具调用顺序、子 Agent 调度和返回结果，并从既有轨迹恢复或分叉。这对研究错误来源、复现实验和比较循环策略很有价值。
Codex 通过线程事件、执行进度、diff 和审批请求展示任务状态。SDK 可以继续同一线程或根据线程 ID 恢复过去的工作。它的可观测性更贴近日常交付：用户关注当前做了什么、哪些文件发生变化、需要批准什么，以及测试是否通过。
选择时应区分两种需求：如果要研究 Agent 如何运行，trajectory 级控制更重要；如果要稳定审查和交付代码，清晰的 diff、测试、事件和审批通常更实用。
安全边界与人工控制
DeepSeek Harness 以本地优先为设计原则，并详细记录模型看到和执行的内容。但只要启用了外部 Provider、Web 工具、MCP 服务或插件，数据仍可能离开本机。本地 UI 不等于完全离线。
Codex 更强调配置后的执行边界，包括本地、worktree 或云环境，文件系统沙箱，命令与文件变更审批，以及宿主对工具和网络访问的控制。使用 SDK 时，也可以按线程选择只读或工作区写入等沙箱范围。
两者都不能被简单标记为“天然安全”。实际风险取决于：
- Agent 能读取和修改哪些仓库与目录。
- 是否暴露生产凭据、云账号或内部网络。
- 已启用哪些插件、MCP Server 和外部工具。
- Shell 命令和网络访问是否需要批准。
- 合并、部署和基础设施变更是否保留人工检查。
成熟度与维护成本
DeepSeek Harness 明确处于 developer preview，核心 API 和插件边界可能发生破坏兼容性的变化。使用它构建内部平台时，需要为升级、迁移和集成回归测试预留工程预算。早期试点应放在可丢弃环境或非关键路径。
Codex 的日常产品工作流更成熟，但不能把所有界面视为相同成熟度。CLI、IDE、桌面、云端、SDK、app server 和较新的扩展机制可能拥有不同的发布节奏。生产采用前仍应针对计划依赖的具体入口验证稳定性与权限行为。
维护成本也不同：DeepSeek Harness 把更多 Runtime 所有权交给团队；Codex 减少默认配置工作，但团队仍需维护项目规则、Skills、工具连接、云环境和验收标准。
哪个更适合你的团队？
选择 DeepSeek Harness
- 工作成果本身就是自定义 Agent Runtime。
- 需要自由切换模型 Provider 或私有网关。
- 需要替换沙箱、存储、会话、循环、调度或界面。
- 重点研究上下文注入、子 Agent 或工具轨迹。
- 团队能够承担 preview API 变化和集成测试成本。
选择 Codex
- 主要目标是理解仓库、实现变更、运行检查并审查 diff。
- 希望在本地、worktree 和云端之间使用较完整的默认流程。
- 需要通过 CLI、IDE、桌面或 SDK 接入同一编程工作流。
- 想通过项目指令、Skills、Plugins、MCP 和子 Agent 扩展能力。
- 团队不希望先构建 Agent Runtime 才能开始交付代码。
同时评估两者
可以把 Codex 作为日常交付基线，在隔离分支或实验仓库中评估 DeepSeek Harness。两者处理同一个 commit 和边界清晰的任务时，应保持权限、测试、超时和成功标准一致。
适合记录的指标包括：
| 指标 | 观察重点 |
|---|---|
| 任务通过率 | 最终实现是否满足测试与验收标准 |
| 首次方案质量 | 是否需要推翻初始计划或大幅重做 |
| 恢复表现 | 工具或测试失败后能否找到正确路径 |
| 修改范围 | 是否产生无关文件或越界变更 |
| 人工干预 | 需要多少批准、提示与代码修正 |
| 可观测性 | 是否能解释上下文、工具调用与关键决策 |
| 总交付成本 | 模型、计算、运行时间与人工成本之和 |
一套可复用的实测方法
- 从相同的干净提交创建两个隔离工作区。
- 选择缺陷修复、多文件功能、构建诊断和只读审查各一项。
- 固定任务说明、文件、工具权限、超时和最大执行轮数。
- 为两者设置等价的测试、静态检查与验收条件。
- 保存完整事件、轨迹、diff、测试输出和人工干预记录。
- 重复执行任务，避免用一次成功结果判断稳定性。
- 按任务通过率、恢复能力和总成本决定生产基线。
最终结论
DeepSeek Harness 的优势是把 Agent Runtime 的每个关键层都暴露为可组合部件，适合平台建设、Provider 实验和执行轨迹研究。Codex 的优势是提供覆盖本地、IDE、桌面和云端的集成式编程工作流，让团队先交付代码，再按需扩展 Agent。
如果工作产出是自定义 Runtime，优先评估 DeepSeek Harness；如果工作产出是可测试、可审查的代码变更，优先评估 Codex。仍不确定时，让两者在同一仓库完成相同任务，以通过率、恢复表现、人工干预和维护成本决定，而不是只比较模型或产品名称。
