DSH一切皆是插件的理念的启示

DeepSeek Harness（DSH），我觉得最值得关注的并不是它又做了一个 Coding Agent，而是背后的架构思想：

Everything is a Plugin——一切皆插件。

很多 Agent 平台也讲插件化，但通常只是把 MCP、Skill、Tool 做成插件，真正的 Agent Engine 还是固定的。

DSH 更激进。

它把模型、工具、Skill、MCP、Session、Sandbox，甚至 Agent Loop 本身都做成可以替换、组合的能力。

这件事对我们做企业 AI 应用基座很有参考价值。

一、DSH 真正的核心不是 Agent，而是 Runtime

传统 Agent 平台一般长这样：

Agent Engine

├── Model

├── MCP

├── Skill

└── Tool

Agent Engine 是“大脑”，外围能力只是往里面挂。

DSH 的思路更像：

Runtime Context

├── LLM Plugin

├── Agent Loop Plugin

├── Tool Plugin

├── Skill Plugin

├── MCP Plugin

├── Session Plugin

└── Sandbox Plugin

也就是说，Agent 本身都只是 Runtime 里面的一种能力。

真正稳定的不是某一个 Agent，而是：

接口、事件、生命周期和插件组合机制。

这点非常重要。

因为现在 Agent 技术变化太快。

今天是 ReAct，明天可能是 Planner + Executor，后面还有 Multi-Agent、Verifier、长任务 Agent。

如果我们把某一种 Agent Loop 写死在 AI 基座里面，两年以后大概率又要推翻重做。

所以更合理的方式是：

Agent Runtime 本身也应该可以替换。

---

二、“一切皆插件”真正解决的是系统扩展问题

企业 AI 平台最麻烦的地方，往往不是调用模型，而是环境越来越复杂：

不同模型、不同客户、不同权限、不同知识库、不同沙箱、不同部署环境。

如果平台不断这样写：

if 客户A

if 客户B

if DeepSeek

if GPT

if 私有化环境

if 信创环境

最后一定会变成一个巨大的条件判断工程。

DSH 的思路其实很简单：

不要判断，做组合。

比如文件系统只定义统一接口：

FileSystem

├── Local Provider

├── Sandbox Provider

└── Remote Provider

上层 Agent 不需要知道文件到底在本机、容器还是远程环境。

模型也是一样：

LLM Provider

├── DeepSeek

├── OpenAI

├── Qwen

└── Local Model

这样换底层实现，不需要改上层 Agent。

这个思想特别适合企业 AI 基座。

---

三、另一个值得抄的是 Event Log

DSH 还有一个设计我觉得非常实用：Agent 的执行过程事件化。

例如一次 Agent 任务，可以被记录成：

user/message

agent/request

llm/stream

tool/call

tool/result

assistant/message

这样做的意义不是为了“多记日志”，而是为了以后能够：

Replay、Resume、Fork、Audit。

传统系统出了问题，日志可能只有：

«API 调用成功，耗时 2.3 秒。»

但 Agent 出问题，我们真正想知道的是：

模型当时看到了什么？

调用了什么 Tool？

Tool 参数是什么？

返回了什么数据？

为什么下一步做出了这个决策？

所以未来企业 Agent 的可观测体系，不能只做传统日志。

应该逐步变成：

Event Log + Trace + Replay。

这对问题复现、审计、安全都很重要。

---

四、对我们 AI 应用基座的几个直接启示

我觉得 DSH 不需要照搬，但有三个东西值得吸收。

第一，基座核心尽量做薄。

不要把 RAG、Agent、Workflow、OCR、Search 全部塞进一个巨大 AIService。

核心只负责：

Context

Interface

Event

Lifecycle

Policy

具体能力全部通过 Provider 或 Plugin 接入。

第二，行业能力做成 Bundle。

比如：

政务 Bundle

= 政务知识库

+ 公文 Skill

+ 政策检索

+ 审计策略

医疗 Bundle

= 医学模型

+ 医疗知识库

+ HIS Connector

+ 脱敏策略

底层 Runtime 不变，不同客户只是不同插件组合。

第三，安全治理也要进入统一调用链。

未来 Tool 调用最好不是：

Agent → Tool

而是：

Agent

→ Permission

→ Policy

→ Approval

→ Sandbox

→ Tool

→ Audit

这样权限、审计、脱敏、限流、成本控制都可以统一治理。

最后

DSH 给我的最大启发其实只有一句话：

AI 基座真正应该稳定的，不是某一种模型、Agent 或 Skill，而是“能力如何被组合”。

模型一定会换。

Agent 一定会换。

MCP、Skill、Harness 也会继续变化。

所以一个好的 AI 应用基座，不应该试图把所有能力都做进去。

更好的方向是：

把自己做成一个稳定的 Runtime，让所有能力都可以插拔、替换和组合。

这可能比再造一个“大而全的 AI 中台”更有价值。