解读：上下文工程是代理系统的“信息预算”管理

• 对应原文：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents [61]
• 对应译文：AI 代理的有效上下文工程

一句话主旨

上下文不是越多越好，而是要用最小的高信号集合，让代理在每一轮都朝着可预期的方向行动。[61]

关键洞察

• 上下文是稀缺资源：随着 token 增长，注意力预算被稀释，检索与长程推理精度下降。[61]
• 信息的“高度”要对：过度细化会让系统脆弱，过度抽象又无法执行，最佳区间是“明确但不硬编码”。[61]
• 工具也是上下文的一部分：工具定义越清晰、返回越高信号，代理越稳定；工具重叠会导致犹豫与误用。[61]
• 运行时检索是关键能力：用索引代替堆叠，把探索成本留给工具，而不是塞进上下文。[61]
• 长任务的三把钥匙：压缩、结构化记忆与子代理分工，分别解决跨度、持久性与并行性。[61]

工程落地建议

• 上下文分层：系统指令分块、工具指引与输出要求分区，减少混杂干扰。[61]
• 最小集合优先：先用最小 prompt 和工具跑一遍，再基于失败模式补充。[61]
• 检索“只在需要时发生”：保存轻量索引（路径、查询、链接），减少一次性塞满上下文。[61]
• 压缩策略前置设计：先保障高召回，再精简；避免丢失关键决策与未解决问题。[61]
• 长期记忆落地为文件：以 NOTES.md、任务清单或 memory 工具固定状态，减少跨会话漂移。[61]

与本书章节的对照

• 第 2 章强调“工具是合同”，本篇补充“工具=上下文契约”；工具定义是上下文工程的一部分。[61]
• 第 8 章谈长任务 harness，本篇给出具体手段：压缩、记忆、子代理如何组合。[61]

读后结论

上下文工程的本质是“信息预算管理”。当代理无法稳定时，往往不是模型不够聪明，而是上下文里信号被稀释、噪声太多。把上下文压成“高信号、低噪声”的最小集，是可控代理的起点。[61]