23 篇博文 含有标签「ci-cd」

一个人类工程师在看到一个明明不可能由改动引起的测试失败时，会做一件智能体做不到的事：耸耸肩。他们会点击重新运行，对着 CI 大神嘀咕几句，然后继续工作。这种耸肩行为包含了多年积累的上下文 —— 这个测试从 3 月份开始就一直不稳定（Flaky），那个服务的预发布环境每逢周一就会崩溃，没人信任 WebSocket 的测试套件。而编码智能体完全没有这些。它看到一个红色的 X，就将其视为绝对真理，因为它的所有训练和提示词都在告诉它：测试失败意味着代码是错误的。

接下来的环节才是最昂贵的部分。智能体不会耸耸肩 —— 它会采取行动。它会“修复”那些从未损坏的代码。它会因为应用改动后测试套件变红而回滚一个正确的改动。它会消耗大量的 Token 预算去追赶一个幻影，在原本正常的代码路径中添加重试、等待和防御性检查，直到那个不稳定测试碰巧通过，智能体便得出结论：它最后的突变就是解药。测试基座中的非确定性一直是人类注意力的一种负担。而对于智能体循环来说，它更糟糕：它是直接注入到决策系统中的受损训练信号，而系统正以机器速度基于此做出反应。

在你的代码库中的某个地方，有一个配置文件，在 test 配置下写着类似 model: small-and-cheap，而在 production 下写着 model: frontier。当有人添加这一行时，感觉是很负责任的做法 —— 为什么要为了每天运行 20 次的 CI 任务去消耗 frontier 模型的 token 呢？但那一行代码悄无声息地废除了一项你的团队十五年来一直在不假思索遵循的规则：你测试的环境应该表现得和你上线的环境一致。

“十二要素应用宣言”（Twelve-factor methodology）称之为开发环境与生产环境等同（dev/prod parity），我们在这方面已经做得非常出色，以至于我们开始忽略它的存在。Docker 为我们提供了位级一致的运行时环境。基础设施即代码（Infrastructure-as-code）为我们提供了完全一致的拓扑结构。然后，我们在请求路径中间加入了一个语言模型，重新引入了我们花了十年时间才弥合的差距 —— 只不过这一次，产生差异的组件不再是数据库版本。而是系统中负责做决策的部分。

你的编程智能体（Coding agents）刚刚让编写代码成为了交付软件中最廉价的部分。但它们并没有让代码落地变得更便宜。AI 采用率高的团队合并的 Pull Request (PR) 数量几乎是以前的两倍——而他们的交付指标却几乎没有变化，因为每一个 PR 仍然必须挤进同一个代码评审流水线、同一个 CI 集群以及同一个合并队列（Merge Queue），而这些设施当初是按人类打字速度设计的。约束并没有消失，而是向后移动了，移到了系统中那个最窄的管道：从“已批准”到“进入主分支（main）”之间的串行化路径。

这是一个经典的约束理论（Theory-of-constraints）故事，大多数工程组织目前正身处其中却尚未察觉。当一名开发者可以在并行工作树中指挥 5 到 10 个智能体时，PR 的体量就不再与员工人数挂钩。但合并吞吐量仍然取决于一些更为死板的东西：你的 CI 每小时能验证多少个 main 分支的候选状态。这个数字受限于测试套件的时长、执行器（Runner）容量、抖动率（Flake rate）和队列机制——而这些都没有随着智能体变快而变快。

我曾合作过的一个团队花了三天时间寻找他们智能体（agent）循环中 22% 的延迟回归原因。他们归咎于新的工具路由（tool router）。他们归咎于切换了模型版本。他们归咎于前一周悄悄升级的 JSON schema 验证器。他们最终在代码下游两层的地方找到了元凶：一个运行器镜像（runner image）进行了更新，新镜像将 cpufreq 调节器（governor）的默认值从 performance 改为了 schedutil，而智能体工具调用循环的突发性使得 schedutil 的升频延迟在 p95 指标中变得显而易见。模型没问题。智能体也没问题。仅仅是内核在微突发任务之间改变了 CPU 频率的调节策略，导致整个基准测试结果发生了偏移。

这是大多数智能体团队从未见过的故障模式，因为他们从不观察。你的 CI 基准测试数字并不是对模型或智能体的测量。它们是对一个技术栈的测量，这个栈恰好包含了模型、网络、共享虚拟机、虚拟机监控程序（hypervisor）调度器、具有未知邻居的缓存层级，以及——最隐蔽的——频率缩放策略，它决定了给定的每一毫秒计算是以 1.0 GHz 还是 3.6 GHz 运行。

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

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

凌晨 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 手册当初就是默认人类才是意图的来源。

打开任何生产环境中的 LLM 代码库里的提示词文件，你会发现评审者的目光变得呆滞。这个 diff 是 15 行自然语言，其中包含一个微调过的 few-shot 示例，一条重新表述的指令，以及编辑器留下的一个多余的尾部空格。没有针对它的语法检查，没有 Linter 抱怨相互矛盾的指令，没有扫描器注意到 few-shot 示例包含上周二支持日志中真实客户的电子邮件地址，也没有冒烟评估（smoke eval）来确认这一更改不会导致系统实际提供的提示词延迟飙升。评审者凭感觉批准——就像 2008 年团队批准 HTML 模板的 diff 一样——然后在 6 小时后，生产遥测系统捕获到了回归。

围绕代码的内环工具（inner-loop tooling）已经成熟了 20 年。围绕提示词的内环工具则介于“我们在 git 中有一个 .md 文件”和“我们在入职后运行过一次 promptfoo”之间。这种差距正在扩大，因为在许多系统中，提示词现在是杠杆率更高的修改：一个 30 行的系统提示词更改比 1000 行的服务重写更能改变行为，而它的评审过程却像处理一份 Word 文档。

想要发现你的 AI 团队缺乏评测纪律，最快的方法就是分别在 Slack 私聊中询问三名工程师：“你上次的提示词（prompt）修改提升了质量吗？”——然后看着他们三个人都回答“是”，但给出的却是三个不同的数字，针对的是三个不同的切片（slice），在三台不同的笔记本电脑上运行，而且团队中没有其他人能复现这些结果。从教科书式的定义来看，这不单纯是评测问题。教科书会说你没有评测。而现实情况更糟：你有 太多 的评测，每个评测都是私有的，每个都能衡量一些真实的东西，但没有一个能汇总成组织可以据此制定计划的单一指标。

这就是“影子评测（shadow eval）”反模式，大多数 AI 团队在承认这一点之前，这种状态持续的时间比他们愿意承认的要长。它看起来效率很高——每个工程师都有一个 notebook，每个 PR 都附带一张通过率的截图，每次站会都会提到“在长尾切片上取得了胜利”——而且它能在季度评审中幸存下来，因为“我们做评测”的门槛太低了，只要运行任何内容都算。但组织得不到任何信号。领导层无法判断上个月的三次提示词修改是推动了产品进步还是原地踏步，因为三名工程师是根据三个私有切片进行衡量的，而且在切换文件的那一刻就停止了对之前基准（baseline）的追踪。

周二下午，一个只有六行代码的系统提示词（system prompt）编辑出现在了一个 Pull Request (PR) 中。Diff 只是普通的英文。两位评审者扫了一眼新的措辞，觉得读起来更自然，于是点击了批准。PR 在不到一分钟内合并。到了周五，客服开始收到关于智能体的工单：它突然拒绝总结超过一定长度的文档，不再引用来源，并莫名其妙地在每句回复开头都加上 “Certainly!” —— 这种行为没人要求过，Diff 中也无法预见。

当一个花了十年时间学习如何评审代码的团队，在面对提示词这一产物时，竟然退化到了第一周的水平，结果就是这样。Diff 看起来 毫无害处，因为它读起来像英语，而人类正是用眼睛来审阅英语的。让代码评审发挥作用的规范 —— 运行测试、检查影响范围、对 “小改动” 保持适当的怀疑 —— 并没有悄然转化。措辞变好了，但行为变差了，直到用户发现之前，没人注意到。

决定一个模型是否上线生产环境的数字，是由运行在某个工程师 MacBook 上的 Jupyter Notebook 生成的。数据来源是 Slack 私聊中的一个 CSV 文件，评分则由一个没人固定版本的裁判模型完成。两周后，在工程师又动了三次 Notebook，且 API 供应商悄悄发布了一个微小的模型更新后，团队里已经没人能重现那个数字了——包括当初生成它的那个工程师。然而，那个数字就是准入闸门。它决定了 GPT-4o-mini 是否足以在客户支持流程中取代 GPT-4；它决定了新提示词模板的发布；它决定了微调模型的晋升。团队把它视为核心承重构件，却像对待便利贴一样存储它。

这就是“评估差距”（eval gap）。五年来，业界一直在将评估视为一个方法论问题——哪种评分技术、哪种裁判模型、哪种评分标准、哪种数据集——却几乎从未将其视为一个工程问题。但是，一旦你的评估套件开始充当生产发布的守门员，它就继承了生产栈其余部分所遵循的所有要求：可重现性、版本控制、所有权、可观测性、依赖管理、延迟与可靠性预算，以及一套在构建它的工程师离职后依然能运行的流水线。大多数团队完全跳过了这一层，只有在发生重大事故后才发现它的缺失——通常是评估分数显示绿色，而用户体验却是一片红色。

许多自称“有评估（evals）”的团队，其实际情况是：有一个仪表板，某人每周运行一次测试套件，然后将数据粘贴到没人看的 Slack 频道。评审人员批准提示词（prompt）更改时，甚至根本没看过它是否影响了测试套件，而回归问题（regression）两周后才在客户反馈单中显现。评估确实存在，但评估并未进入开发循环。

解决办法在于结构，而非意愿。只有当评估存在于变更发生的地方——即 Pull Request（PR）评论中，紧挨着代码差异（diff），并带有单个 PR 的增量变化和评审员无法忽视的回归提醒时，评估才能真正起到质量把关的作用。在其他任何地方，它们都只是表演性的产物：投入了大量精力构建，却什么也拦截不到。

我最近合作的一个团队有三个不同的“总结这份合同”提示词。一个存在于 Notion 页面中，法律科技小队将其复制粘贴到他们的服务里。一个存在于客户成功后端的 prompts/ 文件夹中，为了适应他们的语气偏好做了轻微修改。还有一个内联在数据团队 notebook 里的 Python 文件中，被硬编码在两个 f-string 插值之间。当 OpenAI 弃用了它们运行的所有模型时，迁移计划变成了一场 “Slack 考古” —— 必须追踪到每个所有者，重新评估每个变体，其中两个变体在生产环境中默默地出了一周的故障才被察觉。

这就是规模化后的提示词 Cookbook 的样子。对于十个提示词和一个团队来说，Cookbook 是合理的。但当提示词达到一百个、团队达到四个左右时，它们就会变得难以管理。当你运行一个 AI 组织时，你的 prompts/ 文件夹（装满 .md 文件）的表现就像 2008 年那种靠复制粘贴引入的第三方代码：每个消费者都有自己的快照，偏差（drift）是不可见的，而破坏性变更会以不可预测的方式向外扩散。