长时间运行的智能体的上下文工程：向量数据库、KV缓存、Claude Code
运行200步的智能体的上下文工程：为何长上下文会失效、KV缓存的成本效益、向量数据库的内存问题，以及Claude Code与其他工具的差异。
来源: Context Engineering Architecture Patterns for AI Agents — A Practitioner’s Guide
关于上下文工程已有大量论述，但很少有人探讨实际开发中面临的难题：对于需要运行200步的智能体，应如何设计上下文处理流程？虽然百万token的窗口大小看似充裕，但2025年Chroma对18种前沿模型的研究显示，当窗口填充度达到50%至70%时，模型质量就开始下降。以下是为那些正在部署生产级智能体的人士准备的解决方案蓝图，内容包括长上下文质量下降的原因、借鉴计算机架构的记忆模型、四种上下文管理策略、KV缓存的成本分析、三种知名产品的差异，以及基于指标的决策路径。
没有记忆设计的智能体相当于患有失忆症
想象一个能够正确执行第1步到第40步的智能体。到了第41步时，它似乎忘记了目标，开始重复之前已经做出的决策。这很少是逻辑错误，而是上下文衰退——即随着输入长度的增加，答案质量会出现可测量的下降。模型接收的信息越多，实际损失也就越大。
2026年Zylos AI发布的研究也得出了相同结论：任务持续时间翻倍会导致失败概率增加四倍，而且智能体在完成大约35分钟的同等任务时间后性能就会开始下降。上文提到的Chroma研究发现，18个模型在面对更多上下文时性能都会下降。NoLiMa基准测试（ICML 2025）的表现更为糟糕：在仅32K个令牌的输入下，13个模型中有11个的性能甚至低于其基准值的一半，尽管这些模型宣称自己的处理能力可达128K个令牌或更高；而GPT-4o的性能则从99.3%下降到了69.7%。
为何会存在衰减现象
Transformer注意力机制会将每个标记与其它所有标记进行比较。因此，文本长度翻倍会导致计算量增加约四倍，而非两倍。在20万个标记的情况下，每层需要处理约400亿对注意力关系。将所有内容都纳入上下文对于需要执行数百步操作的智能体来说根本无法实现有效扩展。
另一个问题是“中间内容丢失”。模型对长上下文的开头和结尾处理得最好，而中间部分的精度会下降，导致埋藏在其中的关键信息几乎无法被识别。奇怪的是，那些连贯且结构良好但无关紧要的文本，其对准确率的负面影响甚至超过随机打乱的相同句子。噪声中的语义相似性使得真实信号更难被找到。
宣传中的模型参数也具有误导性。虽然某个模型能够处理一百万个标记，但其实际可用容量并非一百万个标记。
上下文焦虑
用户们观察到了一个现象，Anthropic也予以承认：Claude Sonnet 4.5在接近上下文限制时往往会过早结束任务。这种现象被称为上下文焦虑。该模型的表现就好像内存即将耗尽一样，在资源真正用尽之前就主动停止工作。
由于性能下降不可避免，模型的架构必须能够应对这一问题。系统工程中有一个经典的类比可以用来解释这一现象。
模型相当于CPU，上下文相当于RAM，向量数据库相当于磁盘
2025年中期，安德烈·卡帕西主张优先采用“上下文工程”而非“提示工程”，并将其描述为一种精妙的艺术与科学，旨在为下一步操作精准填充所需信息。他并非在创造新术语，而是在指出一种思维方式的转变：大语言模型相当于CPU，上下文窗口则相当于RAM，而构建智能体的工程师则扮演操作系统的角色。
这一类比在实践中很容易理解。数据压缩类似于垃圾回收，状态注入类似启动流程，子智能体则相当于进程隔离，而像CLAUDE.md这样的文件则是在启动时加载的配置。变化的是关注点：人们不再那么注重提示语的措辞，而是更关注哪些内容以及何时被加载到内存中。
智能体的内存层次结构
智能体与计算机一样具有层级结构，每一层都在速度与容量之间取得平衡：
- 上下文工作内存。无额外延迟，可处理20万到100万个标记。其性能与寄存器和L1缓存相当：速度最快，成本最高，限制也最多。
- KV缓存。延迟低于10毫秒。与L2或L3缓存类似，用于存储为早期标记预先计算好的注意力矩阵，并在多次请求之间保持这些数据。
- 向量数据库或语义搜索。延迟大约在5到50毫秒之间，可存储数百万条记录，相当于RAM的功能。所列数据包括本地运行的FAISS每次查询约0.34毫秒的延迟，以及Pinecone的p99延迟为7毫秒。
- 文件系统或笔记。延迟超过100毫秒，且没有实际大小限制，类似磁盘。
- 归档存储。读取延迟以秒计，与网络存储或备份存储相当。
关于信息存储位置的每一项决策都是在成本、延迟和容量之间进行的权衡。如果选择了错误的层级，要么会产生高额费用，要么会导致智能体遗忘信息。2023年发表的MemGPT研究被广泛引用，它以“虚拟上下文管理”这一概念对这一理念进行了形式化阐述，其设计灵感来源于操作系统对分层内存的管理方式。这一理念至今仍以Letta框架的形式存在。
如果上下文是智能体的RAM，那么在真实系统中有哪些模式用于管理它，它们又是如何相互配合的？
四种模式：写入、选择、压缩、隔离
上下文工程基于四种基本模式。这些模式并非可供选择的替代方案，而是构成整体设计的互补层次，每一个实际应用的智能体最终都会使用这四种模式。
写入：将状态存放在窗口之外
写作意味着将状态外化。智能体会在 todo.md、NOTES.md 或 progress.md 等文件中记录笔记，并在后续步骤中重新读取这些笔记。Manus 以“待办清单复述”而闻名：智能体会将任务清单不断重写到上下文的最后，从而引导模型的注意力集中在整体计划上。这是一种有意识的注意力引导方式，能够避免“迷失在中间”的问题。
据报道，在一项玩《宝可梦》的实验中，Claude Opus 4 在数千步的游戏过程中始终保持着准确的笔记，记录了角色等级、地图信息以及策略内容，而无需任何关于如何组织记忆的明确指示。
选择：按需获取
选择这种方式意味着在需要时才获取上下文，而非预先加载。CLAUDE.md起到静态预加载的作用，就像新员工入职第一天收到的培训文档。之后，智能体会使用grep和glob工具探索代码库，仅获取当前步骤所需的资料。
据报道，Claude Code曾尝试过向量数据库，但最终放弃了，因为代码会不同步，权限管理也会变得复杂。Cursor则采取了相反策略，依靠语义索引实现动态发现。据称，该方案通过A/B测试显示，当智能体按需加载MCP工具时，使用的令牌数量减少了46.9%。
压缩：减少数据量
压缩是通过总结或截断来减少数据量。而紧凑化则是让大语言模型总结目前的对话内容，在保留关键信息的同时释放窗口空间。
据称，Claude Code在容量达到约80%时会发出警告，并在接近95%时自动进行压缩，同时保留架构决策。过度激进的压缩会丢弃那些细微但至关重要的上下文信息，导致模型开始重新探索已经处理过的内容。在实际应用中，3到6倍的压缩率似乎是生产环境下的最佳选择。学术基准测试显示的压缩率要高得多（LLMLingua指出在GSM8K数据集上可达20倍压缩率，且精确匹配损失仅为1.5分），但生产环境需要更高的保真度。
隔离：通过子代理分开处理
隔离意味着将不同的上下文分开。专门的子代理在自身的上下文窗口中工作，然后将简化后的结果反馈给其父代理。它可能会处理1万个标记或更多内容，但最终返回的摘要仅1千到2千个标记，远少于共享上下文所能积累的内容量。Manus采用了从Go语言中借鉴的原则：不要通过共享内存来通信，而要通过通信来共享内存。
关键不在于选择哪种模式，而在于如何组合这些模式以及何时触发它们。编写代码加上筛选是第一道防线，而压缩加上隔离则是系统实现扩展的方式。
上下文管理中的一个方面会对生产成本产生巨大影响，却常常在设计阶段被忽视。
KV缓存命中率，最重要的指标
KV缓存用于存储之前已计算出的注意力矩阵，这样模型就不必为每个新标记重新计算它们。可以将其想象成一种预先为常见查询前缀计算好连接操作的数据库。在某次GPT-2的测试中，使用缓存生成200个标记需要11.9秒，而不使用缓存则需要56.2秒，速度提升了约4.7倍。
为何它会改变智能体成本结构
典型的生产型智能体的输入与输出比例接近100比1，而聊天机器人的这一比例约为1比1。每次调用时，重新计算全部输入内容占据了主要时间。提示词缓存是一种服务端机制，用于在多次请求之间存储相同前缀对应的已计算标记，从而使读取操作的成本降低约十倍。对于Claude Sonnet而言，使用缓存时每百万个标记的成本为0.30美元，而不使用缓存则为3.00美元。
因此，围绕KV缓存重新设计上下文结构，确实可以将每月8,000美元的API费用降至800美元，这与Anthropic提供的十倍缓存折扣相符。Manus的联合创始人Yichao “Peak” Ji表示，对于正在实际使用的智能体而言，没有什么比KV缓存的命中频率更重要的了。
保持缓存活跃的三个规则
- 稳定的前缀。只要有一个标记的差异就会导致缓存未命中。Manus指出的一种错误做法是在系统提示的开头添加时间戳：这会让模型知道当前时间，从而破坏命中率。
- 仅允许追加内容的上下文。只能向上下文中添加内容，绝不能事后修改。历史记录必须保持不可更改，因为任何改动都会导致缓存未命中。此外，JSON序列化也必须是确定性的，因为键的顺序很重要。
还有一种常被称为“MCP税”的问题。假设10到15种工具各自携带1万到1.5万个定义标记，那么在用户输入任何内容之前就已经产生了10万到22.5万个标记的开销。以1000名开发者每天使用5次会话计算，仅工具定义这一项每年就会耗费约120万美元。解决办法是渐进式展示：及时加载工具而非一次性全部加载。
缓存命中率及四种模式都属于理论范畴。在那些已经在生产环境中遇到过该问题的系统中，实际情况又是怎样的呢？
Claude Code及其他两款产品，三种理念
Claude Code、Cursor 和 Manus 对同一问题给出了三种相互关联却又各不相同的解决方案。每种方案都是基于其自身的使用场景而设计的，并非因为不了解其他选项才如此选择。
Claude Code：静态预加载与即时读取
来自 Anthropic 的 Claude Code 会在会话开始时加载 CLAUDE.md 作为入门文档，随后通过 glob 和 grep 工具在代码库中搜索，无需依赖向量数据库。它能自动压缩约 95% 的内容，同时保留原有的架构设计。据称，将记忆工具与上下文编辑功能结合使用后，性能相比基准值提升了 39%。
Sonnet 4.5 模型存在上下文管理问题，需要定期重置外部上下文。Anthropic 据称在后续版本中解决了这一问题，且未改变该工具的架构设计。
Cursor：双层架构与动态发现
Cursor（由Anysphere开发）将“意图上下文”（即用户的需求）与“状态上下文”（即文件的实时状态、编辑内容及错误信息）分开处理。默认情况下，它仅读取任何文件的前250行，这一设计旨在节省算力成本与费用。
2026年1月出现了一项重要变化。Cursor表示，随着模型作为智能体功能愈发强大，事先提供较少细节、让智能体自行获取相关上下文的效果更好。此前进行的A/B测试显示，采用这种按需加载方式可减少46.9%的算力消耗。
Manus：通过试错实现梯度下降
Manus将其方法称为“随机梯度下降”，以文件系统作为最终上下文。据称自2025年3月以来，该团队已五次重构其框架。Ji总结道：上下文构建远非如此简单，而是一门实验性科学。
该团队提出了六项原则：
- 优先考虑KV缓存。
- 使用掩码工具而非直接删除它们，以保留缓存。
- 将文件系统视为无限的外部内存。
- 反复回顾待办清单，将注意力集中在整体计划上。
- 将错误保留在上下文中，因为删除失败记录会丢失证据。
- 变换序列化模板，以避免少样本陷阱。
对比分析带来的启示
没有哪种哲学是绝对正确的。Claude Code专为需要稳定性的长时间编码会话设计，而Cursor则针对需要动态响应编辑器上下文的短时辅助会话。Manus则是为能够每项任务执行50次及以上工具调用的完全自主型网络智能体打造的。Manus的五次重构表明了一个基本事实：上下文工程是一门经验性学科，而非一次设计完成即可永久使用的蓝图。每个生产系统都需要经历自身的迭代过程。
人们很容易认为增加上下文窗口就能解决问题，因为一百万个标记应该已经足够了。但NoLiMa和Chroma的数据很快便打破了这一假设。Claude 4 Sonnet在抵抗上下文失效方面的表现明显优于旧模型，但这只是个例，无法证明问题已经消失。
那些系统与模式涵盖了有效的方法。剩下的工作是将它们转化为针对特定智能体的具体设计选择，并判断上下文设计是否发挥了应有的作用。
设计蓝图：该使用什么，以及如何衡量
2026年3月发表的一篇关于企业多智能体架构的论文（arXiv:2603.09619，探讨从提示词转向上下文工程）提出了五个评估上下文质量的标准，并将上下文视为智能体的操作系统：
- 相关性。该信息是否与当前的决策步骤相关？无关的上下文只会带来负面影响。
- 充分性。智能体是否拥有做出决策所需的所有信息，而无需猜测？
- 隔离性。不同智能体的上下文是否得到妥善分隔，以避免A租户的数据泄露给B租户？
决策路径
对于短期任务，步骤数在20步以内且没有长距离依赖时，滑动窗口即可满足需求。只需保留最近的N轮对话以及系统指令即可。这样没有额外开销，实现方式也最为简单。
对于长期任务，如果第5步的决策会影响第50步的结果，则需要使用能够保留架构决策的压缩方法。在容量达到80%左右时发出警告，在95%左右时自动进行压缩。
对于包含10种以上工具的独立子任务，应使用能够生成1K到2K个标记符长度摘要的子代理，每个子代理在独立的窗口中运行。
对于工具众多但会话时间较短的情况，应按需加载工具而非预先加载所有工具。逐步披露机制可避免MCP带来的性能负担。
需要监控的指标
如果没有这些指标，上下文架构将缺乏可观测性：
- 标记符增长速率。如果呈现稳定单调增长趋势，说明没有采用压缩策略；而出现上升、重置后再上升的锯齿状变化，则表明压缩策略正在起作用。
- KV缓存命中率。若低于50%，则说明系统提示语的前缀部分一直在变化。应首先检查时间戳及其他动态元素。
- 35分钟启发式规则。智能体在完成约35分钟的同等任务时间后表现似乎会下降，因此规划检查点时应考虑这一因素。
- 压缩后的遗忘现象。如果智能体重新探索它已经探索过的区域，说明压缩强度可能过大。
对于设计这类系统的人来说，有一个明显的问题：目前没有标准指标来衡量压缩过程中丢失的信息量。错误会在之后显现，而非在压缩发生的瞬间。最佳的压缩时机仍是一个未解之谜——过早压缩会浪费时间，而过晚压缩则会导致问题恶化。
SWE-ContextBench（arXiv:2602.08316）的研究也支持了这一点，发现未经筛选或选择不当的经验只能带来有限甚至负面的效果。更多的上下文并不总是更好，不良的上下文反而会带来危害。
长时运行智能体的上下文工程规则
设计上下文处理流程与询问什么是上下文工程是两个不同的问题，由此可得出几点结论。
- 上下文衰减是变换器模型的固有特性。更优秀的模型无法解决这一问题，需要通过内存架构来管控。
- 模型相当于CPU，上下文相当于RAM，而上下文工程则相当于智能体的操作系统，这使得讨论范畴从语言学转向了系统工程。
- 写入、筛选、压缩和隔离是相互补充的环节而非替代关系，每个实际应用的智能体都会使用这四种功能。
- 需要关注的是KV缓存的成功访问率，系统提示中一个多余的时间戳就可能导致每月费用增加数万美元。
- 正如Claude Code、Cursor和Manus所展示的，不存在唯一正确的理念。
一个实际的第一步是在下一次智能体设计评审中为上下文安排专门讨论环节：包括状态存储方式、KV缓存的处理方法、压缩阈值设定，以及哪些子任务应分配给子智能体。这并非简单的性能优化，而是构建可靠系统的基础。