<p>现代人工智能系统扩展的主要摩擦点不是计算能力或模型质量，而是集成的复杂性。当不同框架、语言和 API 模式构建的离散 AI 服务必须进行通信时，开发人员往往花费更多时间编写 “粘合代码” 而不是实际的 AI 逻辑，导致脆弱的单体架构。在最近关于构建多智能体系统的演讲中，谷歌开发者倡导者 Amit Maraj 提出了这个问题的基础解决方案：代理到代理（A2A）协议，配合代理开发工具包（ADK），提供一个标准化的、类似微服务的框架，以实现代理之间的互操作性。</p>
<p>Maraj 谈到了通用接口的必要性，将当前 AI 集成的状态比作与不兼容的旅行适配器搏斗。A2A 协议旨在成为那个通用适配器，确保代理无论其底层栈是 Python、Node 还是 Go，都可以通过标准 HTTP 接口无缝通信。这种标准化依赖于一个核心概念：AgentCard，这是一个托管在`/.well-known/agent.json`的机器可读 JSON 文件。</p>
<p>这个 AgentCard 充当代理的公共合同。它指定了代理的名称、描述、版本，以及关键的能力，包括输入和输出模式。Maraj 指出，AgentCard“有点像我们代理的约会资料”，提供了另一个代理或协调者与其智能交互所需的所有信息。通过明确地定义这些模式，代理可以有效地进行通信，而无需导入或理解其同伴的内部代码依赖。这类似于现代微服务使用 OpenAPI 规范（Swagger）来定义其接口，但专门针对大型语言模型（LLMs）的动态、提示驱动特性进行了调整。</p>
<p>这种方法的直接好处是架构解耦。如果一个研究代理使用 Python 构建了一个超快、便宜的模型，而后续的内容创作代理使用 Go 构建了一个庞大、昂贵的推理模型，它们可以在不关心彼此实现细节的情况下交换数据。它们只需使用 A2A 进行交流。Maraj 强调，这使得真正的多语言持久性和架构灵活性成为可能：“你甚至可以明天用 Go 重写研究者，保持相同的 A2A 接口，而你系统的其余部分甚至不会眨眼。这才是真正的微服务架构，但用于 AI。” 这种关注点的分离对于希望快速迭代、根据成本或性能更换模型并保持对技术更迭的韧性的企业至关重要。</p>
<p>通过 A2A 实现互操作性只是战斗的一半；复杂的 AI 工作流需要强大的状态管理和执行控制。这就是代理开发工具包（ADK）引入以协调者代理为中心的关键架构模式的地方。与其让每个工作代理维护自己对过去步骤和上下文的记忆——这种方法本质上是脆弱且资源密集的——ADK 强制执行一个模式，其中一个协调者管理整体状态。</p>
<p>协调者充当 “项目经理”，维护状态的 “主剪贴板”。这种设计确保了专门的工作代理，如研究者或评审，保持轻量、可扩展且抗崩溃。</p>
<p>工作代理是无状态的，从协调者接收指令和上下文，执行特定任务，然后在终止或等待下一个指令之前将输出返回到主剪贴板。这种架构本质上是容错的。正如 Maraj 所指出的，“如果一个工作机器人崩溃并重启，那没关系。它没有丢失任何重要的东西，因为它没有持有任何重要的东西。” 协调者保留完整的历史和上下文，允许轻松重试或重新分配失败的步骤，而不会丢失关键进展。这与早期的代理框架有根本的不同，后者通常需要持久的、有状态的工作进程，使得部署和扩展变得困难。</p>
<p>ADK 进一步简化了编排层，通过提供标准化的工作流管理模式，如顺序代理（执行步骤 A，然后是 B）和循环代理（迭代步骤 A 直到满足条件）。这些模式抽象了任务路由和状态持久化的复杂逻辑，使开发人员能够专注于定义工作流和在代理之间流动的状态数据结构——“剪贴板”。因此，重点从编写复杂的集成代码转移到定义精确的数据合同（通过 A2A）和高层次的执行流程（通过 ADK 模式）。对于复杂的 AI 生态系统，定义需要保存的数据——如研究结果和评审反馈——成为在编写任何代码之前的基础步骤。这种严谨的方法承诺将 AI 代理构建提升到从实验脚本到工业级分布式系统工程的水平。</p>

谷歌-C

谷歌-A

1 倍做空谷歌 ETF - Direxion

2 倍做多谷歌 ETF - Direxion

<p>谷歌推出了代理到代理（A2A）协议和代理开发工具包（ADK），以解决集成不同人工智能系统的复杂性。A2A 协议充当一个通用接口，使得用不同语言构建的代理能够无缝沟通。AgentCard 是一个机器可读的 JSON 文件，指定了每个代理的能力，从而实现有效的沟通而无需内部代码依赖。ADK 引入了一个协调者代理来管理状态和执行控制，确保轻量级、可扩展的工作代理。这种架构促进了容错性，并简化了工作流程管理，增强了强大人工智能系统的开发</p>

<p>The primary friction point in scaling modern AI systems is not computational power or model quality, but the sheer complexity of integration. When disparate AI services—built across different frameworks, languages, and API schemas—must communicate, developers often spend more time writing “glue code” than actual AI logic, resulting in brittle, monolithic architectures. Google Developer Advocate Amit Maraj, in a recent presentation on building multi-agent systems, introduced a foundational solution to this problem: the Agent-to-Agent (A2A) protocol, paired with the Agent Development Kit (ADK), providing a standardized, microservice-like framework for agent interoperability.</p>
<div class="lb-trans"><p>现代人工智能系统扩展的主要摩擦点不是计算能力或模型质量，而是集成的复杂性。当不同框架、语言和 API 模式构建的离散 AI 服务必须进行通信时，开发人员往往花费更多时间编写 “粘合代码” 而不是实际的 AI 逻辑，导致脆弱的单体架构。在最近关于构建多智能体系统的演讲中，谷歌开发者倡导者 Amit Maraj 提出了这个问题的基础解决方案：代理到代理（A2A）协议，配合代理开发工具包（ADK），提供一个标准化的、类似微服务的框架，以实现代理之间的互操作性。</p>
</div><p>Maraj spoke about the necessity of a universal interface, likening the current state of AI integration to wrestling with incompatible travel adapters. The A2A protocol aims to be that universal adapter, ensuring that agents, regardless of their underlying stack—Python, Node, or Go—can communicate seamlessly via a standard HTTP interface. This standardization hinges on a core concept: the AgentCard, a machine-readable JSON file hosted at `/.well-known/agent.json`.</p>
<div class="lb-trans"><p>Maraj 谈到了通用接口的必要性，将当前 AI 集成的状态比作与不兼容的旅行适配器搏斗。A2A 协议旨在成为那个通用适配器，确保代理无论其底层栈是 Python、Node 还是 Go，都可以通过标准 HTTP 接口无缝通信。这种标准化依赖于一个核心概念：AgentCard，这是一个托管在`/.well-known/agent.json`的机器可读 JSON 文件。</p>
</div><p>This AgentCard serves as the agent’s public contract. It specifies the agent’s name, description, version, and, critically, its capabilities, including input and output schemas. Maraj notes that the AgentCard is “kind of like our agents’ dating profile,” providing all necessary information for another agent or orchestrator to interact with it intelligently. By defining these schemas explicitly, agents can communicate effectively without needing to import or understand the internal code dependencies of their peers. This is analogous to how modern microservices use OpenAPI specifications (Swagger) to define their interfaces, but tailored specifically for the dynamic, prompt-driven nature of large language models (LLMs).</p>
<div class="lb-trans"><p>这个 AgentCard 充当代理的公共合同。它指定了代理的名称、描述、版本，以及关键的能力，包括输入和输出模式。Maraj 指出，AgentCard“有点像我们代理的约会资料”，提供了另一个代理或协调者与其智能交互所需的所有信息。通过明确地定义这些模式，代理可以有效地进行通信，而无需导入或理解其同伴的内部代码依赖。这类似于现代微服务使用 OpenAPI 规范（Swagger）来定义其接口，但专门针对大型语言模型（LLMs）的动态、提示驱动特性进行了调整。</p>
</div><p>The immediate benefit of this approach is architectural decoupling. If a Researcher agent is built using a super-fast, cheap model in Python, and a subsequent Content Writer agent uses a massive, expensive reasoning model in Go, they can exchange data without caring about each other’s implementation details. They simply speak A2A. Maraj emphasized that this enables true polyglot persistence and architectural flexibility: “You could even rewrite the Researcher in Go tomorrow, keep the same A2A interface, and the rest of your system wouldn’t even blink. That’s true microservice architecture, but for AI.” This separation of concerns is paramount for enterprises looking to iterate quickly, swap models based on cost or performance, and maintain resilience against technological churn.</p>
<div class="lb-trans"><p>这种方法的直接好处是架构解耦。如果一个研究代理使用 Python 构建了一个超快、便宜的模型，而后续的内容创作代理使用 Go 构建了一个庞大、昂贵的推理模型，它们可以在不关心彼此实现细节的情况下交换数据。它们只需使用 A2A 进行交流。Maraj 强调，这使得真正的多语言持久性和架构灵活性成为可能：“你甚至可以明天用 Go 重写研究者，保持相同的 A2A 接口，而你系统的其余部分甚至不会眨眼。这才是真正的微服务架构，但用于 AI。” 这种关注点的分离对于希望快速迭代、根据成本或性能更换模型并保持对技术更迭的韧性的企业至关重要。</p>
</div><p>Interoperability through A2A is only half the battle; complex AI workflows require robust state management and execution control. This is where the Agent Development Kit (ADK) introduces a crucial architectural pattern centered on the Orchestrator agent. Instead of having every worker agent maintain its own memory of past steps and context—a method that is inherently fragile and resource-intensive—the ADK enforces a pattern where a single Orchestrator manages the overall state.</p>
<div class="lb-trans"><p>通过 A2A 实现互操作性只是战斗的一半；复杂的 AI 工作流需要强大的状态管理和执行控制。这就是代理开发工具包（ADK）引入以协调者代理为中心的关键架构模式的地方。与其让每个工作代理维护自己对过去步骤和上下文的记忆——这种方法本质上是脆弱且资源密集的——ADK 强制执行一个模式，其中一个协调者管理整体状态。</p>
</div><p>The Orchestrator functions as a “Project Manager” maintaining the “Master Clipboard” of state. This design ensures that specialized worker agents, such as the Researcher or the Judge, remain lightweight, scalable, and crash-resistant.</p>
<div class="lb-trans"><p>协调者充当 “项目经理”，维护状态的 “主剪贴板”。这种设计确保了专门的工作代理，如研究者或评审，保持轻量、可扩展且抗崩溃。</p>
</div><p>Worker agents, being stateless, receive instructions and context from the Orchestrator, execute a specific task, and return the output to the master clipboard before terminating or awaiting the next instruction. This architecture is inherently fault-tolerant. As Maraj points out, “If a worker bot crashes and restarts, it’s fine. It didn’t lose anything important because it wasn’t holding anything important.” The Orchestrator retains the complete history and context, allowing failed steps to be easily retried or re-assigned without losing critical progress. This is a fundamental divergence from earlier agent frameworks that often required persistent, stateful worker processes, making deployment and scaling difficult.</p>
<div class="lb-trans"><p>工作代理是无状态的，从协调者接收指令和上下文，执行特定任务，然后在终止或等待下一个指令之前将输出返回到主剪贴板。这种架构本质上是容错的。正如 Maraj 所指出的，“如果一个工作机器人崩溃并重启，那没关系。它没有丢失任何重要的东西，因为它没有持有任何重要的东西。” 协调者保留完整的历史和上下文，允许轻松重试或重新分配失败的步骤，而不会丢失关键进展。这与早期的代理框架有根本的不同，后者通常需要持久的、有状态的工作进程，使得部署和扩展变得困难。</p>
</div><p>The ADK further simplifies the orchestration layer by providing standardized patterns for managing workflow, such as the Sequential Agent (do step A, then B) and the Loop Agent (iterate step A until a condition is met). These patterns abstract away the complex logic of task routing and state persistence, allowing developers to focus purely on defining the workflow and the data structure of the state—the “clipboard”—that flows between agents. The emphasis, therefore, shifts from writing complex integration code to defining the precise data contracts (via A2A) and the high-level execution flow (via ADK patterns). For sophisticated AI ecosystems, defining what data needs to be saved—such as research findings and judge feedback—becomes the foundational step before any code is written. This disciplined approach promises to elevate AI agent construction from experimental scripting to industrial-grade, distributed systems engineering.</p>
<div class="lb-trans"><p>ADK 进一步简化了编排层，通过提供标准化的工作流管理模式，如顺序代理（执行步骤 A，然后是 B）和循环代理（迭代步骤 A 直到满足条件）。这些模式抽象了任务路由和状态持久化的复杂逻辑，使开发人员能够专注于定义工作流和在代理之间流动的状态数据结构——“剪贴板”。因此，重点从编写复杂的集成代码转移到定义精确的数据合同（通过 A2A）和高层次的执行流程（通过 ADK 模式）。对于复杂的 AI 生态系统，定义需要保存的数据——如研究结果和评审反馈——成为在编写任何代码之前的基础步骤。这种严谨的方法承诺将 AI 代理构建提升到从实验脚本到工业级分布式系统工程的水平。</p>
</div>

Decoupling AI Agents: Google Introduces the Agent-to-Agent Protocol

- 当前 AI 系统扩展的主要障碍是整合复杂性。  
- Amit Maraj 介绍了 A2A 协议和 ADK，旨在实现代理互操作性。  
- 该架构通过单一 Orchestrator 管理状态，提高系统的灵活性和容错性。

解耦 AI 代理：谷歌推出代理对代理协议