1. 事故复盘我那天经历了什么1.1 日常 AI 基建Claude Code / Codex / Grok 各司其职我属于那种把 AI 当成“数字同事”的人工作流里同时挂着三套主流服务Claude Code 跑在终端里负责主力编码Codex CLI 处理跨仓库重构这类批量任务Grok bot 则用来做文案润色和快速问答。这三个工具各司其职正常情况下配合得相当顺滑但有一天它们突然集体翻车我精心搭建的 Agent 工作流差点就瘫痪了。Claude Code 是我最依赖的一个。安装很简单一行npm install -g anthropic-ai/claude-code就搞定配好 API key 后直接在项目目录里启动会话。它真正厉害的地方不只是代码生成而是能把整个仓库的上下文拉起来理解然后一步步改代码、跑测试、修 bug。我习惯每天早上开工先开一个 Claude Code 会话把前一天没跑完的需求继续往前推。用了几个月下来它几乎成了我肌肉记忆的一部分。Codex CLI 是我的“批处理专员”。它擅长的是那种“给你一个任务你自己去读文件、改代码、跑检查”的无人值守模式。我不会拿它做探索式开发但跨模块重命名、统一日志格式、升级依赖这种事交给它效率极高。安装用的是官方脚本配置里要指定 API 端点和模型名。我通常会给它喂一个需求 markdown让它拆成十几个子任务逐条执行。这种批量能力让你很难割舍。Grok 则相对轻量我主要用它写提交说明、PR 描述或者让它在两个模型回答不一致时投个票。它最大的价值是“语气更接近人”生成的东西不会太像说明书。比如有一次我让三个模型分别解释同一个报错最后 Grok 的表述最直白直接说“这个错误是类型不匹配导致的建议去第 37 行看看”。三家服务有各自的账号和 API key我原以为这种“分布式”布局已经足够稳后来才知道这种想法有多天真。1.2 故障爆发429、连接重置、网页转圈一起袭来那天下午两点左右我在做一个“升级日志系统”的专项任务。Claude Code 刚跑完第一轮仓库扫描正准备把结果传给 Codex CLI 时终端忽然被一堆红色报错刷屏。最典型的是Error: claude-code: Request failed with status 429 Retrying in 15s...刚开始我以为是订阅套餐的并发上限被撞了心想等几秒就好。可过了十分钟429 没消失反而 Codex CLI 那边开始报更严重的错codex endpoint /responses连接被重置偶尔返回一个 200 状态码却带着空响应体。这种“假成功”最坑——我的编排脚本只认状态码空响应也会被当成正常结果继续往下走然后生成一堆基于幻觉的后续动作等到人工发现时已经浪费了很多时间。与此同时Grok bot 在网页端也开始转圈最后弹出一句“服务暂时不可用”。我关掉网页试 API同样超时。那一刻我才意识到不是我的账号出了问题而是“AI 服务大宕机”多家主流模型服务商在差不多同一时间段集体翻车。这种感觉就像你平时依赖的三条高速路同时封路导航再怎么规划也都是死路。1.3 连锁反应我的 Agent 工作流差点整体瘫痪我当时正在跑一条相当典型的 Agent 流水线环节大概长这样Claude Code 扫描所有仓库找出所有旧日志 API 调用点Codex CLI 根据扫描结果生成替换补丁并逐个应用每应用完一个补丁Grok 负责润色提交说明自动化脚本执行测试并推送异常检测。看起来很清晰但故障一出现就全卡住了。Claude Code 在第一步就停了后面环节全在等待任务队列越积越长两个依赖 Claude 输出的子 Agent 在等待超时后直接报错退出连带着整条流水线标记失败。我想手动接管却发现每个环节都是自动触发的根本没有“暂停键”只能看着任务一个个失败。这次事故让我彻底想通一件事表面上我有三家服务互为备份但因为它们都是云端 API底层基础设施、网络链路、甚至故障频段都可能重叠真出大事的时候所谓“多模型协作”和“单点依赖”没有本质区别。后来我不止一次拿这件事提醒团队与其追求“用最多的 AI 工具”不如先把“断了一个怎么办”想清楚。2. 我的 Agent 工作流架构表面上多元骨子里单点2.1 工作流的逻辑分层与依赖关系我搭的这套 Agent 工作流从逻辑上分成四层入口层一个常驻的 Python 编排脚本监听 Git 仓库事件和需求文档变化有新任务就自动拆解入队规划层用 LLM 把任务拆成子任务并决定每个子任务的执行模型这一层同样依赖云端 API执行层Claude Code 和 Codex CLI 在本地终端跑通过 API 调用云端模型完成代码修改和命令执行交付层生成 commit、PR 描述和变更日志用 Grok 做润色或者直接用本地模板。每一层都有明确的分工看起来没有任何问题。但仔细看依赖关系就会发现每一层都卡在“云端 API 必须可用”这个前提上。规划层要调 LLM 做任务拆分执行层要调 LLM 做代码生成交付层还要调 LLM 做文案润色。三层全走云端任何一层断了整个流水线都会停转。更无语的是规划层和交付层其实都是很小的任务完全可以用本地小模型完成但我当时为了省事全走了云端把风险全部放在了一起。2.2 选择这三家的原因以及忽略的隐患选 Claude Code 是因为它长上下文理解和 agentic coding 的稳定度确实是我用过最好的选 Codex CLI 是看中它在批量代码重构上的执行力以及和现有工程流程的匹配度选 Grok 则是纯粹喜欢它输出内容的语气比自己写 PR 描述生动得多。工具本身都很好问题出在我的架构设计。但我忽略了三件非常实际的事。三家服务商虽然品牌不同但它们的高可用机房可能部署在同一个区域区域性的网络抖动完全可能把它们同时带走三家的限流策略各不相同但高峰期的“限流风暴”是同步出现的——当整体请求量暴涨所有服务商都会在差不多同一时间开始拒绝新增请求我的编排脚本没有任何降级逻辑所有失败都只会固定等待后重试重试失败就带着整条流水线一起死掉。这几个隐患平时根本不显眼直到“集体宕机”才一次性暴露。我后来反思真正的“高可用”不是你有几个模型订阅而是你的系统能不能在任意一个模型不可用时继续运转。你把三家都买了不等于你就有了三个选择你只是把同一场事故买了三份。2.3 容易忽略的隐形依赖DNS、网络链路与账户配额除了模型服务商本身我的工作流还依赖很多“看不见”的公共设施。比如本地到 API 的网络链路、系统 DNS 解析、API 网关的限流头信息以及账号本身的配额状态。这些因素平时都不起眼但一旦出问题表现起来和“服务宕机”一模一样。事故当天我第一件事是检查本地网络用curl -I到一些常用站点延迟和丢包都正常说明问题不在我这端。接着我查了各家 API 控制台发现自己的配额并没有耗尽但请求依然被拒。这才锁定问题出在服务端侧。这段排查其实花了我不少时间因为普通的网络检查根本查不出“云服务商内部故障”这类问题。还要提一笔账户配额。很多时候“大宕机”并不是全线瘫痪而是限流风暴。由于某个时段请求暴涨服务商为了保障核心用户开始对普通订阅做激进限流你越重试越触发限流最终进入恶性循环。所以排查时一定要把“配额不足”和“服务端故障”分开看两者处理方式完全不同。前者是省钱和规划问题后者是容灾和降级问题混在一起处理只会越搞越乱。3. 从报错到定位我的排障实录3.1 把报错信息当线索而不是噪音面对一堆报错时最忌讳的是看到什么就重启什么。我会先把报错归类按照下面的表快速判断问题层面错误类型典型症状可能原因429Request failed with status 429配额不足、限流策略触发5xx500 / 502 / 503服务端异常或网关故障连接层Connection reset / timeout网络链路、CDN、基础设施假成功空响应但状态码 200服务端返回异常需要校验内容这张表的价值在于它把“用户可控”和“用户不可控”的报错分开来了。429 和 5xx 虽然是服务端返回的但前者还掺杂着配额因素后者基本就是服务端问题连接层错误则可能来自本地的网络链路。先分类再决定是重试还是停机能省下大量无效操作。那天我一开始看到 429 就以为是配额问题结果 Codex CLI 那边跟着出现连接层错误这基本就排除了“只限流”的可能。再去翻三个官方状态页发现都在不同时段出现了异常同时第三方监测平台也有大量用户反馈基本可以断定是行业级事故。这时候再看自己终端的报错每条都像诊断报告不再是无意义的噪音。3.2 排障顺序先本地后云端先验证再假设我整理了一个固化下来的排查流程现在每次出问题都照着走效率提升不少先用curl -I直接打 API 端点看 HTTP 状态码和响应时间确认本地链路是否正常检查本地 CLI 工具的配置比如环境变量、API key 是否过期以及本地是否有非必要的中转规则打开各家官方状态页和官方账号看有没有发布故障公告用第三方监测平台做交叉验证判断影响范围确认是远端故障后立即停掉自动重试启动降级方案。如果前两步都是正常的基本可以断定是远端问题。这时候千万别继续重试重试只会让限流更严重正确做法是暂停相关任务改走备用通道。我记得那天我还在犹豫要不要继续等后来发现等下去毫无意义果断把主流程切到了人工模式至少保住了最核心的仓库扫描结果。3.3 复盘时发现的定时炸弹睡死重试与级联失败排查过程中我发现了工作流里的两个致命设计缺陷。第一个是“睡死重试”。我的旧编排脚本遇到 429 后固定等待 15 秒再重试一旦遇到持续限流几百个子任务就会同时卡在重试循环里。这不仅拖垮了我自己的任务队列还给 API 侧增加了很多无效压力。后来我把重试改成了指数退避并且加上最大重试次数超过阈值就熔断。这个改动虽然不起眼但效果立竿见影至少不会再出现“任务把自己卡死”的傻事。第二个是“级联失败”。旧工作流里一个子任务失败后它下游的所有任务都会跟着失败整条主流程归零。这个设计在“所有服务都正常”时看不出问题可一旦上游进入降级状态下游全得陪葬。后来我给每个子任务加了执行状态机支持跳过、重试、标记人工处理才算堵住这个坑。其实这些概念做后端的人天天讲但真正做到 Agent 工作流里的很少大家都默认 API 永远可用。4. 高可用改造给 Agent 工作流加逃生通道4.1 多供应商冗余把写死的模型改成动态路由我做的第一件事是把执行层从“写死调用某一家”改成动态路由。核心思路是为每个模型封装统一的接口让路由层根据健康状态和优先级自动选择供应商。这样做的目的不是追求“最强模型”而是追求“什么时候都有的用”。MODEL_TIERS [ {name: claude, client: claude_client, priority: 10}, {name: codex, client: codex_client, priority: 9}, {name: grok, client: grok_client, priority: 8}, {name: local, client: ollama_client, priority: 5}, ] def execute(task): for tier in MODEL_TIERS: if not is_healthy(tier[name]): continue try: result tier[client].run(task) return validate_result(result) except ServiceUnavailable: mark_unhealthy(tier[name], cooldown120) continue raise AllServicesDown()这里有一个细节每个任务不会盲目选择优先级最高的模型而是从任务的preferred_models列表里选。比如某个任务明确依赖 Claude 特有的 artifacts 能力那就把 claude 设为唯一首选其他模型作为兜底如果某个任务只是普通的代码格式化则让本地模型优先节省 API 配额。我还给路由层加了一个健康状态缓存每个服务连续失败两次就会被标记为不健康冷却两分钟后再探测避免每次都去试错。4.2 本地模型兜底云端全挂时的最后防线当所有云端供应商都不可用时本地模型是唯一的逃生通道。我在工作流里接入了 Ollama跑一个 7B 级别的代码模型。它写复杂逻辑的能力确实不如云端大模型但做基础补全、格式化、生成提交说明完全够用。安装和配置都不复杂官方镜像拉下来就能在本地起服务接口风格也和 OpenAI 兼容改几行 base_url 就行。具体做法是路由层检测到所有云端服务都不健康时自动把执行层切换到本地 Ollama同时把任务标记成“降级模式”。降级模式下我只允许它处理低风险任务——比如生成 commit message、修 lint 错误、跑静态检查涉及核心业务逻辑改动的任务则进入待人工审批队列绝不会让本地模型直接改代码。这道限制看着保守但非常有必要因为本地小模型的“幻觉率”相比云端大模型还是要高一些让它碰核心逻辑只会帮倒忙。这一步很重要它的目的不是追求效果而是保证工作流不断线给云端恢复争取时间。实测下来那天三家服务修好后我的任务队列里只积压了少量降级任务整体损失比之前预计的小得多。4.3 超时、退避、熔断与降级把“集体宕机”变成“局部抖动”我封装了一个调用 API 的健壮性中间件关键参数调整如下参数原值修改后作用单次请求超时120s45s快速失败避免线程阻塞第一次重试延迟15s5s缩短等待快速探测恢复最大重试次数无限3次防止死循环重试退避公式固定等待指数退避base * 2^attempt减轻服务端压力熔断阈值无连续失败5次熔断2分钟保护配额和系统资源熔断器的逻辑有点像家里停电后的总闸一旦检测到连续失败直接切断对该服务的调用而不是硬着头皮反复试。2 分钟后放一个探测请求成功才恢复服务。这个改造带来的最大变化是即便某个模型还在故障也不会继续消耗我的配额整体的“故障半径”被控制住了。另外我把“超时”也分成了连接超时和读超时两层。连接超时设成 10 秒读超时设成 45 秒避免某些服务“已经建连但一直不返回响应”把线程拖死。这套参数在不同网络环境下可以调但整体思路就是快速失败、快速切换哪怕是误判也比一直挂起强。4.4 断点续跑让任务队列不因一次故障清零断点续跑也是这次改造的重头戏。我给每个子任务加了一个幂等状态用 SQLite 记录执行状态取值包括pending、running、completed、failed、manual。工作流中断后编排脚本重启时会读取这个状态库跳过已经completed的任务只重跑pending和failed的任务。举个例子20 个仓库补丁任务跑到第 7 个时宕机了以前只能清空队列从头跑现在重启后脚本直接从第 8 个继续。这个能力在日常开发里价值巨大因为断网、断电、系统重启都难免发生只要任务能断点续跑就不会白白浪费时间。写状态库的时候要注意一个细节必须在每个子任务真正完成后才更新状态而不是在任务开始前就标记。否则任务执行一半崩了状态却显示完成重启后就会跳过它造成数据丢失。我的做法是在任务函数末尾统一调用mark_completed(task_id)执行过程中不管怎么异常都不会误标。“先做事后记账”这个原则做任务系统的人应该都很熟悉但真的很容易忽略。5. 日常避坑与监控告警经验5.1 为 AI 服务加监控比官方状态页快一步官方状态页往往有延迟而且只反映“是否挂了”不一定反映“是否可用”。我后来自己写了一个简单的健康检查脚本每两分钟请求一次各家 API 的真实推理接口记录响应码和时延一旦连续三次非 200就通过群机器人推告警到手机。这个脚本本身没什么技术含量关键是它把“人工盯着状态页”变成了“系统主动通知你”。这里有一个小技巧不要只探测像/models这种轻量管理接口最好真正发一个小成本的推理请求比如max_tokens1的最简 completion。因为某些服务可能“状态页正常但推理服务挂了”只有真实请求才能暴露问题。虽然这种探测会带来一点点额外费用但相比一次事故造成的损失这点钱完全可以忽略。另外健康检查的数据也可以直接喂给路由层。每次探测成功就把结果写入一个本地 JSON 文件路由层读取后就能知道哪些服务当前是健康的而不是每次任务都要先试错一遍。这个联动改造之后我的 Agent 工作流在故障期间的切换速度明显快了。5.2 配额预警别等到 429 才后悔另一个经验是把配额管理前置。我每个月会预估各家服务的使用量并在 API 控制台设好额度告警。比如某家服务当日消耗量达到 80%就自动停掉非关键任务只保留核心任务。这样既避免月底超支也大幅降低触发限流的概率。很多人的 429 其实不是服务商挂了就是自己把配额用光了然后在最不该出问题的时候卡住。同时我在路由配置里把任务分成不同优先级核心任务走付费和稳定性更高的服务非核心任务走更便宜的备用模型。这不仅能省钱还能避免“所有任务都挤在同一份配额里大家一起撞线”的尴尬。比如批量文档润色我全丢给 Grok 或者本地模型Claude 的配额都留给代码改造。实践证明这种分流比单纯提高订阅等级划算得多。5.3 常见问题速查表我把这段时间遇到的高频问题整理成了一张速查表也分享给了团队同学大家反馈说比翻官方文档快得多。尤其是那种“看着像宕机其实是自己配置问题”的情况表格里基本都有对应解法。症状最可能原因解决思路Claude 突然 429账户额度或区域限流查用量控制台切换备选模型Codex CLI 报 Connection reset服务端网关故障停止自动重试查看状态页Grok 网页端转圈官方服务异常等待恢复或改用 API 调用空响应却显示成功服务端返回了畸形 body增加响应校验空内容判为失败编排脚本定时卡住超时过长或重试死循环缩短超时启用熔断机制本地模型参与后质量下降模型能力不足限定为低风险任务核心逻辑人工处理表格里最值得说的是“空响应却显示成功”这一行。很多 agent 框架只校验 HTTP 状态码不校验内容这导致服务端返回空 body 时也会被判为成功。我后来在所有解析响应的地方统一加了内容校验只要content为空就抛异常这才堵住这个坑。5.4 把宕机当常态Agent 工作流的设计原则最后说点非技术的事。这次事故彻底改变了我设计系统的心态从“默认 AI 服务永远可用”变成了“默认 AI 服务随时可能挂掉”。任何一个新的 Agent 工作流上线前我都会问自己三个问题如果所有云端模型同时挂掉我还能手动完成任务吗如果某个模型连续失败工作流能自动降级到可用模型吗任务中断后重启能不能从断点继续而不是从头再来这三个问题的答案我会写进架构评审 checklist 里。把逃生通道当成第一需求而不是事后补救才是这次“AI 服务大宕机”给我上的最重要一课。技术的细节可以慢慢调但如果整个系统压根没有“逃生”的概念那平时跑得再顺也可能在某一天突然归零。这次“AI 服务大宕机”最后持续了几个小时三家服务才陆续恢复。我虽然没有损失关键数据但那种看着工作流瘫痪却无从下手的感觉真的不想再体验第二遍。后来我在每一次架构评审里都把“逃生通道”列为必查项本地模型兜底、多供应商路由、熔断降级、断点续跑缺一样都不允许上线。如果你也在跑类似的 Agent 工作流趁着服务都正常赶紧把这些能力补上。等真出事了再想对策就像着火之后才找灭火器不是每次都这么幸运的。