# Everything is a Plugin，DeepSeek Harness 为什么把自己设计得这么复杂

DeepSeek Harness 最醒目的口号是 **Everything is a Plugin**。按照官方架构，模型适配与工具注册由插件提供，Session Log 和 Agent Loop 也可以通过配置替换。[1] 对一个只想让 AI 改代码或做一份 PPT 的用户，这套设计首先带来的是额外概念。Profile 决定加载哪套组合，Bundle 负责分发配置与代码，Cordis 管理插件的依赖和生命周期。Claude Code 和 Codex 已经把大部分选择收进一套经过打磨的默认体验里，DeepSeek Harness 却主动把它们放到了公开的控制面上。

这也是我理解它高门槛的起点。DeepSeek Harness 可以作为 Coding Agent 使用，但它给自己的设计边界留得更宽。Coding Agent 是今天最成熟、也最重要的一类 Agent，未来的 Agent 还会进入更多业务现场。一旦运行对象离开代码仓库，上下文、执行方式和失败恢复都很难长期沿用 Coding Agent 的固定答案。DeepSeek Harness 因此先建设一套可以重组的 Agent Runtime，并为后续的领域封装保留接口。它接受了较高的初始复杂度，以此换取替换内部部件的空间。官方文档给出了架构事实，本文再据此推断它可能覆盖的范围。

## 高门槛来自公开的选择

把 DeepSeek Harness 和 Claude Code、Codex 放在一起比较，很容易把问题理解成谁的插件更多。这个角度会漏掉关键差异。Claude Code 已经形成完整的插件机制，Codex 也支持 Skills 与 MCP；两者都公开了会话事件和审批能力。[6][7] 它们的产品中心十分明确：用户进入一套成熟的 Coding Agent，由产品给出上下文组织、工具循环与交互方式，用户再从外围增加能力。

Everything is a Plugin 走得更深。模型与工具系统来自插件，持久化和 Agent Loop 也遵循同一规则。官方目录又把执行环境、凭据、沙箱与工作流抽象成接口。[3] 接口开放以后，使用者获得了更大的控制权，也接过了一部分产品设计责任。原来由产品团队替用户决定的事情，现在需要 Profile、Bundle 和插件依赖共同回答。

DeepSeek Harness 的复杂直接来自这些公开选择。它还要求选择能够组合和替换，并在替换以后维持一致的运行语义。用户看到的 Profile、Capability 和 Session Event，是这笔架构成本在界面与配置层的投影。Developer Preview 又让成本更加显眼：默认组合还在快速变化，兼容性也没有稳定下来。[5]

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

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

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

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

## 用 Coding Agent 开发一个运行在 DSH 上的领域 Agent

可以设想一个面向云服务故障处理的 Agent。开发团队先借助任意成熟的 Coding Agent 编写领域插件，把监控查询和变更审批接入系统，再将这些能力组合成一个 Profile。Coding Agent 承担开发工具的角色，DeepSeek Harness 承载新 Agent 的运行。会话、工具协议和插件生命周期已有共同起点，团队可以把主要精力放到本领域的判断规则上。

一条告警进入后，运行时先把输入写入 Session。领域插件随后装配服务拓扑与近期变更，模型据此提出诊断调用。工具结果继续写回同一个 Session，下一次模型请求从事件流派生。模型准备触发生产变更时，权限插件可以把流程停在审批位置。操作失败以后，团队沿着 Session Log 还原模型当时获得的上下文，并继续查看工具调用及其结果，随后修改装配逻辑或执行策略，再用留下来的轨迹复现问题。

上面是一条架构推演，DeepSeek Harness 目前并未交付这样的运维产品。Coding Agent 写出插件和配置，DSH 承载运行，领域团队持续维护工作流。若这条路径能够成立，一个掌握行业流程的小团队便有机会做出自己的“领域版 Claude Code”，省去从头搭建零散 Agent 基础设施的工作。

## Session Log 让运行过程成为可检查的事实

官方把 append-only Session 定义为事实来源，模型历史以及后续的恢复和持久化都从事件流派生。[2] 这项设计会增加事件模型与存储负担，却回答了 Agent 工程里的一个长期问题：界面上看到的是结果，工程团队还需要知道结果经过了哪条路径。

这里也要区分 Session Log 与 Trajectory。Session Log 保存运行事实，并为恢复与上下文派生提供依据；Trajectory 是面向人的观察视图，帮助开发者理解任务为何走到当前结果。它们放在一起以后，Agent 的失败便不再只是一段“模型表现不好”的印象，而能落到某次上下文装配或工具执行上。

可观察性与可替换性在此接上了。Trajectory 可以帮助诊断，却需要稳定的修改接口把判断变成改动；插件提供了这个接口，也需要完整事件记录来减少猜测。DeepSeek Harness 将二者放进同一套架构，给领域 Agent 的长期演进补上了反馈回路。

## Spatiotemporal Composability 为什么会继续增加复杂度

Everything is a Plugin 还会引出另一个问题：插件可以随时加入和移除，系统怎样避免留下失效资源？Cordis 用 Spatiotemporal Composability 回答这件事。空间组合依靠显式依赖，插件在条件满足时激活，依赖消失时退出。时间组合要求运行时记录自己管理的副作用，并在插件撤销时调用清理逻辑。[4]

Reversible Effects 指向插件生命周期内的工程可逆性。工具注册可以注销，监听器也能在插件退出时解除。它无法撤回已经发送的邮件，也无法自动取消外部系统里已经生效的生产变更；外部行动仍需自行设计事务或补偿流程。它的作用在系统内部：重组能力时清理旧状态，降低热更新留下脏资源的概率。

代价同样明确。插件作者要提供正确的清理行为，依赖图必须避免循环，相关资源还要经过运行时管理。系统由此可以动态组合，也背上了一套需要长期维护的生命周期纪律。DeepSeek Harness 的复杂性有相当一部分来自这里，因为它处理的是能力进入和退出以后，整个环境能否继续工作。

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

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

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

这些工程对象需要留在可见的控制面上。普通用户希望尽量缩短路径，Agent 建设者却需要进入下面的结构。DeepSeek Harness 目前同时承接两种诉求，体验上的张力几乎无法避免。未来更成熟的做法，很可能是用稳定 Profile 和领域发行版把复杂度下沉。最终用户看到简洁的应用，Workflow Owner 与开发团队保留必要的控制权。

## 它覆盖的范围更宽，成败标准也更高

我喜欢 DeepSeek Harness 现在的调性，因为它没有把 Agent 的运行过程处理成一个只能接受的黑盒。Everything is a Plugin 允许系统改变结构，Session Log 与 Trajectory 留下理解运行过程的依据，Cordis 让这种改变服从可恢复的生命周期。三者连在一起以后，DeepSeek Harness 覆盖的设计范围已经超过一款默认体验出色的 Coding Agent，它更接近用于建设和运行不同 Agent 的公共框架。

覆盖范围扩大以后，工程检验也随之增加。插件接口与 Session 语义需要保持稳定，Profile 还要形成质量足够高的发行版，普通开发团队也要能遵守 Cordis 的组合纪律。这些条件决定了架构会带来生产力，还是只留下负担。当前的 Developer Preview 已经把方向写进代码和文档，生态能否沿着它成长仍要等待项目验证。

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

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

## 参考资料

[1] [DeepSeek Harness Architecture](https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/architecture.md)

[2] [DeepSeek Harness Session README](https://github.com/deepseek-ai/deepseek-harness/blob/master/packages/core/session/README.md)

[3] [DeepSeek Harness Config Catalog](https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/config-catalog.md)

[4] [Cordis: A Programming Paradigm for Spatiotemporal Composability](https://github.com/cordiverse/paper)；[Cordis Lifecycle and Effects Tutorial](https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/cordis-tutorial/02-lifecycle-and-effects.md)

[5] [DeepSeek Harness README](https://github.com/deepseek-ai/deepseek-harness)

[6] [Codex Skills](https://developers.openai.com/codex/build-skills)；[Codex App Server](https://developers.openai.com/codex/app-server)

[7] [Claude Code Settings](https://code.claude.com/docs/en/settings)；[Claude Code Headless Mode](https://code.claude.com/docs/en/headless)