很多人应该都有过类似的经历：第一次用AI处理复杂任务时，效果往往很好。你把要求说清楚，给它几份资料，它很快就能抓住重点。但随着对话越来越长，事情开始变得奇怪。前面明明强调过的要求，它后面忘了；已经否掉的方案，它隔了几十轮又重新提出来；你为了避免它犯错，又继续补背景、加规则、塞案例，最后Prompt越来越长，聊……

从“写好Prompt”到“管理AI的注意力”，个人用户该如何理解Context Engineering，编译自 Anthropic《Effective context engineering for AI agents》｜2025年9月29日，头图来自：AI生成

很多人应该都有过类似的经历：第一次用AI处理复杂任务时，效果往往很好。你把要求说清楚，给它几份资料，它很快就能抓住重点。但随着对话越来越长，事情开始变得奇怪。前面明明强调过的要求，它后面忘了；已经否掉的方案，它隔了几十轮又重新提出来；你为了避免它犯错，又继续补背景、加规则、塞案例，最后Prompt越来越长，聊天窗口越来越满，AI却没有因此变得更可靠。

更让人困惑的是，资料明明就在对话里。它不是“没看过”，而是像一个桌面堆满文件、连续工作了十几个小时的人：东西都在眼前，却越来越难准确找到此刻真正需要的那一页。

过去遇到这种情况，我们最容易得出的结论是：Prompt写得还不够好。于是继续研究提示词，增加角色设定、步骤要求、注意事项和示例。最近重看了Anthropic应用AI团队在《Effective context engineering for AI agents》中提出的判断，有了新的理解：当AI从一次性问答走向能够连续搜索、读文件、调用工具、执行几十分钟甚至数小时任务的Agent之后，问题已经不只是“你该怎么跟AI说话”，而是“在每一步，它究竟应该看到什么”。

这就是Context Engineering——上下文工程。对普通用户来说，这听起来像一个偏开发者的概念，但它其实解释了大量日常使用AI时最令人抓狂的问题，也给出了一个很实用的方向：想让AI长期稳定地帮你做事，未必需要给它更多信息，反而要学会控制它在每一个时刻看到的信息。

一、你以为自己在写Prompt，其实是在给AI布置“工作台”

Anthropic首先把Prompt和Context区分开来。Prompt Engineering关心的是如何写和组织指令；Context Engineering管理的范围更大，它指的是模型在一次推理时能够看到的全部Token，包括系统指令、工具说明、MCP、外部检索数据、历史消息，以及Agent此前几轮执行产生的中间结果。

如果只是让AI改一封邮件，两者的差别并不明显：你提出要求，模型生成答案，任务结束。但如果你让AI帮你完成一份行业研究，它可能先搜索资料，再读几篇论文，再比较公司数据，然后根据你的反馈修改框架。每走一步，新的搜索结果、旧的对话、临时判断都会继续进入上下文。到这时，真正影响结果的已经不是最开始那一句Prompt，而是模型此刻“工作台”上究竟摆着哪些东西。

Anthropic把Context Engineering视为Prompt Engineering的自然延伸，并用一个问题概括它的核心：“什么样的上下文配置，最可能产生我们想要的模型行为？”这句话对个人用户很有用。以后AI答偏时，不妨先别急着继续补一句“请认真一点”，而是检查：现在这个对话里是不是已经混进太多旧任务、无关资料和相互冲突的要求？

换句话说，Prompt是你给AI的一张任务单；Context则是任务单、参考资料、历史记录、工具和中间结果共同组成的整个工作环境。AI能不能把事做好，越来越取决于后者。

二、最反直觉的一点：能装得更多，不代表能用得更好

今天的大模型不断宣传更长的上下文窗口，这很容易让人形成一种直觉：既然能装几十万甚至更多Token，那就把所有可能相关的资料都放进去，宁可多给，也不要漏给。

Anthropic恰恰提醒人们不要这样理解上下文窗口。它引用了“context rot（上下文腐化）”这一现象：随着上下文中的Token越来越多，模型准确召回其中信息的能力会下降。不同模型退化程度不同，但这种现象具有普遍性。信息并没有从窗口里消失，真正下降的是模型可靠调用这些信息的能力。

Anthropic把模型可用的注意力形容为一种“attention budget（注意力预算）”。每加入一条信息，都在占用这份有限预算。因此真正应该问的不是“这条资料有没有一点关系”，而是“它的重要程度是否值得占用模型的注意力”。

这和个人使用AI时的体验非常接近。比如你要让AI修改一篇3000字文章，最有效的上下文通常是原稿、明确的修改目标、少量风格参考和必须核验的事实来源。如果你同时把过去十篇稿件、几十轮聊天、各种临时想法和大量边缘案例全部塞进去，信息量虽然增加了，真正决定这一次修改质量的信号却可能被稀释。

Anthropic进一步解释，这种退化通常不是突然发生的。模型不会在某一个Token之后立刻失效，它仍然可能保持流畅、完整、甚至非常自信的表达，但事实召回和长距离推理精度已经在悄悄下降。这也是长对话最危险的地方：你看到的语言质量没有明显下降，却很容易误以为它仍然牢牢掌握了前面的一切。

三、真正有效的原则不是“越短越好”，而是“最小充分”

既然上下文是一种有限资源，是不是意味着Prompt和资料越短越好？Anthropic同样否定了这种简单答案。它给出的原则是：找到能够最大化目标结果概率的、最小的一组高信号Token。

这里最容易误解的是“最小”。Anthropic专门强调，minimal does not necessarily mean short——最小并不一定意味着短。复杂任务当然需要足够的背景、约束和资料，真正需要删除的是那些没有显著增加任务成功率、却持续消耗注意力的东西。

对普通用户来说，可以把它理解成“最小充分”：少一条就可能影响判断，多十条却不会让答案更好。比如让AI做一次公司研究，与其一次性丢给它50篇报道，不如先给它研究目标、公司名称、需要回答的关键问题和几份最核心材料，再让它根据任务需要继续搜索。

这也解释了为什么很多所谓“万能Prompt”最终会变得越来越笨重。为了覆盖所有可能情况，人们不断添加规则、例外、示例和禁止事项，最后得到一份几千字甚至上万字的指令。Anthropic建议的方向正好相反：先从最小版本开始，用当前最强的模型跑真实任务，观察它到底在哪里失败，再针对真实失败增加清晰的指令和例子。

这套方法的价值在于，每一条新增规则都有现实原因，而不是为了获得一种“写得越详细越安全”的心理安慰。对于个人用户也是一样：不要一开始就试图写出一份完美Prompt，先让AI做，再根据它真正犯过的错迭代。

四、少给规则，多给“典型例子”

Anthropic仍然非常推荐few-shot，也就是给模型示例。但它反对把大量边缘案例像“洗衣清单”一样堆进Prompt。原因很直接：案例太多会吃掉上下文、稀释真正重要的行为模式，也可能让模型困在表面差异里。

更好的方式是挑少量、多样而典型的标准案例。Anthropic有一句很形象的话：对于LLM而言，例子就是“一图胜千言”的那张图。一个真正好的样例，可以同时告诉AI文章结构、语气、判断标准、信息密度以及什么叫“合格”，这些东西往往比写十条抽象规则更有效。

如果你经常用AI写作，这一点尤其明显。与其告诉它“不要AI味、不要小短句、要像成熟商业编辑、逻辑自然、语言有节奏”，不如同时给它一篇真正符合你标准的文章，再明确指出你要它学习的是段落组织、信息密度和叙述节奏，而不是照抄内容。对模型而言，这种高质量范例往往比继续增加形容词更有用。

但这里同样需要克制。参考文章不是越多越好。你真正需要的是能够清楚表达目标风格的少数代表作。

五、别把整个资料库塞给AI，让它需要时自己去找

Anthropic在文章里提出的另一个重要变化，是“just-in-time context（即时上下文）”。过去很多AI系统喜欢在任务开始前就把可能相关的资料检索出来，一次性塞进模型；随着Agent能力提高，Anthropic越来越倾向于让模型保留轻量引用，在真正需要的时候再动态加载。

Claude Code就是他们给出的典型案例。面对大型代码库，它不会先把所有文件全部放进上下文，而是通过文件路径、查询和head、tail等命令逐步查看真正需要的部分。Anthropic认为，这种方式其实更像人的认知习惯：我们不会背下整个硬盘、邮箱或书架，而是依赖文件夹、书签和搜索，需要时再取回信息。

这一点对个人用户非常实用。如果你让AI帮你做长期研究，与其把几十份PDF全部塞进一个对话，更好的方式往往是先给它任务框架和资料目录，让它先判断需要哪些信息，再逐步读取。做文章也是如此：先让它理解选题和问题，再针对每一部分补对应的原始研究、访谈或数据，而不是一开始把所有资料堆满窗口。

Anthropic把这种过程称为progressive disclosure——渐进式披露。Agent一层层探索，每一次得到的信息都决定下一步去哪里找。工作记忆里只留下当下最需要的内容，其余信息放在外部，需要时再调回来。

这意味着，未来真正好用的Agent不一定是“什么都记得”的Agent，更可能是“知道什么时候该去哪里找”的Agent。

六、对话越来越长时，最有效的动作可能是：重新开一个

这是普通用户最容易立刻应用的一点。很多人已经习惯在同一个ChatGPT或Claude窗口里连续工作几天甚至几周，因为担心新对话会“失去上下文”。但Anthropic的文章实际上给出了另一种思路：当上下文越来越臃肿时，保留关键状态、压缩历史，然后进入一个干净的新窗口，往往比拖着全部历史继续走更可靠。

Anthropic把这种方法称为Compaction。它会把接近窗口极限的对话压缩成高保真摘要，保留架构决策、未解决问题和关键实现细节，删除重复工具输出等已经失去价值的信息，然后用这份摘要重新开始。

个人用户完全可以手动做同样的事。比如一篇文章已经和AI来回修改了30轮，后面越来越混乱，可以让它先整理一份“当前版本工作摘要”：文章目标是什么、已经确认哪些事实、哪些观点已经删除、目前还剩哪些问题、写作风格有什么硬性要求。然后把这份摘要和最新稿件带到一个新对话里继续。

关键不是把旧对话完整搬过去，而是把真正影响下一步工作的状态搬过去。这就是上下文工程最核心的思想：保留信息，不等于保留所有原始记录。

七、长任务要让AI学会“写笔记”，而不是永远靠聊天记录记忆

除了压缩，Anthropic还提出Structured note-taking，也就是结构化笔记或Agentic Memory。

Agent会把重要状态写到上下文窗口之外，例如维护一个To-do List或NOTES.md，需要时再读取。

Anthropic用Claude玩《宝可梦》的实验说明这种方法：Agent能够跨越数千个游戏步骤记录目标、训练进度、探索地图和战斗策略；上下文重置之后，再读取自己的笔记继续行动。这里真正重要的不是AI会不会玩游戏，而是它展示了一种长期任务的工作方式——持续任务不必依赖一个永远不清空的聊天窗口，关键状态完全可以外置。

对普通用户来说，这意味着如果你长期用AI做一个项目，可以主动建立一份“项目记忆”。里面只放长期有效的信息：目标、已经完成的事项、重要决策、关键人物、固定写作标准、不能改变的事实，以及下一步计划。每次开始新的对话，把真正需要的部分重新带回来。

这比指望AI从几百轮历史消息中自动找回所有重要信息，更可控，也更可靠。

八、个人真正需要学的，不是Prompt技巧，而是“注意力管理”

把Anthropic整篇文章拉回到个人使用场景，它其实提供了一套非常朴素的方法论：把AI的上下文当成工作记忆，而不是硬盘。

你不需要让它时时刻刻看到所有东西。真正重要的是，在当前这一步，让它看到最有价值的信息。写文章时，只放当前稿件、核心原始材料和明确标准；做研究时，让它先建立问题，再按需查资料；长对话开始混乱时，及时总结、压缩、换窗口；长期项目把重要状态写进外部笔记，而不是无限依赖历史聊天；需要模仿风格时，给少量真正好的典型案例，而不是几十篇参考。

这套思路看起来没有“一个Prompt让AI能力翻倍”那么吸引人，但它可能更接近AI真正稳定工作的方式。Anthropic在结论中再次强调，Context Engineering的核心，是在每一步谨慎选择进入模型有限注意力预算的信息，并寻找能够最大化目标结果概率的最小高信号Token集合。

对于个人用户而言，这也意味着AI使用能力正在发生一次变化。过去，我们比的是谁更会“问”；接下来，更重要的可能是谁更会“组织信息”。

一个真正熟练的AI用户，不一定拥有最长的Prompt，也不一定把最多资料交给模型。他更像一个好的编辑、研究员或者项目经理：知道目标是什么，知道当前需要哪些信息，知道哪些材料应该暂时放在一边，知道什么时候该总结，什么时候该重新开始，也知道什么时候应该让AI自己去寻找答案。

所以，Anthropic这篇文章真正值得普通人记住的，不是Context Engineering这个新名词，而是它背后的一个简单判断：AI的注意力也是有限的。用好Agent，不是不断把世界塞进它的脑子，而是在每一个当下，只让它看到最值得看到的那部分世界。

给个人用户的一份简化使用原则：

• 复杂任务开始前，先明确目标、交付物和硬约束，不要一上来堆资料。

• 参考材料优先选择少量高质量、直接相关的内容；能按需调用的资料，不必全部预加载。

• AI开始重复、遗忘或前后矛盾时，优先考虑上下文是否已经过载，而不是继续叠加Prompt。

• 长对话定期生成“项目状态摘要”，必要时带着摘要和最新材料开启新对话。

• 长期项目维护一份外部项目记忆：关键事实、已做决定、未完成事项、固定标准。

• 给示例时追求典型和多样，不追求数量；把边缘案例留给测试，而不是全部塞进运行时Prompt。

• 始终问自己：这一条信息真的会提高当前任务做对的概率吗？如果不会，就不要占用上下文。

原文与编译说明：

原文：Anthropic, “Effective context engineering for AI agents”

发布时间：2025年9月29日

作者：Anthropic Applied AI团队 Prithvi Rajasekaran、Ethan Dixon、Carly Ryan、Jeremy Hadfield 等

原文链接：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents