div-anthropic D1: client.ts 云 provider 解耦 — 决定 seam 是否覆盖 bedrock/vertex/foundry 签名

[dahai80]

背景

feat/div-anthropic 分支 Phase 5 已完成错误层解耦 (commit 93bf783→8a31408): withRetry.ts / api/errors.ts / utils/errors.ts 等 12 个文件不再 instanceof APIError/APIUserAbortError,改用 isApiErrorLike/isAbortError 鸭子类型桥; 编译后二进制 0 处 @anthropic-ai/sdk 错误类引用; MLX smoke 200 OK。

但 SDK 运行时依赖的根仍在: src/services/api/client.ts 对每个 provider 都 new Anthropic(...):

// line 1
import Anthropic from "@anthropic-ai/sdk";
// line 199 — firstParty + fusionMlx 都走这里 (fusionMlx 用 custom fetch 包装, 仍需 Anthropic 类)
return new Anthropic(clientConfig);
// line 226 foundry
const { AnthropicFoundry } = await import("@anthropic-ai/foundry-sdk");
return new AnthropicFoundry(foundryArgs) as unknown as Anthropic;
// line 265 bedrock (AWS SigV4 签名)
const { AnthropicBedrock } = await import("@anthropic-ai/bedrock-sdk");
return new AnthropicBedrock(bedrockArgs) as unknown as Anthropic;
// line 292 vertex (GCP token)
const { AnthropicVertex } = await import("@anthropic-ai/vertex-sdk");
return new AnthropicVertex(vertexArgs) as unknown as Anthropic;

因此 package.json 的 @anthropic-ai/sdk / foundry-sdk 仍是运行时必需,无法移除。

问题

seam (streamViaSeam,flag LLM_ADAPTER_SEAM) 目前只覆盖 firstParty + fusionMlx 两条路径。client.ts 实例化的 SDK client 提供的不只是 HTTP 传输,还包括:

• bedrock: AWS SigV4 请求签名 (@anthropic-ai/bedrock-sdk)
• vertex: GCP OAuth token 获取与签名 (@anthropic-ai/vertex-sdk)
• foundry: Foundry 私有协议适配 (@anthropic-ai/foundry-sdk)
• firstParty/fusionMlx: SDK 的重试、流式协议、messages.create 入口 (seam 已可绕过)

要彻底去除 @anthropic-ai/sdk 运行时依赖,需让 seam 覆盖全部 provider,但 bedrock/vertex/foundry 的请求签名是 SDK 内部实现,seam 的 httpClient.ts 目前只做裸 HTTP POST,无签名能力。

约束

• 跨仓规则: fusion-code 仓库只能改 fusion-code 自身。bedrock/vertex SDK 的签名逻辑属于上游,不能复制实现进 fusion-code。
• 若自行实现 SigV4/Vertex token 签名,等于重新实现 SDK 核心能力,违反 Rule 2 (Simplicity)。

待评估方案

1. seam 扩展签名层: 在 httpClient.ts 增加 per-provider 的 signRequest hook,bedrock/vertex 各自实现轻量签名 (需评估 SigV4/GCP token 的实现量)。
2. 保留 SDK 仅用于云 provider: client.ts 仅在 bedrock/vertex/foundry 时 new Anthropic,firstParty/fusionMlx 走 seam 纯 HTTP。@anthropic-ai/sdk 变为 optional dep (云 provider 用户才装)。package.json 主依赖移除,降为 optionalDependencies。
3. 接受当前状态: Phase 5 错误层解耦已是独立价值 (seam 错误可重试/分类),SDK 依赖保留,标记为"已知技术债"。

请评估后选择方案。本 issue 解锁 D2 (package.json 移除)。

验收标准

• 选定方案并记录决策
• firstParty/fusionMlx 在 seam 下不 new Anthropic (若选方案 1/2)
• bedrock/vertex/foundry 路径有明确归属 (自实现签名 / 保留 SDK / optional dep)
• grep -rln "new Anthropic" src/ 结果与方案一致

[dahai80]

调查结论：#63 — bedrock/vertex/foundry 签名是否由 seam 覆盖

三家云 provider 的签名机制（已读 SDK 源码确认）

Provider	SDK 类	签名依赖	签名实现	路径改写
bedrock	AnthropicBedrock	@smithy/signature-v4 + @aws-crypto/sha256-js + @aws-sdk/credential-providers + @smithy/protocol-http	SignatureV4({service:'bedrock', region, credentials, sha256:Sha256}) 对 HttpRequest 做 AWS SigV4 签名，返回 signed.headers	否
vertex	AnthropicVertex	google-auth-library (GoogleAuth)	GoogleAuth({scopes:'cloud-platform'}).getRequestHeaders() 取 Bearer token，注入 Authorization 头	是 — /v1/messages → /projects/{pid}/locations/{region}/publishers/anthropic/models/{model}:rawPredict|streamRawPredict，body 注入 anthropic_version，删除 model
foundry	AnthropicFoundry	无外部（仅 @anthropic-ai/sdk）	apiKey 为字符串 → x-api-key 头；azureADTokenProvider 为函数 → Authorization: Bearer <token>	否（baseURL=https://{resource}.services.ai.azure.com/anthropic/）

关键发现

1. bedrock 的依赖树最大。SigV4 不是简单的 HMAC，它需要 AWS 凭证链解析（fromNodeProviderChain：环境变量 / shared-credentials / IAM role / SSO / 容器元数据等多源回退）、SHA-256 HMAC、规范化请求 + 签密。在 fusion-code 内重写等于重新实现半个 AWS SDK，违背跨仓库规则（签名逻辑属于上游 SDK，不应在本仓重写）。

2. vertex 需要路径改写 + GCP token。除了 Bearer token，还有一段非平凡的路径/ body 改写逻辑（模型名从 body 搬进 path）。google-auth-library 自身又是一棵依赖树（gaxios、gtoken、jws 等）。

3. foundry 最轻。无外部签名依赖，仅 x-api-key 或 Bearer <token>，URL 固定。理论上 seam 能直接覆盖，但 value 很小——它本来就不带 SDK core 耦合。

4. 三家都 extends BaseAnthropic（@anthropic-ai/sdk/client）。seam 当前的 httpClient.ts 是裸 fetch POST，没有 SDK 的 buildRequest/prepareOptions/prepareRequest 钩子，无法复用它们的路径改写与签名注入。要覆盖，必须为每家写一套等价的"请求准备器"。

建议方案（推荐 B）

A. seam 全量覆盖三家签名 — ❌ 不推荐

• bedrock 要重写 SigV4 + AWS 凭证链，vertex 要重写 GCP token + 路径改写。维护成本高、易错、违背跨仓库规则（上游问题先 issue/PR）。一旦 AWS/GCP 改签名协议，fusion-code 要跟改。

B. "SDK 仅用于云签名" + 按 provider 条件依赖（推荐） ✅

• firstParty + fusionMlx：走 seam，零 SDK 运行时（当前已实现，Phase 5 已验证二进制 0 SDK 引用）。
• bedrock / vertex / foundry：继续用对应 SDK 类做仅签名 + 请求构造，但把"签名后的 headers + 最终 URL + body"从 SDK client 抽出来，交回 seam 的 httpClient 发请求。即：SDK 退化为"签名器"，不持有网络 I/O 与流解析。
• 落地：在 client.ts 增加一个 signRequest(provider, req): {url, headers, body} 抽象，bedrock/vertex/foundry 各自调用其 SDK 的 buildRequest+prepareOptions 拿到签名头，然后 seam 统一发请求 + 解析 SSE。
• 好处：① 移除 SDK 对流解析 / 重试 / 错误分类的运行时耦合（这些 seam 已接管）；② 云 provider 功能不丢；③ 签名逻辑仍由上游 SDK 维护，合规；④ @anthropic-ai/sdk 主包对本地/firstParty 路径变成可选依赖（仅在配置了云 key 时安装），package.json 可标注 optionalDependencies 或动态 require。

C. 接受现状（不覆盖） — 可接受的退路

• 保持 Phase 5 的成果：错误层已脱 SDK，本地 + firstParty 走 seam。云 provider 仍 new Anthropic{Bedrock,Vertex,Foundry}(...)，SDK 主包作为云 provider 的硬依赖保留。
• 风险：@anthropic-ai/sdk 无法从 dependencies 移除（div-anthropic D2: package.json 移除/降级 SDK 依赖 (受 #63 阻塞) #64 被本 issue 阻塞）。

对 #64（package.json 移除 SDK）的影响

• 选 B：SDK 主包 + bedrock/vertex/foundry-sdk 可降级为 optionalDependencies（按 FUSION_CODE_USE_* 触发），#64 可推进到"默认不装、云 provider 按需"。
• 选 C：#64 无法推进，SDK 保留为硬依赖。

优先级建议

选 B，但排在"本地路径全面测试合并主干"之后。当前 PR #66 的首要任务是验证 firstParty + fusionMlx seam（已在 MLX 单机冒烟通过）。云 provider 路径在 fusion 生态中实际使用极少（fusion-mlx 本地优先），B 的落地需要真实的 bedrock/vertex 凭证做端到端测试，资源不具备时可先选 C，待有云测试环境再升级到 B。

[dahai80]

PR #66 已合并到 main (ed892e1)，Phase 1-6 (中立类型层 → HTTP/SSE 基础设施 → 适配器 → 主循环接缝 → 错误层脱 SDK → 文档) 全部落地，LLM_ADAPTER_SEAM flag (default off, dev-full set) 守护，即时回滚=关 flag。

本 issue (#63) 为 Phase 7+ 后续: client.ts 云 provider (bedrock/vertex/foundry/openai) 仍走 new Anthropic(...) 签名。接缝当前仅覆盖 firstParty + fusionMlx。作为独立后续任务保留，不阻塞本次补丁发布。