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

每天，你的智能体（Agent）都会把失败案例打包成“礼物”发还给你。一名用户点击了“踩”。另一名用户读完答案后一言不发，直接关掉了标签页。第三名用户将同一个问题改写了三次，直到智能体终于答对。每一个都是带标签的失败案例 —— 真实的输入、真实的上下文、系统失误的真实时刻 —— 由那些最希望系统运行正常的人免费提供给你。

大多数团队都会把这些信息全部丢掉。并非故意为之。点击“踩”只是增加了仪表盘上的一个计数；放弃使用表现为留存图表中的一次下滑；改写问题看起来就像普通的日常使用。没有任何东西能将信号及其产生的上下文一并捕捉，因此也就无法进行回放、分选（Triage）或转化为测试用例。你所拥有的最丰富的评估数据源正擦肩而过，而团队却还在继续手动编写合成的评估（Eval）案例。

这就是你从未构建的智能体反馈循环。它不是你忘记购买的某种工具，而是一条流水线 —— 从用户信号，到分选后的失败案例，再到新的评估案例 —— 它之所以未能建立，与技术本身关系不大。

财务部门对你发布的每个功能都会问一个问题：“每个用户的成本是多少？”对于传统功能，答案是一个数字。页面渲染、数据库查询、推送通知 —— 每一个的边际成本在不同请求之间几乎没有波动。你测量一次，乘以用户数量，预测就能成立。

AI 功能打破了这种契约。问一下“这个智能体（agent）每次请求的成本是多少”，坦诚的回答不是一个数字，而是一张直方图。同一个智能体，处理上一个工单可能只花 2 美分，但在处理下一个工单时可能会烧掉 4 美元。因为用户问了一个模糊的问题，智能体循环调用了 11 次工具，而每次调用都将不断增长的对话全文重新输入模型。这两次请求的平均值 —— 2 美元 —— 既无法描述其中任何一次请求，更无法真实反映最终账单。

这就是陷阱。当你向财务提交一个单一的平均成本时，你并不是在简化混乱的现实。你是在报告一个在特定的、昂贵的方向上完全错误的数字。

编程面试的设计初衷是为了隔离单一变量。把一个人关在房间里，给他们一个问题，拿走他们的参考资料，观察他们是否能独立将问题转化为可运行的代码。这种形式的一切——白板、空白编辑器、禁止查阅资料——都是为了剥离协作者和工具，从而衡量一种被隔离的技能：这个人能否在压力下独自编写出正确的代码。

这项技能已不再是工作中需要锻炼的技能了。2026 年的日常工程工作是工程师与智能体（Agent）之间的协作。工程师决定构建什么，智能体起草大部分代码，而工程师真正的任务是审查、纠正，并判断智能体何时在“自信地犯错”。面试衡量的是独立产出代码的能力。而工作奖励的是指导一个不知疲倦、快速、偶尔产生幻觉的协作者。代理指标与目标已经脱节，而大多数招聘流程尚未察觉到这一点。

这并不是在抱怨作弊，尽管作弊是每个人都关注的症状。这是一个测量问题。当你无法再观察到测试旨在隔离的变量时，测试就不再产生信号——而一个在所有人仍然信任它的同时却不产生信号的测试，比根本没有测试更糟糕。

一个新的嵌入模型登上了排行榜。它比你 18 个月前发布的模型得分更高，API 只需更改一行代码，甚至维度也一致。有人提了一个工单：“升级嵌入模型”。这看起来就像更换一个日志库一样简单。

事实并非如此。嵌入模型并不是你检索系统的一个普通组件——它就是你检索系统所处的坐标系。更换它并不会改进你的索引，而是会让索引失效。而最残酷的地方在于，系统并不会崩溃。没有异常，没有失败的健康检查。你的搜索只是开始返回微妙不同的结果，而在 RAG 管道中，“微妙不同”意味着不同的文档被喂给了模型，也就意味着不同的答案最终传达给用户。

你在 18 个月前编写了这套评估集（eval set）。那时它是一个非常有用的工具：低价模型的得分是 71%，更好的模型得分是 84%，而当出现回归（regression）时，分数会下降并被察觉。这套测试套件在 CI 中赢得了一席之地。于是你不再关注它了。

今天再运行它，每个候选模型的得分都是 96、97、98。新版本的得分与旧版本相同。你怀疑表现较差的模型与你认为更好的模型得分也一样。仪表盘上的数字依然显示为绿色，检查依然通过，但它实际上什么也没告诉你。你的评估集并没有坏。它只是变简单了——因为底层的模型变强了——而没人在意它失去区分度的那个瞬间。

这就是评估饱和（eval saturation），这不仅是你可能遇到的失效模式，更是任何静态测试套件在足够长的时间跨度下必然走向的终局。一个所有模型都能通过的测试，已经不再是测试了。

每一个成熟的 AI 团队构建其评估套件的方式都如出一辙，而且几乎没有人会公开说出那个潜台词。生产环境中出现了一个故障。有人写了一份复盘报告。一名工程师将该事故提炼为一个测试用例，将其添加到评估套件中，于是仪表盘再次变绿。重复这个循环一年，你就会拥有几百个案例、一个令人满意的通过率，以及一个足以让你在演示幻灯片上感到无比安心的数字。

潜台词是：那个评估套件其实是一个博物馆。每一件展品都是团队已经挺过来的故障类别。98% 的通过率证明了你的系统可以抵御过去 —— 抵御那些已经发生过的特定破坏方式 —— 而对于模型迁移、提示词编辑或用户行为转变即将引入的新型故障模式，它几乎给不出任何参考。评估集是一个披着先行指标外衣的滞后指标。

你发布了一个模型升级。评估套件的分数从 87% 提升到了 91%。更新日志信手拈来，领导层纷纷鼓掌，然而那些真正重要的仪表盘——用户满意度、工单升级率、点踩率——却毫无动静。毫无起色。甚至可能略微变差了。

这是 AI 工程中最令人迷惑的失败模式之一，因为表面上没有任何东西坏掉。评估运行正常。数字是真实的。在你测试的 600 个示例中，模型确实有所改进。问题在于，这 600 个示例是你构建套件那一周的流量快照，而在那之后的几个月里，你的用户已经走出了画面。

打开任何成熟的智能体（agent）代码库，问一个简单的问题：需求文档在哪里？不是融资演示文稿，不是发布文档，也不是那个上次更新还在第三季度的 Notion 页面。那份具体且明确地规定了这个智能体应该做什么的产出物在哪里？

对于大多数团队来说，诚实的回答是：评测套件（eval suite）。那里有一个测试用例文件夹——输入与预期输出成对出现，还有评分标准、评判提示词——以及一个显示通过或失败的 CI 门禁。那个文件夹是唯一一个将“正确”定义得足够精确以供执行的地方。其他一切都是散文，而散文会随时间发生偏移。

这本身并不坏。一个可执行的规范比没人读的 PRD 更诚实。问题在于，几乎没有人将评测套件视为规范。它是由一名工程师在截止日期前拼凑出来的，只是为了让发布门禁显示为绿色。它编码了一百个从未被记录、从未被审查、也从未被达成共识的判断。而模型现在正针对它进行精确优化。

每一个具有韧性的 LLM 设计在配置中都有一行代码指定了一个备选模型。它之所以存在，是因为有人在设计评审中提出了正确的问题——“如果主模型宕机了怎么办？”——而另一个人用一个 fallback: 键回答了这个问题。大家都点头表示赞同。架构图上多了一个带有虚线箭头的第二个框。合规文档中也增加了一句关于优雅降级的描述。

然后，再也没有人碰过它。

备选模型是大多数生产环境 AI 系统中被断言得最自信、但演练最少的组件。它被命名、被记录、被画在图中——而在它真正承载流量的那一天，也是它第一次遇到真实请求的一天。你并没有建立安全网。你只是构建了第二个断裂强度未知的模型，而你将在最糟糕的时刻发现那个极限。

每个成熟的 AI 系统都会配备回退方案（fallback）。当主模型被限流时，路由到更廉价的模型。当服务商返回 5xx 错误时，提供缓存的答案。当置信度低于阈值时，回退到手写的启发式规则（heuristic）。架构图中有一个清晰的小分支，标注为“降级模式”（degraded mode），每个人都因此感到更安全。

令人不安的部分在于：那个分支是系统中几乎从未运行过的唯一代码。主路径每天执行数百万次，并经过大量流量的调试、性能分析和实战测试。回退路径几乎从不执行——直到某天，它在负载下、在事故期间、在三名工程师看着仪表盘变红时，突然为所有人同时执行。

一个你不练习的回退方案并不是冗余。它是一个不受监控的第二系统，其“首秀”在统计学上注定会发生在最糟糕的时刻。

大多数团队对待 LLM 评审员（LLM judge）的方式就像对待单元测试运行器一样：将其视为产生可信数字的中性基础设施。你编写评分标准（rubric），让模型针对你的输出进行评估，然后评审员返回分数。分数会显示在仪表盘上。仪表盘的趋势线驱动着产品路线图（roadmap）。没有人认为评审员是一个具有“行为”的东西，因为自动化的全部意义就在于将人为行为从环节中剔除。

但评审员本质上是一个模型。它有版本，有偏差。一旦它发生变化——无论是评估平台团队为了省钱更换了模型，还是提供商在 -latest 别名后悄悄滚动了权重——它产生的所有历史分数与新分数之间都会变得不可比。你的季度质量趋势现在是用两种不同的货币计价的，而且没有人给出汇率。

这并非假设的边缘情况。如果不像对待测量仪器那样对 LLM 进行版本化管理，这就是将其作为测量工具的必然结果。

两个支持用户在短短一分钟内向你的智能体提出了几乎相同的问题。第一个用户问：“我们针对 EU 订单的退款期限是多久？”第二个用户问：“我们针对 US 订单的退款期限是多久？”这两个句子的嵌入向量（embeddings）仅有一丝之差——长度相同，结构相同，只有一个两字母 token 的区别。你的语义缓存经过了相似度阈值的微调（在演示中看起来非常合理），将它们判定为匹配。于是，第二个用户得到了第一个用户的答案。EU 的 14 天冷静期被当作事实，以流利的文字呈现给了一位 US 客户，且没有任何补充说明。

没有人会因此收到报警。缓存返回了 200。延迟表现优异。成本看板显示了一次命中，这正是每个人想要的结果。唯一能说明出了问题的信号是客户根据一项不适用于他们的政策行事——而这个信号在几天后才会通过退款纠纷传来，而不是通过你的监控系统。

正是这种故障模式，让语义缓存与你之前构建过的任何缓存都截然不同。精确匹配缓存可能会过期，但它永远不会 错误——key 要么匹配，要么不匹配。语义缓存则是有意放弃了这种保证。它被设计为能针对从未见过的 key 返回答案，而这种延迟优势的代价是正确性风险，大多数团队从未对这一风险进行过量化。