整体删除已退役的 gpt-image-2-c

- 删除 platform-image 的 GPT_IMAGE_2_C_MODEL 常量、re-export、尺寸语义与审计标签 - 移除 api-server 三处任务边界对 gpt-image-2-c 的兼容解析分支 - 移除主站前端历史模型常量与恢复分支，并同步其测试 - 同步 External v1 OpenAPI 描述、ADR、CONTEXT、pitfalls 与后端/运维文档 - 数据库既有 gpt-image-2-c 审计字符串保持原样，不回写不改写
2026-09-21 20:31:16 +08:00
parent fc53f362e4
commit f3c362b1ec
20 changed files with 51 additions and 102 deletions
@@ -1,11 +1,11 @@
 # 决策记录

-## 2026-09-21 图片 provider 路由白名单拒绝业务名与已退役的 gpt-image-2-c
+## 2026-09-21 图片 provider 白名单收紧，并整体删除 gpt-image-2-c

- 背景：GPT Image 2.5 迁移后，`resolve_image_provider` 仍把业务模型名 `gpt-image-2.5` 与历史 `gpt-image-2-c` 一起判为 Tiantoken，等于把「非 provider model」留在 provider 边界的白名单里。`gpt-image-2-c` 自 2026-07-21 起只是首选模型失败时的兜底 provider model，兜底移除后仅剩历史审计字符串；api-server 的图片请求一律传具体 `provider_model`（`gpt-image-2.5-flare-c` / `gpt-image-2.5-sunburst-c` / nanobanana）。
- 决策：`resolve_image_provider` 白名单只接受现役具体 provider model；业务名 `gpt-image-2.5` 与 `gpt-image-2-c` 命中即拒绝（`不支持的图片模型`）。业务名仍由 api-server 在任务边界解析成具体 key；`gpt-image-2-c` 只作为历史 fallback / 审计字符串存在，永不参与路由；`gpt-image-2` 继续作为历史可读值接受。
- 影响范围：`server-rs/crates/platform-image/src/image_provider/protocol/request.rs` 与其集成测试。提交边界（画布参数、Agent 工具参数、External v1 请求 DTO、前端历史布局恢复）对 `gpt-image-2` / `gpt-image-2-c` 的兼容解析保持不变。
- 验证：`cargo test -p platform-image` 22 项通过，新增 `resolve_image_provider_rejects_business_model_and_accepts_concrete_models`；`cargo test -p api-server` 1115 项通过。
+- 背景：GPT Image 2.5 迁移后，`resolve_image_provider` 仍把业务模型名 `gpt-image-2.5` 与 `gpt-image-2-c` 一起判为 Tiantoken，等于把「非 provider model」留在 provider 边界白名单里。`gpt-image-2-c` 自 2026-07-21 起只是首选模型失败时的兜底 provider model（兜底移除后仅剩历史审计字符串），从未进入业务模型、持久化 `model` 字段或前端契约——api-server 持久化的模型一律取自 `generation_options.model`（业务值），前端在 2.5 迁移前只写 `gpt-image-2`。
+- 决策：`resolve_image_provider` 白名单只接受现役具体 provider model，业务名 `gpt-image-2.5` 命中即拒绝，必须先在任务边界解析成具体 key；`gpt-image-2` 继续作为历史可读值接受。`gpt-image-2-c` 不再只做「拒绝」，而是整体删除：常量、re-export、`is_gpt_image_2_family_model` 尺寸语义、`auditable_image_model` 审计标签、api-server 的三处提交边界解析、前端常量与历史恢复分支全部移除；数据库既有审计字符串原样保留，代码不再引用该值。
+- 影响范围：`platform-image`（constants / lib / image_provider mod / protocol request / runtime executor / 集成测试）、`api-server`（`openai_image_generation`、`editor_project`、`editor_generation_config`、`editor_agent/tool`）、主站前端 `ImageCanvasGenerationModel` 与其测试、External v1 OpenAPI 描述、ADR 与本文档。前端与 External v1 传入 `gpt-image-2-c` 现在按「不支持的值」处理（走既有未知值分支），不再解析为 GPT Image 2.5。
+- 验证：`cargo test -p platform-image` 全绿（含新增 `resolve_image_provider_rejects_business_model_and_accepts_concrete_models`）；`cargo test -p api-server` 1115 项；`npx vitest run src/components/image-editor/ImageCanvasGenerationModel.test.ts` 34 项通过；`check:encoding`、`check:doc-index` 通过。

 ## 2026-09-21 图片 provider 启动期缺配置的报错点名环境变量

@@ -2503,7 +2503,7 @@ Cocos Creator 根目录由 `package.json.creator.version` 与普通 `assets/`

 - 现象：配置了 `APIMART_BASE_URL` / `APIMART_API_KEY` 后，RPG、拼图或方洞的 GPT-image-2 生图仍返回缺配置，或请求体里还出现 `official_fallback` / `image_urls`。
 - 原因：2026-05-21 后 GPT-image-2 图片生成按 VectorEngine 创建/编辑接口分流；2026-07-05 后创意 Agent 文本链路也改为 VectorEngine Chat Completions `gpt-5.4-mini`，APIMart 不再作为当前创意 Agent 来源。
- 处理：为图片生成配置 `VECTOR_ENGINE_BASE_URL=https://api.vectorengine.ai`、`VECTOR_ENGINE_API_KEY`、`VECTOR_ENGINE_IMAGE_REQUEST_TIMEOUT_MS`；排查请求体时确认无参考图路径为 `/v1/images/generations`、有参考图路径为 `/v1/images/edits`，业务 / 计费与 provider 首发模型均为 `gpt-image-2`，仅在符合条件的 provider 失败后切到兜底模型 `gpt-image-2-c`。
+- 处理：为图片生成配置 `VECTOR_ENGINE_BASE_URL=https://api.vectorengine.ai`、`VECTOR_ENGINE_API_KEY`、`VECTOR_ENGINE_IMAGE_REQUEST_TIMEOUT_MS`；排查请求体时确认无参考图路径为 `/v1/images/generations`、有参考图路径为 `/v1/images/edits`，新任务业务模型为 `gpt-image-2.5`，provider 具体模型为 `gpt-image-2.5-flare-c`（生成）/ `gpt-image-2.5-sunburst-c`（编辑），只在同一具体模型内重试。历史兜底模型 `gpt-image-2-c` 已从代码整体删除，不再存在任何 fallback 路径，请求体里出现该值即视为异常。
 - 验证：运行 `cargo test -p api-server openai_image --manifest-path server-rs/Cargo.toml` 和相关玩法图片生成测试；真实联调只在本地私密环境放置 VectorEngine key。
 - 关联：`docs/technical/VECTOR_ENGINE_GPT_IMAGE_2_GENERATION_2026-05-09.md`、`server-rs/crates/api-server/src/openai_image_generation.rs`。