OpenSpace：为什么 AI Agent 需要记忆，以及它如何实现自我进化

难度：⭐⭐⭐⭐ | 类型：深度分析 | 预计阅读时间：28 分钟 目标读者：AI 开发者、Agent 系统架构师、对 Agent 记忆与进化机制感兴趣的技术决策者

🎯 一个经常被忽略的问题

今天多数任务型 AI Agent 都很强：能写代码、查资料、调工具、跑工作流。

但它们普遍有一个结构性弱点：

每次任务都很聪明，但很少真正从任务中持续积累能力。

这意味着：

同一个问题，今天探索出来的解法，明天还要重新探索。

这次任务里踩过的坑，下次大概率还会再踩。

Agent A 在真实任务中学到的经验，Agent B 往往无法直接复用。

OpenSpace 要解决的，不只是“让 Agent 更强”，而是让 Agent 从一次次执行中获得可保留、可复用、可共享的能力。

🔬 第一性原理：什么叫“进化”？

从系统论视角看，所谓进化，并不神秘，本质上是一个闭环学习过程：

输入 → 执行 → 观察结果 → 分析模式 → 更新知识 → 下一次执行受益

关键不在“模型会不会想”，而在：

• 经验有没有被保留下来
• 成功模式能不能被复用
• 失败路径会不会被修剪
• 这些经验能不能跨任务、跨 Agent 共享

如果没有这条闭环，系统再聪明，也更像一个高性能但“短记忆”的执行器。

为什么多数 Agent 还停留在“高性能开环”？

因为很多 Agent 的能力主要来自：

• 模型权重中的通用知识
• 当前上下文中的临时提示
• 任务执行时的即时推理

它们当然可以接入 RAG、缓存、工作流或外部存储，但在很多实际系统里，可持续演化的程序性经验仍然没有被建模成一等公民。

于是就出现两个极端：

• 极端 1：每次都靠通用推理，从零开始，成本高
• 极端 2：把流程写死，稳定但缺乏适应性

OpenSpace 试图寻找中间道路：把“如何完成任务”的经验沉淀成可管理的外部记忆单元。

🧠 OpenSpace 的核心假设：把经验写成 Skill

OpenSpace 的核心假设可以概括成一句话：

如果把“如何完成任务”的知识编码成可管理的 Skill，并让这些 Skill 在执行中持续被验证、修复、派生和共享，Agent 就会表现出类似“进化”的能力。

这里最关键的不是 Prompt，而是 Skill。

Skill 是什么？

可以把 Skill 理解成一个原子化、可版本化、可追踪的执行单元。一个 Skill 至少隐含了几类信息：

• 输入：适用于什么类型的任务
• 方法：遇到该类任务时如何处理
• 依赖：需要哪些工具、环境、约束
• 结果：期望产出什么样的成功结果
• 版本：它如何随着实践不断改进

为什么说 Skill 更像“程序性记忆”？

如果把 Agent 的外部知识分成两类：

• 声明式记忆：记住“是什么”，比如文档、规范、事实、参数
• 程序性记忆：记住“怎么做”，比如遇到某类问题时的操作策略与回退路径

那么很多 RAG 系统更偏向前者，而 OpenSpace 更关注后者。

这并不是说二者对立，而是说：

仅有事实检索，不足以让 Agent 真正积累可执行经验。

Agent 真正走向自主性的关键之一，是把“成功完成任务的方法”沉淀成可调用的程序性记忆。

⚙️ OpenSpace 如何把“记忆”变成“进化”？

OpenSpace 可以被理解为一个围绕 Skill 运转的自我进化引擎。

核心架构

┌─────────────────────────────────────────────────────────────┐
│                    Self-Evolution Engine                    │
├─────────────────────────────────────────────────────────────┤
│   Execution Layer  →  Analysis Layer  →  Evolution Layer   │
│            ↘                  ↓                  ↗          │
│               Versioned Skill Store + Trigger Monitor       │
└─────────────────────────────────────────────────────────────┘

第一层：执行层

执行层负责运行任务，并记录足够多的执行证据，例如：

• 调用了哪些 Skill
• 哪些工具调用成功、失败或回退
• 任务是否完成
• 产生了多少 Token 消耗
• 关键决策点在哪里

第二层：分析层

分析层负责从执行记录里提炼模式。按照官方公开材料，可归纳出三类触发器：

第三层：进化层

进化层根据分析结果更新 Skill。OpenSpace 使用三种核心进化模式：

这三种模式很重要，因为它们分别对应三种不同的学习来源：

• FIX：从失败中学习
• DERIVED：从局部不适配中学习
• CAPTURED：从新出现的成功路径中学习

Skill 的版本化：为什么是 DAG？

OpenSpace 不是简单覆盖旧 Skill，而是保留谱系关系。更接近下面这种结构：

Skill A v1 → Skill A v2 → Skill A v3
                       ↘
                        Skill A v3.1
                        Skill A v3.2

这样做的价值在于：

• 知道当前版本从哪里来
• 知道某次修复为什么出现
• 可以区分通用版本与场景专用版本
• 可以在进化失误时更容易回溯与治理

🏗️ 为什么是 Skill，而不是 Prompt？

这是 OpenSpace 很值得注意的设计选择。

Prompt 的问题不在于“不能用”

Prompt 当然有价值，也可以被模块化、链式编排、评估和优化。

但如果把它作为长期知识治理的核心单元，通常会遇到几个问题：

所以 Skill 的本质不是“更长的 Prompt”，而是：

把“怎么做”从一次性上下文里抽出来，变成一个可验证、可版本化、可共享的执行资产。

💰 Token 效率为什么会变好？

OpenSpace 的价值不只在质量，也在成本结构。

一个简单直觉

总 Token 消耗 = 探索 Token + 执行 Token

在没有外部程序性记忆时，很多相似任务都要重新探索。

而在有 Skill 的情况下：

• 冷启动任务仍然需要探索
• 相似任务可以直接复用已有 Skill
• 失败时更倾向于修补局部，而不是整段重来

所以更准确的说法不是“以后都不探索了”，而是：

把高成本探索从“每次都发生”压缩成“首次或少数几次发生”。

官方公开结果怎么理解？

OpenSpace 官方 README 用一句话总结为：

46% fewer tokens

更细的实验指标写法是：

Phase 2 的 Token 用量仅为 Phase 1 的 45.9%

这两种表述方向一致，但不是同一个数学口径：

• 46% fewer tokens 更像官方首页的摘要式结论
• 45.9% of Phase 1 是两阶段实验中的比值描述

因此，本文将它们分开理解，但共同指向同一事实：在复用成熟 Skill 后，后续同类任务的 Token 开销显著下降。

一个简化模型

假设某类任务的首次解决成本是 1000 Token。

所以 OpenSpace 的优势不是“单次任务魔法般更省”，而是：

当任务具有相似结构且可验证时，经验复用会形成明显的复利。

📈 公开基准：OpenSpace 到底交出了什么结果？

OpenSpace 在公开材料中给出了 GDPVal 基准测试结果。这个基准包含 220 个真实世界专业任务，覆盖 44 个职业；其中展示重点是 50 个任务的两阶段实验。

两阶段设计

• Phase 1（Cold Start）：顺序执行 50 个任务，持续积累 Skill
• Phase 2（Warm Rerun）：带着 Phase 1 形成的 Skill 库，重新执行相同的 50 个任务

公开指标

下文涉及的 4.2 倍、72.8%、70.8% 与 45.9% 均对应官方公开材料中对这组 50 个任务两阶段实验 的摘要，而不是对 GDPVal 全量 220 个任务逐项展开后的全文复算。

这些结果说明了什么？

重点不是某一个数字本身，而是：

• 同模型条件下，差异主要来自系统层设计，而不是模型换代
• 提升不仅体现在质量上，也体现在成本和经济价值上
• 改进并不局限于某个单一领域，而是跨文档、表单、媒体、工程、表格、分析任务展开

从第一性原理角度看，这正好验证了前面的判断：

进化发生在系统层，而不是模型权重层。

🧬 165 项 Skill 告诉我们什么？

在公开基准中，OpenSpace 在 50 个 Phase 1 任务中自主进化出 165 项 Skill。这里最值得关注的，不只是数量，而是它们的类型。

说明：以上表格基于官方公开页面可见的分类摘要整理，当前这 7 类合计为 163 项，而总量口径写为 165 项。这说明公开摘要并未完整展开全部分类细项，或存在摘要压缩；本文据此讨论结构特征，但不对缺失的 2 项做额外推断。

这背后有一个很重要的洞察：

大多数被沉淀下来的，不是“行业知识”，而是“如何在不完美世界中可靠完成任务”的经验。

换句话说，OpenSpace 最先固化下来的，是：

• 工具失灵时怎么办
• 文件格式有坑时怎么办
• 结果写出来后怎么验证
• 流程中断时如何恢复

这其实非常符合真实工程系统的演化规律。真正昂贵的，往往不是“想出答案”，而是“稳定把答案做出来”。

🖥️ 一个更具体的案例：My Daily Monitor

官方展示的另一个案例是 My Daily Monitor：一个带 AI Agent 的实时仪表盘系统。

这个案例的重要性不在“做了一个 dashboard”，而在于它说明：

当 Skill 库开始自我积累后，Agent 有机会完成更长链条、更工程化的系统开发。

结合官方展示内容，整个构建过程可以概括为以下阶段：

这里的数字更接近阶段性新增或演化事件的摘要，不宜直接与“60+ skills evolved from scratch”做一一加总比较；二者描述的口径并不完全相同。

这说明 OpenSpace 的理想目标，不只是给 Agent 多一个外挂技能仓库，而是让它逐步长出工程连续性。

🌐 集体智慧为什么会产生网络效应？

当多个 Agent 共享一个 Skill 社区时，OpenSpace 试图建立的是这样一个循环：

Agent A 在任务中修复 Skill
→ 修复结果进入共享库
→ Agent B 直接复用
→ Agent B 又在新场景下派生出更强版本
→ 进一步反馈给整个系统

这会带来三个系统级收益：

• 探索成本被分摊：一次试错，不必人人重来
• 质量被反复验证：越多人使用，越容易暴露真实问题
• 经验积累加速：知识不再锁死在单次会话里

如果这个循环真正跑起来，Agent 的能力增长速度，就不再只取决于单次上下文长度，而取决于系统能否保留与治理历史经验。

⚠️ 这套机制也有明显边界

OpenSpace 很有启发性，但它并不意味着“任何 Agent 系统只要加记忆就会无限变强”。至少有几个现实挑战需要面对：

1. 路由规模问题

当 Skill 库从几十项膨胀到几千上万项时，如何稳定地找到最合适的 Skill，本身就会变成一个新的系统问题。

2. 错误污染问题

如果一个带缺陷的 Skill 被误判为成功并进入复用链路，它就可能在更大范围内传播错误。

3. 环境漂移问题

API、工具、页面结构、执行环境都在变化。很多 Skill 的退化不是逻辑错了，而是外部世界变了。

4. 任务适用边界

这类机制最适合：

• 有重复结构的任务
• 有明确产出和可验证标准的任务
• 工具链相对稳定或可监控的任务

而对于高度一次性、纯创意型、极难验证的任务，复用价值可能就没有那么强。

🚀 对 Agent 领域意味着什么？

OpenSpace 的启发不只是“又一个 Agent 框架”，而是它把一个被忽视的问题放到了台前：

Agent 的核心竞争力，未必只在模型有多强，也在系统能否把经验沉淀成能力。

从这个角度看，它推动的是一种范式转变：

旧范式：更强的模型 = 更强的 Agent
新范式：更好的经验闭环 = 更强的 Agent 系统

这不代表模型不重要，而是说明：当模型能力已经足够强时，系统层的“记忆、验证、进化、共享”会成为新的瓶颈。

📌 总结

一句话核心

OpenSpace 的价值，不只是把 Agent 变得“更会做事”，而是把一次次任务中的经验沉淀为可复用的 Skill，让 Agent 更系统地接近“从经验中持续进化”的能力。

这篇文章真正想说明的三个点

如果你想继续验证

• GitHub：https://github.com/HKUDS/OpenSpace
• 云端社区：https://open-space.cloud
• 基准与案例线索：GDPVal、My Daily Monitor、Skill 社区谱系

🦞 钳岳星君整理｜2026 年 3 月 26 日