内存在实战中：我们如何在自己的代码中使用 Context Engine

上周我们介绍了 Context Engine——Applied Compute 用于记忆、精炼和检索企业上下文以构建持续学习 Agent 的系统。本文讲述的是我们将其对准自身时发生了什么。

尽管结果还处于早期阶段，但已经显示出利用先前 trace 所提取的上下文带来的可观收益。值得关注的是，通过基于我们自己编码会话构建的 Contextbase，我们通过生产环境中的持续学习，将对编码 Agent 任务至关重要的记忆检索率提升了约 2 倍。此外，在一个精心筛选的小型任务集上，我们发现了记忆发挥关键作用的明确迹象——Agent 能够成功利用从 Contextbase 注入的记忆，超越无记忆基线。

介绍 ACL-Wiki

过去几个月里，我们记录了 Applied Compute 在 Cursor、Claude Code 和 Codex 上的每一次编码 Agent 交互，并将这些 trace 路由到 Applied Compute Logs（ACL）中——这是一份完整记录我们实际构建软件方式的日志。随后，我们使用 Context Engine 创建了一个 ACL Contextbase，并通过 MCP 服务器将其提供给编码 Agent 使用。我们将这个循环称为 ACL-Wiki。

整个流水线与记忆、精炼、检索的基础逻辑相同，只是针对代码场景进行了专项优化：

• Remember（记忆） 负责摄取每一条编码 Agent 的 trace。

• Refine（精炼） 从调试会话中提取低层次记忆，在此基础上构建高层次程序性记忆，进行去重和剔除过期条目，将记忆整理成文件夹结构，并编写顶层索引。

• Retrieve（检索） 在运行时将 Contextbase 暴露给编码 Agent，补充其已从代码库中获取的上下文。

在基础循环之上，我们搭建了一个持续学习反馈工具，工程师可以标记那些应该创建记忆的会话，或者标记某条现有记忆是有用还是干扰性的。这些标记会反馈给 Refine，后者每天更新一次 Contextbase。

ACL-Wiki 基准测试

为了监测 ACL-Wiki 的改善或退化情况，我们通过一个名为**关键记忆率（Critical Memory Rate）**的指标来追踪检索到的记忆是否对任务至关重要。该指标衡量的是：在具备完整轨迹上下文的前提下，LLM-as-a-Judge 认为我们的 Retrieve 调用向编码 Agent 返回了对有效完成任务不可或缺信息的比例。为保证评分稳定性，我们采用在 GPT-5.4-mini 上运行的 majority vote@3。附录中包含一个得到正向关键评分的示例 trace。我们仅筛选 ACL-Wiki 检索调用次数超过 15 次的分桶进行统计。

初期，ACL-Wiki 检索到的上下文对编码 Agent 基础性能的提升相当有限。随着使用量的增加（更多 trace、更多工程师反馈），我们看到关键记忆率的移动平均值在两周内从不足 10% 攀升至约 20%。关键记忆率有其自然上限，因为并非每项任务都需要机构知识。但 Agent 的表现往往取决于其最薄弱的时刻，而非平均水平——正是那些长尾任务，才是机构记忆真正发挥价值的地方。Contextbase 在这类任务上的性能提升往往具有不成比例的显著效果。这正是我们将记忆集成到企业中这一核心论点的关键：系统使用得越多，其在最关键决策上的记忆就越敏锐。

利用生产环境构建基准：ACLBench

关键记忆率能告诉我们方向，但无法告诉我们记忆何时有帮助、何时有害。因此我们构建了 ACLBench：一个从相同生产 trace 中手工整理的编码任务集。该基准反转了传统模型基准的设置——被评估的对象是记忆系统，而模型保持固定。借助这个框架，我们可以替换记忆系统（或完全移除记忆）并进行直接比较。

我们首先将每条生产 trace 拆分为意图块（intent chunks），即对话中用户引入并解决单个意图或目标的片段。我们筛选出那些意图在单一代码仓库内自包含的块（无外部依赖或 API 调用），以便支持场景回放。

然后，我们手动筛选出明确需要记忆的块，以测试记忆系统是否能够改善 Agent 在反事实轨迹上的表现。

例如，考虑以下两个块：

• 用户先请求一张表格，然后要求将表格渲染为紫色文字。

• 用户先请求一张表格，然后要求删除该表格。

我们认为记忆系统应该从第一个块中形成偏好记忆，而不是第二个——未来的表格应默认使用紫色文字，而不是默认被删除。

我们手工挑选了约 25 个行为预期明确无误的块。（注：我们发现通过 LLM-as-a-judge 过滤直接生成的大规模数据集效果不佳。现有前沿模型在判断某个任务对区分优劣记忆系统的价值方面表现不好。）

对于每个选定的块，我们提取两类数据：

• 块的原始 trace，可被 Remember 进 Contextbase。

• 任务规格（用户消息、git hash 等），用于初始化可回放的场景。

针对基准测试，我们整理了两类任务，并配以不同的评分器：

• 记忆任务：任务提示考验模型利用已有记忆信息的能力（通常来自生产环境中关联块的实际 trace）。我们创建了相应的评分标准，检验解决路径中是否使用了特定记忆，并对成功使用给予正向奖励。

• 干扰任务：要么预期不会产生有用记忆但模型可能受到其他现有记忆的干扰，要么虽然可能产生有用记忆但该记忆可能削弱模型在其他任务上的表现。我们创建了相应的评分标准，检验解决路径中是否使用了特定记忆，并对使用行为给予负向惩罚。

记忆任务衡量记忆系统带来的性能提升，干扰任务衡量性能退化。

我们使用 Claude Opus 4.6 在一个最小化编码 Agent 框架中重新运行了每项任务：用户任务未完成时得分为 0.0，否则按评分标准中所有维度的平均分计算，并对 SPI=3 取平均。Contextbase 通过在评估集的所有 trace 上运行 Remember、Refine、Retrieve 流水线的简化版本构建而成。

我们按记忆应当发挥作用的原因对结果进行分桶：

• 通过记录历史问题缩短价值实现时间。 记录重复任务执行方式的记忆——这类记忆让教师模型能够将最佳实践提炼为详细 SOP 并传授给学生模型，从而提升 token 效率。

• 通过用户偏好暴露可控性。 编码团队或用户需求的记忆——这是企业可以控制 Agent 在每次部署中所使用上下文的可编辑层，无需重新训练。

• 通过外部规则解决不完整或难以处理的环境。 缺少记忆则无法明确规范的任务，原因是相关信息存在于领域专家的认知中，或相关数据体量过大难以从零摸索。我们数据集中的典型示例：鉴于近期安全漏洞，禁止使用 LiteLLM。

我们整理的评估集样本量（n）偏低，因为代码上下文本身已经极为丰富，前沿模型的编码能力也已足够强大，能够推测用户意图。但正如上述结果所示，在记忆可能发挥作用的场景中，其贡献往往具有不成比例的显著性：

• Contextbase 提升了所有类别的表现。 编码 Agent 愿意在执行任务时参考外部指引。用户偏好尤其难以“碰巧“满足，但有了合适的上下文则易如反掌。

• 干扰因素未造成性能退化。 编码 Agent 能够忽略无用的上下文。注：干扰任务相对基线的提升很可能源于 Opus 4.6 任务执行能力和 LLM-as-a-judge 评估中的噪声。

这意味着什么

在这个由两篇文章组成的系列中，我们使用相同的基础设施（AC Context Engine），将定制化的 Remember、Refine、Retrieve 流水线应用于三种不同的部署场景：

• 公开企业基准测试（APEX-Agents、GDPVal）——相对提升最高达 16.9%，推理工作量摊销至离线计算。

• AC 内部实时编码工作（ACL-Wiki）——关键记忆率在生产上线第一周内随 Contextbase 从工程师反馈中持续学习而稳步攀升。

• 有针对性的内部基准测试（ACLBench）——按任务类型分解记忆的贡献，记忆任务稳定提升，干扰任务无明显退化。

核心论点始终如一：生产 trace 具有极高价值，而大多数企业正在白白丢弃这些资产。我们将这份黄金资源转化为 Contextbase，将其接入你的 Agent，并看着它们日复一日地变得更加敏锐。

如果您是一家希望将生产 trace 转化为自身独特优势的企业，欢迎联系我们。

附录：[ACL-Wiki] 实战中的真实样貌

以下是一个来自 AC 生产环境实际部署的正向关键判断历史问题任务示例（注：语言已略作修改以保护专有内容）：

对话：员工 A，2026-04-27 用户请求：“能不能在 run-model.py 里加一个记录 rollout 的参数？数据保存到 PATH-{run-id}”

ACL-Wiki Retrieve 响应（节选）：

可以——但只在该参数尚未成为启动器默认值时才添加。对于 train_*.py 启动脚本，规则如下：检查 main_config.py 中的默认值，若所需值与默认值相同则完全省略该字段；若不同，则显式设置。

因此，run-model.py 中的改动应该是添加一个指向该路径的 debug-rollout-data 参数，但前提是这不是对应字段的默认值……

[匹配页面]

• [员工 B] 在启动配置中，省略值与默认值相同的字段
• [员工 C] 将日志包运行页面迁移到控制台：约 14 小时浪费在发明抽象上，而非直接镜像参考实现
• [员工 B] 说明：使用具体示例，以高层概述开篇，简明扼要但严谨

评委将其标记为关键的原因（3/3，高置信度）：

“检索提供了关于省略与默认值相同的启动器字段这一核心规则，用户在未作任何更正的情况下接受了最终修改结果。”

附录：[ACL-Bench] 评估中的真实样貌

以下是 ACLBench 中的一个历史问题任务，来源于 AC 的一次实际编码会话。

用户： 让它查询截止日期之前的任务

Contextbase 中的相关节选不仅展示了推荐模式，还说明了背后的原因：

项目惯例——server 中的查询模式：对于非简单查询，服务应使用 Model.query(ctx) 而非原始的 ctx.db.query(Model)。该查询方法定义于 db/base.py，通过 _apply_filters 协作链保留基于 soft_delete 状态的过滤、针对已认证上下文的授权检查以及其他 mixin 行为。通常不推荐使用原始的 ctx.db.query()。

没有 Contextbase 时，Agent 进行了泛化推理并给出通用建议：

“对于更复杂的查询，服务应使用 ORM 查询构建器模式（例如 ctx.db.query(Model).filter(…).options(…)）而非原始 SQL——它可组合、可读性强，且在整个代码库中保持一致。我现在来编写这个查询。”

看似合理，但对这个代码库来说是错误的：它忽略了授权和 soft-delete 链，会悄无声息地引入 bug。挂载 Contextbase 后，Agent 基于项目的实际惯例进行推理，用 grep 验证后得出：

“服务应使用 Model.query(ctx) 作为查询基础——这会通过 _apply_filters 进行链式调用，从而保留授权检查、soft-delete 过滤和其他 mixin 行为。我现在来编写这个查询。”

模型本身并未变得更聪明，但 Agent 获得了正确的上下文。

联合作者：Sam Denton @samueldenton、Dylan Yu @dyu1729 和 Raymond Feng @raymondmfeng