@ai-sdk/togetherai 3.0.87：模型目录重构

Vercel 的 AI SDK 生态里，@ai-sdk/togetherai 是连接 Together AI 推理服务的官方 provider 包。3.0.87 这个补丁版本表面上只是一次依赖同步，实际改动集中在模型 ID 逻辑的组织方式上——把散落的模型标识符收拢成一个声明式的模型目录。

补丁版本里藏着的结构性调整

这个版本号属于 patch 级别，按语义化版本约定不应该引入行为变更。发布说明也明确写了「Request behavior is unchanged」，即请求行为保持不变。

改动本身是把 Together AI 的模型 ID 逻辑重构进一个模型目录（model catalog），由这个目录统一声明每个模型的能力（capabilities）和 provider 选项，并基于目录自动生成 provider 能力文档。

对使用者来说，升级后调用的模型 ID、参数传递方式、返回结构都不会变。变化发生在包的内部组织和文档生成流程上。

语义化版本（SemVer） 是 npm 生态通用的版本号约定，格式为 MAJOR.MINOR.PATCH。补丁号（PATCH）递增代表只包含向后兼容的缺陷修复或内部调整，不应引入行为变更；次版本号（MINOR）递增代表新增向后兼容的功能；主版本号（MAJOR）递增代表不兼容的 API 变更。因此发布说明中标注「Request behavior is unchanged」是对 SemVer 契约的明确确认——包使用者可以按 ^3.0.87 之类的范围自动升级，而无需担心调用方式被破坏。理解这一点，就能明白为什么一次结构性的内部重构会选择以 patch 版本发布：重构没有改变对外可观察的行为，只是重组了包的内部实现。

模型目录解决了什么问题

多模型 provider 包的长期痛点是模型元信息的分散。哪些模型支持工具调用、哪些支持结构化输出、上下文窗口多大、有哪些 provider 专属参数——这类信息过去往往散落在条件分支、硬编码列表和手写文档里。

模型目录把「模型是什么」和「怎么调模型」拆开。目录负责声明能力和选项，调用逻辑从目录读取，文档也从同一份数据生成。好处是三者不会各自漂移：文档里写的支持能力，就是代码实际执行时读取的那份声明。

这个模式在 AI SDK 的其他 provider 中已有先例。把 Together AI 对齐到同一套结构，意味着跨 provider 的维护成本下降，新增模型时只需在目录里加一条声明。

声明式（declarative） 与 命令式（imperative） 是两种相对的组织范式。命令式写法用条件分支和过程代码逐条描述「怎么做」：例如 if (model === 'x') return { tools: true }。声明式写法则用数据结构直接描述「是什么」：用一张模型表列出每个模型的能力字段，再由通用逻辑读取这张表。声明式的优势在于数据与逻辑解耦——新增模型只改数据不改代码，能力信息可被调用逻辑、文档生成、校验器等多个消费者共享，避免同一事实在多处重复导致漂移。模型目录正是把「模型 ID 以及其能力」这一事实收敛成单一数据源，这也是它比散落的硬编码列表更易维护的根本原因。

能力文档自动生成的意义

发布说明特意提到「generate provider capability documentation from it」。文档从代码数据源生成，而不是人工维护，直接消掉了一类常见问题：模型升级支持了新能力，文档没跟上；或者模型下线了，文档还在列。

对开发者来说，这意味着查文档时看到的能力矩阵更可信。对 provider 维护者来说，减少了一份需要同步更新的负担。

依赖同步与升级建议

本次一并更新了依赖，其中包括 @ai-sdk/openai-compatible@3.0.86。Together AI provider 建立在 OpenAI 兼容层之上，这层依赖的版本对齐属于常规维护。

由于请求行为未变，升级风险很低。如果你的项目锁定了 provider 版本，可以按常规 patch 升级节奏处理。如果你正在自己维护模型能力清单或文档，这次重构提供了一个参考样本：把模型元信息抽成声明式目录，让代码和文档共享同一数据源。

需要留意的是，模型目录的引入通常伴随后续版本的功能扩展——一旦能力声明集中化，按能力筛选模型、动态校验参数这类特性就有了落地基础。这个补丁版本本身没带这些功能，但结构上的准备已经完成。