AMR 生产发布影响报告

生成时间：2026-09-26（观察时刻 2026-09-26T03:37:08Z）；分析对象：从 origin/main（HEAD 37639613f，feat(tools): 新增 Erosion / Verbosity 分项目分析与独立报告 (#129)，2026-09-26 02:59 UTC，Liu Yi）发布 Web、API、Link、Admin、DB migration 与 Model Routing Catalog 的影响分析。四个服务以 EKS Pod 实际运行镜像为生产发布点，DB migration 与 Catalog 以对应 Forgejo workflow 最近一次成功运行的 commit_sha 为生产发布点；六个维度分别计算变更范围。

本次核对结论

Web / API 的 EKS Pod 已运行 4d9eee278，本轮待发布范围内这两个维度没有任何文件变更，DB migration 也无需执行；真正需要发布的是三步：Admin 补上 #127（公共模型状态 API）、Link 补上 #122 / #126（BytePlus 接入与权重下调）、随后 apply Model Routing Catalog（同一批 seed / data 变更，Catalog 仍为 0ab43a985）。其中 Link → Catalog 的先后顺序不可颠倒，Admin 与 Link 之间无依赖。

观察方式：Grafana Prometheus（datasource UID prometheus）× kube-state-metrics，namespace nexu；只接受命中目标业务容器与镜像仓库正则（prod-[0-9a-f]{40}）、且 kube_pod_status_ready{condition="true"} 的 Pod，因此 CronJob、Link Redis 与 metrics exporter 不会混入。Workflow 记录来自 Forgejo core/amr 最近成功运行，仅作审计对照；六个维度的发布点不统一，比较范围按维度分别计算。

当前生产发布点（EKS 实态 + workflow 记录）

越新的发布点意味着该维度已上线越多内容；feature 表里只列出发布点之后的变更，发布点之前的 commit 归入「已在生产生效」一节。目标 commit 均为 37639613f（feat(tools): 新增 Erosion / Verbosity 分项目分析与独立报告 (#129)）。

Web · EKS Pod 实态
Workload：nexu/amr-web · container web
观察时间：2026-09-26T03:37:08Z（样本时间戳相对本地时钟 -1~-1s，时钟偏差远小于 5 分钟新鲜度上限）
Ready Pods：2 / 期望 2（spec / status / updated / available 均为 2，无滚动发布或回滚混合态）· amr-web-587cc86d95-b9zhw、amr-web-587cc86d95-2k6tz
实际 commit：4d9eee278 · 镜像 …/amr-web:prod-4d9eee278e70…
镜像 digest：sha256:f182b80920802b11c1c18433ae66ee048642b9d9b14b25bbd075698e8134b422
Workflow 审计对照：deploy-web-eks-prod.yml 最近成功 run #2874 · 2026-09-24T10:57:57Z → 4d9eee278；与 Pod 实态一致（workflow commit_sha = Pod 镜像 tag）
本次待发布（4d9eee278...37639613f）：0 个 commit 触及 apps/web（范围内共 3 个 commit，均不影响该服务）
API · EKS Pod 实态
Workload：nexu/amr-api · container api
观察时间：2026-09-26T03:37:08Z（样本时间戳相对本地时钟 -9~-9s，时钟偏差远小于 5 分钟新鲜度上限）
Ready Pods：2 / 期望 2（spec / status / updated / available 均为 2，无滚动发布或回滚混合态）· amr-api-6f447fd845-gq7s5、amr-api-6f447fd845-4kzqq
实际 commit：4d9eee278 · 镜像 …/amr-api:prod-4d9eee278e70…
镜像 digest：sha256:9315c44cb33f4f8f118a20eeb8e8715e9282135610858a85b5dd91cd1d3bb172
Workflow 审计对照：deploy-api-eks-prod.yml 最近成功 run #2872 · 2026-09-24T10:53:21Z → 4d9eee278；与 Pod 实态一致（workflow commit_sha = Pod 镜像 tag）
本次待发布（4d9eee278...37639613f）：0 个 commit 触及 services/api（范围内共 3 个 commit，均不影响该服务）
Link · EKS Pod 实态
Workload：nexu/amr-link · container link
观察时间：2026-09-26T03:37:08Z（样本时间戳相对本地时钟 -14~-14s，时钟偏差远小于 5 分钟新鲜度上限）
Ready Pods：2 / 期望 2（spec / status / updated / available 均为 2，无滚动发布或回滚混合态）· amr-link-64c4bd4b76-j54qc、amr-link-64c4bd4b76-8hhnc
实际 commit：5a6c7f1ae · 镜像 …/amr-link:prod-5a6c7f1ae915…
镜像 digest：sha256:b18fa89d69bf3eb54ae970e4f9949f90d0742f191e89d967dde7e692a99974d0
Workflow 审计对照：deploy-link-eks-prod.yml 最近成功 run #2807 · 2026-09-24T08:44:14Z → 5a6c7f1ae；与 Pod 实态一致（workflow commit_sha = Pod 镜像 tag）
本次待发布（5a6c7f1ae...37639613f）：2 个 commit 触及 services/link（范围内共 10 个 commit）
Admin · EKS Pod 实态
Workload：nexu/amr-admin · container admin
观察时间：2026-09-26T03:37:08Z（样本时间戳相对本地时钟 -31~-31s，时钟偏差远小于 5 分钟新鲜度上限）
Ready Pods：2 / 期望 2（spec / status / updated / available 均为 2，无滚动发布或回滚混合态）· amr-admin-7b8fdd6c5-5jk49、amr-admin-7b8fdd6c5-44cnr
实际 commit：4d9eee278 · 镜像 …/amr-admin:prod-4d9eee278e70…
镜像 digest：sha256:dc8f4af23e8f449a8b71b69a20e9ac67e9ad7bf03abbc456ba578c01dc8b5fd9
Workflow 审计对照：deploy-admin-eks-prod.yml 最近成功 run #2873 · 2026-09-24T10:53:45Z → 4d9eee278；与 Pod 实态一致（workflow commit_sha = Pod 镜像 tag）
本次待发布（4d9eee278...37639613f）：1 个 commit 触及 apps/admin（范围内共 3 个 commit）
DB migration · workflow 记录
Workflow：deploy-db-migrations-prod.yml
最近成功：run #2800 · 2026-09-24T08:22:04Z
发布点 commit：5a6c7f1ae
本次待发布（5a6c7f1ae...37639613f）：0 个 commit 触及该维度路径（范围内共 10 个 commit）
Model Routing Catalog · workflow 记录
Workflow：deploy-model-routing-catalog-prod.yml
最近成功：run #2812 · 2026-09-24T09:02:59Z
发布点 commit：0ab43a985
本次待发布（0ab43a985...37639613f）：2 个 commit 触及该维度路径（范围内共 9 个 commit）

此次发布真正新增的 feature 和影响面

feature 表只包含「各维度生产发布点之后」的变更：四个服务以 EKS Pod 实态为基线，DB migration 与 Catalog 以 workflow 记录为基线。发布点之前已生效的内容见 「已在生产生效」 一节。

Feature / Author / Commits Web API Link Admin DB schema / migration DB catalog（seed）
LBytePlus 原生 Responses 上游接入与首选档加权分流：deepseek-v4.1-flash / glm-5.3-flash

是什么：BytePlus ModelArk 首次承接文本模型流量。为两个公开模型新增 provider_byteplus 文本路由与 backend，置于各自最高优先级档（priority 10）的加权分流中，上游走原生 Responses（/api/v3/responses，backend metadata upstream_request_kind: responses）： DeepSeek V4.1 Flash → BytePlus 10 / DeepSeek 56 / Aiping 7 / 阿里云 7（BytePlus 约 12.5%；Novita、OpenRouter 仍为 priority 20 / 30 备用档）；GLM-5.3-Flash → BytePlus 10 / Z.AI 30 / Aiping 30（BytePlus 约 14.3%；OpenRouter 备用档）。上游模型 ID deepseek-v4-1-flash-260910、glm-5-3-flash-260828 已用临时凭据直连验证普通与流式 Responses 均 HTTP 200。

行为变化：公开 Chat Completions 与 Responses 两类协议复用同一组 Chat 路由权重（规格中明确写入：不要为这类 backend 另加独占的 Responses 路由），因此 Responses / Codex / Claude Code 客户端的请求同样按权重分流，不会整体压到单一供应商。公开售价不变（data/json/public_pricing.json 本次未被修改），改动的是流量归属与供应商成本。份额是首选供应商可用时的加权目标，供应商故障或请求显式指定供应商时实际比例会变化。

面向谁：所有调用 deepseek-v4.1-flash 与 glm-5.3-flash 的用户；用户无需做任何改动，无 API 契约变化。

Author：mrcfps（mrc@refly.ai）

  • 8f7628f75 feat(link): 接入 BytePlus DeepSeek/GLM 并配置首选流量分配 (#122) — 首次引入 BytePlus 文本路由与上述权重（当时为 30 / 40）
  • 4247cbca3 fix(link): 降低 BytePlus DeepSeek 和 GLM 路由权重 (#126) — 把首选档 BytePlus 权重 30 / 40 统一降到 10，只改权重，优先级与其他供应商不动；同时把依赖运营 catalog 的 Go 分流测试换成与 catalog 解耦的确定性夹具（1:3 主路由 + 高权重备用路由，验证 25% / 75% 及主路由可用时不选备用）

部署依赖（顺序不可颠倒）：必须先发布 Link 到 37639613f，再运行 deploy-model-routing-catalog-prod.yml。Link 侧 8f7628f75 才把 request_path_overrides 白名单扩展到 responses / responses_stream；当前生产的旧 Link（5a6c7f1ae）解析 catalog 里新增的这两个键时会在构建 provider_byteplus 账户阶段直接报错（unsupported request_path_overrides request type），导致 BytePlus 的 provider 账户构建失败 —— 连现有的 Seedream / Seedance 生图与视频路由也会一起不可用。另外 #126 明确记录：生产目录里此前还没有这两条 BytePlus 路由，apply 时需审阅 catalog plan 中的新增行。

 无。待发布范围（4d9eee278...37639613f）内 apps/web 无任何文件变更。 无。待发布范围内 services/api 无任何文件变更。 有（BASE_LINK 5a6c7f1ae 之后，2 个 commit）：
  • 8f7628f75：services/link/internal/bifrostengine/account.go —— parseRequestPathOverrides 放行 schemas.ResponsesRequest / schemas.ResponsesStreamRequest（唯一的运行时行为改动）；services/link/README.md、specs/current/link/provider/README.md、specs/current/link/provider/providers/byteplus.md 文档同步（新增「只维护 chat_completions 路由 + upstream_request_kind: responses，不要加独占 Responses 路由」的规则）。
  • 测试：新增 bifrostengine/byteplus_responses_test.go（+72 行，断言普通/流式都打到 /api/v3/responses 且只命中一次上游）、catalog/byteplus_traffic_test.go（+93 行）；4247cbca3 删除后者并新增 catalog/weighted_traffic_test.go（+63 行），bifrostengine/account_test.go 覆盖新键。
 无。待发布范围内 apps/admin 无任何文件变更。 无。BASE_DB 5a6c7f1ae 之后 db/migrations 与 db/schema 无任何变更，本次不需要跑 migration。 有（BASE_CATALOG 0ab43a985 之后，2 个 commit）：
  • db/seeds/seed-model-routing-catalog.sql + data/json/provider_routes.json：新增 2 个 backend model（backend_model_byteplus_deepseek_v4_1_flash_260910、backend_model_byteplus_glm_5_3_flash_260828，均带 upstream_request_kind: responses）与 2 条 active 路由 route_deepseek_v4_1_flash_byteplus_deepseek_v4_1_flash_260910、route_glm_5_3_flash_byteplus_glm_5_3_flash_260828（priority 10）。
  • data/json/providers.json + seed：provider_byteplus.custom_provider_config.request_path_overrides 增加 responses / responses_stream → /api/v3/responses（保留 image_generation）。
  • data/json/route_policies.json + seed 权重：DeepSeek V4.1 Flash 由 DeepSeek 80 / Aiping 10 / 阿里云 10 变为 BytePlus 10 / DeepSeek 56 / Aiping 7 / 阿里云 7；GLM-5.3-Flash 由 Z.AI 4 / Aiping 4 变为 BytePlus 10 / Z.AI 30 / Aiping 30。
  • 生成器与测试：db/seeds/generate_model_routing_catalog.py（TEXT_PROVIDERS 增加 byteplus）、generate_model_routing_catalog_real_data_test.py（新份额断言 + 「BytePlus 路由必须位于同模型同协议的最高优先级档」）、generate_model_routing_catalog_output_test.py 快照。
该批变更由 deploy-model-routing-catalog-prod.yml 的 plan + apply 覆盖（先校验再 apply，失败即中止），无需人工 SQL；apply 前必须已完成 Link 发布。
SGLM / BytePlus 供应商成本（COGS）口径重建

是什么：把两个模型的供应商成本从「官网挂牌价 / 汇率折算」改为用户确认的合同口径：BytePlus DeepSeek V4.1 Flash 按官网标准在线推理价四折（input $0.06 / output $0.24 / cache_read $0.0012 per 1M，峰谷时段 09:00–12:00、14:00–18:00 UTC+8 为 $0.12 / $0.48 / $0.0024）；GLM-5.3-Flash 的 BytePlus、Z.AI、Aiping、OpenRouter 四个供应商统一按公开标价的九折（$0.0675 / $0.225 / $0.0135，公开标价 $0.075 / $0.25 / $0.015）。

影响：只影响成本与毛利口径 —— 公开售价不变（public_pricing.json 未改），用户账单与模型选择行为不受影响。BytePlus 的折扣缓存存储（$0.00332/M tokens/hour）属按时长计费的独立服务，未计入 token 成本。Z.AI / Aiping / OpenRouter 的 GLM 报价此前分别来自各官网挂牌价或汇率中点，本次被统一覆盖为九折口径，因此这三个供应商的 GLM 成本数字会出现明显跳变（Z.AI 降 55%，OpenRouter 降 10%，Aiping 降 41%），做毛利对账时需按新口径解释。

Author：mrcfps（mrc@refly.ai）

  • 8f7628f75 feat(link): 接入 BytePlus DeepSeek/GLM 并配置首选流量分配 (#122)（同一 PR 内的成本口径变更）
 无。 无。 无。本次 Link 代码改动不涉及计价逻辑。 无。 无。 有（BASE_CATALOG 0ab43a985 之后）：
  • data/json/provider_pricing/provider_byteplus.json：row_count 2 → 4，新增 DeepSeek V4.1 Flash / GLM-5.3-Flash 两条报价与 metadata.pricing_basis（user_confirmed_40_percent_of_official_usd_peak_offpeak / user_confirmed_cogs_90_percent_of_public_list_price）、observed_at: 2026-09-24。
  • provider_aiping.json / provider_zai.json / provider_openrouter.json：GLM-5.3-Flash 报价改写为九折口径，source 由各家官网 URL 改为 user_instruction_2026-09-24，并附 reference: data/json/public_pricing.json#glm-5.3-flash。
  • db/seeds/seed-model-routing-catalog.sql：上述报价同步写入 backend_models.pricing（BytePlus DeepSeek 含峰谷 windows）。
纯数据口径变更，同样随 catalog apply 生效；不含 migration。
SAdmin 公共模型状态 API：GET /api/public/v1/models（只读、免会话）

是什么：Admin 新增无需 Admin session 的只读端点 GET /api/public/v1/models，供脚本/内部系统直接查询模型目录当前状态。端点刻意放在 /api/admin/* 之外，既有的鉴权路由与管理台行为不变。返回稳定的 schemaVersion JSON：模型身份与类型、status、visibility、releasePhase、可用路由数与派生的 routingAvailable / publiclyVisible、blockers（model_inactive / pre_release / archived / no_usable_route / internal_visibility）、deployedAt（public_models.created_at）与 releasedAt（仅当前 phase 为 released 时取 release gate 的 updated_at，pre_release / archived 返回 null）。

接口契约：可选精确匹配筛选 name / status / visibility / releasePhase（如 ?name=gpt-6-sol&status=active&visibility=public&releasePhase=released）；未知、空值、重复或非法筛选返回 400，非 GET 返回 405；响应带 Cache-Control: private, no-store；不暴露供应商配置、凭据、定价、backend 名与 route id。

顺带修正既有写入路径的时钟语义：updateReleasePhase（以及 release gate 更新）在 phase 未变化时改为主动 no-op —— 不刷新 updated_at、不再写第二条审计事件；只有真实切换 phase 才更新 updated_at 并记审计。因此 releasedAt 恒等于最近一次真实进入 released 的时间，重复提交同一 phase 不会再污染时间与审计记录（Admin 返回值新增 changed 字段以区分）。

可达性与安全边界：Admin 部署为内网可达（README 明确该路由不新增浏览器 CORS 访问）；该端点在应用层不带鉴权，若 Admin 曾被内网穿透或代理到更广范围，需要留意它会被匿名读取。数据面只读。

面向谁：发布/运维脚本与内部系统（例如发布后核对模型上线状态）；终端用户与公开 API 契约不受影响。

Author：Liu Yi（liuyi@refly.ai）

  • 0dc3fc2fb feat(admin): expose public model status API (#127) — 新增 public 路由 + 212 行仓储/处理逻辑，并调整 release phase 写入语义

依赖：查询 link.public_models / public_model_release_gates / public_model_routes / backend_models / providers / backend_model_availability_overrides，这些表已存在，不需要 migration；但返回的 releasePhase、usableRouteCount 取决于 catalog 当前状态，建议在 catalog apply 之后再核对端点输出（可看到 BytePlus 两条新路由进入可用路由计数）。

 无。待发布范围（4d9eee278...37639613f）内 apps/web 无任何文件变更。 无。待发布范围内 services/api 无任何文件变更。 无。本次 Admin 改动不涉及 Link。 有（BASE_ADMIN 4d9eee278 之后，1 个 commit）：
  • 0dc3fc2fb：新增 apps/admin/app/api/public/v1/models/route.ts（14 行，runtime = "nodejs"）与 apps/admin/lib/server/public-model-status.ts（212 行：筛选校验 + 单条 SQL 聚合 + JSON 投影）。
  • apps/admin/lib/server/admin/core.ts / models.ts：updatePublicModelReleasePhase / release gate 更新在 phase 未变时提前返回并返回 changed: false；apps/admin/README.md 增补端点文档。
  • 测试：新增 apps/admin/test/public-model-status.test.ts（+168 行）、admin-console.test.ts 增补（+75 行）；PR 记录 vitest 303 项通过、pnpm lint、pnpm --filter @vela/admin build 通过，并本地起 Admin（:3100）实测 200 / 400 / 405 / 401 行为。
 无。待发布范围内 db/migrations 与 db/schema 无任何变更。 无。本次 Admin 改动不改动 db/seeds / data/json。

范围内还有 37639613f feat(tools): 新增 Erosion / Verbosity 分项目分析与独立报告（#129）：只在仓库内新增 tools/code_quality/ 的 Python 静态分析工具与 tools/tests/，不被任何服务镜像或部署维度使用（Web / API / Link / Admin 路径下无文件变更，也不含 migration / seed），对生产运行时没有影响，因此不单列 feature。

已在生产生效（发布点之前，本次不重复发布）

下面这些变更全部落在对应维度当前发布点之前，已在生产运行：Web / API / Admin 已到 4d9eee278，Link 到 5a6c7f1ae，DB migration 到 5a6c7f1ae，Catalog 到 0ab43a985。这些内容不要出现在上面的 feature 表里，本轮也不要为它们重复发布。

发布建议

  1. Migration 判断：BASE_DB 5a6c7f1ae 之后没有新增 migration 文件，不需要运行 deploy-db-migrations-prod.yml。
  2. 服务发布（两个服务，顺序自由，但都应在 Catalog 之前）：(1) Admin —— 4d9eee278...37639613f，1 个 commit（#127，独立无依赖，不影响其它维度）；(2) Link —— 5a6c7f1ae...37639613f，2 个 commit（#122、#126），新代码可兼容旧 catalog；(3) 再运行 deploy-model-routing-catalog-prod.yml 的 plan + apply —— 2 个 commit 的 seed / data 变更。Web / API 本轮不要滚动发布，避免无变更的重复重启。顺序颠倒的风险：catalog 中新增的 responses / responses_stream 路径覆盖键会被当前旧 Link 拒绝（unsupported request_path_overrides request type），provider_byteplus 账户构建失败，BytePlus 已有的生图 / 视频路由会一并不可用。
  3. Catalog apply 前检查：#126 的提交说明指出，生产目录里此前没有这两条 BytePlus 文本路由，plan 中应能看到 2 个 backend model + 2 条 route 的新增以及 DeepSeek / GLM 权重行的修改；确认新增行符合预期后再 apply，apply 后核对 provider_byteplus 的两条文本路由为 active、priority 10、weight 10。
  4. 运行环境前提：Link 已用 BYTEPLUS_API_KEY 承接 Seedream / Seedance 图像与视频路由，本次文本 Responses 路由复用同一凭据，无需新增配置；但新路由依赖该 key 在 Link 运行环境可用。
  5. 发布后观测：① deepseek-v4.1-flash / glm-5.3-flash 的按供应商实际流量分布（首选档目标 BytePlus 12.5% / 14.3%，DeepSeek 70%、Z.AI 与 Aiping 各 42.9% 的相对关系），并确认 Responses 与 Chat 两类协议份额一致；② BytePlus 新上游的 5xx / 超时 / 上游模型错误率与首 token 时延（首次承接生产文本流量）；③ 这两个公开模型的实际计费金额与 COGS 差额（公开售价不变，BytePlus DeepSeek 四折、GLM 全供应商九折）；④ Admin 新增端点：GET /api/public/v1/models 无 Cookie 返回 200、非法 releasePhase 返回 400、POST 返回 405，确认 /api/admin/* 仍为 401；catalog apply 后同一端点中 BytePlus 两条新路由应计入 usableRouteCount。

所有 workflow、commit、PR 与 compare range 均指向 Forgejo code.powerformer.net/core/amr；四个服务的 compare range 基于 EKS Pod 观察到的 BASE（4d9eee278 / 5a6c7f1ae），DB migration 与 Catalog 的 compare range 基于各自 workflow 最近成功运行的发布点（5a6c7f1ae / 0ab43a985），未统一使用最旧基线。本次观察时刻四个服务的 workflow 最近成功记录与 Pod 实态完全一致，没有发现 Pod 与 GitOps 差异。