企业官网建设流程全解析

先说结论：凌晨两点，MR 合并窗口前四十分钟，CI 突然全红，第一条报错是unable to connect to anthropic services failed to connect to api.anthropic.com，紧接着是网关层的claude does not look like an anthropic model: expected a gateway model route。那一刻你不会有心情去查文档——你只会盯着日志滚动，期待某行输出能给你一条活路。

这篇内容就是我处理这次事故的完整记录。它涵盖三件事：在 GitLab CI 里接 Anthropic API 做代码审查时踩到的基础设施坑、围绕模型参数和网关路由的配置问题、以及高压下工程师真正该有的排查姿势。适合正好在搞 AI 辅助研发流程、或者想在 CI 里调外部大模型服务的同学。我会把报错原文、排查命令、最终方案全部写出来，你照着能省至少一个通宵。

1. 危机背景：为什么 CI 会依赖一家外部 AI 服务

先交代一下背景，不然你很难理解为什么一个 CI 管线会跟 Anthropic 的 API 扯上关系，而且扯得这么深。

1.1 我们在 CI 里拿 Anthropic API 做什么

我们的团队大概从半年前开始在研发流程里引入 AI 辅助环节，落地的场景比较实际——不是那种“让 AI 自动写整个项目”的激进路线，而是做了三个相对稳妥的自动化点。

第一个是 AI 代码审查。传统的静态检查只能抓语法错误和明显的坏味道，但漏不掉“你改了这个函数，调用方那边可能没人知道”这类上下文问题。我们用 Claude 对每个 MR 的 diff 做一次补充审查，让它在代码逻辑层面找问题，比如空指针隐患、并发边界、接口变更没同步调用方，然后把发现结果作为评论贴回 MR 讨论区。这个场景对响应时间敏感，因为 merge 窗口就那么长，基本是硬实时需求。

第二个是自动生成测试用例的建议。我们会把新增函数的签名、依赖关系、关键业务规则打包成一段上下文，让模型给出测试边界建议。这个事情对参数配置的容忍度比审查高很多，晚个几分钟结果也能接受，可以作为后台任务慢慢跑。

第三个是 PR 描述自动生成。根据提交信息和 diff 摘要生成一份结构化的 MR 描述草稿，让开发者在提交前稍微改改就能用。这个场景容错性最高，即使模型偶尔抽风也不影响主流程。

这些任务的共同点是：都在 GitLab CI 里跑，都由一个 Python 脚本统一调度对 Anthropic API 的调用。所以当 API 不可达或者路由配置出错时，三个任务一起挂，CI 全线飘红。

1.2 架构选型：GitLab CI + Python + Anthropic SDK

选用 GitLab CI 不是因为它是功能最强的，而是因为这正好是我们团队已有的基础设施，没必要为了一个 AI 审查功能单独搭一套流水线。GitLab CI 的.gitlab-ci.yml文件可以直接定义 pipeline，天然支持 MR 触发、基于分支或标签的过滤规则，还能把 CI dashboard 显示的失败状态与 MR 关联起来——这个能力在故障发生的时候真的很有用，它让所有人第一眼就知道出事了，不用等谁去翻日志。

Runner 我们用的是自托管的 Kubernetes runner。选择它的原因很直接：涉及调用外部 API 的 CI 任务，必须能控制网络出口；同时我们也想限制任务运行的资源上限和超时时间。如果当初用的是 GitLab.com 的 SaaS runner，后面的故障可能连排查的机会都不会给你——你根本看不到日志下面发生了什么。这一点算是我踩过几次坑后很深的体会：CI 任务只要依赖外部网络资源，自托管 runner 是底线。

Python 侧是调用 HTTP 统一封装层，用官方 SDKanthropic库，把 model、temperature、max_tokens 这些参数从外部配置注入。SDK 本身帮你处理请求签名、响应解析、部分错误重试，比较省心。但这里有个陷阱：SDK 的重试策略只覆盖极少数的网络瞬时错误，遇到连接层完全不可达、或者 HTTP 层返回 4xx 时，它不会自动重试，而是直接抛错。这基本意味着，如果你把重试逻辑完全交给 SDK 默认配置，那你离故障其实只有一步之遥。

1.3 为什么选 Anthropic 而不是别的模型

选 Anthropic 是做过一轮对比之后的决定，不是说它没有缺点，但在我们这几个场景里优势非常明显。

首先是长上下文窗口。代码审查要处理的 MR diff 往往不是小改动，一个中等规模的 MR 可能有几百行 diff，加上相关上下文，很容易一下吃掉几万个 token。Anthropic 的模型对长上下文的处理质量在同类里都属于第一梯队，上下文窗口够大，且长文本处理能力很稳，这是我们从实际测试里得出的经验。

其次是代码理解能力。把一段带有明显并发缺陷的 Python 代码丢给它，它能准确指出竞争条件的原因，并且给出一个和测试用例相关的复现思路。我们在评测集里对比过多个模型，它在代码逻辑推理和边界条件分析上的准确率确实能打。

第三是可控性。Anthropic 的 API 在整个请求参数设计上比较克制，没有一堆花哨项，这对于做自动化集成来说是件好事——参数少了，出错的维度也就少了。至少在参数这个问题上，它比某些堆了一堆超参数的模型好处理得多，CI 任务配置清楚之后基本不用天天调。

不过这些优点在故障发生时都帮不上忙，因为当请求连 API 都到不了的时候，模型再聪明也是白搭。所以下面开始真正进入事故现场。

2. 经典问题一：网络层面被卡住

先说第一个，也是最伤人的一个：unable to connect to anthropic services failed to connect to api.anthropic.com。

2.1 现场还原：unable to connect to anthropic services

这次故障发生在一次常规的 MR 合并窗口。当天傍晚我们开始跑一轮新的 AI 审查任务，计划是跑完这批审查后把几个待合并的 MR 全部合进去。结果 CI 一开跑，AI 审查这个 job 几乎是秒挂的，而且是三个任务一起挂。日志输出停在这样一行：

anthropic.UnableToConnectError: unable to connect to anthropic services failed to connect to api.anthropic.com port 443 after 2500ms

这个报错信息很明确——不是认证问题、不是参数问题、不是限流问题，是压根连不上api.anthropic.com这个域名。连接超时时间是 2500ms，这个数字是 HTTP 客户端配置的默认超时，说明 TCP 层面就没建立起来连接。

当时第一反应是查服务状态。我直接去 Anthropic 的状态页看有没有 incident，结果显示全部绿色。那就基本上可以排除是对方服务整体挂了，问题大概率出在我们自己这一侧的网络链路。

2.2 排查过程：从进程到网络再到出口策略

排查网络问题，我的习惯是层层往上走，像剥洋葱一样从自己这边往外剥。

第一步是确认 runner 节点本身能不能解析并访问这个域名。我先 ssh 上 runner 所在的节点，直接敲curl -v https://api.anthropic.com看返回。结果发现节点本机访问是通的，DNS 解析正常，TLS 握手也顺利完成。这就很有意思了——问题不在 runner 节点本身，而在 runner 节点和最终请求之间的某个环节。

第二步是查看 CI job 的运行方式。我们的 runner 跑在 Kubernetes 里，job 是通过一个动态 pod 执行的。问题很可能藏在这里面。我直接进 pod 里再试了一次 curl，果然，pod 里无法解析域名，nslookup api.anthropic.com直接超时。

第三步是看 pod 的网络配置。Kubernetes pod 默认走集群的 DNS 服务，如果 DNS 里没有配置外部域名解析的转发规则，或者网络策略限制了对公网的访问，就会出现“宿主机能通、pod 走不通”的现象。这次的现象就是典型的 pod 层出站网络受限。

第四步是查网络策略。Kubernetes 中配置了 NetworkPolicy，它可能对 pod 的出站流量做了白名单限制。我们当时的策略明确只放行集群内部通信和若干个白名单外部域名，api.anthropic.com不在其中。这就是根因。

你可以想象一下这个画面：宿主机配置没有问题，集群整体也没有问题，但是 CI 任务运行在 pod 这个隔离层里，被一张看不见的 NetworkPolicy 挡住了。原因很平淡，但也正是这种平淡让排查过程格外漫长——因为你潜意识里总觉得“网络问题应该出在网络设备上”，很难第一时间想到是 Kubernetes 网络策略这种带应用层属性的配置。

2.3 这类问题的常规病灶与对策

这类连接失败的问题，在 CI 环境里有几个非常常见的病灶，我直接整理成一份检查地图：

• 环境变量残留了HTTP_PROXY/HTTPS_PROXY。CI 构建环境的镜像经常是从某个基础镜像继承来的，如果 base image 里设置了代理环境变量，你调外部 API 时请求会走代理，代理一挂就全挂。而且关键是这种问题具有随机性，不是每次都会触发，非常坑。
• DNS 解析策略。容器环境的 DNS 配置默认是ClusterFirst，即先查集群 DNS，查不到再转发到上游。如果集群 DNS 的转发配置不对，就会出现宿主机能解析、容器解析不了的情况。
• 防火墙和出口策略。与上面说的 NetworkPolicy 类似，企业防火墙、云安全组、服务网格的 sidecar 都可能挡掉出站流量。
• IPv6/IPv4 双栈问题。有些环境里 DNS 返回了 IPv6 地址，但容器网络没有路由，导致连接一直卡在超时。用curl -4先试一把，可以快速排除。

我遇到这种问题，现在习惯性会先做一步：在 CI 脚本里加一段网络自检。不用写得很复杂，几行 shell 就行，比如用curl -sS -m 5 -o /dev/null -w "%{http_code}" https://api.anthropic.com打印出连接状态。如果连接失败，job 直接输出“网络不通，请检查白名单”，而不是让后面的业务代码跑半天之后才报一个晦涩的异常。这个自检不是给系统看的，是给人看的——故障发生时，每一分钟都是在跟窗口期赛跑，能让定位快一秒都是赚的。

3. 经典问题二：网关路由与模型参数

网络问题解决后，CI 恢复了正常运行，但没过多久，我们又在日志里撞见了另一个雷：claude doesn’t look like an anthropic model: expected a gateway model route。

3.1 报错现场：claude doesn't look like an anthropic model

这行报错，说句实话，比前面的网络错误更让工程师头大。网络错误至少能凭直觉去查连通性，但这条错误信息写的不是“invalid api key”，也不是 “model not found”，而是一句看起来像在质检模型身份的话。第一次看到的人，很容易误以为是 Anthropic 那边对模型做了某种资格校验。

实际上去拆解这行报错的信息结构，它是在告诉你：你声称调用的这个模型名，在 Anthropic 的网关列表里找不到对应的路由。也就是说，你传进去的model参数，和网关侧配置好的模型路由表对不上。

在 Anthropic 的 API 设计里，有个概念叫做 Gateway Model Route，简单理解就是：API 网关层会根据你请求中携带的模型名称或路由标识，决定把请求转发给哪个实际的模型实例。你传的模型名如果不在路由表里，网关就会直接拒绝，不会去尝试猜测你的意图。

3.2 路由机制与 model 参数的真实含义

在这里我先把 model 参数真实的解析路径讲清楚。你调用 Claude API 的时候，请求体里有model: "claude-xxx"这个字段。拿到这个字符串后，网关首先会做一个动作：匹配路由表。如果匹配成功，就转发到对应模型；如果匹配不到，它不会像某些宽容的系统一样给你降级到默认模型，而是直接报错。这种设计有其合理性——在自动化场景里，一个错误的 model 参数可能会悄悄地把请求路由到能力完全不同的模型，产生的结果你还不知情，这对生产环境是危险的。

我当时犯的错误是：模型名配置是从一个旧 document 里复制过来的，写的是某个已经下线的模型名。那段时间 Anthropic 调整过一次模型列表，旧名字被撤掉了，但是我的配置文件没更新，于是所有请求都被网关拒在门外。

排查这类问题的思路很简单但很高效：

• 第一步，先确认你用的 model 名称在当前 API 版本中是否仍然有效。直接去官方文档看模型列表。
• 第二步，确认你访问的 API 端点是否匹配模型类型。Anthropic 有不同系列的模型端点，如果一个请求走错了端点，同样会出现类似的报错。
• 第三步，检查你的请求是否通过中间代理或者网关转发。如果你们企业内部有 API 网关，网关侧的 model 路由配置也要检查——有些中间层会改写 model 字段，改完之后就匹配不上了。

这个问题的隐蔽性在于：如果没有良好的日志记录，你只会看到错误的文本，而不会知道请求实际到了哪个网关、网关里的路由表长什么样。所以在 CI 脚本里，尽量把 model 名称、API 端点、请求 ID 一并打出来，这些东西在问题排查期就是你的救命稻草。

3.3 超参数在自动化场景中的收敛策略

同样是“参数”两个字，model 参数是路由选择的关键，而 temperature、max_tokens、top_p 这些则是控制输出行为的超参数。在 CI 自动化场景里，这两类参数的调法完全不同，但我想先强调一个很多人容易忽略的事实：在 CI 流程里，输出的一致性比创造力重要得多。

什么意思呢？如果你在做一个 AI 聊天产品，temperature 调高一点、给模型一些自由度，可能是加分项，用户会觉得回答更自然、更有灵性。但 CI 里的 AI 审查任务不是这样的——模型的输出会直接决定一个 MR 能不能被合并，或者至少决定审查评论里是否会包含误导性的警告。如果同样的输入，今天输出一个结果，明天又输出另一个结果，你是没法信任这个自动化环节的。

我们现在的做法是：把 CI 场景里所有模型的超参数全部收敛到保守区间。temperature 固定在 0.2 或者更低，top_p控制在 0.9 左右。max_tokens 根据任务类型设定一个明确上限，比如代码审查给到 4096，PR 摘要给到 2048。这样做的代价是输出风格偏保守，但换来的是可复现性和稳定性。

另外一个重要的实践是对超参数做版本化管理。不要把参数散落在各个 CI job 的配置里，而是统一放到一个配置文件或者环境变量组里，跟着代码库走版本。如果模型升级了、参数要微调，review 代码时也能一眼看到改动，不会出现生产环境某个参数已经变了你却毫不知情的情况。

这里我需要提一个在 CI 里最容易踩的坑：不要在 CI job 里把 temperature 调来调去。有些人在本地调试的时候发现某个参数效果不错，直接复制粘贴到 CI 配置里，但 CI 环境的上下文、任务复杂度跟本地完全不同，参数不经过验证就上线，大概率会出问题。我后来总结出一套流程——先在本地跑一个小样本集，把超参数固定下来，验证输出稳定，再同步到 CI 配置。流程虽然多了两步，但故障率降了不止一个量级。

4. 高压工程现实：如何在发布窗口内冷静处理

说完了具体的技术问题，我想花点篇幅聊聊比技术更重要的那部分——面对高压，工程师的排查方式决定了故障的持续时间。

4.1 为什么故障总在最重要的时刻爆出来

这次事故最让人血压飙升的不是错误本身，而是时机。它发生在 MR 合并窗口期的傍晚，整个团队都在等 CI 通过以后合代码，不然功能就赶不上当晚的发布。大量的人盯着 dashboard，每多一分钟红色，你的判断能力就衰减一分。

这不是巧合，而是工程现实里一种很常见的“墨菲定律”。平时任务量不大、并发不高的时候，很多隐患被冗余和运气掩盖了；但一旦流量上来了、任务密集了，问题就会集中爆发。就拿这次来说，我们之前单次跑审查任务时，跑的 pod 可能碰巧分配到了有出站权限的节点，但高峰期 pod 重新调度，新 pod 被分配到了限制更严格的节点，问题立马暴露。

所以我想说的第一件事是：永远不要把 CI 的稳定运行寄托在“能跑就行”上。你要提前预设“它一定会炸”的态度，去设计排查路径。

4.2 分级排查法：5 分钟定位到根因

一线处理过太多 CI 故障后，我慢慢养成了一套自己的排查方法，叫“分级排查法”。核心思路是：不盲目深入细节，先按层次快速扫一遍，每层控制在几分钟内。

第一级，看错误类型。读报错关键字，判断是哪类问题：连接类（connect、timeout、DNS）、认证类（authentication、permission、key）、逻辑类（model not found、validation error）、限流类（rate limit、too many requests）。这一步通常半分钟之内完成。你不用理解细节，只需要知道该往哪个方向查。

第二级，看基础设施状态。如果是连接类错误，直接看 runner 节点、容器网络、DNS、防火墙。这时候我通常用一套固定的自检脚本，在 30 秒内把网络层面的可能风险点全部探测一遍。如果探查结果都正常，再往上层走。

第三级，看业务配置与调用逻辑。model 名、API 端点、密钥注入方式、环境变量是否遗漏。很多报错一搜就能对上号，但你是亲眼看到过日志中的上下文，知道哪儿最可疑，就直接去看那个地方。

第四级，才轮到翻代码和依赖库行为。SDK 的配置、中间代理的转发规则、重试逻辑是否被改写，这类问题最耗时，所以尽量在前几级就解决掉。如果走到这一级，说明前面所有判断都失败了，这时候建议直接在代码里加日志，重新跑一次完整流程，看实际请求到了哪一步。

这套方法在高压场景下最重要的价值是：它给了你一个冷静的框架。你不需要烧脑去猜，只需要严格按顺序执行。每一次失败的排查，都能向前推进至少一层。

4.3 让 CI 任务学会“失败得体”

“失败得体”这个词是我自己编的，意思是：CI 任务挂在外面不可怕，可怕的是挂得没有信息量，挂得让排查者无从下手。

我强烈建议每个 CI 任务在失败时都要做三件事：

• 输出结构化的错误信息。不要只 print 异常类型，要把 HTTP 状态码、响应体、请求 ID、model 参数、超时时间这些关键字段全部打出来。我当时排查路由错误时，全靠日志里的 model 字段和请求 ID 才确认了是模型名写错，如果日志只有一行 “Request failed”，我可能得重新手动构造请求才能复现。
• 把失败分类。网络错误、认证错误、限流错误、逻辑错误、未知错误，每一类用不同的退出码或者在输出里打不同的前缀。这样后续无论是人看日志还是写自动化告警，都能立刻区分故障类型。
• 失败时输出排查建议。这是最被人忽略但也是最省事的一步。我们在异常处理里做了一张映射表：如果报unable to connect to anthropic services，输出“请检查 CI 网络连通性”；如果报模型路由错误，输出“请确认 model 参数是否在最新模型列表中”。这些建议输出来后，下一班接手的同事也能直接上手，不必半夜摇人。

在 CI 的世界里，故障绝不是“能不能避开”的问题，而是“来了之后你慌不慌”的问题。有了这套失败处理，你会发现自己面对红灯时的心态完全变了——不是恐慌，而是开始按流程收数据。

5. 实操：一套可复用的最小实现

理论讲再多，不如直接给代码。下面这套方案是基于我们这次故障之后重构过的版本，你可以直接拿去用，改一改参数就能跑。

5.1 GitLab CI 配置片段

.gitlab-ci.yml里定义了一个跑 AI 代码审查的 job。核心点在于：把网络超时时间设置得宽松一点，同时把 job 超时和重试策略显式配置出来，避免某个任务卡死导致整个 pipeline 停滞。

ai-review: stage: review image: python:3.11-slim script: - pip install anthropic==0.40.0 - python ci/ai_review.py variables: ANTHROPIC_API_KEY: $ANTHROPIC_API_KEY ANTHROPIC_MODEL: "claude-3-5-sonnet-latest" ANTHROPIC_TIMEOUT: "60" ANTHROPIC_MAX_TOKENS: "4096" ANTHROPIC_TEMPERATURE: "0.2" only: - merge_requests retry: max: 2 when: - runner_system_failure - stuck_or_timeout_failure timeout: 10m

这里有几个配置细节我需要解释一下：

retry的when字段我只允许了runner_system_failure和stuck_or_timeout_failure两种失败原因触发重试。为什么不重试 API 本身的报错？因为如果是认证失败、模型路由失败这类业务错误，重试一定是白给的，只会浪费时间。只有基础设施层面的短暂故障，才值得重试。

timeout: 10m是给整个 job 一个硬性时间保障。没有这个配置的话，万一某个请求因网络原因卡死，job 可能要等很久才超时，整个 pipeline 都被拖住。10 分钟这个值是我这边 AI 审查任务正常耗时的三倍左右，留足了余量。

绝对不要在.gitlab-ci.yml里写死 API key。用$ANTHROPIC_API_KEY这种变量引用，然后去 GitLab 的 CI/CD Variables 里配一个 Masked 变量。另一个容易踩的坑是：如果你用了 Kubernetes runner，image: python:3.11-slim这个镜像里默认不带 curl 和 dig 工具，网络自检脚本就得用 Python 来写，否则会报/bin/sh: curl: not found。

5.2 调 API 的 Python 脚本

下面是核心的调用脚本，我做了简化并保留关键逻辑。

import os import sys import time from anthropic import Anthropic def check_network(): """网络自检：在调用 API 前先确认连通性""" import socket host = os.getenv("ANTHROPIC_HOST", "api.anthropic.com") port = 443 try: socket.create_connection((host, port), timeout=5) print(f"[CHECK] network to {host}:{port} OK") return True except OSError as e: print(f"[CHECK] network to {host}:{port} FAILED: {e}") return False def post_review_comment(review_text: str): # 这里对接你们的 GitLab API，发评论到 MR print(f"[INFO] would post comment: {review_text[:50]}...") def main(): model = os.getenv("ANTHROPIC_MODEL", "claude-3-5-sonnet-latest") timeout = float(os.getenv("ANTHROPIC_TIMEOUT", "60")) max_tokens = int(os.getenv("ANTHROPIC_MAX_TOKENS", "4096")) temperature = float(os.getenv("ANTHROPIC_TEMPERATURE", "0.2")) if not check_network(): print(f"[FATAL] cannot reach api.anthropic.com. " "Check runner egress rules / NetworkPolicy.") sys.exit(2) api_key = os.getenv("ANTHROPIC_API_KEY") if not api_key: print("[FATAL] ANTHROPIC_API_KEY is not set") sys.exit(2) diff = os.getenv("CI_MR_DIFF", "") # 正常场景从这里读取 MR diff if not diff: diff = "Sample code:\ndef add(a, b):\n return a + b\n" client = Anthropic(api_key=api_key, timeout=timeout) try: response = client.messages.create( model=model, max_tokens=max_tokens, temperature=temperature, messages=[ { "role": "user", "content": ( "You are reviewing a code change. " "Find bugs, race conditions, edge cases. " "Reply in concise bullet points.\n\n" f"<diff>\n{diff}\n</diff>" ), } ], ) except Exception as e: err_cls = type(e).__name__ print(f"[ERROR] anthropic call failed: {err_cls}: {e}") # 这里我们故意在错误输出里带上排查建议 if "connect" in str(e).lower(): print("[HINT] Check egress network: runner pod -> api.anthropic.com") elif "model" in str(e).lower(): print(f"[HINT] Check model name: '{model}' is valid and not deprecated") elif "authentication" in str(e).lower(): print("[HINT] Check ANTHROPIC_API_KEY secret is valid") sys.exit(3) review_text = response.content[0].text print(f"[INFO] review generated, chars={len(review_text)}") post_review_comment(review_text) if __name__ == "__main__": main()

注意这个脚本里check_network()的存在——它在业务逻辑开始前先把网络问题隔离出来，相当于给 CI 流程加了一道“红灯预检”。别小看这几行代码，它让我后续任何一次 AI 任务出问题，都能在 5 秒内分辨出是网络问题还是 API 业务问题，而不是互相猜疑。

5.3 参数清单与建议值

我把这次实践中所有的关键参数集中放一张表，方便你直接复制去配置。

这个参数表看着简单，但每一条都是从故障里换来的。特别是 temperature 这个值，我们最早跑过一次对比实验，同一段代码用 temperature=0.2 和 0.8 各跑十轮，0.2 的结果一致性明显更高，误报率也更低。所以 CI 自动化任务里，超参数越收敛，结果越可信。

6. 故障速查表与避坑清单

最后一个部分，我把这次事故里遇到过的所有报错、原因、排查命令和解决方案整理成一张表，你可以贴在团队 Wiki 里或者自己收藏。

6.1 避坑清单

除了速查表，还有几条案例里不太容易直接浮现的避坑经验，单独一条条列出来。

• 不要在 CI 里用最新模型名称的“短期别名”。Anthropic 会更新模型版本，短期内别名的指向可能变化，昨晚好好的配置今天可能就报路由错误。我们后来直接固定到一个明确的版本号模型名，牺牲了一点“追新”的爽感，换来了稳。
• 一定不要把 API key 打到日志里。排在排查第一位的永远是认证错误，如果日志里出现了 key 的任何一部分，马上把日志清掉并轮换 key，别抱有侥幸心理。
• CI 任务里尽量不做大并发调用。一次 MR 审查只需要一次请求，串行执行绰绰有余。并发一开，回车集群限流，错误信息从 “model not found” 变成 “rate limit”，排查范围反而变大。
• 网络自检别只检查一次。如果你的 runner 是多节点环境，或者 pod 会重新调度，一次检查通过不代表每次检查都能通过。最好在脚本里做成每次调用前都做一次轻量连接检测。

6.2 从这次事故里总结出的工作习惯

最后分享两个可能对你有帮助的小习惯，都是在这次高圧事故之后我慢慢固定下来的。

第一个是“本地先行”原则。任何对 CI 配置的修改，第一步永远是在本地环境先跑通。拿这次的事故来说，我用一个本地 Python 脚本、同一个 model 参数先调一遍 API，确认模型名没问题后，才去怀疑 CI 环境的问题。这个顺序的重要性是：它能帮你把“代码问题”和“环境问题”彻底分离开来，避免在错误的楼层里找电梯。

第二个是“日志留档”原则。每次 CI 故障的排查过程，我会顺手把报错摘要、根因、处理方案整理成一条记录放进团队共享文档。积累到一定程度，你就会发现，CI 环境的故障类型就那么多，大部分历史问题完全可以通过搜索历史记录来定位，不用每次从头查一遍。

经历过这次事故，我最大的体认是：接入外部 AI 服务这件事，真正的难点从来不在模型推理有多么复杂，而在工程链路的每个环节如何保持稳定和透明。网络、路由、参数、重试、日志，每一项单独拆开都不难，但组合在一起、再叠加一个发布窗口的压力，你才会理解什么叫“工程现实”。希望这篇记录能帮你少熬一个凌晨。