AIGoCode 返回 500、502、503、504：重试前先核对什么

先确认收到的是哪一种失败

请求 AIGoCode 时出现 500、502、503 或 504，先保存失败时间、状态码和脱敏后的错误信息，再决定下一步。不要一看到连接失败就同时重建密钥、更换地址和切换模型；改动混在一起，后续很难判断哪个操作影响了结果。

官方《错误码说明》把这四个状态码列在“5xx 上游或服务异常”下，可能原因包括上游模型波动、网络问题和服务临时异常。这是排查方向，单凭一个状态码无法确定故障发生在哪一层。如果工具只有“请求失败”的提示，连 HTTP 状态码都没有显示，应先记录“状态码未显示”，不要自行补成 504。

本文处理已经看到 5xx 后的操作顺序，不提供固定恢复时间，也不把一次重试成功当成长期稳定性或计费保证。

重试前，先把原请求和实际结果对应起来

先暂停自己反复点击重试的操作，检查当前工具已经显示了什么：是否有部分回复、是否完成了文件修改、是否仍有任务在运行。这里是为了保留任务现场；这些界面现象本身不能证明后台生成或计费状态。

建议只记录界面或日志真实提供的字段：

字段看不到，就注明未显示。不要根据一次点击推算一定只发出了一次请求，也不要根据前台报错推断后台一定没有生成。若怀疑工具自己重试，需要用实际请求记录核对，而不是按工具名称猜测其行为。

保存和分享日志时移除 API Key、认证头、携带密钥的查询参数及敏感业务内容。模型名称和错误描述可用于排查，完整认证信息不需要交给支持人员。

稍后做一次有限对照，记录改了什么

官方错误码文档对 5xx 给出的处理建议是“稍后重试，或切换模型”。本文不设统一等待秒数，也不把某个固定间隔当成 AIGoCode 的恢复承诺。

一种便于比较的做法是：先保留原配置，稍后对一项小范围、可重复验证的请求做一次对照，记录状态码和回复是否变化。若任务涉及写文件或执行后续操作，先核对已有结果，再决定是否重做整项任务；不要为了测试连接把已经完成的操作全部再执行一遍。

若选择切换模型，先确认目标模型确实可用于当前接入，记录原模型、目标模型及这次调整，不同时改密钥和服务地址。切换后成功只能说明这次调用成功，不能据此证明原模型存在持续故障，也不能假定替代模型的费用、能力和输出结果完全相同。

官方《额度与限制》说明，不同模型的输入、输出、缓存读写成本不同，工具重复请求也会增加消耗。因此，排查时应限制验证范围，避免一边多客户端并行重试，一边失去对调用次数的记录。

错误变化后，转到对应分支

对照后仍为 5xx，就继续保留同一类故障的时间和结果。若变成其他错误，应根据新响应重新判断：

• 收到 401，核对当前接口实际要求的认证方式和密钥填写。
• 收到带余额、额度或订阅不足提示的 403，核对控制台显示的账户状态。
• 收到 429，检查是否有同时请求过多、工具自动并发或短时间重试过快的情况。

上述分支来自官方错误码说明。认证与额度问题可继续阅读本站的401 与 403 排查指南，避免沿用先前的“服务异常”判断去解释所有后续失败。

扣费与生成结果，回到用量记录核对

官方对 5xx 的扣费说明是“以最终生成和用量记录为准”。因此，“工具报错”不能直接等同于“一定扣费”或“一定不扣费”；需要把同一时间范围内的最终结果与实际请求记录对应起来。

按官方额度说明，可前往主站用量统计查看具体请求记录。将原请求与后续重试分开记录，保留页面显示的用量和单位；同一时段还有其他工具在调用时，也一并备注。更详细的核对方法见一次任务的用量检查，不要只用余额前后变化替代逐项核对。

若 5xx 持续影响使用，官方建议联系支持。提交时写清失败时间范围、工具与模型、状态码、脱敏错误、一次对照调整以及能核对到的最终结果。可以说“原请求和稍后一次重试均返回 502”，但在没有更多证据时，不写成“后台一定重复扣费”或“上游已经确认故障”。一份可对应的记录，比连续重试后只剩下“还是不行”更有助于继续排查。