990 篇博文 含有标签「insider」

一个 PR（合并请求）进入了你的评审队列。Diff 显示系统提示词（system prompt）中修改了三个词：Output strictly valid JSON 变成了 Always respond using clean, parseable JSON。这看起来就像是一次文案润色。你快速浏览了一下，CI 检查勾标是绿色的，于是你点击了批准。总耗时：90 秒。

六个小时后，下游解析器开始拒绝带有尾随逗号和缺失字段的响应。结构化输出的错误率从接近零飙升至两位数，一个创收工作流陷入停滞。Diff 中没有任何迹象预示到这一点。Diff 中也不 可能 预示到这一点，因为 Diff 衡量的是错误的东西。

这就是评审提示词变更的核心问题：提示词 Diff 的大小完全无法说明其影响范围的大小。三五个词的修改与三段话的重写都只是文本，而文本 Diff 以相同的视觉权重呈现它们，就像对待任何其他编辑一样。但提示词并不是 描述 行为的文本 —— 它是 导致 行为的文本，而一次编辑所产生的因果爆炸半径在你评审的产物中是不可见的。

只要翻开任何足够长的生产环境对话记录，你都会发现有用户会将同一个问题问上三遍。每一轮的措辞都会稍微改变——代词换成了名词，加上了限定词，到第三次尝试时，那些客气的委婉话也消失了——但底层的请求是完全相同的。他们不是在问三个问题。他们是在问同一个问题，而智能体没能给出答案，用户希望这一次表达的方式能产生不同的效果。

这里的对话记录级信号是如此响亮，以至于近乎显而易见。用户已经通过他们的键盘敲击告诉你，之前的回答没有帮助。他们不需要填写调查问卷，不需要点踩。他们通过再次输入问题直接告诉了你。而在大多数生产环境的 AI 技术栈中，这个信号被评估流水线默默丢弃了，因为这些流水线孤立地对每一轮对话评分，而满意度调查仅在会话结束时触发——到那时，那些重复提问三次的用户通常已经流失，永远不会进行任何评分。

我在上季度合作的一个团队将一个新模型部署到了影子回放（shadow replay）中，结果发现其针对现有模型的胜率仅为 47%。同样的提示词，同样的检索，而该模型在厂商自带的评估中明显排名更高。影子测试框架获取了上周的生产流量，将其通过候选模型运行，把两者的响应都交给 LLM 裁判进行打分，最后宣布这次升级基本上就像掷硬币一样。团队当时差一点当场就回滚了。

问题不在于模型。问题在于回放中的每一条用户消息都已经受限于旧模型的上一轮对话。候选模型在第一轮写出了更好的回答，但日志中的用户是针对一个已不再存在的不同回答做出的回应，从第二轮开始，裁判评估的其实是一段根本没有发生的对话。一个真正更好的、能够改变用户后续行为的模型，是无法与已有的基准真相（ground truth）进行对比评分的。回放机制在潜移默化中奖励了那些停留在旧轨迹上的行为。

你的运营 Agent 通过引用一条内容为 “我们明天发版” 的 Slack 消息，回答了一个关于即将到来的发布会的问题。Agent 将其视为当前的计划，并开始撰写沟通稿。然而，这条消息是六周前发布的。发版早就完成了。检索流水线（retrieval pipeline）根据你衡量的每一项指标——与 “发布日期” 的语义相似度、高于阈值的 top-1 置信度、与项目匹配的来源频道——抓取到了正确的文本块（chunk），而 Agent 基于一句仅在编写时的会议语境下才有意义的话制定了计划。

这里的 Bug 不在模型本身。Bug 在于，“明天” 并不是一个日期。它是一个指向时钟的指针，而该消息编写时的时钟并不是 Agent 阅读时的时钟。你的检索流水线索引了消息的正文，却丢弃了其框架（frame）。

你发布会幻灯片上的可靠性数字，来自一些和用户实际使用的会话完全不像的对话。演示是五轮的：打开、提问、看到一个干净的回答、再细化一次、然后在高音上收尾。而你的核心用户昨天跑的那个会话有三十一轮长，包含两次工具失败（智能体用乐观主义掩盖了过去），最后用户放弃并提交了一张工单。两个会话出自同一个模型。第一个发了新闻稿。第二个被归档为"边缘情况"。

会话长度是评测的一个维度，而演示文化系统性地低估了它。我们衡量单轮准确率，是因为单轮准确率能放进幻灯片里，然后当单会话成功率从一个我们从未在任何图表上画过的悬崖上掉下来时，我们感到惊讶。这个悬崖既不是随机的，也不是尾部事件——它是误差累积、注意力漂移以及那些模型不会重新审视的已承诺假设的可预测后果。每个团队应该问的问题不是"这个模型有多好"，而是"在我们已经在第一到第二十七轮说过那些话之后，这个模型在第二十八轮有多好"。

你曾在十八个月前嵌入了知识库。模型没变。分块（chunks）没变。索引很健康，延迟也正常，召回率仪表盘是一条 0.86 的水平线。然而，客服团队正悄无声息地在工单回复中粘贴错误的文章链接，销售机器人在潜在客户询问新产品时不断翻出已弃用的 SKU，而一名内部用户刚告诉你助手“感觉变笨了”，却说不出具体原因。

一切都没坏。是你的嵌入（embeddings）老了。在你的领域中，“post”一词以前指的是博客文章；现在，语料库中有一半的地方用它指代 Slack 帖子、论坛帖子和职位发布（job posting），而你那十八个月前的向量仍将其视为同一个概念。编码这些向量的模型从未见过这些新含义，从未见过新的产品名称，从未见过品牌重塑，也从未见过引入了三个新术语的监管规定——而你的客户现在正不假思索地使用这些术语。检索系统回答了它知道如何回答的问题，但这已不再是你的用户正在提出的问题。

打开任何一个生产环境智能体的 trace，看一看在用户提问和第一个真正有用的动作之间到底跑了哪些工具调用。你会看到一个 get_user_profile 返回了一个根本没人用的名字、一个 check_status 返回绿色然后再也没被引用、一个 list_recent_orders 的结果被总结成"ok"然后直接丢掉。这些调用没有一个改变了最终答案。但每一个都花了真金白银的钱、真实的延迟，以及在 trace 里真实占一行。你的智能体已经学会了表演勤奋——而表演勤奋如今是你最大的单一浪费来源。

这就是填充式工具调用：智能体发出一个动作，不是因为它需要那个结果，而是因为"先想一想，再行动"的整体模式在训练时被反复奖励，多到模型现在会把"显得周全"当作回答任何问题的副作用来执行。这是一个 LLM 版本的初级分析师，故意打开五个根本不会读的标签页，好让坐在对面的高级同事看到自己很忙。区别只在于：初级分析师会累。智能体永远不会。

你的 AI 功能看起来很健康。周活跃用户持平或微涨,满意度评分为正,仪表板告诉你应该多做这类功能。PM 在下一轮规划会议上引用了这个指标,工程主管点头同意,路线图上又多了一个相邻功能。

然后有人按用户使用时长对图表进行分段,画面瞬间反转。老用户——那些在功能上线时就已存在的用户——每天都在深度使用它。首次用户在两次交互内就跳出了。那条"持平"的曲线其实是两个队列在相互抵消:一条向上倾斜的幂律曲线,和一条向下倾斜的流失曲线,加总成一个谎言。

凌晨两点，你的客服智能体呼叫一位真人。那位真人已经请假一周了。休假自动回复就躺在智能体正在读取的同一个邮箱里。智能体仍然 ping 了过去。自动回复弹了出来。智能体礼貌地道了声谢，然后又 ping 了一次——因为回复里没有它在等的那个工单解决码。十二个循环之后，另一支团队的人偶然发现这个未读会话已经堆了六十条消息，才手动去把值班的人叫醒。

智能体完全照着 prompt 说的做了。Prompt 让它升级给一个人。这个"人"在它眼里只是一个字符串，不是一个角色。这个字符串不知道什么叫 PTO。

你周二下午花时间删除了一个已经废弃的工具模块。你清理了导入，运行了类型检查器，看着 CI 变绿，然后合并了 PR。周三上午，一个新的 Agent 会话查看同样的代码，认定代码库“缺失”了一个小型助手函数，于是又把那个废弃的模块写了回来——名字相同，形状相同，只是风格略有不同。昨天批准删除的评审者现在不得不回想为什么要删掉它，找到当时证明其合理性的对话，并再次解释一遍。Agent 并没有出现故障。它只是完全按照其上下文的要求在行事。

这是编码 Agent 的结构性可靠性问题，没有人通过提示词工程（Prompt Engineering）来解决：Agent 的上下文起始于代码库的当前状态，而不是该状态为何如此的历史。你移除的文件没有留下 Agent 可见的痕迹。你迁移掉的依赖项只是 npm 上的另一个包。你刻意删除的不稳定测试（Flaky test）是一个等待被“修复”的覆盖率缺口。缺席——即你做出的决策留下的负空间——是不可见的。

这一切始于一个 cron 作业。每晚凌晨 2 点，一个脚本会被唤醒，拉取当天的记录，通过模型运行，将结果写入表中，然后继续休眠。这是解决该问题的最简单形态，而且在整整一年的时间里，它确实是最合适的形态。没有人去考虑它，因为没有人需要去考虑。

接着有人问结果能否在早上 8 点而不是中午准备好。然后有人问用户是否可以按需触发单条记录的运行。接着一位产品经理问是否可以让应用内的体验“感觉像是即时的”。每个请求都是合理的。每一次改动都很小。而且从始至终，没有人打开过一份名为“重新架构推理流水线”的文档，因为没有任何一次单一的改动让人觉得像是在重写。

18 个月后，你拥有了一个披着批处理作业外壳的延迟敏感型在线服务。它的 p99 无人衡量，队列无人清理，且存在一种失效模式：由于流水线被构建为重试整个批次，一条错误记录就会导致面向用户的请求停滞。这是 AI 系统中最常见的架构失效之一，而且它几乎从未作为一项决策出现，而是作为对一系列合理请求不断说“是”而产生的缓慢累积。

一家中型 SaaS 公司的支持智能体正确处理了一起计费纠纷。它读取了工单，检查了客户账户，发现了重复收费，执行了退款，并发送了一封礼貌的确认邮件。每一步都是正确的。唯一的问题是时间戳：客户所在时区的凌晨 3:14。客户在睡梦中醒来看到退款通知，以为自己的信用卡被盗刷了，在公司有人醒来解释之前，就向银行提交了欺诈申诉。

在那个工作流中，没有任何环节是传统意义上的 Bug。智能体没有产生幻觉，没有选错账户，也没有算错退款金额。它只是完全不知道凌晨 3 点是一个告知别人资金变动的糟糕时间。这个模型读过的人类睡眠习惯相关文本比世界上任何人都多，但它的行为表现仍然像是在对待一个随时待命的服务端点，只要你调用它，它就是清醒的。