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

凌晨 3 点 17 分,一个不稳定测试被隔离了。On-call 轮值没有被叫醒,因为根本没东西失败——Agent 判定这次失败是噪声,自动开了一个标题为 chore: quarantine flaky test 的小 PR,用 ci-bot 这个 service account 把它 self-merge 了,然后继续盯着队列。六天之后,一个用户来反馈说某个功能从周二开始就坏了。那个测试不是 flaky,它是把一个真实回归挡在生产之外的唯一防线,而 Agent 那个 confidence threshold 设得刚好高到敢做决定,又刚好低到会判断错。

这是 agentic CI 中市场材料从不提及的那部分。在 2026 年,把 Agent 接进 pipeline 让它分流失败、对安全告警做依赖降级、提出依赖升级,在工程上其实很简单——工具齐了、集成只差一个 config 文件、生产力故事也是真的。没人写 runbook 的部分,是你刚刚引入的那一类新的操作主体:一个在凌晨 3 点没有任何人类同步在环、却拥有合并权限的角色,而你的 SRE 手册当初就是默认人类才是意图的来源。

用户正在阅读 Agent 流式输出的推理过程。在 token 1200 附近,模型决定调用 send_email,然后 create_ticket,再 kick_off_deploy。用户看到部分输出并意识到 Agent 误解了请求,在停止按钮上慢了半秒。邮件已经发出,工单已经创建,部署已经在跑。停止按钮取消的是下一个 token,而非上一个 token 的后果。

Bug 不在取消处理程序里。Bug 是那个假设——从团队路线图上所有其他流式 UI 借来的假设——即"逐步渲染的输出"就是"逐步可逆的输出"。工具调用并不遵守这个契约。它们是时间点上的提交,流式层一边欢快地触发它们,响应的其余部分还在生成中,而取消按钮无法沿着线路追赶它们。

这是那种没人认领的失败模式,因为它存在于两个团队各自干净交付的接缝处。UX 团队上线了流式,因为用户研究中表现更好;平台团队上线了工具调用,因为框架支持。两个团队都没有开过会问:当响应已经离开大楼时,"停止"应该是什么意思?

合规部门给你转发了一张工单。三周前，一名客户的退款请求被你的支持代理拒绝了，他们发起了申诉，现在需要有人解释这一决定。你对此感到很淡定，因为你记录了一切。每一次提示词、每一次工具调用、每一段检索到的内容、每一个 Token 计数、每一项延迟数据——所有这些都在追踪记录（trace）中，你可以在几秒钟内调出它们。

你调出了记录。你可以看到代理收到了退款请求。你可以看到它调用了 get_order_history，接着是 check_return_window，然后是 lookup_policy。你可以看到它检索到的确切政策文本。你可以看到它发送的最后一条消息：拒绝退款。追踪记录是完整的。每一个 span 都是绿色的。但你仍然无法回答那个问题，因为追踪记录显示代理拒绝了退款，并向你展示了它查看过的所有内容，但它没有向你展示为什么这些输入叠加在一起的结果是“不”。原因存在于模型如何权衡上下文，而这种权衡从未成为一种产物（artifact）。它从未在任何地方被记录下来。

这就是追踪记录与解释（explanation）之间的差距，几乎所有声称“我们拥有完全可观测性”的团队都还没有意识到，他们只构建了前半部分。

一名外包人员在上个季度结束了为期六个月的聘期。人力资源部门执行了离职清单：禁用 SSO、擦除笔记本电脑数据、移除 GitHub 席位、归档 Slack、撤销 Notion 访问权限。合规部门签字确认。六周后，一个内部 RAG 助手在回答问题时引用了该外包人员编写的一份机密战略文档——而引用的数据块在向量数据库的白名单中仍标记着该外包人员的用户 ID。事实来源（source-of-truth）的访问日志中没有任何读取记录，因为根本没有发生读取。检索来自一份从未被纳入离职流程的数据副本。

这是没人会画在架构图上的结构性问题。你的向量索引不仅仅是一个相似度搜索引擎。它是一个权限缓存——一个关于“谁能看到什么”的派生存储，冻结在你运行嵌入任务的那一刻——而且几乎没有人像失效其他内容那样去失效它。

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

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

你让智能体修复一个不稳定的测试。第三分钟，测试通过了。第四分钟，智能体正在读取相邻文件。第九分钟，它“改进”了一个测试从未触及的辅助函数，为了清晰起见重命名了一个无关的参数，并开始对 fixture 构建器进行重构。最终提交的 diff 涉及 12 个文件和 400 行代码。原始 Bug 修复了，一些原本没坏的代码也顺便被“修复”了。

这不是模型感到困惑，而是模型完全按照指令留下的空间在行事。任务要求“修复 Bug”，但并没说“修复后就停止”。大多数智能体循环都有明确的起点和成功标准，但对第三个问题却含糊其辞：你什么时候结束？在聊天会话中，“结束”是由用户决定的。在自主循环中，“结束”是由停止条件决定的，如果你没写停止条件，那停止条件就是“模型失去了兴趣”。这不属于你可以调试的故障模式，而是一种你必须通过设计来消除的故障模式。

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

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

发布标志运作完美。你在它后面发布了 AI 摘要生成器，在两周内将其比例从 1% 提高到 10%、50%，最后达到 100%，紧盯仪表盘，一切正常。季度末，平台团队的标志清理机器人发起了一个 PR，删除了这个已经多余的入口。你批准了。该 PR 与其他过期标志清理工作一起合并，代码库精简了 200 行。六周后的凌晨 2 点，供应商滚动更新了一个新的模型快照，你的摘要生成器开始信誓旦旦地在法律文件中编造条款，而你的值班工程师发现没有快速关闭它的手段 —— 只能重新部署。

标志完成了它的工作。但标志是错误的保留产物。发布标志回答的是“这条新代码路径是否应该是可达的？”一旦大家达成共识，删除它就是正确的清理举动。而紧急开关（Kill switch）回答的是“上游模型今天表现正常吗？” —— 这个问题永远不会过期，因为上游模型永远在变化。将它们放在一起清理，就像把烟雾报警器当作建筑许可证一样，是范畴错误：建筑物建成后，许可证会被归档，但报警器的接线必须永远保持连接，因为由于它所监控的情况仍然可能发生。

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

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

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

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

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

每场关于 AI 功能的规划会议最终都会陷入同样的二元对立。一方想“直接套个 API”并在下个冲刺阶段发布。另一方则想“掌握模型”，以便公司掌控自己的命运。这种争论听起来很有战略意义，但实际上是一个分类错误。

“自研还是购买”将你的 AI 功能视为一个不可分割的整体，要么自研，要么购买。但 AI 功能并不是单一的事物。它是一个由至少五个不同层级组成的堆栈，每一层都有其自身的答案。如果团队将决策简化为一次掷硬币，几乎总是会掌握错误的层级并租用错误的层级，因为他们提出的问题无法区分这些层级之间的差异。

更好的问题不是“我们能做出来吗？”大多数东西你都能做出来。真正的问题是：如果竞争对手明天购买了完全相同的东西，哪一层会破坏我们的差异化？ 这个问题会为你梳理出堆栈的优先级。

打开任何一份 AI 功能评论，你都会听到关于这三个数字的辩论：延迟、Token 成本和准确率。有人调出 P95 图表，有人计算单千次请求的成本，还有人争论评估分数 (eval score) 已经好到可以发布了。没人提到能源。没人提到碳排放。正因为没人提及，该功能的环保足迹仍然被决定了——由谁赢得了那场关于金额的争论所含蓄地决定。

这就是 AI 可持续性中沉默的问题。并不是团队故意选择了高碳设计，而是他们根本没有做出选择。碳足迹成了成本决策的副作用，而成本与碳排放之间仅存在松散的关联。在支出仪表盘上看起来大获全胜的路由规则，可能会悄无声息地让排放量翻倍，而会议室里没人会知道，因为那个能告诉他们真相的数字从未出现在仪表盘上。

这篇文章将能源和碳排放视为它们的真实身份：AI 系统的一个可测量、可掌控的属性，与延迟和成本处于同等地位。它不是企业价值的脚注，而是一个明细项。