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

一个 AI 审查器拦截了一个合并（merge）。一名开发者盯着失败的检查，点击“查看详情”，扫视了三段样板文字，然后在没有阅读实际发现的情况下提交了一个“强制推送异常”（force-push exception）。在不到一周的时间里，团队中的每一位工程师都在潜意识里认为 AI 门禁只是背景噪音——是需要被忽略的，而不是需要去参与处理的。

这是大多数构建 AI CI/CD 门禁的团队实际交付的结果，即便底层模型在技术上是有能力的。问题不在于 AI 是否能审查代码，而在于你要求它拦截什么，以及你期望在它拦截时发生什么。

问任何一个 AI 工程团队是否测试了他们的提示词，他们都会说"是的"。再问一句：一个有问题的提示词能否让 PR 失败并阻断合并？房间里会安静很多。对大多数团队而言，诚实的答案是否定的 —— 他们偶尔会跑一些评估笔记本，也许有一份记录已知提示词问题的共享 Notion 文档，以及一种模糊的感觉：事情比以前更糟了。那不是测试，那是在碰运气。

这个差距的存在，是因为提示词测试在感觉上与单元测试有本质区别。代码要么行为正确，要么不正确。提示词的输出处于一个连续谱上，输出是非确定性的，而且运行足够多的样本以建立信心会花费真金白银。这些都是真实的约束，但没有一个是无法克服的。那些建立了真正阻断合并的提示词 CI 的团队，并不是在每次构建上花费五十美元 —— 他们在三分钟以内、花费不到一美元的情况下完成运行，这得益于几个让这个问题变得可处理的设计决策。

发布一个调用 LLM 的功能很容易。但要判断该功能的下一个版本是否优于生产环境中的当前版本，却相当困难。传统 CI/CD 对确定性行为提供通过/失败信号：函数要么返回正确值，要么不返回。但当函数封装了一个语言模型时，输出是概率性的——相同的输入在不同运行、不同模型版本和不同时间会产生不同输出。

大多数团队的应对方式是绕过这个问题。他们运行单元测试，对几个提示词做快速的人工检查，然后发布。这种方式在出问题之前都还能用——直到某个模型提供商悄悄更新了底层权重，或者一个看似没问题的提示词改动在孤立测试中没有异常，却在凌晨三点以生产流量规模改变了输出分布。

更好的答案并非假装 LLM 输出是确定性的，而是构建基于分布、阈值和评分标准的 CI 质量关口，而不是精确匹配。

每一个从"我们有个聊天机器人"升级到"我们有个 Agent"的工程团队，都会撞上同一堵墙：他们的测试套件开始失去意义。

经典测试金字塔——70% 单元测试、20% 集成测试、10% 端到端测试——建立在三个基本假设之上：单元测试运行成本低、与外部系统隔离、结果确定可重复。Agentic AI 系统同时打破了这三个假设。所谓的"单元"是一次消耗 token 且每次返回不同结果的模型调用。一次端到端运行可能耗时数分钟，消耗的 API 预算足以让一位初级工程师整个迭代周期的测试都无法证明其合理性。而隔离性几乎无从实现，因为 Agent 的智能恰恰来自于与外部工具和状态的交互。

大多数使用 LLM 的工程团队都专注于代码生成 —— 让模型更快地编写功能。但有一个杠杆率更高、受关注度却低得多的应用：使用 LLM 生成能发现人类遗漏的 bug 的 测试。不是测试 AI —— 而是 用 AI 测试你的软件。

这个想法非常诱人。手动编写的测试套件受限于人类的想象力，这意味着它们往往集中在开发者能想到的场景中。LLM 探索状态空间的方式则完全不同。它们生成的输入和边界情况对于原始作者来说往往感觉很陌生 —— 而这恰恰是未被发现的 bug 潜伏的地方。

但现实比愿景要复杂得多。原生 LLM 生成的测试有一半以上的时间无法通过编译。超过 85% 的失败源于错误的断言。而且，将非确定性的生成过程集成到确定性的 CI 流水中，本身就会产生一系列工程难题。以下是让它真正发挥作用的方法。

大多数构建 AI Agent 的团队在经历第一次生产事故后，都会发现同一个测试陷阱。你有两个明显的选择：在 CI 中进行实时的 API 调用（缓慢、昂贵、且具有非确定性），或者将 LLM 完全 Mock 掉（快速、廉价、但内容空洞）。这两种方法都会以不同但可预见的方式失败，而第二种方法的失败模式更糟糕，因为它是隐形的。

Mock 掉 LLM 的团队可能会跑六个月的全绿 CI，发布到生产环境后，才发现代码库中一直潜伏着一个 bug：在 8 步循环的第 6 步，Agent 处理畸形工具响应的方式有问题。那个总是返回 "Agent response here" 的 Mock 根本没有触及编排层。实际的工具分发、重试逻辑、状态累积和兜底路由代码从未被测试过。

好消息是还有第三条路。它与其说是一种单一的技术，不如说是一个由三层测试组成的架构，每一层都旨在捕获不同类别的失败，且无需承担其他方法的成本。

你的 CI 流水线假设了一件自你加入 LLM 调用以来就不再成立的事情：运行相同的代码两次会产生相同的结果。传统的 CI 是为确定性软件构建的 —— 编译、运行测试、获得绿灯或红灯。传统的 ML 评估是为固定的输入输出映射构建的 —— 对测试集进行推理、计算准确率。Agent AI 同时打破了这两个假设，其结果是一个要么对你撒谎，要么因误报而阻塞每次合并的 CI 系统。

核心问题不在于 Agent 难以测试，而在于你现有的测试基础设施是为一个“非确定性是 Bug 而非特性”的世界设计的。当你的 Agent 在连续运行中通过不同的工具调用路径得到相同的正确答案时，确定性断言就会失败。当它产生语义等效但词汇不同的响应时，字符串比较会将其标记为回归。测试框架本身变成了噪音的来源。