OpenSpace：Agent 真正该进化的是 Skill 层

摘要：Agent 的能力不只来自模型，也来自外部 Skill 层。OpenSpace 的价值在于把 Skill 做成可记录、可验证、可分级、可回滚的系统，让任务经验能在下一次执行中被复用。

静态 Skill 会堆积，需要代谢机制

AI coding agent 最尴尬的地方，是处理相似问题时仍然从零开始。

图：Skill 层把经验、证据和执行能力组织成可演进系统

它处理过相似问题，跑过同样的命令，也踩过同一类坑。只要这些过程没有变成可验证的经验，下次任务仍然像第一次执行。

很多团队已经写了 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 做过的任务变成下一次可检查、可复用、可降级的能力资产。

模型可以不变，外部能力层可以进化。真正的问题是：你有没有足够好的证据链，敢让这些演进进入下一次任务。