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

浏览任何成熟工程团队的 PR 队列，你都会看到同样的现象：一个四行的 Bug 修复会引来三轮关于命名、错误处理和测试覆盖率缺失的评论；而对系统提示词（System Prompt）的四十行修改却能凭借一句 “LGTM, ship it” 轻松过关。作者对此不以为意，因为差异对比（diff）看起来就像文档；审查者也无所谓，因为他们对于那段英文块中什么是“好”没有心理模型。结果是，一个具有功能发布级别影响范围的提示词更改，却仅以修复拼写错误的门槛通过了审查。

这是每个在生产环境中使用 LLM 构建产品的团队所面临的隐秘质量危机。代码库拥有数十年积累的纪律——Linter、类型检查、代码所有者（Code Owners）、测试关卡、发布窗口。而真正引导模型的产物——系统提示词、评估准则（Eval Rubric）、工具描述、少样本示例（Few-shot Exemplars）——虽然存放在同一个仓库中，却通过为英文散文设计的审查流程进行发布。因此，提示词回归、评估准则漂移和工具模式（Schema）损坏，却能以团队永远不会接受的代码质量标准通过。

高管演示进行得非常完美。模型回答了精选的问题，智能体（agent）完成了工作流，屏幕录像已保存到公司网盘，发布日期也已排入日程。六周后，上线部署遭遇惨败，复盘报告不言自明：模型需要更多打磨，提示词（prompt）需要更多迭代，团队低估了从原型到生产环境之间的工作量。

这种叙事是错误的，而且代价昂贵，因为它让团队回去重复那些已经失败的工作。演示并不是生产环境的“欠打磨”版本。它只是团队从未测量过的分布中的一个“单一采样”（single sample）。那个惊艳瞬间只是模型针对相同输入可能产生的数千个结果中的一次实现，而团队却把最好的那次当作典型表现发布了。演示与生产环境之间的差距不是质量下滑，而是团队尚未察觉的“方差”（variance）。

这种思维转变至关重要，因为方差问题的解决方法与打磨问题的解决方法完全不同。“打磨”导向会说：“迭代提示词，微调模型，雇个更好的产品经理。”而“方差”导向则会说：“在输入分布中进行 n 次采样之前，你根本不知道自己手里拿的是什么。”这两种诊断会产生不同的路线图、不同的预算以及不同的事故模式。那些在 2026 年能够可靠交付的团队，都清楚自己面临的是哪种问题。

一位平台工程师修改了公司“品牌风格”序言中的开场白——这是用于统一所有面向客户的助手语气的一行代码。这项改动通过 feature flag 发布。到了周二，搜索团队的相关性退化指标激增，支持机器人的评估通过率下降了四个百分点，入职引导 Agent 的重试率翻了一倍。这些团队中没有一个动过自己的代码。他们都没有收到任何预警。平台工程师对这一切一无所知，因为没人收到过类似的警报：“你的修改刚刚搞坏了三个下游功能。”

这就是定义 AI 团队成立第二年后的典型失效模式。第一年，每个团队都在各自的角落闭门造车。第二年，这些角落开始共享产物——这里一个提示词片段，那里一个种子评估集，或者一个被当作协议复用的工具 Schema。当这种共享变得隐性时，AI 功能之间的依赖图就变得不可见了。你现在拥有的是一个没人能叫出其边缘名称的分布式系统。

解决这一问题的方法论（discipline）并不是一个新平台，而是绘制这张图。

我上个季度合作的一个团队发布了一个 AI 助手，并附带了一整套完备的支撑文档：一个提醒 AI 可能会生成不准确结果的产品内工具提示（Tooltip）、一篇题为“助手如何工作”的帮助中心文章、一份处理升级问题的内部支持操作指南（Runbook），以及一份列出了底层模型、助手可调用的工具及其覆盖的数据领域的公开模型卡（Model Card）。发布过程非常顺利。六个月后，提示词（Prompt）被修改了 14 次，模型在不同层级间进行了切换，拒绝行为（Refusal Behavior）发生了微妙的变化，增加了两个新工具，一个工具被废弃但未从提示词中移除，语言设置也从仅限英语扩展到了 9 个语种。

每一份文档都出错了。并非灾难性的错误——而是那种一句话半真半假、描述的功能与模型实际表现不再匹配、记录的拒绝模式在新模型中从未触发、或者帮助文章里出现的工具名称助手根本不会调用的那种错误。这类错误会产生持续不断的令人困惑的支持工单，当 AI 做了文档说它不会做的事情时会导致客户信任倒退，并且——因为公司在受监管的垂直领域销售——还会产生一个微小但真实的合规漏洞，而 AI 团队中没有人想到要跟踪这一点。

我上个月交流过的一个团队，在四个星期内将一项新的 Agent 功能从 1% 的用户灰度推广到了 50%。聚合质量指标保持在噪声范围内，延迟也保持在 SLA 之内。他们正在准备 100% 全量发布的备忘录时，支持队列突然“起火”了——一个拥有六工具研究工作流的客户，自 10% 灰度阶段以来就一直在接收静默损坏的输出。困难查询（Hard queries）一直存在，均匀地分布在每个分群中，被平均化到了底噪中。直到一个高频用户在大规模使用中撞上了这些问题，大家才发现。

这不是监控失败，而是灰度发布维度的失败。功能标志工具（Feature flag tooling）——包括 LaunchDarkly、Flagsmith、Unleash 和 Cloudflare-Flagship 等所有此类工具——都假设爆炸半径（blast radius）随接触到的人数成比例扩大。对于确定性软件，这在很大程度上是正确的：一个空指针异常（NullPointerException）要么影响所有人，要么谁都不影响，将其暴露给 1% 的用户会将可见的爆炸范围限制在 1%。但对于 AI 功能，爆炸半径并不在“人”这个维度上扩展，而是在“输入”维度上扩展。而几乎没有人会在输入维度上进行灰度发布。

打开公司里那位上线真实的 AI 功能超过六个月的工程师的日历。数一数那些重复出现的 “30 分钟同步 —— 关于 Agent 的问题” 邀请，那些最终被预定的即时 “能耽误你 15 分钟吗？” Slack 消息，那些被标记为 “可选” 但他们实际上不得不参加的架构评审，以及最初只是周五下午的一个时段、现在却每天吞噬两个小时的 Office Hours。然后看看路线图，追踪哪些功能取决于该工程师尚未做出的决定。两者的交集才是你真正的发布时间表。Jira 看板只是虚构。

这就是 AI Office Hours 瓶颈，它在 2026 年的 AI 组织中是核心承重约束，尽管组织里没人会大声说出来。团队快速扩展了 AI 功能开发 —— 每个产品小组都拿到了模型预算，每个 PM 都学会了写 Prompt —— 然后把每一个 “这个模型对吗”、“这里该不该用 RAG”、“我们的评估设计是否有效”、“为什么缓存命中率很奇怪” 的问题都抛给了唯一那个真正上线过足够多生产环境 AI 功能、能给出答案的工程师。六个月后，那位工程师的日历成了半个路线图的限速试剂，“我需要找他谈 30 分钟” 成了你的事故响应本该明确化的核心升级路径。

当团队发布“每个席位 $X 美元的无限 AI”订阅层级时，定价会议上没有人意识到这是一个衍生品头寸。它看起来就像一个普通的 SaaS 定价页面——一个数字、一个层级、一个行动召唤（CTA）。但现在，该页面带来的每一美元收入都暴露在供应商设定的 Token 成本曲线之下，而该供应商的路线图根本不在乎你的毛利率。你写的不是定价页面，而是一份针对 Token 波动性的裸卖空合约，而行权价就是你的供应商在下季度收取的费用。

数学计算很快就显现出结果。少数重度用户发现了工作流，并开始在他们能塞进的最长上下文中运行它。竞争对手的 UX 变化重新训练了中位数用户，让他们发送长出 40% 的查询。你的功能所绑定的前沿模型因为旧版本层级被弃用而迎来了每百万 Token 价格的上调。其中任何一项都是你在单个季度内无法通过定价页面逆转的利润事件——而且它们往往会成群结队地到来。

在发生第一起涉及六位数损失的智能体（agent）事故后的第二天早晨，董事们不会询问模型是否处于世界领先水平。他们会要求查看风险登记簿（risk register）中列出该场景的那一行、签字的负责人，以及董事会上次审阅该记录的日期。如果你的企业风险登记簿中包含了网络、供应商、监管和运营风险，但唯独没有“自主智能体在我们的凭证下采取了导致客户可见损失的操作”这一行，那么你即将在董事会上花时间解释，为什么其他每一类风险都有的应对方案，在刚刚让你赔钱的这一类风险上却偏偏缺失。

这不再是假设。Gartner 预测，到 2026 年底，企业将面临超过 1000 起因 AI 智能体造成损害而引发的法律诉讼。在短短一年内，AI 相关风险在安联风险指数（Allianz Risk Barometer）中的排名已从第十位跃升至第二位。保险公司现在在董监高责任险（D&O）续保调查问卷中询问：董事会如何将 AI 纳入公司风险登记簿，以及如何跟踪第三方智能体风险敞口。下文列出的项目代表了一个可靠的答案应具备的内容，以及 AI 功能负责人必须据此进行辩护的节奏。

晨会上出现了一个回归问题：支持代理昨晚回答错了三个客户问题。有人说：“我们试试在这个路径上用 Opus，看看能不能解决。”四十分钟后，评估通过率回升了，团队关闭了工单，而该路径上的推理账单悄然翻了三倍。六周后，同样形式的回归出现在另一个路径上，并采用了同样的修复方法。你的团队刚刚训练出了一种巴甫洛夫反射：质量回归 → 增加算力。更大的模型是你的技术栈中最昂贵的调试工具，而你现在却首先想到它。

问题不在于更大的模型没有帮助。它们确实有——有时甚至很大。问题在于，更大的模型是一种绝对占优的“掩盖”策略。当提示词指令冲突、检索返回了过时的块、工具描述被误读，或者评估集没有覆盖失效的分布时，更强大的模型会绕过这些故障而不修复其中的任何一个。下一次回归仍具有相同的根本原因，账单已经复加，而底层系统变得更加脆弱，而非更加稳健，因为升级带来的缓冲空间让所有人都不再去探究底层逻辑。

过去，那种“在标签页中运行模型”的故事很容易被忽视：小模型、新奇的演示、在笔记本电脑风扇狂转前只能运行 30 秒的 Whisper 语音转录。现在，那个时代已经结束了。量化技术得到了改进，WebGPU 已经在所有主流浏览器中发布，设备端缓存获得了持久配额，现在 4-bit 3B 模型在价值 500 美元的笔记本电脑上输出 token 的速度，已经快到让用户感到“流畅”。“这是否应该在服务端运行？”不再是一个默认选项 —— 这是一个关键的架构决策，如果你的产品团队每次都直接接受平台团队的第一个方案，那么他们就在无意中做出了这个决定。

随之而来的错误比演示效果变差更严重。团队为整个产品选择一种后端 —— 通常是服务端推理，有时是浏览器推理 —— 然后在每个不匹配的功能上付出错误的代价。对隐私敏感的功能输给了对延迟敏感的功能，因为架构强制给出了单一答案。或者更糟，团队因为演示时的惊艳效果选择了浏览器原生方案，然后发布了一个“机群级”的体验，导致长尾设备群体中 30% 的用户获得了一个性能降级的产品，而仪表盘却无法察觉。

浏览器原生 AI 并不是更快的 TensorFlow.js。它是一个具有不同 SRE 逻辑、不同成本模型以及四个无法坍缩为单一答案的权衡维度的不同运行时。将其视为“API 调用的廉价版本”是 2026 年最典型的架构错误。

我认识的一个团队在上个季度通过将支持邮件分类流程从顶级模型（frontier model）迁移到中级模型，将推理费用降低了 40%。CFO 还专门发了感谢信。六个月后，客户支持团队增加了两名全职员工（FTE），平均解决时间上升了 35%。没有人把这些点联系起来，因为这些“点”分布在不同的仪表盘上：推理费用在平台团队的仪表盘上，而支持工作量在运营团队的仪表盘上。在所有人都在追踪的唯一指标上，这次迁移看起来是一次胜利。但指标错了。

这就是“单 Token 成本”（cost-per-token）陷阱。你的账单告诉你花了多少钱在 Token 上，但它无法告诉你每个“正确”任务花了多少钱，因为推理供应商根本不知道在你的领域里什么是“正确”。他们卖给你的是原始算力。而你买的是结果——或者你以为你买的是结果。这两个单位之间的差距，就是 AI 单元经济（unit economics）悄然崩溃的地方。如果不去衡量正确的分母，团队就只算了一半的账，而在另一半的交付上处于盲目状态。

A 团队的智能体宣传其成功率为 99%。B 团队的智能体也宣传 99%。调用这两者的全新联合工作流在状况良好时成功率为 98%，而在状况不佳时仅为 96% —— 负责该联合工作流的团队现在成了两个他们不拥有、无法在本地复现、且未编写评估集的系统的事实上的 SRE。每个上游团队都达到了其 SLO（服务水平目标）。但复合产品却未达标。边界正确一侧的报警器却始终保持沉默。

这是独立失败率的数学问题，自从组织开始允许智能体相互调用以来，它就一直潜伏在显而易见的地方。五个可靠性为 99% 的组件会给你带来 95% 的端到端可靠性。十个组件则会降至 90%。一个每步成功率为 95% 的 20 步流程，其最终成功率仅为 36% —— 超过一半的操作在完成前就会失败。当一个工作流链接了 50 个组件时 —— 一旦企业级智能体开始调用子智能体，再由子智能体调用工具智能体，这种情况并不罕见 —— 一个每个环节都“99% 可靠”的系统，在大约十次请求中就会失败四次。

研究人员在分析了超过 150 个任务中的五个流行多智能体框架后，发现失败率在 41% 到 87% 之间，其中排名前三的失败原因是：步骤重复、推理与行动不匹配，以及对终止条件的忽视 —— 观察发现，与单智能体基准相比，非结构化的多智能体网络会将错误放大高达 17 倍。这其中的数学逻辑并不深奥。问题在于，组织的 SLO 表、仪表板、轮值安排和 PRD 仍然是以单个智能体为单位进行定义的。