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

与此同时，支持团队看到了另一个故事。如果只看表面，那些截图是具有毁灭性的：用户的标签页确实在 29 分多钟时关闭了，用户确实不高兴。工单中的措辞一致且可信。“你们的智能体总是罢工。”一名初级支持人员为了对眼前的客户负责，会将这些作为平台事故上报。

财务看到了第三个故事。退款量上升。单位经济模型将退款视为平台可靠性的函数，因此退款增长被记为可靠性成本，这增加了增加可靠性投入的理由，于是第三个团队开始追逐同一个幽灵。

这些团队对自己获得的局部信号都没有错。他们错在对他人的信号判断上。这个横切事实——即一个行为群体正在利用政策缝隙——处于任何团队的仪表盘都覆盖不到的真空地带，因为没有一个仪表盘是根据超时边界上的用户行为模式进行细分的。

缩小差距的关键​

“收紧退款政策”这种本能反应通常是错误的起手式。对真实的平台故障采取慷慨的退款政策是信任契约中承重的一部分。取消它会为了追逐“利用规则群体”而惩罚“合法用户群体”，而利用规则群体会逐渐适应任何新的边界。真正的解决办法是让退款决策基于原因，而非症状。

以下是几种在实践中奏效的模式：

超时原因分类。 退款资格检查应该检查超时是由平台驱动（网络断开、依赖失败、队列饥饿）还是由用户驱动（显式放弃、关闭标签页、手动中止）。这两个群体应该分开计费。这是一个成本极低的一小块会话遥测数据，它能将二进制的“是否触及边界”转化为关于“为什么”的结构化信号。

计费流程中的行为分群。 一种针对每个用户的分析，用于在大规模范围内检测“超时并恢复”模式——在边界处中止重复任务，随后进行廉价的恢复轮次以完成工作——并将这些账户路由到单独的审核通道。检测逻辑不需要很复杂。像“同一用户在一周内出现超过三次‘超时后恢复’对”这样一个简单的规则就是一个强信号，它可以交给人工审核员，而不是自动触发退款。

长任务的优雅移交协议。 如果用户想离开一个 30 分钟的任务而不放弃工作，平台应该在产品层面上而非计费层面上使其成为可能。一个带有明确计费语义的“暂停并在稍后恢复”的功能消除了博弈超时的动机，因为合法的用例有了自己的出口。

按分群细分的退款率仪表盘。 现有仪表盘将“退款量”作为单一线条报告，这是误诊的前提。按原因（平台故障、用户放弃、可疑模式）拆分退款量，会在行为分群出现的第一个月就将其暴露出来。

按用户而非仅按代理细分的超时率面板。 可靠性调查之所以走向错误方向，是因为超时率指标是跨所有用户聚合的。按用户拆分会显示出一小部分账户对增长贡献巨大，这是行为分群而非回归（regression）的特征。

架构层面的认知​

这里有一个比任何单一修复都更深刻的观点。平台据以补偿的每一个阈值，退款或信用点数触发的每一个边界，都是定价函数中的一个坐标，用户最终会对其进行映射并针对其进行优化。这种映射并不总是刻意构建的——有时它源于论坛帖子，有时源于客户成功对话，有时源于一个资深用户发现这个月完成同样的工作账单变低了。一旦这种映射存在，它就会传播，平台的收入模型现在就成了“有多少用户读过这张地图”的函数。

在设计退款政策时，如果不将用户建模为一个优化者，那么这项政策就成了一项最精明的用户可以自我发放的折扣。这在用户层面并不是道德败坏——他们只是对书面合同做出了理性的反应。这在平台层面是设计上的失败，因为政策被写成了一种单方面的保护，而不是双向的激励。

做得好的团队会像构建安全防御体系一样构建他们的计费和退款逻辑：假设存在一个仔细阅读规则并据此行动的对手。安全案例中的对手是恶意的；计费案例中的对手是拿着电子表格的付费客户。架构上的准则是相同的。平台在书面承诺的每一个边界都会成为攻击点，每一项退款政策都是一份契约，其长期成本不是由它所模拟的人群决定的，而是由学会游走在其边缘的人群决定的。

对于即将发布长运行代理（long-running agent）产品的团队来说，最有用的框架是：退款政策是定价界面的一部分，而不是独立的。它应该由审查定价页面的同一批人进行审查，保持同样的细致，并带有一个明确的问题——“在这种政策下，用户的最优行为是什么？这是我们想要资助的行为吗？”——并将其写入审查模板。如果这个问题没有好的答案，那么这项政策就还没准备好。