某家保险公司用一整年的客服对话记录微调了一个支持模型。上线不到一周,合规审查员就发现了怪事:这个机器人一直把 "deductible"(免赔额)写成 "deductable"。不是偶尔出错——而是每八条出现该词的消息里,大约都会有一条这样写。模型并没有自己发明这个拼写错误。它继承了这个错误。一小撮一线客服两年来一直这么打字,而语料库忠实地反映了他们打的内容,不是字典里的内容。
这就是在运营数据上做监督式微调最令人不安的地方:模型并不是在学习你的领域,它是在学习你的语料库。这两者有重叠,但并不等同,而那道缝隙正是每一个本可预防的行为缺陷藏身的地方。训练数据里的频率并不是正确性的信号,它只是一个信号——告诉你你的团队恰好做某件事做得够多,多到模型愿意模仿。
错别字是最容易识别的情形。难的是那些没人愿意写成规则的部分,因为大家都默认模型会学到工作的"专业"版本,而不是工作被实际执行的样子。
代理系统里最贵的 bug 是那种没有任何报错的 bug。Worker 提出一个草稿。Verifier 用一段反馈把它驳回。Worker 修改。Verifier 再次驳回。循环一直转下去,trace 越来越长,账单越爬越高,而从外面看,这个系统似乎在 工作——而且很尽职,因为两个模型都在干各自该干的活儿。没有人定价进去的是:验证器的接受标准在不同调用之间并不固定。worker 在追的那个目标本身在动,而循环没有任何收敛保证。
你以为自己交付的是"迭代到满意为止",其实你交付的是一次对极值可能根本不存在的空间的搜索。
我认识的一位产品经理，花了两周时间排查公司 AI 写作助手的流失激增。免费用户的会话长度骤降 30%，客服收件箱挤满了"你们的模型以前很聪明，现在变懒了"的各种变体，团队第一反应是把锅甩给同一周上线的模型升级。模型其实没有变。变的是财务在季度中途悄悄收紧了按用户分配的 Token 预算，应用在用户跨过新阈值时，正在静默截断系统提示词、丢弃工具调用、缩短回答。从用户的座位看，AI 退化了。从仪表板看，一切正常。两边都对，这就是失败模式。
这种模式现在到处都是。ChatGPT 免费版触达上限后会切到一个更小的模型，产品里除了"接下来一段时间回答可能会短一点"之外没有任何标识。Anthropic 的免费层行为类似。你在任何一家之上做功能，再叠加一层自己的按用户 Token 预算用来控成本，于是你串联了两道隐形悬崖——平台的，加上你的——而用户只看到一个聊天框，无从分辨自己刚才到底踩到了哪一道。
上季度我和一位客服主管聊天,他对新 AI 客服 78% 的转移率赞不绝口。转给人工的工单骤减;每单成本数字漂亮;仪表盘连续三个月一片绿色。然后营收运营团队跑了一次队列分析。那些至少为账单问题接触过机器人的客户,流失率是没接触过的 1.7 倍。转移率衡量的不是"得到帮助",而是"沉默"——而这种沉默,恰恰是付费用户在悄悄离开的声音。
这是行业开始公开承认的失败模式。转移率统计的是"客户没有联系到人工"的对话数。它无法区分"我得到了答案"和"我放弃了"。把两者算成同一个数字,你就会朝错误的方向优化,因为让机器人更难逃离,远比让它真正解决问题要容易。Klarna 在 2026 年公开学到了这一课:它在宣布用 AI 替代约 700 名客服一年后,开始重新雇佣客服人员;重复联系率上升约 25%,当初支撑裁员决策的成本节约,被重新处理机器人首次没处理好的工单的代价抵消殆尽。
你对两个 prompt 变体跑了一次 A/B 实验。你的 LLM 评审——因为图省事,默认就用了和候选模型同一家厂商的模型——一致地偏好变体 A,差距大到足以被称为统计显著。你上线了 A。一周后,满意度指标下降了,退款队列上升了,没人能解释原因。终于有人用另一个模型家族的评审重新跑了一遍评测,偏好翻转了。
评审根本不是在衡量质量,评审只是在衡量候选模型听起来有多像评审自己。
你的法务团队花了四次会议来打磨那一句披露的措辞。工程团队把它放到了系统提示词的最顶端。QA 确认每个会话的第一轮都会出现。三个月后，一位监管者转发了一份对话记录：这是一段处理投诉的对话的第十四轮，整整一小时围绕一笔退款纠纷给出实质性建议，而在那十四轮里，用户从未看到「我是一个 AI」这几个字。你那份通过单轮合规评审批准的披露，在结构上根本无法在真正需要它的对话里存活下来。
这就是「披露衰减」（disclosure decay），它是 2025–2026 那波聊天机器人监管浪潮没有设计去捕捉、你的 QA 流程也没有配置去测试的多轮 Agent 失败模式。欧盟 AI 法案第 50 条的义务将在 2026 年 8 月 2 日正式可强制执行，罚款最高可达 3500 万欧元或全球营业额的 7%。加州的 SB 243 已于 2026 年 1 月 1 日生效，附带私人诉讼权，消费者可以直接起诉，每次违规最低赔偿 1000 美元。华盛顿州要求重复披露，对未成年人采取每小时一次的频率。这些监管体系没有一个是在假设「披露会在第三次工具调用后悄无声息地从会话里掉出去」的前提下写出来的——但这就是你的运行时此刻正在做的事，在每一个长时间运行的对话里，正在生产环境中发生。
公司里的某个地方，四个人各自都相信第五个人在管推理账单。工程把它当成云账单的一项。AI 团队把它当成做产品的成本。财务把它当成毛利率的可变输入，默认工程那边已经在管了。产品把它当成工程吸收的间接成本。账单一直在涨，唯一达成共识的是：这账不是我的。
这不是预算问题，而是所有权真空。它第一次浮出水面，往往是因为这条线大到 CFO 在董事会上点名问起。到那时，大家临时拼凑的回答——"我们会优化"、"我们会多做缓存"、"我们会换模型"——描述的是干预手段，却没有指出谁负责。本该在一年前发生的对话，并不是怎么把账单压下去，而是这笔账究竟属于谁的损益表。
这是结构性的变化。推理在企业 AI 支出中的占比，从 2024 年的 15% 涨到 2026 年的大约 85%；同一时间窗口里，企业平均的 AI 预算从 120 万美元涨到了 700 万美元左右。一项原本属于零头的科目，现在已经是董事会会注意到的数字，而那张在变化之前画好的组织架构图里，根本没有给它留一行。
一位用户拨通了你的客服 Agent。他们说话，Agent 倾听，用户在通话中途上传了一张错误截图，Agent 同时对图片和转写文本进行推理，最后通话以一封总结修复方案的邮件收尾。三天后用户投诉过来：修复没有生效，邮件也从未送达。你打开可观测性栈，发现三个独立 UI 里躺着三条互不相干的追踪。语音流水线给你一条 ASR 追踪。视觉流水线给你一段图片上传的 span。LLM 调用给你一条带 token 数和工具调用的聊天追踪。这些仪表盘里没有任何东西告诉你：它们其实是同一次对话。
这就是没人愿意写的那种复盘。不是因为数据缺失——每一个模态都老老实实记录了它该记录的东西——而是因为跨模态的"接合"从来就没建起来。每条流水线都从自家模型供应商默认配置里长出了自己的追踪约定，而把它们绑在一起的那一次对话轮次，只存在于设计这个 Agent 的那位工程师的脑子里。
你的网关给每个 tenant 干净利落地强制执行每秒 100 次请求的限制。dashboard 显示每个 tenant 都舒舒服服地在那个上限之下。但模型 provider 寄来的账单告诉你,你的支出上限照样被打穿了。rollout 电话会议上没有人能给出一个干净的解释。
答案在于限流器和账单衡量的是不同的东西。当用户点击一个按钮时,限流器看到的是一次"用户请求"。而 provider 看到的是一次 planner 调用、三次工具结果反思、一次因更严格 JSON schema 触发的格式修正重试,以及一次最终综合——每一次都带着自己的内部重试预算,在瞬时 429 或 500 回来时就会触发。一次点击可以扇出成三十次模型调用。限流器只数到一次。桶以它被设计容量的三十倍漏水。
在 HTTP 边界上对 agentic 系统做限流,就像在高速公路入口立速限标志,而入口里面的车却在自我繁殖。除非限流器理解了这个循环,否则循环就会绕过它。
六个月前,你的提示词前缀是 4,000 tokens。它稳定、缓存预热,几乎可以摊销到不计成本——系统指令的每次调用附加费,相比每次响应的成本,只是一个舍入误差。今天那个前缀变成了 11,000 tokens,你的缓存命中率从 92% 滑到了 31%,你的推理账单上升了 4 倍。团队里没有人能指出是哪个 PR 干的。没有一条 commit message 写着"将提示词增加 7,000 tokens"。每一次修改都很小,每一次修改都有理有据,每一次修改都干干净净地合入了。
提示词前缀长出胳膊和腿,就像地下室积攒纸箱一样。一个团队需要注入用户的订阅等级,这样 agent 才能解释套餐限制。另一个团队需要用户时区的今天日期,这样"明天提醒我"才能工作。第三个团队把当前 A/B 变体名硬塞进去,这样 eval traces 才能切片。市场团队加进了当前促销 banner,这样 agent 才能适时提及它。合规团队加进了功能标志清单,这样模型才能拒绝那些不在灰度名单里的用户访问 beta 功能。每一条都是一行的添加。每一条单独看都站得住脚。但加起来摧毁了你的缓存。
用户正在阅读 Agent 流式输出的推理过程。在 token 1200 附近,模型决定调用 send_email,然后 create_ticket,再 kick_off_deploy。用户看到部分输出并意识到 Agent 误解了请求,在停止按钮上慢了半秒。邮件已经发出,工单已经创建,部署已经在跑。停止按钮取消的是下一个 token,而非上一个 token 的后果。
Bug 不在取消处理程序里。Bug 是那个假设——从团队路线图上所有其他流式 UI 借来的假设——即"逐步渲染的输出"就是"逐步可逆的输出"。工具调用并不遵守这个契约。它们是时间点上的提交,流式层一边欢快地触发它们,响应的其余部分还在生成中,而取消按钮无法沿着线路追赶它们。
这是那种没人认领的失败模式,因为它存在于两个团队各自干净交付的接缝处。UX 团队上线了流式,因为用户研究中表现更好;平台团队上线了工具调用,因为框架支持。两个团队都没有开过会问:当响应已经离开大楼时,"停止"应该是什么意思?
你在实验中上线了一个模型替换。两周过去了，控制面板只变动了 0.1%，读数显示“无显著差异”。你得出结论，新模型与旧模型基本相同，然后继续进行其他工作。
它们并不相同。你的指标从未敏感到足以区分它们。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
