pikasTech-unidesk/docs/MDTODO/details/sub2api-upstream-reliability/R1_Task_Report.md

R1 任务报告

目标

把 Sub2API 上游故障调查从零散日志读取收敛为可复用的受控 CLI 能力，并用实际错误证据形成保守、可逆的账号级 runtime 调度缓解。

工具改进

• runtime list|get 补充 proxyId、并发上限、当前并发、loadFactor 和优先级，能够直接核对代理与调度事实。
• runtime errors 综合 account_upstream_error、openai.forward_failed 和 Sub2API Ops 上游错误记录，输出全池主因排名、账号主因、状态码、消息、模型、小时和流式分布；详细样本通过 --full 渐进披露。
• 错误分析显式区分 Ops 样本与 runtime 日志，不按时间或位置强行关联；缺少全部请求尝试分母时不计算错误率，缺少错误发生时并发历史时不把当前并发快照作为降并发依据。
• runtime apply|delete 仅修改显式指定账号的临时不可调度配置；无 --confirm 时为 dry-run，有 --confirm 时才写入，并回读模板匹配、代理、并发、状态和调度状态。

全池结论

• 最近观测窗口内主要错误是仅状态码上游失败、通用上游失败、过载和上游 API-key 校验失败；明确并发错误只占较小部分，降低全池并发量不应作为首要修复。
• 账号 27 的集中 HTTP 500 证据为 Failed to validate API key，指向上游网关 key 查询或依赖失败；账号 32 才有明确并发限制证据。
• context window、缺少 terminal event 和 encrypted_content 属于请求语义或流式续链问题，不应通过临时摘号模板泛化掩盖。
• Sub2API 仅能在响应尚未提交时通过临时不可调度触发换号；SSE 已向客户端写出后再缺少终止事件，不能透明切换账号。

配置与运行面应用

• owning YAML 的 codex-upstream-failover 模板收敛为 5 条实际观测规则：429、500、502、503、524，每条冷却 1 分钟。
• 500 仅匹配实际证据中的 failed to validate api key 和 do request failed；可用性、过载和并发关键词按实际状态码分别配置。
• 通过 runtime CRUD 将模板显式应用到 9 个 API-key 手工账号；OAuth 账号 lyon9801 保持 enabled=false、零规则。
• 未改变账号凭据、代理、并发上限、优先级、长期 status 或 schedulable；原先已禁用或错误的账号保持原状。

验证

• 全池 runtime 回读确认 9 个 API-key 账号均为 5 条规则并匹配模板，OAuth 例外未变化。
• bun --check scripts/src/platform-infra-sub2api-codex/runtime.ts 通过。
• Bun 内置 YAML 解析确认规则状态码为 429,500,502,503,524，持续时间均为 1 分钟。
• git diff --check 通过。

后续边界

本次只能证明配置正确应用，不能立即证明错误率下降。后续应在独立的新时间窗口复核错误记录、切号证据和最终客户响应，并继续保持错误数量、请求分母和流式提交阶段的语义区分。