DeepSeek 近日发布了名为 DeepSeek Harness 的新产品，但它的形态可能出乎许多人的意料——不是一款调校完成的代码 Agent，而是一套开放的 Agent 开发基础设施。官方给出的定义是：Agent 等于模型加 Harness。在 DeepSeek Harness 中，工具、会话、工作流、子 Agent 乃至用户界面都可以被做成插件，由名为 Cordis 的内核统一负责插件的加载、卸载和依赖管理。更特别的是，插件甚至可以在 Agent 运行过程中被更换，系统还支持“创造模式”：当 Agent 发现自己缺少某项能力时，可以现场编写一个插件，再挂到当前流程里继续工作。
这一设计思路与市场此前的期待形成了鲜明对比。过去一段时间，已有不少第三方产品围绕 DeepSeek 模型修补结构化输出、优化工具调用、减少缓存消耗，例如作者提到的 Reasonix，甚至被 DeepSeek 官网作为核心接入 Agent 的工具来介绍。既然外部团队都能做出不错的配合，许多人自然期待 DeepSeek 亲自下场，把自家模型与 Harness 的配合再推进一步，推出一款类似“官方调校”的代码 Agent。但 DeepSeek 交出的答卷，不是一辆调校完成的“官配车型”，而是把试验台本身开放了出来。
这种开放性带来了明显的两极分化。从开发者角度看，DeepSeek Harness 的架构很有想象力：它允许 Agent 在运行中修改自己的能力边界，而不是像大多数现有 Agent 那样，能力范围由产品经理和开发者预先划好。它研究的不仅是“怎样让 DeepSeek 写代码更好用”，更是“未来的 Agent 能否一边工作，一边重组自己”。此外，系统采用只追加的事件日志，模型的提示词、工具调用、权限变化和子 Agent 调度都可被追踪，这对于研究 Agent 如何行动、如何失控、又如何恢复，具有独特价值。
然而，如果把它当作面向普通用户的代码产品，现阶段很难给出高分。安装、配置和概念门槛都不低，许多基础体验还要靠社区插件补齐。文件引用、侧边栏、视觉能力、自动化这些在成熟产品中理应自然存在的功能，在这里反而成了插件生态最先填补的空白。一个简单的例子：在许多 Agent 中已经习以为常的用 @ 标记文件的功能，在 DeepSeek Harness 中仍需要额外安装第三方插件才能实现。开放性在此刻既是优点，也像一张尚未完工的清单。
普通用户关心的往往是更实际的问题：模型会不会跑偏，文件会不会改错，任务能否一次做完，账单是否可控。一个系统允许你更换所有零件，不等于它已经比一辆成熟的量产车更好开。因此，网上最早出现的许多“整活”并不奇怪——它们证明了这套架构的上限很高，却没有回答普通用户最关心的那个问题：它现在能替我做什么？
不过，就此断言 DeepSeek Harness 没有价值，或许也为时过早。就像编辑器领域的 Vim 和 VS Code，它们的意义从来不只是默认安装后有多少功能，而在于允许开发者按照自己的工作方式持续改造工具。DeepSeek Harness 走得更远：它不仅让人写插件，还试图让 Agent 为自己写插件。这份价值眼下主要属于开发者和研究者，而非普通消费者。
DeepSeek 给产品取名“Harness”而不是“Code”，其实已经说得很坦白：它发布的不是一个替你写代码的完整答案，而是一套用来寻找答案的基础设施。市场期待的是 DeepSeek 版本的 Claude Code，而 DeepSeek 自己更感兴趣的，似乎是下一代 Agent 架构可能长成什么样。这也很符合 DeepSeek 一贯给人的感觉——它并不是一家特别愿意为 To C 体验反复打磨的公司，AGI、模型能力和技术探索排在前面，具体产品更像研究过程里顺手长出来的枝条。
评论认为，DeepSeek Harness 现阶段更像一个“极客玩具”——这不是贬义，极客玩具常常会提前展示未来，只是未来并不会因为被展示出来就立刻变得好用。试验台当然可能孕育下一代汽车，但如果你今天只是想开车上班，大概没必要先学会拆发动机。