当 Agent 成为交易主体：从授权、身份到 A2A 支付的信任基建

技术教程2026-09-22约 18 分钟AI AgentAgent交易信任基建授权KYAA2A支付安全沙箱

我们已经习惯让 AI 回答问题、总结资料、生成代码，也开始让它替我们订餐、打车、选商品和安排日程。下一步更大的变化是：Agent 不再只是给人建议，而是代表人发起真实交易。

这会把问题从“模型是否足够聪明”推进到一组更难的系统问题：

这笔交易是不是用户真正授权的？
发起交易的 Agent 到底是谁？它代表谁、服务谁？
Agent 可以花多少钱、买什么、在什么时间内行动？
用户如何在执行前看到将要发生的事情？
交易出错后，平台、商户、模型提供方和 Agent 运营者谁负责？
两个 Agent 之间进行大量小额交易时，支付网络如何确认身份、结算和处理争议？

《外滩大会线下圆桌｜敢把钱包交给AI吗？聊聊Agent交易爆发前夜的信任基建》正是围绕这些问题展开。节目来自 2026 Inclusion·外滩大会主论坛“当 Agent 成为交易主体”圆桌，参与嘉宾包括蚂蚁集团 CEO 韩歆毅、万事达卡首席产品官 Jorn Lambert、OPPO 高级副总裁兼首席产品官刘作虎、阿里巴巴集团首席科学家周靖人，由硅谷 101 创始人、播客主理人泓君主持。

本文根据 YouTube 页面公开的简介、章节和可见信息整理，不是完整逐字稿。文中对嘉宾观点的描述以章节主题和节目简介能够支持的范围为限；后半部分的系统架构、权限模型和工程检查表，是本文为了方便落地而补充的分析，不代表嘉宾的逐句原话或某家公司的正式技术方案。

一、Agent 交易有两条线：替人办事，以及 Agent 之间协作

节目简介把 AI 交易概括成两条同时展开的路线。

第一条是 Agent-to-Human：Agent 代表人完成任务。用户说“帮我订一杯适合下午的咖啡”，Agent 需要理解偏好、比较选项、确定门店、选择支付方式，最后完成下单。

第二条是 Agent-to-Agent（A2A）：一个 Agent 与另一个 Agent 或机器服务交互。比如采购 Agent 向供应商 Agent 询价，库存 Agent 与物流 Agent 协调，内容 Agent 向数据服务 Agent 购买一次查询，软件 Agent 为计算资源或 API 调用支付费用。

两条路线看起来不同，但最终都会进入同一条链路：

自然语言意图
  → Agent 规划任务
  → 发现可用服务或商品
  → 代表用户发起请求
  → 授权与风险检查
  → 支付、交付与记录
  → 处理异常、退款或争议

当 Agent 只提供建议时，错误通常还停留在信息层；当 Agent 可以直接下单、扣款或调用有成本的服务时，错误就会进入资金、合同、隐私和责任层。

因此，“让 Agent 能交易”不是给聊天机器人增加一个支付按钮，而是要重新设计从身份到结算的完整边界。

二、“先有鸡还是先有蛋”：智能体商业为什么容易卡住

节目章节从“先有鸡还是先有蛋”切入 Agent 商业。这个问题的本质是双边网络的冷启动：

没有足够多的用户和真实意图，商户没有动力为 Agent 优化商品、接口和履约。
没有足够多的可调用服务、可信商品和稳定支付能力，用户也没有理由把任务交给 Agent。

传统应用可以先通过一个中心化产品积累用户，再逐步接入服务。但 Agent 交易更像一个多边市场，至少同时涉及：

参与方	关心的问题
用户	Agent 会不会越权、买错、泄露偏好或花错钱？
用户侧 Agent	如何理解意图、比较选项并在权限范围内行动？
商户 / 服务方	如何识别真实请求、报价、履约和收款？
支付网络	如何认证主体、授权资金、清算交易并处理争议？
平台与设备方	如何提供身份、权限、风控和用户体验？
监管与审计方	出问题时如何追责、留证和执行规则？

这也解释了为什么“先把模型能力做出来，再补交易基础设施”可能走不通。对于交易型 Agent，信任不是后置模块，而是产品能否启动的前置条件。

三、当 Agent 开始交易，支付网络需要改变什么

人类支付通常围绕几个熟悉对象建立：持卡人、商户、收单方、发卡方、支付凭证和交易金额。Agent 进入链路后，还会多出一组机器身份和委托关系：

用户
  └── 授权给用户侧 Agent
        └── 请求商户侧 Agent / 服务接口
              └── 调用支付网络
                    └── 结算给商户或服务提供方

这条链路里至少要区分四种身份：

资金所有者：谁的钱被使用？
授权人：谁允许这一次或这一类交易发生？
执行主体：哪个 Agent 实际发起了请求？
受益与收款主体：谁提供商品或服务，谁最终收到钱？

如果系统只记录“某个 API Key 发起了支付”，它很难回答用户真正关心的追问：

这个 API Key 代表哪个 Agent？这个 Agent 依据什么用户意图行动？它是否超出了授权范围？

未来的支付记录可能需要同时携带：用户授权、Agent 身份、任务上下文、商品或服务标识、报价快照、权限策略、风险评估、执行结果和可验证收据。

支付不只是“扣款接口”

对交易 Agent 来说，支付能力至少包括：

发现支付方式与币种；
获得一次性或持续性授权；
限制金额、品类、商户、地区和时间窗口；
在支付前展示最终价格、费用和关键条件；
处理重复请求、超时、部分成功和网络重试；
生成用户可理解、机器可验证的交易收据；
支持退款、撤销、争议和责任追踪。

因此，A2A 支付网络不能只追求“更快地让机器互相扣款”，还必须让每次交易都能被解释、限制、核对和追责。

四、手机为什么可能成为意图入口和信任中枢

节目章节讨论了手机作为“意图入口”、个人智能和主动智能的可能性，也进一步追问未来二十年手机是否仍是核心设备。

手机的价值不只是屏幕和计算能力，它还集中拥有几类关键资源：

用户身份与设备绑定关系；
通知、确认和生物识别入口；
通讯录、日历、位置和使用习惯等个人上下文；
已经配置好的支付方式和安全设置；
用户可以随时看到并打断 Agent 的交互界面。

这使手机很适合成为 Agent 的“授权面板”：Agent 可以在后台理解和规划，但涉及金额、敏感数据、不可逆动作或高风险场景时，手机负责让用户确认、拒绝或调整权限。

不过，手机成为入口不等于所有智能都必须在手机上完成。更合理的分工可能是：

手机 / 可穿戴设备：身份、通知、确认、打断
云端 Agent：规划、检索、长期上下文和跨服务协作
商户 / 服务端：报价、库存、履约和订单状态
支付网络：授权、清算、风控、退款和争议处理

设备的核心竞争力可能从“谁的模型回答更快”转向“谁能让用户安全地把意图交给系统，并且随时收回控制权”。

五、模型还缺什么：长期上下文、提问能力与可靠执行

节目把模型距离可靠交易还缺什么归纳为几个方向，其中最重要的不是再增加一点语言流畅度，而是补上从意图到执行的中间能力。

1. 长期上下文

一次交易可能依赖用户长期偏好：饮食禁忌、预算上限、常用地址、家庭成员、差旅规则、过往投诉和商户黑名单。

但长期记忆不能等于“把所有历史对话都塞给模型”。系统需要区分：

用户明确保存的偏好；
从行为中推断出的暂时偏好；
只对当前任务有效的约束；
过期、冲突或未经确认的历史信息。

交易系统应优先使用可追溯、可撤销的偏好，并在高风险动作前重新确认关键条件。

2. 主动提问

一个只会猜的 Agent 很危险。真实任务经常存在无法从上下文推断的缺口：预算是多少、是否接受替代品、能否使用某种支付方式、什么时候必须送达、是否允许自动续费。

可靠 Agent 的表现不是“永远马上执行”，而是知道什么时候应该停下来问一个最小但关键的问题。

3. 可靠执行

模型输出一句“已经帮你订好了”不等于订单真的创建成功。可靠执行需要把计划和事实分开：

模型计划
  → 工具参数校验
  → 权限与风险检查
  → 服务端执行
  → 读取真实状态
  → 向用户报告结果

模型只能提出动作，不能自己宣布动作已经发生。订单号、价格、余额、支付结果和履约状态都必须由领域服务或支付系统返回。

六、信任基建的五个核心对象：授权、身份、KYA、资金安全、可追溯

视频在 16:00 章节明确把信任基建拆到授权、身份、KYA、资金安全和可追溯等问题。可以把它们进一步组织成五个工程对象。

1. 授权：用户允许 Agent 做什么

授权不应该只有“允许 / 拒绝”两个按钮，而应描述范围：

主体：哪个用户、哪个 Agent、哪个设备
动作：查询、推荐、预订、购买、退款、转账
对象：哪些商品、商户、账户、服务
限制：金额、频率、时间、地区、品类
条件：价格变化、库存变化、是否需要二次确认
有效期：一次性、任务期、固定时间或持续授权

例如，“帮我买一杯咖啡”不应该自动扩展成“以后所有饮料都可以自动购买”。任务授权与持续授权必须分开。

2. 身份：Agent 代表谁

Agent 的身份至少要包含可验证的主体、运行环境、能力范围和责任归属。匿名的“某个机器人”不适合直接承担高价值交易。

系统应能够回答：

Agent 由谁创建、运营或托管？
它使用哪个版本的策略和工具？
它是否代表个人、企业或另一个 Agent？
它的凭证是否可以撤销和轮换？
请求是否来自经过认证的运行环境？

3. KYA：Know Your Agent

KYA 可以理解为“了解你的 Agent”，对应传统金融和平台治理中对交易主体的识别思路。它不一定要求所有 Agent 都公开全部实现细节，但至少需要让交易对手知道：

这是哪个 Agent；
它具有什么能力和权限；
它的行为规则和限制是什么；
发生争议时由谁处理；
它是否通过了某种认证、风控或合规检查。

对于 A2A 交易，KYA 可能成为类似服务发现和信誉交换的基础层。没有可识别的 Agent 身份，机器之间的协作会退化成不可解释的自动请求洪水。

4. 资金安全：让最坏情况也有边界

资金安全的核心不是假设 Agent 永远正确，而是限制它出错时能造成的损失：

使用受限额度或专用钱包；
高风险动作需要用户确认；
按商户、品类和金额设定策略；
支持速率限制、冷却期和异常暂停；
将预授权与最终扣款分开；
允许随时撤销 Agent 的支付权限。

5. 可追溯：每一步都能还原

发生争议时，单独保存最终订单是不够的。至少需要保留：

用户意图
  → Agent 版本与上下文摘要
  → 可用选项与报价快照
  → 授权策略
  → 用户确认或自动授权依据
  → 工具调用与服务端响应
  → 支付收据与最终订单
  → 退款、取消或争议记录

日志不应该记录不必要的敏感内容，但必须保留足以解释和审计决策的证据。

七、能力信任与风险信任：手机厂商为什么关心 A2A 行为规范

节目从手机厂商视角讨论了“能力信任”和“风险信任”，并提到 A2A 行为规范。两者经常被混在一起，但实际是不同问题。

信任类型	用户想知道什么	系统要证明什么
能力信任	Agent 能不能完成任务？	服务是否可用、结果是否准确、履约是否稳定
风险信任	让它完成任务会不会伤害我？	权限是否受限、行为是否可追溯、出错后是否能补救

一个 Agent 可能能力很强，但风险边界不清；也可能非常安全，却无法完成任何有价值的任务。面向交易的产品必须同时提升两种信任：一方面让 Agent 真的能办事，另一方面让用户知道它不会在不可见的情况下扩大目标、权限或成本。

A2A 行为规范则需要让机器之间共享一套最低预期，例如：

明确声明身份、能力和收费方式；
说明请求的目的、范围和有效期；
不伪造用户授权，不隐藏额外费用；
对失败、拒绝、超时和部分成功返回结构化状态；
遵守重试、速率和幂等约束；
支持撤销、退款、争议和审计。

这类规范越早形成，后续的 Agent 市场就越不容易被大量不可解释、不可撤销、不可追责的自动调用占据。

八、“普拉提课测试”：为什么沙箱和预览比一句确认更重要

章节中提到“普拉提课测试”，并把讨论引向授权、沙箱与安全执行。这个例子可以抽象成一个常见场景：Agent 想替用户预约一次课程，但任务中有时间、地点、价格、退款政策和会员资格等多个变量。

如果系统只弹出一句“是否确认”，用户很难判断确认的到底是什么。更安全的做法是把交易分成几个阶段：

理解意图
  → 搜索与比较
  → 生成交易预览
  → 检查授权与风险
  → 沙箱 / 试运行
  → 用户确认
  → 正式执行
  → 回读真实状态

交易预览至少应显示：

商品或课程名称；
商户和地点；
最终价格、税费和服务费；
时间、数量和关键限制；
取消、退款或自动续费条款；
使用哪一个账户或支付方式；
Agent 哪些信息将被发送给商户。

沙箱的价值是让系统先模拟“如果执行会发生什么”，而不是在模型第一次生成计划时就触发真实副作用。对于可逆性差、金额高或涉及敏感数据的动作，预览和沙箱应该是默认路径。

一个最小的交易执行状态机

DRAFT
  → PREVIEWED
  → AUTHORIZED
  → EXECUTING
  → SUCCEEDED
        ↘ PARTIALLY_SUCCEEDED
        ↘ FAILED
        ↘ NEEDS_HUMAN_REVIEW

每次状态变化都需要有服务端事实支撑。不能因为模型生成了一个“成功”文本，就把交易状态直接标记为 SUCCEEDED。

九、700 亿 Agent 的商业想象，关键不在数量而在交易密度

视频章节提出了未来五年的“700 亿 Agent”商业想象。这里应当把它当作节目中的行业展望，而不是本文验证后的预测数字。

即使未来存在数量巨大的 Agent，商业价值也不会简单等于 Agent 数量。更重要的变量包括：

每个 Agent 的活跃频率；
每次任务调用的服务数量；
单次交易价值和平台费用；
用户是否愿意授予持续权限；
商户和服务是否提供机器可调用接口；
失败、争议和欺诈的处理成本。

这会带来新的基础设施机会：

机会方向	可能解决的问题
Agent 身份与认证	让交易对手知道请求来自谁
权限与策略引擎	限制金额、品类、时间与动作
Agent 服务目录	发现可信、可调用、可结算的服务
机器可读报价	让 Agent 比较价格、条款和履约能力
微支付与清算	支持大量低金额、高频率交易
交易审计与争议	还原授权依据并处理失败和退款
Agent 信誉系统	评价可靠性、履约、拒付和滥用行为

真正的基础设施壁垒可能来自这些跨平台的信任和结算能力，而不是某一个更会聊天的 Agent。

十、一杯咖啡怎么选出来：推荐系统也会变成交易入口

节目还用“一杯咖啡怎么选出来”讨论大模型推荐机制。这个问题看起来轻量，却代表了 Agent 交易里一个关键变化：模型不只是执行用户已经明确选好的商品，还可能参与“定义选择集”。

传统搜索通常给用户一页结果，用户自己比较；Agent 推荐则可能先根据上下文筛选，再直接给出一个或少数几个建议。如果推荐和下单紧密连接，就需要注意几个风险：

用户偏好是否被准确理解？
推荐结果是否受到佣金、广告或商户排序影响？
为什么推荐 A 而不是 B？
价格、距离、配送时间和质量之间如何权衡？
用户能否看到被过滤掉的关键选项？
Agent 是否因为追求“方便”而牺牲了用户真正重视的条件？

推荐型 Agent 至少应向用户解释影响结果的主要因素，而不是只输出一个看似确定的答案。涉及商业利益时，还应该明确标识推广、佣金和排序规则。

一个实用的推荐结果结构可以是：

推荐：A 店燕麦拿铁
主要原因：距离近、符合无乳糖偏好、预计 15 分钟送达
代价：比附近另一家贵 4 元
未满足条件：不是你最近评价最高的店
下一步：查看详情 / 换一家 / 直接下单

这类解释既方便用户纠正模型，也为后续争议提供决策依据。

十一、A2A 商业真正需要的，是海量微交易支付轨道

如果 Agent 之间开始频繁购买搜索、验证、计算、数据、物流和执行服务，单笔交易金额可能很小，但调用次数非常多。A2A 商业的支付系统需要面对和传统人工支付不同的约束：

高频率

一个 Agent 可能在几秒内调用多个服务。支付网络需要支持批量授权、额度管理、聚合结算和异常速率限制。

低金额

单笔金额太小会让固定支付手续费变得不划算，需要考虑预存余额、支付通道聚合、批量清算或其他成本结构。

机器可验证

双方不能依赖人工阅读长合同。报价、服务范围、SLA、失败退款和结算条件都需要有结构化表达。

可重试但不能重复扣款

网络超时会导致 Agent 重试。每次支付和服务调用都需要幂等键、状态查询和对账逻辑，不能把“没有收到响应”误判成“没有执行”。

有争议且可追责

机器之间的自动结算也会出现虚假结果、服务未完成、质量不达标、超额调用和身份冒用。支付轨道必须支持证据引用、退款、仲裁和账户冻结。

一个面向 A2A 的最小交易协议，可以包含：

{
  "request_id": "stable-idempotency-key",
  "buyer_agent": "verified-agent-id",
  "seller_service": "verified-service-id",
  "purpose": "structured-task-description",
  "price": { "amount": 0.02, "currency": "USD" },
  "authorization": "scoped-policy-reference",
  "expires_at": "2026-09-22T12:00:00Z",
  "settlement": "escrow-or-postpaid",
  "dispute_policy": "policy-reference"
}

这只是示意结构，不是视频嘉宾提出的标准，也不能直接用于真实支付。它强调的是：机器交易要有稳定身份、明确目的、有限授权、过期时间、幂等标识和争议路径。

十二、给 Agent 交易系统的安全落地清单

如果要把 Agent 接入真实订单、支付或外部服务，至少应先完成以下检查。

身份与权限

用户、Agent、设备、商户和服务是否都有可区分的身份？
权限是否按动作、对象、金额、时间和次数限制？
一次性任务授权是否和长期自动授权分开？
用户能否快速撤销权限并查看当前生效的授权？

计划与执行

模型生成的计划是否先经过代码校验？
高风险动作是否有预览、确认或人工审核？
是否有沙箱、模拟执行或只读检查阶段？
工具调用是否具备超时、重试、幂等和状态查询？
订单、余额和支付结果是否来自服务端事实，而不是模型文本？

资金与责任

Agent 使用的是受限额度还是主账户全部权限？
失败、部分成功、重复扣款和退款如何处理？
交易日志能否还原用户意图、授权依据和执行过程？
出错后谁负责处理：平台、Agent 运营者、商户还是支付网络？

A2A 生态

交易双方能否验证对方 Agent 的身份与能力？
报价、服务条件和结算规则是否机器可读？
是否有统一的拒绝、超时、重试、退款和争议状态？
是否有速率限制和异常 Agent 隔离机制？

结语：把钱包交给 AI，先把控制权写进系统

“敢不敢把钱包交给 AI”不是一个单纯的产品体验问题，也不是等模型准确率提高后自然解决的问题。它要求整个系统同时做到：

知道 Agent 代表谁。
知道用户授权了什么。
限制 Agent 能做什么。
在执行前让用户看懂关键后果。
在执行后提供真实收据和可追踪证据。
在出错时支持暂停、退款、争议和责任归属。

Agent 交易时代的竞争，不只是谁拥有更强的模型，也是谁能把“意图—授权—执行—结算—追责”这条链路做得更可信。

当 Agent 只会聊天时，系统可以容忍一些模糊；当 Agent 开始花钱、签约和调用其他 Agent 时，模糊就会变成风险。真正的信任基建，应该让 Agent 更能办事，也让用户始终知道它正在替自己做什么。

来源与观看入口

原视频：外滩大会线下圆桌｜敢把钱包交给AI吗？聊聊Agent交易爆发前夜的信任基建
发布频道：硅谷101播客
视频页面显示发布于：2026 年 9 月 18 日
视频页面列出的圆桌主题：2026 Inclusion·外滩大会主论坛“当 Agent 成为交易主体”