企业官网建设流程全解析

聊个很现实的问题：你正在终端里用Codex，让它把某模块的重构方案落地，提示刚打了一半，屏幕突然定住，接着刷出一行白字：Selected model is at capacity. Please try a different model.那一刻你会怎么做？我见过随手连按三下回车、疯狂重试的，也见过直接把窗口关了开始怀疑人生的。老实说，这问题最近确实有点频繁，尤其是工作日的白天，基本隔一段时间就撞上一次，不致命，但非常打断节奏。

这篇文章不打算写什么高深原理，单纯把我在实际项目里摸索出的缓解方法整成一份可照做的清单。适合谁看？第一类是拿Codex当日常编码搭档、被这个报错恶心过的人；第二类是正在写自动化脚本、想尽量避免任务中途挂掉的人；第三类是刚上手、遇到报错一脸懵、怀疑是自己账号出了问题的人。看完你至少能知道：这个错到底是怎么回事，现场怎么应急，平时怎么防范，以及如果它还是出现，该怎么用更高级的姿势绕过它。

1. 这个报错是什么，为什么偏偏盯上你

1.1 报错的典型现场：它不是账号问题

先明确一点：看到Selected model is at capacity时，绝大多数情况不是你账号被封，也不是你欠费，更不是网络出了故障。它是模型服务侧主动拒绝新的推理请求，字面意思就是：你选中的那个模型太忙了，暂时腾不出算力给你，建议换一个池子里的模型试试。

我自己第一次遇到时也怀疑过是不是用量配额用完了，后来点开用量页面，发现消耗量根本没到上限，这才确认是容量问题。两者的区别对你接下来的处理方式影响很大：账号问题你要去检查权限、去续套餐；容量问题你什么都不用动，换个模型或者等一会儿就行。很多人在这里浪费了整整一下午，反复检查订阅、清理缓存、重装客户端，其实完全是错误的方向。

更要命的是，这个报错的随机性很强。同样一个任务，白天撞上，晚上顺滑；同一个时段的同一个请求，换个模型立刻就好。这种"薛定谔的成功率"特别容易让人抓狂，但它恰恰暴露了问题的本质：负载是多变的，不是你的环境变了。

1.2 容量报错背后的运行逻辑

了解一点背后逻辑，就不会乱慌。Codex背后是大量的共享推理集群，这些集群按模型类型拆分资源池。假设某个模型当前同时在跑的请求数是1万，集群上限就是1万，那第1万个之后的请求进来，服务端不会排长队等你，而是直接甩一句capacity错误，让你识趣点换个池子。

这里有个容易误解的点：capacity不是全局统一状态，而是按模型、按数据中心、按时段动态变化的。同一个时间点可能重型模型很挤，轻量模型很空；也可能你所在的区域很挤，另一个区域很空。所以"try a different model"不是官方的敷衍话术，而是真的建议你去试负载更低的资源池。这不是什么隐藏技巧，而是容量架构的基本特征。

你可以把类比放得再日常一点：商场周末只有一家奶茶店，排队半小时起步，旁边另一家没什么人。你换一家买，就能立刻买到。报错就是这个意思——它没有把你拉黑，只是这家"奶茶店"暂时产能满了。换个品牌买，问题当场解决。

这也是为什么企业级专用节点很少触发这个报错：专用资源池是隔离出来的，不跟公共流量挤。普通开发者用的公共入口，波动就大很多。如果你的工作依赖Codex的连续可用性，这一点早晚会让你考虑升级通道或者更灵活的任务编排方式。

1.3 为什么最近感觉变频繁了

如果你最近明显觉得这个报错变多，正常现象。一来是模型能力更新后涌进来的用户变多，二来是很多开发团队开始批量用Codex跑自动化编码任务，自动化脚本一挂就是并发几十路请求，把共享容量吃得更快。再叠加你所在时区的正常业务高峰，就很容易撞上。

从我的观察来看，工作日上午十点到下午四点这个区间是最容易唱的。这个时段对应用户活跃度最高的时间段，容量报错像一个峰值信号器，提醒你：现在全世界的开发者都在干活。明白这几层之后，接下来该看的全是实操。

2. 撞上报错后的应急操作：止损优先

2.1 第一反应：切换模型试试

最直接的缓解方式就是提示里那句"try a different model"。实际操作里，我一般分两种情况：

• 还没发起请求：在初始化模型的选择界面直接换一个模型，比如从更重的推理模型切到轻量模型。这一步很快，几秒钟就能完成。
• 已经会话跑到一半：直接在那段会话里切换不一定可行，我处理的方法是尽量在新会话里重开一次对话，然后一句话说明你要继续的任务，让新会话接管。虽然会损失一部分上下文，但好处是立刻恢复了生产力，而不是干等着。

注意一点：不是所有模型都适合你的任务。轻量模型适合修bug、写测试用例、做小范围代码生成；而重构、架构设计、长文件生成这一类的重任务，还是需要在负载更高的模型下跑。所以切换的时候要结合任务复杂度，临时顶一下可以，重要的长任务不要硬换到完全不适配的模型上，否则后续返工更浪费时间。

我自己的经验是，把模型按"重、中、轻"三个档位分好。遇到capacity时，先试中档模型；中档也失败，再试轻档。这样既能解决眼下的问题，也不会因为降级太多导致输出质量明显下滑。

2.2 等待退避：跟容量搏斗的正确姿势

很多人的下意识动作是立刻重试，而且连续点。这个做法其实最不划算。

服务端的容量状态是动态的，超载高峰期可能持续几分钟到半小时，你在第一分钟里狂点20次，可能19次都被拒。更重要的是，过于高频的请求会让服务端触发你的请求流控，等于你在capacity之外又给自己添了一道坎。这个教训我是真金白银换来的，有一阵子我写了个循环脚本自动重试，结果撞上容量高峰期，脚本以每秒三次的频率连着打了几分钟，不仅一个问题没解决，后面还被限了大约一刻钟。

我的做法是"递进式等待"：第一次失败后等30秒，再失败等2分钟，再失败就直接切后台去做别的任务，过10分钟再回来。这个节奏是从实际工程里的指数退避策略学来的，对容量类错误尤其有效，因为服务端什么时候恢复没有确定值，只有随机等待才能覆盖不同峰谷，乱撞只会消耗自己的耐心和配额。

2.3 缩短上下文：给模型减负

同样一个任务，上下文越短，一次推理占用的算力资源越少，请求被拒绝的概率也越低。Codex每次会把当前会话历史、相关文件的内容一起打包发给服务端，你如果在一个会话里连续处理了2小时、塞进去好多大文件，请求开销会明显变大。到了高峰期，这种"胖请求"往往是最先被拒的那一批。

实操上我做三件事：

• 用对话压缩功能把历史摘要化，别让几千行历史记录继续堆着。压缩后Codex只保留关键结论，丢失的细节反正也在代码里。
• 把不相关的文件移出项目目录，或者明确告诉Codex"只关注某个子目录"，减少它自动扫描文件树的范围。
• 如果要处理一个大文件，尽量用裁剪后的相关片段去问，而不是动不动把整个文件丢进去。对代码来说，真正相关的可能就那几十行，其余都是噪音。

这个思路很快见效。我有一次连续撞了三次capacity，用对话压缩加清理项目里一个无关的大数据文件后，第四次请求稳稳过去了。顺带说一句，精简上下文不只对避让容量有帮助，对输出质量也是正向的——模型聚焦在真正相关的内容上，思路清晰很多。

3. 把容量问题从偶发变成可控：中长期使用习惯

3.1 错峰使用：挑人少的时候干重活

容量问题有非常明显的时段属性。我统计过自己在不同时段各个位置上的报错频率：工作日白天尤其是上午十点到下午四点这个区间，报错次数是晚上八点后的三倍以上。原因不复杂，这个时段覆盖了多个工作时段的重叠区，很多开发者在同时跑任务。

所以我对重型任务的使用策略是：能在晚上跑就放晚上，能在凌晨跑就扛到凌晨。如果你手里有那种需要连续跑很久的自动化编码任务，挑安静时段挂上会舒服很多。白天的时间段留给轻量请求、临时答疑、简单改动，这类请求就算撞容量，代价也很小。

这个习惯带来的额外好处是：夜间网络通常也更稳定，请求响应速度更快。我甚至会把一些需要反复试验的任务安排在晚上统一跑，早上起来收拾结果，效率和体验都好很多。

3.2 任务拆分：小步快跑比一次梭哈更抗造

我见过一种典型的失败姿势：一句话让Codex"把整个订单模块重构掉，加上单元测试，然后更新API文档和迁移脚本"。结果任务跑到一半撞上capacity，整个上下文全废，不光没结果，前面的进展也丢了。这种大而全的指令对于容量波动非常脆弱，因为单次请求负载大，等待时间长，任何抖动都可能导致任务失败。

正确方式是把它拆成一个小步走、一步一确认的流程：

• 第一步："帮我梳理当前模块的结构和问题点"
• 第二步："针对问题点列出三种重构方案"
• 第三步："选定方案A，先改核心业务逻辑部分"
• 第四步："为改完的部分补充测试用例"
• 第五步："更新模块对应的文档"

每一步都是独立的短会话，单位请求的负载小，撞容量的概率比长任务低很多。即便某一小步失败，重新发起也就损失几秒钟，不需要重新养一个庞大的上下文。这个模式我用了很久，成功率提升非常明显，也不再害怕任务中途断掉。

3.3 请求节奏管理：给自动化脚本装上节流阀

如果你自己写了脚本批量调用Codex，不加节流就相当于无保护地冲击共享资源池。容量错误只是最快暴露问题的方式，再往后可能就是限流。我在批量调用时一定会做三件套：

• 请求间隔：两次请求之间至少停顿0.5秒，随机上限到2秒，用随机抖动防止多个任务在同一时刻爆发。这个随机抖动很重要，如果所有任务都在固定的1秒后发起，很容易形成共振，让服务端在那一瞬间压力骤增。
• 任务队列：用一个简单的队列把任务串行或限制为2~3个并发，而不是一口气全发出去。队列的另一个优势是方便记录每个任务的状态，失败时能单独重试而不影响其他任务。
• 失败重试策略：遇到capacity错误时按指数退避等待，不要立刻重发同一个请求。这个重试策略要单独写，跟普通网络错误区别开，网络错误可以相对快一点重试，容量错误必须拉长间隔。

这套节流阀让我的自动化任务中断率下降了很多。以前一批任务跑下来能完成五六成就算运气好，现在基本能稳定在九成以上，剩下的偶发失败也会被重试机制自动消化掉。

4. 进阶排查：用环境优化和日志分析把问题量化

4.1 网络质量：别让网络背锅，也别让它添乱

capacity错误本身是服务端状态，不是网络问题。但网络质量差会让整个交互链条变脆弱：比如请求在传输中被截断、重连时被调度到其他节点、超时后你误以为服务端还没回复而重复发请求，这些都会放大容量问题带来的影响。

我自己的检查方法很简单：选择一个稳定的公共地址做连通性测试，跑一段时间ping，看延迟和丢包率。如果丢包率超过1%，网络稳定性就比较差了；如果平均延迟比平时高一倍以上，也说明这条链路不健康。换一个更稳定的网络环境能减少一些莫名其妙的连带问题。

另外，注意你本地如果跑了很多占用带宽的东西，比如大体积仓库同步、镜像拉取、视频通话，也可能挤占网络资源。这些对自动化任务的实时性影响是实打实的。我在跑长任务前会先把这些占带宽的应用关掉，保证Codex请求的通道尽量干净。

4.2 抓日志：统计你的专属容量规律

Codex支持调试日志模式，打开之后会在日志文件里记录每次请求的HTTP状态码、耗时、重试次数、模型标识。我推荐用这些日志做一件很有价值的事：量化自己撞容量的规律，而不是每次都凭感觉判断。

我写过一段很简单的Python脚本，读取日志文件，用正则把Selected model is at capacity这一类错误出现的行按照小时聚合，画一个粗糙的频率分布。跑一周之后数据会告诉你三件事：

• 一天里哪些时段对你来说最容易撞容量；
• 哪些模型在你这个项目上的失败率最高；
• 上下文体积阈值在哪里，超过多少规模开始容易失败。

有了这些数据，你就是在用数据调度任务，而不是靠运气。我后来排任务调度前都会先扫一眼自己的历史错误分布，直接把关键任务放到低谷时段去跑，效果立竿见影。

import re from collections import Counter from datetime import datetime # 假设日志每行格式类似：2025-01-01 10:23:45 ERROR capacity: Selected model is at capacity log_pattern = re.compile(r"(\d{4}-\d{2}-\d{2} \d{2}):.*(capacity|error|retry)", re.IGNORECASE) def analyze_log(log_path): hourly = Counter() with open(log_path, encoding="utf-8", errors="ignore") as f: for line in f: m = log_pattern.search(line) if m: ts = datetime.strptime(m.group(1), "%Y-%m-%d %H") hourly[ts.strftime("%A %H:00")] += 1 return sorted(hourly.items()) if __name__ == "__main__": for slot, count in analyze_log("codex.log"): print(f"{slot}: {count} 次")

这段脚本很粗糙，但够用。核心思想是把日志变成趋势，让自己对容量问题有预期，而不是每次都被突然袭击。

4.3 自动化重试脚本：把应急动作写进代码

如果你用的是API方式接入Codex，完全可以把"遇到capacity就切换模型+等待退避"的逻辑写成一个可复用的函数。下面是我常用的一个Python示例思路：

import time import random import requests def safe_request(url, payload, model_priority): models = list(model_priority) for attempt in range(6): model = models[attempt % len(models)] body = {**payload, "model": model} try: resp = requests.post(url, json=body, timeout=60) if resp.status_code == 200: return resp.json() if "capacity" in resp.text.lower() and attempt < len(models) - 1: print(f"模型 {model} 容量不足，等待后切换") else: return {"error": resp.text} except Exception as e: print(f"请求异常：{e}") time.sleep(2 ** attempt + random.random()) return {"error": "all retries exhausted"}

这个脚本的核心思路就是：模型列表按优先级排好，碰到capacity就切下一个模型，等待时间按2的指数增长，加上随机抖动。实际用下来非常稳，尤其是夜间无人值守的任务。你可以把model_priority传成["重模型", "中模型", "轻模型"]，这样即使重模型一直满负载，也会自动滑落到轻模型把任务跑完。

注意：重试逻辑里不要对普通网络错误使用同样的切模型策略，网络错误应该固定重试等待；容量错误才切换模型。两者的处理方式混在一起会导致真正的网络问题被掩盖，甚至把容量问题误判成网络问题，排查时南辕北辙。

4.4 账号与配额体检

排查到最后，还得排除账号因素。区分方法很简单，直接看报错文本：

• 提示认证失败、登录过期：账号层面有问题；
• 提示用量配额不足、达到月度上限：套餐用量问题；
• 提示capacity、try a different model：纯粹容量问题。

我建议固定一个周期检查登录态和用量，别在自己毫不知情的情况下把容量问题和账号问题混在一起。特别是自动化脚本长期挂着的时候，可能一次登录态过期就会让之后的所有请求都以另一种报错形式失败，你要是只盯着capacity看，永远找不到原因。做一次体检，把账号状态、用量、模型可用列表都过一遍，后面能省掉很多无谓的排查。

5. 对照速查与实战心得

5.1 常见问题对照表

5.2 实战心得与习惯沉淀

这个报错我真的踩了挺多次，现在已经不太会被它激怒了。最后分享几个沉淀下来的习惯：

第一，我把"防容量问题"纳入了任务规划。接到大的自动化任务，先看时间是不是高峰期，高峰期就主动拆小任务，或者干脆把任务排期到安静时段。这不是什么复杂技术，但确实让我的成功率提高了一大截。

第二，我的重试等待曲线是固定的：30秒、2分钟、10分钟、30分钟，四级退避。超过30分钟还报错，我就默认是全局性故障，直接停手去做别的事。从时间成本来讲，这个策略比以前的手忙脚乱高效得多，至少不会在无效重试上浪费一个小时。

第三，对Codex不要有"一次问到底"的执念。它最好的使用方式是当好一个高频、短对话、快速反馈的助手，而不是一次性解决所有问题的神谕。短对话对容量问题的免疫力天然更高，出了问题重启成本也极低，就算偶尔撞上一次，也就是重新念一遍需求的功夫。

第四，如果手头有多个模型可选，把它做成一个循环列表，失败时自动转下一个，这是成本最低的高可用方案。哪怕只是手动操作，把模型从重到轻排个序，依次试，也比死磕一个模型明智。

5.3 配套自动化流水线的额外建议

如果你在持续集成或者定时任务里使用Codex，还要额外考虑失败的缓释。我的建议是在流水线里给这类型任务设置独立的超时和错误容忍度，别让一个容量错误把整条流水线打红。具体做法是：把Codex相关步骤标记为可重试步骤，单独配置重试次数；失败后发送一条消息，让当值的人知道但不用立刻介入；并且把当时的上下文和日志自动存档，方便事后分析。

我还尝试过把一天的Codex任务集中到一个队列里，按优先级排序，遇到容量就整体切到备用模型。这套东西跑下来，整个团队的效率都不再受制于某个模型的临时状态，大家也不会因为偶发报错频繁打断思路。说到底，容量问题是服务架构的一部分，我们控制不了服务端，但能控制自己的调度策略和任务形态。

这个报错不会彻底消失，但完全可以被驯化。把我的这套方法试一遍，你的中断率应该会明显降下来；它还在，你就已经有完整的应对预案了。