> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 智能体AI平台大融合已经开始 - URL: https://www.hubwiz.com/blog/the-great-convergence-of-agentic-ai-platforms-has-begun/ - Published: 2026-06-06T02:30:53.000Z - Updated: 2026-10-13T15:16:24.000Z - Description: 每个企业级智能体AI平台都在向同一架构收敛。五层架构图、平台决策框架，以及这对架构师意味着什么。 - Author: admin - Tags: INDUSTRY, #Import 2026-10-14 14:41 1999年，每个主要企业软件公司都在构建自己的系统间通信方式。SAP有自己的方法。Oracle有自己的方法。IBM有自己的方法。企业应用之间的集成层是定制的、脆弱的、昂贵的——每对需要通信的系统都是不同的问题。 然后Web服务来了。REST、SOAP、WSDL——共享协议、类型化契约、标准化接口。五年之内，集成问题从"如何将系统A连接到系统B"变成了"两个系统支持相同的协议，所以把它们插在一起"。难题变成了已解决的问题。 现在，在智能体AI领域正在发生几乎相同的事情，而且速度快得多。 2026年2月，一篇经过同行评审的研究论文分析了五个最广泛部署的企业级智能体平台——Kore.ai、Salesforce Agentforce、TrueFoundry、ZenML和LangChain，发现了一个应该改变每个架构师、工程师和业务领导者思考其AI基础设施决策方式的现象。 所有五个平台，由不同公司为不同市场构建，正在向同一架构收敛：标准化的智能体循环、类型化工具接口、智能体注册表和可审计的控制机制。 **论文的预测**：智能体AI开发的后续阶段将类似于Web服务的成熟过程，依赖共享协议、类型化契约和分层治理结构来支持可扩展和可组合的自主性。 这是2026年企业AI领域最具影响力的架构洞察。大多数组织在不理解这一点的情况下做出平台决策。 **本文是一份指南。** ## 1、为什么融合正在此刻发生？ 在了解什么在收敛之前，先理解为什么在特定时刻发生收敛是有帮助的。 2024年和2025年初部署AI智能体的每个企业都以相同的方式构建：一个连接一两个工具的聊天机器人，以单线程运行，没有可观测性、没有治理、无法扩展。它适用于演示。它在生产用例中失败了。 一旦你看到了这些失败，它们就是可预测的。产生幻觉的智能体没有被捕获。超出授权范围的智能体没有人知道。成本超出预算十倍的智能体没有人追踪。在测试中行为正确但在生产中表现不一致的智能体——这种不一致只有在客户投诉时才被发现。 这些不是模型问题。它们是基础设施问题。每个主要平台——无论它最初是CRM、工作流引擎、超大规模云服务商还是开发者框架——都被迫解决同一组基础设施问题以使智能体生产就绪。这种共同压力就是架构正在收敛的原因。 2026年3月，Gartner正式化了实践中已经出现的东西。智能体管理平台——AMP——是智能体执行层之上的运营控制平面。它通过标准协议连接智能体，从异构环境中摄取遥测数据，在执行时强制执行治理策略，运行生产前评估套件，并将token成本归因到业务单元和工作流。 六个能力。每个想称自己为企业就绪的平台都在构建全部六个。名称不同。底层架构相同。 ## 2、每个人都在构建的五个要素 把这些看作每个成熟的智能体平台都包含的层次——不管谁构建的，也不管它面向什么市场。 ### 2.1 智能体循环 智能体AI的基本单元不是工具调用。它是循环：计划要做什么，执行计划，验证结果，更新计划，重复。 行业已经收敛于此的一个变体——有时称为Plan-Execute-Verify，有时称为ReAct（Reason-Act），有时称为智能体循环——但形状到处都一样。认知层对任务进行推理。执行层调用工具。验证层检查结果是否满足意图。循环持续到任务完成或需要人工介入。 融合研究发现：通过类型化工具接口将认知推理层与执行层分离，是使智能体在大规模上可靠的架构决策。 当推理层和执行层紧密耦合时——当智能体在同一个步骤中决定做什么并执行时——故障难以捕获、难以重放、难以审计。当它们通过类型化接口分离时，每个工具调用都被记录，每个决策点都可观察，故障可以在不调试整个智能体的情况下被隔离。 这是MVC中将控制器与模型分离的智能体等价物。听起来像架构上的讲究。在生产中，它是你能治理和不能治理的系统之间的区别。 ### 2.2 智能体注册表 智能体注册表是一个目录——环境中每个智能体的结构化清单：每个智能体能做什么，它可以访问什么工具，它被授权在什么范围内操作，它的性能历史如何，以及哪个人或团队拥有它。 智能体管理平台通过非人类智能体的身份和访问管理提供安全性：权限范围划定、凭证管理和可审计的访问撤销。 在注册表存在之前，企业智能体部署看起来像影子IT：由个别团队构建的智能体，在生产中运行，没有中央可见性、问责制或访问控制。注册表使智能体成为一等基础设施——就像服务网格使微服务可见和可治理一样。 这对业务领导者很重要，原因很具体。当一个智能体采取了导致问题的行动——发送了不应该发送的邮件、访问了未被授权访问的数据源、生成了造成法律风险的输出——第一个问题总是"哪个智能体做了这件事？"没有注册表，回答这个问题是一个调查。有了注册表，它是一个查询。 ### 2.3 类型化工具接口 融合中的每个平台都采用了同一模式的某个版本：工具由一个类型化契约描述，指定工具做什么，接受什么输入，返回什么输出，以及它永远不应该做什么。 MCP协议（由Anthropic创建，现属Linux基金会）在协议级别标准化了这一点。A2A（由Google创建，也属Linux基金会）标准化了智能体之间的通信方式。它们共同提供了arXiv论文预测将支撑智能体AI下一阶段的类型化契约。 **实际意义**：构建在LangGraph上的智能体和构建在AWS Bedrock AgentCore上的智能体现在可以通过相同的协议调用相同的工具。为Salesforce Agentforce构建的智能体可以通过相同的协议将任务委托给构建在Microsoft Copilot Studio上的智能体。曾经是定制化的集成问题正在标准化。 还没有完全实现。还没有到处实现。但方向是明确的，速度很快。 ### 2.4 可观测性层 LangChain强调traces作为一等可观测性制品——以网关为中心的部署模型专注于策略驱动的流量控制，以及以管道为中心的工具瞄准可复现性和可审计性。 在融合前的世界，智能体可观测性意味着日志记录。日志告诉你发生了什么。它们不告诉你为什么发生，是否应该发生，或者导致输出的推理序列是什么。 融合平台正在向推理追踪构建——智能体决策过程中每一步的结构化记录。不仅仅是它调用了什么，还有为什么调用它，它有什么上下文，以及在行动之前考虑了什么。推理追踪对智能体的意义就像分布式追踪对微服务的意义：它使不可见的变为可见。 > 对工程师来说，这把调试从猜测变成了诊断。对架构师来说，这把治理从策略变成了执行。对业务领导者来说，这把问责从模糊变成了明确。 ### 2.5 治理层 在融合前的世界中，治理意味着对模型API的访问控制。在融合架构中，治理是运行时策略执行——规则不是在访问时应用，而是在执行时应用，对智能体采取的每个行动。 **实际上是什么样的**？一条策略说"这个智能体可以发送邮件，但未经人工批准永远不能发给外部收件人。"一条策略说"这个智能体可以查询客户数据库，但只能查询请求用户自己的账户。"一条策略说"任何金融价值超过500美元的智能体行动在执行前需要人工介入。"这些策略运行在执行层，对照类型化工具接口进行检查，记录在可观测性层中，并可在注册表中审查。 **这是真正有效的治理**——不是假设智能体会遵守指令的治理，而是无论智能体决定什么都会强制执行约束的治理。 ## 3、四个平台类别 2026年的格局包括Microsoft Copilot Studio和Salesforce Agentforce等生产力和CRM平台、ServiceNow和UiPath等工作流平台、Google Gemini Enterprise和Amazon Bedrock AgentCore等超大规模云平台、IBM watsonx Orchestrate等企业套件、LangGraph和OpenAI Agents SDK等开发者框架，以及VDF AI等主权关注平台。 以下是每个类别如何映射到五个要素——以及这对你的平台决策意味着什么。 ### 3.1 CRM和生产力平台 **Salesforce Agentforce。Microsoft Copilot Studio。** **两者都从相同的前提出发**：如果你的数据和工作流已经在我们的平台上，就在这里构建你的智能体。Agentforce智能体生活在Salesforce信任层内，直接访问CRM数据和客户工作流。Copilot Studio智能体与Microsoft 365栈集成——Teams、SharePoint、Dynamics——底层是Azure的身份和合规基础设施。 **五个要素都存在，但围绕特定生态系统构建。** 可观测性层汇入Salesforce的原生分析或Microsoft的Azure Monitor。治理层执行Salesforce或Azure策略。注册表是平台内部的。 **何时选择此类别**：你的主要业务数据在Salesforce或Microsoft栈中。你的智能体主要在面向客户或生产力工作流中工作。选择与你现有栈相悖的方案会产生集成债务，侵蚀ROI。 **何时不选**：你的工作流跨越多个非Salesforce或Microsoft原生的系统。你需要能够跨不同供应商操作或与构建在其他平台上的智能体通信的智能体。 ### 3.2 工作流和运营平台 **ServiceNow。UiPath。** 两者都从工作流自动化平台起步，在现有的工作流图之上构建了智能体能力。ServiceNow的优势在于IT服务管理、运营、安全和员工服务已经在其上运行——治理IT运营的智能体原生访问整个事件、变更和请求生命周期。 UiPath的优势在于其现有的机器人流程自动化集成——结合LLM推理和RPA执行的智能体可以自动化同时涉及结构化软件和非结构化内容的工作流。 **何时选择此类别**：你的用例偏重运营——IT自动化、流程自动化、后台工作流。你需要通过API调用和UI自动化的混合与遗留系统交互的智能体。 ### 3.3 超大规模云平台 **AWS Bedrock AgentCore。Google Gemini Enterprise Agent Platform。Azure AI Foundry。** 超大规模云的方法：如果你的基础设施在我们的云上运行，就在我们的托管服务中构建智能体。Bedrock AgentCore给你在AWS安全边界内运行的智能体，使用IAM进行智能体身份管理，使用CloudWatch进行追踪，并直接访问完整的AWS服务目录。 Gemini Enterprise给你连接到Google Workspace的智能体，底层是Vertex AI，预置了Google的合规认证。Azure AI Foundry与Azure身份层集成，给你继承现有Azure安全态势的智能体。 当最流行的独立AI智能体构建框架吸收了你的工具包时，你就超越了供应商的类别，进入了基础设施的类别。这个观察——关于Nvidia吸收LangChain的——同样适用于超大规模云。 当你的AI智能体在与你其余基础设施相同的安全边界、合规框架和身份系统中运行时，治理就变成了结构性的而非附加的。 **何时选择此类别**：你的主要基础设施运行在一个云上，你有强烈的数据驻留、合规或安全要求。你希望智能体继承你现有的云治理态势。 ### 3.4 开发者框架 **LangGraph。OpenAI Agents SDK。CrewAI。** 框架给你最大的架构灵活性，代价是最大的工程责任。LangGraph将智能体工作流表达为有向图——节点是状态，边是转换，图结构本身就是治理机制。 你可以构建任何拓扑，实现任何控制流，集成任何模型或工具。将智能体AI视为核心竞争优势并有工程团队支持的组织会刻意选择LangChain而非供应商平台。 五个要素都存在，但由你构建。可观测性意味着集成LangSmith或其他追踪解决方案。治理意味着将策略执行构建到你的工具定义中。注册表意味着维护你自己的已部署智能体目录。这是基础设施工作，不是产品工作。 **何时选择此类别**：你有一个强大的AI工程团队。你的用例足够差异化，没有供应商平台能覆盖。你将智能体作为产品构建，而不是为运营部署智能体。 ## 4、决策框架：哪个平台适合哪个组织 平台选择中最重要的原则也是最常被忽视的：从你现有的基础设施出发，而不是从智能体平台的营销材料出发。 如果你的组织运行Salesforce，Agentforce在集成速度和数据访问上获胜。如果你是Microsoft标准化的，Copilot Studio消除了中间件的复杂性。如果你的主要工作负载在AWS上，Bedrock提供最安全和合规的基础。 选择与你现有栈相悖所产生的集成债务在选择时不可见，在部署时令人痛苦。一个需要与你的Salesforce数据、你的AWS基础设施和你的ServiceNow工作流通信的智能体——如果运行在一个不原生支持其中任何一个的平台上——将把大部分开发预算花在集成上，而不是智能体逻辑上。 ![None](https://www.hubwiz.com/blog/content/images/2026/06/1-mtWKnxWDE3iOisihPJAWPw-1.png) 最后一行值得解释。Kore.ai于2026年3月推出了专用智能体管理平台，明确支持跨框架——LangGraph、CrewAI、AutoGen、Google ADK、AWS AgentCore、Microsoft Foundry和Salesforce Agentforce，并配备生产前评估工作室、统一可观测性和跨所有框架的持续治理。 对于跨多个栈运行智能体的受监管企业——使用Salesforce做CRM、AWS做基础设施、ServiceNow做运营的金融服务公司——跨框架AMP提供了单个平台无法提供的治理层。你在任何对用例有意义的平台上构建智能体。AMP从单一控制平面治理所有智能体。 ## 5、参考架构 以下是融合正在产生的架构——每个严肃的智能体部署要么在构建要么在购买的架构。 ![None](https://www.hubwiz.com/blog/content/images/2026/06/1-n47Qk8PvLqsgixKgs0jkxQ-1.png) 每一层向上连接到治理层，向下连接到执行层。可观测性层捕获一切。治理层对一切强制执行策略。工具层是智能体改变世界的唯一途径——每一次变更都经过类型化的、有记录的、策略检查的接口。 这个架构是将生产级智能体系统与演示区分开来的东西。不是模型。不是提示。是模型周围的基础设施。 ## 6、多智能体拓扑问题 arXiv论文将此确定为组织目前在犯的最具影响力的架构决策：多智能体拓扑的选择。 ### 6.1 三种主要拓扑，各有不同的失败模式： **主管-工作者。** 一个中央编排智能体分解任务并委派给专家智能体。清晰、可审计、易于治理。失败模式：主管成为瓶颈。当编排智能体做了不好的分解时，每个下游智能体都在错误的任务上工作——错误会复合。 **点对点。** 智能体直接相互通信，通过智能体注册表发现彼此，通过A2A协议委派任务。灵活、并行，适用于复杂的多步骤工作流。失败模式：上下文不一致。智能体A和智能体B可能对任务当前状态有矛盾的信念，没有协调机制的话，它们的输出会冲突。 **层级式。** 上下文和权威通过树结构向下流动。父智能体拥有整体任务和范围；子智能体在该范围内执行子任务。适用于具有明确组织边界的大型复杂部署。失败模式：刚性。当任务不适合层级结构时，升级路径变得昂贵和缓慢。 对架构师来说最重要的研究发现：上下文不一致，而非模式选择，是多智能体编排在生产中失败的主要原因。如果上下文管理正确，每种拓扑都能工作。如果上下文管理不正确，每种拓扑都会失败。选择正确的拓扑不如构建防止不一致的上下文管理层重要。 ### 6.2 这对架构师和工程师意味着什么？ **对于本季度选择平台的架构师：** 不要孤立地评估平台。要根据你现有的技术栈、团队组成、治理需求和时间线来评估。一个架构优雅但需要六个月的集成工作才能连接到你主要数据源的平台不是正确的平台。 融合意味着平台锁定不如以前那么持久。随着类型化工具接口通过MCP和A2A标准化，将智能体从一个平台的执行层迁移到另一个的成本正在降低。尚未标准化——真正具有粘性的——是治理层。仔细构建你的治理层，因为那将是你使用时间最长的。 **在这些平台上构建的工程师：** 融合尚未完成。类型化工具接口在已采用MCP或A2A的平台上可以可靠地跨平台工作。许多企业系统尚未采用任何一个。你仍然会遇到需要定制连接器的集成工作。融合减少了这种工作；但没有消除它。 可观测性层是目前任何智能体系统杠杆最高的投资。追踪生成成本低，但改造成本高。从第一天起就构建它。记录每个智能体行动，归因每个成本，记录每个决策。当出现问题时你会用到这些追踪——而问题一定会出现。 **对于做出投资决策的业务领导者：** 问题不是"哪个平台最好。"而是"哪个平台最适合我们特定的上下文、团队、现有基础设施和监管环境。"一个常见模式是使用云提供商的平台如Bedrock或Vertex进行基础设施级别的智能体服务，同时使用LangGraph或CrewAI进行自定义智能体开发，使用Kore.ai等平台进行面向客户的治理。 你不需要选择一个平台。大多数成熟的智能体部署使用两到三个。治理层位于它们之上。协议连接它们。决策是哪种组合适合你的组织——而不是哪个单一平台赢得了该类别。 ### 6.3 什么仍然未解决？ 融合是真实的。但它没有完成。三个问题仍然很难。 **跨供应商智能体身份。** 智能体的身份——它是谁，被授权做什么，做过什么——目前被隔离在每个平台的注册表内。当Agentforce中构建的智能体将任务委派给Bedrock中构建的智能体时，身份和授权模型不能干净地跨边界传递。A2A的智能体卡片规范正在解决这个问题，但还没有解决。 **跨拓扑的上下文传播。** 在一个需要在不同框架上构建的智能体共享状态的多智能体系统中，上下文模型因框架而异。LangGraph将上下文管理为图状态。Bedrock AgentCore以不同方式管理它。当两个框架的智能体协作一个任务时，上下文同步需要协议尚未完全标准化的显式工程工作。 **智能体规模的治理。** 大多数企业治理框架是为拥有几十个智能体的系统设计的。随着组织跨多个平台和用例部署数百或数千个智能体，治理模型需要以当前工具不完全支持的方式进行扩展。注册表有帮助。策略执行层有帮助。但一千个智能体企业的审计、报告和监督模型还没有被很好地理解。 这些是行业正在解决的问题。它们不是延迟的理由。它们是审慎构建的理由——使用类型化接口、全面的可观测性和可以随标准成熟而扩展的治理基础设施。 ## 7、重要的类比 开头的Web服务类比值得回顾。 1999年，理解Web服务方向的工程师构建了具有干净接口、标准协议和关注点分离的系统。他们在前期比构建定制集成的工程师花的时间多一点。五年后，他们的系统是可组合和可维护的。定制系统运营成本高昂且无法扩展。 同样的选择现在在智能体AI中可用。构建具有类型化接口、全面追踪、基于注册表的治理和协议兼容的工具契约的智能体的工程师在前端多花了一点时间。构建具有硬编码工具调用、没有可观测性和没有治理的智能体的工程师现在更快。 问题不是哪种方法更快。而是三年后你想运营哪种方法。 融合告诉你答案。行业已经在架构上达成一致。平台已经在五个要素上收敛。协议是开放和稳定的。基础设施已经可用。 现在就向它构建，或者以后再改造。 --- 原文链接：[The Great Agentic AI Platform Convergence Has Started](https://medium.com/predict/the-great-agentic-ai-platform-convergence-has-started-4af4bf2431c7?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处 > **这是「Agent / MCP」专题的一部分。**完整地图见：[Agent / MCP / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/)