摘要
- Databricks追踪了内部AI智能体的MCP工具调用,发现了7个小漏洞,这些漏洞正是每年约120万美元损失(49.9万美元token费用+1.2万小时工程时间)的根源
- 结合Unity Gateway的追踪功能与Genie One的自然语言查询,找到并修复这些漏洞只用了一个小时
- Jira工具每天出现535次失败,平均要重试12次才能恢复,而Google Drive工具的调用失败率高达49.6%
表面上看只是"用量增加"
Databricks内部广泛在编程等多项业务中接入AI智能体,随着使用量上升,成本也跟着增加。问题在于,没办法分清这种成本增长是正常的用量扩大,还是哪里出了问题导致的资金外流。因为智能体在工具调用失败时不会大张旗鼓地报错,而是悄悄重试、自行猜测,最终想办法绕过去把任务做完。从外部看,任务似乎顺利完成了,汇总仪表盘上只显示token支出增加了10%,这种结构很容易被误认为只是普通的用量增长。
简单来说,MCP(模型上下文协议)是AI智能体调用Jira、Google Drive等外部工具时使用的标准规范。Databricks在自动记录所有MCP调用的Unity Gateway之上,叠加了可以用自然语言提问并获得答案的Genie One,由此揪出了潜藏的漏洞。
追踪加自然语言查询,一小时锁定问题
为了验证这个猜测,Databricks动用了Unity Gateway的追踪功能和Genie One。Unity Gateway会为每一次MCP工具调用自动记录OpenTelemetry追踪信息,把工具名称、参数值、是否出错、token数量、延迟时间、会话ID都汇总进同一张表里。由于网关本来就位于所有调用路径上,不需要额外埋点,数据可以直接拿来用。
接着把Genie One连接到这张追踪表上,用自然语言提出诸如"智能体在调用Jira时好像在空转"这样模糊的疑问,几分钟内就得到了一份按严重程度排序的漏洞清单。不用写SQL、不用翻数据库结构,靠一句普通的提问就拿到了答案。据说这一个小时里,大部分时间不是花在写查询上,而是花在读懂查询结果上。从发现漏洞、量化影响,到用编码智能体完成修复,整个流程大约只花了一个小时。
Jira和Google Drive上发生的事
出现频率最高的漏洞出自Jira的issues.search工具。这个工具原本期望fields参数是像"key,summary,status"这样用逗号分隔的字符串,但模型按照JSON的惯例,自然而然地把值传成了数组格式。服务器对数组调用.split()方法,结果只抛出一段Python报错信息,智能体从这条报错中完全得不到任何有用线索,只能重复同样的错误,或者反复去读取schema,原地打转。平均要重试12次才能恢复,而且30%的会话里同一个错误会反复出现两次以上。
Google Drive那边的漏洞影响范围更大。drive_file_get调用的失败率高达49.6%,原因是模型不断发送id、name、mimeType这类在Google Drive API文档里看起来合情合理的字段名,但这个工具的端点实际上根本不接受这些字段。
| 漏洞 | 失败频率 | 平均恢复所需重试次数 | 备注 |
|---|---|---|---|
| Jira issues.search | 每天535次 | 12次 | 30%会话复发,每年损失8.7万美元+4850小时 |
| Google Drive drive_file_get | 占全部调用的49.6% | 原文未单独给出数值 | 字段名不匹配导致反复失败 |
工具设计要贴合模型实际调用的方式
表面上的结论似乎是"把错误信息写得更清楚一点",数据也确实支持这一点。但更有意思的问题是,模型当初为什么会"用错"方式调用工具。Databricks认为,在大多数情况下模型并没有犯错。MCP工具的签名往往为了通用性而故意写得比较宽松,而且参数说明里的每一个字都是模型每次调用都要付出的token成本,所以说明常常被简化。字段规范一旦含糊,模型就会用合理的推测去填补空白,把字段列表以JSON数组的形式传过去正是这类合理推测之一。问题在于,服务器在多种可能的解释里只接受其中一种,遇到其他情况就直接卡死了。
"找出该修什么,一直比动手修更难"(Databricks官方博客)这句话概括了这个案例的核心。修复本身其实很简单,只是把列表转换成字符串、给缺失的参数补上默认值、让工具能容忍意外传入的参数而已。
现在可以做些什么
Databricks在今年8月4日宣布正式发布Unity AI Gateway。这次用到的追踪功能来自网关的统一追踪表,而这张统一追踪表本身目前还处于公测阶段。如果所在团队也把智能体接入了各种工具,可以按同样的思路展开排查:先在网关这样的层面收集工具调用日志,再接上可以用自然语言提问的界面。Databricks在文章末尾也建议,"如果你把智能体接到了自己的工具上,不妨照做一遍——追踪调用记录,问问Genie One到底哪里一直出问题"。
编辑视角
这个案例的重要之处,不在于损失数字本身,而在于浪费藏身的地方。当智能体悄悄吞下失败、靠重试掩盖问题时,成本仪表盘上呈现的就只是"用量增加了"。要是换成人工操作的系统,报错会显示在屏幕上,总会有人注意到;但智能体会自己绕过去,所以没有人会拉响警报。随着智能体支出在各类组织内不断扩大,这种悄无声息的失败,未来很可能会在更多公司的预算里反复上演。
接入过生产环境智能体的团队,对这种情况应该不陌生。一开始只是感觉token费用比预期涨了一点,后来打开日志才发现,同一个错误已经重复了几百次。这个案例的真正价值在于,由于追踪基础设施本来就已经搭好,整个排查过程不再是要花上一整天的项目,而是变成了随口一问就能得到答案的事。
给国内运营内部智能体团队的实用启示很明确:构建工具服务器时,参数规范可以适当放宽,但这种宽松必须由服务器自己去消化,而不能一遇到就直接崩溃退回报错。智能体成本如果在上涨,也不应该只盯着总量仪表盘,而要养成按工具、按错误类型拆分支出的习惯。可以预见,未来几个月里,智能体工具服务器的错误处理方式本身,很可能会成为厂商选择和内部审计的重要标准之一。
评论