DeepSeek 开源 Harness：Agent 的竞争，正在走向模型之外

admin

DeepSeek Harness 发布后，社区的反应很有意思。

一边有人说，DeepSeek 把这套东西开源，开发者终于可以少受某个闭源 Agent 生态的限制。

另一边，有人马上追问：既然模型、Harness 和算力都有了，为什么不直接推出一个编程订阅？

还有人只回了一句：

　　｜“another one。”

怎么又来一个 Harness？

这三种反应，刚好对应了三类人的期待：

· 开发者关心自由度；
· 普通用户关心好不好用；
· 已经被各种 Agent 工具轰炸过的人，只想知道它到底有没有实质性的不同。

发布一天左右，DeepSeek Harness 的相关发布内容接近 300 万浏览，项目仓库的星标也迅速超过 8 万。热度很高，但如果只把它看成“DeepSeek 版 Claude Code”，可能会低估这次开源真正值得关注的部分。相关发布[1]　项目仓库[2]

它更像是一套用来“制造 Agent”的运行时。

────────────

【一】模型会思考，但它还不会工作

一个大模型，可以理解问题，也可以生成代码。

但当我们真的希望它连续工作几个小时，自己读文件、调用工具、修改代码、运行测试、处理错误，它马上会遇到一系列模型之外的问题：

· 这一轮应该给它看哪些信息？
· 哪些工具可以调用？
· 执行命令前要不要经过用户批准？
· 任务失败后，是重试、回滚，还是停下来？
· 一次任务没有做完，下一次怎么接着做？
· 它怎么知道自己是真的完成了，而不是“觉得自己完成了”？

这些事情，都不是模型权重本身负责的。

负责这一层的，就是 Harness。

如果把模型比作大脑，Harness 更像是大脑之外的神经系统、双手、工作记忆、安全员和行车记录仪。

它负责把模型产生的意图，变成真实世界里可以被执行、被约束、被验证的动作。

所以 DeepSeek 招聘 Harness 研究员时，用了一句很直接的话：

　　｜Model + Harness = Agent.

这句话可能比“又一个代码 Agent”更接近 DeepSeek Harness 的真实定位。

【二】真正值得看的，是它把什么开放了

现在很多 Agent 产品也支持插件、Skills 和 MCP。

DeepSeek Harness 的不同之处，是它把插件化做得更彻底。

模型可以替换，工具可以替换，文件系统可以替换，沙箱可以替换，记忆和会话可以替换，Agent Loop 可以替换，连 UI 都可以替换。

官方把这套设计概括为：

　　｜Everything is a Plugin.

这意味着，开发者不只是能给 Agent 增加一个新工具，还可以改变这个 Agent 组织上下文、执行任务、保存状态和调用模型的方式。架构文档[3]

过去很多 Agent 产品像一辆已经造好的车。你可以换轮胎、加导航，但发动机和底盘是固定的。

DeepSeek Harness 更像是把发动机、底盘、仪表盘和控制系统都拆成了可以重新组合的部件。

这会带来更高的自由度，也会带来更高的理解成本。

对于普通用户来说，它目前未必比一个成熟的编程 Agent 更轻松。但对于真正想研究 Harness、定制企业 Agent，或者研究模型与 Agent 系统如何共同演化的人来说，它提供了一套少见的完整样本。

【三】它有几个值得关注的设计

◆ 一切模型可见的内容，都应该被记录

DeepSeek Harness 的会话不是简单保存几段聊天记录。

用户消息、模型输出、工具调用、工具结果、任务步骤、审批和状态变化，都会被写入追加式事件日志。

它提出了一个很重要的原则：

　　｜模型能够看到的内容，必须可以从日志中重新构造。

这样做的好处是，Agent 的运行过程可以被恢复、回放和分叉。

当任务失败时，开发者不必只面对一句“执行出错”，而是可以重新检查：

· 模型当时看到了什么？
· 它为什么做出这个选择？
· 工具返回了什么？
· 是哪一步开始偏离？

这看起来像一个底层实现细节，但它可能是 Agent 从“偶尔能跑”走向“可以长期维护”的基础。

◆ 工具不只是被调用，还要经过一道执行管道

在 DSH 里，一次工具调用不会直接落到系统上。

它会经过权限检查、审批、执行保护、结果处理和日志记录。

开发者可以在动作执行前拒绝它，也可以要求用户确认；执行后还可以验证结果，决定是否把这个结果交回模型。工具执行管道[4]

这使得 Harness 不只是模型的“手”，也是模型与真实世界之间的守门人。

◆ 模型可以写一段程序来组合工具

普通 Agent 每调用一次工具，都要在模型与执行环境之间往返一次。

DeepSeek Harness 的 Code Mode 会给模型生成一套类型化的 TypeScript 或 Python 工具接口，让模型在一个程序里完成循环、条件判断、并行读取和多步调用。Code Mode[5]

比如它不必：

· 读一个文件，回到模型；
· 再读一个文件，再回到模型；
· 搜索一次，再回到模型。

它可以写一段小程序，把这些动作组合起来，只把最后真正需要的信息带回上下文。

这有机会降低工具调用的往返成本，也能减少中间数据对上下文窗口的占用。

不过，普通工具造成的副作用不会随着程序失败自动回滚。这一点在代码环境里已经需要谨慎，到了硬件环境里就更需要单独设计安全边界。

◆ Agent 甚至可以修改自己的运行方式

DSH 还提供了一个 Cordis/Creator 模式。

这个模式允许 Agent 查看并修改自己正在运行的 Harness 配置，甚至创建新的 Agent Preset。

换句话说，它不只是在执行任务，也可以参与设计“下一次要以什么方式执行任务”。

这是很有想象力的一步，但也相当危险。官方明确提醒，这个模式的信任级别接近 Shell 权限。Creator Preset[6]

所以它目前更像一个 Harness 研究实验室，而不是可以随便交给普通用户的自进化功能。

【四】它的创新，不是发明了某一个功能

插件、事件日志、沙箱、MCP、多 Agent，这些概念都不是 DeepSeek 首次提出。

DeepSeek Harness 真正有意思的地方，是它把这些分散的能力放进了一套统一、可替换的运行时里。

它把 Agent 外层的工程系统，从产品内部不透明的实现，变成了一套可以研究、修改和重新组合的对象。

这里也需要保持一点克制。

支撑它的 Cordis“时空可组合性”论文，目前还是正在修改中的预印本。官方仓库也没有提供能够证明它超过 Claude Code、Codex 或其他 Harness 的正式基准测试。Cordis 论文[7]　Benchmark 文件[8]

所以现在更准确的评价可能是：

它的架构方向很前沿，设计野心也很大，但产品成熟度还需要时间验证。

【五】社区里的争论，其实都说对了一部分

觉得它带来开源自由的人，看到了模型之外那层基础设施的价值。

要求 DeepSeek 推出订阅的人，看到了“底层平台”和“普通用户能直接使用的产品”之间还有距离。

觉得“怎么又一个 Harness”的人，也提出了一个合理问题：

　　｜架构再漂亮，最后还是要回答完成率、成本、稳定性和体验。

现在的 DSH 仍处于 Developer Preview。官方明确提醒未来会有破坏性变更。

社区也已经出现了一些早期反馈，包括长会话性能、子代理数量边界，以及 Web 授权控制面可能存在的安全问题。这些目前主要来自用户报告，部分已有修复讨论，不能直接当作官方确认的安全结论；但它们足以说明，现阶段不适合把 DSH 直接放到高权限生产环境里。性能讨论[9]　子代理讨论[10]　授权边界讨论[11]

尤其值得注意的是，DSH 当前的沙箱主要约束文件系统写入，网络访问和进程可见性不属于同一套限制范围。沙箱文档[12]

对于一套刚刚开放的复杂 Agent 运行时来说，这种情况并不意外。

只是我们需要把“很值得研究”和“已经适合生产”分开。

【六】它可以用在哪里

1. 代码 Agent。开发团队可以给不同项目配置不同工具、权限、模型和上下文策略，也可以把它接入企业内部模型、自建网关和远程沙箱。
2. Agent 研究。研究者可以更换 Agent Loop、上下文压缩、长期记忆、子代理策略和工具呈现方式，测试究竟是哪一层改变了模型的实际表现。
3. 企业内部自动化。只要提供对应插件，它可以连接业务系统、数据平台、测试环境和内部知识库，并保留相对完整的任务执行记录。
4. 嵌入其他产品。它既有 Web UI，也提供 headless、JSON-RPC 和 Python SDK，因此可以被放进桌面应用、IDE、内部平台或者后台服务。Python SDK[13]

再往外延伸，它也可以用于研究 Agent 如何操作浏览器、数据系统、仿真环境和真实设备。

但走到这里，问题就不再只是“给 Agent 多装几个工具”。

────────────

【七】AI 硬件真正可以学习什么

把 DeepSeek Harness 和 AI 硬件放在一起看，最容易想到的是：

　　｜给 Agent 一个串口工具、一个 GPIO 工具，它是不是就能控制开发板和机器人了？

技术上可以。

但这可能不是最值得学习的部分。

◆ 模型不能进入实时控制环

机器人、电机、电源系统和工业设备的底层控制，需要确定的时序、命令限值、看门狗和故障回退。

这些事情应该继续由 MCU、RTOS 或 ROS Controller 负责。

LLM 和 Harness 更适合处理秒级的高层任务：

· 理解用户意图；
· 拆解任务；
· 选择已有动作；
· 分析传感器和日志；
· 判断是否需要调整计划。

ROS 2 的控制架构本身就强调实时循环、命令限值和失败后的回退机制。ROS 2 Controller Manager[14]

因此，比较合理的分工是：

· 模型负责理解和规划；
· Harness 负责工具、权限、记录和验证；
· 实时控制器负责真正的运动和安全。

◆ 软件可以卸载，物理动作不能撤销

Cordis 讲“可逆副作用”，主要指插件卸载时，可以撤销它注册的软件行为。

但到了物理世界，这个概念必须重新理解。

插件可以卸载，机械臂伸出去的手不能自动回到原位。

会话可以回放，烧毁的器件不能回放。

软件世界可以使用 Git 恢复文件，现实世界没有一个通用的 `reset --hard`。

所以 AI 硬件需要额外建立一套模型无法绕过的安全层：

· 动作限值；
· 电流和温度保护；
· 独立看门狗；
· 紧急停止；
· 人工审批；
· 执行后的传感器验证；
· 仿真和 HIL 测试。

NVIDIA 在边缘 AI 和机器人资料中，也把仿真与硬件在环测试放在真机部署之前。NVIDIA Jetson 与 HIL[15]

◆ 最适合先做的，不是“AI 控制机器人”

如果现在要基于这一套思路做一个 AI 硬件项目，比较合适的起点可能是一套固件开发与硬件测试 Agent。

它运行在 PC、服务器或 Linux ARM 边缘主机上，连接编译器、烧录器、串口、测试仪器和继电器。

Agent 负责：

· 编译固件；
· 烧录测试板；
· 读取串口日志；
· 执行测试；
· 发现失败后分析原因；
· 修改代码，再跑一轮。

这里有编译器、日志、传感器和测试程序提供反馈，Agent 不需要只凭自己的语言判断任务是否成功。