TypeScript 项目里多模型对话的 Vercel AI SDK 类型怎么抽象
如果我同时接入多个大模型，每个模型的返回结构、消息格式、工具调用能力都不一样，直接写业务代码会遇到什么问题？抽象类型能解决哪些维护成本？
先统一类型边界，再扩展模型能力
多模型场景下，直接把 SDK 返回值散落在业务层，通常会带来类型分散、分支判断过多、接口升级困难等问题。抽象类型的价值在于把“模型差异”收敛到一层适配器里，让上层只面对统一的对话输入、输出、流式响应和工具调用结果。这样做的好处是，新增模型时只需要补充适配逻辑，不会影响聊天 UI、会话存储和业务编排代码。
我想让 GPT、Claude、Gemini 这类模型都能走同一套对话流程，但它们的 message、part、toolCall 类型都不同。应该用联合类型、泛型，还是用适配器模式来组织这些类型？
用统一领域类型包住模型原生类型
比较稳妥的做法是定义一套与业务强相关的领域类型，例如统一的 Message、ToolInvocation、StreamChunk，再用泛型或映射类型去承接不同模型的原生结构。模型原生类型只出现在适配层，由适配器负责转换成统一领域类型，或把统一领域类型转换回模型所需格式。对于工具调用和流式输出，建议把“能力”作为可选泛型参数或能力标记，这样既能保留类型安全，也能避免某个模型不支持某功能时把类型写死。
我希望代码里能明确区分哪些模型支持流式、哪些支持工具调用、哪些支持图片输入。有没有办法让 TypeScript 在调用时自动提示可用能力，并阻止错误用法？
用能力约束驱动类型推导
可以把模型能力抽象成独立的类型参数或能力接口，例如 Streamable、ToolEnabled、VisionEnabled，再把模型客户端声明为带能力约束的泛型类型。调用方拿到具体模型实例后，TypeScript 就能根据实例类型推导可用方法和参数结构。这样做能在编译期拦住不支持的调用，比如对不支持工具调用的模型传入 tools 参数，或者在不支持图片输入的模型上使用 multimodal 消息结构。
我可能会根据价格、延迟、额度或者地区限制动态切换模型。切换后输入输出类型怎么保持一致，避免每换一个模型就改一堆业务代码？
把切换逻辑放在适配层，保持业务协议稳定
模型切换和降级的关键，是让业务层依赖稳定协议，而不是依赖某个具体 SDK 的类型。可以定义一个统一的 ChatModel 接口，所有模型实现都返回同一种业务可消费的数据结构。切换逻辑只负责选择具体实现，不参与业务类型定义。这样即使底层从一个模型切到另一个模型，只要适配层继续输出同样的协议，前端渲染、消息存储、审计日志和测试用例都不需要跟着重写。