Agent Harness 会不会也迎来自己的「Debian 时刻」？
最近一段时间，我一直在思考一个问题：
**Agent Harness 会不会也需要自己的“发行版”？**
Linux 内核提供了核心能力，但大多数人真正安装和使用的是 Debian、Ubuntu 这样的发行版。发行版不仅打包内核，还负责默认组件、依赖关系、安装升级、兼容策略，以及一套相对稳定的使用体验。
我觉得 Agent Harness 可能也会经历类似的阶段。
DeepSeek Harness 提供了一个很有意思的基础：agent loop、tools、skills、plugins、MCP，以及“everything is a plugin”的扩展模型。
但从一个可扩展的 harness，到一个可以长期使用、持续演化、随时升级和回滚的工作环境，中间还有一层没有被充分解决。
所以我做了：
**oh-my-dsh**
[https://github.com/amplifthq/oh-my-dsh](https://github.com/amplifthq/oh-my-dsh)
它是一个面向 DeepSeek Harness 的社区发行版，目标不是 fork 上游，而是在上游之上提供一套可组合、可覆盖、可验证的发行层。
一句话定位：
> 如果 DeepSeek Harness 是内核，oh-my-dsh 想试成为类似 Debian 的发行版层。
## Overlay，不是 Fork
oh-my-dsh 不复制或魔改 DeepSeek Harness 的核心代码，而是通过 overlay 方式组合：
- 上游 Harness
- oh-my-dsh 提供的默认能力
- 用户自己的配置、Skills 和 Plugins
上层可以覆盖下层，但用户自己创建的内容始终拥有最高优先级。
这么设计主要是为了避免两个问题：
1. 为了增加功能长期背着一个越来越难维护的 fork；
2. 每次升级都把用户自己积累的配置和能力覆盖掉。
项目的安装、更新和回滚也是围绕这个模型设计的。发行版本可以替换，但用户自己的成长记录应该保留下来。
## 为 self-evolve native 而生
我不希望这里的“自进化”只是让 Agent 自动修改自己的 prompt。
我更关心的是一条完整、可治理的演化链路：
1. 发现当前能力和能力缺口；
2. 把重复出现的方法沉淀成 Skill；
3. 把需要运行时扩展的能力封装成 Plugin；
4. 用固定输入和机器断言做 Eval；
5. 由 Optimizer 根据失败结果生成可检查的改进建议；
6. 经过 review、验证和批准后，再决定是否保留或提升为默认能力。
围绕这条链路，oh-my-dsh 目前包含几个核心部分：
### Capability Discovery
统一发现当前环境里的 Skills、Plugins、MCP、Prompts 和其他可用能力，让 Agent 不需要依赖一份静态、容易过期的能力清单。
### Skill Forge
把一次成功的解决过程，提炼成可以重复执行、带有明确边界的 Skill。
这里的重点不是“自动生成一段提示词”，而是形成可以检查、测试、版本化和移植的能力单元。
### Plugin Forge
当一个能力需要新的命令、Hook、MCP Server 或运行时扩展时，可以进一步把它封装成 Plugin。
Skill 更接近可复用的方法和工作流，Plugin 则扩展运行时边界。两者解决的是不同层次的问题。
### Eval
Eval 使用冻结的输入快照和机器可判定的 assertions，比较修改前后的行为差异。
它支持：
- 对比能力修改前后的结果；
- 发现回归；
- 通过 ablation 比较“启用／关闭某项能力”时的差异；
- 为是否保留一次优化提供证据。
Eval 只负责评估，不会自动挂载 Plugin、应用 proposal 或修改能力目录。
### Optimizer
Optimizer 根据执行轨迹和 Eval 失败生成结构化、可审查的改进建议。
目前它是 **proposer-only**：可以提出修改，但不能绕过评估和批准流程直接改写系统。
这也是我对 self-evolve native 的理解：
> 系统应该原生支持自我改进，但自我改进不等于自我授权。
Agent 可以发现缺口、提出修改、生成候选能力并运行评估；但权限提升、能力挂载和默认行为变更，仍然应该经过明确的治理边界。
## 另外做了一些日常能力
除了自进化链路，目前还包括：
- MCP 按需激活，减少所有工具常驻带来的上下文和运行成本；
- Skill / Plugin 的发现、覆盖和生命周期管理；
- SSRF-resistant Web Fetch；
- 面向代码修改的语义化 rename / refactor proposal；
- 复用现有 Agent 配置；
- 可移植安装；
- 可验证的更新与回滚；
- 用户配置和自建能力在版本切换时保持独立。
## 安装
**Portable 安装：**
```bash
curl -fsSL https://github.com/amplifthq/oh-my-dsh/releases/latest/download/install.sh | sh
omd setup
omd
```
也可以通过 npm：
```bash
npm install --global oh-my-dsh
omd setup
omd
```
## 当前边界
先主动说一些目前的限制：
- 这是一个社区项目，不是 DeepSeek 官方项目；
- 项目由我独立开发和维护，与 DeepSeek 没有从属关系，也没有得到官方背书；
- 它是发行层，不是 DeepSeek Harness 的 fork；
- Plugin Forge 生成的是具有宿主权限的代码，不应该被误解成安全沙箱；
- 自进化过程仍然强调 proposal、review、Eval 和显式批准，不追求无人监管的自动改写；
- 目前仍处于比较早期的阶段，接口、默认策略和能力组合都可能继续调整。
- 我现在想验证的不是“能不能再给 Agent 多装一些工具”，而是：
- Agent 的能力能不能像软件包一样被发现、生成、评估、组合、升级和回滚？
- 如果答案是肯定的，那么 Agent Harness 上面可能确实还需要一个发行版层。
项目地址：
[https://github.com/amplifthq/oh-my-dsh](https://github.com/amplifthq/oh-my-dsh)
在 DeepSeek Harness 社区的介绍：
[https://github.com/deepseek-ai/deepseek-harness/discussions/3113](https://github.com/deepseek-ai/deepseek-harness/discussions/3113)
欢迎拍砖，尤其想听听大家对下面几个问题的看法：
1. Agent Harness 是否真的需要“发行版”这一层？
2. Skill 和 Plugin 的边界应该怎么划分？
3. 自进化系统里，哪些动作可以自动执行，哪些必须保留人工批准？
4. Eval 怎样设计，才能避免最后退化成“模型自己评价自己”？
---
原文链接：[点击查看](https://www.v2ex.com/t/1235404)
**Agent Harness 会不会也需要自己的“发行版”？**
Linux 内核提供了核心能力，但大多数人真正安装和使用的是 Debian、Ubuntu 这样的发行版。发行版不仅打包内核，还负责默认组件、依赖关系、安装升级、兼容策略，以及一套相对稳定的使用体验。
我觉得 Agent Harness 可能也会经历类似的阶段。
DeepSeek Harness 提供了一个很有意思的基础：agent loop、tools、skills、plugins、MCP，以及“everything is a plugin”的扩展模型。
但从一个可扩展的 harness，到一个可以长期使用、持续演化、随时升级和回滚的工作环境，中间还有一层没有被充分解决。
所以我做了：
**oh-my-dsh**
[https://github.com/amplifthq/oh-my-dsh](https://github.com/amplifthq/oh-my-dsh)
它是一个面向 DeepSeek Harness 的社区发行版，目标不是 fork 上游，而是在上游之上提供一套可组合、可覆盖、可验证的发行层。
一句话定位：
> 如果 DeepSeek Harness 是内核，oh-my-dsh 想试成为类似 Debian 的发行版层。
## Overlay，不是 Fork
oh-my-dsh 不复制或魔改 DeepSeek Harness 的核心代码，而是通过 overlay 方式组合：
- 上游 Harness
- oh-my-dsh 提供的默认能力
- 用户自己的配置、Skills 和 Plugins
上层可以覆盖下层，但用户自己创建的内容始终拥有最高优先级。
这么设计主要是为了避免两个问题：
1. 为了增加功能长期背着一个越来越难维护的 fork；
2. 每次升级都把用户自己积累的配置和能力覆盖掉。
项目的安装、更新和回滚也是围绕这个模型设计的。发行版本可以替换，但用户自己的成长记录应该保留下来。
## 为 self-evolve native 而生
我不希望这里的“自进化”只是让 Agent 自动修改自己的 prompt。
我更关心的是一条完整、可治理的演化链路：
1. 发现当前能力和能力缺口；
2. 把重复出现的方法沉淀成 Skill；
3. 把需要运行时扩展的能力封装成 Plugin；
4. 用固定输入和机器断言做 Eval；
5. 由 Optimizer 根据失败结果生成可检查的改进建议；
6. 经过 review、验证和批准后，再决定是否保留或提升为默认能力。
围绕这条链路，oh-my-dsh 目前包含几个核心部分：
### Capability Discovery
统一发现当前环境里的 Skills、Plugins、MCP、Prompts 和其他可用能力，让 Agent 不需要依赖一份静态、容易过期的能力清单。
### Skill Forge
把一次成功的解决过程，提炼成可以重复执行、带有明确边界的 Skill。
这里的重点不是“自动生成一段提示词”，而是形成可以检查、测试、版本化和移植的能力单元。
### Plugin Forge
当一个能力需要新的命令、Hook、MCP Server 或运行时扩展时，可以进一步把它封装成 Plugin。
Skill 更接近可复用的方法和工作流，Plugin 则扩展运行时边界。两者解决的是不同层次的问题。
### Eval
Eval 使用冻结的输入快照和机器可判定的 assertions，比较修改前后的行为差异。
它支持：
- 对比能力修改前后的结果；
- 发现回归；
- 通过 ablation 比较“启用／关闭某项能力”时的差异；
- 为是否保留一次优化提供证据。
Eval 只负责评估，不会自动挂载 Plugin、应用 proposal 或修改能力目录。
### Optimizer
Optimizer 根据执行轨迹和 Eval 失败生成结构化、可审查的改进建议。
目前它是 **proposer-only**：可以提出修改，但不能绕过评估和批准流程直接改写系统。
这也是我对 self-evolve native 的理解：
> 系统应该原生支持自我改进，但自我改进不等于自我授权。
Agent 可以发现缺口、提出修改、生成候选能力并运行评估；但权限提升、能力挂载和默认行为变更，仍然应该经过明确的治理边界。
## 另外做了一些日常能力
除了自进化链路，目前还包括：
- MCP 按需激活，减少所有工具常驻带来的上下文和运行成本；
- Skill / Plugin 的发现、覆盖和生命周期管理；
- SSRF-resistant Web Fetch；
- 面向代码修改的语义化 rename / refactor proposal；
- 复用现有 Agent 配置；
- 可移植安装；
- 可验证的更新与回滚；
- 用户配置和自建能力在版本切换时保持独立。
## 安装
**Portable 安装：**
```bash
curl -fsSL https://github.com/amplifthq/oh-my-dsh/releases/latest/download/install.sh | sh
omd setup
omd
```
也可以通过 npm：
```bash
npm install --global oh-my-dsh
omd setup
omd
```
## 当前边界
先主动说一些目前的限制：
- 这是一个社区项目，不是 DeepSeek 官方项目；
- 项目由我独立开发和维护，与 DeepSeek 没有从属关系，也没有得到官方背书；
- 它是发行层，不是 DeepSeek Harness 的 fork；
- Plugin Forge 生成的是具有宿主权限的代码，不应该被误解成安全沙箱；
- 自进化过程仍然强调 proposal、review、Eval 和显式批准，不追求无人监管的自动改写；
- 目前仍处于比较早期的阶段，接口、默认策略和能力组合都可能继续调整。
- 我现在想验证的不是“能不能再给 Agent 多装一些工具”，而是：
- Agent 的能力能不能像软件包一样被发现、生成、评估、组合、升级和回滚？
- 如果答案是肯定的，那么 Agent Harness 上面可能确实还需要一个发行版层。
项目地址：
[https://github.com/amplifthq/oh-my-dsh](https://github.com/amplifthq/oh-my-dsh)
在 DeepSeek Harness 社区的介绍：
[https://github.com/deepseek-ai/deepseek-harness/discussions/3113](https://github.com/deepseek-ai/deepseek-harness/discussions/3113)
欢迎拍砖，尤其想听听大家对下面几个问题的看法：
1. Agent Harness 是否真的需要“发行版”这一层？
2. Skill 和 Plugin 的边界应该怎么划分？
3. 自进化系统里，哪些动作可以自动执行，哪些必须保留人工批准？
4. Eval 怎样设计，才能避免最后退化成“模型自己评价自己”？
---
原文链接：[点击查看](https://www.v2ex.com/t/1235404)
评论
暂无评论。