构建分布式 AI 智能体
本文说明如何用编排器模式,把研究、质检和编排拆成可独立扩缩的 Cloud Run 微服务,并通过 A2A 协议对接现有前端。

目录
#构建分布式 AI 智能体
2026 年 3 月 18 日
Amit Maraj
AI 开发者关系工程师(AI Developer Relations Engineer)
老实说:做一个能跑通一次的 AI 智能体(Agent)很容易。做一个能在生产环境里稳定工作、并且接到现有 React 或 Node.js 应用上的智能体?那完全是另一回事。
(长话短说:想直接看代码?请查看 GitHub 上的 课程创建智能体架构(Course Creator Agent Architecture)。)
我们都遇到过这种情况。你有一条复杂工作流——也许是研究一个主题、生成内容,然后再打分。你把所有东西塞进一个巨大的 Python 脚本,或一条巨大的提示词。它在你自己的机器上能用,可一旦接到精致的前端上,事情就变乱了。延迟飙升,调试变成噩梦,不把整块单体复制一遍就无法扩展。
但如果你不必为了容纳 AI 而重写整个应用呢?如果你可以只是……把它插进去呢?
在这篇文章里,我们要探索一种更好的做法:编排器模式(orchestrator pattern)。不是只做一个什么都干的强大智能体,而是组建一支由专职、分布式微服务组成的团队。这样可以把强大的 AI 能力直接接到现有前端应用里,而不必痛苦地重写单体。
我们将使用 Google 的智能体开发工具包(Agent Development Kit,ADK)来构建智能体,使用智能体对智能体协议(Agent-to-Agent,A2A)把它们连起来并让它们互相通信,再把它们作为可扩展的微服务部署到 Cloud Run。
为什么要用分布式智能体?(以及为什么前端团队会喜欢你)
设想你有一个打磨好的 Next.js 应用。你想加一个“课程创建器(Course Creator)”功能。
如果你做一个单体智能体,前端必须等一个长时间运行的进程把所有事情做完。如果研究那一段卡住,整个请求就会超时。此外,你也没有机会按需单独扩展某个智能体。例如,如果质检智能体需要更多算力,你就得把所有智能体一起扩容,而不是只扩质检智能体。
采用分布式编排器模式后,你会得到可扩展性和灵活性:
- 无缝集成: 前端只和一个端点(编排器)对话,由它在幕后处理混乱。
- 独立扩展: 质检这一步慢吗?只把那个服务扩到 100 个实例。研究服务可以保持很小。
- 模块化: 你可以用 Go 写高性能网络部分,用 Python 写数据科学部分。它们只要说 HTTP。
蓝图:课程创建器应用
我们来构建这个课程创建系统。把它拆成三个不同的专职角色:
- 研究员(researcher):负责挖掘信息的专职角色。
- 质检员(judge):负责保证质量的质检专职角色。
- 编排器(orchestrator):负责协调工作并与前端对话的管理者。
第 1 步:雇一位专职人员(研究员)
首先,我们需要有人做基础工作。我们将用 ADK 构建一个聚焦的智能体,它唯一的工作是使用 Google 搜索(Google Search)。
# researcher/app/agent.py
from google.adk.agents import Agent
from google.adk.tools import google_search
researcher = Agent(
name="researcher",
model="gemini-2.5-flash",
description="Gathers information on a topic using Google Search.",
instruction="""
You are an expert researcher. Your goal is to find comprehensive information.
Use the `google_search` tool to find relevant information.
Summarize your findings clearly.
""",
tools=[google_search],
)看到了吗?很简单。它不知道课程,也不知道前端。它只做研究。
第 2 步:质检员(结构化输出)
我们不能让智能体漫无边际地说话。我们需要严格的通过或失败等级,这样代码才能做决定。我们用 Pydantic 来强制执行这份契约。
# judge/app/agent.py
from pydantic import BaseModel, Field
from typing import Literal
class JudgeFeedback(BaseModel):
status: Literal["pass", "fail"] = Field(
description="Whether the research is sufficient ('pass') or needs more work ('fail')."
)
feedback: str = Field(
description="Detailed feedback on what is missing."
)
judge = Agent(
name="judge",
model="gemini-2.5-flash",
description="Evaluates research findings.",
instruction="""
You are a strict editor. Evaluate the findings.
If they are missing key info, output status='fail' and provide feedback.
""",
output_schema=JudgeFeedback, # Enforce the contract!
)现在,当质检员开口时,它说的是 JSON。你的应用逻辑可以信任它。
第 3 步:通用语言(A2A 协议)
魔法在这里。我们用 A2A 协议把这些智能体包成 Web 服务。可以把它看成智能体的通用语言。它让智能体描述自己做什么(agent.json),并通过标准 HTTP 交谈。
# researcher/app/server.py
from fastapi import FastAPI
from a2a.server.apps import A2AFastAPIApplication
from app.agent import app as adk_app
# ... setup runner ...
# Create the A2A App wrapper
a2a_app = A2AFastAPIApplication(agent_card=agent_card, http_handler=request_handler)
app = FastAPI(lifespan=lifespan)
# Register routes: /.well-known/agent.json and /rpc
a2a_app.add_routes_to_app(app)现在,你的研究员是一个跑在 8000 端口上的微服务。它已经可以被任何人调用——包括你的编排器。
第 4 步:编排器模式
一切在这里汇合。编排器是总承包商。它自己不做研究;它雇研究员。它自己不做判断;它去问质检员。
关键是,这是前端唯一需要知道的智能体。
# orchestrator/app/agent.py
from google.adk.agents import LoopAgent, SequentialAgent
from google.adk.agents.remote_a2a_agent import RemoteA2aAgent
# Connect to the remote Researcher service
researcher = RemoteA2aAgent(
name="researcher",
agent_card="http://researcher-service:8000/.well-known/agent.json",
description="Gathers information on a topic."
)
# Connect to the remote Judge service
judge = RemoteA2aAgent(
name="judge",
agent_card="http://judge-service:8000/.well-known/agent.json",
description="Evaluates research findings."
)
# The Orchestrator manages the loop
research_loop = LoopAgent(
name="research_loop",
sub_agents=[researcher, judge, escalation_checker],
max_iterations=3,
)
# The full pipeline
root_agent = SequentialAgent(
name="course_creation_pipeline",
sub_agents=[research_loop, content_builder],
)编排器处理复杂性——重试、循环、状态管理——这样前端就能保持干净和简单。
部署:“杂货店”模型
把这套系统部署到 Cloud Run,你会得到我所说的“杂货店”模型。如果结账队伍(研究员任务)变长,你不必再建一家店。你只要多开几个收银台。Cloud Run 会独立扩展研究员服务来承接负载,而质检服务保持精简。
注意事项与安全考量
当然,能力越大,责任越大(还有安全评审)。
- 身份验证(Authentication):在这个演示里,智能体通过开放的 HTTP 交谈。在生产环境中,你必须把这一点锁死。使用双向传输层安全(mutual TLS,mTLS)、OpenID Connect(OIDC)或 API 密钥,确保只有你的编排器能和研究员交谈。
- 延迟(Latency):每一跳都会增加时间。把这个模式用于粗粒度任务(例如“研究这个主题”),而不是频繁来回的低层交互。
- 错误处理(Error handling):网络会失败。你的编排器必须足够稳健,能优雅地处理超时和重试。
准备好开始构建了吗?
不要再试图做一个什么都干的巨型智能体。通过编排器模式和分布式微服务,你可以构建可扩展、可维护的 AI 系统,而且——最好的一点是——能和你已经有的应用好好相处。
想看代码?请查看 GitHub 上的完整课程创建智能体架构。
如果你准备部署,可以从 Cloud Run、ADK 和 A2A 开始,让你的智能体团队运转起来。
PRIMARY_SOURCE: https://cloud.google.com/blog/topics/developers-practitioners/building-distributed-ai-agents
- #分布式智能体
- #ADK
- #A2A
- #Cloud Run
- #编排器


