随着互联网的不断发展，我们正从一个主要为人类网络浏览而设计的网络，转向一个支持跨系统自主代理协作的基础设施。这种新的范式需要一个根本不同的堆栈，一个建立在开放组件之上的堆栈，以促进无缝通信、工具利用和实时处理。
碎片化Agent生态系统的挑战
当前，AI Agent开发面临着与碎片化和缺乏互操作性相关的重大挑战。这些挑战阻碍了强大且可扩展的AI系统的创建：
- 孤立的Agent：Agent通常在孤岛中运行，无法通信或共享信息。例如，CRM Agent可能不知道数据仓库Agent发现的见解，从而导致错失机会和效率低下。
- 脆弱的工具使用：在没有调用工具和API的标准协议的情况下，Agent依赖于难以维护和重用的硬编码集成。这限制了它们适应不断变化的环境和与新系统集成的能力。
- 不一致的框架：不同的Agent运行时采用不同的模型，将Agent视为聊天机器人、有向无环图 (DAG) 或递归规划器。这种缺乏一致性使得创建可移植和可互操作的Agent变得困难。
- 以原型为中心的开发：许多Agent被设计为一次性原型，缺乏实际部署所需的鲁棒性和可扩展性。它们通常无法解决重试、故障、协调、日志记录和扩展等关键问题。
- 缺乏协作骨干：缺少中央事件总线、共享内存或Agent操作的可追溯历史会阻碍协作和协调。信息通常被困在直接HTTP调用中或埋在日志中，使得理解和调试Agent行为变得困难。
解决方案不在于将所有Agent整合到一个单一的平台中，而在于构建一个基于开放协议、事件驱动架构和实时处理的共享堆栈。这种方法可以促进互操作性、可扩展性和弹性。
Agent2Agent：标准化Agent通信
Google 的 A2A 协议是解决Agent互操作性问题的重要一步。它提供了一种通用协议，用于连接Agent，无论其来源或运行时环境如何。通过为Agent定义一种共享语言，A2A 使它们能够：
- 宣传能力：Agent可以通过
AgentCard声明其能力，AgentCard是一个 JSON 描述符，用于指定Agent可以做什么以及如何与其交互。这允许其他Agent发现和利用他们的服务。 - 交换任务：A2A 通过 JSON-RPC 促进Agent之间的结构化交互，其中一个Agent请求另一个Agent的帮助，并收到结果或工件作为响应。这使得Agent可以协作完成复杂的任务。
- 流式更新：Agent可以使用服务器发送事件 (SSE) 在长时间运行或协作任务期间流式传输实时反馈。这提供了透明度，并允许Agent监视进度并对更改做出反应。
- 交换丰富内容：A2A 支持交换文件、结构化数据和表单，而不仅仅是纯文本。这使得Agent可以共享复杂的信息并协作完成更广泛的任务。
- 确保安全：A2A 包含对 HTTPS、身份验证和权限的内置支持，确保Agent之间的安全通信。这对于保护敏感数据和防止未经授权的访问至关重要。
模型上下文协议：启用工具使用和上下文感知
Anthropic 的 MCP 通过标准化Agent如何使用工具和访问外部上下文来补充 A2A。它定义了Agent如何调用 API、调用函数以及与外部系统集成，从而使它们能够与现实世界交互。
虽然 A2A 侧重于Agent如何相互通信，但 MCP 侧重于Agent如何与环境交互。这两个协议共同为连接的Agent生态系统提供了全面的蓝图：
- MCP 通过提供对工具和信息的访问来增强单个Agent的智能。
- A2A 通过促进Agent之间的通信和协作来实现集体智能。
对稳健通信基础设施的需求
想象一下一家公司，员工只能通过直接的一对一消息进行通信。共享更新需要单独向每个人发送消息，跨多个团队协调项目将涉及手动在组之间传递信息。随着公司的发展，这种方法变得越来越混乱且不可持续。
类似地，建立在直接连接之上的Agent生态系统变得脆弱且难以扩展。每个Agent必须知道与谁交谈、如何联系他们以及他们何时可用。随着Agent数量的增加，所需连接的数量呈指数增长，使得系统难以管理。
A2A 和 MCP 为Agent提供了交流和行动的语言和结构，但仅有语言是不够的。为了协调企业中的大量Agent，需要强大的基础设施来管理消息流和Agent反应。
Apache Kafka 和 Apache Flink：Agent协调的骨干
Apache Kafka 和 Apache Flink 提供了支持可扩展Agent通信和计算所需的基础设施。Kafka 充当分布式事件流平台，而 Flink 是实时流处理引擎。
Kafka 最初在 LinkedIn 开发，用作持久、高吞吐量的消息总线，允许系统实时发布和订阅事件流。它将生产者与消费者分离，并确保数据持久、可重放和可扩展。Kafka 广泛应用于各种应用程序，从金融系统到欺诈检测再到遥测管道。
Flink 也是一个 Apache 项目，专为有状态、高吞吐量、低延迟的事件处理而设计。虽然 Kafka 处理数据的移动，但 Flink 处理数据在系统中流动时的转换、丰富、监视和编排。
Kafka 和 Flink 共同形成了一个强大的组合：Kafka 是血液，Flink 是反射系统。它们为构建可扩展且有弹性的Agent生态系统奠定了基础。
正如 A2A 正在成为Agent世界的 HTTP 一样，Kafka 和 Flink 形成了事件驱动的基础，可以支持可扩展的Agent通信和计算。它们解决了直接的、点对点通信无法解决的问题：
- 解耦：使用 Kafka，Agent不需要知道谁将消费他们的输出。他们将事件（例如，
"TaskCompleted"，"InsightGenerated"）发布到主题，任何感兴趣的Agent或系统都可以订阅。 - 可观察性和可重放性：Kafka 维护每个事件的持久、按时间顺序排列的日志，使Agent行为完全可追溯、可审计和可重放。
- 实时决策：Flink 使Agent能够实时响应事件流，根据动态条件过滤、丰富、连接或触发操作。
- 弹性和扩展：Flink 作业可以独立扩展、从故障中恢复，并在长时间运行的工作流中维护状态。这对于执行复杂的多步骤任务的Agent至关重要。
- 流原生协调：Agent可以通过事件流进行协调，而不是等待同步响应，发布更新，订阅工作流并协作地推进状态。
总结：
- A2A 定义了Agent如何说话。
- MCP 定义了他们如何对外部工具采取行动。
- Kafka 定义了他们的消息如何流动。
- Flink 定义了如何处理、转换这些流并将其转化为决策。
面向企业级AI Agent的四层堆栈
像 A2A 和 MCP 这样的协议对于标准化Agent行为和通信至关重要。然而，如果没有像 Kafka 这样的事件驱动的底层和像 Flink 这样的流原生运行时，这些Agent仍然是孤立的，无法灵活地协调、优雅地扩展或随着时间的推移进行推理。
为了充分实现企业级、可互操作的AI Agent的愿景，我们需要一个四层堆栈：
- 协议：A2A 和 MCP 定义了Agent通信和工具使用的 什么。
- 框架：LangGraph、CrewAI 和 ADK 定义了Agent实现和工作流管理的 方式。
- 消息传递基础设施：Apache Kafka 支持Agent之间消息和事件的 流动。
- 实时计算：Apache Flink 支持通过实时处理和转换数据流来 思考。
这四层堆栈代表了 AI Agent 的新互联网堆栈，为构建不仅智能而且协作、可观察和生产就绪的系统奠定了基础。
迈向互联的Agent生态系统
我们正处于软件发展的关键时刻。正如最初的互联网堆栈开启了全球互联的新时代一样，AI Agent 正在涌现出一个新的堆栈。这个堆栈是为自主系统协同工作以进行推理、决策和行动而构建的。
A2A 和 MCP 提供了Agent通信和工具使用的协议，而 Kafka 和 Flink 提供了实时协调、可观察性和弹性的基础设施。它们共同使得从断开连接的Agent演示转变为可扩展的、智能的生产级生态系统成为可能。
这不仅仅是解决工程挑战，而是实现一种新型软件，其中Agent跨越边界进行协作，实时提供洞察力和行动流，并允许智能成为分布式系统。
为了实现这一愿景，我们需要公开、互操作地构建，并牢记上次互联网革命的经验教训。下次构建Agent时，不要只问它可以做什么。问问它如何适应更大的系统：
- 它可以与其他Agent通信吗？
- 它可以与其他人协调其行动吗？
- 它可以进化并适应不断变化的环境吗？
未来不仅仅是Agent驱动的；它是Agent连接的。