过去两年间，AI agent 的架构演进出现了一个显著趋势：越来越多的系统将文件系统视为 agent 记忆与状态管理的核心基础设施。从早期的简单日志写入，到如今复杂的「agent filesystem」抽象，开发者似乎达成了一种默契 —— 让 agent 像人类一样拥有持久化的「工作目录」，在其中存储计划、记忆、中间产物与学习成果。然而，当我们将视角转向 Stanford ACE（Agentic Context Engineering）框架所展示的 ephemeral context 设计时，一个根本性的问题浮现出来：持久化文件系统真的是 agent 赖以生存的基石，还是一个隐藏甚深的反模式？

从 ACE 框架看上下文管理的本质差异

Stanford ACE 框架代表了当前 agent 架构研究的一个重要方向：不再将上下文视为静态的提示词容器，而是将其看作一个需要持续演化的活对象。ACE 将这个演化过程拆解为三个核心角色 ——Generator（生成工具调用计划）、Reflector（批判并提炼洞察）、Curator（应用增量更新到上下文）。这三个角色共同构成了一个自洽的反馈循环，使 agent 能够在长周期任务中保持推理的连贯性与学习的累积性。

值得注意的关键细节在于，ACE 的所有状态管理都发生在内存上下文中。Generator 产生的计划、Reflector 产生的批评、Curator 产生的增量更新 —— 这些全部以结构化数据的形式存在于运行时内存里，通过角色间的消息传递完成流转。整个框架从未假设需要将任何中间状态写入持久化存储，agent 的「记忆」本质上是上下文窗口内的一段可演化序列，而非文件系统中的某个目录结构。

这与当前盛行的 filesystem abstraction 形成了鲜明对比。后者将 agent 的工作空间映射为一个虚拟文件系统，agent 的每次思考、每个决策、每条学习到的规则都被写入磁盘文件，需要时再从文件中读取并「重新水合」（rehydrate）到内存中。从表面上看，这种设计提供了更强的持久性保障 —— 即使进程崩溃，agent 也能从上次中断的地方继续工作。但如果我们深入审视这种设计的隐含代价，就会发现它可能引入了一系列比它解决的问题更棘手的新问题。

持久化文件系统引入的隐含成本

状态一致性的脆弱性是文件系统依赖最直接的代价。当 agent 的状态以文件形式存在于磁盘上时，任何非原子性的写入操作都可能导致状态损坏。一个典型的场景是：agent 正在更新其「学习到的规则库」，写入过程被系统中断，结果是规则库文件处于半写入状态，下一次读取时要么解析失败，要么读到的是过时且不一致的数据。为了解决这个问题，开发者通常需要引入写前日志（write-ahead log）、事务机制或复杂的锁策略，这些机制本身又引入了额外的复杂度与性能开销。

并发访问与多实例冲突是生产环境中更为棘手的问题。当同一个 agent 的多个实例运行在不同的容器或进程 中时，文件系统成为了共享状态的唯一协调者。文件锁机制在跨平台场景下表现不一，网络文件系统（NFS）的缓存一致性问题更是臭名昭著。即使引入分布式锁服务（如 Redis 锁或 ZooKeeper），也仅仅是将问题转移到了另一层，并未真正消除文件系统作为共享状态存储的根本缺陷。

迁移与可移植性的丧失同样不可忽视。基于文件系统的 agent 状态隐含了对特定主机目录结构的依赖。当需要将 agent 从开发环境迁移到生产环境，或者在不同云区域之间调配资源时，路径不一致、权限配置差异、存储后端特性不同等问题都会逐一浮现。相比之下，以纯内存上下文形式存在的 agent 状态可以通过序列化（但不含文件系统路径）的方式在任意环境中重建。

安全攻击面的扩大是一个常被低估的风险。文件系统暴露了 agent 的内部状态到操作系统层面，这意味着恶意进程可以通过文件权限漏洞、符号链接攻击、竞态条件等路径读取或篡改 agent 的记忆与决策逻辑。而在纯内存上下文中，攻击者需要首先突破进程的内存保护才能访问 agent 状态，大幅提升了攻击门槛。

重新审视「持久化」的真正需求

一个关键的问题是：agent 真的需要持久化吗？答案是复杂且因场景而异的。短期任务（数分钟到数小时）中，agent 的整个生命周期都可以在一次运行时内完成，根本不存在「持久化」的需求 ——ACE 框架正是为这类场景设计的。中期任务（数天到数周）中，持久化的需求来自于人类监督者的介入与恢复需求，而非 agent 自身的内生需求 —— 此时通过检查点快照（checkpoint snapshot）机制定期导出完整状态，要比持续维护文件系统中的增量状态更为可控。长期任务（数月以上）中，真正需要持久化的是 agent 与外部系统交互产生的结果（如报告、代码、决策记录），而非 agent 内部的推理状态 —— 后者可以通过重新运行相同的输入上下文来「重建」，前提是外部输入是可重复获取的。

这种分层思维帮助我们厘清了一个核心混淆：需要持久化的是agent 的产出，而非agent 的思维过程。一个完成编程任务的 agent 需要保留它生成的代码，但不需要保留它「思考」时使用的内部上下文。代码可以写入代码仓库（版本控制系统），这是成熟且被广泛验证的持久化方案；而 agent 的推理上下文应该保持 ephemeral，仅在运行时内存中存在。

转向 Ephemeral Context 的工程实践

如果放弃文件系统依赖，agent 的状态管理应当如何设计？以下几个工程实践提供了可行的方向。

第一，使用结构化内存存储替代文件存储。 将 agent 的状态（计划、规则、记忆）保存在内存中的数据结构（如 Python 字典、专门的 State 类或专门的内存数据库如 SQLite 的内存模式）中。这些结构可以在进程退出前序列化为 JSON 或 MessagePack 格式，仅在需要恢复时使用，而非在每次更新时写入磁盘。

第二，采用检查点快照而非持续写入。 对于需要支持中断恢复的场景，不要持续将状态写入文件，而是每隔固定时间间隔或每次重要阶段完成后，对整个内存状态做一次快照。恢复时从最近的快照加载即可。这种模式的写入频率远低于持续写入模式，大幅降低了状态损坏的风险。

第三，将产出与推理分离。 Agent 产生的所有需要持久化的产出（代码、文档、分析结果）应直接写入目标系统（代码仓库、文档系统、数据库），而非写入中间的文件系统目录。Agent 的内部推理状态不需要知道这些产出是如何存储的 —— 它只需要调用正确的 API 或工具即可。

第四，利用外部记忆服务实现状态复用。 当多个 agent 实例需要共享状态时，使用专门的记忆服务（如向量数据库存放记忆片段、Redis 存放结构化状态）而非文件系统。外部记忆服务提供了更好的并发控制、一致性保证与访问抽象。

何时可以保留文件系统：务实的边界判断

完全否定文件系统在 agent 系统中的作用同样是一种极端。以下几个场景中，文件系统仍然是合理的选择：需要与外部系统进行文件交换时（如读取用户上传的文档、生成需要交付的 PDF 报告），文件系统作为与外部世界的接口层仍然不可替代。调试与可观测性需求中，将 agent 的完整运行轨迹写入日志文件是排查问题的重要手段，此时文件系统是合理的日志后端。在资源受限的边缘计算场景中，内存容量可能不足以容纳完整的上下文，此时文件系统作为溢出存储（overflow storage）是务实的折中。

关键在于区分两种截然不同的场景：agent 的内部状态管理（记忆、推理上下文）应当 ephemeral 化，而与外部世界的交互（输入、输出、日志）可以保留文件系统作为接口层。这个边界一旦厘清，许多看似矛盾的架构决策就能找到清晰的立足点。

结语

Stanford ACE 框架的 ephemeral context 设计并非偶然的选择，而是一种经过深思熟虑的架构立场。它揭示了一个重要的原则：agent 的智能不应该依赖于持久化存储的「记忆」，而应该来源于上下文在运行时内的持续演化能力。文件系统 abstraction 固然提供了一种直观的抽象方式，但它带来的状态一致性、并发控制、迁移成本与安全攻击面问题，在生产环境中往往远超其带来的便利性。

当我们在架构层面做决策时，一个有用的检验标准是：如果把文件系统从 agent 的架构中完全移除，这个系统是否仍然能够工作？ 如果答案是肯定的，那么文件系统就是一个可选的优化层；如果答案是否定的，那么这个系统可能已经陷入了一种隐蔽的依赖 —— 而这种依赖，在追求 agent 自主性与弹性的道路上，终将成为需要被克服的负担。

参考资料