Agent Harness 会不会也迎来自己的「Debian 时刻」？

[kangkona]

最近一段时间，我一直在思考一个问题：

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

它是一个面向 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 安装：

curl -fsSL https://github.com/amplifthq/oh-my-dsh/releases/latest/download/install.sh | sh
omd setup
omd

也可以通过 npm：

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

在 DeepSeek Harness 社区的介绍：

https://github.com/deepseek-ai/deepseek-harness/discussions/3113

欢迎拍砖，尤其想听听大家对下面几个问题的看法：

1. Agent Harness 是否真的需要“发行版”这一层？
2. Skill 和 Plugin 的边界应该怎么划分？
3. 自进化系统里，哪些动作可以自动执行，哪些必须保留人工批准？
4. Eval 怎样设计，才能避免最后退化成“模型自己评价自己”？

[acidsweet]

很有意思