你将如何构建具有复杂推理能力和特定专长的AI系统？以金融交易为例说明：成功不仅需要一个有效的交易策略，还需要严格的风控和合规管理。一个AI系统如何才能在预测市场走势和实施交易限制两方面都表现出色？如果你将这些关注点拆分为专门的AI代理，你如何确保它们能够理解彼此的请求和回应？

这个挑战是设计如Agentic Trading Simulator这样的系统的核心。尝试构建一个单一的大规模AI代理来处理交易策略和风险检查可能会导致复杂的且相互纠缠的逻辑，难以升级或改进。解决方案是将这些职责分离到专门的代理中。然而，如果没有一个统一的沟通方式，策略代理如何可靠地问风险代理“这个交易行得通吗？”并清晰地理解批准或拒绝，以及原因解释？一对一的定制集成是脆弱且难维护的。

交易代理模拟UI

这是谷歌的开源Agent Development Kit (ADK)和Agent-to-Agent (A2A)协议发挥作用的位置。ADK提供了构建各自交易策略和风险管理代理程序的结构，而A2A则定义了它们如何交互的标准通信规则。两者结合，让这种应用能够实现模块化和协作的架构。

这篇帖子通过一个交易模拟器作为例子，探讨了ADK和A2A背后的架构理念，主要关注于这些技术如何使多智能体系统更有效。

我们的演示应用程序由3个模块组成。

1. 模拟器用户界面: “操作者”作为用户界面和调度器。它运行模拟循环，但将核心“思考”任务交给专门代理。
2. AlphaBot ADK代理: “交易策略师”接收市场和投资组合信息（通过A2A传递）并根据其内部逻辑确定潜在的交易行动（如本演示所示的移动平均线交叉策略）。
3. RiskGuard ADK代理: “风控官”接收AlphaBot提出的买卖指令（通过A2A传递）并根据预设的风险规则（如仓位大小和集中度）进行评估。它通过A2A回复同意或拒绝。

关键的架构模式是通过标准化的通信来实现的责任分派。

模拟器不需要知道AlphaBot决定交易的具体方式，只需要知道如何通过A2A发送数据以及如何解读其响应即可。同样，AlphaBot也不需要了解RiskGuard规则的细节，只需要知道如何通过A2A提出交易以及如何理解返回的状态即可。

请注意以下事项，此应用程序仅供教育和示范之用。 它并不提供任何财务性、投资、法律或交易建议。

尽管A2A定义了代理之间如何交流，谷歌的代理开发工具包（ADK）提供了构建他们要说的内容以及他们做出决定的方式所需的核心工具包。ADK为AlphaBot和RiskGuard的内部逻辑提供了结构，使它们能够处理信息，管理状态，使用工具（如通过A2A互相呼叫），并最终在交易系统中完成其特定职责。这促进了模块化和可维护性，而不是简单地编写单体脚本。

以下是支持AlphaBot和RiskGuard的关键ADK构建的可视化图，随后将对每个构建进行详细解释：

ADK 架构在代理式交易应用程序中

• 业务逻辑 ([**BaseAgent**](https://google.github.io/adk-docs/api-reference/google-adk.html#google.adk.agents.BaseAgent)): 这是AlphaBot的交易策略所在，它通过分析价格并决定潜在行动。对于RiskGuard，这是评估risk rule的地方。ADK鼓励将核心推理从周围的通信和执行样板中分离出来。
• 接收输入和上下文 (InvocationContext): 代理如何获取其特定任务所需的数据？InvocationContext被传递到代理的run方法中。它携带关键输入——对于AlphaBot来说，这包括由模拟器UI（通过A2A发送）的市场数据和投资组合状态；对于RiskGuard来说，这是AlphaBot发送的交易提案（通过A2A）。
• 与外部能力互动 ([**BaseTool**](https://google.github.io/adk-docs/api-reference/google-adk.html#google.adk.tools.BaseTool)): 代理很少孤立工作。它们需要调用API，查询数据库，或者在我们的情况下，“与其他代理通信”。ADK提供了一种标准化的方法来定义和调用这些外部功能。这就是AlphaBot与RiskGuard通信的方式。我们定义了一个[A2ARiskCheckTool](https://github.com/kweinmeister/agentic-trading/blob/main/alphabot/a2a_risk_tool.py)。AlphaBot的逻辑调用了这个工具，它封装了对RiskGuard的A2A JSON-RPC调用的细节。
• 通信结果和行动 ([**Event**](https://google.github.io/adk-docs/api-reference/google-adk.html#google.adk.events.Event)): 一旦代理做出决定（例如，AlphaBot提出交易或RiskGuard批准/拒绝交易），它是如何发出信号的？代理通过产生Event对象来表示。这些事件包含代理的输出，比如文本、结构化数据和工具结果，并可以发出表示动作的信号，如state updates。Runner处理这些事件。
• 编排和状态管理 ([**Runner**](https://google.github.io/adk-docs/api-reference/google-adk.html#google.adk.runners.Runner),[**SessionService**](https://google.github.io/adk-docs/api-reference/google-adk.html#google.adk.sessions.BaseSessionService)): Runner编排代理的生命周期——接收输入，调用代理的run逻辑，处理yield的事件，调用请求的工具，并管理总体流程。对于像AlphaBot这样的有状态代理，SessionService提供了在同一个会话中的多次调用之间存储和检索状态的机制。ADK提供了实现，例如[InMemorySessionService](https://google.github.io/adk-docs/api-reference/google-adk.html#google.adk.sessions.InMemorySessionService)（在我们的演示中使用），允许AlphaBot在市场更新之间保持其交易策略。在演示中，RiskGuard基本上是无状态的，但可以根据需要使用会话状态（例如跟踪最近的交易速度）。

ADK 结构化 代理，而 A2A 则定义了 代理之间如何通信。这种基于 JSON-RPC 的标准化协议（详情见这里）通过 HTTP 实现，让不同框架或团队开发的代理能够有效协作。我们的演示利用了几个核心 A2A 概念。下面的序列图展示了这些概念在实际中的应用。

序列图：A2A客户端与服务器间的交互

要加入A2A生态系统，代理需要托管在支持该协议的服务器上。这个服务器作为代理的公开接口，监听入站的标准A2A请求。在我们演示中，AlphaBot 和 RiskGuard 都在这个 [A2AServer](https://github.com/kweinmeister/agentic-trading/blob/main/common/server/server.py) 实例中启动（来自 A2A样本库 的示例）。此服务器接收传入的HTTP POST请求，验证这些请求是否符合A2A JSON-RPC结构，识别请求的A2A方法（如tasks/send），并将请求参数路由到底层代理逻辑（由ADK的Runner通过我们的TaskManager类进行管理，TaskManager是我们的任务管理器类）。

任何需要与A2A代理互动的服务都作为A2A客户端。客户端负责构建有效的A2A请求（通常是一个JSON-RPC负载），并通过HTTP POST发送到目标代理的A2A服务器端点。在模拟器中，UI在向AlphaBot发送市场数据时充当A2A客户端，使用帮助类[A2AClient](https://github.com/kweinmeister/agentic-trading/blob/main/common/client/client.py)。AlphaBot也在它的[A2ARiskCheckTool](https://github.com/kweinmeister/agentic-trading/blob/main/alphabot/a2a_risk_tool.py)中作为A2A客户端，通过httpx调用来发送给风险控制A2A服务器其提议的交易详情。

客户如何知道代理的位置和它能做什么？A2A协议定义了一个标准代理名片。这张名片包含了一些关键信息，如代理的名称、描述、它的A2A端点URL、支持的功能，比如流媒体、具备的技能以及默认的数据格式。我们的A2AServer会自动提供每个代理在启动时定义的代理名片。虽然这个示例使用了配置好的URL，但一个更动态的系统可能会先获取代理名片，以了解如何及何处与另一个代理进行通信。

A2A中的核心互动围绕着 [任务](https://google.github.io/A2A/#/documentation?id=任务) 进行。客户端通过诸如 tasks/send（用于请求响应）或 tasks/sendSubscribe（用于流式更新）这样的方法发起任务。模拟器（Simulator）向AlphaBot发送一个任务（“根据这些市场数据决定一笔交易”），AlphaBot再向RiskGuard发送一个子任务（Sub-task）（“检查这笔提议的交易是否符合规定”）。这些任务的参数，包括输入数据和诸如风险限额这样的元数据，根据A2A规范使用 [TaskSendParams](https://github.com/kweinmeister/agentic-trading/blob/main/common/types.py#L135) 结构进行打包。

任务中的数据交换通过 [Message](https://google.github.io/A2A/#/documentation?id=message) 对象来完成，这些对象包含一个或多个 [Part](https://google.github.io/A2A/#/documentation?id=part) 对象，具体来说。A2A 定义了一些标准部件类型，例如 TextPart、FilePart 和 DataPart。我们的演示依赖于 [DataPart](https://github.com/kweinmeister/agentic-trading/blob/main/common/types.py) 来发送结构化的 JSON 负载。市场状态、投资组合详情、交易提案和风险参数等信息都通过 DataPart 进行交换。

当任务完成后，代理如何返回可能复杂的成果？A2A 使用 [Artifact](https://google.github.io/A2A/#/documentation?id=artifact) 对象。Artifacts 作为 A2A 任务结果的附件，可以包含各种数据片段。在我们演示中，RiskGuard 将其结构化的决策打包成 DataPart，然后放置在 Artifact 中。AlphaBot 的 [A2ARiskCheckTool](https://github.com/kweinmeister/agentic-trading/blob/main/alphabot/a2a_risk_tool.py#L123) 被设计用来在 RiskGuard 的回复中查找名为 Artifact 的内容并从中提取决策数据。

想看看ADK + A2A架构的实际运行吗？你可以自己运行Agentic Trading Simulator，选择本地运行或部署到Google Cloud Run。首先，克隆Agentic Trading仓库，然后按照README.md文件中的入门指南部分操作。以下是两种部署选项：

本地运行演示：最简单的方法是在您的机器上运行演示程序，只需使用提供的deploy_local.sh脚本。

此脚本会自动启动RiskGuard组件、AlphaBot组件，并使用它们各自的默认本地配置来启动模拟器UI Web服务器。服务启动后，然后您可以在浏览器中访问模拟器UI。

部署到 Google Cloud Run: 为了将服务部署到 Google Cloud Run，仓库中有一个自动化脚本 deploy_cloud_run.sh，它使用 Google Cloud Build 和 Cloud Run 来自动化部署过程。

此脚本将为每个服务构建容器镜像文件，并将其推送到Google Artifact Registry，并将其部署为可公开访问的Cloud Run服务。它会自动配置所需的服务URL，使代理和UI能够互相通信。脚本将在部署完成后输出模拟器UI的最终网址。注意：这会使演示公开访问；请评估在非演示用途中的安全影响。

在这篇博客文章中，我们展示了如何使用Google Agent Development Kit (ADK) 和Agent-to-Agent (A2A) 协议构建协作代理系统的核心概念。提供的演示应用程序为构建更复杂和更高级的系统奠定了基础。ADK 结构化代理开发与 A2A 标准化通信的结合使用为下一代智能分布式AI应用铺平了道路。

为了保持势头，你可以克隆Agentic Trading demo 仓库并尝试。还可以看看A2A 示例仓库，该仓库不仅有更多示例，还有这个应用程序用到的客户端/服务器代码。

考虑通过增强系统，添加新的代理（如情感分析代理）并使用A2A（代理对代理）进行集成，或探索更高级的ADK功能，例如实时处理和状态维护。可以利用A2A的更丰富功能，如通过代理卡片实现动态发现代理，或进行异步任务管理以支持更长的过程。为了扩展到生产环境，可以研究使用Vertex AI Agent Engine这样的托管平台。随时欢迎在LinkedIn, X和Bluesky上与我联系，继续交流！

视频教程：模拟器应用程序、相关代码以及关于A2A和ADK的相关概念（时长15分钟）