智能体组合审计：如何在不损害团队自主性的前提下，将15个独立智能体整合为统一平台

大多数工程团队在推出第一个AI智能体六个月后，会发现自己已经拥有了15个。这并非出于规划——而是因为每个团队都解决了真实问题并付诸实施。客服团队构建了分类智能体，数据团队构建了报告生成智能体，平台工程团队构建了运行手册智能体，基础设施团队又构建了三个。这些智能体之间没有共享的认证、日志、工具或评估方法。Token费用从十几个供应商账户持续流失，而没有人能告诉你哪个智能体负责哪些开销。

这一时刻，正是能够规模化AI的工程组织与不能的工程组织之间的分水岭。答案不是放慢智能体的开发——而是在熵使整合变得不可能之前，先进行一次组合审计。

为什么你会走到这一步

智能体蔓延遵循着可预测的模式。构建一个智能体的门槛——一段提示词、几个工具定义、一个循环——比传统软件开发低了几个数量级。任何具备Python技能和API密钥的团队都能在一天内交付一个可用的智能体。这在很大程度上是好事：它加速了特定领域的自动化，让最了解问题的人来构建解决方案。

问题在于结构。团队构建智能体的方式与构建内部工具相同：快速、局部化、针对当下问题优化。权限管理是事后考虑，日志是临时的，评估是手动的。费用计入单一共享API密钥，没有任何归因元数据。当一个智能体出现故障，值班工程师发现既没有追踪记录，也没有负责人。

Gartner报告显示，2024年第一季度至2025年第二季度，多智能体系统咨询量激增1445%，是过去十年中任何企业技术采用最快的速度。调查显示，82%的组织发现了至少一个其安全或IT团队之前未知的AI智能体。这是智能体版本的影子IT，并积累了相同的治理债务。

你无法再非正式管理的临界点通常出现在约十个智能体时。到了十五个，你面临真正的问题：重复的API集成、相互冲突的工具定义、零组合级成本可见性，以及无法回答诸如"我们哪个智能体处理客户数据？"或"我们每个业务单元的月均LLM支出是多少？"这样的基本问题。

四维审计

在整合任何内容之前，你需要清楚地了解自己拥有什么。组合审计涵盖四个维度：

能力图谱。 对每个智能体：它做什么、调用哪些工具、访问哪些数据、谁负责？目标是找出能力重叠——各团队在不知情的情况下独立构建了功能重叠度超过70%的智能体。重叠并非总是坏事（一定程度的冗余是可以的），但它必须是有意为之的选择，而不是意外。

评估覆盖率。 哪些智能体有任何形式的正式评估？哪些有结构化基准测试？哪些只在出现问题时才手动检查？大多数组合明显分为两类：具有CI集成评估的智能体（通常由ML工程师构建）和没有可重复评估的智能体（通常由应用团队构建）。没有评估意味着无法发现因模型升级、提示词变更或工具Schema漂移导致的回退。

基础设施依赖。 清点每个智能体实际运行所需的内容：调用哪些LLM供应商、使用共享还是独立凭证、是否向集中式可观测性系统发送追踪记录、维护什么内存后端。特别关注维护自身持久状态的智能体——这类智能体往往有最出人意料的故障模式和最大的安全暴露面。

成本归因。 统计过去30天整个组合的LLM支出，并确定有多少比例可归因于已知的、有负责人的智能体。在大多数未托管的组合中，40-60%的LLM支出实际上是未归因的——计入共享API密钥，没有元数据将其与团队或功能关联。无法度量的，就无法优化。

以跨职能方式进行审计。获取数据，而非意见。当团队自我报告其智能体的功能时，他们往往低估工具重叠度、高估评估覆盖率。解析实际工具调用日志和供应商账单数据，而不是依赖README文件。

整合操作手册

一旦获得审计结果，整合工作分为三个并行推进的轨道。

轨道一：共享控制平面。

这是无论哪个团队拥有，每个智能体都应通过的基础设施。它包含三个组件：

LLM网关。 所有智能体与所有LLM供应商之间的集中代理。网关处理API密钥管理（团队获得虚拟密钥，而非真实供应商凭证），强制执行每个团队和每个智能体的速率限制，并为每个请求附加归因元数据。发送给任何供应商的每个Token都流经网关；这是获得组合级成本归因的唯一方式，也是强制执行预算控制的唯一方式。

加载中…