Google 的智能体打电话给商店，而每一项协议保证都掉了下去

那些花了两年为智能体商务铺设密码学轨道的公司——签名意图、签名购物车、可验证的支付授权书，还贡献给了 FIDO Alliance——把自己最显眼的消费级智能体功能，发在了一条一样都不承载的信道上。Google 的购物智能体现在会打电话给商店询问有没有现货；而一件差事一旦离开协议轨道走上电话线，主叫身份就退化成一句口头声明、授权彻底消失，关于"到底谈成了什么"的唯一记录，是智能体自己写的、关于自己的一份摘要。

实际发布了什么

Google 的智能体购物功能——对话式搜索、智能体结账，以及一个会给本地商店打电话的智能体——在 2026 年夏季陆续放量，截至 8 月初仍在推进中。其中打电话这一块最值得细看，因为它比报道给人的印象更窄，而它的后果又远超这份"窄"所暗示的程度。

属性	Google 的说法	为什么它要紧
范围	美国境内的部分品类——玩具、健康美妆、电子产品等	刻意做小。这是一次有边界的试点，不是通用型外呼智能体。
差事	挨个致电本地商店，询问库存、价格与可得性	一件真实的差事，而对绝大多数商店来说，没有任何商家 API 能回答它。
披露	智能体会表明自己是自动呼叫	自愿、逐厂商；而 FCC 关于"这类披露必须怎么说"的规则，截至 2026 年 8 月仍是提案。
被叫方控制	商家可以选择不再接收此类呼叫	逐厂商退订。不存在一个商店注册一次即可的跨运营方登记处。
结果	用户通过短信或邮件收到一份摘要，外加本地库存详情	这份摘要是智能体对一场"没有别人代表用户做过记录"的对话的自述。

把这张表当作产品来读，它平平无奇——一个有用、划定了边界的助手功能。把它当作一次协议层面的决定来读，它就是今年智能体商务里最有意思的一件事，因为它旁边摆着的东西。

被建起来的那条轨道，和真正被用上的那条

一件差事走哪条轨道，是由商家的集成预算决定的，不是由结果有多要紧决定的。

Google 于 2025 年 9 月发布 Agent Payments Protocol，首发阵容庞大，横跨卡组织、支付处理商与企业软件，其核心是签名的 Intent、Cart 与 Payment Mandate——一条密码学授权链，使智能体无需商家采信它关于"我代表谁"的自述即可交易。2026 年 4 月 Google 发布 v0.2 并把该协议贡献给 FIDO Alliance；5 月该联盟宣布 AP2 与 Mastercard 的 Verifiable Intent 均已被贡献进来。竞争性方案同样存在，2026 年做集成的零售商多数是并行接入不止一种，而公开证据在很大程度上仍是设计意图的文档，而非交易量的证明。

这是一份相当扎实的工作，且正对着信任问题：一个出现在商家面前的智能体，是一个自称代表某人的陌生方，而授权书链条就是它证明这一自称的方式。这套栈里的每一项保证——谁在呼叫、它被允许做什么、这个请求是不是已经发生过、到底谈成了什么——都随请求本身一起传送。

然后，购物智能体需要知道三条街外那家五金店有没有那个零件。那家店没有 AP2 端点。它根本没有 API。它有一部电话、一个人，和一个六点结束的班次。于是智能体拨了号，而上一段里的一切都被留在了中继口上。

智能体拿起电话时，掉下去的是什么

第一行以下的每一行，都是用户从未选择、也看不见的一次降级。

有意思的比较不是抽象的"电话 vs API"，而是逐项去看每条信道到底能承诺什么。主叫身份在协议轨道上是一个签名；在通话里则是智能体说出的一句话，其可信度与任何其他人说同一句话完全相同。受限授权在轨道上是一份写明"该智能体可以替其委托人承诺到什么程度"的授权书；在通话里根本不存在这样一个对象，于是范围就是模型接下来决定说什么，唯一的边界是它的提示词。

重放保护是差距在运营上变得最尖锐的地方。结构化请求携带一个 nonce 或订单 ID，于是超时后的重试可以被安全去重。而一通在商家答应留货之后掉线的电话，压根没有任何标识符——你平时会伸手去拿的那套恰好一次机制无处着力，唯一的缓解是在承诺之前先问一个确认性问题，并保留一份持久的本地记录以便事后由人对账。

再说凭证：在轨道上，双方最终各自持有一份描述发生了什么的签名物件；在通话里，用户收到的是智能体对这场对话的摘要。它可能完全准确，但除了那位店员之外没有人能证伪它——而店员同样没有留档。网页结账上的浏览器智能体处在两者之间：它借用用户自己的会话充当身份、免费得到一个订单 ID、还能指向一个订单确认页——值得一提，因为这说明降级是一条渐变的曲线，而电话位于它的最底端。

为什么电话是永久的，而不是过渡性的

一个令人安心的读法是：这只是权宜之计——协议还早，采用率会扩散，几年后智能体命中的将是端点而不是总机。这个读法低估了商家人群的形状。

智能体商务协议正在被你意料之中的那些企业采用——大型零售商、平台、支付服务商，以及任何有集成预算、且智能体来源流量大到值得为之投入的一方。而 Google 选来演示的这件差事，面对的恰恰是相反的人群：独立小店、加盟门店、服务柜台，那些库存不进入任何数据流、人员配置也伸展不到一个集成项目的地方。街角五金店去实现一套授权书协议，没有任何可信的未来图景——因为成本不在代码，而在于"是否存在一个人，其岗位职责里包含维护一个 API"。

所以电话不是一架大家都在往上爬的梯子的最低一级。它是智能体商务的永久地板，是覆盖结构化轨道永远够不到的那条巨大长尾的信道，也是那条完全没有信任机制的信道。这个行业把标准化的力气花在了最不需要它的那群人身上——大型商家本来就有合同、拒付权与法律救济——而在"智能体的一句话就是全部可得凭据"的那群人身上，一分力气也没花。

还有一个值得留意的二阶效应。如果智能体来源的呼叫变得普遍，小商家的电话线就不再是一条客户通道，而变成了一个由人类做解析的、未经认证的 API，在一个它从未同意过的量级上，服务着它无法识别的请求方。这是一次成本转移，而没有人为它定价。

被叫方手上没有称得上控制的东西

这三样都不是标准。而它们全都存在于同一批公司为"有 API 的商家"所建的那条轨道上。

Google 做了它能做的那些负责任的事：智能体会说明自己是自动化的，商家可以退订。两者都是真实的，也都在结构上不足——原因相同：它们是某一家厂商产品的属性，而不是这条信道的属性。

退订是最清楚的例子。一家不想接智能体来电的商店，必须逐个去发现每一个运营方的存在、找到该运营方的退订机制、再逐个使用它——Google 记载的其中一条路径是拨打一个号码、留下带有商家名称的语音留言。把它乘以每一家推出外呼智能体的公司，负担就完全落在最没有能力承担它的那一方身上。真正管用的是一个所有运营方都遵守的单一登记处，而这是一个标准化问题，同一批联盟早已具备解决它的条件——只是没人向他们提出这个要求。

披露的形状类似。FCC 于 2024 年 2 月的解释性裁定确认，AI 生成语音在 TCPA 意义上属于"人工或预录语音"，但 TCPA 的限制是围绕住宅线路与无线号码写的——一家商店的商用固话并不是那套框架所要保护的对象。而 FCC 关于定义"AI 生成呼叫"并强制规定披露措辞的立法程序，截至 2026 年 8 月仍是提案。因此对打给企业的呼叫而言，"智能体自报家门"是一条自愿规范，此刻正由最先发布的那一方设定；而以这种方式设定的规范，其耐久程度恰好等于随之而来的竞争压力。欧盟在一个很窄的方面走得更远：AI 法案的透明度义务自 2026 年 8 月 2 日起可执行，要求告知当事人其正在与 AI 系统交互——这与让披露问题对智能体整体变得不可回避的，是同一条原则。

第三个问题是没人在问的那个。那位说了"行，我给你留一个"的店员，已经进入了某种承诺关系，却手上没有任何记录，日后也无从对用户的说法提出异议。在协议轨道上这件事已被解决——双方各持一份凭证。在电话上，持有录音的那一方，是打出这通电话的那一方。

如果你正站在这件事的任一端

两类读者，两份很不一样的清单。

如果是你的智能体在打电话	如果是你的生意在接电话
每一通都在第一句话里、不待询问地披露。监管尚未定局；规范此刻正在被设定，而设定者是你。	在量涌上来之前就定好政策，而不是之后。"我们接受关于库存的智能体来电，但不接受下单"是一条挺好的政策，而它需要白纸黑字地存在。
永远不要让模型在行内断言结果。从文字记录中抽取一个带类型、带置信度字段的结果，并让下游代码显式处理低置信度。	在预留或承诺任何事之前，请对方书面确认。那是双方唯一会有的凭证。
在拨号之前先写下一条持久的意图记录，让掉线的通话可以由人对账，而不是被静默重试。	把智能体来电与客户来电分开记录。你没法为一笔从未统计过的成本去争辩。
在你的整个运营范围内立即兑现退订，并把抑制检查做成拨号的前置条件，而不是提示词里的一句指令。	如果你想退出，就去找到并使用每一家运营方的退订入口。今天它是逐厂商的，没有捷径。
把回程的文字记录当作对抗性输入。对端说了什么，都是进入你智能体上下文的不可信文本。	培训员工：一个自称代表某位顾客的来电者，说的是一个声明，不是一份凭据——这是最古老的社工面。

工程侧的展开见电话与 PSTN 接入与外呼语音智能体，两者都从实现者的座位上讲了同一个底层要点：电话是一条尽力而为、未经认证、无确认的信道，任何需要保证的东西都必须从别处取得那份保证。

常见问题

Google 的外呼功能到处都能用吗？

不能。它是在美国的部分品类上线的——玩具、健康美妆与电子产品等——而预约、等位时长查询这类相关的自动呼叫功能仅限美国，并排除了部分州。整个放量过程贯穿了 2026 年夏季。

智能体会告诉商店自己是 AI 吗？

会。Google 表示智能体会表明自己是自动呼叫，且商家可以选择不再接收此类呼叫。两者都是厂商承诺，而非某项标准设定的要求；而那条会为 AI 生成呼叫规定强制披露措辞的 FCC 规则，截至 2026 年 8 月仍是提案。

为什么智能体不能直接用 AP2 之类的协议来完成这些呼叫？

因为被呼叫的商家没有实现任何一种，而且大多数永远不会。智能体支付协议需要商家侧的集成，这适合大型零售商与平台；而独立小店构成的长尾没有 API、没有集成预算，也没有一个人的岗位职责会包含这件事。那道缺口正是电话在填补的东西。

TCPA 的规则能保护商店免受智能体来电吗？

并不直截了当。FCC 于 2024 年 2 月的裁定确认了 AI 生成语音在 TCPA 下算作人工或预录语音，但该法条的限制是围绕打给住宅线路与无线号码的呼叫构建的。打给商用固话的呼叫大体落在那套框架之外——这正是今天实际可用的控制手段只剩下各厂商自家退订的原因。

真正能修好这件事的是什么？

三件事，全都是标准问题而非研究问题：一个被叫方可以验证的签名主叫身份、一个跨运营方的单一退订登记处，以及一次智能体通话之后向双方各出具的一份凭证。它们每一样，都已经以某种形式存在于同一批公司为"有 API 的商家"所建的那条结构化轨道上。