feat(proxy): seat_group resolve/select + persona + group runtime

[Jakegogo]

Part of the seat_group (席位组 / OAuth account pool) feature.

Group VK resolution, seatassign selection, AccountPersona normalization (pooled), group_runtime pull. Direct-bind path byte-unchanged.

🤖 Generated with Claude Code

[raysonmeng]

@Jakegogo 「override 谁写谁读」(动态决策引擎冲突 5)。分工:引擎当 assignment_override 的写者(引擎内,我们做);override 的下发端点 + proxy 读取这两块管道归你建。给足 spec:

背景

引擎(master 调度大脑)会按风险/容量决定"某席位下次该走哪个号",写进 seat_group_member.assignment_override(你已建好这列)。但你 proxy 现状:① 路由纯跑 seatassign.Rank 取第一个可用,完全不读 assignment_override;② 连 master 的 GroupAccountRef.assigned(rank-0 advisory)也显式忽略、自己重排。→ 引擎写了 override 没人读、指挥不动流量。assigned 你忽略没问题(它就是哈希第一名),但 assignment_override 是引擎的动态风险决定、不是哈希,proxy 必须读。

要你建的两块(引擎只当写者,不碰你的 seatassign)

1. GET /accounts/me/routing 下发端点(master/control-master)——你现在只有 group-runtime(下发加密物料),没有 override 下发。新建这个端点返回 seat → account_id 映射(= 引擎写的 override)+ routing_version 增量语义。与 group-runtime 分开走(不复用 60s 物料拉取通道;这是 §5.4b 的 routing 快路径、不 bump sync_version)。cli 里那个注释提到的 "routing-override POLL(N12)" 就是它,目前零代码。
2. proxy group_resolve.go 加"override 优先"读取——选号前先看这个席位有没有有效 override:override.account_id ∈ 本地 group_accounts 候选集(成员有效性校验,候选集走结构同步、override 走快路径,两路径异步无版本绑定,必须双侧校验)。有效就用它当起点;否则回退现有 seatassign.Rank(现状行为一行不动)。

安全网(贴合你现状)

没 override 时(引擎没上线/没写)→ proxy 就是回退纯 seatassign = 你现在的行为。所以这是优雅叠加:"没 override = 你现状,有 override = 引擎指挥",引擎挂了系统照跑(不变量 1)。

一句话:引擎写 override 值(引擎内);你建 routing 端点 + proxy 加 override 优先读(带成员有效性校验)。assigned 忽略不用改。

🤖 Generated with Claude Code

[raysonmeng]

@Jakegogo 引擎以外待建 · 信号底座(I5,承接前面 override 那条)。好消息:上报通道不用新建,搭现成用量管道即可。

proxy 现在对 unified-* 只透传 window_max_util_pct + 看 window_status==exhausted 布尔,把利用率数值丢了。引擎风险评分要"撞墙前预警"(利用率斜率 d(util)/dt、消耗速率),光 exhausted 布尔算不出斜率。要两步:

1. 真解析 unified- 数值*:anthropic-ratelimit-unified-5h/7d-utilization(float 0~1)、-{5h,7d,opus-7d}-reset、-overage-*、401 OAuth token has been revoked(不是只取 exhausted 布尔)。forward_and_resolve.go:475 你已经把这些头抓在 rateLimitHeaders 里打日志了,差的就是解析成数值。
2. 不另建上报通道——搭现成:把解析出的数值塞进 proxy 已有的用量事件(events_and_helpers canonical event),顺 aikey-data 用量管道进 ODS。上报频率 = 用量事件频率(每请求、零额外成本);引擎从 ODS 按自己再平衡节拍(1~5min)取、算斜率,你不用定上报节奏。

即:你采+解析+搭车上报,引擎在 ODS 上消费。落点和 persona 归一同仓。

🤖 Generated with Claude Code

[raysonmeng]

@Jakegogo 更正一下上面那条 override 评论的口径 🙏 —— 我后来看了你 760ea08「clarify candidate-set vs single routing account」的澄清,发现这正是你自己 §5.4b 的设计,不是我们要新加的东西。所以上面那条 spec 的本质是「请把你 §5.4b 已经设计好的东西在这个 PR 里落地」:

你 §5.4b / 760ea08 已经定义好的(我们完全照用,不改设计):

• 端点 GET /accounts/me/routing?since=routing_version(返回 seat→当前账号映射,变了才重拉)
• proxy 读法「有 override 就覆盖本地 hash、没有就用本地 hash」
• 字段 my_assignment_override(cache 投影 {protocol:account_id})/ seat_group_member.assignment_override(master 权威)
• 写者 = 你标注的「远端路由轮询(N12)」= 就是引擎
• 候选集是权威集合,override 只是其上的一个选择,候选集收缩使存量 override 失效 —— 这条成员有效性校验我们双侧都做(master 写前校验 account_id ∈ group_accounts、proxy 应用前再校验,不在则丢 override 退回 hash)

现状:你这套 §5.4b 设计已定,但 PR 代码里还是零(端点、proxy override 读都没接,proxy 现在纯 seatassign 顺序取可用、忽略 advisory)。所以引擎按你这套契约当 override 唯一写者,你把 §5.4b 落地即可,无需改任何设计。

(前一条评论说「你留空了、按我们 spec 建」口径不准,以这条为准——是落地你自己的 §5.4b。)

🤖 Generated with Claude Code

[Jakegogo]

@raysonmeng N12 override 分工收到（引擎写 assignment_override、我建下发端点 + proxy 读）。先把接口契约敲死，免得两边并行写、接的时候对不上。下面是我的提案，请确认/调整：

1. 下发端点 GET /accounts/me/routing

• 鉴权：account-JWT（同 group-runtime）。
• 返回（席位→账号，稀疏，只列有 override 的席位；无则空）：

  { "routing_version": 7, "assignments": { "<seat_id>": "<account_id>", ... } }

• routing_version：单调递增整数，任一 assignment 变更即 +1。proxy 记住上次版本，版本未变 → 整个跳过（不重处理）。
• 独立通道：与 group-runtime 物料管道分开，不 bump sync_version（§5.4b 快路径）。
• 空语义：引擎未写/未上线 → 返回 assignments: {} → proxy 全量回退到现有 seatassign（= 现状）。

2. proxy 侧（我建）

• 轮询：独立 60s ticker 拉该端点（复用 RefreshableJWT），override 表只存内存（非密、易变 → 不写 vault、不 reload）；版本未变不动。
• override 优先读（group_resolve.go，选号前）：
  • 该 seat 有 override 且 override.account_id ∈ 本地候选集 且该账号当前可用 → 用它当选号；
  • 否则 → 现有 seatassign.Rank（现状一行不动）。

3. 两个待你确认的点

• (a) override = 偏好，不是硬命令：若引擎指定的账号正好被 proxy 冷却（刚 401/exhaustion-429）或过期/耗尽 → proxy 仍绕开它、回退选号（账号已挂是硬事实，不该把请求往死号上送）。同意吗？
• (b) 端点谁建：GET /accounts/me/routing 在 master、紧挨你写 assignment_override 的地方——建议你顺手建（读 seat_group_member.assignment_override → 返上面格式）；我这边建轮询 + override 优先读。可否？

4. 安全网 / 边界

• 无 override / 引擎挂 → proxy = 现状（优雅叠加，不变量 1）；全程在 AIKEY_PROXY_SEAT_GROUP_ENABLED 开关后。
• 校验"override 账号 ∈ 本地候选集"——候选集走结构同步、override 走快路径，两路异步必须双侧校验。
• N12 整体仍属 post-MVP；既然你在写引擎，我把 proxy 这半边按上面契约建好对接。

契约确认后我就开写 proxy 轮询 + override 优先读。

🤖 Generated with Claude Code

[raysonmeng]

@Jakegogo routing 契约逐条确认，可以开写：

1. 下发端点 GET /accounts/me/routing —— 我们建（master 侧）

端点紧挨引擎写 assignment_override 处，由引擎侧建：读 seat_group_member.assignment_override → 返你定义的格式 { "routing_version": N, "assignments": { "<seat_id>": "<account_id>" } }。

• routing_version 由引擎写 override 时单调 +1（每次 BuildOverrideMap 递增）；
• 稀疏，只列有 override 的席位，无则 assignments: {}；
• account-JWT 鉴权、独立通道、不 bump sync_version（§5.4b 快路径）。

全照你的提案，零改动。

2. proxy 侧（你建）—— 全采纳

60s 独立 ticker、override 表只存内存（非密不写 vault）、版本未变整跳过、override 优先读 + 候选集校验、否则回退 seatassign.Rank（现状一行不动）。

3. 两点确认

• (a) override = 偏好非硬命令：同意。 引擎指定的号若正被 proxy 冷却（刚 401/429）/过期/耗尽 → proxy 仍绕开、回退选号。这正是不变量 1（引擎挂了系统照跑）+「死号是硬事实，不该往上送」。引擎只给偏好，proxy 的熔断硬闸门永远优先。
• (b) 端点谁建：我们建 master 端点，你建 proxy 轮询 + override 优先读。 §5.4b 整套是你的设计，我们只把 master 这半边落地（读 override 列发出去）；proxy 半边你按上面契约接。

4. 安全网 —— 一致

无 override / 引擎挂 → proxy = 现状；全程在 AIKEY_PROXY_SEAT_GROUP_ENABLED 后；候选集双侧校验（master 写前 + proxy 应用前，account_id ∈ group_accounts，不在则丢 override 退 hash）。N12 整体仍 post-MVP。

契约敲定。master 端点跟 allocengine override 写入同 PR 出；你出 proxy 轮询 + override 优先读。