上周三上午十点左右我的屏幕从左到右依次飘红。先是Claude Code第一个请求超时重试两次后直接503接着Codex端点的/responses请求也失败提示找不到可用通道最后连Grok Bot都开始限流页面只留下一句“稍后再试”——三个后端在几分钟内集体掉线我精心搭了半个多月的Agent工作流瞬间进入半瘫痪状态。这篇文章不是复读新闻稿而是想聊聊那天我实际做了什么怎么判断故障范围、怎么用本地模型顶着跑、怎么保住半成品任务不丢以及事后我把哪些容灾设计固化成了常态。如果你也在用Claude、Codex、Grok这类AI服务搭Agent工作流或者正在做自己的Agent项目这篇东西值得你花几分钟看完因为我踩过的坑你大概率也会踩一遍。1. 宕机日复盘我的Agent工作流到底断在哪1.1 我平时怎么用Claude、Codex和Grok先交代一下背景。我说的Agent工作流不是调一个API就完事的玩具而是真正跑在日常开发里的多代理协作链路。我同时挂着三个后端Claude Code在终端里负责核心代码生成Codex负责测试补充和提交信息产出Grok Bot负责技术资料检索和方案对比。三者之间不直接互相调用由我手里的少量脚本统一编排。Claude Code最适合“读仓库改多个文件”这种活。它配合MCP server读接口定义、查调用链、跑lint能把“帮我重构支付模块”这个模糊需求翻译成十几个文件的实际修改。Codex则适合处理已经成型的diff给它一段改动让它补边界测试、检查兼容性、生成commit message这类结构化任务它做得很稳。Grok Bot被放在“外脑”的位置遇到不熟悉的开源项目、需要快速比较几个存储方案的时候直接问它省去大量翻文档的时间。这套设计的初衷很简单就是让每家模型的强项各管一段。但那天宕机之后我才意识到它有一个致命前提这些服务必须一直活着。1.2 故障第一现场三个服务几乎同时顶不住时间点我记得很清楚。10点02分Claude Code的第一次请求超时我那套脚本按老规矩自动重试第二次、第三次都失败返回503。10点05分Codex端点的/responses开始报错日志里出现类似连接被断开的提示。10点08分Grok Bot的接口限流控制台显示额度暂时不可用。最让我头皮发麻的不是报错本身而是调度脚本还在“忠实地”做自动重试。三路并发重试把剩余可用配额打得干干净净。终端里全是退避等待的日志一条接一条看着就像流水线同时在所有工位卡住。那一刻我意识到所谓的Agent工作流本质上是一个脆弱的单点依赖系统模型服务一旦抽风所有下游环节一起停摆。1.3 影响链分析为什么模型挂了活就干不动很多人以为AI服务宕机最多就是“晚点再跑”但在我这种用法里问题远比这严重。我把太多判断交给了模型。一个改动从理解需求、产出代码到补测试、写说明每个环节都依赖模型确认它一断整条流水线就停在半成品状态。更麻烦的是会话上下文的丢失。Claude Code这类工具的核心优势是长期记住仓库上下文但服务重启后Agent对项目的“记忆”必须重新灌入上下文窗口又有限宕机时间越长重新组织上下文的成本越高。我当天有几个任务就是卡在“已经读了一大堆文件还没开始改”的状态服务恢复后只能全部重来。第三个影响是人自身的遗忘。任务悬停在半路如果中间没有落盘记录就连你自己都忘了刚才让Agent改到什么程度。经过这次复盘我彻底想明白了Agent工作流的瓶颈从来不是模型能力而是依赖设计。2. 多AI协作架构不是押注一家而是设计一套依赖网络2.1 为什么坚持三家同时用有人问我为什么不干脆只押一家省心又省钱。我给的答案很直接单家服务不可能永远在线多供应商架构才是常态。假设每个服务每月故障概率5%三家在同一个小时全部不可用的概率确实还在但长期来看比单家稳定得多。这次虽然撞上了但也证明我没有押错方向。能力差异是第二层原因。Claude Code在代码语境理解和长上下文上确实稳尤其适合多文件重构。Codex在结构化输出和测试生成上更强给它的diff越明确它给出的结果越规整。Grok Bot的优势是响应快、信息归纳直接适合外围情报收集。既然三家各有擅长把它们拆开用正好把任务分发到最合适的模型上。成本上也有讲究。三家的计费单位和免费额度不一样外围任务丢给便宜的通道核心任务才走旗舰模型整体开销比单家硬扛低不少。这里顺便说一句“harness和agent区别”我理解的harness是编排层负责路由、重试、状态管理而Claude Code、Codex这些是agent是具体执行单元。没有harness层三个agent就只是三个孤岛谁挂了都难以及时切走。2.2 职责切分与协作接口多AI协作最怕的就是“谁都管谁都不管”所以我把每个角色的输入输出都规定得很死。角色工具输入输出代码生成Claude CodeTASK.md 仓库上下文implementation.diff测试与验证Codexdiff 测试要求test.patch、测试结果摘要情报检索Grok Bot问题描述research.md兜底执行本地模型任务片段局部补丁每个角色的输出都落到文件而不是通过对话框传来传去。这样设计有个非常实际的好处任何一个角色挂了我可以直接把它的输入文件丢给另一个角色接着干。比如Claude Code断了本地模型也能照着implementation.diff的任务描述生成一个改得粗糙但能用的版本后面再让Codex审一遍质量就能拉回来不少。2.3 上下文交接Agent之间怎么“对暗号”多Agent协作最容易翻车的地方是上下文交接。模型没有记忆延续会话一断就是失忆。我的方案是给每个任务建一套标准文件最核心的是TASK.md。TASK.md里会写清楚目标、约束、已完成步骤、下一步建议相当于给Agent做交接班记录。每次会话结束时我也会让当班的模型强制生成一份handoff.md里面写“我读到了什么、改到哪、还有什么坑”。这样服务端会话过期也好切换模型也好新接手的Agent拿这两份文件就能快速续上。这个做法平时看起来有点笨甚至显得多余。但宕机当天正是这些文件让我能在一小时后用本地模型从checkpoint继续跑而不是全部推倒重来。3. 降级自救我在宕机期间做的三件事3.1 第一手操作探活与定位故障范围服务报错之后我做的第一件事不是继续重试而是冷启动检查先判断到底是全局故障还是只有我这边的配置出了问题。方法很简单直接用curl手动打一次对方接口的健康检查路径看看返回什么。响应特征判断动作429 / 403配额或权限问题换key、换组织身份502 / 503服务端故障进入降级流程别干等超时网络或负载过高缩短超时时间指数退避200但响应慢局部拥塞放慢并发预留余量这里提醒一句不要完全迷信服务商的状态页。有时状态页还挂着一片绿但你的账号已经因为并发过高被限流了。以实际请求返回码为准比看公告可靠得多。还有遇到“本地代理配置失败”这类报错时要先分清楚是远端挂了还是自己的配置代码变更导致的问题不然容易白折腾半天最后发现是虚惊一场。3.2 切到本地模型LM Studio兜底Claude Code本地模型这次真的救了我。我机器上常驻了一个LM Studio服务暴露的是OpenAI兼容接口。Claude Code是Anthropic协议但好在它支持自定义base_url我直接通过环境变量指过去绕过云端。# 环境变量方式接入本地模型 export ANTHROPIC_BASE_URLhttp://127.0.0.1:1234 export ANTHROPIC_API_KEYlocal-key export ANTHROPIC_MODELqwen2.5-coder-7b-instructCodex那一路我用类似方式接本地模型只要本地服务兼容OpenAI协议就行。这里最关键的坑是模型名必须和服务端发布的slug完全一致差一个字符都报model not found。我当时第一版配置写错了模型编号排查了十分钟才发现是名字问题。本地模型的定位不是替代旗舰而是接管那些“不需要很高智商”的环节。批量修类型错误、整理代码格式、根据报错日志给出搜索关键词、生成中规中矩的commit message这些活7B模型完全能顶。真正复杂的架构推理和跨文件重构本地模型确实吃力我不会硬塞给它。3.3 纯离线模式不依赖大模型也能维持产出本地模型也不是万能的。Grok挂掉之后检索信息这条路直接断了我一度连“对比两个库的API差异”都做不了。这时候我被迫切回老派做法反而发现很多任务根本不依赖大模型。git stash把半成品保住用grep和sed完成批量替换手写关键测试用例靠lint和编译错误定位问题——这些在AI时代被严重低估的能力在故障期就是救命稻草。我当天下午甚至靠纯离线方式修复了一个线上bug没有动用任何一个模型服务。这件事对我触动挺大。它让我重新认识到Agent工作流的关键路径不该完全押在模型身上至少应该给紧急任务留一条“不经过模型”的旁路。3.4 状态保存与断点恢复让工作流可重放宕机结束后我的第一个动作不是立刻写代码而是做状态恢复。恢复的前提是之前有好好落盘。我现在的习惯是每个Agent步骤完成就自动git commitTASK.md里更新checkpoint标记关键路径再跑一遍snapshot脚本把现场备份下来。恢复流程很简单先git reset到最近一个正常checkpoint打开TASK.md看当前进度再把本地模型顶出来的半成品diff合并进来最后人工review一遍再继续。这套流程在平时看起来只是一堆“额外动作”但在故障日能省下几个小时的重建成本。4. 给Agent工作流做容灾设计的实操清单4.1 依赖分级哪些环节绝不能被AI卡脖子容灾设计的第一步是给工作流里每个环节做依赖分级明确哪些必须靠模型哪些可以降级哪些根本不需要模型。环节需要模型吗备选方案需求理解与拆解否人工主导模型只做辅助头脑风暴代码生成部分需要本地模型兜底、模板代码测试用例设计可降级手写关键用例commit message不需要模板脚本自动生成信息检索可降级本地文档、grep、离线快照分级的意义在于你知道哪些环节必须留足预算和冗余。我给自己的硬规矩是任何关键路径上的任务启动前必须确认有替代执行方案否则先不开始。4.2 标准化任务文件与输出协议容灾的前提是信息可迁移而信息可迁移的前提是格式标准化。我现在每个Agent任务目录下都放一份TASK.md结构固定Agent换谁都看得懂。# TASK: 支付模块重构 ## Goal 把支付流程从同步改为异步兼容原有回调接口。 ## Context 仓库路径services/payment/ 依赖模块notify, order 已知约束不能改动数据库表结构。 ## Constraints - 保持对外接口不变 - 错误处理走统一 log 规范 ## Checklist - [ ] 梳理调用链 - [ ] 实现异步流程 - [ ] 补兼容测试 ## Checkpoint - 当前进度调用链已梳理完 - 下一步实现异步流程输出端我也做了统一约定所有Agent输出必须符合markdown或JSON结构关键字段不许乱写。这样换后端时不用重新教一遍本地模型也能照样解析。4.3 自动降级与重试策略重试策略是这次翻车最直接的教训。我之前用的是固定间隔重试结果三路并发直接把配额打光。现在全部改成指数退避加抖动import random, time backends [claude, codex, local] def run_with_failover(task): for backend in backends: try: result call_backend(backend, task) validate_schema(result) return result except ServiceUnavailable: wait min(2 ** backends.index(backend), 30) random.random() * 2 time.sleep(wait) continue raise AllBackendsDown(所有后端不可用)没有抖动的重试就是灾难。固定间隔重试会在服务恢复瞬间涌进大量请求反而把刚刚站稳的服务再次打挂。指数退避加抖动是基本操作实测下来稳定很多。4.4 我踩过的坑和最终的日常配置踩坑一自动重试打光配额。现在我给所有自动化任务设置了总重试次数上限超了就停下来等人工判断绝不让脚本自己无限耗下去。踩坑二本地模型输出格式不稳定。本地模型能力弱偶尔会生成非法JSON导致下游解析失败。解决办法很简单对关键输出做schema校验不合格就重新生成一次再不行就人工接管。踩坑三把高风险任务交给全自动流程。现在我的硬规矩是任何涉及生产环境的改动不管模型多自信都必须有人工review这道门禁。日常配置上我保留了一个.env.local文件里面装着降级用的本地服务地址和备用key。每天早上开工花三十秒跑一遍探活脚本确认三路云端加一路本地的健康状态。这个习惯给了我很大的安全感。5. 常见故障排查实录从报错到恢复5.1 Claude Code启动报错与VM平台配置Claude Code在Windows上启动报“workspace requires the virtual machine platform on windows”是环境问题不是服务端故障。它的Workspace功能依赖虚拟化组件系统没开启对应功能就会报这个错。排查步骤很明确打开“启用或关闭Windows功能”勾选“虚拟机平台”和“适用于Linux的Windows子系统”重启机器再用wsl --status确认状态。这套操作是纯本机设置和云端服务没有关系。很多人卡在这一步其实只是Windows功能没开全。5.2 Codex端点无响应与组织设置加载问题Codex两块高频故障一是/responses端点请求失败二是组织设置加载不出来。我的排查顺序很固定先用curl手动打一次端点看返回码再确认当前使用的API key有没有对应组织权限最后翻本地配置文件的改动历史看看是不是谁动过配置。这里最容易犯的错是一看到端点报错就怀疑服务挂了。实际上有几次是本地配置里填的endpoint不正确或者是key过期跟远端故障半毛钱关系没有。把配置文件纳入版本管理之后这类问题一分钟就能定位。5.3 Grok Bot不可用时的信息检索替代Grok挂掉的时候我手里最值钱的替代品其实是本地资料镜像。我把常用依赖库的文档仓库全部git clone到本地再定期更新。检索时直接grep或者用RAG做向量索引查询响应速度不比云端接口慢而且完全不受限流影响。我也保留了GitHub代码搜索这条路径查开源项目用法时反而比模型更准。经历过Grok断供之后我给自己定的规矩是任何外部信息源都必须有本地影子否则不把它写进关键流程。5.4 本地模型接入主工作流的配置要点如果你也想把本地模型接进现有工作流几个配置要点供参考。模型选型建议7B到14B参数级别再小就基本不可用再大个人机器跑不动。服务地址用127.0.0.1加固定端口模型名严格对齐服务端发布slug。上下文长度根据显存调别盲目拉满不然吞吐量骤降。temperature设低一点比如0.2输出更稳定适合代码类任务。实测下来本地模型在格式整理、错误日志分析、代码审查补漏这些“检查类”任务上有不错的性价比。但让它们做多文件架构级重构结果基本不能看。所以我只在降级路径上用它从来不让它碰创意型任务。折腾了几个小时后服务陆续恢复。那天我没有急着补进度而是把整个过程的日志整理了一遍该加的落盘、该改的重试、该补的探活脚本当天下午就全部改完。我现在每天早上开工前花三十秒跑一次探活任何Agent任务启动前先确认它有落盘checkpoint任何降级路径至少手动演练过一次。这次Claude、Codex、Grok集体翻车让我真正明白一件事Agent工作流能不能扛住故障拼的从来不是模型有多聪明而是把任务拆小、把状态落盘、把退路留好。我的Agent工作流现在还在跑只是它脚下不再只有一块砖。