Agent cost management is about more than the model

Agent 成本管理不仅仅是模型本身 - Arize AI

您的应用程序每次调用 LLM 都会产生费用，而基于代理的应用程序会进行大量 LLM 调用。单个用户请求会扩展为规划、工具选择、检索和合成步骤，每一步都需要调用模型，而所有这些费用最终都会以一个无法区分的条目出现在月底账单上。

在原型设计阶段，这并不重要。但一旦有真实流量，它就会成为基础设施账单上较大的数字之一，而且它有一个普通计算资源不具备的特性：代理成本随着使用量呈非线性增长。由于上下文会在对话轮次中累积，返回大有效载荷的工具不会只产生一次费用，而是在相同追踪中的后续每一步都会产生费用，因为该有效载荷现在已成为重新发送给模型的对话内容。

因此，您可能会看到流量翻倍，但随着交互模式的变化，推理成本的增长幅度会超过两倍。这使得成本成为可观测性故事中的关键部分，而成本控制则是扩展过程中的核心环节。重要的是，您的可观测性系统不仅要告诉您哪些部分昂贵，还要说明如何降低这些成本。

成本优化常被功能开发优先级取代

优化生产代理成本的一个常见问题是，这通常不是任何人的具体职责，而且这项工作既繁琐又耗时，因此没有人愿意接手。

这项工作并非火箭科学：查看遥测数据，按支出对跨度进行排序，然后将成本与质量评分相关联，以找出那些支出不值得的步骤。最后，将昂贵的跨度追溯到生成它们的具体函数，并起草一个范围明确的小型差异。

这是一个代理擅长解决的问题类型。证据以易于访问的结构化数据形式存在，分析过程是机械化的，决策由证据驱动。对昂贵代理的自然回应是另一个代理，其职责是控制它们的支出。

更妙的是，这个过程是一个循环，因此您可以持续且自主地运行它。诊断是机械过程，修复措施相对较小且能快速审查：精简有效载荷、缩短提示、添加缓存、合并冗余调用、降级过度配置的模型。重要的是，这也可以轻松验证：一旦部署更改，相同的证据将明确告诉您成本是否真正下降。虽然繁琐但机械，验证成本低廉：这正是代理的理想领域。

让代理来处理

Arize AX 现在以托管代理的形式提供成本控制功能，该代理直接在我们的平台内运行。在“新建代理”选择器中，它与 Signal 和调试代理并列显示。

成本代理与 Signal 和调试代理一起出现在“新建代理”选择器中。

配置成本代理只需几个选择。您选择运行代理的集成方式。选择它被允许读取的追踪项目：此处是 live-fin-langgraph，这是一个使用 LangGraph 构建的多代理金融助手，其中主管代理在检索金融数据、进行网络研究和生成最终摘要的代理之间路由问题。您决定是单次运行还是按计划运行。

配置成本代理：选择集成方式、可读取的追踪项目，以及是单次运行还是按计划运行。

不过这里有一些重要的选择需要考虑。首先是仓库连接：通过附加 GitHub 技能，代理可以读取实现代码，而不仅仅是遥测数据。这使它不仅能诊断问题，还能创建直接解决问题的 PR。第二个是自动化模式：您可以选择在一次性会话中尝试，或设置计划任务自动运行，从而在最小人工干预的情况下让整个流程自主运行。

启动前您可以看到任务提示，并可以对其进行编辑。这是添加额外领域上下文的好方法，例如那些不明显或之前尝试过的约束条件。

启动前任务提示是可见且可编辑的，因此您可以添加已尝试过的约束或策略。

实际应用结果

代理在沙盒环境中运行，您可以实时观看并随时中断其工作过程。在此示例中，运行耗时 16 分钟，共执行了 62 步。

16 分钟的运行：500 个 LLM 跨度，100% 使用 gpt-4o-mini，研究代理节点的令牌分布达到 20 倍。

它首先报告的是最明显的问题上没有任何需要报告的内容：

30 天基线：500 个 LLM 跨度，100% 使用 gpt-4o-mini。好消息是：没有发现前沿模型滥用情况。模型选择已经是最优的。

在优化代理成本时最明显的变化是降级到更便宜的模型。在这里，工具已经超越了这种简单的策略，开始深入分析。它按节点拆分支出：处理财务数据和网络研究的代理节点占成本的 72%，监督者占 15%，摘要器占 12%。因此它开始分析代理具体在做什么。

代理节点的令牌分布（用代理自己的话来说）非常极端：中位数为 616 个令牌，95% 分位数为 10,240，最大值为 11,983。中位数调用和尾部之间存在 20 倍差距。它追踪到尾部来自单个函数：tools.py 中的 read_webpage，每次调用返回多达 50,000 个字符（约 12,500 个令牌）。它还发现了机制：网页内容会进入 LangGraph 的共享 AgentState.messages，并在相同追踪的后续每一步重新发送给模型。一次大页面抓取会引发三到四次下游 LLM 调用。样本中有 71 次这样的调用。

随后又发现了三个问题。首先，在 631,654 个提示令牌中没有任何缓存命中。监督者只有两个唯一的系统提示，被调用 184 次，但平均每个提示只有 688 个令牌，低于 OpenAI 的 1,024 令牌自动缓存阈值，因此这些重复内容没有被缓存。摘要节点使用了错误的消息角色，重新摄入了完整的对话历史记录（包括原始 API 负载）。另外两个财务工具在只需要最近一个周期数据时，却返回了多年时间序列数据。

这些都是上下文管理挑战，而代理足够智能可以直接解决这些问题。

直接修复

由于仓库已连接，调查最终以拉取请求结束。

调查以拉取请求结束：进行了 6 处修改，合计约占每月账单的 35-40%。

六项修改，每项都有预估的节省效果：将 read_webpage 从 50K 字符截断至 6K 字符，修复摘要器的功能和消息过滤机制，通过 set_llm_cache() 连接 InMemoryCache 缓存，将两个金融工具的调用次数上限设为 2 次，将监督器的上下文缩短至最近四条消息，并将监督器的 LLM 拆分为独立实例以便后续实现按角色路由。综合来看，这些修改可减少约 35-40% 的月度账单。

最后一项修改尤其值得关注，因为它并非直接与成本相关。这是一个重构，为未来优化预留了空间。这种做法体现了资深工程师在修改文件时的远见，而不是单纯通过成本模式匹配得出的结论。

代理随后通过告知你合并后的监控指标来闭环：代理节点的 p95 值应从约 10,240 个 token 降至 2,500-3,000。它还指出下一个优化方向：监督器的系统提示词需要增加约 340 个 token 才能突破自动缓存阈值，这将使所有 184 次月度路由调用都具备缓存命中资格。

这就是你期望的代理表现：按优先级列出发现结果并解释机制，提供差异对比，对后续监控数据做出可证伪的预测，并明确指向下一步行动。

人类仍是最终决策者

此处没有任何代理自主推动生产环境变更的逻辑。成本代理提出建议，拉取请求本身就是一个提案。你的工程师会审阅差异并做出决策，其中部分修改会被拒绝：例如将 read_webpage 截断至 6K 字符，这是关于研究代理需要多大页面内容的判断，属于产品决策而非纯粹成本决策。

这就是代理应扮演的角色：分析 500 个追踪点，找出 71 次关键调用，并推导出真正问题是工具负载被静默重发了四次。所有涉及产品变更的最终决策权仍保留在人类手中。

入门指南

AX 当前已全面支持成本追踪功能：它会在跨度和追踪层面为每个 LLM 调用计费，提供常见模型的默认配置，并支持自定义费率、缓存 token、推理 token 和分层计价。开启该功能、确认模型与默认配置匹配后，你便拥有了整个闭环所需的基础架构。

托管代理（包括成本代理）目前处于企业版测试阶段。如果你希望每周由代理而非每季度由工程师审计追踪数据，请联系你的 Arize 账户团队。