如何通过 MLflow AI Gateway 防止代理成本失控
控制代理成本最难的部分不在于设定预算，而在于在投资错误的优化方案之前，明确代理的哪一部分正在推高成本。
本文将介绍如何使用 MLflow AI Gateway 作为多代理系统的控制平面。我们将以生产环境中的客户支持代理为例，展示如何精确锁定成本在代理各个步骤中的累积情况，确定优化方向，并在支出失控前设置预算警报。
注意：本文中的成本数字仅供说明。实际成本将根据您的供应商、定价层级和 token 使用量而有所不同。
认识一下我们的代理
我们的代理（姑且称之为 SupportBot）是一个旨在处理一级客户支持的多代理系统。其架构如下：
当客户发送消息时，嵌入（embedding）流水线将查询转换为向量，并从我们的知识库中检索相关上下文。协调器（orchestrator）读取查询并决定调用哪个子代理：处理“我的包裹在哪里？”问题的订单查询代理、处理退货请求的退款代理，或是处理一般政策和产品问题的 RAG 代理。子代理响应后，协调器会综合生成最终答案，并经过护栏（guardrail）检查，以在回复客户前捕捉个人身份信息（PII）泄露或不恰当的语气。
每个组件都能很好地完成工作，但没有人对其运行成本进行过建模。
单张工单背后的隐形成本构成
每张工单都会触发一系列调用。链条上的每一个环节都有对应的价格标签。
- 嵌入：将查询转换为向量以进行知识库检索
- 协调器路由：由 LLM 决定由哪个子代理处理请求
- 子代理执行：实际工作部分，如果代理需要重试或调用工具，可能需要额外的调用
- 响应合成：由协调器编写面向客户的回复
- 护栏检查：再进行一次 LLM 调用以验证安全性和语气
一个问题 = 4–6 次 LLM 调用（在没有错误的情况下）。
这是单张工单（工单 T001，订单状态查询）的成本明细：
四次 LLM 调用，四种不同的成本贡献。协调器路由很便宜（$0.0009），但合成器和护栏检查合计占总成本的 80% 以上。现在将其乘以每天的所有工单数。
以 500 张工单/天计算 20 张样本工单的表现如下：
在每天 500 张工单的情况下，成本约为 $9.40/天，这看起来还算可控。但扩展到每天 10,000 张工单时，费用就变成了 ~$188/天 — 大约 $5,650/月。如果上下文窗口膨胀或在供应商停机期间重试率飙升，成本很容易翻倍。
问题不在于单次调用昂贵，而在于代理成本是乘法累积而非加法累积的。这种乘法调用模式是多代理系统中生产成本意外激增的最常见原因之一。
扩展规模前：上线检查清单
在您的代理处理第一张生产工单之前，请确保已落实以下五点。每一项都对应本文后续章节，将其视为最低可行性成本基础设施：
| # | 检查点 | 重要性 |
|---|---|---|
| 1 | 通过网关路由所有 LLM 调用 | 凭证、流量和成本跟踪的统一控制平面 |
| 2 | 从第一天起启用自动日志和追踪 | 无法度量就无法优化 |
| 3 | 至少设置一项预算警报策略 | 在支出失控演变成危机之前将其拦截 |
| 4 | 检测缓存命中/未命中跟踪 | 确保后续添加缓存时仪表板依然准确 |
| 5 | 将“每解决一张工单的成本”定义为北极星指标 | 将 LLM 支出与业务成果挂钩，而非原始 API 调用次数 |
如果您已经在生产环境运行但未做到这些，没关系，下面的每一步都是可以补救的。但如果您还在构建阶段，现在是引入它们成本最低的时候。
第 1 步：通过网关进行路由
第一步很简单但也至关重要：将所有 LLM 调用通过 MLflow AI Gateway 进行路由，而不是直接调用供应商。这为您提供了一个统一的凭证、流量和成本跟踪控制平面。
只需两条命令即可开始：
pip install 'mlflow[genai]'
mlflow server
打开网关 UI https://:5000/#/gateway。在 API Keys 下注册您的供应商凭证。然后在 Endpoints 下为代理中的每个角色点击 Create Endpoint，为其命名，选择提供商和模型，并附加 API 密钥。SupportBot 使用了四个端点：
| 端点 | 模型 | 代理中的角色 |
|---|---|---|
orchestrator | GPT-5.1 | 将工单路由到正确的子代理 |
sub-agent-light | Claude Haiku 4.5 | 用于 FAQ / 状态查询 |
sub-agent-strong | GPT-5.1 | 推理要求高的退款/升级流程 |
embeddings | bge-large-en | 知识库检索 |
每个端点都有自己的 URL 路径，可以独立进行路由、限流和预算控制。请参阅 Create & manage endpoints 获取完整指南。
在代理端，只需极小的改动——将 base_url 指向网关即可：
from openai import OpenAI
# Before: calling Databricks FMAPI directly
# client = OpenAI(base_url=f"{HOST}/serving-endpoints", api_key=TOKEN)
# After: routing through MLflow AI Gateway
client = OpenAI(base_url="https://:5000/gateway/mlflow/v1", api_key="")
您的代理代码保持不变。网关处理其余部分：凭证管理、请求路由以及对每次调用的自动追踪。
第 2 步：查看资金去向
一旦流量通过网关，每个请求都会自动追踪 token 数、成本、模型名称和延迟，无需额外配置。
要在代理代码中捕获追踪信息，请启用 自动日志（autologging）。
import mlflow
mlflow.openai.autolog()
现在，当 SupportBot 解决工单时，您可以查看到完整的 追踪记录，包括从嵌入到护栏检查的链条中每一个 span，以及每个步骤的成本归属。
追踪记录显示了完整的 span 层级：process_ticket → route_query → refund_agent → synthesizer → guardrail，每一个都有其延迟和 token 数。一个客户问题，四次 LLM 调用，全程耗时约 14 秒。
追踪记录揭示了哪些组件消耗了最多的 token，明确了优化的切入点。
第 3 步：设置预算护栏
可见性告诉您发生了什么，预算策略则告诉系统如何处理。MLflow AI Gateway 支持基于阈值的预算策略，有两种操作：ALERT（触发 webhook，流量持续）和 REJECT（触发 webhook 并返回 HTTP 429 以阻止新请求）。
在网关 UI 的 AI Gateway > Budgets 下，点击 Create budget policy 并设置预算金额、重置周期（日/周/月）以及操作（ALERT 或 REJECT）。在 Budget alert webhooks 下注册一个 Slack webhook，以便 ALERT 策略发送到您的值班频道。这是我们为 SupportBot 制定的分层策略：
| 策略 | 预算 | 重置 | 操作 |
|---|---|---|---|
| 早期预警 — 每日 | $90 (上限的 60%) | 每日 | ALERT → Slack |
| 安全网 — 每日 | $150 | 每日 | REJECT (HTTP 429) |
| 按团队 — 每月 | $3,000 | 每月 | ALERT → Slack |
| 按团队 — 每月硬限制 | $5,000 | 每月 | REJECT (HTTP 429) |
这种分层方法是有意为之的。每天 $90 的预警让我们有时间在系统崩溃前进行调查。每天 $150 的拒绝策略是最后一道安全网，防止重试风暴或上下文膨胀导致糟糕的一天演变成灾难。月度策略则提供了长期上限，以防缓慢的支出增长未被察觉。
默认情况下，网关在处理过程中跟踪支出。详细参考请参阅 Budget alerts & limits。
以下是这些阈值在不同流量级别下的处理效果：
当 $90 的警报触发时，Slack 会在我们的 #agent-ops-alerts 频道收到通知，详细说明触发的策略、当前支出和阈值金额。这让值班工程师有时间检查仪表板，判断激增是合理的流量增长还是系统异常。
警惕重试循环。 预算策略能限制总支出，但无法阻止在几分钟内耗尽每日额度的瞬时激增。请在网关层面单独设置每分钟或每小时的速率限制，而不仅仅是每日预算。如果追踪视图显示错误率突然跳升且请求频率很高，那就是重试风暴，即子代理在反复轰炸故障中的提供商端点。至少，代理中的每个 LLM 调用都应使用带有抖动（jitter）的指数退避策略。否则，短暂的提供商错误可能引发数百次浪费的调用，在警报触发前就耗尽您的预算。
当 $150 的拒绝策略触发时，新请求将收到 HTTP 429 响应。代理需要优雅地处理这种情况。
在网关中设置重试和模型回退。 对于每个端点，网关都有一个 Priority 2 (Fallback) 部分，您可以在其中列出备选模型，以便在主模型报错或触发限流时依次尝试。对于 orchestrator，我们添加了 Claude Haiku 4.5 作为成本优化回退，因此在 GPT-5.1 发生短暂故障时，流量会自动切换到更便宜的模型，而无需修改任何客户端代码。详细配置请参阅 Traffic routing & fallbacks。
剩下的就是由客户端决定当所有模型选项都耗尽时，用户会看到什么。
from openai import OpenAI, RateLimitError
gateway = OpenAI(base_url="https://:5000/gateway/mlflow/v1", api_key="")
def call_orchestrator(messages):
try:
# Retries and model fallback are handled by the gateway
return gateway.chat.completions.create(model="orchestrator", messages=messages)
except RateLimitError:
# Every fallback exhausted — hand off to humans or queue
if is_urgent(messages):
return {"role": "assistant",
"content": "I'm connecting you with a human agent now. "
"Please hold — someone will be with you shortly."}
enqueue_for_later(messages)
return {"role": "assistant",
"content": "We're experiencing high demand. Your request has been "
"queued and we'll follow up within 2 hours via email."}
第 4 步：通过模型路由、缓存和验证进行优化
在成本可视化和护栏措施就位后，最后一步是优化。并非所有查询都需要最强大（也最昂贵）的模型。简单的 FAQ 查询和订单状态检查完全可以使用 Claude Haiku 4.5，而复杂的退款推理则确实能从 GPT-5.1 中获益。
MLflow AI Gateway 的流量拆分功能让您无需重写代理代码即可测试此假设。在 orchestrator 端点上，打开 Priority 1 (Traffic Split)，点击 Add Model，并分配总和为 100% 的权重（例如 70% GPT-5.1 和 30% Claude Haiku 4.5）。网关会在零停机时间内更新配置，因此您可以根据评估结果随时调整拆分比例。
我们最初将 30% 的协调器流量路由到 Claude Haiku 4.5，并通过 MLflow 的评估追踪监控质量。当我们确认路由准确性没有下降时，调整为 50/50，然后是 70% 的 Haiku。事实证明，协调器的工作（分类应调用哪个子代理）完全在 Claude Haiku 4.5 的能力范围内。
缓存作为补充手段。 精确匹配缓存和语义缓存（匹配意图相同但措辞不同的查询）可以完全消除冗余的 LLM 调用，特别是在嵌入和 FAQ 检索路径中，客户往往询问几乎相同的问题。关键在于确保缓存的响应依然出现在您的 MLflow 追踪记录中，并带有如 cache_hit=true 和 cost=0 等元数据，从而保持仪表板和单工单成本指标的准确性。缓存不能代替智能模型路由，但它能叠加节省效果：路由到更便宜的模型，并且在之前见过该问题时彻底避免调用。
提交前进行验证。 未经衡量的流量拆分只是在猜谜。在将大部分流量切换到更便宜的模型之前，请运行一次留出法评估：抽取近期的一组路由决策，通过候选模型重新运行，并衡量路由准确性。我们设定了 >95% 准确率的阈值——如果廉价模型在评估集上无法达到这一标准，我们就不会进一步切换。MLflow 的评估追踪使这一切变得直接：将原始决策与候选输出一起记录，并以编程方式进行比较。
关键点总结
-
代理成本是乘法累积的，而非加法累积。 每个子代理、每次重试、每次护栏检查都会成倍增加单次交互的成本。从第一天起就要做好计划，不要等到账单送达时才处理。
-
看不见就无法控制。 追踪一切。网关的自动追踪功能让这一切毫不费力，除了
mlflow.openai.autolog()，我们没有添加任何额外的可观测性代码。 -
预算限制是安全网，而非策略。 真正的节约来自于了解您的成本分布并进行针对性的优化，如模型路由。预算限制只是防止最坏情况发生的手段。
-
MLflow 网关将成本控制从被动消防演变为持续运营循环。 可视化推动优化，优化改变成本分布，预算策略拦截意外，所有这些都在一个统一的控制平面下完成。
有关 MLflow AI Gateway 的更多信息，请参阅：