AIAgent 产品观察
架构事实与产品推断

DeepSeek Harness 调研

Everything is a Plugin

DSH 想把 Agent 从一个固定产品，变成一套可以重新组合的运行状态。

本文只回答两个问题。第一，DSH 的 “Everything is a Plugin” 到底意味着什么？第二，从已经出现的用法里，能对下一阶段 Agent 产品形态做出什么推断？全文区分官方事实与作者推断。
I

Everything is a Plugin 到底意味着什么？

重点不是插件数量。Agent 的核心运行结构，也进入了可组合范围。

Plugin 和 MCP / Skill 有什么不同？

MCP 和 Skill 更多是在扩展 Agent 的能力。DSH Plugin 会进一步参与定义 Agent 本身。

传统 Agent 产品通常可以抽象成：先有一个相对固定的 Agent Core，再通过 MCP、Skill、Tool 扩展外围能力。这个 Core 决定 Context 怎么组织、Agent Loop 怎么运行、Memory 怎么管理、Tool 怎么调用、Session 怎么维护、UI 怎么呈现。

Agent 并不是先存在，再往上安装 Plugin。Agent 本身就是一组 Plugin 在 Runtime 中组合之后形成的运行状态。

MCP 解决的是 Agent 如何连接外部 Tool 和 Resource。Skill 更接近可复用的任务知识、操作流程或脚本。它们主要回答：这个 Agent 还能做什么。通常不会重新定义：这个 Agent 本身是什么。

最典型的例子是 Agent Loop

在大多数 Agent 产品里，下面这条循环属于最核心的运行逻辑：

但在 DSH 中，Loop 本身也是一个 Plugin。因此理论上可以替换 Agent 的控制逻辑，而不需要颠覆整个 Harness。

传统 Plugin 在扩展一个已经存在的 Agent。DSH Plugin 则在参与组成和定义这个 Agent。

架构事实

DSH 官方架构文档明确写道：模型适配器、工具注册表、会话日志和 Agent Loop 都是插件，并可以从配置中替换。这里的 Plugin 指 Runtime 组成单元，不只是第三方功能包。

特殊之处不只是「Plugin 更多」

插件架构本身并不新。VS Code、Chrome、Obsidian 都有成熟的 Plugin 生态。如果 DSH 只是做到各种模块都可以安装、卸载，并不足以构成真正的架构差异。Cordis 更值得看的，是它试图解决动态组合里的两个基础工程问题。

Temporal Composability：组件离开之后，影响能不能一起撤销？

一个 Plugin 运行时，可能会注册 Tool、注入 Prompt、监听 Event、提供 Service、改变 Context 或挂载 UI。删除 Plugin 本身，并不等于系统已经回到安装前。

Cordis 把这些变化设计成 revertible effects。Runtime 不只记录发生了什么，还记录如何把这次变化撤销。于是「安装 → 修改系统 → 卸载 → 恢复」成为 Runtime 需要保证的性质，而不只是依赖 Plugin 作者手动清理。

Spatial Composability：组件之间如何动态建立关系？

一个 Memory Plugin 可能依赖 Session、Storage 和 Embedding Model。传统实现里，这些依赖通常被写进初始化代码：Memory 启动时主动找到具体模块。

模块关系被写死之后，替换 Storage 往往不只是替换 Storage；Embedding 暂时不可用时，Memory 也不一定能安全失活；删掉一个模块，其他地方可能还留着引用。模块越多，初始化和依赖关系越难维护。

Cordis 的思路是：组件不直接寻找某一个具体模块，而是声明自己需要什么能力。依赖满足则激活，依赖消失则可以失活，新的 Storage 出现时，Runtime 可以重新组织关系。模块关系从「A 在代码里绑定 B」，变成「A 声明自己需要一种 B 能力，具体由 Runtime 完成匹配」。

论文中的定义

Temporal composability 指组件被移除时可以完整撤销副作用；Spatial composability 指组件能够声明并响应式管理相互依赖。Cordis 把这两个维度实现为运行时机制。

所以它特殊在哪里

不是「插件很多」，而是两个条件同时成立。

核心结构进入 Plugin Tree

不只是 Tool 和 Skill。Model、Session、Storage、Sandbox、Loop、Scheduling、UI 也进入组合系统。Agent 的核心运行方式本身可以被组装。

加入和离开由 Runtime 管理

Runtime 需要处理 dependency、activation、deactivation、reversible effect、replacement 和 re-composition。组件可以进来，也可以被安全撤回。

核心变化不是 Agent 有了更强的插件系统，而是 Agent 本身开始从一个固定程序，变成一个可以动态组合的 Runtime State。

为什么它和 Self-evolving Agent 有关系？

传统 Agent 如果是「固定 Core + MCP / Skill / Tool」，即使模型 coding 很强，通常也只能改外围：新增 Skill、添加 Tool、修改 Prompt、调整 Memory。它很难安全地说：当前 Agent Loop 不适合这个任务，我换一个 Loop。更难的是：替换 → 测试 → 效果不好 → 自动恢复。

这说明 Self-evolution 不只是模型能力问题。Runtime 至少还要可观察、可组合、可替换、可撤销、可评测。

如果 Loop、Memory、Context、Tool、UI 与 Policy 都能独立操作，那么「修改 Agent 自身」就不再必然等于 fork 框架、重新启动和人工发布。Everything is a Plugin 提供的是这条闭环需要的可变形结构。Agent 有没有能力自动发现问题、设计修改方案、执行评测，是另一层。

DSH 今天已经走到哪一步？

官方预览页

Creator Mode 可以 inspect 当前 Runtime、在内存中试验 Cordis Plugin，并把它们组合成新的 Mode。这证明 Agent Runtime 已经具备被观察和被重新组合的基础。

事实边界

发现问题 → 修改自身 → 自动评测 → 保留 / 回滚，还不能说已经被完整证明。更准确的判断是：DSH 不是 Self-evolving Agent，但它正在把这条路所需的 Runtime 基础设施显式化。

II

从已经出现的用法，推断 Agent 产品会怎么变

如果只是漂亮的工程架构，还不足以说明产品一定会变。真正值得看的，是开发者开始拿它做什么。

Oh Story：不是给 Agent 加「写小说能力」，而是直接变成小说软件

社区项目 Oh Story DSH 做的是一个小说 + 短剧创作工作台。DSH 继续负责底层能力；Oh Story Plugin 则把 Skills、Roles、生产流程、项目协议和三栏工作台一起带进来。

Oh Story DSH 三栏工作台演示：左侧作品结构，中间正文编辑，右侧 Agent

左侧是作品结构，中间是正文编辑，右侧才是 Agent。用户操作的核心对象从 Conversation 变成 Novel Project。

DSH 原有的 Agent、权限、Chat、Trajectory 与工具执行仍然保留。改变的是用户面前的任务对象和交互结构。最终用户看到的产品已经不太像「一个 Chatbot 学会了写小说」，而更像「一个原生为了写小说而存在的软件」。

它和「给 Codex 加一个小说 Skill」有什么区别？

给通用 Agent 增加小说 Skill，改变的是它会不会写小说。把 UI、Workflow、Role、Skill 与数据结构一起重组，改变的是它作为一个产品如何承载写小说这件事。前者的核心对象仍是 Chat，后者的核心对象变成 Novel Project。

产品中心可能从 Agent，转向用户正在做的事

同一套 Harness，可以长成不同的任务界面

写小说→作品结构 + 正文编辑 + 创作 Agent
Coding→代码树 + 编辑器 + Diff + 终端
做研究→论文 + 引用 + 证据关系 + 知识图谱
做旅行→地图 + 行程 + 订单 + 实时状态
智能家居→家庭状态 + 设备控制 + 自动化规则

如果 Loop、Memory、Context Strategy、Tool、Workflow、UI 都可以换，Agent 产品就不一定一直沿着「一个超级入口 + 无限增加能力」走。另一种模式会越来越可行：保留通用 Harness，围绕不同任务动态组装不同的软件形态。Chat 只成为其中一个辅助入口。

Harness 是底座。用户当前正在完成的任务，决定产品应该长什么样。

最终判断

Everything is a Plugin 不是「DSH 拥有一个更开放的插件系统」，而是 Agent 开始从固定程序，变成可组合的 Runtime。工程上，这为 Self-evolving Agent 提供了必要但不充分的基础。产品上，Agent 不一定永远以 Chatbot 或超级 Agent 的形态存在；当 UI、Workflow、Role、Tool、Context 都能一起组合时，它更可能围绕当前任务重新长成一个具体软件。目前这还不是 DSH 已经完成的事实。但 Cordis 的设计、Creator Mode，以及 Oh Story 这样的案例，已经把这件事推进到可以具体讨论工程实现和产品形态的阶段。

参考资料与发布提醒

  1. DeepSeek Harness 官方仓库：项目定位、Developer Preview 状态与 Everything is a Plugin。
  2. DeepSeek Harness 预览页：Plugin 覆盖范围，以及 Creator Mode 可 inspect Runtime、在内存中试验 Plugin 并组合成新 Mode。
  3. DSH Architecture：Cordis、Profiles、Bundles、Patch 叠加顺序与核心插件。
  4. A Programming Paradigm for Spatiotemporal Composability：时空组合、可撤销 effect 与响应式依赖。论文仍是持续修订中的预印本。
  5. Oh Story DSH：小说与短剧工作台、13 个小说 Skills、7 个专业 Roles 与三栏布局。
  6. Codex Configuration Reference、AGENTS.md、Skills 与 Plugins：用于文中的人工映射与对比。
↑