当整个行业仍在争论是否为 AI agents 构建坚固的持久化文件系统抽象时，Stanford 大学的研究者们在 2025 年底发表的一篇论文投下了一枚深水炸弹：Agentic Context Engineering（ACE）框架主张，agents 真正应该优先关注的，不是文件系统，不是存储层，而是那 转瞬即逝的上下文本身。这一观点与 03 月 28 日讨论的「为 agents 构建文件系统抽象」形成了鲜明的技术哲学对立 —— 一方认为智能应栖息于磁盘上的持久化结构，另一方则坚持智能应流动于内存中的临时上下文。理解这场路线之争，对于架构师在 2026 年做出正确的技术决策至关重要。

从权重到上下文：一场范式转移

过去十年，AI 系统的智能化演进始终遵循一条看似不可违背的路径：让模型变得更聪明，唯一的办法是 touching the weights—— 通过微调（fine-tuning）不断修改模型的数十亿参数。然而 Stanford ACE 论文提出了一个极具挑衅性的问题：如果智能可以不依赖于权重修改，而完全在上下文窗口中生长呢？

ACE 框架的核心洞察是，现代大语言模型已经具备了令人惊讶的上下文学习（in-context learning）能力 —— 它们能够纯粹基于上下文中的示例和指令来适应新任务。问题在于，我们过去一直把上下文当作一块静态的提示词（prompt）或一块临时草稿纸，用完即弃。研究者们将此称为「上下文短视」：brevity bias 迫使我们为了效率而压缩提示长度，即便这意味着牺牲关键领域知识；context collapse 则导致连续的提示改写逐渐侵蚀细节，留下一个被掏空的空壳。

ACE 的答案是将上下文重新定义为「一个活着的、可演化的记忆笔记本」。这个笔记本不是一次性写入的静态文档，而是一个持续积累、反思和筛选的动态知识库。系统可以从中读取、写入，并随着时间推移不断精炼其中的内容。

三角色循环：Generator、Reflector、Curator

ACE 的架构设计极具工程美感。它并未引入多个独立模型，而是让同一个 LLM 通过提示词条件切换扮演三个专业化角色，形成一个 生成 - 反思 - 筛选 的闭环。

Generator（生成器）负责执行具体任务。当它收到一个编码任务时，提示词会告知它「你配备了一个经过筛选的 playbook，其中包含策略、API 特定信息、常见错误和经过验证的解决方案」。Generator 在当前上下文的引导下尝试解决问题，同时记录下成功的策略和失败模式。关键在于，它不是在真空中工作 —— 它的每一次尝试都深受当前上下文状态的影响。

Reflector（反思器）扮演诊断引擎的角色。在每一次尝试后，它接收 Generator 的完整执行轨迹、执行结果以及标准答案。它的任务不仅是识别表面错误，而是进行根本原因分析。例如，对于一个失败的编码任务，Reflector 可能会诊断出「代理使用了不可靠的启发式方法（交易描述中的关键词匹配）而非权威数据源（手机应用联系人 API）」。这种深层次的诊断为后续的知识积累提供了原材料。

Curator（筛选器）则负责将反思洞见转化为结构化的上下文增量。它的操作方式极为精细：不是重写整个上下文，而是执行增量式的「ADD」操作，向特定章节追加新的要点。上下文被组织为「策略与硬规则」「特定信息的 API 用法」「验证清单」等分类。每个新增要点都附带元数据 —— 唯一标识符、以及追踪其在后续使用中被证明有帮助或有害的计数器。这种机制使得系统能够自动修剪过时建议、强化有效策略。

性能数据：上下文工程的硬实力

ACE 并非纸上谈兵。Stanford 团队在多个基准测试上进行了严格评估，结果令人印象深刻。在 agent 基准测试上，装备 ACE 的代理相比 GEPA（一种本身已超越强化学习方法的自适应提示优化器）实现了 10.6 个百分点的绝对性能提升；在金融分析等特定领域任务上，提升幅度达到 8.6 个百分点。

效率层面的改进更为显著。与 GEPA 的离线适配相比，ACE 减少了 82.3% 的 rollout 延迟和 75.1% 的 rollout 次数；与 Dynamic Cheatsheet 的在线适配相比，ACE 将适配延迟削减了 91.5%，Token 成本降低了 83.6%。更值得关注的是，在 AppWorld 基准测试（一个测试多步推理和工具使用能力的套件）上，一个较小的开源模型 DeepSeek-V3 配合 ACE，在平均性能上与 IBM 基于 GPT-4 的 CUGA 系统持平，并在更具挑战性的任务分支上略有胜出。这是一场「以巧取胜」的较量 —— 更聪明的上下文管理，弥补了参数量的劣势。

与文件系统抽象的根本分歧

将 ACE 的技术路径与 03 月 28 日讨论的「为 agents 构建文件系统抽象」相对比，两者在哲学根基上存在深刻分歧。文件系统抽象派的核心理念是：agents 需要一个持久化的、结构化的知识存储层，以便跨会话累积和复用结构化数据。这一思路自然导向 RAG（检索增强生成）、向量数据库、层级存储等技术的堆叠。

而 ACE 代表的上下文优先派则主张：智能的栖息地不应是磁盘，而应是内存中的上下文；真正重要的不是持久化存储什么，而是当前上下文窗口中流动着什么。持久化文件系统是「被动」的 —— 它等待数据被写入、等待检索、被调用；而演化的上下文是「主动」的 —— 它自己就是学习循环的一部分，通过 Generator-Reflector-Curator 的持续运转不断自我优化。

这并非说文件系统抽象毫无价值。ACE 论文也承认，并非所有任务都从长上下文受益 —— 简单任务配合固定策略可能只需要简洁指令。但对于那些需要详细领域知识、复杂工具使用或环境特定策略的 agents 来说，上下文工程提供了一条无需微调、实时适应、成本可控的路径。

工程实践启示

对于 2026 年的 agents 开发者而言，ACE 框架提供了几条可落地的实践指引。首先，考虑在 agent 架构中嵌入「上下文演化循环」—— 即使不完整实现 ACE 的三角色分工，也应设计某种机制让执行反馈持续流入上下文，而非仅在会话结束时丢弃。其次，上下文组织应采用结构化分类（策略、API 用法、验证清单等），并为每个知识点附加元数据以支持后续的自动筛选和强化。第三，将上下文视为「版本控制的文档」—— 每个 delta 都应可审计、可回滚，这在生产环境中对调试和问题定位至关重要。

在具体参数选择上，Stanford 的实验表明，上下文增量操作宜采用「ADD」而非「REPLACE」模式，以保留历史知识的累积效应；每个新增要点应保持简洁且可执行，避免引入模糊建议；元数据中的帮助 / 有害计数器应至少追踪 10-20 次使用后再做剪枝决策，以确保统计显著性。

这场关于「智能应该住在哪儿」的争论，短期内不会终结。但对于在技术前沿探索的架构师而言，理解上下文优先与存储优先这两种思路的本质差异，本身就是一项关键的认知升级。

资料来源：Stanford University, "Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models", arXiv:2510.04618