AI Agent的新兴架构：A2A、MCP、Kafka和Flink
数字化格局正在超越以人为中心的网络浏览，朝着自主代理在不同系统之间无缝协作的领域演进。 这种转变需要一种新的基础设施，一个引人注目的解决方案正在形成，它由四个关键的开源组件组成。
- Google 的 Agent2Agent (A2A)：一种旨在促进代理发现和交互的协议。
- Anthropic 的模型上下文协议 (MCP)：一种定义代理如何利用工具和外部上下文数据的标准。
- Apache Kafka：一个强大的、事件驱动的通信骨干，能够实现可靠的和解耦的协调。
- Apache Flink：一个实时的处理引擎，对于丰富、监控和处理代理活动的流至关重要。
本文探讨了这些技术之间的协同关系，强调了仅仅依赖协议的局限性，并展示了这种架构如何为从孤立的机器人到动态的、智能的代理生态系统的过渡奠定基础。
预计 AI 代理将在组织内部激增，这表明大多数公司将部署多个专门的代理，而不是单个包罗万象的代理。 这些代理将自动化诸如代码生成、支持票证管理、客户数据分析、员工入职培训和基础设施监控之类的任务。
然而，目前的工具不足以支持这样的未来。
挑战不仅仅在于“代理孤岛”问题，即代理在孤立的环境中运行，缺乏通信能力。它包括一个更广泛的生态系统碎片化：
- 缺乏代理间通信：代理通常在孤立的环境中运行。 客户关系管理 (CRM) 代理不知道数据仓库代理获得的见解。 支持代理无法响应监控代理检测到的异常。
- 脆弱且定制化的工具使用：如果没有访问工具或外部应用程序编程接口 (API) 的标准化方法，代理将依赖于硬编码的集成和不可重用的逻辑。
- 不一致的框架：不同的代理运行时采用不同的模型，将代理视为聊天机器人、有向无环图 (DAG) 或递归规划器。 这导致缺少可移植的执行层或共享状态。
- 专注于 Notebook 环境的设计：许多代理被开发为一次性的原型，其特点是线性、同步和短暂的操作。 然而，实际系统需要可靠地处理重试、故障、协调、日志记录和扩展，这需要一个支持基础设施。
- 缺少协作骨干：没有事件总线、共享内存或代理活动和基本原理的可追溯历史记录。 信息仅限于直接 HTTP 调用或埋藏在日志中。
正如 12-Factor Agents 项目所强调的那样，代理应遵守云原生原则，表现出可观察性、松散耦合、可重现性和基础设施意识。 不幸的是，大多数代理都是作为脆弱的脚本构建的，这些脚本是手动组装的，并且被假定为独立运行。
这导致效率低下、重复工作和脆弱性。
Agent2Agent 通过为代理提供用于发现和通信的标准化协议，部分地解决了这个问题。 然而，要超越肤浅的演示，实现生产系统所需的规模和可靠性，需要的不仅仅是协议。 它需要一个全面的基础设施。
当前的代理生态系统反映了网络的早期阶段，其特点是强大但孤立且不兼容的系统。 类似于早期浏览器在没有标准协议的情况下与服务器通信所面临的挑战，今天的 AI 代理在发现、通信和彼此有效协作方面步履蹒跚。
Google 的 Agent2Agent (A2A)：一种通用的代理通信协议
Google 的 A2A 协议是解决此问题的一项重大尝试。 它的独特之处在于它不是另一个代理框架，而是一种通用协议，旨在连接任何代理，无论其来源或部署环境如何。
类似于 HTTP 如何标准化网站通信，A2A 定义了一种代理的通用语言，使他们能够：
- 公布功能：通过
AgentCard，这是一个 JSON 描述符，概述了代理的功能和交互方法。 - 发送和接收任务：通过使用 JSON-RPC 的结构化交互，其中一个代理请求协助，另一个代理以结果或“工件”响应。
- 使用服务器发送事件 (SSE) 流式传输更新：在漫长或协作的任务期间促进实时的反馈。
- 交换丰富的内容：支持交换文件、结构化数据和表单，而不仅仅是简单的文本。
- 默认情况下保持安全：内置了对 HTTPS、身份验证和权限的支持。
A2A 的优势在于避免了重新发明已建立的解决方案。 它利用了完善的网络标准，类似于 HTTP 和 SMTP，从而促进了更容易的采用和更快的集成。
然而，A2A 仅代表整体解决方案的一个方面。
Anthropic 的模型上下文协议 (MCP)：标准化工具使用和上下文访问
Anthropic 的 MCP 解决了代理如何利用工具和访问上下文信息的关键方面。 MCP 标准化了代理调用 API、调用函数以及与外部系统集成的过程，本质上定义了它们在其环境中的运作方式。 虽然 A2A 管理代理间通信，但 MCP 侧重于代理与外部世界的交互。
本质上：
- MCP 增强了各个代理的智能。
- A2A 实现了集体智能。
类似于 HTTP 和 SMTP 需要广泛的采用、基础设施和开发人员工具才能取得广泛的成功，A2A 和 MCP 将需要一个强大的生态系统才能充分发挥其潜力。
即使有了像 A2A 和 MCP 这样的标准化工作，一个关键问题仍然存在：如何在复杂且动态的企业环境中有效地扩展代理通信？ 仅仅依赖这些协议定义的直接的、点对点的连接，会带来与可扩展性、弹性和可观察性相关的挑战。 这突出了对强大的底层通信基础设施的需求。
想象一家公司，员工只能通过直接的、一对一的消息进行交流。 分享更新将需要单独向每个人发送消息。 跨多个团队协调项目将涉及手动在每个团队之间传递信息。
将这样的系统扩展到数百名员工将导致混乱。
这种情况反映了基于直接连接构建的代理生态系统所面临的挑战。 每个代理都必须知道要联系哪些代理、如何联系他们以及他们的可用性。 随着代理数量的增加，所需的连接数量呈指数增长，从而导致一个脆弱的、难以管理的和不可扩展的系统。
A2A 和 MCP 为代理提供了通信和行动的语言和结构。 然而，仅有语言是不够的。 为了跨企业协调众多代理，需要基础设施来管理消息流和代理响应。
Kafka 和 Flink：可扩展代理协作的骨干
Apache Kafka 和 Apache Flink 提供了这个至关重要的基础设施。
Kafka 和 Flink 解释
Apache Kafka，最初由 LinkedIn 开发，现在是 Apache 软件基金会项目，是一个分布式事件流平台。 它用作持久的、高吞吐量的消息总线，使系统能够发布和订阅实时事件流。 Kafka 被广泛用于各种应用中，包括金融系统、欺诈检测和遥测管道，因为它能够将生产者与消费者分离，并确保数据的持久性、可重放性和可扩展性。
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 这样的流原生运行时，代理仍然是孤立的，无法有效地协调、高效地扩展或随着时间的推移进行推理。
用于企业级 AI 代理的四层架构
为了充分实现企业级、可互操作的 AI 代理的愿景，需要一个四层架构：
- 协议：A2A、MCP – 定义 什么。
- 框架：LangGraph、CrewAI、ADK – 定义 如何。
- 消息传递基础设施：Apache Kafka – 支持 流动。
- 实时计算：Apache Flink – 支持 思考。
这些层共同构成了 AI 代理的新互联网堆栈，为构建不仅智能而且协作、可观察和生产就绪的系统奠定了基础。
我们目前正处于软件发展的关键时刻。
正如最初的互联网堆栈（由 HTTP 和 SMTP 等协议以及 TCP/IP 等基础设施组成）开启了全球互联的时代一样，一个新的堆栈正在为 AI 代理出现。 然而，这个堆栈不是让人类导航网页或发送电子邮件，而是专为自主系统设计，这些系统协作以推理、决策和行动。
A2A 和 MCP 提供了代理通信和工具使用的协议，而 Kafka 和 Flink 提供了实时协调、可观察性和弹性的基础设施。 它们共同实现了从断开连接的代理演示到可扩展的、智能的、生产级的生态系统的转变。
这种演变不仅仅是解决工程挑战。 它是关于启用一种新的软件范例，其中代理跨越边界进行协作，实时提供见解和推动行动，从而使智能成为一个分布式系统。
然而，这个愿景需要积极的开发，强调开放性、互操作性，并借鉴之前互联网革命中获得的经验教训。
因此，在开发代理时，至关重要的是要考虑其在更广泛系统中的集成。 它能否有效地沟通？ 它能否与其他代理协调？ 它能否进化并适应不断变化的条件？
未来不仅仅是由代理驱动的； 它是代理连接的。