Databricks如何一小时内消除每年120万美元AI Agent浪费

Databricks 的工程师严重依赖 AI 代理来简化和加速他们的工作。反过来，这些代理不仅需要访问不同的基础模型，还需要访问带有工具的 MCP 服务器，这些工具能够访问相关工件（例如系统日志、使用表、支持工单、维基）。在之前的博客中，我们分享了在规模化管理 AI 成本时，不仅需要优化模型选择，还需要优化代理如何使用工具。在本文中，我们描述了如何寻找代理工具使用中的成本节约机会、在此过程中遇到的挑战，以及 Unity Gateway 中的 OTel 跟踪如何将从分析到实现每年 120 万美元节约的路径缩短到仅仅一个小时。

让我们的开发人员能够构建他们的代理极大地提高了生产力，但随着使用量的增加，我们也面临成本上升的问题。我们开始调查多种优化方案，其中一个怀疑是工具调用失败的隐藏成本。具体来说，当工具出错时，调用代理很少会大声失败。相反，它会重试、猜测，最终绕开问题，全程悄悄消耗 token 和开发人员的时间。这种浪费很危险：从外部看，任务仍然完成，而聚合成本仪表板可能显示 token 支出小幅上升 10%，这很容易被误解为使用量增长。

我们使用 Unity Gateway 的跟踪和Genie One在我们的代理群中调查了这一怀疑。我们发现了工具服务器中的七个小的错误，这些错误估计导致每年浪费 49.9 万美元的 token以及每年约 12,000 个工程小时的代理等待时间。总体而言，这估计是每年 120 万美元的生产力损失。

找到所有七个错误、量化它们并修复它们大约花了一个小时。本文描述了我们所遵循的过程以及它教给我们的关于为代理构建工具的经验。

如何监控 AI 代理和 MCP 活动

当我们最初在 Databricks 广泛部署 AI 代理用于编码和内部工作流时，由于缺乏对代理工具调用和整体活动的可见性，我们无法管理甚至完全理解成本。为了解决这个问题，我们利用了 Unity Gateway，它会自动为所有 MCP 工具调用发出 OpenTelemetry 跟踪，包括工具名称、参数、错误（如果有）、token 计数、延迟以及将会话联系在一起的会话 ID。这些跟踪进入一个表，该表准确记录了我们的代理在任何时间窗口内的行为。无需新的仪器，网关已经位于每次调用的路径上，因此数据随时可用。

这使得 AI 代理成本管理更加可操作，我们不仅可以查看总 token 支出，还可以将浪费的支出归因于特定工具、错误和代理会话。

现在数据可用，下一步是探索：

• 哪种工具错误最常发生？
• 当代理遇到一个错误时，需要多少轮才能恢复？
• 每个错误在 token 和挂钟等待时间上花费多少？

通常，这类分析中昂贵的部分是 SQL 和模式探索。但有了 Genie One，我们只需将其指向跟踪表，用简单的英语问出这些确切的问题，几分钟内就能得到答案。我们的大部分时间花在阅读这些答案上，而不是编写查询。

跟踪揭示了什么：MCP 工具故障如何推高 AI 代理成本

Genie One 将模糊的怀疑（“代理似乎在 Jira 调用上挣扎”）在几分钟内变成了一个排序、量化的错误列表。以下是单个 24 小时窗口中的示例，展示了我们 Jira 和 Google Drive/Docs 工具服务器中的错误：

以最高量的错误为例，每天 535 次失败。Jira issues.search 工具接受一个 fields 参数，服务器执行了以下操作：

它期望一个逗号分隔的字符串，如 "key,summary,status"。但对于“字段列表”来说，数组是语义上自然的 JSON 类型，模型根据其对 JSON 约定的背景知识以及同一会话中相邻工具调用推断出了这一点。因此它传递了合理调用者可能传递的结构化值：

列表没有 .split()，因此服务器引发了 'list' object has no attribute 'split'，这是一个原始 Python 堆栈跟踪，没有告诉代理它做错了什么。因此代理再次猜测。有时它重试相同的列表并同样失败；有时它重新读取模式或退回到试错。平均需要12 轮才能恢复，30% 的会话不止一次遇到错误。一次 .split() 调用估计每年在 token 上花费 8.7 万美元，并在代理等待时间上花费 4,850 小时。

Google Drive 的 “Invalid field selection” 错误在数量上更为惊人：所有drive_file_get调用中有 49.6% 失败，因为模型不断传递看起来有效的 Drive API 字段名（id、name、mimeType），而工具的端点不接受这些名称。

真正的教训：如何为 AI 代理和 LLM 设计 MCP 工具

显而易见的结论是“写更好的错误消息”，数据支持这一点。恢复成本几乎完美地反映了错误消息质量：

但“好的错误消息有帮助”是旧闻。更有趣的问题是为什么模型首先会“错误”地调用这些工具。在大多数这些情况下，它并没有。

MCP 工具签名通常故意定义得不够具体。我们有意让它们保持松散：一部分是为了通用性，一部分是为了节省上下文令牌，因为每次调用模型都会为每个参数描述支付令牌成本。结果是，当签名对字段含糊其辞时，模型会用合理的猜测来填补空白，而 JSON 数组是对字段列表的合理猜测。这个错误不在于模型错误地调用了工具，而在于服务器只接受了几种合理解释中的一种，并在其他解释上崩溃。

因此，设计原则与反射式原则相反：为代理设计的工具应当适应 LLM 自然调用它们的方式，例如，将列表强制转换为字符串，对省略的参数使用默认值，吸收意外的参数，等等。一个定义不足的签名是对灵活性的承诺，工具应该在接收端兑现这一承诺，而不是在遇到与其作者心中设想形状不符的第一个输入时就崩溃。

简单部分：我们如何在一小时内减少 AI 代理的浪费支出

修复本身很简单，并不是这个故事中有趣的部分。一旦 Genie One 给我们提供了按优先级排序的错误列表，以及模型实际发送的内容，在工具服务器上应用这些修复就是使用编码代理快速完成的事情。整个循环（发现、量化、修复）大约花了一个小时。

稀缺且昂贵的步骤从来不是编写修复代码，而是知道修复什么。追踪加上 Genie One 将这个步骤从研究项目变成了可以随口问出的问题。

闭合循环：如何持续监控并降低 AI 代理成本

随着越来越多实际工作转移到代理上，静默工具故障成为首要成本中心，这种故障隐藏在“使用量增长”中，从不通知任何人。捕获它们的循环廉价且可重复：Unity Gateway 使代理行为可观察，而 Genie One 使这种行为无需 SQL 即可查询。

结合起来，这为团队提供了一种可重复的方式来监控 AI 代理、诊断 MCP 工具故障，并减少浪费的 AI 支出。如果你针对自己的工具运行代理，也请这样做。追踪调用，并询问 Genie One 什么持续出错。

开始使用 Unity Gateway 与 Genie One 进行追踪分析

Unity Gateway 现已正式可用，您现在可以使用统一的追踪表（现在处于测试阶段）监控所有 AI 活动。请参阅我们的文档了解如何开始。