本章核心主旨：给模型看什么、如何组织上下文，比模型本身能力更决定Agent最终效果。
API消息结构构成上下文骨架；KV Cache划定上下文修改约束；提示工程与Agent Skills负责静态指令、动态知识的高效注入；Agent状态栏将隐式任务状态转化为显式元信息；上下文压缩解决上下文膨胀问题，不只是控制token长度，更是把原始数据蒸馏为高密度结构化知识。

统一工程思想：采用显式、工程化的知识管理，不要指望模型在海量原始信息中被动检索，主动向模型提供提炼完成的结构化知识。
结合《苦涩的教训》，本章全部手段都是在现有模型能力边界下，依靠工程提升信息利用效率；长远演进目标是Agent自主完成原始数据到结构化知识的提炼，不再完全依赖人类预定义结构。
本章内容属于第一章Harness框架“上下文与工具”层的落地实现，没有打破上下文五大组成部分：Skills通过工具执行结果进入上下文；压缩是对历史轨迹消息的精炼替换；Agent状态栏API层面使用user角色，语义承载环境、任务元信息，属于原有框架的补充注解，并非全新类别。
下一章进入跨会话持久化知识：用户记忆与知识库，实现多轮会话之间经验沉淀。

---

深度思考题

1. ★★★ 滑动窗口对话历史会导致Agent反复执行相同工具调用。完整保留历史又会让上下文不断膨胀。设计一种策略，既能避免信息丢失，又能控制上下文长度，且不破坏 KV Cache 前缀。

问题本质：普通滑动窗口直接丢弃早期消息会丢失约束与历史结论，造成Agent遗忘重复操作；修改前缀消息会直接破坏KV Cache。硬性约束：system提示、工具定义、初始任务目标等静态前缀不可改动。

策略：静态前缀 + 冷热双区上下文架构

1. 将system提示、工具定义、初始任务目标、核心约束作为永久静态前缀，固定放在上下文最前端，保障该部分持续命中KV Cache。
2. 上下文划分为热区、冷区两块：热区保存最近N轮完整原始交互轨迹，保障ReAct循环正常运行；冷区摘要块追加在热区后方，绝不修改前置静态消息。
3. token到达阈值后，将移出热区的旧轨迹做结构化归档摘要写入冷区；原始旧消息保留并打上[ARCHIVED]标记，不做删除替换，避免破坏KV Cache。Prompt引导模型优先读取冷区摘要，原始归档消息仅用于溯源查阅。
4. Agent状态栏同步维护任务快照，把关键结论、已完成工具、待办事项显式写入，降低模型翻阅远古历史的依赖。

权衡：静态前缀缓存完整保留，原始消息可溯源；但总token依旧会缓慢上涨，触及窗口上限仍需外部压缩。

2. ★★ Qwen3 的 Chat Template 思维链保留机制只保留“最后一个真实用户消息之后”的思考。如果一个 ReAct 循环跨越了上百轮工具调用，累积的思考内容可能消耗大量上下文。你会如何修改这个机制来应对超长循环？对比 DeepSeek（剥离全部历史思考）的策略，各有什么利弊？

问题本质：ReAct每轮生成think思考块，长循环下历史思考占用大量token；全部保留开销巨大，全部删除会丢失推理路径，容易重复犯错。

修改方案：分层思考留存

1. 保留最近K轮完整think原始内容，保障近期ReAct推理链路完整可用。
2. 更早的历史思考不再直接删除，提取关键推理结论、失败原因、错误路径做摘要归档，丢弃完整思考文本，摘要追加至上下文尾部，旧思考标记[THINK_ARCHIVED]。
3. 工具调用失败、方案切换这类关键决策点对应的思考强制完整留存，跳过压缩逻辑。

策略对比

1. DeepSeek完全剥离全部历史思考

• 利：token开销极低，上下文干净，不受旧错误思考干扰。
• 弊：丢失失败路径，Agent容易重复踩坑；无法复盘推理；复杂多步任务稳定性下降。

2. 分层留存方案

• 利：近期思考完整保障ReAct运转，旧思考压缩保留经验，控制token总量，留存失败路径。
• 弊：需要额外LLM调用做摘要，模板逻辑复杂度上升，归档质量依赖压缩能力。

3. ★★ 上下文感知压缩实验中，从约 148K 个字符压缩到约 2,000 个字符，这种极端的压缩是否存在“不可逆信息损失”的风险？如何解决？

风险：细粒度事实、标识符、时间、URL被篡改丢失；丢失冲突证据、备选方案、失败路径；丢失来源无法校验事实；后期细分查询缺少原始素材支撑。

缓解手段

1. 有损摘要搭配无损索引：输出精简摘要，每条事实附带来源ID/URL；原始大文本持久化落盘，模型需要细节时可依据索引重新拉取原文片段。
2. 设置压缩白名单，UUID、hash、时间、版本号、链接强制原样保留，禁止改写。
3. 分级动态调整压缩倍率：信息收集阶段降低压缩强度，汇总阶段才使用高倍率压缩。
4. 压缩提示明确要求标注舍弃信息类别，约束不可丢失的实体；原始工具输出全部磁盘落盘，主上下文仅使用摘要。

4. ★★ Agent状态栏将隐式状态显式化。但如果状态栏本身包含了错误信息（比如工具计数器出了 bug），Agent 可能基于错误的信息做出有害的决策。这种“元信息可靠性”问题如何缓解？

问题本质：模型默认状态栏为可信事实源，框架输出错误元数据会造成垃圾输入垃圾输出，模型本身无法甄别元信息错误。

缓解方案

1. 框架侧轨迹校验：状态栏字段不单纯依赖程序内部变量；每一轮更新都扫描真实对话轨迹重新统计生成，例如工具调用计数器遍历消息列表统计，避免程序变量bug。
2. Prompt约束：状态栏仅作为辅助参考，状态栏与原始历史冲突时，以原始对话消息为准，降低元信息绝对可信度。
3. 状态栏附带版本号、校验哈希，检测数值异常突变；检测到计数器倒退、状态矛盾等异常，直接清空状态栏，从历史轨迹重新构建。
4. 完整记录每一轮状态栏输出，用于故障排查。

5. ★★ 提示工程消融实验表明，信息组织的混乱导致成功率下降 30% 以上。但在实际开发中，系统提示词往往由多人在不同时间维护。你会用什么工程实践来防止系统提示词的“熵增”？

提示词熵增：多人迭代持续追加规则，旧规则不清理，出现冗余、冲突、顺序混乱。

工程实践

1. 提示词模块化文件管理，接入Git版本控制；禁止业务代码硬编码大段system字符串。
2. 模块设置优先级，高优先级覆盖低优先级；废弃规则直接删除，不做注释遗留。
3. 增加自动化回归测试，提示词修改后执行标准化Agent用例，成功率大幅下跌则拒绝合并。
4. 开发简单lint脚本，检测重复、矛盾、无效规则，告警冗余片段。
5. 运用Skills渐进披露思想，system只保留最核心规则，细分业务规则做成Skill按需加载，避免system无限膨胀。
6. 每一条规则附带业务场景注释，无对应场景的规则直接移除。

6. ★★★ 本章提出“上下文学习本质上是检索而非推理”。如果这个论断成立，当前所有基于“把更多信息塞进上下文”的优化方向都需要重新审视。你认为应该如何突破这一局限？

核心矛盾：上下文擅长片段检索，不擅长单次前向传播完成统计、归纳、多源融合；盲目塞入更多文本只会触发上下文腐化。

突破方向

1. 前置知识蒸馏：不把海量原始文本送入上下文，外部模块提前做抽取聚合，送入高密度结构化知识，如上下文压缩、Agent状态栏。
2. 外部RAG检索：原始数据存放向量库，仅把当前推理真正需要的片段召回进上下文，把“大海捞针”转移到模型外部完成。
3. 任务拆解与子Agent隔离：统计归纳类复杂任务交给子Agent独立执行，仅把最终摘要返回主Agent，海量中间过程不进入主上下文。
4. 检索推理阶段分离：单独一轮完成信息汇总，再执行决策推理，不让推理阶段同时承担大规模材料检索。
5. 引入跨会话持久记忆，高频复用知识存入记忆库，避免每轮全部塞入上下文。

根源：上下文学习是浅层临时适配，无法真正内化知识，需要外部工程系统补齐归纳、统计、记忆能力。

7. ★★ Skills 的渐进式披露只在 Agent 判断需要时才加载完整内容。但这个判断本身依赖模型的能力——如果模型不知道自己不知道什么，就无法正确触发 Skill 的加载。这个“元认知”问题如何解决？

问题本质：模型无法识别自身能力缺口，不会主动触发对应Skill加载。

解决方案

1. Skill的简短元数据（能力名称、适用场景）常驻system前缀，完整Skill本体延迟加载；让模型知道存在该能力，才有机会触发加载。
2. 增加框架侧兜底逻辑，不完全依赖模型判断；框架解析任务关键词、工具调用行为，命中场景就主动注入Skill。
3. 失败回退：Agent多次无效输出、连续工具调用失败，框架批量加载候选Skill元集合重试。
4. 配置Skill依赖关系，加载A时自动加载其依赖的B。

常驻元数据会少量消耗token，属于工程补偿，无法彻底消除元认知缺陷。

8. ★★ Skills 机制中，Agent 从 SKILL 文件中动态读取提示词之后，后续的操作能否正确遵从这些指令？不同的模型对 Skills 模式的支持有什么区别？

动态加载的Skill追加到上下文，等价运行时注入提示，但遵从度不是100%。风险：动态注入的指令位置靠后，长上下文下注意力衰减，容易被头部system提示压制。

模型差异

1. Claude、DeepSeek等模型：对上下文后段新增指令服从度高，适配Skills模式。
2. 开源小参数量模型：高度依赖最开头system前缀，后续user角色追加的规则约束力明显下降，容易忽略Skill指令。
3. 部分ChatTemplate只认头部system角色，其余位置规则权重低；ReAct能力强的模型更擅长响应动态加载的Skill。

工程经验：关键业务Skill尽量靠近输出位置；最高优先级规则依旧保留在头部system，不交给动态Skill。

9. ★★★ 本章强调动态信息（如系统时间戳、工具列表顺序）的变化会破坏 KV Cache 前缀命中。在一个拥有大量工具且工具集频繁变动的生产系统中，你会如何设计上下文布局来最大化缓存命中率？

问题本质：前缀任意token发生改动，改动位置之后全部KV Cache失效；动态内容放在头部会严重破坏缓存。

布局方案

1. 上下文分段：最前端为完全不变的静态区，存放基础system、固定规则；全部动态可变内容移出静态前缀，工具列表、时间戳、动态配置后置到Agent状态栏区域。动态内容改动只会破坏后置部分缓存，静态前缀持续命中。
2. 工具集合拆分：基础常驻工具放在静态前缀；频繁变更的业务工具放置后置动态块，业务工具改动不污染静态前缀。
3. 时间戳不要每轮强制更新，状态栏按需更新，减少token变动。
4. 优先追加消息，尽量避免修改、删除历史消息；工具集改动做批量更新，减少频繁重建缓存。

权衡：动态内容后置会降低指令注意力权重，需要在Prompt中提升动态信息优先级。