# 从"Everything is a Plugin"看DeepSeek Harness的设计

DeepSeek Harness 最醒目的口号是 **Everything is a Plugin**。按照官方文档，模型适配与工具注册由插件提供，连Session Log 和 Agent Loop 也可以通过配置替换。

但对目前最典型的Agent用户群体而言，程序员已经习惯了功能强大但是越来越雷同的Coding Agent，更广大的非程序员用户群体则是习惯了把harness封装起来并承诺同样强大的AI工具，这套设计首先带来的是对用户心智的概念爆炸：Profile 决定加载哪套组合，Bundle 负责分发配置与代码，Cordis 管理插件的依赖和生命周期。X上普遍存在对DeepSeek Harness的批评，大致可以总结为它是”一种来自于程序员的自high“，毕竟OpenClaw及其变体今年走红就是在不断给大众承诺AI”越来越好用“，但DeepSeek Harness似乎反而做得比Claude Code和Codex还要复杂。Claude Code 和 Codex 已经把大部分选择收进一套经过打磨的默认体验里，DeepSeek Harness 却主动把它们放到了公开的控制面上。

这也是我理解它高门槛的起点。DeepSeek Harness 可以作为 Coding Agent 使用，但它给自己的设计边界考虑得更宏大。Coding Agent 是今天最成熟的一类 Agent，未来的 Agent 还会进入更多业务领域。一旦运行对象离开代码仓库，上下文、执行方式和失败恢复都很难长期沿用 Coding Agent 的固定框架。从我的视角来看，DeepSeek Harness的这个设计准则与我强调的”工程化“是几乎完全相同的理念，不管是Coding Agent还是未来的其它成熟场景，AI仍然是要在一整套工程化的体系当中运行，DeepSeek Harness便是要建立这样的基础框架，它先建设一套可以重组的 Agent Runtime，并为后续的领域封装保留接口，本质是通过较高的初始复杂度来换取替换内部部件的空间。

当然了，以我的工作经验来看，类似的由于理念崇高、梦想高远而创造概念、过度分层的项目也非常多，而且它们还很难在某个阶段就证明哪里有问题。只是突然有一天你会发现，TCP/IP在实践中代替了OSI七层模型，C++模板库ACE被评价为”学之者生，用之者死“，OpenStack从”第二个Linux“变成了无数团队的噩梦。关于这个风险，我暂时还无法评估，本文先从正面理解DeepSeek Harness的角度拆解它的设计。

## 高门槛来自DeepSeek的主动选择

把 DeepSeek Harness 和 Claude Code、Codex 放在一起比较，很容易把问题理解成谁的操作体验更方便和插件生态更丰富。用这个来看OpenCode和PI等Coding Agent是非常务实的角度，但这似乎就窄化了DeepSeek Harness的设计目标。

Claude Code 已经形成完整的插件机制，Codex 也支持 Skills 与 MCP；两者都公开了会话事件和审批能力。它们的产品中心十分明确：用户进入一套成熟的 Coding Agent，由产品给出上下文组织、工具循环与交互方式，用户再从外围增加能力。

Everything is a Plugin的原则针对的问题更深入。模型与工具系统来自插件，持久化和 Agent Loop 也遵循同一规则。官方目录又把执行环境、凭据、沙箱与工作流抽象成接口。接口开放以后，使用者获得了更大的控制权，也接过了一部分产品设计责任。原来由Coding Agent替用户封装起来的具体决策，现在被Profile、Bundle 和插件依赖等概念呈现给用户去自由选择。

DeepSeek Harness 的复杂直接来自于它的主动选择：它在以自己的方式尝试解答”Harness的本质是什么“和”最好的Harness应该长成什么样“。它要求选择能够组合和替换，并在替换以后维持一致的运行语义。用户看到的 Profile、Capability 和 Session Event，是这笔架构成本在界面与配置层的投影。目前已经发布的版本被称之为Developer Preview，即是在暗示这是在为开发者准备的最完整的概念框架，只是我估计以后新的版本也不会让它的高门槛降低到哪里去。

## Coding Agent 只是当前最成功的一种组合

Coding Agent 之所以进展快，与软件开发本身的结构有关。代码仓库划定边界，Agent 通过终端行动，再由测试形成反馈，Git 则保存可以比较和恢复的修改。Claude Code 和 Codex 围绕这套闭环持续优化，于是用户得到一条很短的路径：提出任务以后审查修改，再运行验证并提交结果。

领域 Agent 很少共享这样统一的工作面。进入生产运维以后，Agent 面对持续变化的服务状态，它的输出还可能触发线上操作。企业流程中的上下文又散落在业务系统里，行动受到组织权限约束。给 Coding Agent 增加提示词和工具可以接入能力，却无法顺带确定状态怎样保存、审批放在哪里以及失败后由谁接管。

这正是 DeepSeek Harness 的可替换性发挥作用的地方。不同领域可以保留相同的插件运行机制，再换上适合自己的会话存储、执行环境或 Agent Loop。一组经过验证的插件与配置还能封装成 Profile，交付给固定用户。这样一来，Coding Profile 只是 DSH 上的一种发行形态（Standard Mode），其他领域也可以形成自己的版本。它们未必共享界面，却可以共享底层的生命周期和事件语义。

## Standard Mode 是 DSH 装配出来的 Coding Agent

Standard Mode 本身就是一个 Coding Agent，这也是大多数人第一次接触 DSH 时最容易形成的印象。它能在代码仓库中调用工具完成任务，直接使用时与 Claude Code、Codex 处在同一个产品层。这个入口容易遮住 DSH 的另一层设计：Coding Agent 描述的是 Agent 处理哪类工作，DeepSeek Harness 处理的是 Agent 由哪些能力组成，又怎样在会话中持续运行。为 DSH 选择面向代码工作的 Profile，它就呈现为 Coding Agent；领域团队改写 Profile，并接入自己的数据和执行工具，同一套 Harness 便可以承载另一类 Agent。Standard Mode 直接复用 Session 的状态记录和工具执行机制，运行轨迹由此保留下来；这套运行层的质量会直接影响 Standard Mode 的会话管理、工具调用和异常处理。**Coding 是 DSH 已经装配好的一种用途，Harness 才是它希望复用到其他领域的运行结构。**

领域团队可以用 Coding Agent 开发插件，完成后交给 DSH 运行。Claude Code、Codex 或 DSH 自己都能完成插件和 Profile 的开发测试；部署后的 DSH 接收领域任务，按对应的 Profile 装配上下文和工具。今天已经有人用 Claude Code 开发依附于 Claude Code 运行的工作流，代码开发很顺手，交付给领域用户以后却要迁就一个围绕代码任务设计的宿主，OpenClaw 也受到了这种实践思路的启发。DSH 预先拆开 Profile、插件和运行时接口，领域团队可以围绕自己的任务重新组合它们。

沿着这套结构，可以推演一个云服务故障处理 Agent。团队先用任意 Coding Agent 编写监控查询和变更审批插件，并把它们组合成 Profile。告警进入 DSH 后，运行时将输入写入 Session，领域插件装配服务拓扑和近期变更，模型据此生成诊断调用。DSH 解析调用并交给 Provider 执行，工具结果写回同一 Session，新增事件形成下一轮模型输入。生产变更触及权限边界时，审批插件暂停执行并等待授权；操作失败后，团队可以沿 Session Log 复原当时的上下文和工具结果，修改装配逻辑或执行规则，再用已保留的轨迹复现问题。

在这条路径里，Coding Agent 负责开发，DSH 负责运行，领域团队持续修改插件与工作流。会话、工具协议和执行循环已有共同结构，小团队可以把工程投入集中在行业规则与执行边界上。插件契约和运行时的成熟程度会决定这种领域 Agent 能走多远；**DSH 的设计目标已经超出一个 Coding Agent 产品，它希望把 Standard Mode 中成立的 Harness 能力带到代码之外。**

## AI Workflow Owner 怎样使用这套控制面

我们在前面的讨论里把一类角色称为 AI Workflow Owner。这个角色理解业务目标，也要负责 Agent 的运行边界。他要沿着工作流决定上下文怎样形成、行动在何处审批，最后明确失败后的接管人。模型能力越强，这些判断越需要写进系统，否则 Agent 只会在演示时显得聪明，进入长期运行后却很难治理。

DSH 为这类工作提供了更接近工程对象的表达方式。Workflow Owner 可以把领域规则装进 Profile 与插件，把运行历史留在 Session 中，再根据轨迹调整执行策略。规则发生变化时，修改范围有机会留在对应能力内部。业务判断仍由人负责，但这些判断可以进入系统，接受检查并持续修改。

这些工程对象需要呈现在可见的控制面上，DeepSeek Harness如果想要承接这种诉求，体验上的”高门槛“几乎无法避免。未来更成熟的做法，很可能是用稳定 Profile 和领域发行版把复杂度下沉，最终用户看到简洁的应用。在这种情况下复杂性被AI Workflow Owner通过DeepSeek Harness来封装，但DeepSeek Harness本身仍然很复杂。

## DeepSeek Harness的成也萧何

我喜欢 DeepSeek Harness 现在的调性，因为它没有把 Agent 的运行过程处理成一个只能接受的黑盒。Everything is a Plugin 允许系统改变结构，它更接近用于建设和运行不同 Agent 的公共框架。

以后某个版本把默认界面做得更简单，并不会推翻今天的判断。只要简洁来自更成熟的 Profile、Bundle 与默认插件，它反而说明复杂性被封装到了合适的位置。DSH 若收缩成难以替换的固定 Coding Agent，或者这套生命周期无法在生产项目中维持稳定，我们才需要重新评估今天的推断。

更适合 DeepSeek Harness 的评价标准，是一个领域团队能否借助它，把自己的流程与判断做成可以持续运行和检查的 Agent，并且比从零搭建更快。Coding Agent 是它眼下最重要的应用，也是开发这些新 Agent 的有力工具。DeepSeek Harness 的架构继续向前一步，开始处理这些 Agent 此后怎样组织，怎样长期运行，以及怎样在变化中保持可控。