模型只是 CPU，插件运行时才是 Agent 的操作系统：从 DeepSeek Harness 到 Zongsoft

导读：DeepSeek Harness（DSH）开源后，“一切皆插件”成了 AI Agent 圈最热的口号。但口号人人会说，机制决定生死。本文不写“DSH 很厉害”的观后感，而是翻开它的真实组合清单与源码，把“一切皆插件”拆成插件运行时必须回答的五个底层问题——能力坐标、依赖激活、效果撤回、组合形态、自省演化。

有意思的是：这五个问题，Zongsoft.Plugins 从 2010 年 4 月创立那天起，就在用另一套机制回答。十六年后，两条独立演化的技术路线在 Agent 时代会合。它们给出的答案不同，但问的是同一个问题。本文要论证的，正是标题里的那句判断：模型只是 CPU，插件运行时才是 Agent 的操作系统。

引言：模型只是 CPU，插件运行时才是 Agent 的操作系统

当所有人都在追逐更大的模型时，DeepSeek 却把一个看起来不那么性感的东西推到了聚光灯下：Harness（驾驭框架）。如果借用计算机体系结构的比喻，模型更像 CPU——它决定推理能力的上限，却不会自动长出文件系统、工具、权限、会话、持久化、沙箱、界面和协作协议。真正把这些能力组织成产品的，是模型外面的 Harness。Claude Code 与 ChatGPT(Codex) CLI 的走红，不单单是模型之胜，与之配套的 Harness 才是帮助它们走向决战之巅的战车：模型之外的那一层，正在成为产品差异的主战场。

当然，“操作系统”不是给插件框架换一个时髦名字。它提出的是一条更严格的判断标准：

当一个运行时可以安装、组合、替换、撤销和治理 Agent 的各种能力时，它才开始具备 Agent OS 的形状。

2026 年 8 月，DeepSeek 开源了 DeepSeek Harness（DSH）开发者预览版，底层以 vendor 方式引入 Cordis 插件框架，并配套了论文 A Programming Paradigm for Spatiotemporal Composability。它最显眼的宣言只有一句话：

Everything is a Plugin —— 模型适配器、工具、会话、沙箱、存储、Agent 循环、乃至整个 Web 界面，都是插件。

这句话很有流量，但也容易产生误导。很多人把“插件化”理解成“把功能拆成很多 npm 包”——这只是物理拆分，还没有解决组合问题。真正的插件化，必须回答一组更底层的问题：

• 插件把能力放在哪里，别人怎么找到它？
• 插件什么时候可以开始工作，依赖没了怎么办？
• 插件改变了世界，卸载时怎么把世界还回去？
• “产品是什么”由谁决定，能不能晚于编译再决定？
• 运行中的系统能被观察、被修改吗，谁有资格改？

这五个问题，我称之为插件运行时的五项机制。DSH 用 Cordis 的“上下文 + 效果 + 反应式依赖”回答它们；而 Zongsoft.Plugins 从 2010 年 4 月创立那天起，就用“插件树 + 清单 + 构建器/解析器”回答它们。十六年后，两条独立演化的路线在 Agent 时代会合，并且抵达了同一个结论：

插件不是“给完成的应用加功能”的扩展点，而是“组成这个应用本身”的组织单位。

一、先看 DSH：一行一个插件

要理解 DSH，最好的入口不是架构图，而是它的组合清单。DSH 把每个 profile（产品形态）定义为一棵从“空根”上长出来的插件树，每个插件在 cordis.patch.yml 里占一行。下面是从 dsh-base 组合包的真实 cordis.patch.yml 中节选的片段（该包是每个 profile 的第一层）：

# dsh-base/cordis.patch.yml（节选）
- insert:
    - id: timer
      name: '@deepseek-ai/cordis-plugin-timer'
    - id: llm
      name: '@deepseek-ai/dsh-llm'
    - id: session
      name: '@deepseek-ai/dsh-session'
    - id: agent
      name: '@deepseek-ai/dsh-agent'
    - id: agent-default-model
      name: '@deepseek-ai/dsh-agent-default-model'
      config:
        provider: deepseek-official
        model: deepseek-v4-flash
    - id: tools
      name: '@deepseek-ai/dsh-tools'
    - id: agent-loop
      name: '@deepseek-ai/dsh-agent-loop'
      config:
        agents: []
    - id: sandbox
      name: '@deepseek-ai/dsh-sandbox-local'
    - id: approval
      name: '@deepseek-ai/dsh-user-approval'
    - id: session-persistence-jsonl
      name: '@deepseek-ai/dsh-session-persistence-jsonl'
    - id: web
      name: '@deepseek-ai/dsh-web'
      config:
        searchProvider: deepseek-official

每一行的语义是：“把名为 X 的插件，以这份 config 挂进运行时”。行与行之间没有加载顺序的含义——清单里的注释写得很直白：“Row order carries no load semantics (activation is service-availability driven)”，即激活由服务可用性驱动，而不是行序。一个插件声明自己依赖哪些服务（inject），依赖齐了它才启动；依赖消失，它先失活，等依赖回来再重新激活。这是“插件”与“一堆 import”最本质的区别。

连“内核”都是插件

DSH 最激进的地方在于：它没有一个需要被“扩展”的特权内核。我们通常认为的 Agent 内核——循环、会话、工具系统——在 DSH 里全部是插件行。看 dsh-agent-loop 包的 README，这句话值得反复读：

“这是 harness 中唯一包含具体循环逻辑的包。其他所有内容要么是抽象服务，要么是针对扩展点的插件：新行为应放入插件，而不是这里。”

也就是说，整个 DSH 只有一个“具体实现”：那个调用模型、运行工具、然后重复的 React Loop。其余一切——压缩、持久化、遥测、审批、沙箱、UI——都是监听事件分类体系（agent/*、tools/*、session/event）的插件。工具执行也不是硬编码的“调一下函数”，而是一条可以被任何插件拦截的流水线：

tools/pre-execute（允许/拒绝/询问）
  → guard（单调策略）
    → tools/execute（超时/重试包装）
      → tools/post-execute（检查/替换结果、附加上下文）
        → finalizeContent（最终内容）
          → tools/result（只读观测）

权限沙箱挂在 pre-execute，计划模式挂在 pre-execute + 提示词，上下文压缩监听 agent/pre-step 与 agent/request-error，崩溃恢复监听 agent/request-error 做退避重试……每个“能力”都是事件流上的一个听众，而不是循环里的一个 if 分支。

不过要划清一条边界：“没有特权产品内核”不等于“没有运行时基座”。DSH 仍然依赖 Cordis 提供上下文、依赖解析、事件与生命周期语义。准确的说法是：Cordis 是组合规则，DSH 是由这些规则组装出来的产品。

连 UI 都是插件

再往外一层：DSH 的 Web 界面也不是“给 Agent 写的一个前端”，而是一批 dsh.client 插件行。dsh-web-app/cordis.patch.yml 的真实内容里，浏览器里每一个可见的部件都有对应的一行：

# dsh-web-app/cordis.patch.yml（节选）
- insert:
    - id: connection
      name: '@deepseek-ai/dsh-client-connection'
    - id: ui-conversation
      name: '@deepseek-ai/dsh-client-ui-conversation'
    - id: ui-tool
      name: '@deepseek-ai/dsh-client-ui-tool'
    - id: ui-settings
      name: '@deepseek-ai/dsh-client-ui-settings'
    - id: ui-cordis
      name: '@deepseek-ai/dsh-client-ui-cordis'
    - id: ui-plan
      name: '@deepseek-ai/dsh-client-ui-plan'
    - id: ui-goal
      name: '@deepseek-ai/dsh-client-ui-goal'

“模块节点把这张插件名录扫描进 window.__DSH_BOOT__”——浏览器插件在 Cordis 存在之前就被引导，然后作为插件条目被运行时收养。删除一行，某个 UI 部件就从界面上消失；加上一行，新部件就长出来。界面是组合结果，不是仓库里的一个目录。

会话是事实流，不是聊天数组

DSH 的会话子系统把交互历史做成仅追加的事件日志（SessionEvent）：user/message、assistant/chunk、assistant/message、tool/call、tool/result、turn/start、turn/end……模型看到的消息，由这条日志投影出来；原始流式分片被保留，供 UI 还原；恢复、分叉、转录、遥测、持久化都从同一事件流派生。压缩不是“删掉旧对话”，而是追加一条 replace 语义的摘要事件，把被遮蔽的旧条目从未来的模型输入中移除——日志本身永远只增不改。

这让系统获得了很强的可观察性：一次 Turn 可以包含零个或多个 Step，一个 Step 就是一次模型请求及其工具调用；即使输入被拒绝、首步为空或请求失败，运行轨迹仍可以有明确的开始与结束。

会话事件可回放，回答的是“发生过什么”；插件效果可撤销，回答的是“卸载后留下什么”。二者互相配合，但不是一回事。

Agent 能修改运行时自己

DSH 还内置了一套自引用工具：cordis_inspect（查看当前进程的插件、服务、事件）、cordis_define / cordis_run / cordis_stop / cordis_undefine（定义、运行、停止、撤回一个动态包）。这意味着 Agent 不仅能调用工具，还能检查运行时结构、组装新能力、再把实验撤掉。

官方文档对此有非常清醒的边界声明：动态包只存在于进程内存，不会写入配置、不会跨重启存续、也不会自动晋升为正式插件；其 node:vm 隔离 globals，但不是安全边界，应当像授予 bash 权限一样谨慎。一个能修改自身的 Agent，如果没有权限、审计、作用域与进程级沙箱，得到的不是进化能力，而是更大的爆炸半径。

二、插件运行时的五项机制

看完了 DSH 的“表象”，现在把镜头拉远。无论是 DSH/Cordis 的高动态运行时，还是 Zongsoft 的企业级插件框架，要兑现“一切皆插件”，都必须回答下面五个问题。这不是我的发明——是两套代码各自独立长出来的共同结构。

机制一：能力坐标 —— 插件把能力放在哪里？

没有坐标的插件化，等于换了一种目录结构的耦合。

• DSH / Cordis：能力放在 ctx.。每个服务占据一个稳定的上下文键（ctx.llm、ctx.tools、ctx.sessions），其他插件通过键查找能力，而不是 import 具体实现。事件则通过 TypeScript 声明合并注册名字，再以 emit / waterfall / parallel / serial 四种模式分发。插件条目本身也有稳定 id（llm、session、agent-loop），patch 按 id 定位——id 就是坐标。
• Zongsoft：能力放在插件树路径上。对象、服务、模块、事件处理器、命令、启动项被挂载到稳定路径，例如 /Workbench/Modules、/Workspace/Environment/Services、/Workbench/Events。路径既是位置，也是契约：提供者把能力放到约定节点，消费者通过路径或 expose 关系取得它。