Why single AI agents fail at scale: Building governed multi-agent networks

为什么单个AI代理在扩展时会失败：构建受控的多代理网络

Component | Article_teaser

2026年7月23日

8分钟阅读

人工智能

Richard Naszcyniec

AI技术产品营销总监

Joshua Wilson

Subpattern | social_share_set

Component | social_share

分享

Subpattern | subscribe

Component | social_icon

订阅RSS

Component | Icon

© Red Hat, Inc. CC-BY-4.0授权

Subpattern | results_nav

组布局

Component | Nav_links

• 返回所有文章

Component | Generic

一个无法连接任何资源的安全代理，不过是一个带有徽章的昂贵自动补全功能而已。在《为什么提示级别的防护措施并不足够》一文中，我详细介绍了Red Hat AI如何为每个代理分配加密身份并限制其可访问的范围。这解决了信任问题，但并未解决连接性问题，而我认为大多数企业代理部署的瓶颈恰恰出现在连接性问题上——不是因为模型失效，而是因为基础设施出现了问题。

在我们之前的系列文章中，我们讨论过单个AI代理部署可能在一夜之间遭遇的三种失败：43个重复工单、4000美元错误计入账户、以及一个虚构的退款政策导致公司不得不支付280美元的退货。这43个重复工单部分源于连接性故障。代理将工单API当作原始HTTP调用处理：发送请求、超时、重试、重复。没有幂等性封装，没有协议级别的重试保护，也没有代理与API之间的基础设施能理解“此请求已成功完成”。框架处理了工具调用，但未处理受控的工具连接。开发环境中的可用代理与生产环境部署之间的差距不是框架问题，而是基础设施问题。Red Hat AI采用BYOA（自带代理）方法：平台为任何代理框架提供生产级基础设施，无需代码修改。这包括连接层。

一个代理、一个工具，没有问题

我可以在一个下午内将LangChain代理连接到Jira API。我做过。认证过程简单，数据格式有文档说明，错误处理也易于管理。这并不是难点所在。

真正的难点在于组织规模扩大后的情况。数十个代理连接到数百个系统，每个系统都有不同的认证方案、不同的数据格式和不同的访问策略。每次新连接都需要定制集成。每个定制集成都会增加需要凭证轮换和访问审查的安全表面。很快，集成层就会变成一个无人预算的第二代码库。

模型上下文协议（MCP）标准化了这一过程。MCP服务器将系统的功能封装成工具目录。任何兼容MCP的代理都可以通过该目录发现并调用这些工具。当Red Hat为Kubernetes的Red Hat OpenShift Cluster Management发布MCP服务器时，任何兼容的代理（如LangChain、CrewAI、Claude Code或自定义代理）都可以无需从头编写Kubernetes API集成，直接调用OpenShift操作。

对决策者而言，MCP意味着需要资助和维护的定制集成更少。对开发者而言，这意味着只需编写一个连接器，而不是每个代理都需要一个。但标准化协议并未回答更复杂的问题：这个代理可以调用哪个MCP服务器？使用什么凭证？在谁的授权下？

那些更复杂的问题正是MCP Gateway（基于Envoy的代理，目前在Red Hat AI上处于技术预览阶段）存在的意义。我认为它主要实现三个关键功能，而这三个功能对解决重复工单问题都至关重要。

• 聚合能力。代理通过单一网关端点进行连接，可接收来自组织内所有注册MCP服务器的统一工具目录。开发者无需了解特定工具由哪个后端服务器托管。代理只需调用工具，网关负责路由。对于需要管理跨多个部门数十台MCP服务器的团队而言，这意味着代理配置从需要逐台服务器设置转变为通过单一端点自动发现工具。

• OAuth2令牌交换。当代理调用需要访问下游系统（如数据库、工单API、Kubernetes集群）的工具时，MCP Gateway会将代理的身份令牌转换为针对特定服务的下游访问令牌（临时凭证，仅限单个服务）。代理永远不会持有跨服务凭证。如果计费代理的令牌被泄露，影响将被限制在计费API范围内，无法横向渗透到工单系统或集群。这种机制正是防止因凭证扩散导致4000美元错误账单事件的关键。

• 基于令牌声明的授权。代理可调用的工具由其身份令牌中的声明决定，而非模型在提示语中生成的内容。代理看到的工具目录已预先过滤为仅限其被授权使用的范围。提示注入攻击（通过恶意输入诱导模型调用未授权工具）会在网络层被拦截，甚至无法到达任何MCP服务器。

将这三项能力与那43张重复工单联系起来：若MCP Gateway与工单API的连接配置得当，协议层将包含幂等性处理。重试逻辑成为平台层面的统一处理，而非每个代理团队为每个API重复开发。对决策者而言，这意味着因基础设施缺失导致的生产事故将大幅减少；对开发者而言，最棘手的集成问题将在编写第一行代理代码前就被解决。

当单一代理已不足以应对

MCP Gateway将代理与工具连接起来。但复杂的企业工作流往往超出单一代理的上下文窗口或能力范围。

以客户支持流程为例：协调代理接收工单后，需要检查客户账单历史、查询退货政策、验证产品保修状态，并在符合条件时触发升级流程。这涉及4个不同领域，每个领域都有独立的数据源、差异化的访问策略和领域特定的安全控制。将所有内容塞进单一代理会导致模型在所有领域表现平庸，毫无专长。

Agent-to-Agent（A2A）是由谷歌最初开发的开放协议，允许一个代理跨团队和组织边界发现、委托并协调其他代理。A2A使多代理协作变得显式且可审计。与其使用单一的巨型代理，协调代理可委托给专业代理：账单代理处理账户历史，政策代理检查退货窗口，安全代理评估系统状态。每个专业代理返回结构化结果。

机制的核心在于 AgentCard，这是对代理能力、所需工具和模型依赖关系的机器可读描述。协调代理通过 AgentCard 发现可用的专家，分配任务并接收结果，而无需硬编码耦合。如果计费团队部署了改进后的计费代理，协调代理会通过更新后的 AgentCard 发现它。无需进行集成重写。

这种机制令人信服，因为它与组织当前的工作方式相呼应。团队会专精某一领域，发布接口，并通过明确的合同进行协调。A2A 为代理提供了类似的方式——通过开放协议而非专有编排层实现。对决策者而言，这意味着代理网络的组织结构可以与人类组织结构保持一致。对开发者而言，这意味着为自己的领域构建专业代理，而不是试图构建一个能完成所有任务的单一代理。如需详细了解 A2A 的安全考量——包括 AgentCard 保护、重放防护和跨代理提示注入——请参阅 Red Hat Developer 上的《如何增强 Agent2Agent 安全性》。

Red Hat 正通过 OpenShell 构建 A2A 支持，这是一个开源代理运行时，由 Red Hat 与 NVIDIA 共同开发，并集成到 Red Hat AI 中以实现代理安全性和操作化。OpenShell 的代理支持 A2A 协议传输，而 AgentCard 发现功能则在目录和网关层面处理——使代理能够在集群内跨节点发现和委派任务，而无需修改开发者原始代理代码。OpenShell 还通过 SPIFFE 注入生产身份并强制执行工具治理，因此符合 A2A 标准的基础设施作为平台关注点而非开发者负担。如需了解 OpenShell 与 Red Hat AI 如何协作实现安全代理执行，请参阅《Red Hat AI 与 OpenShell：推动企业 AI 的安全增强代理执行》。

目前尚不存在“面向代理的 Hugging Face”——没有一个用于在组织边界内发现和复用代理能力的中心化市场。这些目录和注册表功能正是为了填补这一空白而设计的。

对于决策者而言，发现工具可直接减少重复的工程工作，并为采购和安全团队提供治理层，这是在大规模批准代理部署前所需的必要条件。对于开发者而言，这意味着可以从现有资源出发，而非从零开始构建。

当前可连接的内容

虽然代理注册表仍在规划中，但连接器本身已开始交付。Red Hat 提供了一系列领域专用的 MCP 服务器——即开即用的连接器，团队可直接使用，无需自行构建：

• Red Hat OpenShift MCP 服务器处理集群的 CRUD 操作、Helm 图表管理、KubeVirt、可观测性集成和服务网格查询。
• OVN-Kubernetes MCP 覆盖网络诊断。
• Red Hat Advanced Cluster Security for Kubernetes MCP 提供漏洞扫描和安全态势查询。
• Red Hat Advanced Cluster Management for Kubernetes MCP 服务器支持多集群查询。
• Assisted Installation MCP 提供集群安装指导。
• Lightspeed Advisor MCP 提供 Red Hat Insights 和风险预测。
• Ansible Automation Platform MCP 服务器使代理能够触发 playbook、检查作业状态并协调配置更改。
• Developer Hub MCP 插件暴露 Backstage 操作、软件目录和 TechDocs。

生态系统不仅限于 Red Hat。OpenShift AI 3.4（开发者预览版）中的 MCP 目录提供了一个经过精心策划的多层级目录：Red Hat 服务器与来自 Confluent Cloud、EDB Postgres AI、IBM Terraform、Microsoft Azure 和 Dynatrace 的技术合作伙伴服务器并列，同时还包括 MongoDB 和 MariaDB 的社区服务器。所有服务器均通过 MCP 生命周期操作员部署，通过 MCP 网关连接，并可在生成式 AI 工作室中使用——无论服务器由谁构建，其生命周期管理均遵循相同的治理流程。

这些功能并非理论上的设想。一个构建自主 SRE 代理的团队可以使用 Red Hat OpenShift 的 MCP 服务器，在午餐前即可完成集群操作的集成。安全团队可以连接 Red Hat Advanced Cluster Security 的 MCP 服务器，无需编写任何 API 集成代码即可查询漏洞数据。驱动自主 SRE 代理的同一平台基础设施，同样可以支持 HR 入职助手、采购审批流程或客户服务升级机器人——即使使用场景不同，基础设施本身也与领域无关。

我发现特别有用的一点是，所有这些 MCP 服务器均可通过任何兼容 MCP 的 IDE 访问——如 VS Code、Cursor、GitHub Copilot、Claude Desktop 等。开发者无需离开编辑器即可查询实时集群状态、排查部署问题并获取流水线建议。他们还可以将这些服务器组合、扩展，或作为构建组织专用连接器的模式使用。对于决策者而言，交付领域专用的 MCP 服务器意味着首批代理可在数天内连接到生产系统，而非通常需要数月的定制集成项目。

真正的转变

从单体架构转向微服务的转型耗时数年，产生了分布式系统复杂性，这是无人能完全预见的。代理的等效转型——从单一代理调用单一API到代理网络跨企业系统协调——正在以更快的速度发生，且影响更为重大，因为代理具有自主性。让微服务变得可管理的是围绕其形成的基础设施：服务网格、API网关、容器编排。同样的模式也适用于代理转型。基于开放协议构建的连接性基础设施（MCP和A2A而非专有厂商API）使得代理转型变得可控，同时保持组织对其集成的掌控。

身份层已经就绪。连接层正在逐步完善。但如果代理背后的模型无法在需要时可靠地调用工具，那么这一切都没有意义。

入门指南

准备好通过红帽AI将代理连接到企业工具了吗？

• 在开发者沙箱中免费试用OpenShift AI：在预配置环境中连接代理到MCP服务器
• 体验MCP服务器交互式演示：在OpenShift AI上发现、部署并连接MCP服务器
• 浏览红帽AI文档：OpenShift、网络、安全、多集群等
• 阅读A2A协议规范：代理间协调标准
• 从BYO代理入门套件开始：包含预配置的MCP网关集成
• MCP目录现已上线：在红帽OpenShift AI上发现、部署并连接：精选的红帽、合作伙伴及社区MCP服务器目录，包含生命周期管理

Block | Dynamic pattern deluxe promo

Component | Band_header

Resource

适应性企业：为何AI准备度即变革准备度

这本电子书由红帽首席运营官兼首席安全官Michael Ferris撰写，帮助IT领导者应对当前面临的AI驱动的技术变革速度和颠覆性挑战。

Component | spacer

Component | Cta_multi_basic

Subpattern | simple_cta

Component | CTA

获取资源

Deluxe mbox

Component | Card_header

关于作者

Subpattern | speaker

Card layout

Component | Image_embed

Component | Person

Richard Naszcyniec

Subpattern | social_links

在Sybase、Siebel Systems、Oracle、IBM和红帽（自2012年起）等公司拥有三十多年软件行业经验，我目前担任AI技术架构师和AI未来学家。在红帽任职期间，我曾领导团队通过战略销售策略提升全球销售业绩，此前负责应用服务（中间件）业务单元的技术竞争营销。如今，我的使命是揭开AI架构的神秘面纱，帮助专业人士和组织理解AI如何创造商业价值、推动创新并有效集成到软件解决方案中。我借助丰富的经验，教育和指导AI的战略实施。我的工作重点是解释AI架构的组成部分、其实际应用以及如何转化为切实的商业效益，如获得竞争优势、差异化和通过简单而创新的解决方案取悦客户。我热衷于赋能企业不仅利用AI预见未来技术格局，更能塑造未来。我也致力于推动AI的负责任使用，使每个人都能实现超越以往的成就。

作者的其他文章

Joshua Wilson

类似内容

动态模式

博客文章

物理人工智能：当机器开始在现实世界中思考和行动

模型即服务（MaaS）治理：管理人工智能访问权限和令牌配额

原始播客

技术讲解 | 用开源定义主权人工智能

技术讲解 | 开源人工智能战略解析

子模式 | card_flex

子模式 | text_basic

继续探索

• 什么是智能体AI？文章

• 预测性AI与生成性AI对比 文章

• 构建生产就绪AI/ML环境的关键考量 电子书

• 以Ansible方式实现生成性AI 视频

• 通过现代应用平台实现创新与转型 电子书

继续探索 mbox

子模式 | simple_text

按频道浏览

查看所有频道

模式 | raw_html

自动化

面向技术、团队和环境的IT自动化最新动态

人工智能

让客户能够随时随地运行AI工作负载的平台更新

混合云

探索我们如何通过混合云构建更灵活的未来

安全

跨环境和技术降低风险的最新进展

边缘计算

简化边缘运算的平台最新动态

基础设施

全球领先的企业的Linux平台最新动态

应用程序

应对最复杂应用挑战的解决方案解析

虚拟化

面向本地或跨云工作负载的企业虚拟化未来