553 篇博文 含有标签「ai-engineering」

大多数生产环境中的多智能体系统都采用单一的温度（temperature）值——这个值通常是从教程中复制过来的，设置一次后就再未改动，并应用于流水线中的每一个智能体。分类器、生成器、验证器和格式化器全都运行在 0.7，仅仅因为 README 是这么写的。这等同于给每个数据库查询都设置相同的超时时间，而不论它是点查询还是全表扫描。在开始调试那些看似模型错误、实则是采样策略错误的故障模式之前，一切看起来都很正常。

温度并非一个全局性的旋钮。它是一个基于角色的策略决策，如果设置错误，会根据偏离方向的不同而产生截然不同的故障特征。

演示每次都能成功。LLM把"显示上个季度收入前十的客户"翻译成完美的SQL，结果瞬间弹出，会议室里所有人都点头认可。然后你把它部署到你实际的数仓上——130张表、1400个字段、十年积累的有机命名惯例——模型开始自信地生成返回错误数字的查询。没有报错，只是答案是错的。

这就是Schema边界问题，也是为什么Text-to-SQL在所有AI能力中，基准测试性能与生产现实之间的差距最大。在Spider 1.0（标准学术基准）上得分86%的模型，在Spider 2.0上准确率下降到约6%，而后者更接近真实企业Schema的复杂度。供应商在干净的玩具Schema上演示，你却要在自己的Schema上部署。

每个构建AI Agent的团队都会做同样的粗略计算：用预期的工具调用次数乘以每次调用的成本，再加上一点缓冲。这个估算在离开白板之前就已经错了——不是错了10%或20%，而是错了5到30倍，具体取决于Agent的复杂程度。40%的Agentic AI试点项目在达到生产阶段之前就被取消，而推理成本失控是最常见的单一原因。

问题是结构性的。单次调用成本估算假设每次推理是独立的。在多轮Agent循环中，它们并非独立。每次工具调用都会增大后续所有调用必须支付的上下文。结果是一条二次方成本曲线伪装成了线性曲线，工程师们直到账单到来才发现这一点。

模型卡会告诉你该模型在 MMLU 上得分 88.7 分。但它不会告诉你：该模型会系统性地将责任归咎于可能性列表中最先出现的技术，导致约 10% 的归因答案在事实正确的情况下语义却是错误的。它不会告诉你：在系统提示中加入"你是一个有帮助的助手"，与留空系统提示相比，会降低结构化推理任务的性能。它不会告诉你：在高负载下第 99 百分位延迟是中位数的 4 倍，也不会告诉你：模型在法律和金融查询上的行为，会因你是否包含合规免责声明而发生明显变化。

这些内容都不在模型卡里。你需要将系统部署到生产环境，然后亲眼看着问题出现，才能学到这些。

2026 年 3 月，一家大型电商平台在一天之内损失了 630 万个订单——美国订单量的 99% 化为乌有。原因不是某次鲁莽的部署，也不是数据库故障。一个 AI 编程工具基于过时的内部文档自主生成并部署了代码，导致每个市场的配送时间估算全部出错。该公司要求 80% 的工程师每周使用该工具，采用率指标一片绿灯，工程纪律却不然。

这才是规模化 Vibe 编程的真实面貌——不是四天就能上线的快速演示，而是第 365 天消失的 630 万个订单。

在一项受控随机对照试验中，使用 AI 编程助手的开发者预测他们的速度会提高 24%。而实际上，他们慢了 19%**。关键在于：他们仍然认为自己变快了。这种认知鸿沟——即生产力的“感觉”与实际交付能力背道而驰——是一种失效模式的早期预警信号，这种模式通常在数月而非数小时内显现。

行业已实现近乎普及的 AI 采用。93% 的开发者使用 AI 编程工具。生产力增长却停滞在 10% 左右。这些数字之间的差距并非工具问题，而是一个不断累积的债务问题，大多数团队在扭转成本变得极其昂贵之前，往往察觉不到它的存在。

你的团队上线了一个基于 LLM 的新功能，进行了为期两周的干净 A/B 测试，并看到了具有统计显著性的提升。你将其全量发布。三周后，留存指标毫无变化，客服工单却在攀升。究竟哪里出了问题？你用教科书式的实验方法去测试了一个不符合教科书假设的处理方案——"处理方案是稳定的"这一前提，在无声无息中已然被打破。

标准 A/B 测试是为确定性或近确定性的处理方案而设计的：按钮颜色变更、参数固定的排序算法、结账流程。而 LLM 功能几乎违反了使经典频率派实验可靠的所有假设。处理方案的方差很高，处理方案本身会因服务商推送模型更新而在实验进行中途发生变化，"成功"难以被清晰量化，而且新鲜感效应足够强烈，足以产生在用户适应后就烟消云散的实验结果。

本文将介绍在这些挑战下使实验仍然有效的调整方法。

一个团队交付了一个文档处理智能体（agent）。它在开发环境中表现完美：读取文件、提取数据、将结果写入数据库，并发送确认 webhook。他们运行了 50 个测试用例，全部通过。

部署两周后，在 100 个并发智能体实例运行时，数据库中出现了 40,000 条重复记录，三个下游服务收到了数千个虚假的 webhook，一个共享配置文件被两个同时运行的智能体各覆盖了一半。

智能体本身没有出错。系统崩溃是因为没有任何一个独立的智能体测试曾被要求与其他智能体共同处于同一个运行环境中。

你写了一份详尽的规范。你描述了任务，列出了约束条件，并给出了示例。Agent 运行了——但做了一些与你预期完全不同的事情。

这就是规范差距 (specification gap)：你写的指令与 Agent 理解的任务之间的距离。这不是模型能力的问题，而是规范的问题。2025 年发布的关于多 Agent 系统失败的研究发现，与规范相关的议题占所有失败的 41.77%，而 79% 的生产环境故障可以追溯到任务是如何规范化的，而不是模型能做什么。

大多数编写 Agent 规范的团队都在犯同一类错误：像给一个称职的同事写邮件一样写指令，然后期望一个没有任何共享上下文的自主系统在数千次运行中正确执行这些指令。

一个 AI 审查器拦截了一个合并（merge）。一名开发者盯着失败的检查，点击“查看详情”，扫视了三段样板文字，然后在没有阅读实际发现的情况下提交了一个“强制推送异常”（force-push exception）。在不到一周的时间里，团队中的每一位工程师都在潜意识里认为 AI 门禁只是背景噪音——是需要被忽略的，而不是需要去参与处理的。

这是大多数构建 AI CI/CD 门禁的团队实际交付的结果，即便底层模型在技术上是有能力的。问题不在于 AI 是否能审查代码，而在于你要求它拦截什么，以及你期望在它拦截时发生什么。

大多数 AI 编码演示展示的是智能体从零构建一个 Todo 应用，或者干净地实现一个全新的 API。而你的代码库，却是一个有着十五年历史的单体应用：充满未文档化的隐性契约、三个团队都依赖但没人完全搞清楚的废弃依赖，以及一个从单一类起步、如今已蔓延到四十个文件的服务层。演示与现实之间的差距，不仅仅是规模问题——更是结构性问题。在把代码库的"钥匙"交给智能体之前，理解这一点，能让你避开一类既隐蔽又代价高昂的失败。

AI 编码智能体确实能帮助处理遗留系统，但只在特定任务边界内才有效。超出这些边界，它们不是显眼地失败——而是生成外观可信、语法正确、语义却有误的变更，这些变更能通过代码审查，最终在生产环境中暴露出来。

你的团队花了三个月时间将 LLM 集成到产品中。模型运行正常，延迟在可接受范围内，演示效果也非常棒。你上线了产品，然后眼睁睁地看着使用率指标停留在 4% 不动了。

这是一个典型的过程。大多数 AI 功能的失败并非发生在模型层面，而是在采用（adoption）层面。其根本原因并非技术问题，而是一系列围绕可发现性（discoverability）、信任和习惯养成而做出（或未做出）的产品决策。理解为什么采用率会失败，以及实际上应该衡量和改变什么，是交付“有用 AI”的团队与仅交付“令人印象深刻的演示”的团队之间的分水岭。