标签归档：DSH

从 Pi 到 DSH：Agent Harness 如何从「可扩展」走向「自生长」

大模型能力持续提升之后，Agent 系统的竞争焦点正在发生变化。

过去，我们主要关心模型能不能理解任务、调用工具、编写代码。现在，更重要的问题逐渐变成：模型之外的系统，能否为 Agent 提供一个可以持续变化的运行环境？

这个运行环境通常被称为 Agent Harness。

Harness 负责把模型、提示词、工具、记忆、上下文、权限和外部环境连接起来。它决定模型能够看到什么、调用什么、保存什么，以及一次行动会产生怎样的系统影响。

从这个角度看，Agent 的能力并不只来自模型，用一个公式来表达，大概如下：

Agent 能力
=
模型能力
× 上下文组织
× 工具系统
× 运行时结构
× 生命周期治理

如果 Harness 是固定的，那么即使模型越来越强，Agent 的能力边界仍然主要由开发者预先决定。

如果 Harness 可以扩展，用户和开发者就能不断为 Agent 增加工具、技能和工作流。

但如果我们希望 Agent 进一步具备「自生长」能力，仅仅提供扩展接口还不够。系统还必须允许 Agent：

  1. 发现自己的能力缺口；
  2. 生成或引入候选能力；
  3. 在运行时安全地激活这些能力；
  4. 验证变化是否有效；
  5. 在失败时完整回滚；
  6. 将成功经验沉淀为可复用组件；
  7. 淘汰已经失效或长期无用的能力。

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 产品通常倾向于内置更多功能：

  • 规划模式；
  • 子 Agent；
  • 权限确认；
  • MCP 集成；
  • 后台任务；
  • 长期记忆；
  • 沙箱；
  • Todo 系统。

Pi 选择了另一条路线：这些能力不一定需要成为内核的一部分，它们可以通过扩展或外部环境实现。

Pi 当前提供文件读取、文件修改、内容搜索和命令执行等内置工具，同时允许通过命令行配置工具集合，也允许 Extension 注册新的工具或覆盖现有工具。(pi.dev)

这种设计的意义把稳定的内核和变化的能力分开：

稳定部分：
模型调用、Agent Loop、会话、基础工具、扩展 API

变化部分：
工具、技能、上下文、工作流、权限策略、界面、模型路由

只要扩展接口足够开放，功能就不必全部固化在核心代码中。

2.2 Pi 的四类扩展资源

从 Harness 的角度看，Pi 的可扩展性主要体现在以下几个层面。

2.2.1 Extensions：改变运行时行为

Extension 是可以进入 Agent 运行时的代码模块。

它可以：

  • 注册工具和命令；
  • 监听工具调用；
  • 拦截或修改行为；
  • 改变上下文；
  • 切换模型；
  • 增加权限检查；
  • 实现自定义 UI；
  • 覆盖内置工具；
  • 连接外部系统。

因此，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 可以改变自己的能力结构：

  • 创建新工具；
  • 安装新组件；
  • 替换 Memory；
  • 修改上下文策略；
  • 调整模型 Router；
  • 增加权限规则；
  • 组合新的执行流程；
  • 卸载无效组件。
当前能力结构
    ↓
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 访问环境，那么系统就可以决定：

  • 哪些资源向它开放；
  • 哪些能力只读；
  • 哪些调用需要权限；
  • 哪些状态不能跨组件共享；
  • 哪些操作只能在 Sandbox 中执行。

因此，Context 不只是依赖注入，也是一种能力安全模型：

组件能做什么
≈
Context 向它暴露什么

4.2 Effect 与 Cleanup：让变化可以被撤销

当组件加入 Harness 时，通常会产生副作用。

例如：

  • 注册一个工具；
  • 添加一个事件监听器；
  • 打开数据库连接；
  • 启动后台任务；
  • 修改模型路由；
  • 向上下文注入内容；
  • 挂载文件目录；
  • 注册快捷键；
  • 创建缓存；
  • 改变权限策略。

这些变化可以统一理解为 Effect：

Component
    ↓
Effect
    ↓
Harness 状态发生变化

问题在于，大多数插件系统只强调如何创建 Effect，却没有把撤销 Effect 当作同等重要的能力。

于是，组件卸载后可能出现：

  • 工具仍然留在 Registry 中；
  • 事件监听器重复注册；
  • 后台任务继续运行；
  • 网络连接没有关闭；
  • 临时文件没有删除；
  • Context 中残留失效状态；
  • 新旧路由规则同时生效。

在 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 的组件并不是彼此孤立的。

如果依赖关系只是组件内部的隐式假设，运行时就无法回答：

  • 组件现在能否启动？
  • 它缺少什么能力？
  • 某个依赖消失后，哪些组件应该停用？
  • 替换一个 Provider 会影响哪些组件？
  • 哪些组件可以被安全卸载？
  • 一个候选组件是否与当前环境兼容？

Coeffects 用于显式表达组件所需的外部条件：

Effect：
组件对系统做什么

Coeffects：
组件需要系统提供什么

例如：

const vectorMemory = {
  coeffects: [
    "embedding-model",
    "vector-storage",
    "session-events"
  ],

  effect(context) {
    // 激活 Memory
    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 首先要判断自己缺少什么。

例如：

  • 当前没有访问某类数据的工具；
  • 现有 Tool 无法处理特定协议；
  • Memory 无法支持长期任务；
  • 当前模型不适合某类输入；
  • 缺少项目专用的验证流程；
  • 当前执行环境不满足安全要求；
  • 工具调用成本或延迟过高。

能力缺口不能只由「工具调用失败」判断。

它还可能来自：

  • 任务规划；
  • 运行指标；
  • 用户反馈；
  • 测试结果；
  • 历史失败记录；
  • 现有能力清单；
  • 环境变化。

因此，自生长的起点不是生成代码，而是：

目标要求
-
当前能力
=
能力缺口

4.6.2 第二阶段：生成或引入候选能力

识别缺口后，Agent 可以选择不同方式补齐能力：

  • 编写新的 Tool；
  • 生成新的 Skill；
  • 安装已有 Package；
  • 包装外部 API；
  • 组合已有组件；
  • 替换 Memory Provider；
  • 调整模型 Router；
  • 创建新的工作流；
  • 启动一个专用子 Agent；
  • 为现有组件增加适配层。

这里的关键词是「候选」。

Agent 生成的组件不能因为能够编译或加载，就自动成为系统的永久能力。

生成成功
≠
能力有效
≠
适合长期保留

4.6.3 第三阶段：在受控环境中激活

候选组件应该先进入受限 Context。

系统需要明确：

  • 它可以访问哪些目录；
  • 可以调用哪些网络服务；
  • 是否可以读取凭证；
  • 可以注册哪些工具；
  • 能否修改全局状态；
  • 资源消耗上限是多少；
  • 运行时间是否受限；
  • 哪些副作用必须登记。

这一点尤其重要，因为扩展代码通常拥有较高权限。

以 Pi 为例，其官方安全文档明确说明，内置工具和 Extension 默认继承启动 Pi 的进程权限；第三方 Package 可能执行代码或指示模型执行操作，因此需要代码审查，并在需要时依赖容器或虚拟化提供真正的隔离边界。(github.com)

如果 Agent 开始自行生成和加载组件，权限问题只会更加突出。

所以，自生长必须建立在受控运行时上，而不能建立在「默认信任所有新代码」之上。

4.6.4 第四阶段：验证、保留或回滚

候选能力激活后，系统需要对它进行验证。

验证可以包括：

  • 能否完成目标任务；
  • 是否通过单元测试；
  • 是否破坏已有功能；
  • 是否产生未声明的副作用；
  • 是否扩大了不必要的权限；
  • 是否降低了任务成本；
  • 是否提高了成功率；
  • 是否造成明显的上下文膨胀；
  • 是否与现有组件冲突；
  • Cleanup 是否完整。

验证结果通常有三种：

验证通过
    ↓
保留或固化

部分通过
    ↓
修改后重新试验

验证失败
    ↓
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 不断为自己增加工具和代码。

无限增加不是生长，而是熵增。

一个只会添加能力、不会清理能力的系统，最终会出现：

  • 工具数量不断膨胀；
  • 相似能力重复实现；
  • 组件版本相互冲突；
  • 权限范围持续扩大；
  • 上下文被大量描述占据；
  • 路由规则越来越难以理解；
  • 无效监听器和后台任务持续运行；
  • Agent 无法判断应该使用哪个工具；
  • 系统行为逐渐不可预测。

因此，自生长必须同时包含四种能力：

增加
+
选择
+
清理
+
遗忘

可以进一步表示为：

可持续生长
=
生成新能力
-
淘汰无效能力
+
重组已有能力

这也是 Cleanup 和生命周期管理的重要性所在。

真正成熟的 Agent 不仅要知道「我还需要什么」，还要知道：

  • 什么已经不需要了；
  • 什么正在产生负面影响；
  • 什么应该暂时停用；
  • 什么可以被更简单的组件替代；
  • 什么经验只适用于过去的环境。

遗忘不是生长的反面。

受控遗忘本身就是生长的一部分。

9. Pi 与 DSH 不是替代，而是演进

Pi 的价值在于证明了一件事：

Agent Harness 不需要是一个功能固定的封闭产品。

通过开放 Extension、Skill、Prompt 和 Package，Harness 可以被用户重新塑造，也可以让 Agent 辅助编写自身需要的扩展。

这已经比传统 Agent 产品向前迈出了一大步。

DSH 所代表的方向，则是在此基础上进一步抽象：

如果 Agent 可以创建新能力，那么这些新能力应该如何成为运行时的一等公民？

答案不能只是把更多代码放进扩展目录。

系统还需要：

  • 明确组件所处的 Context；
  • 显式声明组件依赖的 Coeffects；
  • 管理组件产生的 Effect；
  • 在组件退出时执行 Cleanup；
  • 根据环境变化重新计算能力拓扑；
  • 对候选能力进行验证；
  • 将有效能力沉淀下来；
  • 将失效能力安全淘汰。

因此，二者可以形成一种递进关系：

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 既能增加能力，也能验证、回滚、清理和遗忘时，它才真正具备从「可扩展的软件」走向「可持续生长的系统」的可能。

以上。