在网络拥有 HyperText Transfer Protocol (HTTP) 之前，在电子邮件拥有 Simple Mail Transfer Protocol (SMTP) 之前，我们受困于定制化集成、碎片化系统和脆弱的工作流程。直到开放协议和共享基础设施出现，互联网才真正实现规模化，解锁了现代网络、全球通信和整个经济体系。
如今，AI 代理正处于类似的预标准化阶段。它们功能强大、能力卓越且数量迅速增长，但它们无法协同工作。一个代理分析数据，另一个起草代码，第三个自动化 CRM 工作流程。但它们彼此隔离、各自为政，互不知晓对方的存在。
这种情况正在改变。
一个新的开放栈正在浮现，以支持互联网的下一层，这层不是为人类浏览网站而构建，而是为跨系统协作的自主代理而构建。
我们称之为 KAMF Stack：
•Apache Kafka — 用于可靠、解耦协调的事件驱动通信结构•Anthropic’s Model Context Protocol (MCP) — 用于工具使用和外部上下文的标准•Google’s Agent2Agent (A2A) — 代理发现和通信的协议•Apache Flink — 实时处理引擎，用于丰富、监控和处理代理活动流
KAMF Stack 共同提供了从孤立机器人到动态、智能化代理生态系统的必要基础设施。
如果您喜欢请关注公众号：
问题：碎片化的代理，脆弱的基础设施
如果炒作属实（现在看来更像是必然而非猜测），大多数公司不会只部署一个 AI 代理，而是会部署数十个。这些代理将编写代码、处理支持工单、分析客户数据、管理入职、监控基础设施等等。
但今天的工具尚未为这一未来做好准备。
代理孤岛
我们不仅面临“代理孤岛”问题，即代理各自在孤立环境中运行，无法通信，还面临更广泛的生态系统碎片化问题：
•代理之间不沟通：每个代理运行在自己的沙箱中。CRM 代理不知道数据仓库代理刚发现的内容。支持代理无法响应监控代理刚标记的异常。•工具使用脆弱且定制化：没有调用工具或外部 API 的标准，代理最终依赖硬编码集成和不可重用的逻辑。•框架缺乏一致性：不同的代理运行时使用不同的模型——有些将代理视为聊天机器人，有些视为 DAGs，还有些视为递归规划器。没有可移植的执行层或共享状态。•我们像在笔记本中构建代理：如今的大多数代理被设计成一次性原型——线性、同步且短暂。但真实系统不是笔记本。它们需要处理重试、失败、协调、日志记录和扩展。这需要基础设施。•缺乏协作支柱：没有事件总线，没有共享内存，没有可追溯的代理行为历史记录。一切都被锁定在直接 HTTP 调用中或埋藏在日志里。
正如 12-Factor Agents 项目所论述，代理需要遵循云原生原则：它们必须是可观察的、松耦合的、可重现的和基础设施感知的。但今天，大多数代理被构建为脆弱的脚本，手工拼接，假设在隔离环境中运行。
结果呢？孤岛。重复。脆弱。
解决方案不是将所有代理塞进一个单一平台，而是构建一个共享栈，一个基于开放协议、事件驱动架构和实时处理的新基础。
Agent2Agent 通过为代理提供发现和通信的通用协议，部分解决了这个问题。但要超越玩具演示，达到生产系统所需的规模和可靠性，我们需要的不仅是协议，还需要基础设施。
代理如何沟通和行动：A2A 和 MCP 的作用
如前所述，今天的代理生态系统很像早期的网络：功能强大的系统各自完成有用的工作，但彼此隔离且不兼容。就像浏览器曾经难以在没有标准协议的情况下与服务器通信一样，今天的 AI 代理无法轻松发现、通信或协作。
Google’s A2A 协议是大胆的尝试，旨在解决这一问题。它不是另一个代理框架，而是一个通用的协议，旨在连接任何代理，无论由谁构建或在何处运行。
就像 HTTP 标准化了网站通信方式一样，A2A 为代理定义了共享语言，使它们能够：
•通过 AgentCard（一个 JSON 描述符，声明代理的功能和交互方式）宣布能力。•通过结构化交互（使用 JSON-RPC）发送和接收任务，一个代理请求帮助，另一个以结果或“Artifacts”响应。•通过 Server-Sent Events (SSE) 流式传输更新，支持长时间运行或协作任务的实时反馈。•交换丰富内容，不仅限于纯文本，文件、结构化数据和表单都是 A2A 消息的首要部分。•默认保持安全，凭借内置对 HTTPS、身份验证和权限的支持。
A2A 的前景在于它没有试图重新发明轮子。它建立在数十年的互联网协议历史之上，就像 HTTP 和 SMTP 一样，利用熟悉的、经过实战检验的网络标准。这使得采用更容易，集成更快。
但 A2A 只是问题的一半。
Anthropic’s MCP 解决了另一半：代理如何使用工具和访问上下文。MCP 标准化了代理调用 API、调用函数和与外部系统集成的过程，实质上是它们如何在世界中思考和行动。另一方面，A2A 定义了代理如何相互沟通。
如果说 MCP 是为代理提供工具访问的能力，那么 A2A 则是为它们提供彼此访问的能力。
这两个协议共同为连接的代理生态系统提供了一个蓝图：
•MCP 赋予单个代理智能。•A2A 实现集体智能。
就像 HTTP 和 SMTP 并非孤立成功一样，它们需要采用、基础设施和开发者工具。A2A 和 MCP 也需要一个生态系统来实现其潜力。
但即使有了 A2A 和 MCP 这样的标准化，一个根本问题依然存在：这些代理通信如何在复杂、动态的企业环境中有效扩展？仅依赖这些协议定义的直接点对点连接会带来一系列挑战，特别是在可扩展性、弹性和可观察性方面。这让我们需要考虑一个强大的底层通信基础设施。
为什么协议不够：事件驱动支柱的需要
想象一下，运营一家公司，每个员工只能通过一对一的直接消息进行沟通。需要分享更新？必须逐一发送消息给每个人。想协调五个团队的项目？你得手动在每个团队间传递信息。
现在想象将这种方式扩展到数百名员工。混乱不堪。
这正是基于直接连接的代理生态系统所发生的情况。每个代理必须知道与谁沟通、如何联系以及对方何时可用。随着代理数量增加，所需连接数量呈指数级增长。系统变得脆弱、难以管理，几乎无法扩展。
A2A 和 MCP 为代理提供了沟通和行动的语言和结构——但仅语言是不够的。要在企业中协调数十或数百个代理，你还需要基础设施来管理这些消息的流动以及代理对它们的反应。
这就是 Apache Kafka 和 Apache Flink 的用武之地。
Kafka 和 Flink 简介
Apache Kafka 是一个分布式事件流平台，最初由 LinkedIn 开发，现为 Apache Software Foundation 的一部分。它作为一个持久的、高吞吐量消息总线，允许系统实时发布和订阅事件流。Kafka 被广泛应用于金融系统、欺诈检测、遥测管道等领域，因为它解耦了生产者和消费者，并确保数据持久、可重放和可扩展。
Apache Flink 也是 Apache 项目，是一个实时流处理引擎。它从一开始就为有状态、高吞吐量、低延迟的事件处理设计。Kafka 负责数据移动，Flink 负责数据在系统流动时的转换、丰富、监控和编排。
它们一起形成强大的组合：Kafka 是血流，Flink 是反射系统。
Kafka 和 Flink：代理生态系统的基础设施
正如 A2A 成为代理世界的 HTTP，Kafka 和 Flink 构成了支持可扩展代理通信和计算的事件驱动基础。它们解决了直接点对点通信无法解决的问题：
•解耦：通过 Kafka，代理无需知道谁将消费它们的输出。它们将事件（例如“TaskCompleted”、“InsightGenerated”）发布到主题，任何感兴趣的代理或系统都可以订阅。•可观察性和可重放性：Kafka 维护每个事件的持久、时间有序日志，使代理行为完全可追溯、可审计和可重放。•实时决策：Flink 使代理能够实时响应事件流，基于动态条件进行过滤、丰富、连接或触发操作。•弹性和扩展：Flink 作业可以独立扩展，从失败中恢复，并在长时间运行的工作流中保持状态。这对于执行复杂、多步骤任务的代理至关重要。•流原生协调：代理无需等待同步响应，可以通过事件流协调，发布更新、订阅工作流并协作推进状态。
简而言之：
•A2A 定义代理如何沟通。•MCP 定义它们如何操作外部工具。•Kafka 定义消息如何流动。•Flink 定义这些流动如何被处理、转换并转化为决策。
A2A、MCP、Kafka 和 Flink 如何协同工作
像 A2A 和 MCP 这样的协议对于标准化代理行为和通信至关重要。但没有像 Kafka 这样的事件驱动基底和像 Flink 这样的流原生运行时，这些代理仍将局限于孤立交互，无法灵活协调、优雅扩展或随时间推理。
要完全实现企业级、可互操作 AI 代理的愿景，我们需要四层：
•协议 — A2A、MCP — 定义“是什么”•框架 — LangGraph、CrewAI、ADK — 定义“如何做”•消息基础设施 — Apache Kafka — 支持流动•实时计算 — Apache Flink — 支持思考
这些共同构成了 AI Agent的新互联网栈，一个不仅智能，而且协作、可观察且生产就绪的系统基础。
前路：为集体智能而建
我们正处于软件演变的关键时刻。
正如原始互联网栈、HTTP 和 SMTP 等协议以及 TCP/IP 等基础设施开启了全球连接的新时代，一个新的 AI 代理栈正在浮现。但这个栈不是为人类导航页面或发送电子邮件而构建，而是为自主系统协作推理、决策和行动而构建。
A2A 和 MCP 提供了代理通信和工具使用的协议。Kafka 和 Flink 提供了实时协调、可观察性和弹性的基础设施。它们共同使我们从孤立的代理演示转向可扩展、智能、生产级的生态系统成为可能。
这不仅是解决工程挑战，而是启用一种新型软件，代理跨越边界协作，洞察和行动实时流动，智能成为分布式系统。
但这一愿景不会自己实现。我们需要以开放、互操作的方式构建它，并铭记上一次互联网革命的经验教训。
所以，下次你构建代理时，不要只问它能做什么。问它如何融入更大系统。它能沟通吗？能协调吗？能进化吗？
因为未来不仅是代理驱动的。
而是Agent互联的。
如果对您有帮助请点赞、转发、关注。
（文：PyTorch研习社）