在 DeepSeek V4 Pro 正式发布之后，DeepSeek 自家的 Agent 产品也终于亮相了——DeepSeek Harness。
它最值得关注的地方，并不是“又一个代码 Agent”，而是它背后的设计理念：一切皆插件（Everything is a Plugin）。
DeepSeek 给出的核心公式是：
Agent = Model + Harness
这个公式其实很好理解。我们平时使用的 Claude Code、Codex 等产品，本质上都属于 Harness：模型负责推理，而 Harness 负责工具、Skills、上下文、沙箱、存储、Agent 循环、子 Agent、工作流等一整套运行机制。
过去，这些能力大多被封装在一个完整的软件产品里。用户可以使用，但很少需要理解，更谈不上自由修改。
而 DeepSeek Harness 选择了另一条路：把这些原本隐藏在产品内部的能力全部插件化。
Harness 到底是什么？
DeepSeek Harness 真正特别的地方，在于它背后的 Cordis 内核。
Cordis 并不负责直接完成某个具体任务，它做的事情非常克制：管理插件的加载、卸载以及依赖关系。
更重要的是，插件甚至可以在 Agent 运行过程中动态变化，而且不会让整个 Agent 的运行状态直接崩掉。
这里面有两个关键概念：
Temporal composability（时间可组合性）：一个插件被卸载之后，它此前产生的副作用能否被完整撤销。
Spatial composability（空间可组合性）：一个插件依赖其他插件时，当依赖发生新增、删除或者变化，它能否动态重新处理这些依赖。
这两个能力结合起来，就产生了一件很有意思的事情：
Agent 不再只是使用工具，而是可以在运行过程中改变自己的工具和能力。
比如 Agent 发现自己缺少某项能力，它可以创建一个插件，再把这个插件加载进当前环境，然后继续完成任务。
这也是为什么 DeepSeek 没有把它简单命名成 Code 或 Build，而是叫 Harness。
因为它真正想做的，可能并不是一个功能完整、面向普通用户的 Agent 产品，而是一套可以不断扩展、组合和实验的 Agent 基础设施。
从这个角度来看，DeepSeek Harness 更像一个实验场：官方提供一批基础插件，开发者不断创造新的插件，最终让整个 Agent 能力体系变得越来越丰富。
四种模式，其实只是四套预设
第一次打开 Harness，很容易被它的四种模式搞懵。
但理解 Cordis 之后就会发现，这四种模式并不是 Harness 的本质，而只是官方提供的几套插件组合模板。
1. 标准模式
这是最适合普通用户的模式。
它预设了完整的代码 Agent 能力，包括文件读取与编辑、Shell、文件搜索、网页搜索、Skills、计划、目标、后台任务、子 Agent 和工作流等。
如果你只是想正常使用 DeepSeek Harness，直接选标准模式就够了。
2. PTC 模式
PTC 模式拥有标准模式的大部分能力，但改变了模型调用工具的方式。
传统模式下，模型往往是：
调用工具 → 获得结果 → 再思考 → 再调用工具。
而 PTC 会给模型一套 Code Mode SDK，让模型直接编写 TypeScript 程序，把多个工具操作组合起来，一次执行。
例如原本需要多次读取、搜索、筛选、并行调用的任务，可以被压缩成一次程序执行。
它的优势是减少模型与工具之间的往返，同时降低部分 Token 消耗，但代价是对模型的程序规划和调试能力要求更高。
所以普通用户没必要一上来就使用 PTC。
3. 极简模式
极简模式反过来，把环境压缩到了非常小的程度。
它主要提供一个持久 Bash 和文件编辑器，同时去掉大量额外能力。
它更适合做模型能力测试：如果你想比较不同模型在一个最小 Agent 环境中的表现，这个模式会很有价值。
但作为日常 Agent 使用，体验会明显受限。
4. 创造模式
创造模式才是整个 Harness 最有意思的地方。
它不仅可以使用现有能力，还可以检查当前运行的 Cordis 环境，并在内存中实验插件、创建新的 Agent 和插件。
也就是说，Agent 可以尝试改造自己。
比如你可以要求它：
“帮我创建一个只允许读取代码、不允许修改文件的安全审计 Agent。”
或者：
“创建一个拥有公司内部搜索能力和专属 Skills 的研究 Agent。”
甚至可以让它先检查自己有哪些能力，然后发现缺少某个工具时，现场创建一个插件并加载进去。
用一个简单的比喻来说：
Agent 发现自己没有扳手，于是自己造了一把扳手，装到自己手上，再继续干活。
这就是 DeepSeek Harness 最核心的实验意义。
另一个重要设计：一切都是事件日志
Harness 的会话设计也很特别。
它不是简单保存一段聊天记录，而是把整个 Agent 运行过程设计成一份只追加的事件日志。
系统提示词、用户消息、模型推理、工具调用、工具结果、权限变化、上下文注入、上下文压缩、子 Agent 调度等，都可以成为日志中的事件。
下一轮模型看到的历史，也是根据这份事件日志重新推导出来的。
这对于开发者来说非常重要。
传统 Agent 出问题时，我们经常只能看到“任务失败”或者“模型陷入循环”，却不知道它究竟从哪一步开始跑偏。
而事件日志和轨迹视图提供了一种更完整的方式，让 Agent 的运行过程变得可观察、可审计、可复现。
这也是 Harness 更偏向开发者和研究环境，而不是普通消费级产品的原因之一。
真正值得关注的，不是插件数量
DeepSeek Harness 目前最大的特点，也是它最大的争议。
喜欢它的人会觉得：
这就是未来 Agent 应该有的样子。
不喜欢的人则会觉得：
为什么一个 Agent 要搞得这么复杂？
我觉得两种看法其实都没错。
从普通用户的角度来看，Harness 确实存在明显的门槛：开发者术语多、概念复杂、功能之间关系不直观，很多能力需要自己理解插件、模式和运行机制之后才能真正发挥出来。
但如果站在 Agent 基础设施的角度看，它又确实很有意思。
过去我们使用 Agent，本质上是在使用一个已经被厂商设计好的“盒子”；而 Harness 试图把这个盒子拆开，把里面的工具、能力、运行机制全部暴露出来，让开发者自己重新组合。
所以我更愿意把 DeepSeek Harness 理解成：
它现在还不是一个成熟的 Agent 产品，而是一套正在形成中的 Agent 基础设施。
它真正想探索的问题不是“怎么做一个更好用的代码助手”，而是：
如果 Agent 的能力本身也可以被动态创建、安装、卸载和组合，那么 Agent 最终会变成什么？
这也是“一切皆插件”真正有意思的地方。
当然，现阶段它距离普通用户真正意义上的“好用”，还有很长的路要走。
但作为一次对 Agent 架构的大胆尝试，DeepSeek Harness 值得关注。
它可能不是最终答案，但至少提供了一个非常有意思的方向：
未来的 Agent，也许不再是一个固定的软件，而是一套可以不断改变自身能力的运行环境。
暂无评论内容