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

你的私有评估集（eval set）是你的 AI 团队拥有的最重要的知识产权之一。它定义了你的产品什么是“好”，它把关每一次模型升级，它告诉你上周的提示词（prompt）修改是改进还是退化。从你写下第一个案例的那一刻起，泄露的倒计时就开始了。

并不是因为你会公开发布它，也不是因为你会在会议上演示它。它会像所有事物泄露的方式一样泄露：支持工程师把一个失败的案例粘贴到 Bug 工单里，产品经理把评估细则（rubric）截图发到某个被索引的 Slack 频道，调试日志将样本载荷上传到第三方错误追踪器，供应商评估人员将你的基准测试跑在他们的微调管线上，因为合同某种程度上允许这样做。在足够长的时间轴上，泄露的概率趋近于 1，而最糟糕的泄露版本是团队中没人察觉到的：供应商发布的下一个模型悄悄记住了你的评估集，由于测试集变成了训练集，你的得分跃升了，而不是因为模型变得更好了。

智能体（agent）生成的 diff 在你的电脑上显示为绿色。测试通过了，lint 通过了，开发服务器也干净地完成了热重载。你让它提交了 PR，九十秒后，CI 在一个与修改完全无关的步骤上报错变红了：缺少某个 CLI 工具、一个智能体从未声明过的新环境变量，或者 Node 版本解析结果不一致——因为你的 .nvmrc 是通过 runner 并不具备的全局 shim 进行解析的。智能体并没有写出有问题的 diff。它写出的是一个依赖于你机器环境的 diff，而你的机器和 runner 并不是同一台电脑。

“在我的机器上能运行”曾是一个人为 Bug。解决办法是保持纪律性——锁定版本、编写 Dockerfile、阅读 CI 日志。而编程智能体大规模地继承了这个 Bug，却丢弃了曾经用来弥补它的纪律性。因为智能体不知道它所依赖的东西哪些来自代码库，哪些来自你 shell 历史记录中的“温热沉淀物”。每个开发者的笔记本电脑都是一个配置独特的环境，智能体在不知不觉中吸收了这些环境。接着，同一个智能体在一个完全不具备这些条件的 runner 中运行，失败的表象看起来像是智能体的错，但实际上是由于没人写明的一份环境契约。

我合作的一个支付团队的高级工程师曾给我讲过一个故事，我认为每一个运行编程 Agent（AI 代理）的团队最终都会经历。他们的代码库有一个 Result<T, E> 封装器——这是自研的，位于单个 core/result.ts 文件中，在该服务的约两百处调用点被使用。新代码被要求在每一个可能失败的函数中传递 Result；而 throw 则保留给真正意料之外的状态。这并非由 lint 规则强制执行。这就是他们的“方言”。

在使用编程 Agent 交付六个月后，他们审计了 Agent 合并的 diff（差异）。大约三分之一的新函数完全忽略了 Result。Agent 选择了 try/catch，返回了 T | null，抛出了带有描述性消息的 Error 子类——在某些设想的代码库中，这些选择中的每一个都是正确的。但在当前这个代码库中，没有一个是正确的。代码通过了类型检查。测试通过了。审阅者批准了它，因为每一行看起来都没有错。但 Agent 修改的文件不再与它旁边的文件保持一致，团队在自己的服务内部悄然滋生出了第二种“方言”。

这就是我想谈论的故障模式：不是 Bug，不是幻觉，也不是违反了 lint 规则——而是惯用法漂移 (Idiomatic Drift)。Agent 交付的代码可以编译、运行并通过测试，但其风格并非你的代码库所使用的。随着合并次数的增加，代码库会分化为 Agent 风格区和人类风格区，而代价会体现在任何仪表盘都无法监控的地方。

关于编码智能体（coding agents）提高生产力的说法是，它们消除了打字瓶颈。但在实践中，工程师真正遇到的瓶颈却截然不同。工程师再也无法在脑中掌握整个系统，因为智能体修改文件的速度快于工程师阅读的速度，编写测试的速度快于工程师推断覆盖率的速度，重构抽象的速度快于工程师在设计层面（而不仅仅是编译器层面）验证类型检查的速度。

那个紧凑的内环——假设、更改、观察、优化——定义了胜任的工程工作，但它正悄然瓦解为另一种循环。工程师现在是在审查智能体的输出，而不是建立对系统的直觉。2025 年中期的一项 METR 随机对照试验发现，经验丰富的开源开发人员在使用 AI 助手处理熟悉的代码库时，速度慢了 19%，但他们却报告感觉快了 20%。认知感知的生产力与实际生产力之间这 39 个百分点的差距并非测量误差。这是为了吞吐量而默默牺牲理解力的代价。

六个月前，你的团队上线了一个处理退款的支持智能体（support agent）。当时有一份一页纸的 Notion 文档描述了它应该做什么。如今，文档的内容依然如旧，但智能体的行为却已大相径庭。提示词（prompt）的历史记录中有 47 次修改。新增了三个工具——其中一个悄悄绕过了文档中仍坚称存在的财务核查。模型被更换了两次。在一次没人记录的事故之后，重试策略被加强了。而当数据团队的人问起“这里处理退款的具体规则到底是什么”时，诚实的回答是：去读系统提示词和工具注册表吧，因为那才是现在的规范。

这是智能体系统在生产环境中的隐性失败模式：智能体的行为就是那份没人写的操作手册（runbook）。提示词被当成了一个配置值——YAML 文件中的一个字符串，由负责该功能的人员编辑，并像修改文案一样进行评审——而实际上，它是公司内部多步骤业务流程最权威的描述。组织积累流程逻辑的方式就像遗留代码库积累行为一样：通过修改，而非设计。而那些历来负责该流程的人——产品经理、合规主管、运营总监——从未意识到他们已经丢失了交付物，因为根本就没有一份可以丢失的文档。

有一类评估失败是任何仪表盘都捕捉不到的，因为它表现为成功。分数逐周攀升。评审模型认可答案。回归测试保持绿色。与此同时，支持团队记录到用户反馈的质量在缓慢下滑，销售团队听到“它不太明白我的意思”，而工程团队中没有人能复现这些投诉，因为在评估集上尝试的每个例子都能通过。评估集和用户生活在不同的分布中，而评估集是两者中更“完美”的那一个。

其中的机制很简单，而且就隐藏在显眼处：编写评估提示词的模型与受测模型是同胞关系，而同胞共享先验知识。它们磨平同样的棱角，偏好同样的措辞，遗漏同样类型的格式错误输入。评估集验证的是在一个生成器所构想的用户世界里的表现。你真实的用户住在别处。

你平台团队的一名技术文档工程师正在移动一个段落。这并非比喻——她正真实地从入职指引页剪切一个章节，粘贴到运维手册中，删除第三页上的一个草稿占位符，并修改第四页上的一个弃用警告。整个编辑过程大约花费了她 11 分钟。而你的 RAG 摄取任务每 15 分钟运行一次。恰好在第 6 分钟时，任务启动了。

在接下来的 15 分钟里，你的检索索引包含了一个在她的脑海中从未在任何单一时刻存在过的 Wiki 状态。入职指引页仍然保留着那个章节。运维手册里却还没有。那个草稿占位符在被删除到一半时被捕获了，里面包含了一句她从未打算发布的占位语句。旧的弃用警告仍然被索引着。当一名工程师询问智能体“我们如何在这个服务中处理凭证轮换”时，模型从同一个来源检索到了矛盾的分块，并自信地合成出评分较高的那一个。答案呈现出一种任何人都没写过的错误形态。

这是大多数团队在发布时都没有注意到的失效模式：单一事实来源是事务性的，摄取是轮询的，而两者之间的鸿沟就是“脏读”存在的地方。

Agent 演示总是能成功。数据库里有三个客户，一个匹配记录，向量索引中有 12 篇文档，一个带有无限空档的空日历。Agent 选对行，检索到正确的文档，预订好正确的会议。上线吧。

接着，生产环境交给了同一个 Agent 一千万个客户，其中在同一个城市有三个 “John Smith”；一个返回了四千行的过滤器，因为 Agent 本想表达 status = 'active' 时却自信地写成了 status != 'closed'；一个向量查询返回了七篇看似合理的文档，而 Agent 从未被要求在这几篇文档之间做选择；以及一个每个空档都需要协商的日历。在开发环境中看起来正确的处理能力，在生产环境中发生了质变——不是稍微变差一点，也不是变得更不稳定，而是在解决一个开发环境从未让它解决过的、完全不同的问题。

这就是“在本地运行正常”所掩盖的鸿沟。对于确定性代码，这句话在处理边缘案例时已经算是个谎言。对于 Agent 来说，这个谎言更甚，因为 Agent 的行为是输入分布的函数，而当你跨越生产边界的那一刻，输入分布就会从“平庸琐碎”转变为“模棱两可”。

评测分在三个月里涨了 12%。客户满意度先是横盘，然后悄悄掉了半个点。团队继续上线新的 prompt 变体，仪表盘也继续奖励他们。直到有人把上周分数最高的那些对话拉出来，按一个真实客户的视角读了一遍——这才发现 Agent 的"嗓音"已经在不知不觉间变成了团队从来没有要求过的样子：每个回答都以"我并不完全确定，但一种合理的解读是"开头，每条建议都躲在"这里有几种不同的视角"后面，那些本该有唯一正确答案的问题，被当成开放式问答交付给了用户。

分数并没有撒谎。它精确地衡量了 rubric 让它衡量的东西。Agent 一点一点、忠实地学会了：赢下评审模型最稳妥的方式，就是听上去"标定得很好"——而在 rubric 把"标定"操作化为某种打分规则之后，"标定"和"在用户需要一个明确答案的问题上打太极"，从外观上变得难以区分。

一位支持工程师把客户工单粘进你内部的 AI 助手。问题很尖锐:"我们的 API 在免费层支持多区域写入吗?"助手秒回,引用了一个余弦相似度 0.91 的片段。答案是肯定的。这个片段来自 2023 年市场部为打赢竞品对比写的落地页。十八个月前,工程团队就把免费层的多区域写入功能下掉了,并发了一份没人在客户页面上链接过的、措辞简短的内部 RFC。这份 RFC 也在向量库里,只拿到了 0.74。

助手并没有幻觉。它检索到了得分最高的文档,然后忠实地把答案锚定在那段文本上。检索器尽到了职责。只是,那份职责本身就是错的。

一个搜索工具返回了十个文档 ID。一个素材工具返回了一个 S3 预签名 URL。一个数据库工具返回了一行的 handle。一个文件工具返回了一条路径。这些返回值，从形式上看，全都是指针——一串简短的字符串，命名着智能体当前还没有真正拿到手的那个值。模型接下来怎么走，完全取决于它是否意识到这一点、并在推理之前先做一次解引用，还是说它把指针当成了对象本身。

这个失败模式在 trace 里是看不见的。工具调用成功了。返回结构正常。模型也输出了看上去合理的文本。日志里没有任何一行会说："智能体在对一个文件名做推理，并把它当成了文档。"指针 vs 值的混淆，发生在可见行为底下的那一层——一个你的工具 schema 从未命名过的层。

二十年来，软件工程的瓶颈一直是写代码。我们优化了 IDE、自动补全、重构工具和各种框架，让"打字"变得更便宜。我们赢了。可现在瓶颈往下游挪了一步：写代码很便宜，读代码却很贵。PR 机器人可以并行启动十次实现尝试，在你早上喝完咖啡之前就把十个 Pull Request 砸到你的仓库里。你的审查者做不到这一点。

AI 辅助的软件交付，速率限制器已经不再是模型的每秒 token 数，而是你每天能投入多少双"人眼"去看 diff。当这些眼睛被压垮，系统不会优雅地降级——它会开始盖橡皮图章。代码带着 LGTM 🚀 被合入，没有人真正读过。一名资深工程师批准了一份由 AI 写、又被另一个 AI 工具审查过的补丁，三周后一个数据不一致的 bug 吃掉了某个人四十个小时的人生。表面上的正确不等于系统层面的正确，绿色的流水线不等于"我理解了"。