当工单的两端都是 AI Agent 时

在本季度的支持队列中的某个地方，发生了一场没有任何人类参与的对话。你客户的采购智能体发起了一个关于发票差异的工单，你的支持智能体根据退款政策进行了回复，两者往复沟通了 11 次，直到线程终止——问题未解决，没有升级，且对两家公司都是不可见的，直到客户的 CFO 询问为什么退款还没到账。就其自身规则而言，这两个机器人都没有做错任何事。这就是问题所在。

我们为 AI 客户支持构建的一切都假设另一端是人类。情感检测、挫败感阈值、“你是否想与人工通话？”——所有这些都在模拟一个会疲劳、会愤怒或会放弃的客户。而客户的智能体不会做这些事。它具有无限的耐心，程序化的礼貌，并严格遵守剧本。当它遇到同样耐心、同样遵守剧本的支持智能体时，你不会得到解决方案或投诉。你得到的是一个在任何仪表盘上看起来都像健康对话的僵局。

Gartner 预计到 2028 年，AI 智能体将中介数万亿美元的 B2B 支出，而基础设施正在迅速到位：OpenAI 和 Stripe 在 2025 年末推出了智能体商业协议 (Agentic Commerce Protocol)，Google 的生态系统推出了带有加密签名授权的智能体支付协议 (AP2)，而 A2A 协议则标准化了智能体之间如何相互发现和交流。所有这些基础设施都回答了“智能体如何交易”的问题。但几乎没有一个回答交易出错后会发生什么——而这正是支持部门的职责所在，也是两个组织边界、两个策略引擎和两个责任制度在单个工单线程中发生碰撞的地方。

仪表盘无法察觉的升级死锁

在一家公司内部，智能体升级是一个基本解决的问题：置信度下降、情感波动、检测到循环、移交给人工。当对手是机器时，每一个触发因素都会失效。

置信度保持在高位，因为两个智能体都在生成流畅、合理的回复。情感保持中性，因为双方都没有可以检测的情绪。而针对人类调整的循环检测——“客户重复了三次同样的问题”——在被训练为重新措辞而非简单重复的智能体面前会失效。关于谈判的研究直言不讳：模拟智能体对智能体消费者谈判的研究发现，死锁是最持久的失败模式之一，比超额支付或违反预算更难缓解，而且当两个智能体都被配置为代表其委托人坚持立场时情况最糟糕。当然，双方都会这么做——这正是每家公司的提示词工程师领工资要干的活。

更深层的问题是结构性的。你组织内部的升级是你端到端控制的策略决策。跨组织的升级是一个没有协调者的分布式系统问题。当你的智能体决定“这需要人工”时，由哪个人来处理？你的、他们的，还是双方都要？如果你的智能体升级了而他们的没升级，你的支持工程师现在就在和机器人对话——这恰恰消耗了客户部署智能体想要节省的高昂注意力。目前还没有一种协议动词代表“我正在调动人工；你也应该这样做”。A2A 给智能体提供了一个共享的任务生命周期；它没有给两家公司提供关于“卡壳”的共同定义。

实际的解决方法并不光鲜：将跨边界的智能体对话视为一类独特的流量，并给予它们专属的熔断机制。使用回复次数预算，而不是情感检测。使用语义进度检查——提议的解决方案集是否真的在缩小？——而不是重复计数。并建立一条硬性规则，即熔断触发时必须通过将升级写入共享任务状态而非任何一家公司的私有队列，来同时呼叫双方的人工。如果你无法检测对方是否是机器人，那么就把任何回复次数超过你人类 p99 次数的对话都视为机器人对话。

哪些政策是机器可协商的——以及哪些需要人工介入

一旦两个智能体可以对话，诱人的做法就是让他们自己解决问题。有些政策确实应该是机器可协商的，而且收益是真实的：据报道，智能体中介的采购部署比人工谈判的合同有两位数的成本改进，而一个 40 美元的运费退款纠纷由两个机器人在 90 秒内解决，要优于由两个工单队列在 9 天内解决。

但“智能体可以解决它”需要一个边界，谈判文献告诉了你该在哪里划线。智能体在可预测的方面表现不佳——卖方智能体接受低于成本的价格，买方智能体支付超过零售价的金额，以及结果偏差会随着双方使用的模型不同而产生实质性波动。一项大规模的自主谈判竞赛发现，模型能力的差异会直接转化为捕获的价值：你的客户使用前沿模型对抗你成本优化的支持模型，这不是谈判，而是一种压榨。

一个可行的决策框架分为三个层级：

• 机器可结算：受限的、可逆的且定价明确的。限额内的退款、运费补偿、方案按比例计算、重试和更换发货。将限额编码在智能体的权限中，而不是提示词中——提示词是建议，Token 范围才是规则。
• 机器协商，人工核准：智能体在提议的解决方案上达成一致，但只有在授权方的人员批准后才生效。合同条款变更、超过阈值的 SLA 赔付，以及任何会开先例的事情。智能体负责发现和起草；人员负责签署。
• 人工干预项：不可逆的、涉及法律或安全的。数据删除、安全事件、监管投诉，以及任何涉及伤害指控的事情。在这里，智能体唯一正确的做法是拒绝谈判并转接人工——双方都是如此。

干预项清单也是一种防御。一个可以谈判任何事情的智能体是一个可以被诱导做任何事情的智能体；你担心的针对用户的提示词注入风险，在面对一个旨在寻找你政策软肋的对手智能体时会放大十倍。固定的、不可协商的类别比主观判断更容易防御。

验证声称代表你客户的代理身份

在整个领域中，最令人生畏的一句话是你的支持代理每天会听到一千次的话：“我代表 Acme Corp 办理业务。”证明给我看。

凭证令牌（Bearer-token）思维在这里会以一种特定的方式失效。如果客户的代理使用客户的 API 密钥进行身份验证，你将无法区分代理和客户——这意味着你无法缩小其权限范围，无法对其进行单独审计，也无法在不吊销客户权限的情况下撤销代理。它采取的每一个行动都与账户所有者的直接操作无法区分，直到事后分析发现“客户请求关闭账户”实际上意味着“一个配置错误的机器人请求关闭账户”。

新兴的机制将传统身份验证中混为一谈的三个声明分离开来：主体是谁（who is the principal）、执行者是谁（who is the actor），以及具体委派了什么（what exactly was delegated）。带有 actor 声明的 OAuth 令牌交换（RFC 8693）为你提供了“谁在操作”的链条，而 2025 年的 IETF 草案扩展了授权流程，使用户可以明确批准一个具名的代理，而不仅仅是一个应用。AP2 在商业领域更进一步：采用加密签名的意图和购物车授权（cart mandates），这样商家就拥有了防篡改的证据，证明人类授权了 这次 以 这个 价格进行的购买——而不是“某个拥有有效会话的代理做了某事”。代理商业协议（Agentic Commerce Protocol）的共享支付令牌将同样的思路应用于凭据：代理可以在不持有银行卡的情况下发起支付。

对于支持层面，在你的代理接受任何“代表”声明之前，可行的方法是设置一个三部分组成的关卡：

• 验证委派，而不仅仅是凭据。 要求提供一个将代理命名为执行者（actor）、将客户命名为主体（subject）且具有明确权限范围（scope）的令牌。代理提供的原始客户 API 密钥应该被视为比有范围限制的委派更 弱 的信号，而不是等同的信号。
• 按层级而非按会话划分权限范围。 允许代理查询发票状态的委派令牌，不应是那个可以接受结算方案的令牌。在读取和提交的界限之间，强制进行重新授权——最好是经过人类批准并签名的授权指令。
• 记录链条，因为责任随之而来。 当日后对解决方案产生争议时，问题将是“谁同意了这件事？”令牌中嵌套的执行者链条可以给你答案。而共享的会话 Cookie 只会给你带来官司。

没人签署的 API 合同

这是一个令人不安的现实：当你的支持代理和客户的采购代理交谈时，他们正在执行一个无人指定、无人版本化且无人同意运营的集成。你运行的每一个其他跨公司接口——支付轨道、EDI、Webhook，甚至电子邮件的可送达性——都附带一份合同：架构（schemas）、SLA、错误语义、滥用处理。机器人对机器人的支持对话则完全没有这些。两个随机系统（stochastic systems）正在通过自然语言进行自由集成，而两家公司都默认接受由此产生的任何结果。

这种合同空白包含具体的细节。当双方代理都“同意”时，谁受约束——机器人协商的结算是否具有强制执行力，针对谁执行？频率合同是什么——每三十秒轮询一次你支持界面的客户代理是高级用户还是拒绝服务攻击（DoS）？披露规则是什么——代理是否必须表明身份，你是否有权拒绝某些请求类型的自动化交易对手？协议正开始触及这些问题——A2A 代理卡片可以携带组织签名，ACP 的后期版本增加了身份验证界面——但消息的架构并不等同于对行为的协议。目前没有任何规范说明当谈判陷入僵局时，一个“合理的”代理应该做什么，或者应该叫醒哪家公司的人类。

在标准完善之前，合同必须以传统方式编写。如果与交易对手的代理对代理流量至关重要，请在商业协议中加入一份 代理交互附加条款：身份识别要求（代理声明自身身份）、权限代表（各方代理有权结算的内容，以便使“你的机器人同意了”具有明确的法律含义）、频率和滥用条款、僵局处理程序（在 N 轮或 T 小时后，双方承诺转由人类审查），以及审计义务（双方保留争议解决的对话记录和委派链）。这些都不是什么新鲜事——这就是你应用于任何 API 合作伙伴关系的相同规范，只是应用于一个恰好说英语的接口。

为你已有的机器人客户进行设计

人们的本能是将这一切视为 2027 年才会遇到的问题。事实并非如此，原因很简单：你的客户在将代理指向你的支持渠道之前，不会征求你的许可。当你发布聊天组件或支持邮箱地址的那一刻，你就发布了一个最终会被他人的代理消费的 API。唯一的问题是你是否察觉到了。

因此，从检测开始，而不是从架构开始。对你现有的支持界面进行工具化处理，以识别可能的代理流量——响应延迟的均匀性、对话节奏、没有拼写错误和情感、结构化的措辞——并衡量在你的“客户对话”中，已经有多少比例没有人类客户参与。进行这项分析的团队通常会感到惊讶。然后按顺序应用成本较低的干预措施：对可疑的机器人对机器人对话设置轮次限制断路器，支持委派令牌以便表现良好的客户代理有比冒充主体 更好 的路径，以及针对你的代理可以做出让步的行为进行机器可结算/人类批准/特殊分层。

长远来看，这更有趣。为代理交易对手设计的支持界面——经过身份验证的委派、结构化的解决 API、明确的僵局语义——对人类来说也更快、更便宜。我们花了十年时间让机器人伪装成愉快的人类来服务人类客户。接下来的几年则是让机器人停止伪装，这样当工单的两端都是机器时，对话就是一个集成——有合同约束、有界限且可观察——而不是两个非常有礼貌的系统在一段没人阅读的对话中永远失败下去。