# 

> 摘要：2026 年 8 月 13 日，DeepSeek 开源了它的第一款 Agent 产品 Harness v0.1（MIT 协议）。它不是又一个大模型，而是位于模型之上的"运行时层"。本文从架构设计原则出发，解析它最核心的主张——"一切皆插件（everything is a plugin）"，以及支撑这一主张的三块地基：可逆副作用、服务/事件协作、作用域与预设复用。文中所涉信息均基于公开资料，观点为个人技术分析，供交流参考。

## 一、定位：模型之上的"运行时层"

过去两年，行业对 Agent 的讨论大多集中在模型侧：更强的推理、更长的上下文、更好的工具调用。但一个容易被忽略的事实是，Agent 真正跑起来，需要的远不止"一个聪明的模型"，还有一整套支撑执行的工程设施——模型接入、工具调度、会话记录、沙盒隔离、持久化、循环控制，乃至界面。

DeepSeek 这次开源的 Harness，瞄准的正是这一层。官方用一句话概括了它的定位：

> **Model + Harness = Agent**

模型负责"思考"，Harness 负责"执行"。换句话说，DeepSeek 正试图把"模型之上的运行时基础设施"标准化、开源化——从"只提供大脑"，走向"同时开放手脚"。

## 二、架构底座：一个"只做三件事"的元框架

Harness 的架构底座是 **Cordis**，一个用 TypeScript 编写的元框架（Meta-Framework）。理解 Cordis 是理解 Harness 的关键，而理解它的关键是搞清楚它**不做什么**：

- 它不做 LLM 接入；
- 它不做 Agent 逻辑；
- 它甚至不关心"智能体"这个概念。

Cordis 只负责三件事：**插件的加载、卸载与依赖管理**。它是一个纯粹的"插件运行时内核"，所有与业务相关的能力（模型、工具、会话、沙盒、调度、UI）都作为插件挂在这个内核之上。

这个底座并非凭空而来。Cordis 来自开源聊天机器人框架 Koishi 的作者，在 Koishi 上已经历过跨平台、海量插件、热插拔场景的生产验证。DeepSeek 的做法是把 Cordis 整体纳入自己的仓库，并将自研的每一个业务包都声明为对它的依赖。这意味着 Harness 不是一个"用了一个第三方库"的项目，而是**整个产品都建立在插件内核之上**。

## 三、核心机制一：可逆副作用——让"卸载"成为一等公民

几乎所有 Agent 框架都宣称自己是"插件化"的，但 Harness 真正值得深挖的，是它如何解决一个被广泛忽视的问题：**插件卸载时，谁来清理它留下的副作用？**

传统 DI（依赖注入）容器能"绑定"服务，却很少负责"解绑"；插件注册了事件监听、定时器、数据库连接，卸载时这些残留要么靠开发者手动清理，要么直接泄漏。更麻烦的是，如果依赖的某个服务被热替换，下游组件能否自动重启，传统方案几乎无能为力。

Cordis 给出的答案是**可逆副作用（reversible effect）**。它确立了一条贯穿全局的纪律：

> 任何对运行时上下文产生修改的操作——注册事件、提供服务、挂载子插件、启动定时器、打开连接——都必须同时登记一个对应的"撤销动作"。

具体到代码形态，就是插件的注册逻辑返回一个"逆操作"：注册时立即执行副作用，返回的撤销函数被框架收纳；插件卸载时，框架按照**与注册相反的顺序（LIFO）**逐个执行这些撤销函数，把插件对共享环境的所有改动干净地"退回去"。

这条纪律带来几个直接收益：

1. **失败原子性**：插件初始化中途出错，已经生效的一半副作用会被逆序清理，不留半初始化状态。
2. **级联清理**：子插件本身也被视为父插件的一个"副作用"，卸载父插件会连带按栈序拆掉整棵子树，无需额外维护依赖清理表。
3. **运行时热插拔**：换掉某个服务的实现，在运行时层面就是一次"自动卸载再加载"，服务不中断，其他插件不受影响。

这套机制把"卸载"从每个开发者手写的善后代码，变成了**由框架结构性保证的操作**。这也是"一切皆插件、插件可热插拔"这句话能真正成立的前提。

对应地，每个插件实例在 Cordis 内部被抽象为一个**生命周期状态机（Fiber）**，覆盖从"等待依赖就绪"到"加载中""已激活""失败""卸载中""已销毁"的完整迁移。插件声明自己依赖哪些服务后，状态机会一直停留在"等待"态，直到依赖全部可用才执行插件代码进入激活态——这就是"空间可组合性"：**依赖出现则组件自动激活，依赖消失则自动停用**。

## 四、核心机制二：服务与事件的双通道协作

插件之间如何互相拿到对方的能力，是插件化架构的另一半。Cordis 提供了两条松耦合的通道：

- **服务（Service）**：用于"提供与消费能力"。服务是类型化、可作用域化、可注入的，并在插件卸载时自动解绑。
- **事件（Event）**：用于"广播与响应状态变化"。事件监听器同样被纳入生命周期管理，插件卸载时其注册的所有监听器随撤销链自动移除，避免幽灵回调。

一个值得注意的实现细节是**上下文的 Proxy 化**。当代码访问 `ctx.llm`、`ctx.database` 这类属性时，会触发 Proxy 拦截，随后沿着当前的 Fiber 链逐级向上查找，直到找到提供该服务的层级。

这种"沿链查找"的机制带来一个几乎免费的收益——**作用域隔离**：子层能看到父层注册的服务，反过来则不行。想让某个能力只在特定范围内生效，只需把对应插件挂在正确的层级，查找链自然会限制它的可见范围。

一个具体的例子是模型接入。Harness 定义了一个统一的 `llm` 服务接口（只规定"如何发流式调用、如何处理重试"，不关心具体厂商），系统里可以同时挂多个实现该接口的插件——一个适配 DeepSeek 自家模型，另一个负责多家第三方厂商的协议转换。二者互不知晓对方存在，上层 Agent 循环只面向接口编程，装哪个、换哪个都不需要改动调用方一行代码。

## 五、四种运行模式与预设（Preset）复用

针对不同场景，Harness 提供了四种运行模式：

- **标准模式（Standard）**：常规的智能体任务编排与执行。
- **PTC 模式（Programmatic Tool Call，编程式工具调用）**：让模型直接生成代码，用代码组合执行多轮复杂工具调用，降低长链路任务的往返成本。
- **极简模式（Minimal）**：只保留 Shell 和文件编辑工具，面向最小化基准测试。
- **创意模式（Creative）**：允许开发者在内存中直接实验插件，快速验证新的运行模式。

在"复用"这件事上，Harness 引入了**预设（Preset）**机制。一份预设本质上是"一份插件配置清单"，声明了要挂载哪些插件及参数。它的关键在于：**同一份预设的标准实例只挂载一次，后续任意多个会话可以复用同一实例**，而不是每新开一个会话就重新跑一遍插件加载。这通过一条"全局—预设—会话"的作用域链实现，不同用途的会话（写作、编码、调研）可以共享同一套已经跑起来的插件树。

与之配套的还有**工具的分层遮蔽**：一个工具在某个作用域下是否可见、被谁覆盖，是在运行时按作用域链实时计算出来的，而不是静态写死的。这解决了"工具要么全局可用、要么全局不可用"的二元困境——同一个工具在不同预设、不同会话里可以呈现完全不同的可见性，工具代码本身无需写一堆条件判断。

## 六、隔离与安全：Code Mode 的选型

当模型需要"写代码来编排多个工具调用"时，隔离方案的选择直接关系到安全。Harness 选择的是 **Node.js 的 `worker_threads`**，而非同进程的 `vm` 沙箱。

这背后是一个明确的工程权衡：`vm` 这类同进程沙箱存在原型链逃逸到主进程的风险，且热循环难以从外部真正打断；而独立工作线程提供的是**真正独立的 V8 堆**和**可被外部强制终止的执行环境**，代价是每次运行都要新开线程。

在信任假设上，框架把执行模型代码的 worker 视为"不可信的对端"：模型代码通过消息通道调用工具（而非直接引用函数），通道两端逐字段校验消息；宿主侧用精确的自有属性判断和空原型对象来暴露能力，防止 `__proto__`、`constructor` 之类的字段绕过原型链。这体现了一个正确的安全立场——**隔离边界以内，任何来自模型的输入都不被默认信任**。

## 七、架构层面的几点启示

从架构设计原则的角度回看，Harness 有几个值得记录的做法：

1. **把"可逆性"提升为一等公民。** 大多数框架把"加载"当作核心，"卸载"当作边缘善后；Cordis 把二者对称化，用可逆副作用统一起来。这是热插拔、HMR、乃至"自进化 Agent"（运行时装卸自己生成的组件）能够成立的前提。

2. **配置即架构。** 一份配置里一行就是一个插件实例，改配置即可触发热替换，无需改源码、无需重启。这让"拼插件、写配置、跑起来"的循环被显著压缩。

3. **循环本身也可替换。** 很多框架的工具接口、审批策略可配置，但驱动"采样—执行—反馈"的核心循环被固定在代码里。Harness 把这条循环也抽象为可替换的组件，理论上整个运行时没有哪个模块拥有不可撼动的特殊地位。

4. **副作用义务的收敛。** 框架无法证明"逆操作写得对不对"，但它通过"服务物化"把副作用集中到少数服务实现者身上，把"每个插件作者都要写对清理逻辑"的义务，收敛为"框架保证清理会被调用"。

## 八、局限与观察

作为 v0.1 开发者预览版，Harness 距离"面向普通开发者的成品"还有明显距离：目前上手仍需要 Node.js 工具链和命令行，对非工程背景的用户不够友好；插件生态刚刚起步；"逆操作是否正确"在语义层面仍是组件作者的义务，框架只保证结构、不保证语义。

但这些局限恰恰也暴露了它架构上的空间——宿主如何启动、界面如何呈现，本身就是可替换的插件，把这层复杂度包进一键启动，属于产品化问题而非架构障碍。

## 结语

DeepSeek Harness 的发布，标志着一个信号：Agent 的竞争正在从"模型效果"延伸到"运行时质量"。运行时如何组织、扩展成本多高、换一个组件要付出多大代价，这些工程决策正在成为 Agent 产品体验的一部分。

Harness 用 Cordis 这个经过生产验证的插件内核，加上"可逆副作用"这套设计哲学，把"一切皆插件"从口号落到了具体的结构上。至于这套架构能否在真实复杂场景中持续撑住，还需要时间和生态来验证，但它给出的方向——**一个可组合、可热插拔、可回滚的 Agent 运行时**——值得持续关注。

摘要：2026 年 8 月 13 日，DeepSeek 开源了它的第一款 Agent 产品 Harness v0.1（MIT 协议）。它不是又一个大模型，而是位于模型之上的"运行时层"。本文从架构设计原则出发，解析它最核心的主张——"一切皆插件（everything is a plugin）"，以及支撑这一主张的三块地基：可逆副作用、服务/事件协作、作用域与预设复用。文中所涉信息均基于公开资料，观点为个人技术分析，供交流参考。

从架构层面解读 DeepSeek Harness：一款"一切皆插件"的 Agent 运行时

摘要：2026 年 8 月 13 日，DeepSeek 开源了它的第一款 Agent 产品 Harness v0.1（MIT 协议）。它不是又一个大模型，而是位于模型之上的"运行时层"。本文从架构设计原则出发，解析它最核心的主张——"一切皆插件（everything is a plugin）"，以及支撑这一主张的三块地基：可逆副作用、服务/事件协作、作用域与预设复用。

架构设计

人工智能

开发工具

DeepSeek开源Agent运行时Harness v0.1，基于Cordis插件内核实现"一切皆插件"架构。核心机制包括可逆副作用保证热插拔、服务/事件双通道协作、作用域隔离及四种运行模式。通过配置即架构设计，实现组件可组合、可替换、可回滚的Agent执行环境，推动Agent竞争从模型效果转向运行时质量。

聊天机器人

TypeScript

数据库

智能体

DeepSeek

容器

Agent

2026上云采购 | AI焕新·智启新局

tione

腾讯云大数据特惠0.2折起


oceanus

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

从架构层面解读 DeepSeek Harness：一款"一切皆插件"的 Agent 运行时-腾讯云开发者社区-腾讯云

从架构层面解读 DeepSeek Harness：一款"一切皆插件"的 Agent 运行时

从架构层面解读 DeepSeek Harness：一款"一切皆插件"的 Agent 运行时

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐