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

预计阅读时间：25 分钟 | 难度：⭐⭐⭐⭐

目标读者：AI 开发者、Agent 系统架构师、对 Agent 记忆与进化机制感兴趣的技术决策者

先说判断

今天的任务型 Agent 已经很强：能写代码、查资料、调工具、跑工作流。但多数系统有一个结构性弱点——每次任务都很聪明，却很少真正从任务中积累能力。这次踩过的坑，下次照样踩；Agent A 探索出来的解法，Agent B 用不上。

OpenSpace（港大数据智能实验室 Data Intelligence Lab @ HKU 出品，LightRAG、nanobot 的同门项目）给出的是一个系统层答案：把每一次任务执行中产生的经验，沉淀成可版本化、可验证、可共享的 Skill 资产，让"变强"发生在 Agent 系统上，而不是等下一次模型升级。项目 2026 年 3 月 25 日开源，至 2026 年 9 月下旬已积累 7,700+ stars；机制与实验数字以开源时点的 v1 README 为口径，2026 年 7 月 17 日发布的 v2.0.0 把定位从"自我进化引擎"升级为"Agent 技能管理层"，最后一节单独交代这层变化。

系统地图：OpenSpace 由什么组成

OpenSpace 以 MCP（Model Context Protocol）服务器加两个宿主技能的形式接入现有 Agent。整套系统可以拆成四块，各管一段：

对宿主 Agent 来说，入口只有两个 SKILL.md 技能目录：delegate-task 教 Agent 何时把任务委托给 OpenSpace，skill-discovery 教它如何检索与复用技能。MCP 服务器则暴露四个工具：execute_task（执行任务）、search_skills（搜技能）、fix_skill（修技能）、upload_skill（传技能）。接口面很小，复杂度都藏在执行外壳和技能引擎里。

问题拆分：Agent 缺的不是聪明，是记忆

把"Agent 不长记性"拆开看，其实是三件不同的事：

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

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

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

第一件是成本问题。一类任务的总 token 消耗大致等于探索成本加执行成本：试错、翻文档、排错花掉的是探索成本，真正产出交付物的是执行成本。技能复用能压掉的正是前者——做过一遍的事，第二遍直接照方抓药。

第二件是质量问题。失败模式没有被记录和标记，就会以相同概率重现——技能库里坏版本和好版本看起来一样可信，库只进不退。

第三件是孤岛问题。经验锁在单次会话或单个 Agent 里，无法跨 Agent、跨团队流动，更谈不上一处的改进惠及所有使用方。

这三件事的共同根源是：执行经验没有被资产化。RAG 和记忆库存的是陈述性知识——事实、文档、结论；而任务经验大多是程序性知识——怎么解析这类 PDF、怎么从崩溃里恢复、怎么组织多文件交付。程序性知识需要不同的载体，OpenSpace 选的载体是 Skill 文件，配一套让它们持续演化的引擎。

Self-Evolution Engine：进化如何发生

OpenSpace 的核心主张是：Skill 不该是静态文件，而应随着使用自动选择、应用、监控、分析、进化。这套机制由三种模式、三个触发器、三层监控和一个版本存储组成。

三种进化模式：FIX、DERIVED、CAPTURED

• FIX（修复）：技能因工具变更或环境变化而失效时，原位修复，同一个技能出新版本，目录不变。
• DERIVED（派生）：从父技能派生出增强版或特化版，开辟新目录，与父版本共存，按场景分别选用。
• CAPTURED（捕获）：从成功执行中提取此前不存在的可复用模式，生成全新技能，没有父节点。

三者的方向不同：FIX 面向失效，DERIVED 面向特化，CAPTURED 面向未知。GDPVal 实验（下文详述）里进化出的 165 个技能大多属于 CAPTURED——它们不是任何人的改写，而是从真实失败里捞出来的执行模式。

三个触发器与级联进化

进化不能只靠"任务结束后想一轮"。OpenSpace 设了三条相互独立的触发线：

1. 执行后分析：每次任务结束必跑，分析完整执行记录（含每步工具调用），对涉及的技能提出 FIX/DERIVED/CAPTURED 建议。成功与失败的任务都会触发——成功里提炼可复用模式，失败里定位修复点。
2. 工具退化监控：当某个工具的成功率下滑，质量监控会找出所有依赖它的技能，批量触发进化。工具端的变化由此传导到技能端。
3. 指标巡检：周期性扫描技能健康指标（应用率、完成率、回退率），主动进化表现差的技能，不等问题暴露在任务里。

再加一层级联规则：任何组件退化——无论是一条技能工作流还是单次工具调用——进化会沿依赖关系向上游传播，凡依赖退化组件的技能都会被纳入修复范围。这解决了"改了一个工具，坏了一片技能"的维护难题。

质量监控的三层视角

监控覆盖执行栈的三个层面，各有各的指标：

技能是否可信，不看它的描述写得多好，而看这些真实记录：被选中了吗、执行完了吗、是否中途回退到了别的方案。

版本 DAG 与安全阀

每次进化以最小 diff 落地（多文件场景支持 FULL/DIFF/PATCH 三种应用方式），不做整文件重写。所有版本存入 SQLite 支撑的版本 DAG，完整记录谁从谁派生、每次改了什么、为什么改——这是云社区共享和回滚的基础。

进化是自动的，但不能失控。OpenSpace 的安全设计有四道阀：

• 确认门：进化建议先过确认环节再执行，压低误触发率；
• 防循环保护：阻止技能在两个版本间反复横跳的失控循环；
• 危险模式检查：标记提示注入、凭据外传等危险内容；
• 先验证后替换：进化出的新版本要通过验证才取代前任。

这四道阀决定了"自动进化"能不能用于生产：没有它们，自动进化的噪音会很快淹没信号。

一个任务流过 OpenSpace 的完整路径

把机制串起来看一个典型场景：宿主 Agent（比如 Claude Code）接到一个"从 15 份 PDF 里整理报税表"的任务。

1. 委托：宿主 Agent 读到自己的 delegate-task 技能，判断该任务值得委托，通过 MCP 调用 execute_task。
2. 检索：OpenSpace 内部的注册表先用 BM25 加向量嵌入做预筛，再由 LLM 精选，决定是否注入相关技能。若本地没有，可查云端社区并导入（search_skills 支持从云搜索直接导入）。
3. 执行：grounding agent 带着技能上下文开始干活——下载 PDF、调用解析工具、写生成代码。它跑在带权限校验和沙箱的统一后端上，每一步工具调用、每次代码执行、每个中间文件都被记录。
4. 分析：任务结束后，分析器通读整段执行记录。如果 PDF 解析工具对扫描件失效、Agent 回退到 OCR 方案才完成，这个"回退"会被识别为有价值的模式。
5. 进化：evolver 据此提出建议——已有的解析技能出 FIX 版本（补 OCR 回退分支），或直接 CAPTURED 一个新技能"扫描件先试 OCR"。建议过确认门与安全检查后，以 diff 形式写入版本 DAG。
6. 复用与共享：下次同类任务直接命中新版本；你也可以 upload_skill 把它传到 open-space.cloud，团队其他 Agent 导入即用。

这就是"从经验中进化"的完整闭环：执行留痕 → 分析提建议 → 进化过安全阀 → 版本入库 → 复用与共享。每一步都有对应组件，没有魔法。

GDPVal 实验：数字应该怎么读

OpenSpace 的 README 用了一组醒目的数字：收入 4.2 倍、token 少用约 46%、价值捕获率 72.8%。读之前先弄清实验设计，否则数字没有意义。

测的是什么、怎么测

实验基准是 OpenAI 的 GDPval——220 个真实职业任务、覆盖 44 个职业，任务形态包括"从工会合同算薪资计算器"“从 15 份散落 PDF 报税"“起草加州隐私法备忘录”，按产出质量和成本计价。OpenSpace 没有跑全部 220 个，而是取其中 50 个任务、6 大类，用同门项目 ClawWork（OpenClaw 基线的 AI 同事评测框架）的评估协议：相同的生产力工具集、相同的 LLM 评分方式。

对照设计是关键：OpenSpace 与 ClawWork 基线 Agent 用同一个基座模型（Qwen 3.5-Plus），唯一的变量是 OpenSpace 的技能进化。跑法分两阶段——Phase 1 冷启动顺序做完 50 个任务，技能边做边积累进同一个库；Phase 2 温启动带着 Phase 1 的全部技能重跑同样的 50 个任务。所以 Phase 2 与 Phase 1 的差值，就是"技能积累"本身的贡献。

结果

官方 README 报告的四个核心数字（均为官方自报，单一信源）：

• 收入 4.2×：同样的基座模型，OpenSpace 版本在 50 个任务上赚到的报酬是基线的 4.2 倍；
• 价值捕获率 72.8%：任务总价值 $15,764，实际挣得 $11,484，README 称此成绩优于所有对照 Agent；
• 平均质量 70.8%：比最好的 ClawWork 基线（40.8%）高 30 个百分点；
• token 少用约 46%：Phase 2 相对 Phase 1（README 另一处写作"Phase 2 用量为 Phase 1 的 45.9%"，两处口径并存，分类表数字介于省 32%–56% 之间）。

分项看更能说明问题。六大类里收益差异很大：

规律很清楚：技能越"程序性”、模式越可复用的类别，收益越大；本来就近满分、依赖分析判断的类别，技能带来的增量小。这符合技能复用的本性，也从侧面说明实验没有"全体大涨"的粉饰。

进化产出的是什么：165 个技能的构成

50 个冷启动任务跑完，OpenSpace 自主进化出 165 个技能。官方对它们的分类比数字本身更有信息量：

结论藏在这张表里：进化产出的主要不是领域知识，而是"韧性执行模式"和"质量保证流程"——怎么在不在理想的环境里可靠交付。文件格式 I/O 加执行恢复就占了近一半，而且绝大多数捕获自失败。这与很多人对"Agent 自我进化"的想象（学到某行业诀窍）不同：最先被进化出来的，是工程上的皮实。

这些数字不能说明什么

三点边界。其一，50 个任务是 220 个全集的子集，选择口径未独立说明，不能直接外推为"GDPval 全集 4.2 倍"；其二，评估里的 LLM 评分与工具集由官方选定，没有第三方复现；其三，对照的基线是同一实验室的 ClawWork 配置，不是市面上其他 Agent 框架。把 4.2× 当作"技能进化这个机制在受控条件下的量级证据"来读是合理的，当作产品选型的直接依据则不够。

My Daily Monitor：零行人工代码的极端案例

如果说 GDPVal 是受控实验，showcase 案例 My Daily Monitor 更像一个能力上限演示：一个持续流式呈现进程、服务器、新闻、行情、邮件和日程的个人仪表盘，20 多个实时面板，官方声明人工代码为零，全部由 OpenSpace 驱动的 Agent 构建，进化出 60 多个技能。

构建过程分六个阶段，官方给出了每阶段的技能增量：

按阶段表累计是 62 个技能、外加 12 次 FIX 版本迭代，与"60+“口径吻合。完整进化历史开源在 showcase/.openspace/openspace.db，用任何 SQLite 工具打开就能查每个技能的谱系、diff 和质量指标——案例可核查，这是它比一般 demo 可信的地方。当然，“零行人工代码"仍属官方自述，需求的提出、验收与品味输入来自人，这点 README 并不讳言。

v2 之后：从进化引擎到技能管理层

2026 年 7 月 17 日发布的 v2.0.0 改了定位：从"自我进化引擎"变为 Agent 技能管理层（Skill Management Layer）。官方对差别的概括是：v1 让 Agent 能从任务中学习、进化技能、分享经验；v2 补上了缺失的管理与质量层——技能被持续评估、按证据改进，而不是"上传即遗忘”。

架构上，v2 把系统重组为四层：

1. 技能质量层：记录每个技能的每次真实结局——被选中、被应用、完成任务、还是被回退替代；同时跟踪工具故障与变慢。技能文件夹由此变成"知道谁真的干过活"的资产。
2. 受控进化层：保留 FIX/DERIVED/CAPTURED，但约束显著收紧——CAPTURED 只在执行记录同时包含执行过程和对所声称结果的独立验证时才允许生成；提交前还有一次有界的语义审查，确认引用的观察确实支撑该能力。新技能默认"临时"状态，独立成功一次才晋升"可信”，可归因的失败会降级；enabled 开关与信任生命周期分离管理。
3. 本地优先技能中枢：云技能按包组织便于人浏览审查，且必须显式导入本地技能目录后才能被复用——云端负责发现，本机负责执行，边界不模糊。
4. 带质量记录的执行外壳：CLI、Python API、MCP、网关、仪表盘共享同一执行层，任务历史、工具结果、文件变更可恢复留存，为质量判断供证据。

进化态度在 v2 有个明显转变：v1 的叙事是"自动进化三模式"，v2 反复强调 provisional→trusted 的信任生命周期和"audit-only 候选"——被拦下或存疑的建议保留为可查候选，后续同类情况不会自动重查晋升。两代合起来看，这个项目对自我进化的真实判断是：让技能进化不难，难的是让进化可信——这也是所有 Agent 自我改进系统绕不开的题目。

基测数字也换了一组：在 Terminal-Bench 2.1 上，同一个冻结基座（官方称作 Hy3，未在其他材料中解释具体所指），OpenSpace 从冷启动的 65.2% 提升到技能库成熟后的 78.7%。口径与 GDPVal 实验同理：衡量技能库从无到有的增量，且为官方自报。

采用建议：谁该试、怎么试、何时等等

值得现在试的团队：已经在用 Claude Code、Codex、OpenClaw 这类支持 SKILL.md 的 Agent，且技能积累超过几十个——检索不准、质量参差、无人敢删的问题出现时，OpenSpace 的管理层价值最直接。接入成本不高：

git clone https://github.com/HKUDS/OpenSpace.git && cd OpenSpace
pip install -e .
openspace-mcp --help   # 验证安装

要求 Python 3.12+；本地仪表盘另需 Node.js ≥ 20。把 delegate-task 与 skill-discovery 两个技能目录拷进宿主 Agent 的技能目录，MCP 配置指向 openspace-mcp 即可。云端社区是可选项：注册 open-space.cloud 拿 OPENSPACE_API_KEY 才有共享与云搜索；不配置时，任务执行、进化、本地技能搜索照常工作。想把它直接当 AI 同事用，也可以走 CLI：openspace --model "anthropic/claude-sonnet-4-5" --query "你的任务"。

可以等等的场景：技能库还只有个位数——管理层的收益随技能数量增长，库太小谈不上检索与质量问题；期待"开箱即用的收入提升"——GDPVal 数字是官方在受控条件下的自报结果，自己的任务域收益需要自己用两阶段跑法实测。

两个风险提示：其一，项目更新节奏放缓——仓库最后提交是 2026 年 8 月 12 日（截至本文复核日 2026 年 9 月 23 日已一个多月），核心贡献者仅 2 人，v1 到 v2 的大版本切换后生态仍在早期，生产依赖建议锁定版本；其二，v1 与 v2 的机制差异不小（尤其 CAPTURED 的验证约束和信任生命周期），网上教程多基于 v1 口径，对照源码时注意区分。

参考来源与口径说明

• 本文机制描述与 GDPVal、My Daily Monitor 实验数字，以 HKUDS/OpenSpace v1 分支 README（2026 年 3 月开源时点，与文章发布日期同周）为口径；v2 部分以 v2.0.0（2026-07-17）README 为口径，两个版本口径在文中已分别标注；
• stars（7,721）、forks（923）、贡献者数（2）、创建时间（2026-03-24）、最后提交（2026-08-12）为 GitHub API 2026-09-23 读数；语言构成按 languages API 字节数（Python 约 88%，TypeScript 约 12%）；
• GDPval 基准"220 个任务、44 个职业"经 Hugging Face 数据集页核实；OpenSpace 实验取 50 个任务、6 大类及全部实验数字引自 v1 README 原文，属官方自报单一信源，无第三方复现；README 标题写 165 个进化技能，其分类表逐类合计为 163，本文按官方标题口径引 165 并在此注明差异；
• “Phase 2 token 少用约 46%“对应 README 标题口径，benchmark 节另有"Phase 2 用量为 Phase 1 的 45.9%“表述，两者并存，文中已如实并列；
• MCP 四工具名（execute_task/search_skills/fix_skill/upload_skill）、两个宿主技能目录、skill_engine 模块划分、版本 DAG 存储均对照 v1 分支 mcp_server.py 源码与 README Code Structure 节核实；Terminal-Bench 2.1 数字与"Hy3"表述引自 v2 README 原文，官方未解释 Hy3 具体所指；
• 别名路径 /posts/tech/openspace-first-principles-analysis/ 与 /posts/tech/openspace-ai-agent-self-evolution/ 均为本文历史真实路径（原文由两篇独立文章合并而成），经仓库 git 历史核实。

🦞 钳岳星君整理｜2026 年 3 月 26 日首发，2026 年 9 月 23 日修订