大模型能力持续提升之后，Agent 系统的竞争焦点正在发生变化。
过去，我们主要关心模型能不能理解任务、调用工具、编写代码。现在，更重要的问题逐渐变成：模型之外的系统，能否为 Agent 提供一个可以持续变化的运行环境？
这个运行环境通常被称为 Agent Harness。
Harness 负责把模型、提示词、工具、记忆、上下文、权限和外部环境连接起来。它决定模型能够看到什么、调用什么、保存什么，以及一次行动会产生怎样的系统影响。
从这个角度看，Agent 的能力并不只来自模型，用一个公式来表达，大概如下：
Agent 能力
=
模型能力
× 上下文组织
× 工具系统
× 运行时结构
× 生命周期治理
如果 Harness 是固定的，那么即使模型越来越强，Agent 的能力边界仍然主要由开发者预先决定。
如果 Harness 可以扩展，用户和开发者就能不断为 Agent 增加工具、技能和工作流。
但如果我们希望 Agent 进一步具备「自生长」能力，仅仅提供扩展接口还不够。系统还必须允许 Agent：
-
-
-
-
-
-
-
Pi 与 DSH 可以被视为这条演进路径上的两个阶段。
Pi 回答的是：
如何构建一个足够小、足够开放，可以持续扩展的 Agent Harness？
DSH 进一步追问：
如何让 Agent 不只是使用外部提供的扩展，而是安全地参与自身能力结构的形成？
这不是从一种插件格式切换到另一种插件格式，而是 Agent Harness 从开放扩展平台向能力生长环境的转变。
1. 什么是 Agent Harness
一个最简单的 Agent，可以被表示为：
Model
↓
Prompt
↓
Tool Call
↓
Environment
模型接收上下文，生成工具调用，再根据工具结果继续推理。
但在真实系统里，Agent 还需要处理更多问题：
于是，Agent 的实际结构更接近于：
┌─────────────┐
│ Model │
└──────┬──────┘
│
┌──────▼──────┐
│ Agent Loop │
└──────┬──────┘
│
┌───────────────┼────────────────┐
│ │ │
┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐
│ Tools │ │ Memory │ │ Context │
└─────────────┘ └─────────────┘ └─────────────┘
│ │ │
└───────────────┼────────────────┘
│
┌──────▼──────┐
│ Environment │
└─────────────┘
Harness 并不是模型外面的一层简单包装。
它实际上规定了 Agent 的：
因此，当我们讨论 Agent 是否可以扩展、重构甚至自生长时，本质上讨论的不是模型参数如何变化，而是 Harness 能否安全地改变自身结构。
2. Pi：以最小内核换取最大扩展空间
Pi 的核心思想非常明确：
不要预先替用户决定完整工作流，而是提供足够小的基础能力，让用户自己构建需要的 Harness。
Pi 将自己定义为一个最小化的 Agent Harness，并通过 Extensions、Skills、Prompt Templates、Themes 和 Packages 提供扩展能力。它允许用户修改工具、命令、模型提供商、工作流、上下文处理和终端界面，也支持将这些资源打包后通过 npm 或 Git 分发。(pi.dev)
这背后是一种「原语优先」的设计哲学：
不是：
内置所有功能
而是：
提供少量原语
+
开放扩展接口
+
允许用户自行组合
2.1 最小化不是能力不足
传统 Agent 产品通常倾向于内置更多功能：
Pi 选择了另一条路线：这些能力不一定需要成为内核的一部分，它们可以通过扩展或外部环境实现。
Pi 当前提供文件读取、文件修改、内容搜索和命令执行等内置工具，同时允许通过命令行配置工具集合，也允许 Extension 注册新的工具或覆盖现有工具。(pi.dev)
这种设计的意义把稳定的内核和变化的能力分开：
稳定部分：
模型调用、Agent Loop、会话、基础工具、扩展 API
变化部分：
工具、技能、上下文、工作流、权限策略、界面、模型路由
只要扩展接口足够开放，功能就不必全部固化在核心代码中。
2.2 Pi 的四类扩展资源
从 Harness 的角度看，Pi 的可扩展性主要体现在以下几个层面。
2.2.1 Extensions：改变运行时行为
Extension 是可以进入 Agent 运行时的代码模块。
它可以：
因此，Extension 改变的不只是模型“知道什么”，还可以直接改变 Harness“如何运行”。
2.2.2 Skills：注入按需能力
Skill 更接近一种可复用的过程知识。
它可以告诉 Agent：
Pi 将 Skill 设计为按需加载的能力包，使 Agent 不必在每次会话开始时把所有知识都放进上下文。(pi.dev)
2.2.3 Prompt Templates：固化交互模式
Prompt Template 将常见任务封装成可复用提示词，例如：
它改变的是任务入口和交互结构。
2.2.4 Packages：分发完整能力
Package 可以将 Extensions、Skills、Prompt Templates 和 Themes 组合起来，通过 npm、Git 或本地路径安装。Pi 还支持临时加载 Package，使组件只对当前运行生效。(github.com)
这使 Pi 不只是一个 Agent，也成为一个 Harness 能力分发平台：
Pi Package
├── Extensions
├── Skills
├── Prompts
└── Themes
2.3 Pi 的关键突破：Agent 可以参与修改 Harness
Pi 最值得关注的地方，不只是「插件多」。
它的官方描述明确鼓励用户让 Pi 编写自己需要的扩展，并在修改后通过重新加载继续当前工作。(pi.dev)
这意味着一种新的工作方式正在出现：
Agent 发现缺少某项能力
↓
Agent 编写 Extension
↓
用户检查或确认
↓
重新加载 Harness
↓
Agent 使用新增能力继续任务
过去，Agent 与开发工具之间的关系通常是：
人类开发 Harness
Agent 使用 Harness
在 Pi 中，它开始变成：
人类定义目标
Agent 修改 Harness
Agent 使用修改后的 Harness
这是从「可扩展」走向「自生长」的重要一步。
但是，这还不等于完整的自生长。
3. 行为自治不等于结构自治
理解 Pi 与 DSH 的关系，需要区分两种不同的自治。
3.1 行为自治
行为自治指 Agent 可以在已有能力范围内自主决定：
此时，Agent 的选择空间是动态的，但能力集合通常是预先确定的。
固定工具集合
↓
Agent 自主选择工具
↓
完成任务
3.2 结构自治
结构自治指 Agent 可以改变自己的能力结构：
当前能力结构
↓
Agent 发现能力缺口
↓
生成候选组件
↓
改变 Harness
↓
形成新的能力结构
Pi 已经为结构自治打开了入口。
但它的扩展机制主要回答的是：
如何把一项新能力加入系统？
真正的自生长还必须回答：
这些问题将我们从扩展系统带到了组件运行时。
4. DSH：为 Harness 自生长建立运行时基础
本文讨论的 DSH，不只是另一个插件系统。
它试图将 Agent Harness 表达为一个可以在运行中不断组合和重组的组件系统。
其基本结构可以概括为：
Component
=
Context
+
Effect
+
Cleanup
+
Coeffects
这四个概念分别回答四个问题：
| 概念 |
回答的问题 |
| Context |
组件可以看到和使用什么？ |
| Effect |
组件加入系统后会产生什么影响？ |
| Cleanup |
组件退出时如何撤销影响？ |
| Coeffects |
组件依赖哪些外部能力或其他组件？ |
DSH 的目标不是让所有模块都能任意修改系统，而是让变化成为一种显式、可追踪、可逆的运行时操作。
4.1 Context：为能力提供明确边界
一个组件不能直接访问所有系统状态。
它应该通过 Context 获取所需能力，例如：
Context
├── Model Registry
├── Tool Registry
├── Memory
├── Event Bus
├── Session
├── Logger
├── Storage
├── Permission
└── Environment
Context 的第一层作用是解耦。
组件不需要知道某个能力的具体实现，只需要知道运行环境向它提供了什么。
例如，一个模型路由组件可能只依赖：
Model Registry
Task Metadata
Usage Metrics
一个长期记忆组件可能只依赖：
Session Events
Embedding Service
Storage
Context Injector
一个工具组件则可能只依赖：
Tool Registry
Credentials
Network
Logger
Context 的第二层作用是限制能力边界。
如果组件只能通过 Context 访问环境，那么系统就可以决定：
因此，Context 不只是依赖注入，也是一种能力安全模型：
组件能做什么
≈
Context 向它暴露什么
4.2 Effect 与 Cleanup：让变化可以被撤销
当组件加入 Harness 时，通常会产生副作用。
例如：
这些变化可以统一理解为 Effect：
Component
↓
Effect
↓
Harness 状态发生变化
问题在于，大多数插件系统只强调如何创建 Effect，却没有把撤销 Effect 当作同等重要的能力。
于是，组件卸载后可能出现：
在 DSH 中，Effect 应该返回对应的 Cleanup：
Effect(Context) → Cleanup
例如：
function activate(context) {
const unregister = context.tools.register(myTool)
return function cleanup() {
unregister()
}
}
更复杂的组件可能产生多个副作用：
function activate(context) {
const stopTool = registerTool(context)
const stopListener = registerListener(context)
const stopWorker = startWorker(context)
const closeConnection = connectDatabase(context)
return async function cleanup() {
await stopWorker()
stopListener()
stopTool()
await closeConnection()
}
}
这使组件具备完整生命周期：
创建
↓
激活
↓
运行
↓
停用
↓
清理
4.3 时间可组合性：让 Agent 有资格试错
Effect 与 Cleanup 提供的是一种时间可组合性。
一个组件可以在某个时刻进入系统，也可以在另一个时刻完整退出：
t₀：Harness 原始状态
t₁：组件进入
→ 注册工具
→ 启动服务
→ 注入上下文
t₂：组件运行
t₃：组件退出
→ 移除工具
→ 停止服务
→ 撤销上下文
t₄：Harness 恢复到可预测状态
这对普通插件系统很重要，但对自生长系统更重要。
因为自生长必然包含试错。
Agent 创建的新工具、新路由器、新记忆策略，不可能每次都正确。如果一次失败的尝试不能被完整撤销，那么每次实验都会向系统中留下残余状态。
最终，所谓“生长”就会退化成不可控的复杂度积累。
因此，自生长的基本过程不应该是：
生成组件
↓
永久安装
而应该是：
生成候选组件
↓
执行受控 Effect
↓
验证运行结果
┌──┴──┐
成功 失败
│ │
保留 Cleanup
Cleanup 的意义不只是“支持热卸载”。
它赋予 Agent 一种更关键的能力：
在不永久污染系统的前提下试验新的自身结构。
4.4 Coeffects：让依赖关系成为运行时的一部分
时间可组合性解决的是组件何时进入、何时退出。
但 Agent Harness 的组件并不是彼此孤立的。
如果依赖关系只是组件内部的隐式假设，运行时就无法回答：
Coeffects 用于显式表达组件所需的外部条件：
Effect：
组件对系统做什么
Coeffects：
组件需要系统提供什么
例如：
const vectorMemory = {
coeffects: [
"embedding-model",
"vector-storage",
"session-events"
],
effect(context) {
return cleanup
}
}
运行时可以根据当前 Context 判断组件是否具备激活条件：
依赖全部满足
↓
组件激活
依赖不完整
↓
组件保持未激活
依赖运行中消失
↓
执行 Cleanup
这使 Harness 不再只是一个插件列表，而是一个动态依赖图：
Credential
↓
GitHub Provider
↓
GitHub Tool
↓
Repository Agent
或者：
Embedding Model ─┐
├→ Vector Memory → Context Injector
Vector Storage ──┘
4.5 空间可组合性：让生长不是无序堆积
Coeffects 提供的是一种空间可组合性。
组件不是按照固定顺序硬编码在系统中，而是根据能力和依赖形成运行时拓扑。
当一个能力出现时，依赖它的组件可以被激活；当这个能力消失时，相关组件可以被停用：
Sandbox 出现
↓
Code Executor 激活
↓
Test Runner 激活
↓
Coding Agent 获得安全执行能力
如果 Sandbox 被移除：
Sandbox 消失
↓
Code Executor Cleanup
↓
Test Runner Cleanup
↓
相关工具从 Agent 能力集合中撤销
这与传统插件系统有一个关键区别。
传统插件系统更像：
安装了什么
=
系统拥有什么
而动态组件运行时更像：
当前可用能力
=
当前组件
× 当前依赖
× 当前环境
× 当前权限
这使 Harness 的结构可以随着任务和环境变化，而不是不断向全局系统中永久添加模块。
真正的生长，不是组件数量持续增加，而是系统能够形成更适合当前任务的能力结构。
4.6 从动态重组到自生长闭环
Context、Effect、Cleanup 和 Coeffects 为动态重组提供了基础。
但必须强调：
动态重组是自生长的必要条件，不是自生长的全部。
完整的自生长至少需要五个阶段。
4.6.1 第一阶段：发现能力缺口
Agent 首先要判断自己缺少什么。
例如：
能力缺口不能只由「工具调用失败」判断。
它还可能来自：
因此，自生长的起点不是生成代码，而是：
目标要求
-
当前能力
=
能力缺口
4.6.2 第二阶段：生成或引入候选能力
识别缺口后，Agent 可以选择不同方式补齐能力：
这里的关键词是「候选」。
Agent 生成的组件不能因为能够编译或加载，就自动成为系统的永久能力。
生成成功
≠
能力有效
≠
适合长期保留
4.6.3 第三阶段：在受控环境中激活
候选组件应该先进入受限 Context。
系统需要明确：
这一点尤其重要，因为扩展代码通常拥有较高权限。
以 Pi 为例，其官方安全文档明确说明，内置工具和 Extension 默认继承启动 Pi 的进程权限；第三方 Package 可能执行代码或指示模型执行操作，因此需要代码审查，并在需要时依赖容器或虚拟化提供真正的隔离边界。(github.com)
如果 Agent 开始自行生成和加载组件，权限问题只会更加突出。
所以，自生长必须建立在受控运行时上，而不能建立在「默认信任所有新代码」之上。
4.6.4 第四阶段：验证、保留或回滚
候选能力激活后，系统需要对它进行验证。
验证可以包括：
验证结果通常有三种：
验证通过
↓
保留或固化
部分通过
↓
修改后重新试验
验证失败
↓
Cleanup + 回滚
因此，自生长不是一次性的代码生成，而是一个选择过程：
Generate
→ Activate
→ Observe
→ Evaluate
→ Select
没有评估的生成，只是变化。
经过评估和选择的变化，才可能成为生长。
4.6.5 第五阶段：沉淀、复用与淘汰
一次任务中的成功，不代表组件值得永久保留。
系统还需要决定：
因此，一个可复用组件除了代码，还需要附带元数据：
Component
├── Implementation
├── Capability Description
├── Coeffects
├── Permissions
├── Validation Records
├── Version
├── Provenance
├── Metrics
├── Effect
└── Cleanup
真正的自生长闭环应当是：
发现缺口
↓
生成候选能力
↓
隔离激活
↓
观察与验证
↓
保留或回滚
↓
沉淀为可复用组件
↓
持续评估
↓
升级或淘汰
5. Pi 与 DSH 的核心差异
Pi 与 DSH 并不是简单的替代关系。
它们关注的是两个不同层次的问题。
| 维度 |
Pi |
DSH |
| 核心目标 |
构建开放、可定制的 Agent Harness |
构建支持动态变化的组件运行时 |
| 能力来源 |
Extensions、Skills、Prompts、Packages |
运行时组件及其依赖关系 |
| 主要变化发起者 |
用户、开发者，也可以由 Agent 辅助 |
用户、系统或 Agent |
| 组件组织方式 |
扩展资源与 Package |
动态依赖图 |
| 激活方式 |
启动加载、临时加载或重新加载 |
根据 Context 与 Coeffects 激活 |
| 生命周期 |
以扩展加载和配置为中心 |
Effect 与 Cleanup 对称管理 |
| 依赖治理 |
主要由扩展代码和包依赖处理 |
将运行时能力依赖显式化 |
| 失败处理 |
依赖扩展实现、进程或会话边界 |
通过 Cleanup 支持组件级回滚 |
| 演化方向 |
从固定产品走向开放平台 |
从开放平台走向受控自生长 |
| 核心价值 |
让 Harness 容易被改变 |
让 Harness 可以安全地持续改变 |
可以把两者的关系概括为：
Pi：
稳定核心
+
开放扩展点
+
能力分发机制
DSH：
组件化 Context
+
显式 Coeffects
+
可逆 Effect
+
动态生命周期
Pi 解决了「能力能否加入」的问题。
DSH 更关注「能力如何进入、如何协作、如何退出，以及如何在运行时形成新的结构」。
6. 从可扩展到自生长，中间还差什么
可以把 Agent Harness 的演进分为三个阶段。
6.1 第一阶段：固定能力
模型
+
固定提示词
+
固定工具
系统能够执行任务，但能力边界在设计阶段已经确定。
如果缺少能力，只能由开发者修改产品代码并重新发布。
6.2 第二阶段：开放扩展
稳定核心
+
Extensions
+
Skills
+
Packages
+
开放 API
用户和开发者可以持续增加能力。
Agent 也可以帮助编写扩展，但扩展的发现、安装、验证和维护通常仍然依赖人工流程。
Pi 代表了这一阶段的重要方向：Harness 不再是一个封闭产品，而成为可以根据个人工作流持续定制的平台。
6.3 第三阶段：受控自生长
稳定内核
+
能力缺口识别
+
候选组件生成
+
动态组件运行时
+
显式依赖
+
可逆副作用
+
隔离验证
+
自动回滚
+
能力沉淀
+
持续淘汰
Agent 不再只是等待外部为它安装能力。
它可以根据任务识别不足，提出新的能力结构，在受控环境中试验，并根据结果决定保留、修改还是撤销。
这时，Agent 的角色从能力消费者变成了能力形成过程的参与者。
7. 自生长不等于无限增长
「自生长」并不是 Agent 不断为自己增加工具和代码。
无限增加不是生长，而是熵增。
一个只会添加能力、不会清理能力的系统，最终会出现：
因此，自生长必须同时包含四种能力：
增加
+
选择
+
清理
+
遗忘
可以进一步表示为：
可持续生长
=
生成新能力
-
淘汰无效能力
+
重组已有能力
这也是 Cleanup 和生命周期管理的重要性所在。
真正成熟的 Agent 不仅要知道「我还需要什么」，还要知道：
遗忘不是生长的反面。
受控遗忘本身就是生长的一部分。
9. Pi 与 DSH 不是替代，而是演进
Pi 的价值在于证明了一件事：
Agent Harness 不需要是一个功能固定的封闭产品。
通过开放 Extension、Skill、Prompt 和 Package，Harness 可以被用户重新塑造，也可以让 Agent 辅助编写自身需要的扩展。
这已经比传统 Agent 产品向前迈出了一大步。
DSH 所代表的方向，则是在此基础上进一步抽象：
如果 Agent 可以创建新能力，那么这些新能力应该如何成为运行时的一等公民？
答案不能只是把更多代码放进扩展目录。
系统还需要：
因此，二者可以形成一种递进关系：
Pi：
让 Harness 可以被修改
↓
DSH：
让修改具有显式生命周期
↓
自生长 Agent：
让 Agent 可以发起、验证并沉淀修改
从这个角度看，DSH 不是对 Pi 的否定。
它是在 Pi 所代表的开放扩展思路上，将“变化”进一步提升为运行时的核心抽象。
10. Harness 正在成为 Agent 的生长环境
如果说 Pi 的核心贡献，是把 Agent 从一个封闭产品变成一个可编程、可扩展的平台，那么 DSH 所探索的下一步，就是让 Agent 逐渐成为自身能力变化的参与者。
它不只是使用已有工具，还可以：
但自生长不等于无限增加。
一个只会安装新工具、写入新记忆、叠加新策略的 Agent，最终只会被自己积累的复杂度拖垮。
真正可持续的生长，必须同时包含：
发现
→ 生成
→ 激活
→ 验证
→ 选择
→ 清理
→ 沉淀
→ 淘汰
Pi 回答了：
如何让 Agent Harness 可以被持续扩展？
DSH 则进一步追问：
如何让 Agent 安全地参与自身能力的形成？
从 Pi 到 DSH，变化的不只是扩展机制，而是 Harness 的角色。
它正在从承载工具与插件的工程框架，转变为支持能力试验、筛选、重组和沉淀的运行环境。
未来的 Agent Harness 可能不再只是模型与工具之间的连接层。
它还将成为 Agent 管理自身变化的基础设施：
只有当 Agent 既能增加能力，也能验证、回滚、清理和遗忘时，它才真正具备从「可扩展的软件」走向「可持续生长的系统」的可能。
以上。