商业交互域

范围

本域定位

商业交互域（Commerce Interaction Domain, CID）规定智能体与商户、商户侧智能体或其他智能体之间，在支付执行前围绕商品或服务发现、意图上下文传递、支付能力对齐和交易确认所遵循的交互规则，为智能体商业中的支付前阶段提供统一、可引用、可衔接的商业交互语义。

本域职责范围

本域覆盖以下内容：

商品与服务发现结果的最低信息要求；
意图上下文的组织、传递与候选结果返回；
支付能力声明、能力确认与能力协商；
购物车确认、规则前置检验及交易确认结果；
支付前商业共识形成所需的关键对象、状态语义和跨域引用关系。

本域不规范以下内容：

智能体内部决策算法、排序策略、偏好推断及模型推理过程；
商户内部经营处理、库存扣减、订单管理和履约系统实现；
通用多智能体协作协议、任务编排与服务发现协议；

本域组件列表与关系

组件总览

商业交互域由四个协议组件构成，它们共同完成从商品或服务发现、意图上下文传递与支付前能力协商，到交易确认完成并进入支付阶段的完整链路。

各组件的功能定位如下。

CID-MER-CAT：商品与服务目录接口。 负责规范商户向智能体开放结构化商品或服务目录时的最低信息要求，以支持机器可读的商品或服务发现。
CID-INT-XFR ：意图上下文传递。 负责规范买方智能体向商户或平台传递与当前任务相关的意图上下文，并接收候选商品或服务结果的请求/响应过程。
CID-PCA-NEG：支付能力协商。 负责规范买卖双方在支付前对可用支付方式、支付服务方、接口端点及相关载荷模式进行能力声明与协商的过程。
CID-CART-CFM：购物车确认。 负责规范买方智能体在进入支付流程前，对交易标的、金额、履约条件及相关约束执行最终确认和规则前置检验的过程。

核心对象与标识

为保持本域内部处理以及与其他域之间引用关系的一致性，商业交互域使用一组标准核心对象和标识来描述支付前阶段的关键信息。本域核心对象及其作用可概括如下。

对象或标识	含义	主要产生位置	主要使用位置
意图上下文	买方智能体围绕当前任务构造的结构化意图信息，承载需求、约束和必要背景，并作为商品筛选、匹配和交易确认的上游输入	ADD-INT-ICS，必要时也可由买方智能体基于上游意图对象在本地构造	CID-INT-XFR、CID-CART-CFM，以及商户或平台的候选匹配过程
候选商品或服务结果	商户、平台或卖方智能体返回的结构化候选结果，用于买方智能体执行筛选、比较和后续规则前置检验	CID-MER-CAT、CID-INT-XFR	CID-CART-CFM，以及买方智能体本地决策过程
交易确认结果	购物车确认阶段形成的订单级最终确认结果，通常包括交易标的、金额、商户标识、订单交易号及相关确认时间信息	CID-CART-CFM	支付服务域，以及可信存证与事后争议处理支持环节
支付能力协商结果	买卖双方就可用支付方式、支付服务方、接口端点及方法模式形成的一致结果	CID-PCA-NEG	后续支付服务域的支付请求构造与执行

依赖与跨域引用

CID-MER-CAT 和 CID-INT-XFR 都可作为候选商品或服务结果的上游来源，为后续购物车确认提供输入。

CID-PCA-NEG 的作用主要发生在支付前衔接阶段，用于在需要时确定本次交易所采用的支付方式、支付服务方和接口端点，从而为后续支付请求构造提供依据。

CID-CART-CFM 是本域中承接前序发现、筛选、协商结果并形成订单级最终确认的关键组件，其输出结果将直接影响后续支付服务域是否能够发起支付执行。

委托授权域主要向本域提供 ISR 及相关约束上下文；支付服务域主要引用本域形成的交易确认结果、订单交易号、支付能力协商结果；信任服务域统一维护相关事件类型和存证治理规则，本域不重复定义。

CID-MER-CAT：商品与服务目录接口

概述

商品与服务目录接口（Catalog Interface，CID-MER-CAT）规定商户向智能体开放结构化商品或服务目录时的最低信息要求，以支持机器可读的商品或服务发现。本组件输出的候选商品或服务结果，可作为买方智能体后续比较决策和购物车确认的上游输入。

本组件当前版本暂时不定义统一的目录协议，而是规定目录结果在进入后续商业交互前应满足的最低信息要求。

本组件不规范目录检索排序逻辑、推荐算法、商户内部商品建模方式，以及库存扣减、价格计算和订单履约等商户内部处理。

参与方与前置条件

本组件涉及以下参与方：提供商品或服务信息的商户或平台，以及发起目录访问并消费返回结果的买方智能体。

进入本组件前，应满足以下前置条件。

商户或平台已具备对外提供结构化商品或服务信息的能力。
买方智能体已建立与当前任务相关的基本商业上下文，并能够对返回结果进行本地筛选、比较或后续确认处理。
当后续链路需要依据用户意图与约束执行规则检验时，买方智能体应能够将目录返回结果与委托授权域提供的相关意图上下文相衔接。

最低返回信息要求

商户侧返回的商品或服务目录数据应满足最低信息可用性要求，以确保后续商业交互和支付前确认能够正常开展。

对于每一条可供买方智能体消费的商品或服务明细，返回结果应包含以下信息。

商品或服务标识，应为全局唯一或在商户域内可唯一解析的标识。
商品名称或服务名称，应能够支持买方智能体和后续处理环节识别交易标的。
商品类目或服务类别，应能够支持后续与用户意图约束进行匹配。
明确的标价及货币单位，应能够支撑金额比较、规则前置检验和支付前确认。

除上述最低必备信息外，商户侧返回结果宜进一步包含以下信息。

当前库存状态、可售状态或服务可用状态。
价格有效截止时间或报价更新时间。
预计配送时间、履约时效或服务交付时间。
商户标识、商户引用地址或商品详情引用地址。

当目录结果无法满足最低信息要求时，买方智能体不宜直接将该结果用于购物车确认或支付前衔接。当返回结果仅适用于展示而不足以支持规则前置检验时，实现方宜在进入 CID-CART-CFM 前补充获取必要字段。

ACT 当前版本暂不对目录接口的调用路径、请求方法、认证机制和分页方式作统一规定。

兼容性说明

实现方可结合现有行业协议、商户开放接口或平台既有目录服务完成对接，只要其返回结果能够满足本组件规定的最低信息要求即可。

CID-INT-XFR：意图上下文传递

概述

意图上下文传递（Intent Context Transfer，CID-INT-XFR）规定买方智能体向商户或平台传递与当前任务相关的意图上下文，并接收候选商品或服务结果的请求/响应过程。本组件使用的意图上下文可引用委托授权域形成的 ISR 及相关约束语义，并作为后续候选筛选、规则前置检验和购物车确认的上游输入。

本组件处理的是支付前阶段的意图传递与候选匹配，不规范买方智能体内部的意图理解、偏好推断和决策算法。

参与方与前置条件

本组件涉及以下参与方：发起意图请求的买方智能体，以及接收请求并返回候选结果的商户、平台或其代理接口。

进入本组件前，应满足以下前置条件。

买方智能体已建立与当前任务相关的基本商业上下文，并能够构造可传递的意图上下文。
商户或平台已具备接收意图请求并返回结构化候选结果的能力。
当后续链路需要依据用户目标与约束执行规则检验时，买方智能体应能够将意图上下文与委托授权域提供的相关约束语义相衔接。

意图上下文构成

买方智能体传递的意图上下文应围绕当前任务组织，并能够支持商户或平台开展候选匹配。意图上下文通常包括以下内容。

显式意图需求，即用户明确表达的购买目标或服务需求。
隐式意图需求，即买方智能体基于当前任务上下文、用户已确认信息或连续交互内容归纳形成的补充需求。
约束条件，即与本次任务相关的金额、类目、商户、履约时效等边界信息。
必要背景信息，即为完成候选匹配所需的补充上下文。
经实现方允许且在适用条件下可传递的偏好信息。

显式意图需求和约束条件宜作为意图上下文的主要组成部分。隐式意图需求和偏好信息可作为可选信息传递，不应与用户已明确确认的约束条件或委托授权域形成的 ISR/IAC 所表达的授权边界相冲突。

当传递隐式意图需求或偏好信息时，实现方应自行处理相关的知情同意与数据保护要求。

请求与响应要求

买方智能体发起意图请求时，应构造可被商户或平台解析的请求报文。请求报文宜包含以下关键要素。

请求标识，用于唯一标识本次请求并支持响应关联。
与当前任务相关的意图上下文。
在需要跨域关联时使用的关联标识。
必要的约束条件和响应格式要求。
请求来源认证信息。

商户或平台返回的响应报文应能够与原请求建立对应关系。响应结果至少应包含可供后续筛选和确认使用的候选商品或服务明细。当商户或平台无法返回有效候选结果时，应返回错误响应，并给出可被买方智能体识别的错误语义。

动态更新与错误语义

买方智能体应支持在多轮交互中对意图上下文进行动态更新。每次动态更新应生成新的请求标识，并与前序请求建立关联。动态更新请求宜仅携带本次发生变化的意图内容。

当商户或平台无法正常处理请求时，错误语义宜覆盖格式错误、无匹配结果、访问受限、约束冲突和请求过频等类别。买方智能体可根据错误类型决定重试、切换商户、调整请求或通知用户。

多商户路由

在实际商业网络中，买方智能体可同时向多个商户或平台并发发送意图请求，并汇总各方返回的候选结果。候选结果的比较与最终决策属于买方智能体本地处理过程，不属于本组件规范范围。

注：在需要记录关键商业节点时，实现方可在决策完成后引用 act:commerce:decision-logged 事件标识开展后续存证处理。

CID-PCA-NEG：支付能力协商

概述

支付能力协商（Payment Capability Negotiation，CID-PCA-NEG）规定在需要进入支付执行前，买卖双方就可用支付方式、支付服务方、接口端点及相关载荷模式进行能力声明与协商的过程。

本组件主要适用于卖方智能体参与的多智能体商业交互场景，也可用于其他需要在支付前完成支付能力对齐的场景。本组件输出的支付能力协商结果，可作为后续支付服务域构造支付请求和选择支付路径的输入。

本组件不定义通用的服务发现、消息交换、任务编排与协作交互协议，而仅规范支付前衔接所需的支付能力声明与支付能力协商语义。

参与方与前置条件

本组件涉及以下参与方：发起支付能力协商的买方智能体，以及对外声明支付能力并返回协商结果的商户、卖方智能体或其代理接口。

进入本组件前，应满足以下前置条件。

买卖双方已经形成可进入支付前衔接阶段的基本商业上下文。
买方智能体已能够识别本次交易的金额、币种、交易对象及其他必要交易参数。
卖方一侧已具备对外发布支付能力声明或响应支付能力协商请求的能力。
当本次交易受用户意图或授权边界约束时，买方智能体应能够依据相关约束语义判断候选支付方式是否可用。

支付能力声明

声明模式

卖方一侧可通过标准化路径对外公开其支付能力声明。在卖方智能体场景下，支付能力声明可通过其 Agent Card 中的 capabilities 节点进行发布，并声明本方支持的协商模式及对应接口地址。当实现方支持独立的支付能力声明文件时，也可在约定地址发布 act-payment-capability.json 文件。

支付能力声明应能够表达以下信息。

本方支持的协商模式。
本方支持的支付方式列表。
每种支付方式对应的支付服务方标识。
每种支付方式对应的支付接口端点。
每种支付方式对应的载荷模式或载荷结构说明。

当卖方一侧支持单向声明模式时，其公开能力描述中应能够提供 capability_url 或等价能力声明入口，其 Agent Card 示例如下：

{
  "agent_id": "did:act:alipay.com/agent-alice-001",
  "capabilities": {
    "act:payment:negotiation": {
      "mode": "one-way",
      "capability_url": "https://merchant.com/.well-known/act-payment-capability.json"
    }
  }
}

当卖方一侧支持双向协商模式时，其公开能力描述中应能够提供 negotiation_endpoint 或等价协商接口入口，其 Agent Card 示例如下：

{
  "agent_id": "did:act:enterprise.com/premiumbot-02",
  "capabilities": {
    "act:payment:negotiation": {
      "mode": "two-way",
      "negotiation_endpoint": "https://api.enterprise.com/act/payment/negotiate"
    }
  }
}

单向声明模式

单向声明模式适用于卖方一侧已完整公开支付能力声明，买方智能体可直接读取而无需额外协商交互的场景。在该模式下，买方智能体应读取卖方一侧公开的支付能力声明，并从 supported_methods 中筛选出与本次交易条件相匹配的候选支付方式。

当买方智能体存在来自上游意图或授权边界的支付方式约束时，应仅从满足相关约束的候选支付方式中进行选择。

买方智能体在完成筛选后，应提取所选支付方式对应的 method_id、psp_id、endpoint 和 method_schema_url，作为后续支付请求构造输入。

若公开声明中不存在可用的匹配支付方式，买方智能体不应继续进入支付阶段。

支付能力文件（act-payment-capability.json）的格式示例如下：

{
  "version": "1.0",
  "role": "payee",
  "agent_id": "did:act:merchant.com/servicebot-01",
  "supported_methods": [
    {
      "method_id": "urn:act:payment:alipay",
      "psps": [
        {
          "psp_id": "urn:act:psp:alipay-official",
          "endpoint": "https://openapi.alipay.com/act-psp/v1",
          "method_schema_url": "https://alipay.com/act/schemas/payment-payload.json"
        }
      ]
    }
  ]
}

双向协商模式

双向协商模式适用于卖方一侧需要根据买方请求上下文动态匹配支付方式的场景。在该模式下，买方智能体应向卖方一侧声明的 negotiation_endpoint 发起协商请求。

该请求宜至少包含以下要素。

agent_id，用于标识发起协商的买方智能体。
buyer_supported_methods，用于声明买方当前可接受的支付方式列表。
currency，用于声明本次交易使用的币种。
estimated_amount，用于声明本次交易的预估金额。

卖方一侧收到请求后，应返回与当前交易条件相匹配的支付能力结果。响应结果中的 supported_methods 宜至少包含以下要素。

method_id，用于标识匹配成功的支付方式。
psp_id，用于标识该支付方式对应的支付服务方。
endpoint，用于标识后续支付请求的目标接口地址。
method_schema_url，用于标识该支付方式对应的支付载荷结构说明。

当 supported_methods 为空时，应视为双方未能完成支付能力对齐。在该情况下，买方智能体不应继续进入支付阶段，并应根据业务策略决定是否更换支付方式、更换交易对手或终止本次交易。

示例如下：

第一步（买方发起）：买方智能体向卖方智能体声明的negotiation_endpoint 发送 HTTP POST 请求，请求体包含买方支持的支付方式列表、意图品类、货币及预估金额：

{
  "agent_id": "did:act:platform.com/agent-alice-001",
  "buyer_supported_methods": ["urn:act:payment:alipay", "urn:act:payment:credit_card"],
  "amount_currency": "CNY",
  "estimated_amount": 500.00
}

第二步（卖方响应）：卖方智能体返回匹配的支付方式及对应的 PSP 信息：

{
  "supported_methods": [
    {
      "method_id": "urn:act:payment:alipay",
      "psp_id": "urn:act:psp:alipay-official",
      "endpoint": "https://openapi.alipay.com/act-psp/v1",
      "method_schema_url": "https://alipay.com/act/schemas/payment-payload.json"
    }
  ]
}

若响应中 matched_methods 为空，则表示双方无可用的共同支付方式，本次交易无法继续，买方智能体应中止流程并向委托人反馈。

协商结果

支付能力协商的最终输出，为一组可供后续支付使用的能力对齐结果。该结果至少应能够明确 method_id、psp_id、endpoint 和 method_schema_url 四项参数。

当存在多个可选结果时，具体选择逻辑由买方智能体本地处理，本组件不作规定。

安全考虑

买方智能体在使用支付能力声明（act-payment-capability.json）前，应对其来源进行校验，并确认该声明系由商家已声明的能力地址（capability_url）发布。

买方智能体在解析 supported_methods 时，宜对其中的 method_id、psp_id、endpoint、method_schema_url 等字段进行一致性检查，避免因能力声明被伪造、篡改或替换而误接入非预期支付服务方。

对于来源无法确认或关键字段校验失败的支付能力声明，买方智能体不得继续使用其发起后续支付能力匹配或支付流程。

CID-CART-CFM：购物车确认

概述

购物车确认（Cart Confirmation，CID-CART-CFM）规定买方智能体在进入支付流程前，对本次交易标的、金额、履约条件及相关约束执行最终确认的处理要求。

本组件承担支付前阶段的订单级确认职责，用于将前序商品或服务发现、候选筛选、条件匹配及支付能力对齐结果固化为可进入支付执行的交易确认结果。

本组件不规范买方智能体内部的候选比较算法、排序策略和决策逻辑，也不规范商户内部的订单管理、库存扣减和履约系统实现。

参与方与前置条件

本组件涉及以下参与方：发起交易确认的买方智能体，以及接收确认请求并生成订单级结果的商户、平台、卖方智能体或其代理接口。

进入本组件前，应满足以下前置条件。

买方智能体已获取可供确认的商品或服务候选结果。
本次交易的标的、金额、币种及必要履约信息已经能够被明确识别。
当本次交易受用户目标、约束或授权边界控制时，买方智能体已能够引用委托授权域提供的相关意图与约束语义。

规则前置检验

在正式向交易对手提交购物车确认并获取订单交易号之前，买方智能体应依据当前任务相关的意图与约束信息，对本次拟确认交易执行规则前置检验。当本次交易涉及委托支付时，买方智能体应进一步结合委托授权域提供的授权边界语义开展校验。

规则前置检验宜覆盖以下维度。

金额检验，包括单笔金额是否超出允许范围，以及在存在累计约束时是否超出累计额度边界。
类目范围检验，即拟购买商品或服务是否符合允许类目或未触发禁止类目限制。
商户范围检验，即交易对手是否符合允许商户范围或未触发禁止商户限制。
履约时效检验，即预计配送、交付或服务履约时间是否满足既定要求。
价格容差检验，即最终确认价格是否落在允许的价格波动范围内。

当实现方存在其他与业务相关的必要校验项时，也可在上述基础上增加补充检验，但不应削弱本组件定义的基本校验语义。

检验未通过时的处理

当任一规则前置检验未通过时，买方智能体不应直接进入支付阶段。

若相关意图或授权边界中已预设越界处理策略，买方智能体应按照该策略执行。
若越界处理策略为暂停并通知，买方智能体应中止当前确认流程，并等待用户重新确认或调整约束。
若越界处理策略为自动取消，买方智能体应终止本次商业交互，并记录取消原因。
若未预设明确的越界处理策略，买方智能体宜默认采用暂停并通知的处理方式。

提交锁定与订单生成

当规则前置检验通过后，买方智能体可向交易对手提交购物车确认请求。确认请求宜至少包括本次拟确认的商品或服务明细、最终价格、币种、履约要求以及必要的关联上下文。

交易对手在接受确认请求后，应对相关价格、库存或服务能力执行订单级锁定，并生成订单交易号返回给买方智能体。交易对手返回的订单交易号应能够在后续支付执行阶段被稳定引用。

当交易对手无法完成订单级锁定时，应返回明确的失败结果或错误语义，买方智能体不应将该次确认视为成功。

交易确认结果

购物车确认完成后，买方智能体应形成交易确认结果。

交易确认结果宜至少包括以下内容。

已确认的商品或服务明细。
最终确认金额及币种。
交易对手标识。
订单交易号。
确认时间信息。
在需要跨域关联时使用的关联标识。

注：在需要记录关键商业节点时，实现方可在购物车确认完成后引用 act:commerce:cart-confirmed 事件标识开展后续存证处理。