The Economics of Agent Optimization: How AI agent governance controls cost and proves ROI

_本文是系列文章《代理优化的经济学》的第四篇也是最终篇，该系列分享了可以帮助您优化代理成本并在Microsoft Foundry上将AI作为受管理投资系统运行的策略、能力和实证数据。第一篇阐述了系统所依赖的三个决策，第二篇探讨了运行时的请求处理，第三篇分析了随时间推移的工作流。本文将探讨那个持续运行的决策：支出管理。_

• * *

AI代理正在从孤立的试点项目转向企业级部署。它们跨团队协作，连接数据和工具，并以不同程度的自主性做出决策。对于IT领导者而言，这带来了更广泛的运营问题：如何治理一个能够比传统应用更快增长和行动的自主系统？

AI代理治理始于了解哪些代理存在、由谁负责、可访问哪些资源以及适用哪些策略。它通常被讨论为安全、合规和生命周期管理。但其也是成本优化的基础。缺乏一致的治理时，每个团队都会自行决定模型、工具、容量和限制——而微小的低效率会随着每个代理和每次操作不断累积。

良好的治理使资源消耗变得可见、可追溯且可控。IT部门需要清楚哪些代理和团队在推动使用。财务部门需要可信的预算和成本分配，而无需在账单关闭后发现意外增长。开发人员需要能够以代理运行速度响应的控制机制。

这一最后要求揭示了一个重要区别。传统的成本管理工具可以跟踪支出并预警实际或预测成本，但它们通常基于账单数据而非请求路径运行。陷入重试循环的代理不会等待下一次预算评估。

预算预警就像烟雾探测器。代理还需要熔断器。因此，有效的成本治理取决于三件事：看清支出、设定支出上限，并证明投资回报。

从源头看清支出

AI 成本在以一个汇总数字形式出现时变得难以管理。一个部署可能服务于多个代理；一个代理可能使用多个模型和工具；一个结果可能需要多次交互。当这些成本出现在发票上时，业务背景信息已经消失。

Foundry 的成本管理功能将这些背景信息更紧密地与创建它们的系统关联起来。团队可以跨项目查看预估成本，检查单个代理的成本和令牌使用情况，并监控模型成本。这些预估支持运营决策；Microsoft Cost Management 和发票费用仍然是财务对账的系统记录。

Foundry 还支持 项目级别的成本归属。每个 Foundry 项目都会在其底层使用情况上自动关联一个项目标签。FinOps 团队可以通过该标签在 Cost Analysis 中筛选，将支出分配给产生该支出的业务单元、团队或工作负载。此功能目前处于预览阶段，适用于 Microsoft Azure 提供的模型，包括 Azure OpenAI。

在网关层面，Azure API Management 的 AI 网关可以按 API、产品、用户、订阅、网关和后端发出令牌指标。Foundry 的追踪功能会捕获代理运行过程中的工具使用情况、重试次数、延迟、令牌消耗和成本。

综合来看，可观测性信号不仅解释了代理消耗了多少资源，还解释了原因：

• 追踪信息揭示了模型调用、工具调用、重试次数、延迟和令牌使用情况。
• 监控功能展示了生产趋势和异常情况。
• 评估功能衡量质量、安全性、可靠性及任务完成情况。持续运行时，它们为团队提供了证据，以测试较小模型是否仍能满足质量标准，而不是默认使用最大模型。安全评估器还可以在问题到达生产环境之前标记诸如提示注入、敏感数据泄露和有害内容等问题，从而避免高昂的修复成本。

综合查看这些信号，有助于团队判断成本上升是由客户需求、代理行为低效、质量退化还是架构问题驱动的。

该上下文将成本数据转化为可操作的治理措施。在团队设定限制或衡量投资回报率之前，需要了解代理在生产环境中的行为方式。

在每一层设置支出限制

可见性告诉你钱花在哪里。限制决定是否可以继续支出。控制系统有三个层级，每个层级在不同范围和速度上运行：

1. 在Foundry中实施限制

配置AI网关后，Foundry控制平面可以强制执行项目范围内的模型部署每分钟令牌速率限制和总令牌配额。超出速率限制的请求会收到429 Too Many Requests响应。耗尽令牌配额的调用者会收到403 Forbidden响应。

与成本警报不同，强制执行发生在请求路径中。团队可以在一个项目消耗共享容量之前控制其消耗，并为不同项目设定不同的边界。配额可以按小时、每天、每周、每月或每年周期运行。团队可以配置由Azure API管理支持的网关，并通过Foundry控制平面管理其令牌限制。

2. 在模型和提供商之间应用策略

对于跨项目或模型提供商的控制，llm-token-limit策略通过速率、累计配额或两者来限制每个密钥的使用量。密钥可以代表订阅、应用程序、团队、客户、工作负载标识或其他业务边界。

AI网关在OpenAI兼容API、Anthropic Messages API、MCP服务器和代理到代理API上应用相同的治理模型。后端负载均衡可以在溢出到按需部署之前优先使用预分配容量，而断路器可以暂时停止向故障或被限流的后端发送请求。

与任何分布式限制一样，这些控制都有边界。每个网关独立维护计数器，并发请求可能会导致短暂的临时超额，因为最终的令牌消耗只有在响应返回后才知道。目标是用可预测的操作边界取代无限制的消耗。

3. 使用财务预算进行问责和升级

微软成本管理预算的目的与令牌限制不同。它们使用Azure计费数据（包括实际价格、信用和采购承诺），为财务和IT提供权威的组织支出和预测支出视图。

团队可以设置预算阈值，并在实际或预测成本接近阈值时通知所有者。他们还可以将预算连接到 Azure Monitor操作组，该操作组可以触发客户自定义的工作流程，例如创建工单、通知运维团队或启动逻辑应用或自动化运行簿。成本异常检测在支出偏离其历史模式时提供另一层预警。

这些是宝贵的问责和升级工具，但它们并不是即时的支出上限。它们在消费发生后才响应账单数据。令牌限制则更早起作用，在每个模型请求的路径中，当达到速率限制或配额时可以拒绝新调用。组织需要两者兼具：令牌限制用于在代理运行时控制消耗，财务预算则用于确保所有者负责并防止财务部门措手不及。

目前，这两层使用不同的计量单位。平台以令牌为单位强制执行消耗，而财务规划和投资分配则以美元为单位。由于不同模型和报价的令牌价格存在差异，令牌配额无法转换为一个稳定的美元金额。

我们正在积极通过 Microsoft Foundry和 Azure API Management中的AI网关的未来功能缩小这一差距，这些功能将美元计价的预算、更细粒度的归因以及基于策略的控制更紧密地结合到代理运行的位置。

评估代理创造的价值

仅对消耗设置上限只能解决治理问题的一半。

虽然成本控制可以帮助组织管理支出，但它们无法回答一个更重要的问题：代理创造的价值是否足以证明这项投资？

最便宜的代理不一定是最佳投资。一个成本更高但能显著解决更多案例的代理可能值得增加容量，而一个成本低廉但很少完成任务的代理可能不值得。因此，治理需要在令牌和美元之外引入第二个计量单位：业务成果。

这最终是一个投资回报率（ROI）问题。组织希望了解其代理创造的价值是否超过其成本。然而，将业务成果与运行代理的基础成本联系起来可能非常困难。

Foundry中代理的ROI, 目前处于私有预览阶段，帮助组织将代理成本与业务结果关联。团队可以定义要跟踪的成果，例如任务成功完成、客户满意度或案件转移。然后为这些成果分配商业价值并定义成功衡量方式。Foundry会追踪代理达成的成果，以及在此过程中产生的模型和工具成本，并计算以下指标：

• 生成价值：归因于成功业务成果的总价值。
• 总成本：实现这些成果所产生的模型和工具成本。
• 净价值：扣除成本后的剩余价值。
• 投资回报率（ROI）：相对于所需投资所产生的回报。

仪表板显示每日趋势并区分模型成本和工具成本。团队可以使用每对话平均价值、通过率和改进百分比来比较代理版本。这使得优化决策在商业层面具有说服力：不仅仅是“新版本使用了更少的token”，而是“新版本产生了更高的净价值”。

ROI功能还将业务视角与工程证据连接起来。团队可以检查ROI最低的对话和跟踪记录，发现模型过大、重复的工具调用或消耗token但未产生有意义成果的工作流程。由于ROI与可观测性数据相关联，团队可以直接从业务指标跳转到解释成本、质量及业务结果的跟踪记录、评估和运营信号。

低ROI的跟踪记录可能指向应路由到其他路径的请求、应删除的上下文或需要优化的代理配置。用于提高质量和效率的相同遥测数据现在可以帮助组织回答业务最终提出的问题：这个代理是否值得其成本？

将AI作为统一管理的投资系统运行

本系列的四篇文章共同描述了一个以三种速度运行的优化系统。在运行时，模型路由、部署选择和缓存会根据每个请求进行调整。在数天和数周内，上下文工程、记忆、工具和代理优化会改进工作流程。持续不断地，治理属性会记录消耗情况、强制实施限制，并衡量投资组合是否创造价值。

相同证据贯穿所有层级，回答不同问题：

1. 追踪显示代理在运行过程中执行了哪些操作，暴露高成本请求和低效上下文。
2. 评估显示输出质量是否达标，确保配置变更时仍能保障质量。
3. 成本归属显示资金流向，明确需干预的项目、代理或模型。
4. ROI 显示工作是否值得，帮助领导者判断是否优化代理、增加容量或淘汰代理。

成本只是更广泛治理故事的一部分，明确各方责任归属非常重要。

• Foundry 专为开发代理的开发者而建。这是开发者构建、测试和优化代理的地方，Foundry 控制平面为他们提供对已部署内容的运营视图，从成本趋势和异常到令牌使用和生命周期控制，集成 Azure Policy、Microsoft Defender 和 Microsoft Purview，确保合规性和安全性不是事后考虑。
• Microsoft Agent 365 专为负责整个企业资产的人员而建。IT 管理员和安全团队使用它来发现、清点、保护和管理租户内的所有代理，无论代理来自 Foundry、Microsoft 365 还是合作伙伴平台，并将已应用于人员的相同身份、访问和数据保护扩展到代理。

本系列中讨论的 FinOps 能力位于 Foundry 一侧，为开发人员和平台团队提供控制杠杆以保持支出可预测，而 IT 和安全团队则在 Agent 365 中治理周边资产。

代理优化并不是将每个请求的成本降至零。它关乎以对待其他重大投资时同样的严谨态度运行代理，而这正是 Foundry 的设计初衷：帮助开发者构建和管理那些从设计上就高效、扩展时受控、并对所创造价值负责的代理。

入门

如果您目前在治理代理，请首先使其消耗情况可见且可归属。识别哪些代理和团队在推动使用，应用请求时限制以控制意外消耗，并将这些控制措施与财务预算和警报结合。然后将成本与业务成果关联，以便决定优化、扩展或淘汰哪些代理。

• 强制实施令牌限制 以管理 Microsoft Foundry 中的模型部署。
• 在 Microsoft Foundry 中 规划、监控和分配 AI 成本。
• 在 Cost Management 中 创建预算和告警。
• 在 Azure API Management 中 探索 AI 网关治理功能。
• 了解 Foundry 中的 可观测性 和 代理的 ROI。

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

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