Agent Harness 编码范式#
2026 年 8 月 13 日晚间，DeepSeek 做了一次"闪电二连击"：在发布 DeepSeek-V4-Pro-0813 正式版模型的同时，悄然开源了 DeepSeek Harness 开发者预览版 v0.1。上线不到 48 小时，GitHub Star 数就突破了 9.3 万，首日更是以约 3.75 万 Star 的速度刷新了 AI 开源项目的记录。与此同时，OpenAI 也宣布开源 Codex 的 Agent Harness。两大 AI 巨头几乎在同一时间将目光聚焦于同一个概念——Harness（智能体运行时）。这并非巧合，而是 AI 编程领域一次深刻范式转移的信号。
一、什么是 Harness？为什么它突然变得重要？#
Harness 直译是**“马具”**——套在马身上那套缰绳和挽具。这个比喻很贴切：模型是一匹马力很强的马，但你需要一套缰绳和车厢，才能让它真正拉车干活。DeepSeek 官网给了一个干脆的等式：
Agent = Model + Harness模型负责思考和推理，而 Harness 负责模型之外的一切工程化工作：
- 执行能力：读写文件、执行命令、调用外部服务
- 上下文管理：长任务中积累的大量中间信息需要压缩、筛选和注入
- 权限控制：哪些目录能碰、哪些命令需要批准
- 状态保存与错误恢复：任务中断后能恢复、重试
- 循环与停止条件：什么情况下继续、什么情况下收尾
- 可观测性：记录每一步的输入输出，方便排查问题
你可以把 Harness 理解成 AI 的操作系统外壳——它决定了模型能看到什么、可以调用哪些工具、如何组织上下文、遇到错误怎么重试，以及什么时候判断任务已经完成。
为什么 Harness 突然变得如此重要？#
当模型评测从"单次问答"走向"真实工程任务"之后，Harness 本身已经成为影响评测结果的重要变量。一个设计良好的 Harness 能让中等水平的模型在复杂任务中表现优异，而一个糟糕的 Harness 可能让顶级模型频繁出错。这正是 DeepSeek 选择在 V4 Pro 正式版发布的同时开源 Harness 的原因——模型能力和运行框架必须协同进化。
从宏观视角看，AI 工程范式正在经历第三次跃迁：
| 阶段 | 形态 | 核心特点 |
|---|---|---|
| 第一次跃迁 | 对话式 AI | 模型即产品，一次提问一次回答，能力边界在"模型本身" |
| 第二次跃迁 | Agent + 工具调用 | Function Calling、MCP 等把外部工具接入模型，模型开始"动手" |
| 第三次跃迁 | Agent 运行时（Harness） | 在模型与工具之上增加循环、权限、状态、可观测、可组合的底座 |
DeepSeek Harness 正是第三次跃迁的代表作之一。
Martin Fowler——软件工程领域最受尊重的声音之一——在 2026 年撰文提出了 “Harness Engineering（线束工程）” 这个术语，标志着 Harness 已经从工程实践上升为一种正式的工程范式。
二、两种 Harness 路线#
当前市场上存在两种截然不同的 Harness 路线。
第一种：“产品优先"路线#
代表是 Claude Code 和 OpenAI Codex。它们本质上是把 Harness 做成了闭源成品——工具、Skill、会话管理、沙箱全部被封装进一个壳里。你得到的是精装房，墙不能拆、格局不能动。
Claude Code 追求的是"在当前范式下做出最好的 Agent 产品”，目标是最有效、最简单，同时最大化模型能力边界。
第二种：“框架优先"路线#
代表是 DeepSeek Harness（dsh）。它做的事相当于把精装房的施工图和所有预制件都开源了，告诉你"墙随便拆，零件随便换”。
DeepSeek Harness 以 MIT 协议开源，其核心理念只有五个字：一切皆插件（Everything is a Plugin）。这并非营销话术——模型适配器、工具注册表、会话日志、Agent Loop（智能体主循环）本身，全都可以替换。官方用了一句非常硬核的话：
“不存在需要打补丁的特权内核。”
与主流竞品的对比#
| 对比维度 | DeepSeek Harness | Claude Code | OpenAI Codex | LangGraph |
|---|---|---|---|---|
| 开源协议 | MIT 全开源 | 闭源 | 闭源 | MIT 开源 |
| 架构理念 | 一切皆插件，无特权核心 | 核心封闭，开放扩展点 | 封闭黑盒 | 图结构状态机 |
| 模型支持 | 可换近 40 种主流模型 | 仅 Claude | 仅 OpenAI | 模型无关 |
| Agent Loop 可替换 | 是 | 否 | 否 | 部分 |
| UI 可替换 | 是 | 否 | 否 | 不适用 |
| 多 Agent 编排 | Spawn/Fork/Workflow/Ralph | 有限 | 有限 | 图结构编排 |
| 可观测性 | Append-only 事件流 + Trajectory | 有限 | 有限 | LangSmith 集成 |
| 二次开发自由度 | 最高 | 受限 | 受限 | 中等 |
| 成熟度 | v0.1 预览版 | 成熟产品 | 成熟产品 | 成熟框架 |
形象地说，Claude Code 是精装房，拎包入住；DeepSeek Harness 是毛坯工坊，工具给齐了，但家具得你自己拼。
三、编码新范式：从"写代码"到"编排 Agent"#
Harness 的出现，正在从根本上改变软件开发的方式。
3.1 从"写脚本"到"编排 Agent"#
过去我们写代码，是一行一行地告诉计算机怎么做。现在有了 Agent Harness，开发者从"写代码的人"变成了"编排 Agent 的人"。你不再需要实现每一个细节，而是通过配置和组合插件，让 Agent 自主完成复杂的编码任务。
DeepSeek Harness 预置了四种运行模式，每一种都是一套不同的插件组合方案：
| 模式 | 默认插件集合 | 适用场景 |
|---|---|---|
| 标准模式 | 完整工具组合：文件操作、Shell、搜索、子任务委派、计划维护等 | 日常写代码、修 Bug、分析项目 |
| 代码模式（PTC） | 标准模式全部能力 + Code Mode SDK | 模型生成 TypeScript 程序来编排多轮工具调用 |
| 极简模式 | 只保留 Shell 工具和 str_replace_editor | 最小环境下做模型基准测试 |
| 创造模式 | 标准模式全部能力 + 运行时检查 + 插件试验 | 实验新插件，组合并创作新的运行模式 |
PTC（Programmatic Tool Calling）模式#
PTC 模式是四种模式中最具技术深度的创新之一。传统工具调用是"一轮一次"的：模型决定调用某个工具，等待结果，再决定下一步。而 PTC 模式允许模型先生成一段 TypeScript 程序，再由这段程序编排多轮工具调用。例如，模型可以写一段代码：先查询文件列表，对每个文件检查内容，根据匹配结果决定是否修改——整个过程在一次模型请求中完成，减少了多轮对话的延迟和上下文消耗。
四种模式本质上是四种 Profile（配置组合）。一个 Profile 是存储在 Harness 主目录中的命名组合，它列出了要堆叠的 Bundle、持有的任何外部插件，并保留用户自己的配置文件。一个 Bundle 是 Cordis 配置行及其所挂载代码的分发格式——无论它插入什么，都可以被上层 patch 覆盖。你可以通过以下命令查看机器实际启动的配置树：
dsh --profile web --dump-config这条命令打印出的任何行都可以被你自己的 patch 替换——不 fork 源码，只改配置。
3.2 模型无关：自由选择最优"大脑"#
DeepSeek Harness 在设计上完全不绑定自家模型。官方内置 DeepSeek 模型接入，同时支持 Anthropic、OpenAI 等提供方，以及任意 OpenAI 兼容的自定义端点。模型配置变更下次请求即生效，无需重启服务。
对于自定义提供方（公司网关、自建服务器等），只需选择"添加自定义提供方"，填写 Provider ID、基础 URL、API 协议、凭据和至少一个模型即可。你可以根据任务类型和成本预算自由选择最合适的模型：
- 让 Claude 写复杂逻辑
- 让 DeepSeek 做低成本批处理
- 让 GPT-4 做最后的代码审查
更令人惊叹的是，Harness 甚至可以把 Claude Code 和 Codex 作为子 Agent 来调用。通过解析 PATH 中的对应二进制文件，Harness 可以将任务委托给这些顶级的编程 Agent 执行。
竞争者的产品，变成了自己的零件。
与 MCP 的关系#
两者不在同一层。MCP 是连接 AI 应用与外部数据、工具、工作流的开放标准；Harness 是更上层的运行逻辑。MCP Server 可以成为 Harness 里的一个插件。
3.3 会话即事件流：可重现、可调试、可进化#
DeepSeek Harness 的另一个核心设计，是仅追加的会话日志（append-only session log）——这是整个框架最具特色的功能之一。
模型看到的所有内容都会进入同一份 append-only 日志，包括：
- 系统提示词（system prompts）
- 推理内容（reasoning / thinking）
- 工具调用及其结果（tool calls and results）
- 子 Agent 调度（subagent scheduling）
- 每一次上下文注入（context injection）
开发者可以在 Trajectory（轨迹） 视图中按照来源检查这些信息。会话恢复、分叉、检索与回放，也都建立在同一份事件流之上。
架构文档中有一条关键的运行时不变量：
模型可见即已记录（Model-visible means logged）。任何到达模型请求的内容都必须可以从日志中重建，运行时会断言这一点。
这项设计首先解决的是可观测性。Agent 任务失败时，问题可能出在模型判断、工具返回、上下文注入、调度策略或系统提示词。若这些内容散落在不同组件中，开发者很难还原模型当时究竟看到了什么。统一事件流给调试、评估和回放提供了一份共同底稿。
它也为会话分叉提供了更自然的数据结构：新分支可以沿用分叉点以前的事件，再追加新的上下文和行动，无需覆写原有历史。对于一个强调插件可替换的系统，这尤其重要——因为开发者需要比较不同 Loop、工具或调度插件在相同任务轨迹上的表现。
3.4 安全沙箱：让 Agent 安全地"动手"#
Agent 能读写文件、执行命令，这带来了巨大的便利，也带来了巨大的安全风险。DeepSeek Harness 构建了多层次的沙箱机制：
| 操作系统 | 沙箱技术 |
|---|---|
| Linux | Landlock 封装子进程 |
| macOS | Seatbelt |
| Windows | ACL 受限令牌 |
工具调用在 DeepSeek Harness 中被拆成了一条可扩展流水线，这是整个框架安全设计的核心：
Hook前置拦截 → Approval人工审批 → Permission权限检查 → Sandbox沙箱隔离 → Execute实际执行 → Rewrite结果改写 → Record记录+UI请求执行前会经过 Hook、审批、权限检查、沙箱和超时控制，执行后还可进行结果改写、记录和 UI 渲染。开发者无需修改工具或 Agent Loop，就能在各个环节插入插件。
架构中有一个核心概念叫 Seam（接缝）——一个可替换的能力，包含三个角色：
- Service Definition（服务定义）：声明接口
- Service Provider（服务提供方）：实现接口
- Consumer（消费方）：使用接口，通常是面向模型的工具
Seams 是为什么"一次提供方替换就能改变整个产品"的原因。文件系统和子进程提供方共享一个执行世界，因此将它们指向远程沙箱时，Bash、PTY 和 LSP 会随之移动，无需 provider 分叉。
四、Cordis 微内核：一切皆插件的技术底座#
DeepSeek Harness 底层的插件框架叫做 Cordis——一个只负责插件加载、卸载和依赖管理的微内核。Cordis 本身"几乎什么都不干"，它只提供三样东西：
- 插件的加载（mount）：把插件挂载到共享上下文中
- 插件的卸载（unmount）：卸载时自动撤销该插件注册的所有副作用
- 依赖关系管理：插件可以声明依赖，框架保证依赖先于消费方启动
你可以把整个 Harness 想象成一棵由插件组成的树：
Cordis Root Context
├── Loader
│ ├── Plugin: LLM Adapter (DeepSeek API / OpenAI API / Claude API)
│ ├── Plugin: Tool Registry (Shell Tool / File Editor / Sandbox)
│ └── Plugin: Agent Loop
└── 没有特权核心 —— 所有能力都是插件Cordis 的理念来自北京大学与 DeepSeek 联合署名的论文《A Programming Paradigm for Spatiotemporal Composability》，强调**“时空可组合性”**：
- 时间可组合性：插件卸载后，它注册过的服务、事件和副作用能随之撤销
- 空间可组合性：插件可以声明依赖，并在其他组件变化时重新建立协作关系
插件的三种形态#
Cordis 接受函数插件、对象插件和类插件（Service 子类）。每个插件通过一个 apply(ctx) 函数描述自己贡献的内容。cordis.yml 负责把这些插件"组合"成一个应用。
服务（Service） 是插件间协作的桥梁——一个插件提供、其他插件通过 ctx 消费的具名能力。在 Harness 中，ctx.tools、ctx.llm 和 ctx.agents 都是服务。消费方只指定 'tools' 之类的能力，而不导入其提供方，因此配置可以选择提供方，无需修改消费方。
inject 列出该插件需要的服务。Cordis 会让插件保持 PENDING 状态，直到列出的每项服务都存在。加载顺序由服务依赖决定，而非文件中的位置。
核心设计：动态依赖跟踪#
依赖跟踪是动态的。如果应用运行期间所需服务消失——例如提供方被卸载或热替换——每个依赖插件也会随之卸载，并在服务恢复后再次加载。这就是配置中可以替换服务的原因：卸载 dsh-bash-local，挂载另一个 shell 提供方，所有注入 'shell' 的插件都会重新启动并使用新实现。
生命周期与 Effect#
通过 Cordis API 建立的注册属于 effect，会在所属插件卸载时自动撤销。每个已加载插件实例都拥有一个 fiber，并在以下状态之间转换：
PENDING → LOADING → ACTIVE → UNLOADING → DISPOSED
↘ FAILEDfiber.dispose() 会等该插件的所有清理工作（包括异步 disposer）完成后才结束，并递归卸载它挂载的所有子插件。这种设计确保了插件系统的**“时间可组合性”**——卸载是干净的、可逆的、递归的。
五、更深层的野心：Agent 的自进化#
DeepSeek Harness 的真正野心，并不止于做一个更好的编码工具。
它把 Harness 设计成了可以被 Agent 自己修改、热重载的对象。这不是为了服务现在的编码需求，而是为了服务未来下一代的自进化和持续学习框架。
创造模式（Creator Mode） 是四种模式中最值得关注的设计。传统 Harness 的运行方式通常由产品开发者预先写定，用户只能在既有配置中选择。创造模式试图让 Agent 直接理解自己所处的运行时，再按任务需要试装插件和组合能力。换句话说，Harness 的配置本身也开始成为 Agent 可以操作的对象。
我们可以想象这样的场景：一个 Agent 在执行长达数天的复杂任务时，一边执行任务，一边更换支撑自身运行的部件，就像一艘持续航行的忒修斯之船。当它发现某个工具效率不高，可以自己写一个更好的插件并热替换上去；当它发现当前的推理策略不适合当前任务，可以自己调整 Agent Loop 的逻辑。
这就是 DeepSeek 与 Anthropic 的本质区别：
| 维度 | Anthropic | DeepSeek |
|---|---|---|
| 目标 | 在当前范式下做出最好的 Agent 产品 | 押注下一个范式——直接把替换、组合和撤销 Harness 本身作为研究对象 |
| 路线 | 产品优先 | 框架优先 + 自进化 |
Creator 模式虽然还不是一个完整的自进化系统，但它已经在为这一天做准备。DeepSeek 已经把运行时的可组合性同时交给了模型、配置文件和框架开发者。
六、多 Agent 编排：Spawn、Fork、Workflow 与 Ralph#
DeepSeek Harness 已经内置了一套完整的多 Agent 系统。父 Agent 可以通过多种方式启动子 Agent：
| 方式 | 说明 | 适用场景 |
|---|---|---|
| Spawn | 启动拥有全新上下文的子 Agent | 独立的探索任务 |
| Fork | 让子 Agent 继承已有会话——子请求保持父 Agent 的系统提示词和消息历史字节级一致，追加一个结构化状态快照，然后添加子 Agent 角色指令和任务 | 需要上下文连续性的任务 |
| Workflow | 模型通过 workflow 工具现场编写 JavaScript，用 parallel() 和 pipeline() 组织并行或流水线任务 | 复杂任务编排 |
| Ralph 循环模式 | 多个全新 Agent 按轮次接力——每个 Agent 在自己的轮次中工作，完成后将控制权交给下一个 Agent | 需要持续迭代的长时间任务 |
Fork 设计让 DeepSeek 前缀缓存复用率保持在较高水平。
如果放进常见的五种编排模式中，DeepSeek Harness 最接近层级式 Supervisor-Worker：父 Agent 负责拆解、分配和汇总任务，子 Agent 负责执行。更准确地说，它是一个以层级式编排为主，兼容并行、流水线和 Ralph 循环的混合系统。
真正特别的地方在于——它把这些编排方式做成了可以随配置替换的插件，甚至可以把 Claude Code、Codex 或支持 ACP 的外部 Agent 接到同一个子 Agent 接口后面。
七、范式转移的启示#
Agent Harness 下的编码新范式，带来的启示是深刻的：
第一，AI 编程的竞争正在从"模型竞赛"转向"Harness 竞赛"#
当模型能力逐渐趋同，真正决定 Agent 能否进入生产环境的，已经不只是模型能力，而是 Harness 如何管理上下文、状态、工具、权限、恢复与验收。
第二，开发者的角色正在被重新定义#
你不再需要事无巨细地编写每一行代码，而是需要理解如何设计、组合和编排 Agent 的能力。这是一种更高层次的抽象，也是一种更高层次的价值创造。
第三，开源正在重塑 AI 编程的格局#
DeepSeek 选择 MIT 协议开源，OpenAI 选择 Apache-2.0 开源 Codex 的 Harness。两家巨头不约而同地将最核心的 Agent 基础设施开放出来——这预示着 AI 编程的未来不属于任何一家公司的围墙花园，而属于一个开放的、可组合的、不断进化的生态系统。
DeepSeek Harness 目前仍是开发者预览版，但它在 64 天里完成了 12,293 次提交，附带 683 篇设计笔记。这种迭代速度本身，就是对"新范式正在加速到来"的最好证明。
八、挑战与局限：v0.1 阶段的冷静思考#
DeepSeek 在 GitHub 仓库的 README 中明确标注：
DeepSeek Harness is currently in developer preview and is iterating rapidly. THERE WILL BE COMPATIBILITY-BREAKING CHANGES.
这意味着现在进入生态的开发者需要承受较高的迁移成本。核心插件与基础接口仍会快速变化，尝鲜、学习、做二次开发完全没问题；追求稳定、要上生产，建议等版本收敛。
“什么都能换"这条路线也带来了明显挑战：
| 挑战 | 说明 |
|---|---|
| 接口稳定性 | 插件边界越深，接口稳定性就越难控制 |
| 依赖管理 | 插件之间的依赖关系可能变得复杂 |
| 版本兼容 | 不同版本的插件之间可能不兼容 |
| 性能开销 | 插件化的间接调用带来额外开销 |
| 调试复杂度 | 问题可能出在任何一个插件的交互中 |
更重要的是，“什么都能换"并不会自动带来更好的任务成功率。真正决定这套架构价值的，仍然是：
- 官方能否给出高质量的默认插件
- 能否形成稳定的组合范式
- 能否提供可信的评测结果
- 第三方开发者是否愿意围绕它持续构建插件
一位业内专家向 InfoQ 表示，从 Harness 的完整链路看，工具调用、记忆管理和任务规划等大方向已经基本确定，未来仍有大量创新会发生在各个局部环节：记忆管理需要压缩和冲突整理、任务规划需要复用已有路径、Plan 生成后需要增加一层近似"编译"的检查。DeepSeek “一切皆插件"的价值，也正在于为这些局部能力预留替换、组合和持续试验的空间。
模型是大脑，Harness 是手脚和神经系统。 而当我们不仅能让这套神经系统被自由组装，还能让大脑自己去改造它时——我们距离真正的、可自进化的 AI Agent，或许比想象中更近。
对于爱折腾的开发者来说，现在正是上手体验、参与生态建设的最佳时机。想要什么能力，自己拼——这正是"一切皆插件"的承诺。
“闭源为用户提供现在，开源让用户自己掌握未来。”