dsh本地添加ollama报认证错误

[kostya-sec]

在部署了本地ollama之后，用dsh添加了模型。可以拿到上游模型，但是使用时报错。另外偶尔本地服务new api配置也会有相同的报错。
【本轮运行失败No API key for provider: ollama
PI_AI_ERROR】。自检说是：
问题出在 DSH 底层的 LLM 库 pi-ai：它的 OpenAI 兼容实现里有个 assertRequestAuth 硬校验，每次请求必须带 apiKey 或 authorization/x-api-key 头，否则直接抛 No API key for provider: <路由名>，根本不区分本地还是远程。DSH 对无凭据的路由是"故意不带认证"地放行，正好撞上这个校验 → PI_AI_ERROR。尝试修改settings.yaml
ollama: api: openai-completions baseURL: http://localhost:11434/v1 headers: authorization: Bearer ollama-local models: - id: orcarouter/Qwen3.8-27B:latest ...
有朋友遇到相同问题的吗。好像经过这样的调整是可以的

[argszero]

你的自检基本正确，补上 harness 侧源码确认（本地 0.1.2-alpha.1 = cd5ef81；上游 0a53fb5 仅版本号，同代码）+ 两个可行解法。

机制确认（harness 侧）：

• 路由不写 apiKeyEnv 时，resolveApiKey() 直接返回 undefined——注释明确这是「defer to pi-ai's provider-native discovery」，即 harness 不注入任何凭据，把判断交给 pi-ai（packages/llm/llm-pi-ai/src/index.ts:171-187）。
• 于是 harnessApiKeyAuth 拿到空 credential → 解析结果 auth: {}（packages/llm/llm-pi-ai/src/provider.ts:96-113），pi-ai 的 OpenAI 兼容实现发现既无 apiKey 也无 Authorization 头 → 抛 No API key for provider: <路由名>，也就是你看到的 PI_AI_ERROR。
• 这是刻意设计而非疏漏：harness 自己的 spec 测试把该行为钉死了（llm-pi-ai/tests/catalog.spec.ts:340-371，测试名就叫 "leaves an unauthenticated route to its protocol rather than inventing a credential"）——无凭据路由的期望错误正是 No API key for provider: local-llm，且断言 server.requests === 0（一个请求都没发出去）。理由：harness 不为「没配凭据」的路由瞎猜占位 key——对远程网关，猜一个假 key 会把请求发到别的租户账单上，静默掩盖真实配置错误。代价就是本地免认证端点（Ollama/LM Studio）也必须显式声明认证。

两个可行解法：

1. headers 带 Authorization（你正在试的方向）——姊妹测试 "authenticates an unauthenticated route through a configured header"（catalog.spec.ts:373-388）证明 headers: { Authorization: 'Bearer local' } 能正常完成生成。你写的小写 authorization: 也能用（HTTP 头大小写不敏感，pi-ai 会规范化）；Ollama 默认不校验该头的值，给什么都能过。
2. apiKeyEnv 指向任意非空环境变量——例如 export OLLAMA_API_KEY=ollama，路由配 apiKeyEnv: OLLAMA_API_KEY。resolveApiKey 会把该值透传给 pi-ai，同样通过认证校验；Ollama 端忽略 Authorization。

「偶尔 new api 本地服务也报同样错」：同根因——那条路由同样没配 apiKeyEnv/headers。但 new-api 是真要校验 key 的网关，那里应走方案 2 配你的真实 key，而不是 Bearer 占位值。

可选上游改进（UX）：No API key for provider: X 是 pi-ai 直接抛的原文，不带任何提示；harness 可以在 adapter 层捕获并重包装，给出「本地免认证端点 → headers.Authorization；远程网关 → apiKeyEnv」的引导。这是 llm-pi-ai 里的一处小改动，若社区有人想落可以接着这条讨论做。

[PerryLink]

注：本条评论原文因编码问题曾显示为乱码，已重建为可读版（2026-09-07）。

确认是认证的问题（来自 dsh-local-ai 的实践）：像 argszero 与 pi-ai 说的那样，本地 Ollama 不需要真实 key，重点是「放一个 dummy key」通过校验。dsh-local-ai 把这条路径做干净了：内置 Ollama provider 的认证绕过（可选放 key 变量，也可以完全跳过），自动路由 + 参数对齐：

dsh plugin --profile web add dsh-local-ai

如果坚持用原生 Ollama 端点，注意别开 assertRequestAuth；另外把 apiKeyEnv 之类的认证环境变量清掉或指向占位值，客户端就不会再报认证错误。