一个Agent做完一个任务，把经验存进记忆库。下次遇到类似任务，它去记忆里搜索，找到最相似的那条，照着做。

这套流程听起来合理，但有个根本问题：任务不是单个事件，而是一串子任务的组合。把整条轨迹当成一条扁平记录存进去，就丢掉了子任务之间的关系。

HyperSkill提出了一种不同的记忆结构：超图。

超图解决了什么问题

现有Agent记忆系统大致分三代。第一代存原始轨迹，信息完整但噪声大；第二代提炼成工作流或洞察，泛化性好但丢失操作细节；第三代抽象成可复用的技能（skill），但每个技能被孤立存储，丢掉了它和其他技能的组合关系。

问题出在数据结构上。一条任务轨迹本质上是多个子任务和多个技能的n元关联——不是A和B的关系，而是A、B、C、D一起构成了这次成功。用向量数据库或普通图结构存，只能表示两两关系，组合信息被压扁了。

HyperSkill把记忆组织成超图（hypergraph）：节点分两类——子任务步骤和可复用技能；每条超边（hyperedge）连接一条轨迹涉及的所有子任务和技能，附带一个效用分数和经验教训。

这个设计直接解决了三个问题：超边保留了完整的组合上下文；技能节点被多条超边共享，检索时可以按共现频率排序，而不仅仅按语义相似度；基于图结构的质量加权传播可以合并冗余技能，同时考虑节点效用和邻域拓扑。

检索不是搜索，是结构匹配

HyperSkill的检索走了双路径：先在子任务级别查询（当前任务的第一步像什么），再在轨迹级别查询（整条任务像什么），然后按技能在检索到的轨迹中出现的频率排序。

这和传统的embedding相似度检索有本质区别。假设你做过三次"爬取网页→提取数据→写入数据库"的任务，每次用不同的具体技能。传统记忆会在三次轨迹中分别搜索，返回语义最接近的那一条。HyperSkill会识别出"爬取→提取→写入"这个子任务模式在三条轨迹中共同出现，并把那些跨轨迹反复成功的技能排在前面。

这种基于共现的排序是纯语义搜索做不到的，因为它依赖的是结构信号而非文本相似度。

记忆也得定期修剪

大多数Agent记忆系统只管加不管减。任务做完了就往库里塞一条，从来不删。时间一长，低质量的旧记忆淹没高质量的新记忆，检索效率持续下降。

HyperSkill引入了基于结构的维护机制：定期扫描超图，剪枝低效用节点，通过质量加权传播合并冗余技能。合并不是简单地删掉一条保留另一条，而是把两条技能的信息融合，权重由各自的效用分数和邻域结构决定。

这和数据库的compaction类似——写入的时候追求速度，后台定期整理碎片、合并同类项，保持查询效率。

在xBench、GAIA和WebWalkerQA三个基准上，搭配GPT-4o和Qwen3-30B-A3B，HyperSkill在十个记忆基线中全面领先，GAIA上最高提升11.51分，WebWalkerQA上提升11.18分。

和LycheeMemory对比

同在8月发表的LycheeMemory V2（哈工大深圳）走了另一条路：它聚焦压缩长期记忆的存储体积，用分层摘要和选择性遗忘来降低检索开销。两者并不矛盾——HyperSkill解决"存什么结构"，LycheeMemory解决"怎么控制规模"。一个理想的Agent记忆系统可能需要两者结合：用超图结构组织知识，用分层压缩控制膨胀。

源势AI观点

Agent记忆是个被低估的工程问题。大多数团队搭Agent时把精力放在提示词和工具调用上，记忆模块直接用一个向量数据库了事。但实际跑起来，Agent做得越多，记忆库越臃肿，检索质量越差——这和人类"经验越多反而越僵化"的困境异曲同工。

HyperPaper的超图方案在学术上漂亮，但工程落地有几个门槛：超边的维护成本随轨迹数指数增长，合并操作的延迟需要控制在在线可接受范围，效用分数的定义需要领域适配。对生产环境来说，可能不需要完整的超图——先用图数据库存技能共现关系，检索时加一层共现排序，就能拿到大部分收益。

---

来源：

1. HyperSkill: Self-Evolving LLM Agents via Hypergraph-Structured Skill Memory (arXiv:2608.16114, 2026年8月17日, Northwestern/USC/UIC)

2. LycheeMemory V2: Efficient Long-Term Memory for LLM Agents (arXiv:2608.12990, 哈工大深圳)

3. xBench/GAIA/WebWalkerQA基准测试框架