DeepSeek Harness 到底是什么？

DeepSeek Harness 与 DeepSeek-R1、DeepSeek-V4 等大模型由同一家公司推出，却不是同一种产品。

官方用一个很简洁的公式概括两者的关系：Agent = Model + Harness。

模型提供智能，Harness 提供模型工作时需要的外部系统。DeepSeek Harness 也不只支持 DeepSeek 模型。模型能力在系统中由可替换的 Provider 提供，只要存在相应的适配器，也可以接入其他模型服务。

这些定义听起来还是有些抽象。下面先不背术语，我们从一个具体的例子来理解。

假设你打开 ChatGPT，要求它：

模型很快就能生成一份代码，但结果可能并不好。苹果 Logo 看似简单，轮廓比例却很讲究。模型只根据文字描述凭空画路径，很容易画出一个歪歪扭扭的苹果。

这时候，我们可以先去图标素材网站找到一份准确的苹果 Logo SVG，把 SVG 代码交给模型参考。模型不再凭空猜轮廓，生成效果通常会好很多。

问题是：难道以后每次画 Logo，都要我们先搜索素材、复制 SVG，再手动发给模型吗？

当然可以把这件事自动化。

我们开发一个简单的网站，在后台通过 API 调用模型，同时准备一个 search_logo 函数，专门负责搜索图标素材。当用户提出需求后，网站和模型可以这样配合：

1. 网站把用户的动画需求发给模型，同时告诉它现在可以使用 search_logo 工具。
2. 模型判断自己需要准确素材，于是发出工具调用请求：搜索“苹果 Logo”。
3. 网站后台真正执行搜索函数，得到一份 SVG 素材。
4. 网站把工具结果送回模型，模型参考 SVG 生成线条动画。

注意，模型并没有亲自访问素材网站。它只是做出判断并提出工具调用请求，真正运行函数的是模型外面的程序。

现在，这个网站已经不只是给 ChatGPT 换了一个页面。它开始替模型准备工具、执行工具，并把结果送回模型继续处理。

有了 Logo 素材，效果会稳定很多，但仍然可能翻车：路径动画可能没有闭合，尺寸可能超出画布，最终渲染效果也可能和预期不一样。

于是我们再增加一个 render_preview 工具，把模型生成的 SVG 动画渲染成图片，并把检查结果返回给模型。同时在系统提示词里说明：生成完成后必须检查；如果结果不合格，就修改代码并重新检查。

整个过程就变成了：

模型先判断需要素材，调用搜索工具；拿到 SVG 后生成动画；再调用视觉检查工具；如果发现问题，就继续修改和检查。这个“思考—行动—观察”的循环，通常被称为 ReAct。

走到这里，我们已经做出了一个最简单的 Agent：它不只生成一次回答，还能根据任务选择工具、观察结果并继续工作。

可以先用一个简化公式理解它：

其中，模型负责判断下一步；工具负责接触外部世界；循环负责把模型回答、工具调用和工具结果一轮轮串起来。

这和开头的“Agent = Model + Harness”并不冲突。前一个公式是在描述 Agent 表现出来的工作过程；后一个公式是在描述完整产品怎样组成。工具、循环、会话和权限这些运行条件，最终都需要由 Harness 提供和管理。

这个苹果 Logo Agent 已经可以演示了。但只要真的让用户使用，很快就会遇到更多问题：

• 模型给出的工具参数不符合要求，应该直接执行还是让它重试？
• 搜索工具卡住了，要等多久才算超时？
• 用户上传的 SVG 带有危险代码，谁负责拦截？
• 视觉检查连续失败，最多允许重试几次？
• 对话越来越长，超过模型的上下文窗口怎么办？
• 网页刷新或者任务中断后，之前的执行过程还能不能恢复？
• 哪些工具可以自动运行，哪些操作必须先让用户批准？

如果这些问题全靠一个临时脚本处理，代码很快就会变成一团互相缠绕的判断。我们需要在模型外面建立一套稳定的运行系统，统一管理输入、工具、循环、权限、会话、错误和结果。

这套包在模型和 Agent Loop 外面的工程系统，就是 Harness。

Harness 这个词原本有“马具”的意思。马具不会替马奔跑，却能帮助人控制方向、约束动作并安全地完成路程。类似地，大模型提供推理能力，Harness 则把这种能力接入真实环境，并管理它怎样运行。

因此，Agent 和 Harness 关注的问题并不完全相同：

回到前面的例子。如果使用 DeepSeek Harness 来实现，用户、模型、工具和运行记录大致会形成下面的关系：

图 1-1：UI 负责接收需求，Agent Loop 负责推动任务，模型和工具提供能力，SessionEvent 保存每一步发生的事情。

用户从 WebUI、命令行或 API 提交“绘制苹果 Logo 动画”的任务。Agent Loop 读取当前会话，把任务和可用工具交给模型。模型发出 search_logo 调用请求，工具系统检查参数并执行搜索，然后把 SVG 结果写进会话。

Agent Loop 读取新的会话状态，再次调用模型。模型生成动画后继续调用 render_preview。如果检查不通过，工具结果会再次回到会话，成为下一轮判断的依据；检查通过后，最终结果才返回给用户。

在这个过程中：

• UI、CLI、API 负责接收任务和展示结果；
• Agent Loop 负责推动“模型—工具—模型”的循环；
• LLM Provider 负责连接具体模型；
• Tools 负责搜索素材、渲染检查等真实操作；
• Session 和 SessionEvent 负责保存消息、工具调用和执行结果；
• 权限与防护插件 负责约束危险操作、超时和异常情况。

这样一来，搜索 Logo 和视觉检查只是两项可以替换的工具能力。以后想增加品牌规范检查、配色分析或者动画性能检测，也不需要重新发明整套 Agent 运行系统。

不同 Agent 需要的能力并不一样。编程 Agent 需要文件、终端和代码搜索工具；自媒体 Agent 需要网页搜索、资料整理和图片生成；苹果 Logo 动画 Agent 则需要素材搜索和视觉检查。

如果所有能力都硬编码在同一个程序里，系统会越来越难修改。DeepSeek Harness 因此把模型接入、工具、Session、Agent Loop、界面和很多防护能力都做成插件，再根据运行场景把需要的插件装配起来。

这也带来了接下来会频繁出现的一组名词：Plugin、Profile、Bundle、Patch、Preset、Context 和 Provider。现在不用急着记住它们。此时只需要知道，它们都在回答同一个问题：

第一，DeepSeek Harness 不是大模型，而是运行在模型外面的 Agent 工程系统。

第二，模型负责判断，工具负责行动，Agent Loop 负责让“思考—行动—观察”持续进行。

第三，Harness 进一步管理会话、权限、错误、上下文和运行环境，让 Agent 不只是能演示，而是能够可靠地完成真实任务。