CI中免费AI模型会静默失败，先建熔断器

几个月前，我在一个副业项目的 CI 流水线中接入了一个免费 AI 编码模型。任务很简单：把每个 Pull Request 的 diff 总结成三条要点，作为 changelog 草稿。它正常运行了十一天。第十二天，模型端点开始返回空内容但 HTTP 状态码仍是 200，我的流水线欣然提交了十二个 changelog 条目，内容完整地写着——"-"。因为任务状态是绿的，一周内谁都没发现。

这次故障教会了我一个在免费 AI 模型的演示吹捧中完全被跳过的事实：将零成本模型接入自动化的真正问题不是质量，而是静默降级。付费 API 有 SLA 保障，出问题时会给相关人员发告警。免费端点只会变得奇奇怪怪，而你的流水线继续发货。

本文就是我在这件事之后构建的工作流。它是一个小型路由组件，带有断路器和金丝雀质量门，用 Python 编写，让免费模型端点可以参与 CI 自动化，而不会发生静默故障。

披露：本文作为 MonkeyCode 产品推广的一部分而撰写。我使用 MonkeyCode 的免费模型访问及其免费服务器选项作为下文的具体环境，但该路由是纯 HTTP 的——它可以对接任何 OpenAI 兼容端点，这就是设计意图。

实际的风险模型

在写代码之前，列举一下免费端点在自动化中实际会怎样失败是很有帮助的，因为很少会出现干净的 500 错误：

带成功状态的空响应或截断响应。 以我的经验这是最常见的一种。Token 限制、负载丢弃或静默的模型替换会导致返回 200 但里面没有任何可用内容。

延迟悬崖。 免费套餐在负载下可能从 2 秒突然变成 45 秒。在 CI 中，这不是错误，而是一个占用 runner 分钟数的挂起任务。

行为漂移。 端点保持在线，延迟保持良好，但输出格式悄悄变了，因为背后的模型被换掉了。我之前写过的关于快照测试的文章覆盖了评估场景下如何检测这个问题；这里的关注点更简单——在输出落入 commit 之前在线捕获它。

看起来像随机事件的限流。 间歇性的 429 错误，但其 retry-after 头信息并不如实描述等待时间。

注意缺少了什么："模型给了一个平庸的回答。" 对于我会主张免费模型应该处理的这类任务——changelog、commit message 检查、测试名生成、日志摘要——平庸但可解析是可以接受的。不可解析且被提交了才是问题。

产物：一个带金丝雀门的断路器路由

设计有三个活动部件：

金丝雀门： 在真正请求之前，发送一个固定的可检验探测 prompt（"精确回复 ready 这个词。"）。如果探测失败，无论状态页怎么说，该端点此刻就是降级状态。

断路器： 连续 N 次失败后，停止调用该端点一个冷却窗口，转而路由到降级行为。

降级行为： 关键决策。对于 CI，降级应该是确定性且安全的——跳过 AI 步骤并发出一个占位符——绝不是"阻塞构建"。

下面是一个可用的最小化版本。我已在 MonkeyCode 的免费服务器端点上运行过这个模式；唯一需要配置的是 base URL 和模型名称：

import time
import httpx

class ModelRouter:
    def __init__(self, base_url, api_key, model,
                 failure_threshold=3, cooldown_seconds=300):
        self.base_url = base_url.rstrip("/")
        self.api_key = api_key
        self.model = model
        self.failure_threshold = failure_threshold
        self.cooldown_seconds = cooldown_seconds
        self.consecutive_failures = 0
        self.circuit_opened_at = None

    def _circuit_open(self):
        if self.circuit_opened_at is None:
            return False
        if time.time() - self.circuit_opened_at > self.cooldown_seconds:
            # half-open: allow one trial request
            return False
        return True

    def _record(self, ok):
        if ok:
            self.consecutive_failures = 0
            self.circuit_opened_at = None
        else:
            self.consecutive_failures += 1
            if self.consecutive_failures >= self.failure_threshold:
                self.circuit_opened_at = time.time()

    def _chat(self, messages, timeout=20):
        resp = httpx.post(
            f"{self.base_url}/v1/chat/completions",
            headers={"Authorization": f"Bearer {self.api_key}"},
            json={"model": self.model, "messages": messages,
                  "temperature": 0, "max_tokens": 512},
            timeout=timeout,
        )
        resp.raise_for_status()
        content = resp.json()["choices"][0]["message"]["content"]
        if not content or not content.strip():
            raise ValueError("empty completion with 200 status")
        return content

    def canary_ok(self):
        try:
            out = self._chat(
                [{"role": "user",
                  "content": "Reply with exactly the word: ready"}],
                timeout=10,
            )
            return out.strip().lower().rstrip(".") == "ready"
        except Exception:
            return False

    def complete(self, prompt):
        """Returns (text, source) where source is 'model' or 'fallback'."""
        if self._circuit_open():
            return None, "fallback"
        if not self.canary_ok():
            self._record(False)
            return None, "fallback"
        try:
            text = self._chat([{"role": "user", "content": prompt}])
            self._record(True)
            return text, "model"
        except Exception:
            self._record(False)
            return None, "fallback"

以及 CI 端的用法，安全属性就体现在这里：

router = ModelRouter(
    base_url="https://your-monkeycode-server.example",  # free server endpoint
    api_key=os.environ["MC_API_KEY"],
    model=os.environ.get("MC_MODEL", "default"),
)

text, source = router.complete(f"Summarize this diff in 3 bullets:\n{diff}")

if source == "model":
    changelog_entry = text
else:
    # deterministic, honest, unmissable
    changelog_entry = "- [auto-summary unavailable; see diff]"

write_changelog(changelog_entry)

两个最关键的细节：金丝雀检测每次调用都会执行，而不是按计划运行，因为免费端点每分钟都在降级；_chat 中的空内容检查才是能捕获我最初那十二个破折号事件的东西，因为那个端点从未返回过错误状态。

适用场景与不适用场景

这是我目前在让任何免费模型接触自动化之前应用的决策表：

场景	免费模型是否适用
Changelog 生成、commit message lint、测试名生成、日志摘要	✅ 适用
输出需要被人类审核的场景	✅ 适用
交互式任务（延迟敏感）	⚠️ 慎用（金丝雀会增加延迟）
输出直接触发自动化链	❌ 不适用
无人工审核的下游步骤	❌ 不适用
延迟关键型 CI 任务	❌ 不适用

适用场景：输出是咨询性质或需要被审核的，调用量大导致付费 API 成本令人厌烦，且降级方案便宜的。一旦错误答案可以在未经审核的情况下进入生产环境，成本就不再是相关变量了。

金丝雀会增加延迟。每次真正调用现在变成了两次调用。对我的 changelog 任务来说增加了约 3 秒；对于任何交互式场景，可以批量处理金丝雀或将其结果缓存一小段时间（我用的是 60 秒，代价是少量陈旧风险）。

免费套餐行为不是契约。端点可以增加限流、在同一路由下更换模型，或直接消失。断路器可以吸收这类问题的临时版本；但无法吸收端点在 sprint 中途消失的情况。保持降级路径的演练——我每周运行一次 CI 任务，故意让端点不可达，以证明降级仍然有效。你从未见过执行的降级只是一个传言。

路由不评判质量，只判断可操作性。金丝雀证明端点按格式响应，不证明它响应得好。质量评估是一个独立的离线问题（我写过关于快照测试和评分循环的文章）；把两个门混在一起会让两者都变差。

完全不需要这套方案的人：CI 任务延迟关键型团队、没有下游人工审核步骤的人、以及想让你模型的输出触发进一步自动化的人。模型输出和人类视线之间每多一层自动化，静默降级的爆炸半径就乘以一倍。

免费模型访问的经济账确实有用——MonkeyCode 的免费模型加免费服务器选项意味着我的 changelog 自动化运行成本为零，整个尝试非常便宜。但"免费调用"和"免费信任"是两个不同的声明，而 CI 正是这个差异在凌晨 2 点以一条绿色流水线加满屏破折号显现的地方。先建好断路器，保持降级路径确定性，让免费套餐按照处理任何不稳定依赖的方式在流水线中赢得位置：放在一个假设它会失败的断路器后面。

如果你想尝试这个模式，上面的路由在 MonkeyCode 的免费服务器上无需修改即可运行——值得复制的是金丝雀 prompt 和降级设计，不是端点本身。