作者：Alem Tuzlak，2026年1月2日。
在最新版本中，我们对适配器的实现方式进行了重大的架构调整。我们不再使用一个功能全面的单体适配器，而是将其拆分为更小的适配器，每个适配器负责单一功能。
原因如下。
我们需要支持
我们是一个小团队，资金和人力有限，无法承担会拖慢我们脚步的错误。适配器是整个流程中的最大瓶颈，因此正确实现这一部分至关重要。
我们试图解决三个问题：包分割、易于开发和更好的类型系统。
我们不希望向您提供一个将所有可能的功能捆绑到您的代码中的单个函数，留下您从未使用的数千字节的数据。
解决方案很简单：将单体分解为微适配器。正如所有企业都知道的，这是解决所有业务问题的答案。将其拆分为微服务，或者在我们的例子中，微适配器。
拆分后，单个 openai 函数变成了 openaiText、openaiImage、openaiSummarize，等等。您选择您需要的，我们提供适配器供您使用。
想象一下旧方法的规模
这需要几个月的时间才能发布。
以下是使用拆分适配器后的情况
这种方法使我们能够逐步推进，并最大限度地减少我们影响的表面积。支持新功能变得微不足道，因为我们不需要一次性将其添加到每个适配器中。
我们可以快速行动，添加新功能，并随着生态系统的发展逐步推出支持。外部贡献者可以通过提交几百行代码的 PR 来为适配器添加图像支持。我们可以更快地审查和合并它。
我们的 BaseAdapter 单体已经增长到 7 个类型泛型。而且它只支持聊天。
现在想象一下添加所有其他功能。我们可能会最终达到 20-30 个泛型。对于尚未支持的提供商实现新的适配器，祝你好运。
使用新方法，泛型最多为 3 个。易于添加新适配器。这让外部贡献者可以帮助我们，并让我们以更少的复杂性和更短的时间处理适配器。
一个想法是创建一个具有子属性的适配器
const adapter = openai()
adapter.image('model')
adapter.text('model')
看起来更好。感觉更分散。同样的问题。它仍然捆绑了所有内容。
我们可以在 TanStack Start 中使用自定义捆绑方法来剥离捆绑包中未使用的部分。但我们不希望您为了获得最佳体验而被迫使用我们的框架。该库适用于 Web 生态系统，而不仅仅是 TanStack 用户。这种方法是不可行的。
我们的目标是让 TanStack AI 更易于维护者和社区参与。我们做到了。
适配器易于制作、易于维护且易于理解。您的包大小保持最小。我们的生产力保持高水平。
在所有可能的结果中，这是最好的。我们对方向充满信心。我们相信您也会喜欢它。