DeepSeek Harness 深度解析

背景

2026年8月13日，DeepSeek 正式开源了 Harness 开发者预览版。项目在 GitHub 上线一个多小时便突破两万 Star，引发了广泛关注。

从5月份组建 Harness 团队，到7月开启内测，再到8月以 MIT 协议完全开源，前后不到三个月。这个节奏表明，DeepSeek 此次并非只是发布一个新工具，而是在产品战略上进行了一次方向性调整。

Harness 的概念定义

Harness 这个单词的本义是”马具”，指缰绳、鞍具、辔头等控马装备的总称。马的能力再强，缺少 harness，骑手无法控制方向，更无法完成具体的工作。

在 AI 智能体的语境中，两者的关系可以精确对应：

Agent = Model + Harness

Model 负责思考、推理和内容生成。Harness 负责让模型的能力落地——调用外部工具、管理上下文状态、执行代码、维护对话记忆、协调多个子任务。

模型决定了系统的推理上限，Harness 决定了系统的执行下限。过去两年行业的注意力集中在模型能力的提升上——更大的参数量、更高的 benchmark 分数、更快的推理速度。但当开发者真正将模型部署到生产环境中时会发现，模型本身在整个系统中占比有限。绝大部分工程工作——工具集成、安全管控、状态管理、异常处理——都属于 Harness 的范畴。

AI 工程的三次范式演进

Harness 的兴起并非偶然。回顾过去几年 AI 工程领域的发展，可以看到一条清晰的演进路径。

Prompt Engineering（2022-2023）

这一阶段的核心目标是让模型正确理解任务指令。典型做法包括调整措辞、添加 few-shot 示例、指定输出格式等。本质上是在解决”如何把需求表达清楚”的问题。

这种方式在简单任务上效果良好。但当任务复杂度上升——例如要求模型分析整个代码仓库的安全漏洞并生成修复方案——单靠一段 prompt 便无法胜任。模型需要读取代码文件、调用分析工具、记住已检查的模块。单次输入的信息承载量存在天花板。

Context Engineering（2024-2025）

行业随之意识到，让模型在正确的时机看到正确的信息同样关键。这一阶段的核心是上下文工程——通过 RAG 检索相关文档、管理记忆系统、压缩历史对话、将关键信息注入模型的上下文窗口。

一个直观的类比：Prompt 是给新员工的任务简报，Context 是他手边的参考资料。简报写得再清楚，资料没到位，任务也难以完成。

Context Engineering 解决了信息供给的问题，但它只管”模型看到什么”，不干预”模型做什么”。如果模型决定执行一条危险的系统命令，Context Engineering 本身无法拦截。

Harness Engineering（2026-）

Harness Engineering 的关注点进一步上移到系统层面——不是模型说了什么、看到了什么，而是整个执行环境能做什么、怎么做、出错后如何处理。

它覆盖的核心领域包括：

领域	具体内容
工具编排	模型可调用哪些工具，调用顺序如何安排，失败后的重试或跳过策略
安全护栏	禁止执行的命令列表，文件操作的人工确认机制
上下文管理	对话历史的压缩策略，关键信息的持久化方案
任务规划	复杂任务的拆解方式，子任务之间的协调机制
记忆系统	短期工作记忆的维护，长期记忆的检索策略
执行沙箱	代码执行的隔离环境，资源限制与超时控制
可观测性	执行过程的日志记录，问题出现后的轨迹回放能力

三者的关系是层层包含，后者不替代前者，而是将前者作为自身的组成部分：

┌──────────────── Harness ────────────────┐
│  ┌──────────── Context ────────────┐    │
│  │  ┌──────── Prompt ────────┐     │    │
│  │  │  任务指令的表达          │     │    │
│  │  └────────────────────────┘     │    │
│  │  模型输入信息的组装              │    │
│  └─────────────────────────────────┘    │
│  Agent 运行环境的整体设计                │
└─────────────────────────────────────────┘

Prompt 解决”怎么说”，Context 解决”怎么看”，Harness 解决”怎么干”。

DeepSeek Harness 的架构与特性

发展时间线

2026年5月：DeepSeek 在招聘平台发布 Agent Harness 相关岗位，明确对标 Claude Code
2026年7月：开启小范围内测
2026年8月13日：发布开发者预览版，采用 MIT 协议开源

核心设计理念：一切皆插件

DeepSeek Harness 的架构设计围绕一个核心原则展开——一切皆插件。

模型、工具、技能、会话管理、沙箱、存储、Agent 主循环（Agent Loop），所有能力单元都以插件形式存在。这些插件通过一个名为 Cordis 的插件元框架组装在一起，开发者可以在配置文件中自由替换任意组件，无需修改源码。

这种设计的好处在于：需要更换底层模型、增加自定义工具、或替换执行沙箱时，只需调整配置，不需要重写系统。Cordis 框架本身建立在五个关键概念之上：

插件（Plugin）——每个独立的能力单元
上下文（Context）——插件之间共享的状态空间
服务依赖（Service Dependency）——插件之间的调用与依赖关系
类型化事件（Typed Events）——插件之间的通信机制
可撤销的副作用（Revocable Side Effects）——操作的回滚能力

四种运行模式

DeepSeek Harness 提供了四种运行模式。它们并非独立的系统，而是同一底座上不同的默认插件配置。

模式	定位	工具集	适用场景
标准模式	日常开发	文件编辑、Shell、搜索、Skills、子代理等完整工具集	常规编码与项目管理
PTC 模式	程序化工具调用	标准模式全部能力 + Code Mode SDK	复杂多步自动化流程
极简模式	基准测试	仅 bash + str_replace_editor	模型能力评测与对照实验
创造模式	动态扩展	Agent 可在运行时动态生成新工具	需要高度灵活性的创新任务

其中 PTC 模式（Programmatic Tool Calling）值得重点说明。

传统 Agent 调用工具的方式是逐步进行：推理→调用工具→读取结果→再次推理→再次调用。面对复杂任务，这个循环需要执行多次，每次交互都消耗 token。

PTC 模式的做法是让模型编写一段 TypeScript 程序，将多步操作编排在同一段代码中，然后一次性提交执行。程序内部支持循环、条件判断和多工具组合调用。这种方式大幅减少了模型与执行环境之间的往返次数，在降低 token 消耗的同时提升了复杂任务的执行效率。

轨迹回放机制

DeepSeek Harness 内置了全程轨迹追踪与回放功能。Agent 运行过程中的每一步操作都会被记录为 JSON 格式的 trajectory log，支持以下操作：

回放：完整复现某次执行过程，用于调试和问题定位
恢复：从任意历史节点重新执行
分叉：基于已有轨迹创建分支，探索不同的执行路径
检索：搜索和分析历史轨迹数据

这些轨迹数据的用途不止于调试。它们可以作为 demonstration 数据用于后续的模型训练——Agent 在实际使用中产生的执行记录，反过来为模型优化提供训练信号。这构成了一个数据飞轮：使用量越大，轨迹数据越多，模型能力越强。

与 Claude Code 的对比分析

维度	DeepSeek Harness	Claude Code
开发者	DeepSeek	Anthropic
开源策略	MIT 协议，完全开源	闭源商业产品
架构理念	插件化架构，组件可自由组合	一体化设计，深度绑定自家模型
模型绑定	不绑定特定模型，支持切换	深度绑定 Claude 系列模型
运行模式	四种模式可选	单一模式
特色功能	轨迹回放、PTC 模式、Cordis 插件框架	成熟的 IDE 集成、Hooks 系统
生态成熟度	刚开源，生态处于建设初期	社区和工具链相对成熟
使用成本	DeepSeek 模型调用成本较低	依赖 Claude API，成本相对较高

两者的设计取向有明显差异。Claude Code 采用一体化设计，开箱即用体验较好，但组件不可替换，且与 Claude 模型深度绑定。DeepSeek Harness 采用插件化架构，灵活度更高，支持模型切换和自定义组件，但上手门槛也相应更高。

对于需要快速使用的开发者，Claude Code 的成熟度更有优势。对于需要深度定制 Agent 系统、或希望避免单一模型厂商锁定的场景，DeepSeek Harness 的开源方案提供了更大的设计空间。

行业意义与竞争格局变化

竞争焦点的转移

过去两年，AI 行业的竞争焦点集中在模型能力上——参数规模、benchmark 分数、推理速度。DeepSeek Harness 的发布反映了一个趋势：竞争焦点正在向执行层迁移。

模型的推理能力再强，缺少完善的执行框架，依然无法在生产环境中稳定输出。有内测数据显示，同一个模型在不同 Harness 下的任务完成率差距可达53个百分点。执行框架的质量对最终效果的影响，在某些场景下已经超过了模型本身的选择。

落地能力的关键瓶颈

模型升级提升的是能力天花板，Harness 决定的是落地能力。大多数企业在将 AI 模型投入生产时遇到的真实困难，往往不是模型不够强，而是工具链不完整、上下文管理混乱、异常处理缺失、缺乏监控和调试手段。这些问题都属于 Harness 的范畴。

开源策略的考量

DeepSeek 选择以 MIT 协议完全开源，而非做成闭源商业产品，这一决策可以从两个维度理解。

生态维度。 Agent 框架的竞争本质是开发者生态的竞争。开源允许开发者和工具提供商自由使用、修改和扩展框架，是吸引外部参与者、建立插件生态最高效的方式。

数据维度。 轨迹回放功能可以将执行记录转化为训练数据。用户规模越大，积累的轨迹数据越多，模型优化就越有针对性。用开源换取用户规模，用用户规模换取数据积累，用数据积累驱动模型进化——这与 Android 早期通过开源建立市场份额、再通过生态规模巩固地位的逻辑有相似之处。

当前的局限与约束

作为开发者预览版，DeepSeek Harness 目前存在几个明确的约束：

缺少 CLI 工具。 当前仅提供 Web UI，习惯使用终端的开发者需要等待后续版本补充命令行工具。
插件生态处于早期。 架构设计支持灵活的插件替换，但可供选择的第三方插件数量有限，生态丰富度需要时间积累。
文档覆盖不完整。 特别是 Cordis 插件框架的开发指南，部分实现细节需要参考源码才能确认。
API 稳定性不足。 v0.x 阶段，插件接口和 API 存在破坏性变更的可能，不建议直接用于生产环境。

总结

DeepSeek Harness 的定位不是一个新的聊天机器人，也不是一个套壳 Agent 产品。它是 DeepSeek 从模型供应商向 AI 执行层基础设施拓展的战略产物。

如果将大模型比作发电厂，Harness 就是输电网。发电能力再强，没有输电网，电力无法到达终端用户。

2026 年 AI 领域的竞争，正在从”谁的模型更强”转向”谁的执行框架更成熟”。DeepSeek Harness 在这条赛道上率先交出了开源方案，其”一切皆插件”的架构设计和轨迹回放的数据飞轮机制，代表了 Agent 工程化落地的一个值得关注的技术方向。

至于能否在生态建设和持续迭代中保持领先，还需要后续观察。

参考资料：