用 AI Agent 造 QA DevOps：CI/CD、Docker、Actions

把 AI 放进 CI/CD 之后，它从「你叫它干活」变成「它自己干活」。这一步跨过去之前，有几个闸必须先装好。

先想清楚它在 CI 里干什么

三种用法，风险完全不同：

用法	它做什么	风险
只报告	分析失败、写一份诊断	低 —— 它不改任何东西
开 PR	提出修改，等人合	中 —— 人还在环里
自动合	改完直接进主干	高 —— 没人在场

第一种应该是所有团队的起点。 它没有下行风险，而且能马上暴露一件事：它的诊断准不准。 如果连诊断都经常错，后面两种就别谈了。

跑飞的代价要乘以轮数

单次调用跑飞，代价是一次调用。CI 里的循环跑飞，代价乘以轮数 —— 而且是在没人看的时候乘。

三笔账要在第一次无人值守跑之前就算：

一、派生的帮手会翻倍。 一个任务分出几个子任务，每个又可能重试三次。

二、重试是复利。 一个卡住的问题配上「失败就重试」，能空转整夜。它不会报警，因为从系统角度看它一直在正常工作。

三、上下文越滚越长。 循环把自己的输出喂回去，每轮输入都比上一轮长。

所以预算不是一个数，是三个同时卡着：单次运行上限、每日上限、最大重试次数。少任何一个都留着一条跑不停的路。

这里有两个实现细节容易搞错，我都踩过：

记账要记在动作发生之前。 计数器写在调用返回之后，超时和被限流的请求就不进账 —— 它们花掉了时间和算力，却不消耗预算。限制必须记在动作之前，统计才可以记在之后。

当心 SDK 自己的重试。 常见客户端库默认静默重试两次 —— 你眼里的一次调用，网络上其实是三次请求。我是在排查一次「卡了二十多分钟、而超时设的是 180 秒」的时候才翻到这个默认值的，三次 180 秒加退避正好对得上。重试这件事只能有一层负责。

Docker 与「牲口不是宠物」

agent 在 CI 里执行东西，环境必须是可以随时扔掉的。

好处不只是干净：容器挂了不是灾难，只是一次工具调用返回了错误 —— 上层把它当普通失败处理就行。

更重要的是凭据不放在那个容器里。Anthropic 拆 brain/hands 的一个直接理由就是：原来的设计里 agent 生成的不可信代码和凭据同处一室，拆开之后提示词注入拿不到 token。

把环境故障和产品缺陷分开

这条前面提过，在 CI 里更要紧，因为CI 环境本身就是噪音大户。

有份案例研究的数字：导航和环境超时占 40%，浏览器上下文崩溃占 16%。如果这些和「测试失败」混在一个统计里，你的所有质量数字都带着一层噪音。

做法很简单：失败分类里单独留一档给基础设施，并且这一档不计入质量指标，但要单独告警 —— 因为 40% 的环境故障本身就是个需要修的问题。

n8n 这类工作流工具的位置

课程里也会讲用 n8n 这类工具串流程。我的判断是它们在 QA 场景里的合理位置是粘合，不是核心逻辑：

• 适合：把「测试失败 → 发通知 → 建工单 → 更新看板」这条链串起来。这些步骤确定、无需判断、而且用死规矩就能做对
• 不适合：把判断逻辑放进去。判断该在代码或 agent 里，因为它需要被测试、被版本控制

能用死规矩做对的事，就别交给会瞎猜的东西 —— 这条线画在哪儿，决定整套东西可不可靠。

边界与代价

「自动合」这个能力我建议长期不开。 不是因为模型不行，是因为让它改断言的风险：目标写成「让 CI 变绿」，删测试就是最短路径。至少断言的改动要人批。

CI 里的 agent 会放大你已有的问题。 测试本来就不稳的项目，加了自动修复只会更混乱 —— 它会去「修」那些其实是环境问题的失败。先把不稳的测试治了，再上 agent。

预算上限主要不是省钱，是断路器。 它把一个开放式的风险变成有界的。一个没有上限的循环，等于把花钱的权力交给了自己的 bug —— 而派生的帮手、复利的重试、越滚越长的上下文这三笔账，是在你睡觉的时候一起涨的。