> ## Content Index
> Fetch the complete content index at: https://yonglun.me/llms.txt
> Use this file to discover other available public pages before exploring further.

# 当 Agent 的心脏也可以被替换 - DeepSeek Harness 与「万物皆插件」的野心
- URL: https://yonglun.me/deepdeek-harness/
- Published: 2026-08-15T14:50:08.000Z
- Updated: 2026-08-15T14:50:08.000Z
- Description: DeepSeek Harness 以“万物皆插件”为核心理念，将模型、工具、沙盒乃至 Agent Loop 全部模块化。借助 Cordis、事件溯源、PTC 与多智能体机制，它试图构建一个可动态重组、可回放、可自我修改的 Agent 运行时，并为未来 AI 的自主进化与递归自我改进提供基础设施。
- Author: Yonglun
- Tags: AI

软件世界里有一种很古老的妥协。

我们喜欢说系统是“模块化”的。数据库可以换，模型可以换，搜索引擎可以换，工具可以换，甚至用户界面也可以彻底重写。但沿着架构图不断向中心走，总会抵达某个地方——那里通常有一小块代码不能碰。

它可能叫 Kernel，也可能叫 Runtime、Scheduler、Orchestrator，或者 Agent Loop。

名字并不重要。

重要的是，我们默认那里必须有一个**不可替换的中心**。

2026 年，DeepSeek Harness 做了一件颇有挑衅意味的事情：

它问，为什么？

---

# **模型越来越聪明，真正麻烦的却变成了模型之外的世界**

早期的大语言模型应用非常简单。

输入一段文字，调用一次 API，得到另一段文字。

那时候，软件工程师面对的问题主要是 Prompt 怎么写、Temperature 设多少、上下文窗口够不够长。

Agent 改变了这一切。

一个真正工作的 Agent，需要读取文件、修改代码、调用 Shell、访问网络、维护会话、恢复中断的任务、管理权限、启动子智能体，甚至连续运行几十分钟乃至几个小时。

模型只是其中的一部分。

围绕模型开始出现越来越庞大的基础设施：

**Tools、Memory、Session、Sandbox、Permission、Agent Loop、Subagents、Event Bus、Observability……**

如果把大模型看作一个人的大脑，那么这些东西更接近他的身体、感官、记忆和行动系统。

问题也随之发生了变化。

过去我们问：

**哪个模型更聪明？**

现在越来越重要的问题变成：

**怎样给这个模型造一副足够好的身体？**

这副身体不仅要能够行动，还必须能够被拆开、替换、修复和重新组合。

传统 Agent 框架当然也允许扩展。你可以增加 Tool，可以注册 Hook，也可以接入不同的模型。

但扩展通常存在一个边界。

工具可以替换。

模型可以替换。

Memory 可以替换。

可是控制 Agent 如何思考、何时调用工具、怎样把结果重新交给模型的那段核心循环，往往仍然隐藏在框架深处。

于是，当开发者真正想改变 Agent 的工作方式时，事情很快会变得不那么优雅。

Fork。

修改源码。

维护自己的分支。

然后等待上游更新。

再开始漫长的 Merge。

这就是软件世界里一种并不陌生的税：

**Fork Tax——分叉税。**

DeepSeek Harness 想从架构上消灭它。

它提出了一句近乎宣言式的话：

**Everything is a Plugin.**

万物皆插件。

不是“大部分东西”。

而是——**所有东西。**

---

# **如果万物皆插件，那么谁是核心？**

第一次看到 DeepSeek Harness 的架构时，真正值得注意的并不是它拥有多少工具，也不是它支持多少模型。

而是一个奇怪的缺席：

**它几乎没有传统意义上的“特权核心”。**

模型适配器是插件。

工具系统是插件。

Session 是插件。

Sandbox 是插件。

Permission 是插件。

Web UI 是插件。

甚至连负责驱动智能体不断执行“思考—行动—观察—再思考”的 **Agent Loop，也只是一个插件。**

这件事比听起来更加激进。

在许多 Agent Framework 中，工具是“家具”，模型是“住客”，而 Agent Loop 是房屋本身。

家具可以换，住客可以换。

但没人会在居住过程中把承重墙拆下来。

DeepSeek Harness 的想法更接近另一种建筑：

**连承重结构都是可替换的。**

于是一个很有意思的问题出现了：

如果所有组件都可以替换，那么究竟是什么维持着整个系统？

答案藏在 DeepSeek Harness 最不显眼、却可能也是最重要的部分：

**Cordis。**

---

# **Cordis：让软件学会“忘记”**

插件架构并不是新鲜事。

浏览器有插件。

VS Code 有插件。

WordPress 有插件。

操作系统甚至可以动态加载内核模块。

真正困难的从来不是“加载”。

而是：

**怎样安全地卸载？**

想象一个插件进入系统以后注册了三个事件监听器，修改了两个状态，启动了一个后台任务，又向某个服务注册表加入了一项能力。

几分钟以后，你决定把它换掉。

问题来了。

谁负责把这些东西全部清理干净？

少清理一个监听器，就可能出现幽灵回调。

忘记关闭一个后台任务，就可能发生资源泄漏。

留下一个旧引用，新旧组件便可能同时操作同一份状态。

动态系统最危险的地方，往往不是新组件没有启动。

而是：

**旧组件没有真正死去。**

Cordis 给出的答案叫：

**Revertible Effects——可逆副作用。**

它要求插件对环境做出的每一个改变，都必须附带一个相反方向的动作。

注册事件监听器，就必须知道怎样注销。

创建资源，就必须知道怎样释放。

修改状态，就必须知道怎样撤销。

这些清理操作被记录下来。

插件退出时，它们按照与创建时相反的顺序执行。

像搭积木。

最后放上去的一块，最先拿下来。

这其实是一种非常简单，却又非常深刻的纪律：

**任何进入系统的东西，都必须知道自己怎样离开。**

于是插件不再只是“可加载”。

它开始真正变得：

**可撤销。**

这构成了 Cordis 所谓“时间可组合性”的基础。

---

# **另一半问题：如果依赖突然消失怎么办？**

时间解决了卸载的问题。

但大型 Agent 系统还有另一个麻烦。

依赖关系。

假设一个插件需要两个能力：

tools  
llm

传统软件通常要求工程师决定启动顺序。

先初始化模型。

再初始化工具。

然后启动 Agent。

如果顺序错了，系统就报错。

Cordis 做了一件更接近现代分布式系统的事情。

插件可以直接声明：

**我需要 tools 和 llm。**

如果这些能力还不存在，它不会崩溃。

它只是进入：

**PENDING。**

等待。

某个时刻，一个 LLM Provider 被加载，`ctx.llm` 出现了。

Cordis 发现依赖已经满足。

插件自动启动。

但更有意思的是反方向。

如果运行途中 LLM Provider 被卸载了呢？

依赖它的组件也会停止工作，撤销自己的副作用，重新回到等待状态。

直到新的 Provider 出现。

整个系统因此不再像传统程序那样拥有一个固定的启动顺序。

它更像一座城市。

电力恢复，依赖电力的设施逐渐苏醒。

某项基础服务消失，相关区域自动关闭。

新的服务重新出现，系统再次恢复运行。

DeepSeek Harness 把这种能力称为：

**Reactive Coeffects——响应式共效应。**

如果 Revertible Effects 解决的是：

**一个组件怎样干净地离开？**

那么 Reactive Coeffects 解决的就是：

**一个组件怎样知道什么时候应该存在？**

两者结合，才形成所谓：

**Spatiotemporal Composability——时空可组合性。**

这听起来很学术。

但翻译成工程语言其实很简单：

**组件可以随时出现，也可以随时消失，而系统仍然保持完整。**

---

# **Agent 不再是一台机器，而是一片不断变化的拓扑**

这种思想带来了一个很有意思的结果。

DeepSeek Harness 不再像传统程序那样，由一组固定模块构成。

它更接近一棵**运行时不断变化的插件树**。

每一个插件实例都有自己的生命周期句柄：

**Fiber。**

一个 Fiber 可能处于：

PENDING → LOADING → ACTIVE → UNLOADING → DISPOSED。

如果加载失败，则进入 FAILED。

这套状态机真正重要的地方并不是这些名字。

而是它让系统第一次可以非常明确地回答：

**此刻，这个组件究竟处于什么状态？**

它正在等待依赖？

正在初始化？

已经工作？

还是正在退出？

对于一个几十个乃至上百个插件组成的 Agent Runtime，这种确定性极其重要。

因为未来的 Agent 系统越来越不像传统应用。

它们更像一个**动态生态系统**。

模型可能改变。

工具可能改变。

权限可能改变。

子 Agent 可能出现又消失。

运行策略也可能在任务执行过程中发生变化。

DeepSeek Harness 试图让这种变化成为系统的正常状态，而不是异常状态。

---

# **真正大胆的地方：把 Agent Loop 从王座上赶下来**

这也许是整个 DeepSeek Harness 最值得关注的设计。

几乎所有 Agent 都有某种循环。

简化以后，大致如此：

读取上下文  
↓  
调用 LLM  
↓  
模型决定调用工具  
↓  
执行工具  
↓  
把结果加入上下文  
↓  
再次调用 LLM

这个循环就是 Agent Loop。

在很多框架里，你可以修改循环周围的东西。

但循环本身往往属于框架。

DeepSeek Harness 做了一个非常不同的决定：

**Agent Loop 也只是 Cordis 插件。**

它提供一个服务：

ctx.agentLoop

仅此而已。

于是理论上，你完全可以把默认 Agent Loop 拔掉。

换成一个自己的版本。

例如，一个传统同步循环可以被替换成：

并行 Actor 模型；

多智能体协作网络；

Plan-and-Execute；

Tree Search；

异步事件驱动 Agent；

甚至未来某种今天还没有名字的推理架构。

而 Session、Tools、Sandbox、LLM Provider 和 UI 都不需要因此重新开发。

这是一种非常重要的架构倒置。

传统 Agent Framework 的潜台词是：

**这是我的 Agent，你可以扩展它。**

DeepSeek Harness 更像是在说：

**这里有一组能力。至于什么叫 Agent，由你决定。**

区别非常大。

---

# **这也悄悄打开了一扇危险而迷人的门：Agent 修改自己**

一旦 Agent Loop 本身可以替换，事情就开始变得有些科幻。

因为一个 Agent 理论上可以：

检查当前运行时；

发现自己的调度方式不适合当前任务；

生成一个新的 Agent Loop；

安装它；

卸载旧 Loop；

然后继续执行任务。

也就是说：

**程序修改的对象，开始包含程序自己。**

DeepSeek Harness 提供的 Creator Mode，正是在试探这个方向。

我们过去习惯把 AI 写代码理解为：

AI 修改另一个程序。

但这里出现了另一种可能：

**AI 修改承载自己的程序。**

两者之间隔着一道非常重要的边界。

前者是 Coding Agent。

后者已经开始触碰：

**Self-Modifying Agent。**

甚至是更遥远的：

**Recursive Self-Improvement。**

当然，能够修改自己的运行时，并不意味着系统已经拥有真正意义上的递归自我改进。

“可以改变自己”和“能够持续把自己变得更聪明”，是两件完全不同的事情。

但基础设施已经开始为后者留下接口。

这才是 DeepSeek Harness 最值得注意的地方。

---

# **如果一切都可以变化，什么东西不能变化？**

一个无限可修改的系统会立刻遇到另一个问题：

**怎样知道自己没有坏掉？**

DeepSeek Harness 的答案有些反直觉。

它一方面允许大量组件被替换，另一方面又对系统状态保持近乎偏执的纪律。

其中最重要的一条原则是：

**Model-visible means logged.**

模型看到的东西，就必须被记录。

DeepSeek Harness 的 Session 并不是普通聊天记录。

它更接近一个：

**Append-Only Event Log。**

系统不反复修改“当前状态”。

它不断记录：

发生了什么。

工具调用。

工具结果。

上下文注入。

Agent 状态变化。

模型交互。

然后通过这些事件重新推导当前状态。

这与金融账本有某种相似之处。

银行不会只保存：

余额：10,532 元。

它更愿意保存：

收入 5000。

支出 120。

转账 800。

退款 50。

……

最后：

**余额只是历史事件的投影。**

DeepSeek Harness 对 Agent 状态采取了类似的哲学。

---

# **于是，Agent 第一次拥有了可以真正重放的“过去”**

这带来一个非常现实的工程收益：

**Replay。**

传统 Agent 出问题时，工程师经常面对一种令人沮丧的场景。

日志看起来没问题。

Prompt 看起来没问题。

工具也工作正常。

可是模型为什么在第 37 步突然做了那个决定？

没人知道。

因为日志只是“尽量记录”。

它并不一定等于模型当时真正看到的世界。

DeepSeek Harness 强制要求：

**模型看到的上下文必须与事件日志能够重建出的上下文一致。**

这意味着某个 Agent 在凌晨三点失败以后，第二天工程师可以重新构造：

**失败前一秒，模型眼中的整个世界。**

甚至可以不调用真正的模型。

历史运行轨迹可以成为 Fixture。

Mock Model 根据历史记录返回确定性结果。

Agent 重新执行。

然后：

**Diff。**

旧轨迹。

新轨迹。

哪里不同，一目了然。

对于传统软件开发，这很普通。

对于概率性的 LLM Agent，却是一件意义很大的事情。

Agent 工程开始拥有类似普通软件的：

**Regression Testing。**

---

# **PTC：为什么 Agent 不应该把整个世界塞进 Prompt**

Agent 时代还有一个越来越昂贵的问题：

Token。

传统 Function Calling 的工作方式通常是：

模型输出工具调用；

工具返回结果；

结果被转成文本；

文本塞回上下文；

模型继续阅读。

如果工具返回 50 KB JSON，也许还可以忍受。

如果返回 50 MB 呢？

模型真正需要的可能只是：

符合条件的记录有 17 条。

但为了得到这个数字，我们让模型阅读了一整座仓库。

DeepSeek Harness 的 PTC——**Programmatic Tool Calling**——试图改变这个过程。

它的思路是：

**不要让模型不断调用工具。**

让模型：

**写程序。**

例如模型不再依次执行：

fetch()  
fetch()  
filter()  
sort()  
aggregate()

而是直接生成一段 TypeScript。

程序在 Sandbox 中运行。

几十 MB 的 JSON 留在沙盒内存。

过滤、排序、聚合也在那里完成。

最后只把真正需要的结果：

submit(result)

交回模型。

这背后其实是一种很重要的 Agent 设计哲学：

**让计算发生在计算应该发生的地方，而不是把所有数据都变成语言。**

LLM 很擅长语言。

但数据库擅长过滤。

代码擅长循环。

CPU 擅长计算。

搜索引擎擅长检索。

未来真正成熟的 Agent，不应该试图让 LLM 做所有事情。

它应该知道：

**什么时候不需要思考。**

---

# **能力越大，围墙就必须越厚**

问题也随之而来。

如果模型能够生成代码，并且代码真的可以运行，那么一句：

rm -rf /

就不再只是文本。

它可能成为行动。

于是 Sandbox 不再是 Agent Framework 的附加功能。

它开始成为：

**基础设施边界。**

DeepSeek Harness 把权限拆成两个维度。

一个决定：

**你实际上能做什么。**

另一个决定：

**做之前是否需要人类批准。**

例如文件系统可以处于：

read-only；

workspace-write；

或者 danger-full-access。

操作策略则可以要求：

ask；

或者 never。

更重要的是，它遵循：

**Fail Closed。**

如果权限系统坏了怎么办？

传统软件有时会选择：

“先继续运行。”

DeepSeek Harness 的答案相反：

**拒绝。**

安全机制无法确认，就不执行。

这是一条看似保守，却可能决定 Agent 能否真正进入企业生产环境的原则。

因为未来最大的 Agent 安全事故，很可能并不是模型“说错了什么”。

而是：

**模型真的做了什么。**

---

# **一个 Agent 已经不够了**

当任务越来越复杂，单一 Agent 也开始显得笨重。

一个 Agent 同时阅读几百个文件、分析架构、修改代码、运行测试、检查安全问题，会产生越来越长的上下文。

于是任务开始自然分裂。

一个 Agent 分析数据库。

一个检查前端。

一个研究测试。

一个负责架构。

另一个负责最终整合。

DeepSeek Harness 把 Subagent 同样抽象成服务：

ctx.subagents

于是子智能体究竟运行在哪里，也变成可以替换的实现。

它可以与主 Agent 处于同一进程。

可以继承主 Agent 的部分上下文。

可以启动独立 DSH 进程。

甚至可以通过协议调用其他 Agent Runtime。

这意味着未来的 Agent 系统可能不再是一棵简单的调用树。

而是一张：

**动态计算网络。**

Agent 出现。

执行任务。

交换结果。

然后消失。

真正稳定存在的，也许只有：

事件。

接口。

权限。

以及协议。

---

# **真正有意思的并不是 DeepSeek，而是 Harness**

过去两年，AI 行业的大部分注意力都集中在模型。

GPT。

Claude。

Gemini。

DeepSeek。

参数规模。

Benchmark。

Context Window。

推理能力。

但随着模型能力逐渐接近一个新的平台期，竞争正在向模型之外移动。

一个越来越重要的词开始出现：

**Harness。**

它很难准确翻译。

“框架”太轻。

“运行时”又太窄。

“智能体基础设施”可能更接近它真正的含义。

Harness 决定：

模型能看见什么；

能够调用什么；

怎样保存记忆；

怎样恢复任务；

怎样使用计算资源；

怎样受到权限约束；

怎样与其他 Agent 合作；

以及——

**怎样改变自己的行为。**

从这个角度看，未来 AI 系统真正的差异，也许不会只来自模型。

同一个模型，被装进不同 Harness，可能表现得像完全不同的智能体。

就像同样的大脑，如果拥有不同的身体、记忆、工具和社会环境，最终会成为完全不同的人。

---

# **DeepSeek Harness 真正激进的地方，是它拒绝相信“核心”**

计算机科学长期存在一种近乎本能的架构习惯：

总要有一个中心。

操作系统有 Kernel。

数据库有 Engine。

Web Framework 有 Runtime。

Agent Framework 有 Agent Loop。

DeepSeek Harness 提出了另一种可能。

真正稳定的东西也许不应该是一段不可替换的代码。

真正稳定的应该是：

**接口、契约、事件和不变量。**

实现可以变化。

模型可以变化。

工具可以变化。

调度方式可以变化。

甚至“Agent 是什么”本身也可以变化。

只要契约仍然成立。

这让 DeepSeek Harness 看起来不像一个普通的软件框架。

它更像是一种关于未来软件的实验。

---

# **机器开始拥有一副可以重新设计的身体**

1965 年，I. J. Good 描述“智能爆炸”时，想象的是一台足够聪明的机器开始设计比自己更聪明的机器。

六十多年以后，我们距离那个场景究竟还有多远，没人知道。

但真正的递归自我改进不会只发生在模型权重里。

一个智能系统如果想真正改进自己，它必须能够观察自己的行为，理解自己的失败，修改自己的工具，改变自己的调度方式，验证修改后的结果，并在失败时安全地回滚。

换句话说，它不仅需要一个聪明的大脑。

还需要一副：

**可以被自己重新设计的身体。**

DeepSeek Harness 最值得关注的地方，也许就在这里。

今天，它仍然只是一个年轻的 Agent Runtime。

它的 API 仍然可能变化。

它的插件生态还远未成熟。

它也没有证明 Agent 可以因此实现真正意义上的递归自我改进。

但它已经把一个过去被认为理所当然的问题重新摆到了桌面上：

**为什么 Agent 的运行时必须是固定的？**

如果模型能够写代码。

如果工具可以动态安装。

如果组件可以安全卸载。

如果 Agent Loop 本身可以被替换。

如果系统能够记录自己的历史。

如果它能够重放失败、验证修改，然后重新启动……

那么某一天，我们也许会发现：

真正重要的那一步，并不是机器第一次写出了更好的代码。

而是机器第一次意识到——

**那段需要被改写的代码，就是它自己。**