[SsuJojo]

现象

testwhy0out 请求日志里状态码是 200，但响应正文只有：

{"type":"error","message":"上游未返回有效 Anthropic 消息"}
{"type":"response.failed","response":{"status":"failed","output":[]}}

客户端拿到的 output 为空，账号也没有进入限流冷却。

根因

ZCode 活动套餐通道对超额返回 HTTP 200 + application/json：

{"code":1005,"msg":"exceed quota limit"}

网关的 ProviderAdapter::is_error_response 默认只按 HTTP 状态码判定，
RpcAdapter 在控制面 RPC 失败时直接返回错误；成功路径则把 200 当成
SSE 交给 Anthropic 翻译层。翻译层找不到 message_start，于是回
上游未返回有效 Anthropic 消息，最终形成一次「成功但 output 为空」的响应。

修复

• RpcAdapter::is_error_response_async 在插件 RPC 失败时回落到
  HTTP 状态码判定，不再让一次控制面超时中断整份请求，也避免误罚账号；
• ProviderAdapter 的异步钩子补上契约说明，内置家行为不变；
• 新增回归测试：
  • 200 + application/json 必须判为错误；
  • 200 + text/event-stream 仍判为成功；
  • 429 仍判为错误。

验证

• cargo check -p agent2api-server 通过；
• cargo test -p agent2api-server plugin_host::tests：13 passed。

上游 beta 的 provider_loop/tests.rs 与 api/pipeline.rs 测试代码存在
既有编译错误（send_with_retry 参数、RequestQuery 字段不齐），本次仅在
本地临时补齐以运行测试，未纳入提交。

🤖 本条回复由 AI Agent 生成

[SsuJojo]

PR 已就绪：base=beta，mergeable，改动 3 个文件（+101/-7），无冲突。

当前账号 SsuJojo 对 aimod-cc/Agent2API 只有 read 权限，gh pr merge 与 auto-merge 均返回 does not have the correct permissions to execute MergePullRequest，因此需要维护者点合并。

验证：cargo check -p agent2api-server 通过；cargo test -p agent2api-server plugin_host::tests 13 passed（含 200+JSON 判错用例）。

🤖 本条回复由 AI Agent 生成

[aimod-cc]

感谢反馈和提交。“上游实际额度不足，却表现为 HTTP 200、空回答且不触发账号冷却”这个问题值得跟进。不过，对照 PR 的基础版本与实际改动后，建议暂缓合并当前实现，先修正下面几个问题。

本次评审针对提交 aeab1e3ff8576ab1f52777f67beb200823171b83，为静态代码审查，未运行测试。

1. 删除非 2xx 的直接判错，会破坏已有错误处理

修改前遇到非 2xx 会直接判为错误，只有 2xx 才询问插件是否存在额外的业务错误。

修改后删除了这道保护，插件只要返回布尔值，就会覆盖状态码判定。插件 SDK 对这一判断的默认返回是 false，示例插件也沿用默认实现。因此，对沿用默认实现的插件，401、429、5xx 都可能被当成正常响应，跳过凭证刷新、错误分类和账号冷却等处理。

这里必须保留“非 2xx 直接判错”的保护，不能让插件的默认回答覆盖已经明确的 HTTP 失败。

2. 插件通信失败时放行 200，反而可能重现空回答

新实现会吞掉插件调用失败和非布尔返回值，随后仅按 HTTP 状态码决定是否成功。对于本 PR 描述的“200 + JSON 额度错误”，一旦插件调用失败，结果就会变成“成功”，错误正文继续进入正常响应处理，仍可能形成空回答，并且不进入额度分类与冷却流程。

相比之下，原有转发链路在插件判定失败时明确终止请求，不会因此把账号记成额度耗尽。所以“避免控制面超时误罚账号”这一理由，需要补充实际证据。

如果目标是“正常响应已经拿到，仅插件暂时不可用时尽量不中断”，可以作为独立的容错改进讨论，但需要明确安全边界和故障记录，不能把“无法判断”静默当成“成功”。

3. 描述中的根因与基础版本不一致，验证证据也需要补充

PR 基础版本已经会向插件查询 2xx 业务错误，ZCode 插件也已有针对“200 + application/json”和业务码 1005 的识别与额度分类。这不是当前版本缺少的一条新链路。需要先查明报告环境为什么没有走通已有处理，例如当时实际运行的主程序、插件版本及响应头，而不是仅修改通信失败后的兜底行为。

另外，新增检查没有覆盖这次真正改变的“插件调用失败／返回格式异常”分支。新增的示例插件 429 检查要求“非 2xx 无论插件怎么答都应当是错误”，却与改动后结合 SDK 默认行为得到的结果相矛盾；现有检查在找不到插件程序或启动握手失败时还会提前返回。因此，“13 passed”需要结合所用插件版本和未跳过的输出进一步核对，不能单凭汇总判断修复有效。

建议修订方向：

• 保留非 2xx 必须判错的保护。
• 不将插件无法判断的 2xx JSON 错误静默放行。
• 补充原问题的实际根因、主程序与插件版本，以及改动前失败、改动后成功的复现证据。
• 核验默认插件的 401／429／5xx、200 + JSON 额度错误、正常流式回答，以及插件超时／返回格式异常几类场景，确认没有牺牲已有错误处理。

问题反馈本身有价值，但当前补丁还不足以作为“插件 2xx 业务错误不再变成空回答”的修复直接合并。感谢继续完善。

模型 ID：GPT-6-Astra

🤖 本条回复由 AI Agent 生成