上下文工程（Context Engineering）的本质，是在大模型有限的注意力预算里，只放入「最小且高信号」的 token 集合——不是把资料塞满上下文窗口，而是让每一个进入上下文的 token 都真正改变模型的输出概率。上下文变长会引发 context rot（上下文腐烂），模型召回与长程推理精度会梯度式下降；因此比”换更大窗口”更有效的做法是：控制提示高度、压缩工具集、清理工具结果、把记忆外置、用子代理隔离探索噪声。
Anthropic 在工程博客《 Effective context engineering for AI agents 》中把这条原则写得很直白：找到 the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome。本文把它拆成 6 个可以今天就在项目里落地的动作。
上下文腐烂：为什么塞得越满越笨
Transformer 里 n 个 token 会产生 n² 量级的成对注意力关系，而训练分布中短序列远多于长序列。结果是：上下文越长，模型对其中信息的回忆能力越弱，而且这种退化是梯度式的，不是到某个阈值才突然崩掉——你只会感觉它”越来越不准”，却很难定位。
所以上下文是消耗品：每增加一个 token 都在稀释其他 token 的权重。这也是为什么”等 200 万 token 窗口出来就好了”这个想法不成立——只要你在跑长任务，上下文污染管理就不会消失。
动作一：系统提示保持在「正确高度」
系统提示有两个典型失败极端，中间那条窄路才是对的：
- 过脆：把
if-else逻辑硬编码进提示词，试图精确触发行为。短期有效，长期维护成本爆炸，模型一换版本就崩。 - 过虚：只给”你是一个专业的助手”这类高层指导，缺少具体信号，还默认模型已经知道你的业务口径。
正确高度是：specific enough to guide behavior, yet flexible enough to give the model strong heuristics。做法上，把提示词按区块切分，用 XML 标签或 Markdown 标题界定：
<background_information>
你是内部客服工单系统的 Agent，只对已登录用户开放。
</background_information>
## Tool guidance
优先用 search_order 定位订单，禁止直接查库表。
## Output description
只输出 JSON，不要解释。迭代顺序也很关键：先用最小提示 + 当前最强模型跑一遍，根据暴露的失败模式再加指令，而不是一开始就写三千字规范。
动作二：维护「最小可用工具集」
工具定义了 Agent 与信息/行动空间之间的契约，所以它必须同时满足两件事：返回 token 高效、鼓励高效行为。常见失败是工具集臃肿，导致”该用哪个工具”本身产生歧义。
一条实用的判断标准：如果人类工程师都说不清某个场景该用哪个工具，就别指望 Agent 能选对。把工具砍到最小可用集，既减少歧义，也让长对话中的上下文维护变得可控。
工具设计自查清单（展开）
- 工具是否自包含、抗错、用途一句话说得清？
- 输入参数是否描述性强且无歧义？
- 返回值是否只带必要字段，而不是整张数据库行？
- 是否让 Agent 拿到轻量标识符（文件路径、查询 ID 、 URL）而不是整块数据？
- 是否存在功能重叠的两个工具？有就合并。
动作三：少样本示例要「典型」，不要「穷举」
Few-shot 依然是强推荐实践，但很多人把边缘案例堆成”洗衣清单”，试图穷举所有规则——这不推荐。正确做法是挑选一组多样化、规范化（canonical）的示例，让示例本身承载行为范式。对模型来说，示例是”一图胜千言”。
动作四：压缩（Compaction）——长任务的第一手段
当对话逼近窗口上限，用模型对历史做高保真摘要，再用摘要开启新上下文。保留什么、丢掉什么，是压缩的全部艺术：
| 保留 | 丢弃 |
|---|---|
| 架构决策、未解决 bug 、关键实现细节 | 重复的工具输出 |
| 任务目标与依赖关系 | 已失效的中间结果 |
| 用户明确给出的硬约束 | 冗余的确认性消息 |
调压缩提示词分两步：先在复杂 trace 上最大化召回，确保摘要覆盖所有相关信息；再迭代提升精确率，剔除多余内容。另外，最轻量的压缩手段是工具结果清理——深层历史里被调用过的工具，其原始调用与返回几乎不必再出现在上下文中。
动作五：结构化笔记，把记忆放在上下文之外
让 Agent 定期把笔记写到上下文窗口之外的持久化介质（文件、数据库、 memory 目录），需要时再读回。开销极小，却能支撑跨小时、跨会话的长周期任务。最简单的形态就是一个 NOTES.md 或待办清单：目标、已完成项、关键决策、依赖关系。
动作六：子代理架构隔离探索噪声
复杂研究/分析类任务，让主代理只做高层计划与综合，子代理带着干净的上下文深挖子任务，最后只回传 1,000–2,000 token 的精炼摘要。这样主上下文不会被几万 token 的探索细节淹没。
三项技术怎么选
| 技术 | 适用场景 | 代价 |
|---|---|---|
| 压缩 Compaction | 多轮对话、要保持对话流连贯 | 可能丢失后续变关键的细节 |
| 外部笔记 Note-taking | 有清晰里程碑的迭代开发 | 需要自己设计读写时机 |
| 子代理 Sub-agent | 可并行探索的研究/分析任务 | 编排复杂、延迟更高 |
- 统计当前每轮请求的 token 构成：系统提示、工具定义、历史消息、工具返回各占多少。
- 把系统提示重写为「背景 / 指令 / 工具指引 / 输出描述」四个区块，删除所有硬编码 if-else 。
- 砍工具：合并功能重叠项，返回值改成分页或字段裁剪。
- 加上工具结果清理——超过 N 轮的历史工具返回不再回传。
- 设置压缩触发线（建议窗口用量的 70–80%），写好保留项白名单。
- 建立 NOTES.md 外部记忆：目标、已完成、关键决策、依赖，上下文重置后先读它。
常见误区
- 以为上下文工程就是提示词工程：提示词只是上下文的一个组件，工具、示例、消息历史、外部记忆同样要治理。
- 一次写好、长期不动：上下文是每轮都要重新策划的，不是一次性配置。
- 为了短而牺牲必要信息：minimal 不等于 short，模型仍需足够前置信息来约束行为。
上下文工程（Context Engineering）和提示词工程有什么区别？
上下文窗口越来越大，还需要做上下文管理吗？
压缩（Compaction）应该在什么时机触发？
外部笔记和 Agent 记忆系统是一回事吗？
相关阅读
阅读 Anthropic 原文：Effective context engineering for AI agents本文基于 Anthropic 官方工程博客的观点与实践经验重新组织撰写，结论与落地清单为本站整理。
评论 (0)