这篇写三个特别常见的客户端错误：
text
400 Bad Request
404 Not Found
413 Request Entity Too Large
它们的共同点是：
text
很多时候不是模型坏了。
也不是 4SAPI 挂了。
而是请求本身不对。
所以遇到这三类错误，第一反应不应该是换 Key。
第一反应应该是：
text
我的 URL、endpoint、参数、模型名、Prompt 长度有没有问题？
1. 400：服务器看不懂你的请求
400 Bad Request 的意思是：
在大模型 API 接入里，常见原因有：
text
JSON 格式不合法。
字段名写错。
参数类型不对。
模型不支持某个参数。
messages 格式不对。
tools / response_format 写法不兼容。
比如有些模型或接口不支持某些参数。
你把 OpenAI 风格的 system、tools、response_format 原样传给所有模型，可能就会触发 400。
这不是权限问题。
这是参数兼容问题。
2. 400 的最小化排查法
遇到 400，先不要把整段业务请求发给管理员。
先做最小请求：
text
一个模型。
一句短 Prompt。
不带 tools。
不带复杂 response_format。
不带历史上下文。
如果最小请求正常，再逐步加回去：
text
加 system。
加历史 messages。
加 tools。
加 response_format。
加业务长 Prompt。
哪一步开始报 400，问题大概率就在那一步。
这比盲目改 Key、换模型、换 Base URL 高效得多。
3. 400 常见修复清单
可以按这个清单看：
| 检查项 | 说明 |
|---|
| JSON 是否合法 | 少逗号、多逗号、引号错误都会炸 |
| messages 是否为空 | 有些接口不接受空 messages |
| role 是否支持 | 不同模型对 system/user/assistant 支持不同 |
| max_tokens 是否过大 | 超过模型限制可能失败 |
| temperature 类型 | 不要把数字传成字符串 |
| tools 是否兼容 | 有些模型不支持工具调用 |
| response_format 是否兼容 | 结构化输出不是所有模型都支持 |
如果你接的是企业级 API 网关，建议把模型能力做成配置：
text
supports_system
supports_tools
supports_json_schema
max_context_tokens
max_output_tokens
这样业务系统不会把所有模型当成一个接口用。
4SAPI 也可以通过模型路由和日志，帮你发现哪个模型最常因为参数兼容报 400。
4. 404：你访问的资源不存在
404 Not Found 在 API 接入里通常不是“网页不存在”。
它更常见的意思是：
text
Base URL 错了。
endpoint 错了。
路径少了 /v1。
多了或少了最后一个斜杠。
模型路径和接口路径不匹配。
比如你本来应该配置：
结果写成：
或者 SDK 自动拼接路径时，你又手动多写了一段 /v1。
最后实际请求就变成了不存在的路径。
5. 404 的排查顺序
遇到 404，先看四件事：
text
Base URL 是否正确。
是否需要 /v1。
endpoint 是否是 chat/completions 或 responses。
SDK 有没有自动拼接路径。
很多客户端配置里，Base URL 只填域名即可。
有些客户端则要求包含 /v1。
还有些工具对最后一个斜杠很敏感。
所以最稳的做法是：
text
参考当前客户端的配置说明。
用同一个 Key 在另一个已知可用客户端里测试。
看 4SAPI 日志里实际请求的 path。
如果日志里能看到 path，就很好排。
比如：
这种一眼就知道是重复拼接。
6. 413：请求体太大
413 Request Entity Too Large 表示：
在大模型场景里，最常见原因是：
text
Prompt 太长。
历史对话太多。
把整份文档塞进上下文。
工具返回结果太大。
RAG 召回 chunk 太多。
图片或文件内容编码后过大。
这类问题不能靠重试解决。
你重试 10 次，请求体还是那么大。
7. 413 的修复方式
先做一个简单验证：
text
把 Prompt 缩短到一句话。
只保留当前问题。
不带历史消息。
如果短 Prompt 正常，说明 Key、Base URL、模型路由大概率没问题。
问题就在输入体量。
修复策略：
text
删除无关历史对话。
先摘要，再让高级模型处理。
RAG 只传最相关的 chunk。
工具返回分页。
长文档拆段处理。
图片或文件走专门接口。
企业内部接入时，建议设置输入上限：
text
单请求最大字符数。
单请求最大 token。
工具返回最大长度。
RAG 召回最大 chunk 数。
不要让一个用户的一次请求把整个服务拖慢。
8. 4SAPI 日志应该记录什么
这三类错误都适合记录请求摘要。
字段建议：
text
request_id
project_id
key_group
model
status_code
endpoint
path
input_chars
input_tokens_estimated
has_tools
has_response_format
error_message
注意：
Prompt 里可能有客户数据、代码、合同、隐私内容。
更稳的是记录：
需要深度排查时，再由有权限的人查看原始请求。
9. 给 AI 的排错 Prompt
text
你是 4SAPI 请求格式排查助手。
请根据状态码、Base URL、endpoint、模型名、请求参数、Prompt 长度和脱敏错误信息，判断错误属于：
1. JSON 格式错误
2. 模型参数不兼容
3. Base URL 或 path 错误
4. endpoint 不存在
5. Prompt 或请求体过大
要求：
- 先给最小请求验证方法。
- 不建议更换 Key 作为第一方案。
- 涉及 Prompt 原文时提醒脱敏。
- 输出下一步应该删减或修改的具体字段。
这个 Prompt 可以给低成本模型先跑。
如果涉及多客户端、多模型、多 SDK 的兼容性，再交给 Fable 5 做系统排查。
10. 总结
400、404、413 这三类错误，优先怀疑请求本身。
排查顺序是：
text
先最小请求。
再看 Base URL。
再看 endpoint。
再看参数兼容。
最后看 Prompt 体量。
4SAPI 的价值是把状态码、模型、路径、输入长度和错误摘要记录下来。
一句话：
text
400/404/413，不要先怪模型，先让请求变小、变准、变干净。
