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

DeepSeek Harness 最醒目的口号是 **Everything is a Plugin**。这里的 Harness 是模型之外负责让 Agent 持续完成任务的运行系统。模型生成下一步动作，Harness 组织上下文，执行工具调用并保存任务状态。按照官方文档，DeepSeek Harness 连模型接入、工具执行、会话记录和任务循环都交给插件机制管理。

但对目前最典型的两类 Agent 用户来说，程序员已经习惯了功能强大却越来越相似的 Coding Agent，更多非程序员接触到的 AI 产品则通常把 Harness 封装在内部，只向用户承诺越来越好用。DeepSeek Harness 直接把许多选择放在公开的控制面上，第一次接触它很容易感到概念爆炸。我在 X 上看到的一类批评，大致可以概括为“程序员自嗨”。OpenClaw 及其变体今年走红，进一步强化了大众对 AI“越来越好用”的期待，DeepSeek Harness 看起来反而比 Claude Code 和 Codex 更复杂。后两者已经把大部分选择收进一套经过打磨的默认体验，DeepSeek Harness 却主动让用户看到这些选择。

这也是我理解它高门槛的起点。DeepSeek Harness 可以作为 Coding Agent 使用，但它为自己划定的范围并不限于代码工作。本文把围绕某类专业工作流程设计的 Agent 称为领域 Agent。Coding Agent 本身就是其中一种，只是软件开发的工具、反馈与协作方式已经高度标准化；所谓领域团队，是熟悉另一类专业流程并负责把它做成 Agent 的团队。未来的 Agent 还会进入更多专业工作流程，一旦离开代码仓库，上下文、执行方式和失败恢复都很难长期沿用 Coding Agent 的固定框架。从我的视角来看，DeepSeek Harness 的设计准则与我强调的“工程化”几乎完全相同。无论是 Coding Agent，还是未来其他成熟的 Agent 场景，AI 都要在一整套工程体系中运行。DeepSeek Harness 想建立的就是这样的运行框架，通过较高的初始复杂度换取内部能力可以替换和重新组合的空间。

当然，以我的工作经验来看，因为理念崇高、梦想高远而不断创造概念和层次的项目也不少，而且很难在早期证明问题究竟在哪里。这类风险往往要到实践中才会暴露：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 针对的是运行系统本身。插件在这里并不只是给模型增加一个工具，模型接入、工具执行、会话保存和任务循环都可以替换。接口开放到这个程度以后，使用者获得了更大的控制权，也接过了一部分产品设计责任。Claude Code 和 Codex 把许多具体决策固定在产品默认值里。DeepSeek Harness 的使用者会看到更多选择，也要为这些选择负责。

DeepSeek Harness 的复杂直接来自它的主动选择：它在以自己的方式尝试回答“Harness 的本质是什么”和“最好的 Harness 应该长成什么样”。它既要求内部能力能够组合和替换，又要求替换以后保持一致的运行规则，这些架构成本最终会进入界面和配置。目前发布的版本仍处于 Developer Preview，界面、配置和兼容性上的粗糙会让高门槛更加显眼，但这无法解释全部复杂性。只要 DeepSeek Harness 继续保留可替换的运行结构，后续版本可以把复杂性封装得更好，却很难让它完全消失。

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

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

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

这正是 DeepSeek Harness 的可替换性发挥作用的地方。不同领域可以保留同一套 Harness 的基本运行规则，再接入自己的数据、权限和执行工具。Standard Mode 是面向代码工作的默认组合，其他领域也可以形成自己的版本。它们未必共享界面，却可以共享底层的插件与运行机制。

## Standard Mode 是 DeepSeek Harness 装配出来的 Coding Agent

Standard Mode 本身就是一个 Coding Agent，这也是大多数人第一次接触 DeepSeek Harness 时最容易形成的印象。它能在代码仓库中调用工具完成任务，直接使用时与 Claude Code、Codex 处在同一个产品层。这个入口容易遮住 DeepSeek Harness 的另一层设计：Coding Agent 描述的是 Agent 处理哪类工作，DeepSeek Harness 处理的是 Agent 由哪些能力组成，又怎样持续运行。Standard Mode 选择了面向代码工作的能力组合，所以它呈现为 Coding Agent；同一套 Harness 接入其他专业流程需要的数据和工具以后，也可以承载另一类 Agent。**Coding 是 DeepSeek Harness 已经装配好的一种用途，Harness 才是它希望复用到其他专业流程的运行结构。**

领域团队可以用 Coding Agent 开发所需的插件和规则，完成后交给 DeepSeek Harness 运行。Claude Code、Codex 或 DeepSeek Harness(Standard Mode) 都能承担开发工具的角色，DeepSeek Harness 则负责承载完成后的 Agent。事实上一直都有人用 Claude Code 开发依附于 Claude Code 运行的工作流，代码开发很顺手，交付给专业用户以后却要迁就一个围绕代码任务设计的宿主，所以目前只有在“程序员为程序员开发Agent”时这种模式是比较好的。OpenClaw先提出了一种方案：也许我只需要把它隐藏在用户感到亲切的聊天工具之后，就能宣称解决了维护和使用工作流的复杂性。DeepSeek Harness 则提供了另一种可能：继续使用成熟的 Coding Agent 开发，同时让完成后的 Agent 运行在一套可以按专业流程重新组合的 Harness 上。

沿着这套结构，可以推演一个云服务故障处理 Agent。团队先用Coding Agent 编写监控查询、变更审批和故障判断规则，再把完成后的 Agent 交给 DeepSeek Harness 运行。它接收告警，取得服务拓扑与近期变更，由模型提出诊断步骤；一旦涉及生产操作，流程便停下来等待授权。执行过程会被保留下来，团队可以在失败后检查当时的上下文与工具结果，并据此修改规则。这个例子已经足以说明它与 Coding Agent 的区别，具体的插件组合与运行机制将留到下一篇讨论。

在这条路径里，Coding Agent 负责开发，DeepSeek Harness 负责运行，领域团队持续修改工作流。小团队不必从头搭建 Agent 的运行系统，可以把工程投入集中在行业规则与执行边界上。这条路径能走多远，取决于 DeepSeek Harness 能否让这些组合容易开发、稳定运行并长期维护；**DeepSeek Harness 的设计目标已经超出一个 Coding Agent 产品，它希望把 Standard Mode 中成立的 Harness 能力带到代码之外。**

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

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

DeepSeek Harness 为这类工作提供了更接近工程对象的表达方式。AI Workflow Owner 可以把专业规则、权限边界和异常处理方式写进 Agent，并根据运行记录修改工作流。业务判断仍由人负责，但这些判断可以进入系统，接受检查并持续修改。

这些工程对象需要留在可见的控制面上，因此 DeepSeek Harness 面向构建者时，高门槛几乎无法避免。未来更成熟的产品可以提供稳定的默认组合和面向特定专业流程的发行版，让最终用户只接触简洁的应用。AI Workflow Owner 通过 DeepSeek Harness 管理这些选择，所以他们交付的 Agent 可以简单，DeepSeek Harness 本身仍然会很复杂。

## DeepSeek Harness 的成败都取决于这套复杂性

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

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

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