DSH AI Providers 已可投入使用

DSH AI Providers 现在已经可以供开发者和用户安装使用。0.1.3 版本已发布到 npm，完整提供方套件可以加入 DeepSeek Harness 配置档，供消费插件使用的接口也已有完整文档。

这个项目为 DSH 插件提供一套与具体厂商无关的接口，用于语言模型、嵌入、重排序、文本转语音、语音转文本和图片生成。插件不必再自行实现凭据存储、提供方选择、并发控制和不同厂商的请求协议。

一套接口覆盖多种 AI 服务

AI 功能往往从彼此独立的集成开始。插件先为嵌入实现一套连接，再为语音实现另一套；需要支持第二家提供方时，同样的工作又要重做。功能代码最终会混入鉴权、端点、请求格式、错误处理和设置界面。

DSH AI Providers 把这些接线工作放到稳定的 TypeScript 服务之后。消费插件调用 @dsh-ai-providers/core 中的接口，各提供方软件包负责实现接口，@dsh-ai-providers/runtime 则处理注册、选择、设置、凭据、连接测试和共享并发限制。

当前契约覆盖：

• 语言模型路由与流式响应；
• 嵌入与重排序；
• 文本转语音，以及文件或实时语音转文本；
• 图片生成，并在提供方支持时使用参考图。

共用接口有意保持精简。厂商软件包仍可公开实用的请求参数，运行时也能显示这些设置，而消费插件无需了解对应厂商。

首个正式可用版本中的提供方

完整维护套件会安装运行时和四个提供方软件包。

@dsh-ai-providers/openai 通过可复用的 OpenAI 兼容连接提供语言模型、嵌入、语音和图片生成。@dsh-ai-providers/localai 使用同类协议，并加入 LocalAI 的默认设置、重排序、实时转写和原生图片参数。@dsh-ai-providers/anthropic 通过 Anthropic Messages API 提供语言模型。@dsh-ai-providers/jina-cohere 支持 Jina 与 Cohere 兼容的重排序端点。

OpenAI 兼容传输层还以 @dsh-ai-providers/openai-compatible 单独发布。其他提供方作者可以复用它，而不必依赖 OpenAI 插件本身。

连接和凭据只需在 DSH 中配置一次。各项能力可以独立选择合适的连接。例如，本地端点可以提供语言模型和嵌入，另一项服务负责语音或重排序。

面向消费插件设计

项目的主要读者是 DSH 插件开发者。只安装套件不会增加一个助手，也不会自行发送任何 AI 请求。它提供的是供其他插件消费的服务。

消费插件声明所需服务，然后调用稳定契约。例如，嵌入服务直接返回可用向量，而向量仍由消费插件与自己的数据一起持久化。消费插件最了解自身生命周期和失效规则，因此项目不会强加一个无法理解这些规则的共享长期缓存。

服务遵循 DSH 的实时配置模型。提供方选择和请求默认值变化时，消费代码无需修改。不可用的能力会撤回可用服务值，不会留下一个只在调用时含糊失败的空壳。错误通过共用类型跨越边界，不把厂商异常泄露给消费插件。

并发限制也由各插件共享。限制可覆盖某条模型路由或整项能力，也可为前台工作预留容量。后台索引和媒体任务可以排队，但不会无限拖住用户的下一次请求。

消费插件指南介绍服务接口和生命周期规则。要实现其他厂商，可从提供方开发指南和核心契约参考开始。

“可投入使用”的具体范围

0.1.3 是我认为可以正常使用的第一个版本。所有公开软件包使用同一版本；适用的软件包包含 DSH bundle 元数据；发布流程会先执行类型检查、自动测试、生产构建和软件包校验。

项目当前支持 DSH >=0.2.0-rc.2 <0.3.0。DSH 仍处于稳定版之前，因此这个兼容范围需要认真对待。之后的 DSH 版本可能需要对应的提供方更新。@dsh-ai-providers/core 旨在为消费插件提供稳定表面，但 0.1.x 仍是早期公开版本，不能理解为契约永远不会变化。

语言模型、嵌入、重排序、语音和图片生成也已经配合 LocalAI 做过实际验证。各提供方指南会说明软件包支持的能力，以及上游服务本身带来的限制。这里的“可用”并不意味着所有兼容端点的行为会完全相同。

安装完整套件

把维护套件加入需要使用它的 DSH 配置档：

dsh plugin --profile <profile> add @dsh-ai-providers/all

重启配置档，然后打开 设置 > AI Providers。配置所需连接和凭据引用，选择启用的服务，并在设置页中测试。安装指南还说明了用这些语言模型路由替换 DSH 自带适配器时需要调整的配置档项目。

只需要部分能力时，也可以单独安装软件包。插件开发者通常只依赖 @dsh-ai-providers/core 的类型和契约，把具体提供方选择留给用户的配置档。

接下来会写什么

项目现在已有可用的基础：共用契约、运行时、维护中的提供方、配置界面、文档和发布流程。之后只有值得单独说明的变化才会写成博客，例如重要提供方、新能力，或开发者契约发生实质变化。

现在可以先在测试配置档安装套件，配置消费插件需要的服务，并把具体兼容问题提交到项目 issue tracker。