A2A，MCP，Kafka和Flink：AI代理商的新堆栈

在Web具有超文本传输​​协议（HTTP）之前，并且在电子邮件具有简单的邮件传输协议（SMTP）之前，我们被自定义集成，零散的系统和脆弱的工作流程所困扰。直到开放协议并共享基础设施才出现直到互联网真正扩展，释放了现代网络，全球沟通和整个经济体。

今天，人工智能代理处于同一标准化阶段。他们具有强大的，有能力和速度的速度，但他们没有共同努力。一个代理分析数据。另一个草稿代码。第三个自动化客户关系管理（CRM）工作流程。但是他们彼此孤立，孤立和不知道彼此的存在。

那开始改变。

一个新的堆栈正在兴起，以支持下一层的互联网 - 不是为人类浏览网站而是为跨系统协作的自主代理而构建的。核心是四个开放组件：

• Google的Agent2Agent（A2A）：供代理商发现和交流的协议。
• 人类模型上下文协议（MCP）：工具使用和外部上下文的标准。
• Apache Kafka：以事件为导向的通信结构，可用于可靠，脱钩的协调。
• apache flink：一种实时处理引擎，以丰富，监视和行动在代理活动流。

让我们探索这些技术如何融合在一起，为什么单独的协议足够多，以及这个新堆栈如何提供从断开的机器人转变为动态的，智能的代理生态系统所需的基础架构。

问题：碎片代理，脆弱的基础设施

如果炒作是正确的，并且看起来更像是不可避免的，那么大多数公司就不会部署一个AI代理；他们将部署数十个。这些代理商将编写代码，分流支持门票，分析客户数据，管理入职，监视基础架构等等。

但是，今天的工具还没有为未来做好准备。

我们不仅面对特工岛问题，代理商在孤岛中运行的地方可以交流；我们面临着更广泛的生态系统破碎问题：

• 代理商不互相交谈：每个代理都以自己的沙箱运行。CRM经纪人不知道数据仓库代理刚刚发现的内容。支持代理可以响应与监测代理刚刚标记的相同异常。
• 工具使用脆弱和定制：如果没有调用工具或外部API的标准，代理最终会获得硬编码的集成和不可恢复的逻辑。
• 框架缺乏一致性：不同的代理运行时间使用不同的模型 - 有些治疗代理（例如聊天机器人），其他类似定向的无环图（DAG），其他类似于递归计划者。没有便携式执行层或共享状态。
• 我们构建好像代理商生活在笔记本上：当今的大多数代理商的设计类似于一次性原型 - 线性，同步和短暂的。但是真实的系统却是笔记本。他们需要处理重试，失败，协调，记录和缩放。这需要基础架构。
• 没有骨干进行合作：没有事件巴士，没有共享记忆，没有代理商所做的事情或原因的可追溯历史。一切都锁定在直接的HTTP调用中或埋在日志中。

作为12因子代理项目认为，代理需要遵循云原则：必须可观察，松散耦合，可重现和基础设施感知。但是今天，大多数人都是作为脆性脚本构建的，用手缝合在一起，并假定孤立地运行。

结果？筒仓。复制。脆弱性。

解决方案并非将所有代理都推入一个整体平台。建立共享堆栈，这是一个基于开放协议，事件驱动的体系结构和实时处理的新基础。

Agent2Agent通过为代理提供了发现和通信的常见协议来解决问题的一部分。但是，要超越玩具演示，要达到规模和可靠性生产系统需求，我们需要的不仅仅是协议。我们需要基础架构。

代理商如何交谈和行为：A2A和MCP

如前所述，当今的代理生态系统看起来很像早期的网络：功能强大的系统，每个系统都在做有用的工作，但孤立且不兼容。就像浏览器曾经在没有标准协议的情况下与服务器进行交谈一样，如今的AI代理很容易发现，交流或协作。

Google的A2A协议是为解决这个问题的大胆尝试。这不是另一个代理框架：这是一个通用协议，旨在连接任何经纪人，无论是谁建造它或运行的地方。

就像HTTP标准化网站如何通信一样，A2A也为代理商定义了共享语言。它让他们：

• 宣布功能通过代理卡，宣布代理可以做什么以及如何与之互动的JSON描述符。
• 发送和接收任务通过结构化的互动（使用JSON-RPC），一个代理要求帮助，另一个代理人对结果或伪像做出反应。”
• 带有服务器范围事件（SSE）的流动更新，在长期或协作任务中启用实时反馈。
• 交换丰富的内容。文件，结构化数据和表格不仅是纯文本 - 都是A2A消息的一流部分。
• 默认保持安全得益于对HTTP，身份验证和权限的内置支持。

A2A有希望的是，它没有试图重塑车轮。它基于数十年的互联网协议历史记录，就像HTTP和SMTP一样，通过利用熟悉的，经过战斗测试的网络标准。这使得采用更加容易，更快地集成。

但是A2A只是图片的一半。

拟人化的MCP解决了另一半：代理如何使用工具和访问环境。MCP标准化了代理如何调用API，调用功能并与外部系统集成，从本质上讲，他们在世界上的思维和行动方式。另一方面，A2A定义了代理商如何相互交谈。

如果MCP是关于让代理使用工具的访问，则A2A是要使他们彼此访问。

这两个协议一起为连接的代理生态系统提供了蓝图：

• MCP为个人代理智能提供动力。
• A2A启用集体智能。

就像HTTP和SMTP在孤立方面没有成功一样，他们需要采用，基础架构和开发人员工具，A2A和MCP将需要一个生态系统来实现其潜力。

但是，即使有像A2A和MCP这样的标准化，仍然存在一个基本问题：这些代理通信如何在复杂的，动态的企业环境中有效地扩展？仅依靠这些协议定义的直接点对点连接会产生自己的挑战集，尤其是围绕可扩展性，弹性和可观察性。这使我们需要建立强大的基础沟通基础架构。

我们需要一个事件驱动的骨干，而不仅仅是协议

想象一下，经营一家公司，每个员工只能通过发送直接的一对一消息来通信。需要分享更新吗？您必须单独向每个人发送消息。想在五个团队中协调一个项目吗？您可以在每个组之间手动中继信息。

现在想象一下试图将其扩展到数百名员工。混乱。

这正是基于直接连接的代理生态系统发生的事情。每个代理商都必须知道与谁交谈，如何联系他们以及何时可用。随着代理数量的增长，所需连接的数量呈指数增长。该系统变得脆弱，难以管理并且几乎不可能扩展。

A2A和MCP为代理商提供了交流和行动的语言和结构，但仅语言就不够。要协调跨企业的数十个代理商，您还需要基础架构来实现这些消息的移动方式以及代理对它们的反应。

那是哪里Apache Kafka和Apache Flink进来。

kafka and Flink：快速底漆

Apache Kafka是最初在LinkedIn开发的分布式事件流平台，现在是Apache Software Foundation的一部分。它充当耐用的高通量消息总线，允许系统实时发布和订阅事件流。Kafka无处不在，从金融系统到欺诈检测再到遥测管道，因为它使生产商与消费者和确保数据耐用，可重播且可扩展。

弗林克，也是一个Apache项目，是一种实时流处理引擎。它是从头开始设计的，以进行状态，高通量，低延迟的事件处理。卡夫卡（Kafka）处理数据的移动，flink可以处理数据流过系统时的转换，丰富，监视和编排。

他们在一起形成了一个强大的二人组：卡夫卡是血液，弗林克是反射系统。

Kafka和Flink：代理生态系统的基础设施

就像A2A成为代理世界的HTTP一样，Kafka和Flink形成了事件驱动的基础，可以支持可扩展的代理通信和计算。他们解决了直接，点对点交流的问题：

• 脱钩：与卡夫卡（Kafka）一起，特工不需要知道谁会消耗其产出。他们发布活动（例如，“任务完成”，，，，“洞察力”）主题；任何感兴趣的代理商或系统都可以订阅。
• 可观察性和可重复性：KAFKA保持每个事件的耐用，订购的日志，使代理行为完全可以追溯，可审核和可重播。
• 实时决策：Flink使代理商能够实时对流进行反应根据动态条件进行过滤，丰富，加入或触发操作的事件。
• 弹性和缩放：Flink Jobs可以独立扩展，从失败中恢复并在长期运行的工作流程中保持状态。这对于执行复杂的多步任务的代理商至关重要。
• 流媒体协调：代替等待同步响应，代理可以通过事件流，发布更新，订阅工作流程和协作状态进行协调。

简而言之：

• A2A定义了代理商的讲话。
• MCP定义了它们如何对外部工具的作用。
• Kafka定义了他们的信息如何流动。
• Flink定义了如何处理，转换并将这些流动变成决策。

A2A，MCP，Kafka和Flink如何一起工作

诸如A2A和MCP之类的协议对于标准化代理行为和通信至关重要。但是，如果没有事件驱动的底物，例如Kafka和Flink等流媒体运行时，这些代理仍然陷入了孤立的交互作用，无法灵活地，优雅地缩放或随着时间的推移进行推理。

为了充分实现企业级，可互操作的AI代理的愿景，我们需要四层：

• 协议：A2A，MCP定义什么。
• 框架：Langgraph，Crewai，ADK定义如何。
• 消息基础架构：Apache Kafka支持流动。
• 实时计算：Apache Flink支持思维。

这是AI代理商的新互联网堆栈 - 建筑系统的基础不仅是聪明的，而且还可以合作，可观察到生产。

前面的道路：集体情报的建筑

我们处于软件发展的关键时刻。

就像HTTP和SMTP这样的原始Internet堆栈协议以及TCP/IP之类的基础架构解锁了全球连接的新时代一样，AI代理正在出现新的堆栈。但是，该堆栈不是人类浏览页面或发送电子邮件的，而是为共同努力，决定和采取行动的自动群体而构建的。

A2A和MCP提供了用于代理通信和工具使用的协议。Kafka和Flink为实时协调，可观察性和弹性提供了基础设施。它们共同使他们可以从断开的代理演示转变为可扩展的智能生产级生态系统。

这只是解决工程挑战。它是为了启用一种新型软件，代理在跨边界进行协作，实时提供洞察力和动作流，从而使情报成为分布式系统。

但是这个愿景不会意识到自己。我们需要构建它：公开，互操作，并考虑到上一次互联网革命的教训。

因此，下次您建立代理商时，不要问它可以做什么。询问它如何适合较大的系统。可以交流吗？可以协调吗？可以进化吗？

因为未来不仅仅是代理的驱动；它与代理相关。