[ziyue67]

背景

Sub2API 原有插件能力只有 openai.oauth.outbound_transport.v1（出站传输），它在宿主选完账号之后才被调用。实测确认（openai_account_scheduler.go、gateway_scheduling.go、lane_sticky.go 对 pluginManager 零引用）：选号之前不存在任何插件钩子。

本 PR 新增调度能力，让插件在宿主完成全部硬门槛过滤后，对合法候选集表达一次偏好。

配套插件实现见私有仓库

设计边界

1. 插件只提名，不决策。 调用时机在 selectByLoadBalance 内部、全部过滤之后：

listSchedulableAccounts
  → 状态/平台/分组/传输/隐私/模型能力/配额 全部硬门槛过滤
  → GetAccountsLoadBatch          读权威并发负载
  → resolveSchedulingNomination  ▶ 插件在此被询问一次
  → trySelectByLoadBalancePool    候选池拆分与原生排序
  → tryAcquireOpenAISelectionOrderWithBudget  ▶ 抢槽仍是宿主独占

插件拿到的候选已经全部合法，不可能提名被过滤掉的账号。

2. 提名零副作用。 只把提名账号移到 selectionOrder 首位，不改变集合。抢槽（Redis 在途计数）、lane 水合、粘性写入、失败重放全部仍是原生逻辑。提名账号抢不到槽时宿主沿原序列继续尝试，最坏退化为原生排序，请求不会失败。

3. 失败一律降级。 未启用 / 超时(200ms) / RPC 错误 / 进程退出 / 提名越界，全部 fail-open。

另：跨池不搬运。提名账号若属于订阅池而当前在选常规池，置顶自然失败 —— 刻意为之，跨池搬运会破坏 SubscriptionPriority 语义。

实现要点

• 调度路由从 runtimes 映射派生，不维护独立状态。启用/停用/失败切换/多实例对齐等既有生命周期逻辑自动生效，不会出现"插件停了但调度还生效"。
• 一次选号只问一次（而非每个候选池各一次），保证候选集完整稳定。
• Layer 只在提名确实被选中时改写为 plugin_scheduler，否则保持 load_balance。
• 候选只含决策必需字段，不含账号名/凭据/代理/分组。

兼容性

• 未实现该 RPC 的既有插件返回 Unimplemented，宿主静默跳过，转发能力不受影响。
• 能力白名单从单值校验改为 supportedPluginCapabilities 映射；manifest.schema.json 的 capabilities.id 从 const 改为 enum。
• 无需 DB 迁移（plugin_bindings.capability 是自由字符串，唯一索引已按 (capability, platform, account_type) 分桶）。

测试

项目	结果
go build ./...	✅
go vet -tags=unit ./internal/...	✅
gofmt -l	✅ 无输出
新增单元测试（提名语义/跨池边界/归因/灰度/fail-open）	✅ 20/20
真实包端到端（拉起插件进程）	✅ 2/2
完整 internal/service 回归	✅ 208s 无失败

验收测试断言"宿主读出的值 == 清单声明的值"（installation.Version == manifest.version、GetInfo.plugin_id == manifest.id），不写死具体版本号与插件 ID —— 这样对任意版本、任意插件变体都成立，失败信息也能直接指向真正的不变量。

未运行的项

• -tags=integration（需 Docker：真 PG/Redis）
• 前端 vitest / vue-tsc（未改前端）
• golangci-lint

文档

新增 backend/pkg/pluginapi/docs/scheduling.md，说明契约、设计边界、观测字段与部署流程。

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.