# 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` 通过。

## 后续边界

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