用户学会利用 Agent 超时机制套取退款

某平台发布了一个针对长耗时智能体（agent）任务的 30 分钟实际时间上限，并配套了一项退款政策：任何达到超时上限且未产生交付成果的任务，其消耗的 token 费用将予以退还。其初衷是保护性的：挂起的智能体不应向客户收费。六个月后，超时率翻了一番，工程团队深陷“智能体可靠性”调查，而支持队列中挤满了抱怨智能体“不断超时”的用户——截图显示，用户的浏览器标签页在 29 分多钟时就被关闭了。

在财务模型从未命名的行为群体中，单位经济效益已悄然倒挂。退款人群并非质量不佳的人群。这是一种策略。

你提供赔付的边界就是被瞄准的目标

平台针对任何运营阈值提供的赔付，都会成为用户可以学习并着陆的坐标。这在云计算或 SaaS 领域并不新鲜——SLA 赔偿、退款窗口和免费层级上限已被“薅羊毛”数十年——但智能体平台面临着该问题的一个独特且尖锐的版本，因为单个任务的成本高到足以值得针对其进行单独优化。

从用户的角度来看，计算过程很简单。一个完成的复杂多小时任务将按智能体消耗的全部 token 计费。而同一个任务在 28 分钟处被中断，触及退款边界，退回大部分费用，且由此产生的上下文状态（in-context state）可以在后续轮次中以较低成本恢复，而无需从零开始。一个每周运行十个此类工作流并精于计算的用户，会在每一次高成本运行中刻意导向该边界。

高级用户最先发现裂缝。他们是资金风险最高、最有动力仔细阅读政策、且在操作上足够成熟能围绕限制条件重构工作流的群体。他们也是平台最不想失去的群体，这也是为什么退款政策最初设定得很慷慨。

平台的响应曲线完全搞错了方向。超时率上升，于是可靠性团队调查智能体。智能体表现正常。退款账单上升，财务将其视为平台故障成本升高。值班人员没看到任何事故。每个仪表盘报告的问题其病因都与实际发生的不同，因为这些仪表盘在设计时，是将用户视为智能体行为的被动接受者，而非定价博弈的参与者。

为什么这种失败模式是智能体平台特有的

传统 SaaS 只给用户提供几个粗粒度的杠杆——取消、降级、争议账单。智能体平台则暴露了更细粒度的行为控制，直接映射到单位成本上。用户可以决定何时终止任务、如何组织下一条消息、是否生成子智能体、何时提交工具调用。每一个都是账单上的旋钮。

这种超时退款博弈在结构上类似于过去两年记录在案的针对云 API 的成本攻击类：随使用量扩展的定价表面，产生了一种推动使用量向平台非预期方向发展的激励。智能体的不同之处在于，优化者是客户而非攻击者，且其行为并非恶意——用户只是在阅读并执行书面政策。

第二个复合因素：智能体运行时间足够长，以至于用户有时间在运行中途决定是否让其完成。一个耗时两秒的 API 调用没有有用的“在此中止以获取退款”的空间。一个 28 分钟的智能体任务则有。正是由于长耗时智能体具有价值的特性——持久、多步骤的工作——也给用户提供了一个针对计费边界进行优化的窗口。

第三个因素，也是将其从孤立的小技巧转变为行为群体的原因：来自部分完成的智能体运行的上下文状态是有价值的。如果用户在退款触发后可以廉价地恢复运行，他们实际上已经将“智能体完成了大部分工作”转变为“智能体免费完成了大部分工作”。平台的检查点与恢复（checkpoint-and-resume）能力——作为可靠性功能出售——正兼职作为计费漏洞。可靠性和退款套利共享同一条代码路径，而平台并未意识到它在同时为这两者提供资金。

诊断结果看起来像是质量倒退

这是该失败模式中代价最高昂的部分，因为它将响应路由到了错误的团队。

当超时率翻倍时，工程内部的自然解读是“智能体变得越来越糟”。可靠性调查随之启动。评估套件重新运行。模型版本进行二分查找。工具延迟被审计。结果一无所获，因为没有任何倒退——智能体表现得和以前完全一样，只是其承载的工作负载发生了偏移。

加载中…