构建实用的 A2A 协议用于多智能体供应链智能

Source: Dev.to

供应链很少以整洁的单步工作流运行。
在每一次分类、合规检查、成本估算或风险评估背后，都有一系列决策、查询、验证和相互依赖的计算。大多数传统 API 设计过于简化了这种现实，假设一次请求‑响应循环就足以表示整个过程。

在过去的几个月里，我们一直在设计能够处理大规模供应链情报的系统——将产品、企业、地理位置和信号链接成一个全球供应图。一个反复出现的问题是：

如何设计一个接口，能够表达多步骤逻辑而不让调用方陷入意外的复杂性？

这促使我们探索一种轻量级的 A2A（Agent‑to‑Agent）协议——不是作为多代理编排框架，而是作为一种实用模式，用于将模块化、长时运行或多步骤的能力以可预测的组件形式暴露出来。

问题：供应链工作流本质上是多步骤的

许多供应链操作从外部看起来很简单，但在内部它们会跨越多个决策或数据层展开。几个例子：

• 将产品描述细化为标准化代码的分类步骤
• 包含例外、子规则和国家特定逻辑的合规或关税流程
• 跨供应商、地区或产品层的多跳依赖探索
• 需要在众多节点上聚合的地理集中度检查
• 基于分散的公开信号进行的结构化情报收集

尝试用一次同步 API 调用来表示这些内容会带来若干问题：

• 执行时间长
• 内部分支复杂
• 错误报告困难
• 推理或输出不透明
• 难以维护的单体端点

挑战不在于性能，而在于表达能力。我们需要一种方式，以干净、可预测且模块化的方式暴露复杂分析。

为什么我们探索 A2A 模式

我们没有构建一个庞大的 API 来尝试处理所有事务，而是开始尝试将系统的核心能力以 小而专用的单元 形式暴露，每个单元只执行一项任务。

不是 LLM 意义上的完整“代理”——只是职责明确的模块化组件。

每个单元：

• 接受明确定义的输入模式
• 异步处理（如有必要）
• 暴露 run → status → result 生命周期
• 返回结构化、确定性的输出

这种简单模式出奇地契合了真实的供应链工作流。

A2A 生命周期

该协议围绕三个可预测的操作展开：

1. run

使用结构化输入启动任务。

{
  "task_input": { /* ... */ },
  "metadata": { /* ... */ }
}

返回一个 task_id。

2. status

允许调用方检查进度，尤其是针对长时运行或多步骤逻辑的情况。

{
  "task_id": "abc123",
  "status": "PENDING"
}

3. result

在任务完成后检索最终的结构化输出。

{
  "result": { /* ... */ },
  "evidence": { /* ... */ }
}

这种设计保持了接口的可预测性，同时允许每个单元根据需要表达内部逻辑——验证、多步骤推理、依赖扩展或风险计算。

为什么该模式在供应链系统中表现良好

1. 与真实工作流结构相吻合

供应链逻辑是一步步展开的。A2A 流程正是对这种方式的映射，而不是与之抗争。

2. 保持组件独立

负责分类的单元不需要了解关税逻辑，反之亦然。

3. 为开发者提供更清晰的集成方式

下游系统只调用它们需要的单元。没有人被迫采用单体 API。

4. 优雅支持长时运行的过程

一些任务——比如依赖图构建或大规模分析——本身就需要时间。

5. 提升透明度和可审计性

每个单元只有单一职责，并拥有明确定义的输出形状。

A2A 作为集成接口，而非编排层

一个重要的区别是：我们并未设计 A2A 来在内部编排代理。它是为外部系统提供的干净 集成接口，例如：

• 企业应用
• 合规引擎
• 采购分析
• 风险监控工具
• 内部数据管道

任何下游系统都可以调用它们需要的特定单元，而无需采用新平台。

何时使用 A2A 而非传统 API

当满足以下条件时，这种模式通常效果最佳：

• ✔ 任务是长时运行的
• ✔ 工作流跨越多个步骤
• ✔ 推理或验证必须透明
• ✔ 需要确定且结构化的结果
• ✔ 想要模块化能力而非单体

如果工作流真的只有单一步骤且瞬时完成，常规同步 API 更为合适。

想了解规范吗？

完整的 A2A 协议、模式定义以及集成示例已在此处记录：

👉

我们将继续在构建更多供应链情报组件的过程中完善此模式，也非常期待从处理类似问题的工程师那里获得反馈。如果你设计过类似的架构——或有长时运行或多步骤供应链工作流的经验——欢迎分享你的做法。