861 篇博文 含有标签「insider」

观察一个开发者使用代理型 IDE 二十分钟，你会看到同样的小剧场上演三次。代理开始了一个长任务。在两次工具调用后，用户意识到他们想要一个函数式组件而不是类，或者想要 v2 接口而不是 v1，亦或是想用 Vitest 而不是 Jest 编写测试。他们手中只有一个杠杆：红色的停止按钮。他们按了下去。代理在编辑中途阵亡。他们复制并粘贴上一个提示词，加上修正，然后为前八分钟的工作支付了两次费用。

中止按钮是错误的交互设计。它将“我想调整计划”和“我想丢弃这次运行”视为同一种动作。在实践中，它们就像方向盘和弹射座椅一样迥异，而将两者混为一谈，正是为什么许多代理产品在任务耗时超过一屏输出时就显得脆弱不堪的原因。

一位产品经理拉出了下个季度的路线图。其中三个功能被标记为“依赖下一代模型”。没人问如果下一代模型延期、比演示版本缩水 20%、或者发布的版本仅限你的客户没有资格使用的企业级层级，会发生什么。六个月后，这三种情况都发生了，团队现在正在针对实际发布的模型重建两个季度的架构——而这个模型的形态与他们当初计划的完全不同。

这就是“每周模型路线图”：将尚未发布的能力声明视为确定性的依赖。这是将 12 个月的计划变成 30 个月计划最可靠的方法之一。而在当时，这看起来几乎没有风险，因为每个厂商的演示都让人觉得大势所趋。计划的破坏是隐形的，直到延期产生复合影响。

这种天真的算法是这样的。我们的主供应商拥有 99.3% 的可用性。增加第二个具有类似独立性的供应商，同时故障的概率就会降至大约 0.005%。成本翻倍，风险降至两百分之一。工程负责人批准了双倍预算，轮值报警在供应商宕机时也不再响起。电子表格显示，这是路线图上性价比最高的可靠性投资。

六个月后，电子表格错了。评估套件（eval suite）的运行时间变成了三倍，提示词（prompt）修改需要提交两个 PR，每周的回归报告中有两列内容相互矛盾，而且没人记得预发布环境的备选方案当前路由到了哪个供应商。一旦团队核算了用于保持两条路径校准的人力工时，双倍预算实际上更接近 4–5 倍。第二个供应商在技术上仍在提供流量，但一半的功能已被悄悄锁定在其中一方，因为保持两者同步已经变得不再划算。

这就是多模型成本陷阱。可靠性算法是正确的；但团队搞错的是运营层面的算法。接下来是对引入多供应商后的成本分解、大多数团队应该首先尝试的“单供应商加降级模式”方案，以及真正证明这种非线性复杂性合理性的少数准则。

一名高级工程师在六个月前离职了。她负责管理用于路由客户支持工单的分类器适配器——这是一个基于 847 个手动标注样本训练的 32 秩 LoRA，挂载在一个还有 43 天就要停用的基础模型上。没人记得为什么从最初的 2,000 个样本中选出了这 847 个。训练数据存在一个 S3 存储桶里，由于其生命周期策略，超过一年的对象会被自动清除。她的笔记本电脑已被抹除。那个微调笔记本（notebook）中有一个单元格调用了一个预处理函数，该函数是从她个人的 dotfiles 仓库导入的，而现在那个仓库是私有的。

这就是“孤儿适配器”（Orphan Adapter）——一个比其维护者、数据甚至其所基于的基础模型寿命更长的微调模型。它存在于你的生产栈中，路由着真实的流量，而团队中没人能重新构建它。停用邮件并没有制造这场危机，它只是揭露了危机。

用户向你的智能体提问。Token 开始流式输出。写到第三句时，模型写道“实际上，让我重新考虑一下——”并转向一个不同的答案。修改后的答案更出色。用户却关闭了标签页。

这就是输出承诺问题（Output Commitment Problem），它是已发布 AI 产品中被低估得最严重的 UX 失败案例之一。工程师思维将自我修正视为一项特性——模型注意到了自己的错误，这意味着系统正按预期运行。而用户感知思维则将其视为一场灾难——产品现场演示了其最初自信的断言是错误的。这两种解读都是正确的，且它们本身无法调和。

核心的不对称性在于，流式传输让思考过程变得清晰可见，而清晰的思考就是可审计的思考。一个静默地产生幻觉然后给出简洁最终答案的模型看起来很专业。而同一个模型，如果流式输出每一个不成熟的想法，看起来就像是在胡言乱语。答案的质量是相同的，但感知却截然不同。

用户将一份冗长且复杂的错误报告粘贴到你的 AI 助手。它看起来像是一个经典的空指针问题，其措辞和代码布局与数以千计的 Stack Overflow 帖子如出一辙。模型自信地做出了响应，引用了常用的修复方案，听起来非常权威。用户向它表示感谢。然而，错误依然存在。这份报告实际上关于的是竞态条件 (race condition)；空指针的表述只是用户描述症状时的偶然方式。

这是在生产环境 LLM 系统中捕捉难度最高的一类 Bug。模型没有拒绝回答，没有推诿。它没有幻觉出一个虚假的 API。它只是极其流畅地解决了错误的问题，而下游的所有环节——包括用户、你的评估流水线、你的护栏 (guardrails)——都看到了一个看似合理且切中要害的回答，然后继续下一步。我将此称为模式匹配失败 (pattern-matching failures)：模型锁定了查询的表面特征，并针对与实际提出的问题相邻的问题给出了一个自信的答案。

智能体（Agent）打印了一个五步计划。第三步是“从发票服务中获取用户的账单历史”。追踪链路（Trace）显示，第三步实际上调用了订单服务，关联了一个过时的客户表，并产生了一个看起来正确的数字。输出通过了评估（Eval）。六个月后，财务部门发现仪表盘与事实源（Source-of-truth）悄然出现了 4% 的偏差，复盘时才发现了这次回归（Regression）。

没有人写出 Bug。规划器（Planner）写下了一份执行器（Executor）从未签署的契约。

这就是“计划与执行”架构在其优雅的架构之下所掩盖的失败模式。这种模式被推销为一种赋予智能体长程连贯性的方式：由一个强大的模型起草计划，较弱的模型执行步骤，计划起到脚手架的作用。在实践中，计划只是一种“营销产物”——在 t=0 时发出的一个看起来合理的预告，随后在 t>0 时发生的每一件趣事都会迅速令其失效。追踪链路显示了计划，追踪链路也显示了行动。但几乎没有人去衡量两者之间的距离。

你刚接入的前沿模型对你的竞争对手早有定见。对于你产品旨在反驳的那些难题，它有一套默认答案。它对你所在的领域有一套“最佳实践”，而这些实践往往源于训练语料库中占据主导地位的内容；对于你在设计文档中反复纠结的每一个争议性决策，它都暗自偏向于传统做法。这些都不会出现在你的系统提示词（system prompt）中，也不是你写的。在涉及到你产品核心差异化的查询上，模型会先倾向于那些默认设定，而不是你告诉它的内容。

大多数团队在发布产品时，都把模型当成了一张可以任意配置的白纸。写好角色设定（persona），列出规则，粘贴品牌语气指南，运行几个能产生正确回答形式的 QA 提示词，然后就大功告成了。通过审核的提示词往往是处理简单查询的——在这些查询中，模型的先验认知（prior）恰好与你的预期相符。而那些真正有趣的查询，即如果产生通用回答就会让你的产品惨败的查询，几乎从未进入提示词迭代循环。在这些查询中，先验认知正在悄无声息地取胜。

当检索质量回退（retrieval quality regression）第一次出现在你的值班频道（on-call channel）时，调试路径几乎总是指向一些令人意外的地方。不是嵌入模型（embedding model），不是重排序器（reranker），也不是提示词（prompt）。罪魁祸首通常是对分块器（chunker）的一行改动——比如更换了分词器、调整了边界规则或步幅（stride）——而这行代码是三个冲刺（sprint）前有人合并进预处理 notebook 的。这次修复没有触及任何生产代码。它在夜间重建了索引。而现在，所有租户的准确率都下降了四个百分点。

分块器就是数据库 Schema。你提取的每个字段、划定的每个边界、选择的每个步幅，都定义了存入向量索引的“行”的形状。修改其中任何一项，你就在改变索引的 Schema。而你系统的其他部分——检索逻辑、重排序特征、评估框架、下游提示词——都依赖于这个索引，并假设它是稳定的。但由于分块器通常存在于 notebook 或一个没人将其视为“基础设施”的小型 Python 模块中，这些改动在上线时往往只被当作配置微调，但其爆炸半径却相当于执行了一次 ALTER TABLE。

向用户展示一个带有 AI 答案的界面，且每句话末尾都附有链接，还没等他们读完任何一个引用的段落，他们的信任度就已经飙升。这正是企业级 RAG 的全部营销卖点：“有据可查”、“有源可循”、“可验证”。这也是 AI 工程领域中交付最多、但测试最少的说法。最近的基准测试发现，50% 到 90% 的 LLM 回复并未得到其引用来源的完全支持，有时甚至与来源相矛盾。在对抗性评估集中，最先进模型生成的引用中有高达 57% 是不忠实的：模型根本没有真正使用它指向的文档。这些引用是事后补上去的，目的是为了让模型已经决定给出的答案显得合理。

这不是检索层面的 Bug。即便你拥有完美的检索系统，仍然会得到虚假的引用，因为这种失效是架构性的。生成器先写出文字，然后再缝补链接。这些链接看起来像证据，实则只是装饰。

强化思维在处理新颖的推理任务时表现出色。但在工具边界（即你的智能体必须选择调用哪个函数、何时调用以及传递哪些参数的时刻），同样的思维预算往往会适得其反。模型会权衡三个等效的工具，而快速模型原本只需要一个 token 就能消除歧义。它在原本不存在歧义的地方制造出听起来合理的歧义。它消耗了一千个推理 token 来反复质疑那个显而易见的 search 调用，结果最后还是调用了 search。你为一个不需要推理的决策支付了推理税。

这是 2026 年智能体系统中隐形的成本中心：问题不在于推理模型本身（其擅长领域的定价是合理的），而在于在错误的环节部署了推理模型。这种反模式（anti-pattern）就潜伏在显而易见的地方，因为顶层任务看起来很难（如“回答用户的问题”），所以团队将整个循环都包裹在深思熟虑的模式中，却从未意识到 80% 的思维预算都花在了对工具选择的微观决策上，而这些决策模型凭第一直觉就已经选对了。

在值班文档的表格上，搜索工具的错误率为 2%。事故审查报告称，在三个小时的时间窗口内，Agent 平台的故障率为 20%。没人对这两个数字有异议。搜索团队没有过错。平台团队也没有发布 Bug。这两个数字之间的差距就是故事的全部，而这是一个关于算术的故事，而不是工程能力的平庸。

重试逻辑是 Agent 系统中最常被借用且最少针对性调整的模式之一。团队从他们的 REST 客户端复制 tenacity 装饰器，将它们堆叠在 SDK、网关和 Agent 循环中，然后直接上线。每一层单独看都是合理的。但这种组合就像是一件指向集群中最不稳定依赖项的攻城武器，而且它恰恰在那个依赖项最需要降低负载的时刻开火最猛烈。

本篇文章将探讨这种数学逻辑是如何运作的，为什么 Agent 循环比请求-响应系统更剧烈地放大错误，以及如何通过重试规范防止瞬时波动演变成印着你自己公司 Logo 的关联性宕机事故。