The Economics of Agent Optimization: Context engineering for enterprise AI agents

_这篇博文是系列文章《代理优化的经济学》的第三部分，该系列文章将分享策略、能力和实证案例，帮助您优化代理成本，并在Microsoft Foundry上将AI作为托管投资系统运行。第一篇博文阐述了系统依赖的三个决策。第二篇博文讨论了运行时的请求处理。本文将探讨下一个重点：随着代理学习到有效方法，如何逐步降低每个代理的成本。_

• * *

每个代理都有一个机制来决定其模型在每一轮能看到的内容。在许多生产系统中，这个选择在原型设计阶段确定后便从未被重新审视，尽管它通常决定了最大的运营成本份额，并可能导致令人失望的回答。

这也是代理自身可以改进的部分。模型的能力与您最初选择时保持一致，只有当有人修改指令时才会变化。但随着代理的运行，它所了解、可访问和记住的内容会不断增长，这使其成为在降低长期成本的同时提升性能的关键。管理这一过程称为上下文工程。

为什么上下文窗口决定了代理的成本

模型本身没有记忆能力。在每一轮中，上下文窗口为其提供所有可用信息：指令、可用工具、检索到的文档和对话历史。当这一轮结束时，这些上下文信息会消失，并在下一轮中需要重新发送。

对于回答单个问题的聊天机器人来说，这种成本是可以管理的。但对于需要跨多轮操作以达成最终目标的代理而言，这通常是最大的开支。由于上下文窗口在每一轮都需要付费，不必要的内容会被重复计费。

更隐蔽的成本是质量。更多的上下文并不保证更好的答案：埋藏在40页中的相关事实更难被利用，过长的工具列表反而会增加选择错误的可能性。每个错误都会增加更多轮次——从而产生更多成本来纠正。

这使得上下文值得管理层重点关注。大多数成本削减都涉及权衡：更便宜的模型可能降低质量，更简短的指令可能削弱回答效果。相比之下，移除不必要的上下文可以在不降低质量的前提下降低成本，这使它成为团队更容易支持的优化方向。

上下文工程的实际含义

这就是上下文工程的作用：它决定每一轮进入上下文窗口的内容，使代理获得当前请求真正需要的信息，而非所有可能需要的信息。作为一次性选择，这是一个设计决策。若持续实践，它就是代理改进的方式，因为每一轮都会揭示代理实际使用的内容。四个问题涵盖了这项工作，团队通常按以下顺序处理这些问题。

代理应该了解什么？

许多团队最初采用广度优先的搜索方式，将整篇文档直接插入提示中。这种方法虽然易于构建，但运行成本高昂，且迫使模型在大量信息中寻找唯一相关的细节。

Foundry IQ 通过托管知识层替代了这种模式。知识库可指向 Work IQ、Fabric IQ、Web IQ、Microsoft Azure Blob Storage、SharePoint、OneLake 和 Azure SQL 等多个来源。当代理提交查询时，Foundry IQ 会将其分解为子查询，通过并行搜索关联源、语义重排序结果，并返回带有引用的可靠片段。这种方式将进入模型上下文的信息范围缩小到最相关的证据，同时保持对原始来源的可追溯性。

两个特性使该知识层可跨代理复用，并支持大规模治理。单一知识库可服务多个代理。索引源可按照配置的索引器计划进行增量刷新，而远程源则按需查询。在查询时，Foundry IQ 可在调用者的 Microsoft Entra 身份下运行，同步支持源的访问控制列表，并遵循 Microsoft Purview 敏感度标签，确保代理仅检索调用者有权访问的内容。

我们的内部评估 显示，在 BrowseComp-Plus 基准测试中，Foundry IQ 知识库将证据召回率提升了高达 54%，同时将检索令牌成本降低了 34%。这些提升源于智能检索、语义重排序、改进的答案合成以及更高效的令牌使用。

代理应具备哪些访问能力？

工具开销容易被忽视：添加一个工具可能只需一行代码，但其完整描述会占据提示空间。附加到代理的每个工具，其描述都会在每次交互中发送给模型，无论是否需要，而企业级代理在连接更多系统时会快速增加工具。

Foundry 的工具箱 为代理提供了一个统一的托管模型上下文协议（MCP）端点，可集成内置工具（如网络搜索、代码解释器、文件搜索）以及自定义 MCP 服务器、OpenAPI 3.0 和 3.1 接口、A2A 代理。Foundry 在单一位置管理身份验证、访问策略和工具版本，无需为每个代理单独配置集成。一旦新工具箱版本通过测试并发布，已连接的代理即可直接使用，无需代码更改或重新部署。

工具箱用于组织您的工具。工具箱内的 工具搜索功能 可防止您为所有工具付费。模型不会获取完整的工具列表，而是获得两个功能：用自然语言描述需求的方式，以及调用搜索结果的方式。无论工具箱规模如何扩大，工具列表的成本始终保持不变。在与公开的开源工具检索数据集进行的内部基准测试中，Foundry 的工具箱将大型工具库的平均输入令牌消耗量降低了约 97%，直接降低了构建代理的客户推理成本。1

Foundry 还会注意到每个工具箱最常使用的工具，并将这些工具放在易于访问的位置，因此随着代理运行时间的增加，常用路径会变得更加快速和经济。准确性与成本同步提高，因为简短且匹配良好的列表意味着更少的错误调用和更少的时间用于恢复。

代理应如何执行任务？

知识和工具涵盖了代理可以查找和执行的内容。但两者都没有涵盖公司期望工作完成方式的指导：支持代理遵循的升级路径；代码审查应用的检查清单。这些指导通常存在于代理的指令中。因此，相同的流程可能会被复制到多个代理中，并包含在每个请求中，即使它们并不相关。

技能将这些指导转化为可命名、可重复使用的流程。技能 存储在 Foundry 的中央位置，并通过工具箱提供给代理。无需在每个代理中嵌入流程的副本，工具箱只需引用中央管理的技能。当您的组织改进流程时，可以发布新版本并将其设置为默认版本。使用该技能的每个代理都可以按照更新后的流程执行操作，无需代码更改或重新部署。为最大限度减少上下文使用，代理最初只会看到每个技能的名称和简要描述。只有在技能相关时，才会加载完整的说明。这使得提供大量详细流程的库成为可能，而不会在每次交互中添加不必要的内容。

代理应记住什么？

代理需要连续性，但不需要记住每次交互的所有细节。反复将整个对话发送给模型会增加成本并消耗上下文，即使只有少数细节仍然有用。

Foundry 代理服务中的内存 帮助代理保留重要上下文，而无需重放整个对话。它支持三种类型的内存：

• 会话内存：用于当前对话。
• 用户内存：用于跨会话持续的偏好和事实。
• 过程内存：用于学习的工作流程和任务执行模式。

这使得回头客户可以从中断的地方继续，同时使代理能够始终遵循经过验证的流程，而无需每次都被重新指导。

这些能力共同帮助代理继续与客户互动、个性化未来的响应，并提高其完成重复任务的可靠性。程序性记忆补充了集中管理的技能：技能定义了组织批准的流程，而程序性记忆帮助代理从自身的任务执行中学习。在微软的评估中，启用程序性记忆使STATE-Bench和Tau-Bench的性能提升了约5%。组织还可以通过用户级隔离、保留设置和生存时间策略来控制记忆，这些策略决定了存储的内容及其过期时间。

为什么上下文工程会演变为一个系统

任何团队都可以整合知识检索、工具、程序性指导和记忆。挑战在于让这些组件在统一的权限体系下协同工作，并随着组织的变化保持更新。

Foundry将这些组件整合到一个系统中。知识、工具、技能和记忆可以通过共享的基础设施进行管理，而非独立的产品，同时在数据检索时强制执行权限，使代理继承已应用于企业内容的访问控制。Foundry IQ将该模型扩展到企业知识、业务数据和组织上下文，同时与微软代理框架、LangGraph、GitHub Copilot SDK和Claude Agent SDK等框架兼容。

结果是上下文质量得到提升而无需重建代理。知识库会随着源系统的变更而刷新。技能会随着政策的演变而发展。记忆会积累与用户和成功工作流程相关的重要信息。工具搜索会适应人们实际使用的功能。随后，Foundry Agent Service中的代理优化器通过分析代理行为并生成改进的指令、技能、工具描述和模型配置来形成闭环。

这就是上下文工程的更大目标：不仅仅是减少提示规模或检索成本，而是创建随着使用而改进的代理。当代理所依赖的知识、所发现的工具、所遵循的流程以及所保留的记忆都随时间变得更好时，代理可以在无需重头开始的情况下变得更强大、更高效。

入门指南

如果你正在构建代理，首先应检查每次交互中进入上下文窗口的内容。查看正在检索的文档、正在暴露的工具、正在重复的指令以及正在传递的对话历史。在许多情况下，改进这些输入对成本和质量的影响比更换模型更大。

• 通过 Foundry IQ 将代理与企业数据对接：将 Foundry IQ 知识库连接到代理。
• 为代理的工具提供一个统一的端点，并启用工具搜索：在工具箱中启用工具搜索。
• 添加内存功能，使代理能够在会话之间保留上下文：在 Foundry Agent Service 中创建和使用内存。
• 立即在 Microsoft Foundry 开始构建。

您是否错过了**Agent 优化经济学系列** 中的这些文章？

• AI 成本管理：从 AI 试点到可衡量的 ROI
• AI 成本优化：如何降低 AI 支出

• * *

1命令行、工具搜索：在正确的时间找到合适的工具，2026 年 7 月 29 日。