# R2.2.11 任务报告

## 范围与口径

- 只读复取 PK01 Sub2API 最近2小时所有分组，并以最近30分钟作为趋势对照。
- 请求分母、客户错误和上游错误以 Sub2API 原生 admin/ops 为主；system-log 缺失时才使用 target runtime 日志。
- 分组与账号数据在滚动窗口内持续变化，报告使用本轮最后一次完整分组快照；共享账号的 upstream cause 不跨组相加。
- 未发送探针，未修改 runtime、YAML、proxy、账号或调度配置。

## 所有分组概要

最近2小时初始总览：1391请求、37个客户错误，客户错误率2.66%；74个上游错误，上游错误率5.32%。滚动窗口下钻时请求数增长到约1403，但客户错误总数仍为37。

- `unidesk-codex-pool`：约763请求、26客户错误，错误率3.41%；上游错误率约7.86%。
- `自用`：约640请求、11客户错误，错误率1.72%；上游错误率约2.19%。
- `grok`：0请求、0错误。
- 两个活跃组均无排队，查询时并发约9至10/218；没有证据把主因归为容量不足或需要降低并发。
- 账号29 `https://api.lwylink.xyz pro 0.1` 与账号30 `https://api.lwylink.xyz plus 0.05` 因余额不足403不可用；其余7个OpenAI账号当前可用。

最近30分钟对照：412请求、19客户错误，错误率4.61%；27个上游错误，上游错误率6.55%。其中：

- `unidesk-codex-pool`：251请求、17客户错误，错误率6.77%。
- `自用`：160请求、2客户错误，错误率1.25%。
- 错误没有整体消退，而是更集中到 `unidesk-codex-pool`。

## 主因一：账号27的Responses兼容性400

账号27 `https://sub.yjxm1221.top plus 0.025` 是当前客户错误主因：

- 2小时：139次尝试、91成功、48失败，失败率34.53%，评分38/E；26个分组客户错误中占24个。
- 最近30分钟：48次尝试、30成功、18失败，失败率37.50%；17个客户错误全部来自账号27且全部是400。
- 2小时客户错误状态分布中400有21个，另有404、503、524；模型以 `gpt-5.6-terra`、`gpt-5.6-luna`、`gpt-5.6-sol` 为主。
- 代表请求 `1f3fe800-a72a-4383-88ba-e7311abb8534` 在630 ms内失败，原文为 `Input must be a list`。
- 代表请求 `ee991d2f-08fe-4251-a509-c3d1a4bd8e45` 先经历账号33的524和账号28的503，切到账号27后返回 `Invalid 'input[213].id'`，最终502。
- 另有 `invalid_id_prefix` 类流式 `response.failed`。这些更符合该上游对Responses长历史/input item格式的兼容缺陷，不是并发、网络或普通5xx不稳定。
- 通用400不能直接加入临时不可调度或failover，否则会把真实客户参数错误错误切号；若后续治理，应只针对已证实的精确兼容错误短语和未提交响应阶段处理。

## 主因二：长等待后504，切号已无时间窗

`自用`组11个客户错误全部是 `gpt-5.6-sol`：8个504、2个503、1个524，10个为流式。

- `lyon9801` 2小时109次尝试、100成功、9失败，失败率8.26%，评分75.2/C；8个客户错误，8次failover全部失败。
- 请求 `02f0cc91-6f7f-4106-b902-49ee5260ed57` 等待约29分31秒后才收到账号15的504；1 ms后选号因 `context canceled` 失败。
- 最近30分钟 `lyon9801` 已恢复为34/34成功、TTFT P95约7.8秒；窗口内2个客户错误均来自账号27，不是账号15。
- 当前 OpenAI response-header timeout 为disabled。长等待是客户影响放大器，但现有数据只有端到端耗时，不能断言全部时间都在等待响应头，也不能直接把观测下限当配置值。

## 上游隔离与切号效果

- 账号28 `https://ai.whistlelads.com plus 0.03`：2小时24次尝试全部触发失败，但有26次临时不可调度事件，分组客户错误为0；大量错误被换号吸收。最近30分钟7次失败中5次切号恢复、2次失败。
- 账号31 `https://sub2.pokexiao.com plus 0.03`：2小时215次尝试仅1次失败，评分93.1/A；最近30分钟126次中124成功，2次failover均恢复。
- 账号33 `https://api.iceiu.com plus 0.03`：2小时约3.6%失败，评分B；最近30分钟失败率升到14.55%，并有6次HTTP 200后forward failure，需要关注。
- 成功切号样本 `4d305f0f-3e4f-4e0d-86d1-060a03820d22`：账号32返回524、账号28返回503，约14秒后由账号27完成并最终HTTP 200，证明5xx failover链路能工作。

## HTTP 200后的客户体验错误

- `unidesk-codex-pool` 2小时有12个、最近30分钟有6个 `forwardFailureWithHttpSuccess`。
- `自用` 2小时有3个、最近30分钟有1个同类事件。
- 请求 `e41f8745-e223-4fbf-9fb8-041a40c8ad94` 最终HTTP 200，但约417秒后出现 `stream data interval timeout`，trace正确标记为degraded。
- 这类请求不会进入普通HTTP客户错误分子，因此37个客户错误不是全部体验损失；分组间存在共享账号证据，不能简单把所有forward failure相加成全局唯一请求数。

## 调优建议

1. 优先治理账号27的精确Responses兼容错误族，而不是降低全池并发：先按错误短语、请求阶段和模型统计；候选方案是对已证实的 `Input must be a list`、`Invalid input[*].id`、`invalid_id_prefix` 在响应未提交前触发failover或暂时避免把对应请求形态路由到该账号。是否需要Sub2API源码变更取决于现有精确classifier能否配置表达，不能用通用400规则替代。
2. 研究上游超时与客户deadline的预算关系：目标是让504或无响应在客户context取消前暴露并留出切号时间。缺少客户deadline和response-header阶段耗时前，不直接给出安全timeout数值。
3. 保留账号28现有短冷却策略；它已显著避免客户错误，不建议仅因上游失败率高而长期禁用。
4. 对账号33继续短窗口观察，重点看HTTP 200后 `response.failed`/stream timeout；这类错误无法在响应已提交后安全换号。
5. 账号29、30的余额不足属于静态不可用，应由账号所有者补充余额或退役；当前无排队，暂不构成容量事故。
6. 不因2小时旧错误降权 `lyon9801`；最近30分钟已恢复。若再次出现长等待504，按request ID同步抓trace和基础设施快照。