本页目录8
- Context engineering 是「在每一步推理中,为模型精选最小、信号密度最高的 token 集合」,是比 prompt engineering 更持续、更迭代的过程。
- Context Rot:上下文越长,模型的「注意力预算」越紧张,长距离检索与推理精度会下降,因此不能无脑堆砌上下文。
- System prompt 要找到「right altitude」——既不能写死复杂的 if-else 逻辑,也不能笼统模糊;建议用 XML 标签或 Markdown 分节,从最小可行版本开始迭代。
- 工具集要精简、职责清晰、参数无歧义:如果人类工程师都说不清该用哪个工具,agent 也做不到。
- 长任务(数十分钟到数小时)可组合使用 compaction(压缩历史对话)、结构化笔记(写入上下文外的持久文件)、子代理架构(主代理只接收浓缩摘要)三种技术维持连贯性。
- Agentic search 提倡「just-in-time」按需检索(如文件路径、Bash 查询)而非预先把所有数据塞进上下文,更接近人类不背整本资料库的认知方式。
本文是对 Anthropic 官方文章《Effective context engineering for AI agents》的中文要点摘要,完整内容以原文为准:https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
从 Prompt Engineering 到 Context Engineering
文章开篇提出一个转变:构建 LLM 应用的关注点,已经从「找到正确的措辞」(prompt engineering)转向「什么样的上下文配置最可能让模型产生期望行为」(context engineering)。
两者的区别:
- Prompt Engineering:针对单一任务优化某一条提示词,是离散的一次性工作。
- Context Engineering:「在 LLM 推理过程中,持续筛选和维护最优 token(信息)集合的一整套策略」,是随 agent 多轮运行不断迭代精炼的过程——因为「an agent running in a loop generates more and more data that could be relevant for the next turn of inference」。
为什么上下文工程对 Agent 至关重要:Context Rot
研究表明,随着上下文长度增加,模型准确回忆信息的能力会下降,这被称为「Context Rot」。原因与 Transformer 架构中 token 间 n² 的成对关系有关——模型存在一种「attention budget(注意力预算)」,处理大量上下文时会被逐渐消耗。即便模型能处理很长的上下文窗口,检索精度和长距离推理能力仍会打折扣,这正是需要精心做上下文工程的原因。
System Prompt:找到「right altitude」
核心原则是追求「the smallest possible set of high-signal tokens」。建议避免两个极端:
- 过度具体:把复杂的 if-else 逻辑硬编码进提示词,导致脆弱、难维护。
- 过度笼统:给出模糊指导,或错误假设模型和人类拥有相同的隐含背景知识。
实践建议:
- 用 XML 标签(如
<background_information>、<instructions>)或 Markdown 标题(如## Tool guidance)组织不同信息区块。 - 从一个最小化的 system prompt 开始测试,再根据实际观察到的失败模式,针对性补充说明和示例——而不是一开始就写「大而全」。
工具(Tools)设计
- 工具返回的信息要 token 高效,并引导 agent 采取高效行为。
- 工具应「self-contained、robust to error、且用途表述清晰无歧义」。
- 常见反模式是工具集功能重叠、边界模糊,文章直言:「如果人类工程师都说不清某种情况该用哪个工具,agent 也不可能做得更好」。
- 应维护一个最小可行的工具集,便于长期维护和上下文裁剪。
Few-shot 示例仍然重要
文章依然推荐在提示词中使用示例,但提醒不要堆砌大量边界案例(exhaustive edge cases),而是应「精选一组多样化、具有代表性的典型示例(canonical examples)」来展示期望行为——「对 LLM 而言,示例就是胜过千言的一张张图片」。
Agentic Search:按需检索而非预加载
传统做法是提前用 embedding 做检索、把结果一次性塞进上下文;而更好的做法是「just-in-time」策略——只维护轻量标识符(文件路径、查询语句、链接等),在运行时按需动态加载数据,而不是预先加载全部内容。文章类比这更接近人类认知:我们通常不会去背下整本资料库。
以 Claude Code 处理大型数据库分析为例:模型会自己编写查询、把中间结果存起来、用 Bash 命令做后续分析,而不是把整张表塞进上下文。此外,文件夹层级、命名规范、时间戳等「检索元数据」本身也是重要信号,能帮助 agent 判断信息的用途和使用时机——这种通过探索逐步建立理解的方式被称为「渐进式信息披露(progressive disclosure)」。
代价是:运行时探索通常比预计算检索慢,需要精心设计工具和启发式规则来配合;实践中也可以采用「预检索+运行时探索」结合的混合策略。
长任务的上下文管理:三种核心技术
面对跨越数十分钟到数小时、远超单个上下文窗口的长任务,文章给出三种可组合的技术:
-
Compaction(压缩):上下文接近上限时,把历史对话交给模型汇总,再用摘要重启一个新的上下文窗口。Claude Code 的做法是保留架构决策、未解决的 bug 和关键实现细节,丢弃冗余的工具调用与输出。要点在于:先追求「最大化召回」,确保压缩提示词能捕捉到所有相关信息,再逐步精简,避免压缩过度导致关键上下文丢失。
-
结构化笔记(Structured Note-Taking):agent 定期把笔记写入上下文窗口之外的持久存储(如文件),开销很小却能提供跨长任务的持久记忆。例如 Claude Code 会维护待办清单;在「Claude 玩宝可梦」的例子中,agent 在数千步操作中靠自己写的笔记(计数器、地图、战斗策略等)在上下文重置后继续推进任务。Anthropic 也发布了对应的基于文件的 memory 工具(Claude Developer Platform 公测中)。
-
子代理架构(Sub-Agent Architectures):让专门化的子代理处理聚焦的子任务,而不是让单一 agent 维护整个项目的全部状态。主代理负责统筹和制定高层计划,子代理各自可能消耗数万 token 做深度搜索或技术工作,但只向主代理返回 1000-2000 token 的浓缩摘要,从而实现关注点分离。
三者的适用场景大致是:compaction 适合需要大量往返、保持对话连贯的任务;note-taking 适合有明确里程碑的迭代式开发;子代理架构适合复杂研究分析、能从并行探索中获益的场景。
小结
文章认为,上下文工程代表了构建 LLM 应用方式的根本转变:挑战不再只是写出完美的一条提示词,而是要在每一步都精心筛选进入模型有限注意力预算的信息。无论是做压缩、设计 token 高效的工具,还是让 agent 自主做 agentic search,指导原则始终一致——找到能最大化期望结果概率的、信号密度最高的最小 token 集合。文章也指出,随着模型能力提升,所需的显式工程会减少、agent 会获得更多自主权,但把上下文当作稀缺资源来对待,仍将是构建可靠、有效 agent 的核心思路。