Agent Context Management：从 Prompt 拼接到上下文治理

过去两年，随着 agent 从聊天助手走向 coding agent、research agent 和长期运行的自动化系统，context management 从一个边缘技巧变成了系统设计里的硬问题。

一开始，这件事看起来很简单。模型窗口有限，于是大家研究怎么裁剪历史消息、怎么做摘要、怎么把检索结果重新塞回 prompt。那时所谓的 context engineering，本质上还是 prompt engineering 的延长线：让模型在当前这一轮里看到足够多的信息。

但 agent 一旦跨过单轮对话，这个理解就不够了。

一个真实的 agent，不只是回答当前问题。它还要在长任务里继续推进工作，在多次 session 之间保留连续性，在工具调用、文件修改、外部反馈和用户偏好之间维持稳定状态，并在必要时主动追问、定时回访、恢复中断任务。到这一步，context 已经不再只是 prompt 里的一段文本，也不再只是一个 memory store。问题会变成：

一个 agent 在任意时刻，到底依赖什么来感知世界、形成判断并继续行动？

可以先把这件事拆成三个层次：

1. retention：什么应该被保留下来
2. activation：什么应该在当前任务里被激活
3. governance：这些对象什么时候生效、何时失效、谁来决定、如何审计

主流系统已经把这条线走出来了。OpenAI 先从 session continuity 和 personalization 入手，把问题建模成会话内记忆和跨会话个性化；Anthropic 把它推向长期任务的工程结构；Google 从 production architecture 视角，把 session / state / memory 明确拆开；LangGraph 则直接从 thread、checkpoint 和 state snapshot 出发，把上下文连续性理解成可持久化、可恢复、可回放的运行时状态。

这里，大概会得到一个共识：agent context management 已经不是单纯的 prompt 问题，而是一个分层状态管理问题。 但这还没有走到最深处。

因为“记忆”本身并不是终点。

一、从窗口管理到记忆管理

在最早的 agent / prompt engineering 讨论里，context management 几乎等价于窗口管理。问题很直接：上下文窗口有限，长对话、工具调用结果和外部资料会迅速把窗口塞满，因此需要某种机制决定哪些内容继续留在 prompt 里，哪些内容应该被裁掉。

这一阶段最典型的做法有三类：

• 保留最近 N 轮消息
• 对更早的历史做摘要
• 从外部知识库里检索当前最相关的片段再塞回窗口

这套方法直到今天仍然有价值。它第一次系统化地回答了：长对话和长工具调用链，怎样在有限窗口中继续跑下去。它也证明了，context management 不再只是“随手拼 prompt”，而是会直接影响延迟、成本、准确率和稳定性的工程问题。

但它的边界也很明显。窗口管理擅长的是让模型在当前这次调用里更聚焦，它并不真正回答跨 session 的连续性，也不回答哪些信息应当在未来继续存在，更不回答这些信息在什么时候应该重新生效。它解决的是 active context 的拥挤问题，而不是 durable context 的存在问题。

随着 agent 不再只是短会话问答，而开始承担跨会话个性化、项目延续和长期任务推进，行业自然走向了第二阶段：把 context management 重新表述为 memory management。

OpenAI 的 personalization 路线、Anthropic 的 memory tool、Google ADK 与 Memory Bank，都是这一阶段的代表。它们的共同点在于：都明确承认了 窗口之外还存在另一层上下文。只是这层上下文，在不同系统里有不同名字：

• OpenAI 用 saved memories、reference chat history、session memory、personalization memory
• Anthropic 用 memory tool 和外部 memory 文件
• Google 用 Session / State / Memory 三层模型，以及 MemoryService / Memory Bank

这一阶段真正往前走的一步，不是“多了一个记忆库”，而是正式承认：

并不是所有上下文都应该驻留在当前 prompt 里。

行业开始把 context 从“当前窗口中的内容”扩展为“窗口内活跃部分 + 窗口外可再次激活的部分”。Anthropic 在 memory tool 文档里甚至明确把它说成一种 just-in-time retrieval：不是预先把所有相关信息都塞进上下文，而是把知识放在外部，需要时再拉回来。

Google 在这条线上走得尤其制度化。它把 session、state、memory 明确拆成不同对象：session 是当前对话线程，state 是当前会话内的工作态，memory 则是跨会话的长期知识。这种拆分非常有价值，因为它第一次把“当前工作状态”和“长期知识保留”从概念上硬拆开了。

二、为什么 memory 仍然不够

尽管 memory 路线比窗口管理前进了一大步，但它也带来一个很常见的误判：人们开始倾向于把“有了长期记忆”当成 context management 的完成形态。

问题在于，memory 更像是在回答 retention，还没有把 context management 这件事答完。

首先，记住什么并不等于现在该用什么。被成功写入 memory 的内容，未必应该在当前任务中重新进入上下文；被取回来的内容，也未必应该以当前的最高优先级生效。retrieval 并不等于 activation。

其次，很多真实上下文根本不是稳定事实。例如长期偏好与临时 override 的关系，就很难用简单的 global memory / session memory 覆盖规则描述。一个人可能“通常喜欢甜食”，但“最近几天不想吃甜的”，过几天又恢复默认。这里真正需要管理的不是有没有 memory，而是这些信息各自的作用域、时效、优先级和失效机制是什么。

再次，memory 路线特别容易让人忽略上下文里的其他一等对象：

• 当前任务结构
• 工具可用性与权限边界
• 工作区中的计划文件、测试结果和工件
• 不同 agent 之间的 handoff 语义
• 执行中的中间状态与待办项

这些都不是狭义 memory 能完整承载的。

换句话说，memory 只是 persisted context，而不是 context 的全部。

所以把 context 简化成“记忆系统”是不够的。在长时 agent 系统中，真正持续存在的往往不是某个 agent 实例本身，而是它所依附的工作环境、文件、日志、工件和规则。从这个意义上说，workspace 才是 durable context 的关键载体，agent 更像过客。

三、从记忆走向连续性与底座

如果说窗口管理阶段主要在解决“当前窗口里放什么”，记忆管理阶段主要在解决“哪些信息应该跨窗口留下来”，那么下一步的问题就会自然转向更深的一层：

agent 的连续性到底依赖什么底座？

这是一个比 memory 更基础的问题。因为一旦任务跨越多次 session、多轮工具调用、多阶段规划和长期执行，真正重要的已经不是“有没有一份长期记忆”，而是一个新的 agent 能不能接上旧任务、一个中断的任务能不能恢复、一个系统能不能把半成品、计划、测试、失败和人工反馈重新装配成可继续工作的状态。

1. Anthropic / Claude Code：连续性来自外部工件和工作纪律

Anthropic 在 coding agent 这条线上给人的最大启发，不是“它记得更多”，而是它把 context management 深度嵌进了 coding runtime。

Claude Code 公开暴露出来的对象已经足够说明问题：

• CLAUDE.md
• session continuity
• subagents
• worktree
• hooks
• MCP

这意味着它关心的已经不是单纯的 memory，而是：

• 什么东西应该成为持久指令
• 什么东西应该在隔离上下文里处理
• 什么生命周期事件值得被 hook
• 什么工作副本应该独立出去

更重要的是，Anthropic 自己展示的长期 harness 例子其实已经讲得很直白：长期 coding agent 的连续性，并不是靠把所有历史都压缩回 prompt，而是靠 progress file、feature list、git history 和不断维持 clean state 的工作流纪律。

这条路线真正重要的地方，在于它把“上下文”从模型可见文本，重新定义成一组可被 agent 和人共同维护的工作工件。Anthropic 的长期 harness 说到底是在强调：真正承载连续性的不是模型记忆，而是 workspace 里持续存在的外部结构。

2. LangGraph：连续性首先是可恢复执行状态

如果说 Anthropic 更强调 workspace continuity，那么 LangGraph 走的是另一条路线。它不先从 memory 讲起，而是先从 thread、checkpoint 和 StateSnapshot 讲起。

在 LangGraph 的设计里，连续性首先被理解成：一次 graph execution 是否能够在中断后恢复、是否能够被回放、是否能够 time travel、是否能够在某个 checkpoint 重新分叉。也就是说，它把 context continuity 首先建模为 recoverable execution state。

这条路线的价值很明确。对于需要 human-in-the-loop、复杂工作流调度、长链工具调用和错误恢复的系统来说，thread 和 checkpoint 提供了一个很坚实的运行时连续性基础。它让“继续上次那个任务”不再依赖一段模糊的聊天历史，而依赖一个可持久化、可恢复、可回放的运行时状态快照。

但 LangGraph 的边界也很清楚。它更强的是 execution continuity，而不是 durable context semantics。它很擅长回答“任务如何恢复执行”，却不自动回答“哪些知识应该被长期保留、如何治理偏好和 override、如何在社会性环境中维持身份与上下文边界”。checkpoint 并不等于 workspace，也不等于 context governance。

3. Bub / Tape：上下文首先是事实流，而不是记忆库

Bub / Tape 提供了第三种完全不同的答案。它不是从 session、memory 或 checkpoint 出发，而是从 append-only 的事实流出发。它的基本态度可以压成一句：

context comes from tape, not session accumulation

这个立场纠正了一个很常见的误区：很多系统默认把上下文理解成“累积的历史对话”，然后再思考如何压缩、裁剪、总结。但 Bub / Tape 这条路线认为，更深的第一性对象不是聊天记录本身，而是可追溯的事实、事件、anchor 与 handoff。当前 prompt 只是这些事实流的一种装配结果。

这样的设计天然适合：

• 追溯与审计
• 多 agent / 多人共享同一事实底座
• 保留“结论如何形成”的因果线索
• 在不同视图上重新解释同一条历史

它和“坍缩过程本身也应该被保存”这个判断高度同频。

但它的局限同样明显。线性的 append-only 事实流虽然很适合做 causal substrate，却不天然等于完整 context system。真实上下文还需要层级关系、主题聚合、当前激活状态、长期偏好与临时 override 的语义治理。换句话说，Tape 更像因果地基，而不是整栋建筑。

4. OpenViking：上下文作为文件系统式数据库

如果说 Bub / Tape 更像事实流底座，那么 OpenViking 代表的是另一条路线：把上下文统一重构成一个文件系统范式下的 context database。

OpenViking 最关键的贡献，不是做了一个更强的 RAG，而是提出 memory、resources 和 skills 不应再被散落在不同系统里，而应该在同一个 context plane 中被统一组织。它把 context 理解成一个可以像文件系统一样被遍历、定位、递归展开和分层激活的空间，而不是一堆扁平向量块或孤立文档。

其中最值得注意的是它的分层激活机制。这个思路意味着上下文不再只是“取回来多少”，而变成“以多深的层次进入当前工作集”。这实际上已经在接近 activation 问题，而不只是 retrieval 问题。

因此，OpenViking 的启发在于：它把 context 从黑箱 memory store 提升成了一个可操作、可观察、可组织的 context substrate。不过它也有明显边界：它更强在 substrate 与 retrieval 组织上，还没有把 context governance、本体语义和 agent runtime 一体化做到完整 Agent OS 层。

5. OpenClaw：workspace-native 的 agent habitat

OpenClaw 代表的是另一条非常贴近真实使用的路线：workspace-native 的 agent runtime。

与其说 OpenClaw 有一个单独的 memory system，不如说它把上下文拆散并外化到了工作区中的多个对象里：

• SOUL.md 承担身份与风格锚点
• AGENTS.md 承担操作法则
• MEMORY.md 和 memory/YYYY-MM-DD.md 承担长期与日记式记忆
• HEARTBEAT.md 承担周期性注意力与背景任务
• skills 承担能力和工作方法
• workspace 文件本身承载任务工件与工作世界

这条路线的价值很朴素：它几乎把“上下文”做成了一个文件系统社会。它不依赖一个统一的 state object，而是通过不同层级文件与运行规则，共同构成 agent 的持续环境。这也是为什么它虽然工程上未必最优雅，却很容易让人感到“agent 在活着”：连续性不是藏在模型里，而是分布在 workspace 中可见、可编辑、可协作的多个对象里。

它的边界也很清楚：目前更强的是文件化 convention 和 runtime discipline，而不是形式化的语义治理层。换句话说，OpenClaw 已经相当接近“虚拟操作环境”，但离真正的 context governor 还有一步。

四、为什么下一步会是治理，而不只是存更多记忆

把上面几条路线放在一起看，会发现它们虽然选择了不同的第一性对象，却都在说明同一件事：

context 的问题正在离开“有没有记忆库”这个层面，转而变成“连续性和工作世界依赖什么底座”的问题。

这些系统分别给出了不同答案：

• Anthropic 强调外部工件与 workspace discipline
• LangGraph 强调可恢复执行状态
• Bub / Tape 强调 append-only 的事实流
• OpenViking 强调文件系统式的 context plane
• OpenClaw 强调 workspace-native 的生活环境

从这里也可以得到一个更清楚的区分：

• runtime checkpoint 解决的是“过程如何恢复”
• workspace substrate 解决的是“世界如何沉淀”
• fact / tape substrate 解决的是“因果如何追溯”
• context filesystem 解决的是“对象如何组织与激活”

这些问题彼此相关，但并不相同。也正因为如此，下一步真正难的已经不再只是“做一个 memory system”或“加一个 checkpoint layer”，而是如何把这些不同类型的连续性组织起来，并在时间中持续治理。

一旦上下文跨越：

• 多 session
• 多工具
• 多任务
• 多 agent
• 甚至多模型

context management 就不再适合作为单个 agent 的私有能力，而越来越像一种共享基础设施。

你迟早要回答这些问题：

• 什么信息有资格进入 durable context
• 什么信息只应该停留在当前 active context
• 什么信息应该被降级、失效或遗忘
• 不同来源的上下文如何排序
• 不同 agent / 不同角色之间如何共享最小必要信息
• 当事实、偏好、计划、规则发生冲突时，谁来做仲裁

换句话说，未来 context system 的关键能力不再只是 retrieval，而是：

• activation
• scope
• precedence
• expiry
• audit

这也是为什么我越来越觉得，retrieval 只能算必要条件，而不是最终答案。把信息找回来，并不等于它此刻就应该进入工作集，更不等于它会以正确的优先级生效。

五、为什么很多 agent 还不够会搜索

到这里，问题会继续往前推一步：即便已经有了更好的 context substrate、更长的连续性和更强的治理层，很多 agent 依然不够强。真正缺的经常不是“记不住”，而是不会展开搜索。

今天很多 agent 已经会调用工具、会检索资料、会做工作流，但它们的“搜索”往往更像：

• 去搜索引擎或知识库取回信息
• 在已有上下文上给出一个看起来不错的计划
• 沿着单一路径继续往下执行

但真正高质量的 agentic search，应该包含更强的能力：

• 在问题空间里主动生成多种初始解
• 在解空间里展开不同策略分支
• 在执行过程中根据反馈进行剪枝与再分叉
• 在失败后回溯并切换启发式
• 在多个并行路径中收束，而不是过早锁死

也就是说，未来的 agent 不仅要会 retrieve，还要会 search；不仅要会 follow plan，还要会 explore plan。

如果未来真的要补上这一层，我觉得系统里很可能需要一个新的对象：Agent Search Map。

它不是 memory，也不是 plan。它更像一种介于 plan、heuristics 和 search state 之间的对象，至少要显式表达：

• 常见问题的分解结构
• 不同路径的初始启发式
• 哪些路径容易陷入局部最优
• 哪些信号意味着应继续深挖，哪些意味着应剪枝
• 当前已经试过哪些思路、失败在哪、还缺哪些探索

从这个角度看，Agent Search Map 的作用不是保存过去发生了什么，而是帮助系统在未来更好地展开探索。

写到这里，异构模型和多 agent 才值得讨论，但它们不是这篇文章的主线。更准确的说法是：如果系统之后要提升搜索质量，认知异质性可能是一个重要手段，但它服务的是 search，不是替代 context management 本身。

六、一个更稳的结论

把这些路线放在一起，我现在最想保留的判断是：

Agent context management 的演进，大致经历了从 window management，到 memory management，再到 runtime continuity / substrate，并正在走向 context governance。

如果这个判断成立，那么接下来的问题就不再只是：

• 如何存得更多
• 如何取回更准

而是：

• 什么该保留，什么该激活
• 什么是 durable context，什么是 active context
• checkpoint 与 workspace 应该如何分工
• memory、resource、skill、tool result、plan、git log、tape 这些对象如何统一治理
• 单 agent 是否足够，还是需要 guardian、butler、coordinator、searcher 这类不同角色

换句话说，未来的 context management 不再只是“让模型看到更多”，而是“让一个持续存在的 agent system 在时间中更稳地工作、搜索、学习和治理自己”。

这差不多就是它开始碰到 Agent OS 边界的地方。

主流的进展：

• OpenAI 主要处理 sessionized conversation
• Claude Code 主要处理 coding runtime 的 working set
• Google 主要处理 production memory / state service
• LangGraph 主要处理可恢复执行状态
• Bub / Tape 和 OpenClaw 已经把问题推向 substrate 和 governance

方向相近，停留的层级并不一样。

如果把整篇文章最后压成一句话，可以写成：

Agent Context Management 正在从“如何在有限窗口里塞更多 prompt”演化为“如何把状态、记忆、工件、指令和执行轨迹持久化，并在 runtime 中按任务、作用域和权限重新装配工作集”的问题。

这句话还不是终局判断，但至少比“memory 越来越重要”具体得多。因为 memory 只是其中一个对象，真正变大的，是 runtime。