二十年来，软件工程的瓶颈一直是写代码。我们优化了 IDE、自动补全、重构工具和各种框架，让"打字"变得更便宜。我们赢了。可现在瓶颈往下游挪了一步：写代码很便宜，读代码却很贵。PR 机器人可以并行启动十次实现尝试，在你早上喝完咖啡之前就把十个 Pull Request 砸到你的仓库里。你的审查者做不到这一点。
AI 辅助的软件交付，速率限制器已经不再是模型的每秒 token 数，而是你每天能投入多少双"人眼"去看 diff。当这些眼睛被压垮，系统不会优雅地降级——它会开始盖橡皮图章。代码带着 LGTM 🚀 被合入，没有人真正读过。一名资深工程师批准了一份由 AI 写、又被另一个 AI 工具审查过的补丁，三周后一个数据不一致的 bug 吃掉了某个人四十个小时的人生。表面上的正确不等于系统层面的正确，绿色的流水线不等于"我理解了"。
你的编码 Agent 完成了任务。Diff 很小,测试全绿,Lint 干净,而 PR 正文从头到尾只有一句话:"修复 X 模块中的 bug。"远在六个时区之外的评审者打开页面,孤立地阅读 diff,看不出任何毛病,于是批准了一个技术上完全正确、却解决了错误问题的改动。代码合入。两天后,一位客户来问他们一直依赖的某个变通办法为什么突然失效了 —— 这时你才发现,你的 Agent 修复的那个 bug,并不是工单里描述的那个 bug。
代码没问题。评审者很尽责。Agent 也严格按照吩咐做事。问题出在他们之间的那个交付物 —— pull request —— 它丢失了一切本可避免这次失误的信息。
一次隐私评审批准了你的脱敏层。姓名、邮箱、账号、电话——所有这些都在提示词送达模型之前被清理掉了。你的单轮分类器仍然能跑到 94% 的准确率。六周后，你的多步骤智能体开始对类似"Sarah 用于登录的邮箱和她账单记录里的邮箱是同一个吗？"这样的问题给出自信但错误的答案，而且没人能在开发环境里复现。
脱敏层做到了 infosec 团队要求它做到的一切。它同时也悄悄地摧毁了你的智能体推理所依赖的性质：在不同轮次中出现的两个实体指代是同一回事。这个智能体并没有产生幻觉，它读到的是一份转录文本，其中 Sarah 变成了三个不同的人，"同一个"邮箱地址变成了两个互不相同的占位符。
某家保险公司用一整年的客服对话记录微调了一个支持模型。上线不到一周,合规审查员就发现了怪事:这个机器人一直把 "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 系统做限流,就像在高速公路入口立速限标志,而入口里面的车却在自我繁殖。除非限流器理解了这个循环,否则循环就会绕过它。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
