过去一段时间，Agent 生态的主要叙事一直是“能力增加”：模型更强、工具更多、Skill 更丰富。
但当能力数量真正增长起来，另一个问题会很快出现：这些 Skill 由谁管理？
可以把 Agent 的 Skill 库想成一间不断扩张的工具房。
工具越多，理论上能完成的任务越多；可真正工作时，如果找不到合适工具、选错版本、无法判断效果，或者更新后没有回退路径，工具数量反而会增加不确定性。
HKUDS 开源的 OpenSpace 正面处理了这个问题。它把自己定位成 AI Agent 的 Skill Management Layer，试图把 Skill 的检索、评估、分享和演化放到同一个生命周期中。
一、Retrieve：先解决“该用哪一个”
Skill 少的时候，重点是“有没有”。Skill 多起来以后，重点会变成“当前任务应该用哪一个”。
OpenSpace 的检索思路不是把所有 Skill 一次性塞给 Agent，而是先根据任务需要缩小范围，再选择适合的能力。
它对应的是一个很现实的工程问题：能力库越大，选择成本和上下文成本越不能忽略。
二、Evaluate：不要只相信说明，要看真实任务证据
这是 OpenSpace 最值得关注的部分之一。
一个 Skill 被检索到，不代表它真正被使用；被调用，也不代表任务完成。OpenSpace 把被选中、实际调用、任务结果和 fallback 等记录作为质量上下文。
这套思路的重要性在于，它把“这个 Skill 好不好”从一句主观评价，推进到可以被追踪的任务证据。对团队来说，这比只维护一个描述文件或静态评分更接近真实使用情况。
三、Share：验证过的能力才值得复用
Skill 的价值不应该永远锁在某台机器或某个 Agent 里。但复用的前提不是“它已经被创建”，而是“它在任务中被验证过”。
只有把能力、证据和版本关系保留下来，团队才有机会判断：哪些 Skill 可以共享，哪些仍需观察，哪些只适合某个局部场景。
四、Evolve：可以更新，但必须能追溯
Skill 不会永远保持不变。模型升级、接口变化、任务类型变化，都可能让原来的实现失效。
OpenSpace 强调 provisional 状态、证据、验证和版本历史：先保留变化记录，再决定是否接受更新；出现问题时，也要知道改了什么、为什么改、能不能退回上一版。
这不是鼓励 Skill 自己“随意进化”，而是给演化增加治理边界。
五、local-first 的边界
OpenSpace 还强调 local-first。按项目说明，云端可以用于发现，Skill 明确导入本地后再执行和复用，也支持私有部署。
这不意味着所有外部模型、接口和工具都天然不传数据。它真正解决的是另一层问题：Skill 何时进入本地、由谁执行、如何复用，边界更加明确。
六、从能力供给走向能力治理
OpenSpace 现在仍是一个需要继续观察和验证的开源项目。本文没有独立安装或性能复测，也不能据此断言它会成为行业标准。
但它反映出的方向值得重视：Agent 生态正在从“能力供给”进入“能力治理”。
未来真正影响 Agent 稳定性的，可能不只是模型有多强、Skill 有多少，还包括四个更具体的问题：
- 需要时能不能找到正确的 Skill；
- 是否有真实任务证据证明它可靠；
- 验证过的能力能不能安全复用；
- 更新出错时能不能追溯和回退。
只追着安装更多 Skill，已经不够了。建立一套判断和治理方法，可能才是下一步。
本文基于 HKUDS/OpenSpace 官方 GitHub 整理，核验日期为 2026-08-11。“Agent 生态从能力供给走向能力治理”为作者判断，不是项目方承诺。