你的 AI 助手在前 10 步表现完美。
然后到了大约第 15 步，它开始变得马虎。
工具调用错误，忘记原始指令，输出质量低下。
大多数人都怪模型。
但几乎从来不是模型的问题。
而是模型看到的内容有问题。
组织模型看到的内容，叫做上下文工程。
它正在迅速成为构建 AI Agent 最重要的一项技能。
以下是完整的操作手册。
提示工程已死。上下文工程才是现在最重要的。
你听说过提示工程。
编写清晰的指令，给出好的示例，告诉模型扮演什么角色。
这对聊天机器人来说很有效。
但当你构建一个 Agent 时，它就不再管用了。
原因如下。
聊天机器人回答一个问题就停止。
而 Agent 会执行操作——浏览网页、调用 API、编写代码、运行命令——一步接一步，有时甚至数十步。
每一步都会产生输出，这些输出被添加到模型的上下文中。
而上下文是有限的。
Anthropic 的工程团队是这样定义的：
“上下文是从 LLM 采样时包含的 token 集合。上下文工程就是优化这些 token 的效用，以持续达成期望的结果。”
简单来说：确保你的 Agent 在正确的时间，以正确的格式，看到正确的信息。
提示工程是上下文工程的一个子集。
上下文工程才是一切。
你 Agent 的上下文窗口就是 RAM。而且它正在被填满。
LangChain 对此有一个很好的类比。
把 LLM 想象成一种新型操作系统。
模型是 CPU——它负责思考。
上下文窗口是 RAM——工作内存，模型当前能看到和推理的一切都存在于这里。
就像你的电脑在 RAM 充满时会变慢一样，当上下文窗口变得拥挤时，Agent 的推理能力也会下降。
这叫做上下文腐烂。
Chroma 进行了一项研究，评估了 18 个前沿模型——GPT-4.1、Claude 4、Gemini 2.5、Qwen3 等。
每个模型的性能都随着输入长度的增加而下降。
不是在硬限制处，而是在那之前就开始了。
一个拥有 20 万 token 窗口的模型，可能在 5 万 token 时就表现出显著的退化。
这种下降是连续的，而不是断崖式的。
为什么？Transformer 的工作原理是每个 token 都关注其他所有 token——产生 n 平方的关系。随着上下文增长，模型维持所有这些关系的能力会减弱。
此外还有“迷失在中间”的问题。
LLM 表现出 U 形的注意力曲线。
→ 上下文开头：记忆良好
→ 上下文结尾：记忆良好
→ 中间：很大程度上被忽略
研究人员发现，当相关信息从上下文开头移到中间时，准确率下降了 30 多个百分点。
你最初的指令——被埋藏在 5 万 token 的工具输出之下——实际上就消失了。
Claude Code 用户发现，在上下文容量达到 40–60% 时，输出质量就会下降。远在任何硬限制之前。
实际上在 Agent 上下文中争夺空间的是什么
7 个类别。全部在争夺同一个有限的窗口。
1. 系统提示
Agent 的身份、行为规则、控制流逻辑、不同任务类型的指令。在 Agent 中，这不仅仅是“有帮助”，它可以定义整个架构。
2. 工具定义
Agent 可能调用的每个工具都需要一个模式，描述它的功能、所需参数以及何时使用。
3. 工具调用结果
每次工具调用都会将其输出添加到上下文中。一次网页检索：5000–10000 token。一次文件读取：类似。这些积累得很快。
4. 检索知识（RAG）
从向量数据库检索的文档、搜索结果、API 响应——任何用来告知 Agent 决策的信息。
5. 对话历史
所有已发生事件的完整记录。用户消息、Agent 响应、推理过程、之前的决策。每轮对话线性增长。
6. 记忆
当前会话的短期记忆。之前会话的长期记忆——用户偏好、先前结果、学习到的模式。
7. Agent 状态
当前计划、待办事项列表、进度标记、草稿笔记。跟踪 Agent 在多步任务中所处位置的元信息。
全部 7 个竞争同一个窗口。
上下文工程就是决定什么能胜出。
4 大核心策略
LangChain 发布了一个框架，将所有上下文工程技术组织为 4 个类别。
你将要学到的每一项技术都属于其中之一。
写入。选择。压缩。隔离。
策略 1 — 写入（Agent 会遗忘。给它们一种记住的方式。）
当 Agent 的上下文被填满并压缩时，它会丢失信息。
如果 Agent 在此之前没有写下任何东西——这些信息就永远消失了。
写入意味着给 Agent 提供在上下文窗口之外持久化信息的方法。
三种形式：
草稿板
给 Agent 一个工具，让它在任务过程中做笔记。中间发现、做出的决定、它知道以后需要的信息。
Anthropic 构建了一个“思考”工具——一个专门的空间，让 Claude 解决问题。
在 tau-bench 基准测试中，这使某些任务的性能提升了高达 54%。
规则文件
持久的过程记忆。
如果你用过 Claude Code，你见过 CLAUDE.md。
在每次会话开始时加载的指令——项目架构、约定、如何运行测试、需要注意什么。
Agent 每次启动都会阅读它。
它永远不会忘记基础。
记忆提取
Agent 保存事实、用户偏好和学习到的模式，以便在会话之间检索。
完全存在于上下文窗口之外。
Agent 明天需要的信息，明天到来时就在那里等着。
策略 2 — 选择（不要给 Agent 所有东西。只给它当下需要的。）
一个拥有 40 个工具、一个大型知识库和多个会话历史的 Agent，无法一次性加载所有内容。
必须有东西来决定当前步骤哪些是相关的。
传统 RAG：系统决定。
用户提问 → 检索文档 → 塞入提示 → 完成。
静态的，一次性。模型没有发言权。
Agentic RAG：Agent 决定。 它搜索所需内容，优化查询，选择工具，判断何时拥有足够信息。
检索是一个迭代过程，而不是一次性管道。
这一点很重要，因为每一步的相关性都在变化——只有 Agent 知道下一步需要什么。
工具选择问题是最让人头疼的。
如果你的 Agent 有 40 多个工具，那么在工作开始之前，上下文中就可能已经存在多达 10,000 token 的工具定义。
解决办法：对工具描述进行 RAG。
不要每次调用都转储所有工具定义，而是使用语义搜索只暴露与当前步骤相关的工具。
一篇名为 RAG-MCP 的论文对此进行了测试。
工具选择准确率：从 14% 提升到 43%（提升了 3 倍）。Token 使用量：大约减半。
Anthropic 称之为混合策略：预先加载必要的上下文（如 CLAUDE.md），让 Agent 即时检索其他所有内容。
提前加载基础。按需检索其余。
策略 3 — 压缩（上下文会累积。保留含义，削减 token。）
即使选择了好的内容，上下文仍然会累积。
每次工具调用、检索到的文档和决策都留在窗口中。
想象你的 Agent 已经进行了 20 次工具调用。
上下文：累积的 80,000 token 工具输出、对话历史、推理痕迹。
其中大部分已经不再相关。Agent 已经处理过了。
但它们仍然存在，占用空间，削弱注意力，推高成本和延迟。
你可以在 3 个点进行压缩。
在信息进入上下文之前：
→ 将大型文档分割成连贯的块，然后再检索
→ 进行重排序，只让最有用的块进入
→ 在工具输出进入主上下文之前，实时总结它们
在 Agent 工作时：
→ 对话历史的滚动摘要——持续更新
→ 流行混合方案：保留最近 10 条消息原文 + 总结所有更早的消息
→ 硬修剪：一旦上下文达到大小阈值，删除较早的消息
→ Claude Code 自动压缩：在容量达到 95% 时触发，自动总结整个轨迹
在 Agent 对某件事采取行动之后：
→ 清除工具结果：一旦某个工具结果在 15 步之前被使用，就丢弃它
→ 用一行总结替换，或者完全删除
→ Agent 不需要它在 20 步之前获取的网页全文
目标：减少 token 数量。保留真正重要的东西。
策略 4 — 隔离（最强大的策略。实现多 Agent 系统。）
这是长 Agent 运行中的更深层问题。
不仅仅是空间问题。还有污染问题。
研究阶段的详细文件搜索，当 Agent 转到编写代码时仍留在上下文中。
那些旧的研究上下文现在是噪音。在 Agent 需要专注于干净实现的阶段，它会分散模型的注意力。
隔离意味着给工作的不同部分各自独立的上下文窗口。
子 Agent
父 Agent 将集中的子任务（例如“搜索代码库中所有与认证相关的文件”）委托给子 Agent。
子 Agent 在自己的干净上下文窗口中工作。
当它汇报时，只返回一个精炼的摘要。
所有混乱的搜索操作都隔离在子 Agent 的上下文中，永远不会污染父 Agent。
状态模式隔离（LangGraph 的方法）
设计 Agent 的状态，使不同的字段存储不同类型的上下文。
LLM 只看到与当前步骤相关的字段。
工具结果存放在“后台”字段中——对模型不可见，直到明确地暴露出来。
无需启动单独的子 Agent，即可精细控制 Agent 在每个步骤看到的内容。
隔离是使复杂多步工作流真正可靠的原因。
不同的工作。不同的上下文窗口。没有污染。
Agent 失败的 4 种方式（找出失败原因。修复它。）
Drew Breunig 确定了 Agent 上下文增长时四种不同的失败模式。
你见过的每一个出问题的 Agent 都属于其中之一。
失败模式 1：上下文中毒
幻觉或错误进入上下文。
Agent 在后续步骤中一次又一次地引用它。
第 5 步的错误数据会累积到之后的每一步。
修复： 在工具输出进入上下文之前进行验证。从错误中恢复后，压缩失败尝试的历史。不要保留 10 步死胡同调试的痕迹，只保留最终解决方案。
━━━
失败模式 2：上下文分心
上下文变得太长，模型开始过度依赖最近的历史。
不再综合制定新计划，而是重复最近做过的事。
它停止思考。开始重复。
修复： 积极总结和修剪。即使你有很大的上下文窗口可用。大的窗口并不意味着要填满它。
━━━
失败模式 3：上下文混乱
多余的内容导致模型做出低质量的决策。
经典例子：当给定 46 个工具时，模型在基准测试中失败——尽管上下文完全在限制之内——但只给 19 个工具时却能正常工作。
工具不是多到上下文装不下。
而是多到模型无法清晰推理。
修复： 动态工具管理。使用 RAG-MCP 只暴露与当前步骤相关的工具。保持工具集与当前阶段匹配。
━━━
失败模式 4：上下文冲突
新信息与上下文中已有的信息矛盾。
系统提示说一件事。检索到的文档说了另一件事。
Agent 无法调和矛盾。产生不一致的行为。
修复： 建立明确的权威顺序。系统提示 > 检索到的事实 > 对话历史。在注入新信息之前，先与现有上下文进行验证。使用 XML 标签和清晰的标题，让模型知道哪个来源可信。
如何为 Agent 编写系统提示（不是聊天机器人。是 Agent。）
聊天机器人的系统提示设定一个语气。
“你是一个有用的助手。简洁友好。”
Agent 的系统提示定义架构。
它指定控制流——如何处理任务类型、何时使用哪些工具、出错时该怎么做、要遵循哪些护栏。
这更像是为自主员工编写职位描述，而不是编写个性提示。
Anthropic 称之为在“正确的高度”编写。
过于规定性： “如果用户提到账单并且提到退款并且金额超过 100 美元，则调用工具 X。” 脆弱。在你没有预料到的每个边缘情况上都会失败。
过于模糊： “要乐于助人并使用适当的工具。” 没有给 Agent 任何信息。没有具体的信号，它无法做出好的自主决策。
最佳点： 具体到足以指导自主行为。灵活到让模型在新情况下运用判断。强启发式。不是死板的规则。
实用技巧：
→ 使用 XML 标签或 Markdown 标题组织——背景、指令、工具指南
→ 从最小化开始，在失败中迭代——不要试图一开始就预见所有边缘情况
→ 最小化并不意味着短——一个复杂的 Agent 系统提示可能有几千 token，只要每个 token 都有其价值，这没问题
→ 使用少量示例——向 Agent 展示好的行为是什么样的，而不是试图用文字描述每条规则
KV 缓存：关心上下文顺序的 $$$ 原因
大多数 Agent 构建者不知道这个存在。
当你向 LLM 发送 token 时，模型会为每个 token 计算键值表示。
计算成本很高。
因此推理提供商会缓存这些表示。
如果你的上下文开头——前缀——在 API 调用之间保持不变，提供商会重用缓存的计算，只处理末尾的新 token。
快速。便宜。
但如果你在调用之间重新排列或更改上下文的早期部分——你就会使缓存失效。提供商会从头开始重新计算所有内容。
在 Claude Sonnet 上的成本差异：
→ 缓存输入 token：每百万 0.30 美元
→ 非缓存输入 token：每百万 3.00 美元
相差 10 倍。
对于一个每个任务进行 30–40 次 API 调用的 Agent 来说，这很快累积起来。
KV 缓存效率的实用规则：
→ 稳定内容放在上下文顶部——系统提示、工具定义、任何在轮次之间不变的内容
→ 动态内容放在上下文底部——对话历史、当前步骤、Agent 状态
→ 不要在对话中动态添加和移除工具——这会使缓存失效
→ 使用工具屏蔽而不是工具移除——将所有工具定义稳定地放在前缀中（缓存），只需将不相关的标记为当前阶段不可用
7 小时交付 35,000 行代码的工作流
Dex Horthy（HumanLayer 的 CEO）在 AI Engineer Code Summit 上展示了这个。
据报道，他的团队使用这种方法在 7 小时内向一个大型 Rust 代码库交付了约 35,000 行代码。
方法：频繁的意图压缩。
将 Agent 工作结构化为多个阶段。每个阶段产生一个压缩的产物。每个新阶段从一个只包含该产物的全新上下文窗口开始。
始终保持上下文窗口在 40–60% 以下。
阶段 1 — 研究
子 Agent 探索代码库。读取文件。追踪数据流。绘制架构图。
所有混乱的 grep 结果和文件内容都留在子 Agent 的上下文中。永远不会触及父 Agent。（隔离）
输出：一个紧凑的 research.md——文件路径、函数签名、模式、陷阱。（写入）
上下文重置：原始研究使用了 60–80% 的窗口。研究产物将其压缩到 15–20%。（压缩）
阶段 2 — 规划
新的上下文窗口。只包含：研究文档 + 问题定义。
Agent 生成详细的实施计划。
这是最重要的人工审查检查点。
在这里发现逻辑错误，修复起来既容易又免费。之后修复就会花费数小时。
阶段 3 — 实施
再次全新的上下文窗口。只包含：计划。
Agent 一步步执行。
对于复杂任务：用 progress.md 跟踪已完成和剩余的工作。（写入）
结果：在每个阶段都有一个干净、专注的 Agent。没有污染。没有上下文腐烂。没有“第 20 步变得马虎”。
最佳平台如何处理这些差异
Claude Code
混合检索。CLAUDE.md 预先加载。像 glob 和 grep 这样的工具处理即时代码库导航。
在 95% 时自动压缩——保留架构决策和最近访问的 5 个文件。
可以为复杂的子任务生成子 Agent，每个子 Agent 都有自己干净的上下文。
理念：“做最简单有效的事。”让模型聪明地知道需要什么，并给它工具去找到它们。
Manus
KV 缓存感知的上下文排序：稳定前缀，动态后缀。使用工具屏蔽而不是移除。
观察压缩管道——每个工具输出在进入 Agent 上下文之前都要经过处理。
持久待办事项列表用于状态追踪。
文件系统作为溢出内存存储被驱逐的上下文。
专为规模构建。服务数十万用户，效率是业务成本问题。
ChatGPT Agent
以视觉为先的方法。Agent 与 GUI 浏览器交互。
截图作为视觉快照添加到上下文中。模型在自己看到的内容上进行推理。
视觉 token 很昂贵，因此 Agent 会选择性截图。
使用强化学习在数千台虚拟机中学习最优工具使用策略，而不是显式编程。
Google ADK
最严谨的架构方法。
三个设计原则：
- 分离存储与呈现——持久状态不等于每次 API 调用中出现的内容
- 显式转换——命名、有序的处理器，以可测试、可组合的方式转换上下文
- 默认限定上下文范围——每个模型调用只看到所需的最小信息
工程纪律胜过提示技巧。
通用的 Agent 轮次管道
每个严肃平台都收敛到每个 Agent 轮次的同一个 5 步循环：
→ 收集 — 用户输入、对话历史、工具结果、检索到的文档、Agent 状态
→ 选择 — 在剩余 token 预算内，当前步骤相关的内容
→ 压缩 — 总结、截断或重组以适应上下文
→ 排列 — 稳定内容在前（缓存），动态内容在后
→ 组装并调用 — 最终上下文 → API 调用 → 获取输出 → 循环
这就是你使用过的每个生产 Agent 内部运行的循环。
理解这个循环，是那些能交付可靠 Agent 的构建者与那些纳闷为什么他们的 Agent 在第 15 步就变得马虎的构建者之间的区别。
总结
上下文腐烂是真实存在的，并且早在你的上下文限制之前就开始了。
修复它的 4 个策略：
→ 写入 — 在上下文之外持久化信息，这样 Agent 就不会忘记
→ 选择 — 只拉入当前步骤需要的内容
→ 压缩 — 削减 token，保留含义，主动而非被动
→ 隔离 — 不同工作使用不同上下文，没有污染
需要注意的 4 种失败模式：
→ 中毒 — 错误数据在每一步累积
→ 分心 — 长历史让 Agent 重复而不是思考
→ 混乱 — 太多工具降低决策质量
→ 冲突 — 矛盾导致行为不一致
KV 缓存可节省 10 倍成本。将稳定内容放在前面。
最佳工作流：研究 → 压缩 → 规划 → 压缩 → 实施。每个阶段使用新上下文。
上下文工程对于认真的 Agent 工作来说不是可选项。
它就是工作本身。
如果这有用：
→ 转发分享给你认识的每一位 Agent 构建者
→ 关注 @sairahul1 获取更多在你睡觉时也能运行的系统
→ 收藏本文——你会回来参考这 4 个策略框架的
我写关于 AI、产品构建和实际可行的系统的内容。
