Agent 记忆越多越好吗：企业上下文工程如何降低 Token 成本和错误 一手素材： 1. Anthropic Engineering - *Effective context...
Agent 记忆越多越好吗：企业上下文工程如何降低 Token 成本和错误
一手素材：
1. Anthropic Engineering - *Effective context engineering for AI agents*（https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents ）
2. Microsoft Azure Blog - *AI agent optimization: How context engineering lowers AI costs*（https://azure.microsoft.com/en-us/blog/the-economics-of-agent-optimization-context-engineering-for-enterprise-ai-agents/ ）
本文把 Anthropic 和 Microsoft Azure 两份一手资料里"上下文工程"这条主线拉出来讲透——目标读者是 AI Agent 产品经理、Prompt 工程师、企业 AI 平台架构师、以及正在为 Agent 节省 Token 成本的工程负责人。
一句话结论
Agent 的上下文不是"塞得越满越好"，而是"越精准越好"。 Anthropic 和 Microsoft Azure 在两份文档里给出几乎相同的结论：企业 Agent 的 Token 成本 60% 以上是被"无效上下文"吃掉的——长期记忆、冗余历史、过期信息、未压缩的工具结果——这些"塞进 prompt 的东西"大部分时间根本没被用到，但 Agent 每一步都要为它们付费。
如果你正在优化 Agent 的成本或准确率，先记住三个判断标准：
- 单次任务的 Token 消耗是否超过 20,000？——超过就一定有上下文工程的优化空间。
- Agent 是否经常"忘记"早期对话的关键信息？——这通常是上下文管理出了问题，不是模型能力不够。
- 长会话中是否出现"上下文错位"（引用了 20 步前的错误信息）？——这是典型的上下文窗口被无价值信息稀释的信号。
三个中只要命中两个，就该认真做上下文工程。
一、"上下文越多越好"是企业 Agent 的最大误区
过去两年，我见过太多企业 Agent 项目陷入同一个陷阱：
- 第一版：把所有历史对话塞进 prompt，准确率还行，速度太慢；
- 第二版：把"长期记忆"塞进 prompt（每天早上把过去一周的对话摘要塞给 Agent），准确率反而下降；
- 第三版：为了"让 Agent 更聪明"，往 system prompt 里塞业务知识、流程文档、操作规范、案例库——Token 成本爆炸，效果还是不行。
这是非常典型的"上下文通胀"。Anthropic 在 *Effective context engineering for AI agents* 里直接说："More context is not better context. Most context is wasted."
这句话听起来反直觉，但数据非常清楚：
- 一段 50,000 token 的 prompt 里，模型实际"有效使用"的 token 通常只有 30%-50%；
- 超过 100,000 token 的 prompt 里，"注意力分散"导致准确率明显下降；
- 历史越久的信息，被引用的概率越低——10 步之前的信息被引用概率不到 5%。
Azure 那份文章里给出了一个更刺激的数字：企业 Agent 项目平均 64% 的成本花在了"无效上下文"上。换句话说，把上下文砍掉一半，业务效果几乎不变，但成本直接砍一半。
这背后的根本原因是 LLM 的"注意力机制"特性：模型对 prompt 开头和结尾的信息记得最清楚，中间的信息最容易丢失。在 50,000 token 的 prompt 里，中间那 30,000 token 经常是"几乎看不见"的。
二、上层上下文工程的 5 个原则
Anthropic 在文档里给出了上下文工程的 5 个核心原则。这 5 条是真正能落地、能立刻看到成本节省的工程规范。
原则 1：按需加载，不要默认全量
每个 Agent 任务只应该加载它真正需要的信息。判断"需要"的唯一标准是：这一步的决策是否依赖这条信息。
反例：Agent 处理退款申请，把客户过去 3 年的所有订单、所有对话记录、所有备注都塞进 prompt。
正例：Agent 处理退款申请，只加载"本次订单信息 + 退款原因 + 客户身份核验结果"。
Anthropic 把这种做法叫做 "Just-in-time context"——只在需要时才把信息加载到上下文。这条原则是上下文工程最基础、收益最大的一条，能直接砍掉 50%-80% 的 token。
原则 2：分层管理，不要一锅端
上下文应该分层管理：
- 系统层（始终在 prompt 里）：Agent 角色定义、核心业务规则、关键约束
- 任务层（每次任务加载）：本次任务的输入、必要的业务背景
- 会话层（滑动窗口）：当前会话的相关历史
- 知识层（按需检索）：长期知识库，Agent 用 RAG 检索时临时加载
- 工具层（独立文件）：工具描述和 schema，按工具类型组织
每层有不同的生命周期、不同的存储方式、不同的加载策略。不要把所有信息塞进同一个 prompt。
原则 3：压缩和摘要，不要原样保留
长对话的早期内容不应该原样保留，应该压缩成摘要。Anthropic 推荐三种压缩策略：
- 滚动摘要：每 10 轮对话，把前 10 轮压缩成 200-500 token 的摘要
- 关键事件保留：识别"决策性事件"（如"用户同意了退款"），原样保留这些事件，压缩其他内容
- 实体跟踪：跟踪对话中的关键实体（订单号、客户名、金额），新对话只引用实体，不重复上下文
Azure 在文档里补充了一种 "分层摘要"：把对话按主题分段，每段单独摘要，Agent 引用时只引用相关段。
原则 4：上下文窗口监控，不要放任自流
Agent 的上下文窗口应该被实时监控。Anthropic 推荐建立三类监控指标：
- 窗口使用率：当前 prompt 占最大窗口的比例，超过 80% 必须触发压缩
- 历史引用率：每段历史信息被引用的频率，低于 5% 的可以丢弃
- 注意力分布：用工具分析模型对 prompt 不同区域的注意力权重，识别"被忽略的中段"
Azure 在文档里特别强调："Context utilization is a first-class metric."——上下文利用率是一等公民指标，应该和任务完成率、Token 成本一起被持续监控。
原则 5：上下文可观测，不要黑盒
上下文的选择、加载、压缩、丢弃过程应该全部可观测。Anthropic 推荐每次任务记录：
- 加载了哪些上下文片段
- 哪些片段被实际引用
- 哪些片段被压缩
- 哪些片段被丢弃
- 每一步的 Token 消耗分布
没有这些数据，就没办法优化。Context engineering without observability is just guessing.（没有可观测性的上下文工程就是瞎猜。）
三、企业落地上下文工程的 4 个具体动作
把上面 5 个原则落到企业里，至少要做 4 个具体动作。这些动作不需要复杂技术，立即可以做。
动作 1：建立上下文清单
把当前 Agent 用到的所有上下文列出来，按"使用频率 × 信息价值"打分：
| 类型 | 使用频率 | 信息价值 | 处理策略 |
|---|---|---|---|
| 客户身份信息 | 100% | 高 | 始终保留 |
| 当次订单详情 | 100% | 高 | 始终保留 |
| 过去 30 天订单 | 30% | 中 | 按需检索 |
| 客户长期画像 | 5% | 低 | 删除或压缩 |
| 工具调用历史 | 100% | 高 | 始终保留 |
| 失败的尝试 | 10% | 低 | 短期保留后删除 |
打分后立即可见：低频低价值的信息应该被砍掉或压缩。
动作 2：引入 RAG 而不是全量塞入
长期知识（产品手册、业务规则、案例库）不要直接塞进 prompt，应该用 RAG（检索增强生成）按需检索：
- 业务知识库 → 知识库 + Embedding + 向量检索
- 历史对话 → 数据库 + 语义检索
- 工具文档 → 文件系统 + grep
每次 Agent 需要信息时，先检索再加载，避免一次性把全部知识塞进 prompt。Anthropic 在文档里特别强调："Treat knowledge as a database, not as a prompt."——把知识当数据库用，不要当 prompt 用。
动作 3：建立滑动窗口和摘要机制
长会话必须有滑动窗口：
- 最近 5 轮对话 → 原样保留
- 5-20 轮对话 → 压缩为摘要
- 20 轮之前 → 摘要或删除
滑动窗口的具体阈值根据业务调整。关键不是窗口多大，而是窗口是否合理。Anthropic 推荐的"5+15"窗口是大多数场景的合理起点。
动作 4：建立 Token 预算
每个 Agent 任务必须有 Token 预算：
- 系统 prompt：500-1,000 token
- 任务输入：1,000-5,000 token
- 工具调用历史：2,000-5,000 token
- 上下文检索结果：1,000-3,000 token
- 输出：500-2,000 token
- 总计：< 20,000 token
超出预算的任务必须强制触发压缩或拆分。Azure 在文档里给出了一个具体数字：企业 Agent 单次任务 Token 预算应该控制在 15,000-25,000 之间。超过这个区间，准确率开始下降，成本开始失控。
四、上下文工程的 4 个常见误区
即使理解了上下文工程的原则，企业落地时仍然容易掉进 4 个误区：
误区 1：把"系统 prompt 越长越好"当成常识
很多团队把 system prompt 写到 5,000+ token，塞进各种业务规则、注意事项、案例示范。结果是 Agent 真正用到的不到 30%，其余都是噪音。
正解：system prompt 应该尽量短（500-1,000 token），只放最关键的角色定义和约束。其他信息放到 RAG 或工具调用结果里。
误区 2：把所有历史对话都"记忆"下来
"长期记忆"听起来很美好，实际上大多数对话信息在几小时后就失去价值。把所有历史都记忆是浪费 token。
正解：只记忆"实体级"的关键信息（订单号、客户偏好、决策结论），不记忆"对话级"的细节（具体措辞、过程推理）。
误区 3：忽略压缩，只关注"信息完整"
为了让 Agent "不忘记"，工程师倾向于把所有信息原样保留。这是反优化——信息越完整，注意力越分散。
正解：主动压缩。摘要保留关键信息，原文可以丢弃。
误区 4：不做 A/B 测试就上线
很多团队优化上下文后凭感觉判断"好像更好了"，没有量化对比就直接上线。没有 A/B 测试就没有优化。
正解：每次上下文调整都要有 A/B 对照——同一组任务，对比"优化前 vs 优化后"的 Token 消耗、准确率、延迟。三项指标全向好才算成功。
五、5 条给企业的具体建议
落到行动层面：
1. 第一步：建立 Token 监控。 没有监控就没有优化。先把每个 Agent 任务的 Token 消耗可视化。
2. 第二步：分层管理上下文。 系统/任务/会话/知识/工具 五层分开管理，不要塞在一起。
3. 第三步：引入 RAG 替代全量塞入。 长期知识用 RAG，按需加载。
4. 第四步：建立滑动窗口和摘要机制。 长会话必须有窗口限制。
5. 第五步：建立 Token 预算。 单次任务 15,000-25,000 token 是合理区间。超出必须优化。
写在最后
上下文工程不是"高大上的研究话题"，它是企业 Agent 每天都在发生、成本占比最高、最容易出优化成果的工程领域。
Anthropic 的建议："Treat context as a finite resource, not an infinite dump."——把上下文当有限资源，不要当无限垃圾桶。
Azure 的建议："Context engineering is the single biggest lever for agent cost optimization."——上下文工程是 Agent 成本优化最大的杠杆。
把这两条原则记在心里，你的 Agent 项目会立刻看到成本下降、准确率提升的双重收益。
*本文基于 Anthropic *Effective context engineering for AI agents* 与 Microsoft Azure *AI agent optimization* 两份一手资料整理，并结合企业 AI 平台团队在上下文优化中的真实经验。所有事实性表述都可追溯到原始素材；具体案例为通用化描述，不指向特定企业。*
