先说结论凌晨两点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 doesnt 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 根据任务类型设定一个明确上限比如代码审查给到 4096PR 摘要给到 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 anthropic0.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 runnerimage: 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), timeout5) 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_keyapi_key, timeouttimeout) try: response client.messages.create( modelmodel, max_tokensmax_tokens, temperaturetemperature, messages[ { role: user, content: ( You are reviewing a code change. Find bugs, race conditions, edge cases. Reply in concise bullet points.\n\n fdiff\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 参数清单与建议值我把这次实践中所有的关键参数集中放一张表方便你直接复制去配置。参数建议值为什么是这个值ANTHROPIC_MODELclaude-3-5-sonnet-latest用最新的长上下文代码模型ANTHROPIC_TIMEOUT60秒太短容易误判网络故障太长会拖垮整个 jobANTHROPIC_MAX_TOKENS4096代码审查输出一般不超过 4k tokenANTHROPIC_TEMPERATURE0.2尽量保守保证输出的一致性CI job timeout10 分钟正常任务 3 分钟左右三倍余量retry max2只对基础设施失败重试不重试业务错误API key 存储GitLab Masked Variable绝不能进代码库或明文 job 日志这个参数表看着简单但每一条都是从故障里换来的。特别是 temperature 这个值我们最早跑过一次对比实验同一段代码用 temperature0.2 和 0.8 各跑十轮0.2 的结果一致性明显更高误报率也更低。所以 CI 自动化任务里超参数越收敛结果越可信。6. 故障速查表与避坑清单最后一个部分我把这次事故里遇到过的所有报错、原因、排查命令和解决方案整理成一张表你可以贴在团队 Wiki 里或者自己收藏。报错信息关键字可能原因快速排查命令/手段解决方案unable to connect to anthropic services / 连接超时DNS、防火墙、NetworkPolicy、代理配置curl -v https://api.anthropic.com进入运行 job 的 pod 里执行同样的命令对比两个结果给 CI pod 添加外部域名放行规则移除残留的代理环境变量claude doesnt look like an anthropic model / gateway model routemodel 参数错误、模型已下线、中间网关路由表未更新在请求日志中打印 model 参数去官方文档核对当前模型列表更新 model 参数为最新可用模型名同步中间网关的路由配置authentication_errorAPI key 无效、过期、未注入打印$ANTHROPIC_API_KEY前缀或长度确认用 curl 带 key 手动请求重新生成 key 并替换 CI/CD Variablesrate_limit_error请求频率超限查看响应头里的x-ratelimit-*字段在脚本中加指数退避重试或者把并发任务改为串行context_length_exceeded请求上下文过大统计 diff 的 token 数确认是否超出模型上下文窗口压缩 diff只保留变更函数上下文或者换更大的上下文模型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 服务这件事真正的难点从来不在模型推理有多么复杂而在工程链路的每个环节如何保持稳定和透明。网络、路由、参数、重试、日志每一项单独拆开都不难但组合在一起、再叠加一个发布窗口的压力你才会理解什么叫“工程现实”。希望这篇记录能帮你少熬一个凌晨。
/YOLO无人机视角行人检测)
