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

发布一个调用 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 在连续运行中通过不同的工具调用路径得到相同的正确答案时，确定性断言就会失败。当它产生语义等效但词汇不同的响应时，字符串比较会将其标记为回归。测试框架本身变成了噪音的来源。