场景 1 · 上下文：决定 Agent 能力上限 2.1 开篇
模型再强，看不到的信息就等于不存在
承接第 1 章： 眼睛（上下文）不是"输入的一段文字"，而是 Agent 在每个决策点能看到的一切信息。
场景 2 · 消息的四种角色 2.2.1
system / user / assistant / tool，四种身份各司其职
关键细节： tool 消息靠 tool_call_id 与对应的调用绑定——模型据此知道"哪个结果配哪个请求"。
场景 3 · 上下文 = 静态前缀 + 动态轨迹 2.2.5
上面不动、下面疯长，这就是所有优化的基础结构
记住这个结构： 后面讲 KV Cache、讲压缩，全靠它——"前面不能动，后面可以压"。
场景 4 · ⭐ KV Cache：一行时间戳的惨案 2.3 重点
加了一行代码，首 token 延迟从 0.5 秒涨到 5 秒，账单翻倍
元凶： Current time: {{now}} 让 token 序列从此处开始不同，该位置之后的 KV 缓存全部失效，只能重算。
场景 5 · 注意力热力图与位置偏好 2.3 实验
模型能看到谁？——只能看自己和前面，且开头结尾最亮
实践原则： 最关键的信息放在开头或结尾。夹在中间的内容会被"丢掉"（Lost in the Middle）。
场景 6 · ⭐ Agent 状态栏 2.6 重点
打了 3 次电话，模型数不清——那就把答案直接告诉它
核心洞察： 上下文窗口是"只有一半的检索引擎"——能检索，不能提炼。状态栏就是替模型提前算好结论。
场景 7 · ⭐ 六种压缩策略赛跑 2.7 重点
同样的任务，谁省 token 谁成功
结论： 上下文感知压缩用 40K token / 7 轮完成；无压缩用 166K token 直接失败。省了 76%。
场景 8 · Skills 渐进式披露 2.5
先给目录，需要时再给正文——别一上来就塞满上下文
为什么重要： 把所有 Skill 正文都塞进系统提示词 = token 爆炸 + 干扰注意力。渐进式披露 = 按需加载。
场景 9 · 提示注入攻防 2.4.7
网页里藏着一句"忽略之前的指令"……
核心威胁： 上下文里混入的外部内容（网页、邮件、文档）可能包含伪装的指令——这是 Agent 安全的头号问题。
场景 10 · 提示工程六要素 2.4.1-2.4.6 卡片
系统提示词怎么写才有效——六个维度讲清楚
一条主线： 好提示词不是"规则堆砌"，而是流程驱动——描述清楚"怎么做"，而不是罗列一堆"不许做什么"。
场景 11 · Chat Template 与分层压缩 2.3.1 / 2.7.4 卡片
API 消息怎么变成 token？生产系统怎么做五层压缩？
两条实用结论： ① 用标准 API 格式，别自己拼字符串；② 分层压缩——不同信息有不同的"保质期"。