AI Agent 干得越多，为什么还是不会变熟练？

心底的中国

今天的 AI Agent 已经能接工具、调 API、操作浏览器，也能跑越来越长的工作流。

但部署后的 Agent 还有一个更基础的问题，完成一百次任务之后，第一百零一次并不一定比第一次更熟练。

一次会话结束，任务过程散落在聊天记录、邮件、文档和系统日志里。即使把这些内容存进向量库，下次再检索出来，模型获得的也只是更多参考材料。它可能记得过去发生过什么，却不等于学会了专家为什么这样判断，更不等于这段经验已经变成模型下一次可以稳定调用的能力。

存储不是学习，检索也不是进化。

Alloomi 想补上两者之间缺失的反馈回路。它把这条路线概括成“模型＋应用”。应用层进入真实工作流，捕获任务过程、专家判断和结果反馈；模型层再从筛选后的经验中后训练，让新能力回到下一次交付。

先把“记得住”和“学得会”分开



这条技术路线可以拆成三个层次。

第一层是任务状态。Agent 必须知道同一个人、项目、文件和决定如何跨会话延续，哪些信息仍然有效，哪些已经被新证据推翻。

第二层是经验处理。系统要从真实任务中提取“上下文、决定、反馈”，筛掉低质量轨迹，保留值得学习的部分，并且能在学习效果变差时停止更新或回滚。

第三层才是模型能力。经过筛选的经验不能永远停在外部数据库里，而要通过后训练进入模型，使它在类似任务上减少重复教学，同时又不遗忘已经掌握的能力。

Alloomi 最近公开的两份文件，分别对应这条流程的前后两段。官方材料把它们称为技术报告，本文也按技术报告处理，不把它们包装成已经通过同行评审的论文。

• Holistic Context
  解决“长期工作状态怎样被持续维护”。
• Self-Evolving Agent
  解决“真实任务经验怎样进入一个受控的后训练流程”。
  

前者让 Agent 记得住，后者尝试让它学得会。两者结合，才构成“每完成一次交付，就获得一次成长”这句话背后的技术路线。

Holistic Context 维护长期工作状态



大多数 Agent 对上下文的处理仍然围绕窗口和检索展开。历史被切成片段，问题来了再找几段相似内容，拼回 Prompt。

这套方法适合查资料，却很难维护真实工作的状态。

同一客户的目标会变化，文件会产生新版本，旧决定只在特定阶段有效，新证据还可能推翻过去的结论。一个长期工作的 Agent 不仅要回答“以前说过什么”，还要知道“这句话是谁在什么项目里说的、现在是否仍然有效、后来为什么发生了变化”。

Holistic Context 因此把上下文定义为一份持续维护的工作状态，不再局限于当前窗口里的一段 token。报告把它拆成三个相互配合的机制。

• 适用范围归因。每条信息都带着任务、对话、渠道、人物和有效期等范围，来自不同会话的碎片被归到同一实体和时间线上。
• 分层遗忘与证据保留。过期信息可以退出当前检索，但不会被无痕删除；来源、替代关系和发生变化的时间仍然可以追溯。
• 带竞争关系的关联学习。共同被检索的信息会加强连接；冲突信息先并存竞争，只有证据足够时，新判断才取代旧判断。
  

记忆需要带着范围、时间、来源和修订历史。只追求“记得更多”，反而会让 Agent 更容易把过期信息和当前事实混在一起。

Self-Evolving Agent 把交付记录变成训练材料



记忆系统解决了工作状态，但它本身仍不会让模型变得更熟练。

Self-Evolving Agent 把一次任务抽象成上下文、决策和反馈三个元素。经过质量筛选后，这些任务轨迹进入持续更新的经验池，再推动一个由 LoRA 微调、跨任务经验回放和强教师能力蒸馏组成的后训练循环。

这三步分别回答三个问题。

• 新经验怎样低成本写进模型；
• 学新任务时怎样避免忘掉旧能力；
• 模型怎样避免只复读自己过去的错误。
  

报告还加入了 Engram X 和 MAPE 控制环。

Engram X 是接入 Transformer 残差流的稀疏记忆层，用来承载长尾经验；LoRA 更侧重跨经验的通用推理能力。MAPE 则负责监控、分析、规划和执行每一次更新，用奖励、校准误差和推理轨迹一致性共同决定新版本是否准入。

“自进化”仍然受外部约束。系统需要更强教师或专家标准提供参照，用留出的验证集检查更新效果，再通过版本准入和回滚机制限制错误积累。

报告对这条边界写得很清楚。目前的 20 轮 burn-in 只能提供经验性的回滚证据，不能证明模型能力会形式化地单调上升。能更新不等于每次更新都会更好。可部署的自进化系统必须同时回答“怎么学”和“学偏了怎么办”。

另一个复现边界来自教师模型。能力蒸馏阶段调用的是付费外部 Qwen3.7-Max API，报告明确说明，没有对应 API 访问就无法完整复现 Stage 3。换句话说，框架结构可以公开讨论，但报告中的完整训练实验还不是一条纯本地、纯开源的复现路径。

九项 benchmark，实际在验证三种不同能力



Alloomi 的官方总览把九项成绩列为领先结果，并分成三组。先看每组在回答什么问题，比平铺九个数字更容易理解。

• 记得住。LoCoMo（团队总览写作 LoCoMo-V2）、LongMemEval-S、BEAM。它们检查跨会话、跨时间和超长历史下，Agent 能否保持一致的工作状态。
• 学得会。CL-bench、CL-bench Life、Cont.L.Bench。它们检查 Agent 能否从上下文和任务轨迹中获得新能力，并在连续任务中减少遗忘。
• 做得成。JobBench、SWE-Bench-CL、GDPval-AA Normalized。它们把问题推进到职业任务、软件工程和高经济价值工作的交付结果。
  

这九项成绩不是同一种证据，不能只看成一张总榜。

在“记得住”这一层，Holistic Context 报告给出的 LongMemEval-S 和 LoCoMo 结果分别为 97.6% 和 97.4%；BEAM 在标称 128K、500K、1M 和 10M 历史规模下分别为 72.8%、75.7%、76.5% 和 67.0%。按标称档位计算，从 128K 扩大到 10M，历史规模增长约 78 倍，端点得分下降 5.8 个百分点。

第一档需要额外解释。报告把它列在 128K 栏，但附录说明来源是完整的 128K-scale 对话集，执行器采用 100K-token 窗口。公开 artifact 目前只包含这项捕获运行；500K、1M 和 10M 三档尚未在报告锚定的 OpenContext commit 下完成独立审计。

这些数字很强，但报告也明确写出了限制。所有 Holistic Context 结果都是单种子、单骨干模型的点估计；LoCoMo 只有 10 段对话；LongMemEval-S 与 LoCoMo 的逐题结果尚未随当前 artifact 发布；跨论文对照还采用了不同骨干模型和裁判配置。

所以，这组结果可以支持“这套组合机制在极长历史下具备可行性”，不适合写成严格的一对一胜负判定。

在“学得会”这一层，更值得关注的是同骨干模型对照。Self-Evolving Agent 在固定 Qwen3.6-35B-A3B 骨干的情况下，把 CL-bench 通过率从 FewShot 基线的 24.5% 提高到 47.6%，增加 23.1 个百分点。

另一组 R10 保留测试检查模型经历 10 个任务后，在 5 类技能上的能力保持。完整框架得到 51.3%，同骨干、无回放版本为 33.6%。这两组结果均基于 k=3 种子。因为骨干模型没有变化，它们比拿不同模型的排行榜成绩直接横比，更接近对后训练框架本身的检验。

报告还列出了 CL-bench Life 32.1%、Cont.L.Bench 32.6% 和 JobBench 57.5% 等外部榜单结果。这里也必须带着方法差异一起读。参数规模、训练数据和推理预算并不相同；JobBench 的 57.5% 还更换了裁判，报告把它定义为“更换裁判后仍保持”的观察，而不是同榜条件下的直接胜负。

SWE-Bench-CL 与 GDPval-AA Normalized 的 headline 结果目前出现在团队对外 benchmark 总览中，用来补足“连续软件工程”和“高经济价值职业交付”两类场景。其中，SWE-Bench-CL 在 Self-Evolving Agent 报告里还有另一组“无重训迁移”设置；GDPval-AA 则尚未在两份报告中展开完整方法。本文不把它们与已经展开的方法对照混成同一种证据强度。

把证据分层之后，更有说服力的部分反而更清楚。报告显示，控制骨干模型后，经验回放、教师蒸馏和 Engram X 仍然带来了可测量增量。

OpenContext 提供可检查的工程入口



两份技术报告之外，团队还开源了 Agent 上下文运行时 OpenContext。

开源代码不能证明 benchmark 数字成立，但它能把部分技术主张从“只能听团队描述”变成“外部可以执行和检查实现”。本次验证把仓库固定在 commit 63a5f636
，从干净副本开始安装、构建并运行 examples。

在 Windows 11、Node v22.18.0、pnpm 10.14.0 下，冻结锁文件安装完成；根目录构建覆盖 51/52 个 workspace project 并以退出码 0 结束；examples 的 API surface 冒烟检查得到 97 项通过、3 项跳过、0 项失败。


图 1｜本次实际运行结果。3 项跳过来自上游 CommonJS 依赖在纯 ESM 运行下的模块导入兼容问题，不计为通过，也不计为失败。验证范围仅限公开仓库的安装、构建和 examples 冒烟检查；Alloomi 九项 benchmark 仍以团队公开材料为依据。

构建通过只说明工程入口可用，还不足以验证记忆机制。因此，本次进一步直接调用构建产物里的确定性函数，用合成数据跑了 13 项定向断言。结果里有几处与报告叙事直接对应。

• owner scope 同时比较 userId、workspaceId 和 tenantId；跨用户、跨 workspace 或跨 tenant 的候选不会被视为同一 owner scope。本次检索用例中，跨 workspace 节点被标记为 out-of-owner-scope；
• 默认检索只返回当前范围内仍可见的事实，audit-only 节点被隐藏；旧代表节点进入该状态后，仍保留在生命周期计划中；
• 两条同属一个关系组、取值相冲突的合成记录，关系判断阶段先得到 compete；
• 当一侧积累到 3 个原始事实节点并满足生命周期阈值后，后续计划才把胜者提升为 stable、创建 supersede 边，把旧代表节点保留为 audit-only。
  

图 2｜本次在 commit 63a5f636 构建产物上执行的合成数据用例，13 项断言全部通过、0 项失败。用例没有调用外部模型、账号或 API。验证范围是确定性代码路径，不涉及现实语料上的语义判断准确率。

这说明报告里的“范围隔离、先竞争后取代、保留证据”至少能在这个固定版本的公开实现中找到并跑通相应代码路径。证据边界也很明确。合成测试不能替代长期真实部署，examples 的 97 项冒烟检查也不能替九项 benchmark 背书。

OpenContext 在整条技术叙事中承担公开工程入口的角色，供开发者直接检查、试用和参与建设，不能视为成熟度证明。

两份报告拼出同一条技术路线



把两份报告放在一起看，Alloomi 的技术判断很明确。下一阶段的 Agent 竞争会继续比较工具和上下文窗口，也会比较谁能建立下面这条反馈回路。

真实工作流产生任务轨迹和反馈，Holistic Context 维护可追溯的长期状态，Self-Evolving Agent 从筛选后的经验中后训练，验证与回滚机制控制更新风险，新的模型能力再回到下一次交付。

这条路线同时处理任务状态、Agent 脚手架和模型参数三层。单独做 RAG，只能让模型临时看到更多资料；单独做微调，无法保证训练数据里的上下文正确且仍然有效；让模型自己复盘自己，又可能把错误重复放大。三层配合，才有可能把“完成过一次”变成“下一次做得更好”。

目前的证据仍然属于早期阶段。Holistic Context 需要多种子、多骨干和同一 harness 下的正面对照；Self-Evolving Agent 需要更长任务序列、更多模型架构和更强对手条件下的复验；Alloomi AI 在专业服务场景中的长期交付效果，也还需要真实部署周期和客户侧指标来回答。

如果只是做一次性问答或短会话自动化，成熟的检索与工作流编排可能已经够用。长期运行、跨项目、需要继承专业判断的 Agent 团队，更需要继续关注这条路线。

对这类团队来说，“让 AI 越用越聪明”不再只是一句产品口号，而是一组可以逐层检查的问题。状态有没有维护、经验有没有进入训练、能力有没有保留、学偏之后能不能回滚。

公开材料如下

• Holistic Context 技术报告
• Self-Evolving Agent 技术报告
• OpenContext
• Alloomi 官方账号
    @AlloomiAI
  

OpenContext 仍处于早期阶段。如果正在开发长期运行的 Agent，可以先阅读两份技术报告，再检查固定版本代码与本次验证边界，最后决定哪些机制值得带进自己的系统 #Alloomi