SOTA Sync
← 返回 FEED
AGENT2026-04-24

Google ADK 2.0：5种多 Agent 编排模式，从技能到系统

Google Cloud 在 Next 26 发布了 ADK 2.0，系统回答了多 Agent 编排的核心问题：如何保证 Agent A 的输出格式适合 Agent B 的输入？如何强制某些步骤必须按特定顺序执行，同时允许每个步骤内部有 AI 灵活性？如何协调不同语言、不同团队写的 Agent？

核心三大更新

1. Graph-based Workflows

用有向图定义 agent 逻辑，节点是 actions，边是带条件逻辑的 transitions。关键创新：可以在同一个图里混合确定性节点（硬编码业务规则）和 AI 驱动节点（LLM reasoning）。

2. Collaborative Agents

原生支持 coordinator-specialist 模式。coordinator 处理任务路由和工作流管理，specialist 处理特定领域的工作，有独立的 identity、tool 权限和 memory context。

3. Formalized Skills Framework

SKILL.md 变成了一等公民。通过 SkillToolset，agent 只需要知道 skill 的名称、描述和接口，不需要知道 skill 的内部实现。这实现了跨团队的 skill 组合。

5 种编排模式

Pattern 1: Hybrid Graph

用 graph 解决贷款申请处理：

  • 确定性节点：验证必需文件、信用分检查、合规检查（监管规则，不能由 AI 决定）
  • AI 驱动节点：评估文件质量、生成建议

Graph 强制执行的优点：LLM 在每个节点内有灵活性，但无法跳过节点或 reorder 图。合规官可以直接审查 workflow 结构，验证每个必需步骤都包含且顺序正确，不需要读任何 LLM prompt。

Pattern 2: Coordinator-Specialist

解决「God Agent」反模式：单一 agent 试图做所有事情，system prompt 越来越长，行为越来越不可预测。

coordinator = CoordinatorAgent(
    specialists=[data_analyst, document_writer, customer_expert],
    transfer_protocol=TransferProtocol.CONTEXTUAL,
)

TransferProtocol.CONTEXTUAL 定义了 Agent 间交接时上下文如何流动。document writer 不需要重新查数据库，它接收 data analyst 的输出作为上下文。

每个 specialist 有独立的 identity、tool 权限和 memory context。data analyst 无法访问 CRM 数据，customer expert 无法运行 SQL。任何单个 agent 故障的爆炸半径被限制在其领域内。

Pattern 3: Skill Composition

三个团队各自构建的 skill，可以被 coordinator 无缝组合成新 workflow：

data-extractor → trend-analyzer → executive-summary

多语言团队：ML 团队写 Python，数据工程写 Go，企业集成写 Java，前端写 TypeScript——之前需要自定义 API 集成、协议协商和数据格式转换。A2A 协议标准化了所有这些。

Pattern 4: Cross-Language Pipeline

每个 Agent 通过 /.well-known/agent-card.json 公布自己的能力，其他 Agent 自动发现。ADK Go 1.0 增加了 OpenTelemetry 分布式追踪、自愈逻辑（通过 plugins）和 YAML-based agent 定义（ declarative 管理方式）。Java SDK 增加了事件压缩（管理长对话历史）和 ToolConfirmation（企业治理关键）。

Pattern 5: Sandboxed Executors

在 workflow 里执行代码是刚需，但跑任意代码是安全风险。ADK 2.0 的 SecureWorkspace：

  • allowed_commands：只允许特定命令（python、pip、pytest、git）
  • filesystem_access：只读/写 sandbox 内部
  • network_access：只允许白名单域名
  • max_execution_time：5 分钟超时
  • resource_limits：2G 内存、2 CPU

Sandbox 边界是关键安全属性。Agent 可以跑任意 Python 代码，但代码无法访问主机文件系统，无法连接未批准的网络，无法提权。

关键洞察：为什么 Graph 比 Prompt 好

大多数 agent 系统的生产失败是编排失败：agent 正确推理每个单独步骤，但以错误顺序执行、跳过必需步骤，或走了没有人预料到的路径。

根本原因：把 workflow 逻辑编码在 system prompt 里是根本性限制。LLM 是优化器，训练目标是高效产出有用输出。当模型看到一个五步 workflow，它经常决定通过合并步骤或 reorder 来产出更有用的响应。

Graph 结构从框架层面强制执行：LLM 在每个节点内有灵活性，但无法跳过节点或 reorder 图。

Skills 的渐进式加载

SkillToolset 的关键设计：agent 只在实际调用某个 skill 时才加载该 skill 的完整上下文。如果用户问一个不需要趋势分析的简单问题，trend-analyzer skill 的指令、引用和资产永远不会被加载进 context window。这使得即使 agent 可以访问数十个 skill，context token 使用量仍然高效。

这和 npm、pip、Maven 成功的原因相同：小而专注、可组合、有清晰接口的包，比大型单体库更有价值。

原文：From Skills to Systems: 5 Multi-Agent Orchestration Patterns in ADK 2.0 — Google Cloud Tech

相关