DeepSeek dsh 上手实测：别急着填官方 API key，先看清模型接入这一层

 

 

DeepSeek 前阵子把自家的 Agent Harness 开源了，命令行工具叫 dsh，MIT 协议，目前还是开发者预览版。它有个口号我挺喜欢：Everything is a plugin。模型、工具、技能、会话全都是插件，随时能换。

 

网上不少介绍到这一步就收尾了。但“模型也是插件”这句话认真想想，马上会冒出一个更实际的问题：这个模型插件，线该接到哪里去？

 

官方最顺手的路径是在 Settings → Models 的 DeepSeek 卡片里填个 API key，半分钟跑通。跑 demo 够用了。可我实际用了几天之后，发现直连模式有四个坑，一个比一个烦：

 

多模型的管理成本。dsh 把切换模型做成了改配置就行，但每个模型各连各的服务，账号、密钥、计费后台、错误处理仍然散在好几家平台。切换是轻了，管理没轻。

 

长任务的链路稳定性。我实测一个实时数据看板任务，跑两轮累计烧掉约两千万 token，运行超过三十分钟。任务一长，一次限流或连接抖动就可能让任务中断、重复请求、多烧 token。稳定性问题这时候就是实打实的钱。

 

故障降级没地方放。主模型撞上 5xx 或限流，理想做法是按错误类型切到备用模型继续跑。dsh 支持配多个 provider，但自动切换的路由逻辑得自己补。

 

用量分散。多模型分散在几个平台后台，各家 token 统计口径、缓存计费还不一样，月底对账得手工拼。

 

这几个问题都卡在 Harness 和模型服务中间，可以单独抽出一层“模型接入层”来管：统一入口，顺带承接路由、降级和用量统计。dsh 在这层留了插件接口，接到哪里由你自己定。本文接的是一个 MaaS 网关（七牛大模型平台）。

 

 

先说结论：用自定义 Provider 接网关

 

dsh 的模型接入有三条路：

 

DeepSeek 卡片。Settings → Models 里那张独立卡片，填 API key 就完事，端点、协议、模型列表全部内置。最省事。

 

目录 Provider。点 Add provider，从内置目录选 Anthropic、OpenAI 这类供应商再填凭证。

 

自定义 Provider。点 Add a custom provider，可以接企业网关、自建服务，以及目录没收录的供应商。

 

我选第三种。它背后是 llm-pi-ai 插件，走 OpenAI 兼容协议。只要平台给出兼容端点，就能挂进 dsh。

 

两个细节提前记一下：Provider ID 会被请求、会话、模型默认值和凭证引用，保存后改不了，建议按用途起名，比如 gateway-main。另外 API key 和普通配置是分开存的：实际凭证放在 $DSH_HOME/.credentials.yaml，settings 里只存引用，敏感信息和普通配置天然隔离，这个设计我给好评。

 

具体配置步骤

 

进入 Settings → Models → Add a custom provider，填这几项：

 

 

Settings → Models → Add a custom provider

 

 

Provider ID：小写字母，按用途命名

 

Base URL：见官网

 

API protocol：openai-completions

 

API key：七牛大模型平台控制台里的密钥

 

填完别急着保存，先用 Model catalog 区域的 Fetch available models。它会拿当前的 Base URL 和凭证去请求 OpenAI 兼容的 GET /models 接口，把平台上可用的模型直接拉回来。这次实测里，同一个 API Key 下拉出了 DeepSeek-v4-Pro-0813、GLM-5.3、MiniMax、Kimi、Qwen 一串模型（下图是删减版）。比手敲模型 ID 靠谱，手敲我至少敲错 过一次模型名。

 

 

配置完成后写入 $DSH_HOME/settings.yaml，核心结构大致是：

 

 

llm-pi-ai:
providers:
gateway-main:
apiKeyEnv: QINIU_API_KEY
api: openai-completions
baseURL: https://api.qnaigc.com/v1
models:
- id: deepseek/deepseek-v4-pro-0813
- id: z-ai/glm-5.3

 

 

用 apiKeyEnv 引用环境变量，避免密钥明文进配置文件。需要图片输入的模型，还可以用 input: [text, image] 声明模态。注意这类字段是你对端点能力的声明，得跟模型服务实际支持的对上，声明了它不支持的能力会在调用时翻车。

 

换个模型跑一遍看看

 

为了验证 dsh 的模型切换，我用同一个 Prompt，在两个全新 Workspace 里分别跑 DeepSeek-v4-Pro-0813 和 GLM-5.3，任务都是“从零实现一个 AI 模型调用数据看板”。

 

DeepSeek-v4-Pro-0813 跑了约 5 分钟、16 Steps；GLM-5.3 跑了约 8 分 31 秒、19 Steps。两边都完成了任务。这里我不打算比较两个模型谁强谁弱，因为重点是 dsh 本身：换了模型，Harness 的执行流程照常往下走。

 

 

 

两边最终都产出了可运行的看板，指标卡、Token 消耗趋势、调用明细、筛选这些都有。整个过程我只在 dsh 里选了一下模型，工具配置和调用方式一行没动。

 

这次实测把“模型即插件”最直观的一点坐实了：同一个 Provider 下，换模型停在配置层就够了。

 

 

 

这么接到底值在哪

 

回到开头的问题，在 dsh 和模型之间加一层统一接入，我自己体感到的收益有三个。

 

换模型更轻。多个模型走同一套兼容协议、同一个平台，切换就是改一下模型配置，dsh 的插件化设计才能真正跑起来。

 

长任务有了兜底位置。Agent 会连续调用模型，RPM 限额、超时、重试、模型暂时不可用都会影响整条任务。统一接入后，限额和用量集中管理，Harness 也能基于统一入口处理错误和重试。

 

对账不头疼了。多模型从同一平台调用，消耗和费用在同一个后台看，省掉跨平台查询和手工对账。

 

所以我的看法是：dsh 的插件化解决的是 Harness 内部怎么替换模型；模型接入平台解决的是多个模型怎么从同一入口被管理。两层叠起来，Everything is a plugin 这句话才真正延伸到了模型服务那一侧。

 

一个提醒：dsh 还在开发者预览阶段，官方文档明说了后面可能有破坏性变更。本文的字段和配置以当前版本为准，升级时记得重新核对 Provider、模型配置和凭证相关的文档。

 

 

如果你也想把 dsh 这类 AI Agent 工具和模型接入能力真正用进自己的业务，可以咨询云巴巴。云巴巴是国内领先的企业数智服务平台，覆盖 AI 大模型、智能体、协同办公、营销获客、安全合规等多个领域的企业级产品与方案，能按你的行业、规模和预算比对选型、匹配资源、协助落地。欢迎咨询云巴巴，获取更多产品方案与专属服务。