这是我啃完 Anthropic 官方文章《Effective Context Engineering for AI Agents》后，和教练Opus 4.7的一场灵魂对话。五道题，从懵懂到顿悟，记录下这段“哦原来如此”的时刻。
第 1 题：Prompt Engineering 和 Context Engineering 有啥区别？
我：教练，我觉得 Prompt Engineering 就是优化提示词，跟大模型单次交互嘛。Context Engineering 就更高级了，要管理 Agent 整个生命周期的信息，追求那种“小而美”的高信号 token 集合。教练：嘿，抓到重点了！“高信号 token” 和 “整个生命周期” 这俩词你都说对了。Prompt Engineering就像写邮件——你得精心措辞、组织结构、加点例子，争取让对方看一遍就懂你要干嘛。一次性交易，成败在此一举。Context Engineering呢？那是侦探的工作台。你看福尔摩斯破案，桌上永远只放当前需要的那几份卷宗。什么时候该把旧案卷归档？什么时候该调新证据？这才是关键。Agent 跑几十上百轮，每一轮都得决定“桌上放什么”，这就是 context engineering 的活儿。我：所以 prompt 只是 context 的一部分？教练：Bingo！Context 里还有一大堆东西：Anthropic 那帮人提了个很牛的视角：别老想着“我 prompt 怎么写”，该想“什么样的上下文配置能让模型干出我想要的事”。这就是从 prompt engineering 到 context engineering 的跃迁。我：这么说，很多人 Agent 出 bug，第一反应是“我 prompt 写得不好”，其实可能根本不是 prompt 的锅？这都是context 的问题，不是 prompt 的问题。能分清这个，debug 效率直接提升 5 倍。
第 2 题：为啥 Context 是“有限”的？
我：我理解是因为 token 多了，模型要维持所有 token 之间的成对关系，注意力就被稀释了。教练：标准答案！这个现象有个专业名词叫Context Rot（上下文腐化）。Transformer 靠attention 机制让所有 token 互相“看见”对方token 数量一多，成对关系就是n² 爆炸式增长结果就是每个 token 分到的关注越来越少，关键信息就淹没了教练：像什么？给你 5 个人名，你轻松记住。给你 500 个人名，看过也记不住几个，对吧？教练：但 context 的“有限”还不止这一层。我给你列个表：为啥有限 | 具体说明 |
|---|
架构层面 | attention 机制本身就会随着长度衰减 |
成本层面 | context 越长越贵、越慢，Agent 跑几十轮，成本平方级往上涨 |
训练数据层面 | 模型见过的长 context 样本少，即使窗口够大，表现也会掉 |
所以啊，context 是 Agent 的稀缺资源——稀缺不是因为装不下，是装进去也用不好、用不起。我：那我以后写 Agent 得反复问自己：“这信息真的要塞进去吗？”这次塞了，后面 50 轮还要带着吗？不要就得有机制清掉
第 3 题：窗口大了，就不用搞 Context Engineering 了吧？
“现在模型窗口都 200K tokens 了，context engineering 就不重要了，把所有相关信息塞进去就完事儿。”
我：错！窗口只是容量，context engineering 是质量。我要的是高信息密度的 token 集合，关注的是全生命周期，目标是结果准确。窗口变大 = 书桌从 宽1 米变 5 米Context engineering = 桌上该放啥、不该放啥、啥时候换桌子大了，你能铺更多东西——但你要是乱铺一气，找东西反而更慢、更容易拿错。桌子越大，整理能力越重要，不是越不重要。容量 vs 质量——容量解决“装不装得下”，工程解决“装得对不对”全生命周期——Agent 是几十上百次推理串起来的，时间维度窗口永远解决不了给你讲个真实案例：Anthropic 自家的 Claude Code，窗口 200K，按理论够大了吧？但他们还是投入大量工程做 compaction 和 note-taking。教练：因为真实数据告诉他们：即使窗口能装，装满了模型表现就是会掉。记住这句话：“窗口大”是模型厂商的问题，“context engineering”是 Agent 开发者永远的问题。
第 4 题：怎么管理 Agent 的长期上下文？
场景 | 你的答案 |
|---|
Agent 跑了 50 轮，把前 40 轮总结成 2000 字摘要替换原对话 | ？ |
研究 Agent 派 5 个子 Agent 各研究一家公司，只回传结论 | ？ |
Agent 把发现的重要信息写到 notes.md，下次启动先读 | ？ |
我：第一个是 Compaction（压缩），第三个是 Note-taking（笔记）。第二个……呃……长短期记忆分离？教练：前两个对了，第二个是Multi-agent（多 Agent 架构）。来，我给你详细讲讲这三个策略。
策略 1：Compaction（上下文压缩）
机制：让模型自己把历史对话总结成摘要，用摘要替换原文，腾出空间。优点：保留“叙事连贯性”——Agent 还记得前因后果。缺点：摘要会丢细节，压缩多了会失真，就像复印件的复印件的复印件。
策略 2：Note-taking（结构化笔记）
机制：Agent 把关键信息主动写到外部存储（文件、数据库），用的时候再读回来。比喻：把读过的书放进书架，桌上只放索引卡，需要哪本去书架取。
策略 3:Multi-agent（多 Agent 架构）
省 context 的关键：子 Agent 在自己的 context 里干完脏活累活，只把“结论”回传给主 Agent，主 Agent 永远看不到原始大块材料。三段论：独立 context → 干完只回传结论 → 主 Agent 看不到原料
我：等等，Compaction 和 Note-taking 有啥本质区别？教练：好问题！Compaction 在 context 内，note-taking 在 context 外。 | Compaction | Note-taking |
|---|
信息在哪 | 还在 context 里（只是压缩了） | 在 context 外（文件/数据库） |
有没有损失 | 压缩过程会丢细节 | 完整保留，按需取回 |
适合啥场景 | 对话流要连贯的任务 | 有清晰里程碑、需要跨 session 的任务 |
教练：Session = Agent 的一次连续运行，从启动到关闭。Session 结束，所有 context 默认都没了，Agent 就“失忆”了。举个例子：让 Agent“持续追踪 10 家竞品公司”：周一 9:00（Session 1）：搜了 5 家公司，记录信息，关闭周二 9:00（Session 2）：重启，要继续搜剩下 5 家——它咋知道周一搜过哪些？周三 9:00（Session 3）：又启动，要对比“本周 vs 上周”——它咋知道上周的状态？这就是“跨 session”——Agent 的记忆要在多次启动之间连续。我：所以 note-taking 能解决跨 session,compaction 不行？Compaction 救不了跨 session：压缩后的摘要还在当前 session 的 context 里，session 一关也没了Note-taking 可以：笔记写在外部，session 关了它还在，下次启动先读笔记，“上次进行到哪”就装回来了
策略 | 适合啥时候用 |
|---|
Compaction | 需要长时间对话连贯、来回反复的任务 |
Note-taking | 有明确里程碑、需要跨 session 持久化的迭代型任务 |
Multi-agent | 复杂研究和分析、可以并行探索的任务 |
第 5 题：综合应用——对比 5 家电动车公司财报
教练：来个大题：假设你要做个 Agent 帮用户研究“对比 5 家电动车公司的最新财报”。这任务可能要跑几十轮、读大量网页文档。我会用 Multi-agent：设计 1 个主 Agent + 5 个子 Agent，每个子 Agent 研究一家公司。因为任务时间长、要跨 session，所以子 Agent 要用 note-taking，每次运行都能读到之前的上下文信息。教练：90 分！你的思路很完整，我给你指出几个精进点。
问题诊断准确：把容量问题（不够用）和质量问题（衰减）分开说——专业！主架构选对：看到“对比 5 家公司”这种天然可并行的结构，立刻想到 multi-agent跨 session 用 note-taking：意识到子 Agent 任务长、可能跨 session，用笔记持久化没乱用 compaction：知道“什么时候不用什么”
子 Agent 层：每个子 Agent 把研究某家公司的过程记到自己的笔记里主 Agent 层：主 Agent 把“5 家公司各自结论的汇总进度”记到主笔记两层笔记互不干扰——这呼应了 multi-agent 的核心：上下文隔离不只是运行时的，连记忆也是隔离的。
子 Agent 在研究 A 公司时，单次 session 内就读了 30 篇文章、跑了 50 轮——这一次 session 内部就可能 context 爆掉。这时候 compaction 派上用场：单次 session 内部的对话压缩，跟 note-taking 配合用。
层次 | 用啥策略 | 解决啥问题 |
|---|
主 Agent 协调 5 个子 Agent | Multi-agent | 总任务不堆在一个 context 里 |
子 Agent 单次 session 内对话太长 | Compaction | 单次 session 不爆 |
子 Agent / 主 Agent 跨 session | Note-taking | 跨天恢复现场 |
我：子 Agent 研究完了，直接把所有材料给主 Agent？❌错误做法：子 Agent 把所有原始研究材料（30 篇文章全文）都甩给主 Agent✅正确做法：子 Agent 返回结构化的结论摘要（500 字以内，带关键数据和来源链接）Multi-agent 能省主 Agent context 的前提，是子 Agent 真的“过滤”过信息。如果子 Agent 把原料原封不动倒给主 Agent，那 multi-agent 就白搞了——主 Agent 还是会爆。“子 Agent 返回什么”这个接口设计，是 multi-agent 系统能不能省 context 的真正关键。
写在最后：AI 时代的学习方式变革
说实话，在没有大模型之前，让我啃一篇英文技术官方文档？我连想都不敢想。
脑子里第一个声音就是：“做不到，不可能，英文这门语言都学不明白。”
但现在有了各种大模型和工具之后，反而激发了我求知的欲望。我开始感慨：原来自己需要成长的东西有这么多，而我之前根本没意识到。
学习闭环的形成
以前的学习是什么样的？
看完一篇文章，觉得“嗯，看懂了”
然后呢？没有然后了
不知道自己到底懂没懂，更不知道怎么验证
没有反馈，就没有闭环。
现在呢？我用 Claude Opus 4.7 当教练：
它出题，我答题
我思考不完整的地方，它帮我补充
我不理解的地方，再继续翻阅原文
一问一答之间，知识就这么扎实地装进脑子里了
整体的学习效果比之前强了不止多少倍。
AI 不是替代人的工具
之前听到“能跟 AI 聊就不要跟人聊”这句话，觉得说法太极端了。
但放到现在来看，真是这样。
不是说 AI 比人强，而是：
AI 不是替代人的工具，而是把自己变得更强、更好、更完善的工具。
它是你的：
24 小时在线的私人教练
永不疲倦的学习伙伴
随时可以重来的练习场
这才是真正的学习
这次学习 Context Engineering，我第一次感受到：
原来学习可以这么爽。
不是被动接受，而是主动探索。不是死记硬背，而是理解内化。不是学完就忘，而是真正掌握。
如果你也在学习 AI、学习技术，试试这种方式：
找一篇你感兴趣但觉得有点难的文章
让 AI 给你出几道题
自己先答，然后让 AI 点评
不懂的地方继续追问
你会发现，学习的门槛降低了，但学习的深度反而增加了。
这就是 AI 时代的学习方式。
本文基于 Anthropic 官方文章 Effective Context Engineering for AI Agents
