DeepSeek Harness 支持哪些供应商：清单不在仓库，只有一份快照

2026-08-16

翻一个新框架，最先想确认的往往是「它能接哪些模型供应商」。在 deepseek-harness 里，这个问题的答案有点绕：你在仓库里找不到那份清单。

先把限定条件摆前面。本文依据的是 2026-08-16 采集的快照 47f9438，仓库版本 0.1.0-rc.5，没有任何 GitHub Release，README 自述处于开发者预览阶段并明写未来会有破坏兼容性的变更。下面提到的每一个文件路径、字段名、路由名，都可能在后续版本里变掉。我们没有安装这个项目、没有装过 node_modules、没有调用过任何模型 API，本文全部内容都是对快照文件的静态阅读。

清单在代码里只是一次函数调用

供应商目录的入口在 packages/llm/llm-pi-ai/src/catalog.ts。这个文件在第 15 行、第 123 行、第 141 行引用了 @earendil-works/pi-ai/providers/all 的 builtinProviders() 与 getBuiltinProviders()——也就是说，路由清单是运行时从 pi-ai 这个外部库里读出来的，源码里只有调用，没有名单。

那能不能顺着依赖读进去？packages/llm/llm-pi-ai/package.json 的 dependencies 只有两项：@earendil-works/pi-ai: ^0.82.1 与 @deepseek-ai/schemastery: workspace:^，pnpm-lock.yaml:9255 锁定的解析版本是 0.82.1。但这个包不在仓库里：vendor/ 目录下只有 cordis、cosmokit、group、hmr、include、loader、logger-console、schemastery、timer 九项，没有 pi-ai。我们又没有安装依赖，所以 builtinProviders() 到底返回哪些名字、每个 provider 的 endpoint 和模型清单长什么样，从快照里核不出来。

这是个挺常见的情形：一份看起来属于「产品能力」的清单，实际上是第三方库的数据。它不随仓库版本走，跟着依赖版本走。

仓库里唯一能直接读到的等价证据

翻遍快照，能直接读到具体名字的地方只有一处，而且它在测试目录里：

apps/web/tests/snapshots/models-settings/empty.expected.md 的第 25 到 60 行，是 Web 端 Models 设置页「提供方」下拉的期望文本（中文界面）。用 Python 按 - option "…" 正则统计，共 36 个 option：

python -c "
import re
t=open('apps/web/tests/snapshots/models-settings/empty.expected.md',encoding='utf8').read()
opts=re.findall(r'- option \"([^\"]+)\"',t)
print(len(opts)); print(opts)
"

得到的名单（照抄这 36 个标识符，未做任何排序与增删）：


`amazon-bedrock`	`ant-ling`	`anthropic`	`azure-openai-responses`
`cerebras`	`cloudflare-ai-gateway`	`cloudflare-workers-ai`	`deepseek`
`fireworks`	`github-copilot`	`google`	`google-vertex`
`groq`	`huggingface`	`kimi-coding`	`minimax`
`minimax-cn`	`mistral`	`moonshotai`	`moonshotai-cn`
`nvidia`	`openai`	`opencode`	`opencode-go`
`openrouter`	`qwen-token-plan`	`qwen-token-plan-cn`	`together`
`vercel-ai-gateway`	`xai`	`xiaomi`	`xiaomi-token-plan-ams`
`xiaomi-token-plan-cn`	`xiaomi-token-plan-sgp`	`zai`	`zai-coding-cn`

这张表要怎么读，比表本身重要，所以说清楚三件事：

第一，它是一个测试期望文件里的下拉选项列表，不是我们跑出来的界面。我们没有安装、没有启动过这个项目，这里也不涉及页面长什么样。

第二，它反映的是快照录制时那一版 pi-ai 目录中「能被本适配器认证」的路由集合，不是「dsh 官方支持的供应商列表」，更不代表其中任何一家的可用性、稳定性或质量。本文只是转述这份文本里出现的标识符，不推荐、不比较、不评价其中任何一项服务，仓库里也没有价格与额度信息可供转述。

第三，它随依赖漂移。既然名单来自 pi-ai，那么升级依赖就可能增删条目，而快照文件只有在有人重新录制时才会跟着变。

名单为什么会「少人」：一条扣留逻辑

有意思的是，这 36 项里没有 openai-codex。

原因写在仓库自带的一份 Agent Note 里：.agents/notes/implemented/bug-fix/2026-08-13-oauth-only-providers-withheld.md:37 说明，只提供 OAuth、没有 api-key 认证方式的目录 provider 会被从可配置目录里扣留，而 openai-codex 是安装目录中唯一这样的。同一行还点名了六个「同时提供 OAuth 与 api-key、因此保留条目」的路由：anthropic、github-copilot、kimi-coding、openrouter、radius、xai。

扣留逻辑落在代码里是两处：packages/llm/llm-pi-ai/src/index.ts:142-144 只在 catalogProviderTakesApiKey(provider) 为真时才 declare 该路由；判定实现在 catalog.ts:160-162，本体是 catalogProvider(provider)?.auth.apiKey !== undefined。

也就是说，那 36 个不等于 pi-ai 目录的全集，而是过了一道认证形式筛子之后的子集。这道筛子的判定依据写得很直白：目录条目里有没有 api-key 这种认证方式。

两处名单对不上的地方

沿着这条线往下核，会撞上两处口径不一致。按惯例，这里只陈述差异并标明位置，不推断哪一处「是对的」，也不据此评价项目。

其一，Codex 在不在设置页上。 docs/user/guide/providers.md:19 把 Codex 与 Bedrock、Vertex、Azure 并列，描述为「用 OAuth，只填 API-key 字段配不起来」；而上面那份 Agent Note 的第 37 行写的是 openai-codex 会从可配置目录中整体消失，快照里的 36 个选项中也确实没有它。两处对「Codex 还看不看得到」的表述不一致。

其二，radius 这个名字。 它出现在 Agent Note 第 37 行那六个保留条目里，却不在 empty.expected.md 的 36 个选项中。这个路由当前是否存在于安装目录，我们没能从快照里核实。

别把「协议表」当成「供应商清单」

还有一处容易串线的地方。packages/llm/llm-pi-ai/src/provider.ts:47-51 里有一张 PROTOCOLS 表，只有三项：openai-completions、openai-responses、anthropic-messages；supportedProtocols()（provider.ts:61）就是它的 Object.keys()，config.ts:235 用 z.union(supportedProtocols()) 当作 profile 里 api 字段的取值域。

三个协议名和三十六个路由名是两件事：前者是手写自定义 provider 时能命名的线协议，后者是目录里已经带好 endpoint 与协议的路由。provider.ts:32-45 的注释解释了协议表为何这么窄——Bedrock 要用 AWS 凭据加 region 做 SigV4 签名，Vertex 需要 project / location / ADC，Azure 需要 provider 环境再加 api-version，Codex 走 OAuth，这套配置形状表达不了，硬开出来只会得到一个无法认证的 provider。注释同时写明：目录路由仍可通过自带 provider 走到全部协议，只有显式 override 被拒绝。

顺带一提名字撞车的处理。快照里既有 pi-ai 目录中的 deepseek，也有随仓适配器 dsh-llm-deepseek 自己占的路由 deepseek-official（packages/llm/llm-deepseek/src/index.ts:47）。改名理由记录在 .agents/notes/implemented/architecture/2026-07-30-web-config-plane.md:21：pi-ai 目录合理地拥有 deepseek 这个聚合器条目，所以本地适配器改叫 deepseek-official，并且没有做别名兼容。

想自己核这份名单，可以按这个顺序走

先确认自己在读哪个快照。这个仓库建于 2026-08-13，我们采集是 2026-08-16，前后只差三天；采集当天 star 数在几十分钟内从 131,928 变到 132,054，同一天 GitHub API 返回的 open issues 是 0——这些数字变动很快，以仓库当前显示为准，也不要拿它们推导任何关于成熟度的结论。
读 apps/web/tests/snapshots/models-settings/empty.expected.md，用上面那段 Python 自己数一遍，别凭印象记条目数。
顺着 packages/llm/llm-pi-ai/src/catalog.ts:15,123,141 确认清单确实来自外部依赖，再看 vendor/ 里有没有它。
想知道某个路由为什么不见了，去 index.ts:142-144 和 catalog.ts:160-162 看扣留判定。
如果你关心的是「能不能让它去问端点要模型列表」，那是另一条路径：packages/llm/llm-pi-ai/src/discovery.ts 里可探询的协议只有 openai-completions 与 openai-responses 两项（:38-41），其余抛 DISCOVERY_UNSUPPORTED（:226-231）；而目录路由会短路——catalogModels(provider) 非空时直接从安装目录返回，不发网络请求（:201-211）。docs/user/guide/providers.md:92 的用户侧说法与此对应：模型发现调用的是 OpenAI 兼容的 GET /models，不提供该端点的就手动填模型。

最后提一句凭据。按 packages/credentials/credentials-local/src/index.ts 的模块注释，本地凭据有四层优先级：继承的进程环境（只读，最高）> $DSH_HOME/.credentials.yaml（可写）> 调用目录下的 .env（只读兜底）> $DSH_HOME/.env（只读兜底）；describe() 只返回 { configured, source?, writable }，永不返回值本身。配置里引用密钥的字段（例如 pi-ai profile 的 apiKeyEnv）填的是环境变量名，不是密钥本身，写示例时也别把明文放进去。

这篇的落点其实只有一句：当你在一个框架里找不到某份清单时，先分清它是「没写」还是「不属于这个仓库」。deepseek-harness 属于后者——清单归依赖所有，仓库里留下的是一份测试快照，正好够你确认它长什么样。

延伸阅读

从头读起：DeepSeek Harness 是什么：建仓三天、13 万 star 的 Agent 框架
本专题共 45 篇，完整分组目录见专题页
DeepSeek Harness 手写路由支持的三种线协议分别是什么
DeepSeek Harness 的重试与超时默认值：退避、抖动与流式空闲

本文依据 DeepSeek Harness 官方仓库（github.com/deepseek-ai/deepseek-harness）的 README、docs/ 下的架构与子系统文档、以及 packages/ 下的源码整理，核对日 2026-08-16，对应仓库快照 47f9438（版本 0.1.0-rc.5）。本文内容为仓库源码与文档口径，我们没有安装、也没有运行过这个项目，因此不涉及界面外观、操作手感与运行速度的任何描述。该仓库建立于 2026-08-13，README 自述处于开发者预览阶段并明确说明未来会有破坏兼容性的变更，文中出现的命令、配置与默认值随时可能变动，请以仓库最新内容为准。安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。