摘要：Agent 的能力不只来自模型，也来自外部 Skill 层。OpenSpace 的价值在于把 Skill 做成可记录、可验证、可分级、可回滚的系统，让任务经验能在下一次执行中被复用。
静态 Skill 会堆积，需要代谢机制
AI coding agent 最尴尬的地方，是处理相似问题时仍然从零开始。
它处理过相似问题，跑过同样的命令，也踩过同一类坑。只要这些过程没有变成可验证的经验，下次任务仍然像第一次执行。
很多团队已经写了 SKILL.md、项目规则、slash command 和工作流说明。文件越积越多以后，新的问题会冒出来：
- 哪些 Skill 可靠
- 哪些已经过期
- 哪些只是写得完整，却没有实战证据
OpenSpace 讨论的正是这个问题。它不改模型权重，而是把 Agent 的外部能力层做成可以记录、验证、分级、回滚的系统。
Skill 数量少时，静态文件很有用。一个 SKILL.md 对应一类任务，Agent 读完后按步骤执行，效果直接。
数量一多，问题就变了。
| 现象 | 真正的风险 |
|---|---|
| 多个 Skill 同时命中 | Agent 不知道哪个更可信 |
| 工具接口或项目结构变化 | 旧步骤继续被执行，失败会重复出现 |
| 任务失败没有写回 Skill | 坏经验留在系统里，下次还会触发 |
| 新任务里出现可复用流程 | 没有沉淀机制，经验只停在会话里 |
| 外部共享 Skill 看起来完整 | 没有真实执行证据，不知道能不能用 |
静态 Skill 像一堆文档。文档能积累知识，但不会自己判断哪些内容该保留、修复、降级或退场。
可控演进发生在模型之外
谈 Agent 变强，很容易把答案压到模型上：更大的模型、更长的上下文、更强推理。
团队真正能稳定控制的，常常是模型之外的部分：项目规范、调试路径、发布流程、工具组合、失败案例、验收标准。这些内容不在模型权重里，却会直接影响 Agent 每次任务的表现。
OpenSpace 的核心判断是：Agent 的能力可以在 Skill 层演进。前提是经验不能只是文本，它必须带上证据、版本和信任状态。
一个可演进 Skill 系统至少需要四个对象：
| 对象 | 作用 |
|---|---|
| Evidence | 记录 Skill 是否被选中、是否执行、工具结果如何、任务是否完成 |
| Decision | 判断这次经验应该修复旧 Skill、派生新 Skill、捕获新 Skill，还是拒绝 |
| Trust state | 区分 candidate、provisional、trusted，失败后允许降级 |
| Lineage | 记录 Skill 从哪里来、为什么变化、变过几次 |
这些对象合在一起，才让经验沉淀从写笔记变成工程流程。
OpenSpace 用证据驱动 Skill 演进
OpenSpace 把自己定义为 Agent 的 Skill Management Layer。更贴近工程语境的说法是，它在做一层 SkillOps。
它的流程按证据推进：
关键是顺序：真实任务先发生，证据随后产生，演进建议再进入准入和验证。
候选不是正式 Skill。provisional 也不是永久可信。只有在后续独立任务中持续成功，它才应该升到 trusted。
如果运行在 audit_only 模式，流程会停在 decision 和 admission 记录，不进入 authoring、validation 和 commit。这对生产试点很重要。
三种演进动作：FIX、DERIVED、CAPTURED
OpenSpace 没有把所有经验都揉成自动学习。它把 Skill 演进拆成三类动作，每类都比较克制。
| 动作 | 解决的问题 | 适合场景 |
|---|---|---|
FIX | 修复已有 Skill | 步骤过时、工具参数错、前置条件漏写 |
DERIVED | 从父 Skill 派生窄场景 Skill | 原 Skill 太宽，某类任务需要独立流程 |
CAPTURED | 从任务轨迹捕获新 Skill | 某次成功任务产生了可复用方法，并有证据支撑 |
FIX 是补丁。Skill 原本方向没错，只是被工具升级、目录变化或流程调整打坏了。
DERIVED 是分叉。一个通用 Skill 反复遇到某类特殊场景时，与其继续往原文档里塞条件，不如派生一个更窄的新 Skill。
CAPTURED 最像从任务里长出新能力。它也最需要克制：一次任务成功，不代表可以直接沉淀为通用 Skill。源轨迹必须支撑它声称的能力。
生成 Skill 容易，建立信任更难
让模型写一个新的 SKILL.md 很容易。难的是，下一次任务敢不敢真的用它。
OpenSpace 的信任流转把这个问题拆开了：
这条链路的重点是可追溯。每次变化都要留下来源、证据和版本关系。
真实失败也不能只变成一句“下次注意”。它应该能触发降级、修复或候选审查。
OpenSpace 默认的 OPENSPACE_EVOLUTION_MODE 是 autonomous，这意味着它并不天然保守。生产环境里更合理的起点是 audit_only：先让系统记录证据和建议，再由人决定哪些演进可以进入正式流程。
OpenSpace 接管了证据来源，所以显得重
OpenSpace 不只是一个 Skill 文件夹管理器。为了拿到可信 evidence，它把任务执行也纳入了 Runtime。
| 模块 | 和 Skill 演进的关系 |
|---|---|
| MCP / CLI / Python API | 让宿主 Agent 或外部系统把任务交给 OpenSpace |
| Runtime Harness | 统一工作区、会话和任务生命周期 |
| Tool Pipeline | 记录工具调用、权限、失败和结果 |
| Session / Recording | 保存执行轨迹，支撑事后分析 |
| Dashboard | 展示候选、质量信号、lineage 和 workflow evidence |
| Cloud | 支持 Skill 发现和分享，但执行仍以本地为主 |
它的安全边界也要讲清楚：云端负责发现，本地负责执行，Skill 需要显式导入后才会复用。云端候选不会自动进入你的任务链路。
代价也在这里。OpenSpace 更像完整 Agent Runtime，而不是轻量插件。接入后，团队要维护执行环境、审查流程、Dashboard 和失败归因规则。
试点从窄 PoC 开始
如果团队只有十几个稳定 Skill，任务重复度也不高，手工维护可能就够了。
如果团队已经有成体系的 Agent、项目规则和重复任务，并且开始遇到“经验写了很多，但复用不稳”的问题，可以做一个窄 PoC：
- 接入
openspace-mcp和本地 Skill registry。 - 设置
OPENSPACE_CLOUD_MODE=off。 - 设置
OPENSPACE_EVOLUTION_MODE=audit_only。 - 选一组真实重复任务，观察检索、证据和候选质量。
- 人工批准少量
FIX、DERIVED、CAPTURED，再做 warm A/B。
PoC 要验证的重点，是经过人审批准的 Skill 演进，是否真的让后续任务更稳。验证重点不只是 OpenSpace 能不能跑起来。
项目方 README 给出的结果是：在相同冻结的 Hy3 backbone 下，Terminal-Bench 2.1 从 cold run 的 65.2% 提升到 warm run 的 78.7%。这个结果能说明方向有吸引力，但它不是通用承诺。每个团队都要拿自己的任务集验证。
结语
OpenSpace 最值得关注的地方，是把 Agent 做过的任务变成下一次可检查、可复用、可降级的能力资产。
模型可以不变，外部能力层可以进化。真正的问题是：你有没有足够好的证据链，敢让这些演进进入下一次任务。