在本季度的支持队列中的某个地方，发生了一场没有任何人类参与的对话。你客户的采购智能体发起了一个关于发票差异的工单，你的支持智能体根据退款政策进行了回复，两者往复沟通了 11 次，直到线程终止——问题未解决，没有升级，且对两家公司都是不可见的，直到客户的 CFO 询问为什么退款还没到账。就其自身规则而言，这两个机器人都没有做错任何事。这就是问题所在。
我们为 AI 客户支持构建的一切都假设另一端是人类。情感检测、挫败感阈值、“你是否想与人工通话？”——所有这些都在模拟一个会疲劳、会愤怒或会放弃的客户。而客户的智能体不会做这些事。它具有无限的耐心，程序化的礼貌，并严格遵守剧本。当它遇到同样耐心、同样遵守剧本的支持智能体时，你不会得到解决方案或投诉。你得到的是一个在任何仪表盘上看起来都像健康对话的僵局。
当一个生产环境中的 Agent 首次运行 40 分钟，并在 40 个步骤中的第 27 步遇到 401 错误时，故障复盘的情形几乎总是如出一辙。房间里有人会问为什么令牌没有刷新。另一个人指出刷新逻辑是存在的，但它存在于 HTTP 客户端中，而 Agent 的工具封装层（tool wrapper）从未与之对接。第三个人注意到，即使触发了刷新，Agent 的两个并行工具调用也会尝试在同一瞬间轮换同一个刷新令牌，从而导致会话崩溃。大家纷纷点头。然后，团队在接下来的一周里，为一个假设请求会在 800 毫秒内完成的架构苦哈哈地补齐凭据生命周期管理。
OAuth 的设计初衷是让访问令牌（access token）的寿命长于使用它的请求。长运行 Agent 颠覆了这一假设。现在的请求——实际上是在数分钟或数小时内编排的数十次或数百次工具调用链——比令牌活得更久。整个行业花了十年时间围绕“短请求”假设构建库、代理和刷新流，而这些几乎都无法干净地移植到 Agent 循环中。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
