上下文工程怎么省 Token：工具越多，Agent 反而越容易选错

上下文工程怎么省 Token：工具越多，Agent 反而越容易选错

企业上线 Agent 后，经常先盯模型单价，却忽略每轮请求都在重复发送什么。系统提示词、工具说明、检索文档和历史对话会一起进入上下文；一项任务跑十轮，同一批无关内容也可能付费十次。Microsoft 9 月 2 日发布的成本文章把这个问题称为上下文工程：按当前任务选择模型真正需要看到的材料。

上下文过长还会带来质量成本。相关事实埋在几十页文档里，模型未必能稳定抓到；几十个名称相近的工具同时出现，误选后又要增加几轮调用修正。于是账单上看到的是输入 Token 增长，业务侧感受到的却是回复变慢、工具调用绕路和任务偶发失败。单纯换便宜模型，未必能修复这些结构问题。

知识库不要返回整份文档，工具也不要全量常驻

检索层应返回可引用的小段证据，并保留来源，而非把命中的整份文件拼进提示词。Microsoft 介绍的 Foundry IQ 会拆分查询、并行搜索、语义重排，再把相关段落交给模型。其内部评测称，在 BrowseComp-Plus 上证据召回最多提高 54%，检索 Token 成本降低 34%。这是厂商对特定产品和基准的结果，迁移到企业知识库前仍要用自己的问答集复测。

工具列表同样占上下文。每增加一个 MCP 或 OpenAPI 工具，名称、描述和参数往往每轮都要发送。Microsoft 的 Toolboxes 让模型先描述所需能力，再由工具搜索返回少量候选；官方内部基准称，大型工具库的平均输入 Token 可减少约 97%。数字很醒目，但真正应跟踪的是本业务的工具命中率、误调用率、搜索耗时和任务完成率。

这个思路与统一模型网关互补。网关适合记录哪个模型消耗了多少 Token、何时发生重试和切换；应用层则决定检索片段、候选工具和权限范围。若所有工具描述早已塞进请求，流量到达网关时成本已经形成，后端再选便宜模型只能处理其中一部分。

技能与记忆要按需加载，也要能过期

企业流程经常被复制进多个 Agent 的系统提示词，例如代码审查清单、工单升级规则和采购审批步骤。把流程做成可版本化技能，只在任务匹配时加载完整说明，可以减少重复内容，也让政策更新只维护一处。这里需要区分“批准的流程”和“模型学到的习惯”：前者应由组织发布，后者即使写入程序性记忆，也不能覆盖合规要求。

对话历史也不该无限回放。当前会话需要的是短期状态，跨会话保留的是稳定偏好，任务方法则可能进入程序性记忆。三者的隔离、保留周期和删除权限应分别配置。Microsoft 称其程序性记忆在 STATE-Bench 与 Tau-Bench 上带来约 5% 改善，同样属于产品评测，不代表记得越多越好；过期信息和错误操作也可能被持续放大。

成本排查可以从一次完整任务的输入清单开始，标出每轮新增、重复和实际被引用的内容，再关联 Token、延迟、工具选择与最终结果。删减后要跑相同样本，并由人工或独立模型复核关键输出。若 Token 下降而引用遗漏率上升，优化只是把显性费用换成了隐性返工。

通过 AnyAIS 的统一模型 API，可以把不同模型和路由路径的用量放在同一视角中比较；检索、工具搜索与记忆仍应在 Agent 应用内单独观测。上下文工程做得好，模型不需要知道所有事情，只需要在这一轮拿到足够且有权限使用的证据。

来源：[Microsoft Azure Blog：Context engineering for enterprise AI agents](https://azure.microsoft.com/en-us/blog/the-economics-of-agent-optimization-context-engineering-for-enterprise-ai-agents/)。