Strabo：智能体交互协议的声明式规范与实现

# Strabo：智能体交互协议的声明式规范与实现

来源：https://arxiv.org/html/2606.05043

11机构：北卡罗来纳州立大学 11邮箱：\{schrist, singh\}@ncsu.edu 22机构：兰卡斯特大学 22邮箱：[email protected]

###### 摘要

过去几年，基于声明式交互协议的多智能体系统在建模与实现方面取得了重大进展。我们的贡献——Strabo——旨在确立这些进展与当前业界在智能体 AI 领域努力的相关性。具体而言，我们考察了由 Google 主导的 UCP（*通用商业协议*）——一项旨在为 AI 智能体标准化电子商务交互的近期工作。本练习分为两个部分。其一，我们将 UCP 中涉及结账的部分建模为声明式 Langshaw 协议，并使用 Peach（一种面向 Langshaw 的编程模型）实现智能体。这部分练习彰显了形式化、声明式规范的优势。其二，我们展示了 Peach 智能体能够与 Google 实现的 UCP 智能体互操作，从而验证了我们的方法相对于 UCP 的保真度。这种互操作使声明式协议和智能体能够逐步引入传统环境，为 EMAS 理念在不要求全面更新的前提下影响实践指明了一条路径。

## 1 引言

交互协议对多智能体系统进行建模，并作为智能体工程的蓝图。近期工作（以 BSPL\[13,14,15\] 和 Langshaw\[16\] 为代表）强调了用于规范协议的形式化、声明式方法。形式化规范使得在实现任何智能体之前即可验证协议的正确性。声明式规范能更好地反映利益相关者对交互含义的直觉\[12\]，从而支持智能体之间更灵活的交互。基于声明式协议实现智能体的编程模型\[8,9,3,5\]有助于改善代码结构，并更好地应对不断变化的需求。协议是概念性抽象。不对其进行规范，并不意味着不需要实现它们。只是在缺乏显式协议的情况下，开发者最终会将相关交互约束直接编码在低层代码中，这既繁琐，又会隐藏假设和错误。

智能体 AI 范式与协议领域的进展并行涌现。其核心价值主张是：基于 LLM 的智能体将代表用户处理各类任务。其中许多任务将涉及与其他用户的智能体交互，例如购物、预订旅行等。这一认识催生了大量旨在标准化 LLM 智能体之间交互的业界努力。其中较为突出的包括：Google 主导的通用商业协议（UCP）\[17\]，用于标准化结账和订单处理等电子商务交互；以及 Agent2Agent（A2A）协议\[1\]，提供一个通用的智能体间任务委托框架。这些协议以 JSON schema、散文描述和 HTTP 示例追踪等非正式方式进行规范。

*贡献。*我们的目标是确立"学术性"声明式方法在"实用性"场景中的相关性。为此，我们贡献了 *Strabo*——一种在 Langshaw 中利用声明式协议的通用方法，适用于通过 JSON-RPC 或 REST API 调用对协议建模的业界努力。该方法包含两个组成部分：（1）将业界工作映射为 Langshaw 协议，并使用 Peach\[5\]（一种面向 Langshaw 的编程模型）实现智能体；（2）创建一个桥接层，使 Peach 智能体能够与业界智能体互操作，从而演示与基于传统方法构建的遗留智能体的互操作性。

我们通过将 UCP 的 Checkout 能力建模为 Langshaw 协议，并实现 Peach 智能体来执行该协议，来阐释 Strabo。我们展示了这些 Peach 智能体与 UCP 代码仓库¹中提供的示例智能体的互操作性，以验证 Langshaw 协议相对于 UCP 的保真度。

¹UCP 示例代码见 https://github.com/Universal-Commerce-Protocol/samples

这一练习表明，形式化、声明式协议可直接应用于业界工作。UCP 是非正式规范的，留有诸多重要方面的歧义，而 UCP 的 Langshaw 模型则以形式化方式规范了交互约束，在保持实际互操作性的同时带来了精确性。我们的练习还揭示了 UCP 中隐含的假设，并发现了 Langshaw 和 Peach 所需的增强之处。

## 2 UCP、Langshaw 与 Peach 背景介绍

我们现在描述本文所依托的现有方法。

### 2.1 UCP——通用商业协议

UCP 处理涉及 Platform（客户）、Business（商家）、Credential Provider（数字钱包）和 Payment Provider（如 PayPal 和 Stripe）角色的电子商务交互。其理念是：Platform 作为购物者的代表，与 Business 进行购物，并使用 Credential Provider 生成支付令牌，由 Business 向 Payment Provider 兑换。

典型的 UCP 交互流程如下：Platform 和 Business 均发布列出其能力的 UCP 配置文件。能力是电子商务交互中涉及的广泛活动，例如 Checkout、Order 和 Identity Linking（用于计算忠诚度奖励等）。能力可以扩展。例如，Fulfillment 扩展 Checkout 以支持实物商品的配送。Business 根据自身配置文件和 Platform 的配置文件判断双方是否可以互操作。

#### 2.1.1 能力

能力由 JSON schema 定义。表 1 列出了 Checkout 能力的部分字段（完整 schema 见附录 A）。

表 1：Checkout 能力（摘自 \[17\]）。

#### 2.1.2 操作

对 Checkout 能力实例的所有操作——即 Create、Get、Update、Complete 和 Cancel——均由 Platform 执行。每个操作指定由必填字段和可选字段组成的输入和输出 schema。输出 schema 指定 Business 在响应中返回的 Checkout 实例。Business 在 Update 中根据输入重新计算实例。清单 1 和清单 2 展示了 Create 操作及其（截断的）响应，与 UCP 文档略有差异。

清单 1：Create 操作。
```
POST /checkout-sessions HTTP/1.1

{"line_items":[
{"item":{
"id":"item_123",
"title":"Red T-Shirt",
"price":2500},
"id":"li_1","quantity":2}]}
```

清单 2：清单 1 的响应（截断）。
```
HTTP/1.1 201 Created

{
"id":"chk_1234567890",
"status":"incomplete",
"messages":[{"type":"error","code":"missing",
"path":"$.buyer.email",
"content":"Buyer email is required"}],
"currency":"USD",
"totals":[{"type":"subtotal","amount":5000},
{"type":"tax","amount":400},
{"type":"total","amount":5400}],
"payment":{"instruments":[]},
"line_items":[],"links":[]
}
```

响应表明买家的电子邮件缺失。Platform 通过 Update（`PUT /checkout-sessions/{id}`）解决此异常，提供 `buyer` 字段，以及可选的 `fulfillment` 字段；Business 重新计算并返回完整实例。一旦实例状态达到 `ready_for_complete`，Platform 即发送携带支付工具数据的 Complete（`POST /checkout-sessions/{id}/complete`）。

### 2.2 Langshaw

Langshaw\[16\] 是一种用于规范多智能体交互的声明式协议语言。我们通过清单 3 中的结账协议来说明其概念，并将在第 3 节中详细讨论。

Langshaw 协议定义了*谁*参与交互（角色）、什么构成完整的执行，以及*他们做什么*（带属性的动作）。`who` 子句命名角色——在我们的示例中为 Platform 和 Business。`do` 子句列出动作，每个动作由特定角色执行并带有若干属性。例如，Create 由 Platform 执行，携带 `line_items` 和 `buyer` 等属性。

某些属性被指定为*键（key）*。键将动作关联为*执行实例（enactment）*，即协议实例。协议在其 `what` 子句中声明一个或多个属性为键；携带相同键值的所有动作属于同一执行实例。在 SimpleUCP 中，`cid` 是唯一的键，因此共享同一 `cid` 值的所有动作构成一个结账会话。

在给定执行实例中，一个属性只能绑定一次；一旦绑定，便不可变。执行动作时，每个参数要么重用现有绑定，要么生成新绑定。动作名称本身在动作发生时作为属性绑定，因此引用另一动作名称的动作依赖于该动作已发生。例如，Created 引用 Create，建立因果依赖：Created 只能在 Create 之后发生。

`sayso` 子句分配数据所有权——哪个角色可以绑定哪些属性。在最简单的情况下，一个 sayso 条目赋予某角色对某属性的绝对所有权：只有该角色可以产生其绑定。然而，sayso 条目也可以指定角色之间的优先级排序，允许受控的属性共享，其中一个角色的绑定优先于另一个角色。`nono` 子句声明互斥（例如，Completed 和 Cancelled 不能同时出现在同一执行实例中），`nogo` 子句声明方向性排除（例如，一旦 Cancel 发生，Complete 就被阻止，但反之不然）。`what` 子句还指定完成目标：哪些动作必须发生才能认为执行实例完成。

### 2.3 Peach

Peach\[5\] 是一种用于构建参与 Langshaw 协议的智能体的编程模型。开发者通过指定协议、智能体扮演的角色以及处理通信和底层状态模型的执行器来实例化 `PeachAdapter`（我们的工具）。适配器实现协议的语义：追踪给定执行实例当前状态下哪些动作是可行的，执行 sayso 和因果依赖，并管理键关联。开发者在此适配器之上构建智能体逻辑，而无需在应用代码中重新实现协议约束。

适配器暴露一个小型 API。关键是，`adapter.enabled()` 根据执行实例状态返回智能体当前可执行的动作。开发者选择一个动作，通过 `FeasibleAction.bind()` 绑定其属性值，并通过 `adapter.attempt()` 提交结果，后者返回一个 Promise。该 Promise 在动作完成时 resolve，若动作失败（例如由于并发动作冲突）则 reject，允许开发者显式处理失败。为响应其他智能体的动作，开发者使用 `@adapter.observation` 装饰器注册观察处理器。当协议的完成目标满足时，`@adapter.on_completion` 处理器触发。无论使用何种执行器，此 API 保持不变：Peach 目前支持连接到提供共享状态的 `SyncServer` 的同步执行器（具有即时或批量最终化），以及基于直接消息传递的异步执行器。

Peach 的一个关键方面是其基于使能（enablement-based）的编程模型（源自 BSPL\[13\] 和 Kiko\[9\]）。开发者无需在每次事件后判断哪些动作有效——查阅协议规范并在事件处理器中编码操作逻辑——适配器直接计算当前可行动作集合并呈现给开发者。开发者（或原则上操作智能体的 LLM）只需从已使能的动作中选择并提供绑定。这将协议合规的负担完全转移给适配器：开发者做出领域决策，而非协议决策。

在操作层面，每个适配器根据协议和执行实例的当前状态计算已使能的动作，Peach MAS 内的并发尝试在 SyncServer 处根据其配置的最终化策略（即时或批量）进行协调。由于关联基于键，参与重叠执行实例的智能体不会相互干扰；每个执行实例的状态是独立的。形式操作语义见\[5\]。

## 3 在 Langshaw 中建模 UCP

将 UCP 的 Checkout 能力在 Langshaw 中表达，存在多种可能的方式。我们这里聚焦于一种*原子*变体，它捕获最简单的完整结账：所有信息在单个动作中提交，揭示了基本的数据依赖关系和完成条件。将更新分解为独立动作、使数据流和权限显式化的*增量*变体见附录 C。我们的练习揭示了 UCP 隐含的若干假设。

### 3.1 深入了解 UCP Checkout

我们对 UCP 作如下说明。

1. **R1** 每个 Checkout 实例具有唯一标识符。实例被视为*会话*。Create 操作不携带实例标识符，它在响应中生成。
2. **R2** 某些字段（如 `id`）是原子的，而另一些字段（如 `line_items`）是复合的。
3. **R3** 某些字段（如 `line_items`）在实例中是*必填*的；其他字段（如 `buyer`）是可选的。操作的响应可能进一步将某些可选字段（如 Complete 响应中的 `order`）指定为必填。
4. **R4** 更新可以是部分的，可能会覆盖已有信息。
5. **R5** 操作在概念上具有请求-响应性质，从其输入-输出式规范中可以明显看出。
6. **R6** UCP 隐含地假设操作采用同步模型。具体而言，Platform 只能在上一个操作返回响应后，才能对同一实例发出下一个操作。否则，Platform 和 Business 可能对实例有不兼容的视图。举例来说，假设 Platform 对某实例执行 Update，在收到响应之前又对其执行 Complete。现在，如果 Business 在 Update 之前处理了 Complete（可能是因为 Update 在网络中被延迟），那么所下的 `order` 可能不能反映 Platform 的意图。

### 3.2 Langshaw 中的 UCP

清单 3 给出了 SimpleUCP——一个在 Langshaw 中捕获 UCP 结账的协议……