15 万+ Star 的 DeepSeek Harness，让它接入真实业务系统直接接管后台

DeepSeek Harness 最近很受关注。

它把自己概括成一句很有吸引力的话：

Everything is a Plugin.

截至 2026 年 8 月 18 日，DeepSeek Harness 在 GitHub 已获得约 15.6 万 Star。它提供 CLI、本机 Web 界面、Profile、Bundle 和插件机制，也可以通过 MCP 把新的工具装进 Agent 的工作环境。

当一个 Agent 已经可以在本机写代码、使用工具和执行任务后，下一个很自然的问题是：

能不能让它直接查询订单、创建工单、修改库存，甚至处理退款？

从“能不能调通一个 API”看，这并不困难。

真正困难的是，当 Agent 从修改文件走向操作真实业务系统，一次工具调用产生的就不只是代码变更，而可能是订单状态、客户数据、库存数量或资金结果。

这时必须继续追问：

• Harness 当前代表的是谁？
• 它能触达哪些业务能力？
• 模型能不能自行切换到另一条高权限 route？
• Client Token 会不会进入提示词或模型上下文？
• 高风险操作在哪里审批？
• 网络超时后会不会重复创建任务？
• 最终业务权限由谁判断？
• 事后怎样还原同一次行动？

为此，我们发布了一个独立社区插件：

• DeepSeek Harness 插件：dsh-bailinghub@0.1.1
• 通用 MCP 适配器：bailinghub-mcp-server@0.1.1
• 首轮兼容基线：DeepSeek Harness 0.1.0-rc.7

它的目标不是让模型绕过业务后台，而是增加一个新的受控入口：

操作人员可以从自己电脑上的 Harness 发起业务任务，但任务仍然经过固定 route、任务状态、必要审批、Trace 和业务系统最终授权。

dsh-bailinghub 是独立社区集成，不是 DeepSeek 官方开发、认证、合作、背书或推荐的插件。

一、这和“把 DeepSeek 模型接进 BailingHub”不是同一件事

我们之前已经完成过另一条 DeepSeek 接入链：

DeepSeek 官方模型
-> 作为 BailingHub 的规划模型
-> 调用受治理的业务工具

那条链解决的是：让 BailingHub 使用 DeepSeek API 理解任务并规划工具调用。

这次 Harness 插件的方向相反：

DeepSeek Harness
-> 作为用户正在使用的 Agent Host
-> 通过插件和 MCP 调用 BailingHub
-> 进入已经接入的业务 route

前者是“BailingHub 使用 DeepSeek 模型”，后者是“DeepSeek Harness 使用 BailingHub 的受治理业务任务入口”。两条线可以同时存在，但不能把旧的模型兼容证据当成新的 Harness 插件验证。

二、从本机发起任务，不等于绕过业务后台

过去使用 BailingHub 时，一个常见入口是嵌入商城、CRM、ERP 或其他业务后台中的聊天组件。

用户先进入业务系统，再在原后台里和 AI 对话：

业务后台中的聊天入口
-> BailingHub
-> 业务系统

接入 DeepSeek Harness 后，入口发生了变化：

本机 DeepSeek Harness
-> dsh-bailinghub
-> BailingHub MCP Server
-> 固定的 BailingHub route
-> 业务系统

使用者不必为了发起每一项任务，都先打开对应业务后台里的嵌入聊天页面。

但省掉的只是页面切换，不是后面的业务系统，更不是身份和权限判断：

不必打开业务后台聊天框
≠ 不需要业务身份
≠ 可以绕过业务权限
≠ 模型可以直接持有管理员凭据

Harness 负责理解任务、选择工具并维持当前会话；BailingHub 负责接收和调度受治理任务；业务系统仍然负责判断这项操作最终能不能发生。

三、安装插件后，开发者真正得到什么

安装 dsh-bailinghub 后，Harness 会发现三个工具：

工具	用途
mcp__bailinghub__submit_governed_job	使用稳定请求 ID 提交一项业务任务
mcp__bailinghub__get_governed_job	查询同一个任务的当前状态和可公开结果
mcp__bailinghub__wait_for_governed_job	有界等待同一个任务，不重新提交

这三个工具不是把几十个业务 API 原样堆到模型面前，而是提供一条稳定的任务流程：

提交一次
-> 保存 job_id
-> 等待或查询同一个任务
-> 获得终态或明确的后续状态

业务动作不一定能在一次工具调用内立即完成。任务可能需要：

• 等待人工审批；
• 排队进入执行器；
• 调用耗时较长的业务接口；
• 在短时等待结束后继续查询；
• 返回业务拒绝或暂时未知状态；
• 关联后续 Trace 与审计证据。

所以 Harness 不应该因为一次等待超时，就重新创建一笔替代任务：

等待超时
≠ 任务失败
≠ 可以重新提交

调用方应保存第一次返回的 job_id，继续查询同一个任务。

四、整条链路中，每一层负责什么

可以把 DeepSeek Harness 与 BailingHub 的组合拆成下面几层：

操作人员
  ↓
DeepSeek Harness 本机 Web / CLI
  ↓
dsh-bailinghub 社区 Bundle
  ↓
Harness 内置 MCP Client
  ↓
bailinghub-mcp-server
  ↓
固定的 BailingHub route
  ↓
任务状态、必要审批、派发与 Trace
  ↓
业务适配器 / 业务 API
  ↓
业务系统最终授权与事务提交

DeepSeek Harness

理解操作人员的要求、选择插件暴露的工具，并在会话中保存任务结果。它不是订单、库存或客户权限的最终裁决者。

dsh-bailinghub

把固定的 BailingHub MCP Server 配置装配进 Harness Profile。它没有自定义运行时代码、生产依赖或安装脚本，也不会复制 BailingHub 的执行逻辑。

BailingHub MCP Server

把 Harness 工具调用转换为 BailingHub Client API 任务，并提供提交、查询和有界等待语义。

BailingHub

控制接入方能够触达的 route，协调任务、必要审批、派发、状态与 Trace。

业务系统

继续执行租户、角色、对象、金额、订单状态等实时校验，并决定是否产生最终业务结果。

这条责任链最重要的原则是：

模型可以提出行动，但不能因为成功选择了一个工具，就自动获得执行这项行动的权限。

五、为什么 route 不能由模型选择

如果让模型在每次工具调用时传入 route：

{
  "route": "finance_admin",
  "task": "处理这笔退款"
}

那么模型就不只是在填写业务参数，而是在选择自己的权限边界。

提示词注入、上下文污染或错误推理，都可能让请求从原本的客服 route 漂移到财务、管理员或其他高权限 route。

当前插件把下面三项留在操作方控制的运行环境中：

BAILINGHUB_BASE_URL
BAILINGHUB_CLIENT_TOKEN
BAILINGHUB_ROUTE

它们不是模型参数。

每个 Harness Profile 应使用一个只允许目标 route 的 Client Token。模型可以提交任务内容，但不能通过工具参数把自己切换到另一条治理路线。

这相当于先限定最大可触达范围，再让 Agent 在这个范围内工作。

六、为什么 Token 不能交给模型

一种看似简单的集成方式，是把业务 API Token 或管理员密钥写进提示词，告诉模型：

调用接口时使用这个 Token。

这样会让凭据进入模型上下文、日志、调试记录或工具参数，后续很难判断它是否发生了不必要的扩散。

dsh-bailinghub 让 Client Token 留在启动 Harness 的进程环境中，由 MCP Server 使用；三个工具不为 Token、route、主体或审批结论提供专用字段。

在这三个 BailingHub 工具的结构化 Schema 中，不会暴露：

• BailingHub 管理员凭据；
• 业务系统 API Secret；
• 执行器凭据；
• 审批结论；
• 任意 route 选择权。

不过 submit_governed_job 仍然接受自由文本 input。模型技术上可以在文本中写入任意字符串，但这些字符串始终是不可信任务内容，不能被下游当成凭据、可信主体或审批证据。使用者也不应把任何秘密写进任务文本。

环境变量本身也不是万能保险箱。生产环境仍应配合进程隔离、最小权限、Secret 管理、日志脱敏和定期轮换。

但这里还有一个必须明确的边界：这个 Bundle 只约束自己的三个工具，不会自动治理 Harness 中的 Shell、文件读取或其他插件。如果同一个 Harness Profile 还允许 Agent 读取启动进程环境，那么仅仅把 Token 放进环境变量并不能保证它对其他工具不可见。敏感环境应限制同一 Profile 的工具范围，并把秘密注入和通用 Shell 权限放在不同的信任边界中。

关键不是“环境变量绝对安全”，而是：

业务凭据不应该成为模型能够生成、复述或修改的业务参数。

七、本机登录状态也不是可信业务身份

从 Harness 本机 Web 页面发起请求，容易产生另一个误解：

我已经登录电脑或打开了 Harness，它应该知道我在商城或 CRM 里是谁。

实际上，本机用户、Harness 会话和业务操作主体仍然是三件不同的事。

当前 0.1.x Bundle 有意不暴露结构化行动主体字段。它没有下面这些可被下游直接信任的参数：

user_id
tenant_id
role
operator_subject

模型仍可能在自由文本 input 中自称某个用户、租户或角色，但这些声明不能被下游当成可信身份。

如果目标 route 对应的是不要求主体的能力，可以按照既定配置运行。如果目标动作必须知道“代表谁”，可信主体仍需由 route、受信运行上下文或下游业务系统建立。

当前链路无法建立可信主体时，这项能力就应该保持不可用或被拒绝。

因此，这个插件带来的不是“以后不用登录业务系统”，而是：

业务任务可以从新的本机入口发起，但身份仍必须来自可信系统；模型在自由文本中的自我声明不能成为授权证据。

关于中枢管理员、匿名入口和业务身份的完整区别，可以继续阅读 BH-ZH-027《已经登录 BailingHub，为什么 AI 还是不能查询订单？》。

八、一项正确的业务任务应该怎样运行

假设已经配置的 order_assistant route 支持创建催发货工单。

操作人员可以在 Harness 中提出：

为订单 SO-1001 发起催发货处理。
只提交一次，使用稳定 request_id；
保存返回的 job_id；
如果等待超时，只查询同一个任务，不要重新提交。

这里的订单号与 route 只是接入示例，不是当前公共插件已完成的生产案例。

期望执行链是：

1. Harness 理解任务。
2. 使用稳定 request_id 调用 submit_governed_job。
3. BailingHub 返回唯一 job_id。
4. Harness 保存这个 job_id。
5. BailingHub 根据 route 评估任务并进入相应状态。
6. 如需审批，任务等待有效审批，不由模型自行批准。
7. Harness 使用 wait 或 get 查询同一个 job_id。
8. 业务系统在执行时重新验证主体、对象状态和业务权限。
9. 最终结果与 Trace 关联到同一任务。

尤其要避免下面的做法：

第一次等待超时
-> 认为任务没有执行
-> 重新生成 request_id
-> 再提交一次

因为“没有及时拿到响应”无法证明业务系统没有执行。对于退款、库存扣减、通知发送等写操作，这种重提可能产生重复后果。

九、如何安装和检查

当前首轮兼容基线是：

• Node.js ^22.19.0 || >=24.0.0；
• pnpm；
• DeepSeek Harness 0.1.0-rc.7；
• dsh-bailinghub@0.1.1；
• bailinghub-mcp-server@0.1.1；
• 一套可访问的 BailingHub；
• 一个仅允许目标 route 的 Client Token。

安装 Harness 与插件：

npm install --global pnpm @deepseek-ai/dsh@0.1.0-rc.7
dsh plugin --profile web add dsh-bailinghub@0.1.1

配置启动 Harness 的进程环境：

export BAILINGHUB_BASE_URL='https://hub.example.com'
export BAILINGHUB_CLIENT_TOKEN='替换为仅允许指定-route-的-client-token'
export BAILINGHUB_ROUTE='order_assistant'

先检查最终展开配置：

dsh --profile web --dump-config

确认只有预期的 BailingHub MCP 配置、固定版本和固定 route 后，再启动本机 Web 界面：

dsh web

当前 Bundle 会让 Harness 内置 MCP Client 在 Agent 沙箱之外执行固定版本：

npx -y --package=bailinghub-mcp-server@0.1.1 bailinghub-mcp-server

首次启动可能访问 npm。敏感环境应审查并固定版本，生产镜像可以提前缓存这个精确包。

十、这是不是 DeepSeek 官方插件市场里的插件？

目前 DeepSeek Harness 已提供 Bundle、Profile 和 dsh plugin add 安装机制，可以从 npm、GitHub、本地目录或 tarball 分发插件。

但截至本文事实基线，它没有一个经过官方审核、可在产品内浏览搜索的正式插件市场。当前社区发现入口主要是 GitHub 的 dsh-plugin Topic，以及 Harness 仓库 Discussions 中的 Show Your Plugins! 分类。

dsh-bailinghub 已发布到 npm、GitHub Release，并提交到社区 Discussion #3039。这说明它具备公开安装和社区发现入口，不代表 DeepSeek 官方认证、推荐或合作。

十一、当前实际验证到了哪里

当前已经验证的是：

• dsh-bailinghub@0.1.1 已公开发布到 npm；
• GitHub v0.1.1 Release 已发布；
• npm 发布具备 OIDC/SLSA 来源证明；
• 在干净的 DSH_HOME 中完成 Registry 安装；
• 在 DeepSeek Harness 0.1.0-rc.7 下完成 dump-config 配置展开 Smoke；
• 配置正确锁定 bailinghub-mcp-server@0.1.1、Server 名称和失败关闭选项。

当前尚未把下面这条链路记录为已验证：

Harness 内真实 submit
-> 保存同一个 job_id
-> wait / get 同一个任务
-> 获得 terminal result

也没有外部企业采用或生产运行证据。

因此，插件发布、社区 Discussion、安装成功和配置 Smoke 分别证明的是：

可以被发现
可以被安装
配置能够展开
集成方向可以公开讨论

它们还不等于：

已经完成全部业务 E2E
已经验证所有 Harness 版本
已经获得 DeepSeek 官方认可
已经有外部生产采用

这并不妨碍开发者开始使用，但第一次接入时应在自己的 BailingHub route 中完成真实任务验收。

十二、哪些场景值得尝试

这条路径比较适合：

• 团队已经有一套自托管 BailingHub；
• 订单、库存、工单或内部运营系统已经接入固定 route；
• 开发者或运营人员希望从本机统一发起任务；
• 任务可能需要审批、等待或后续查询；
• 不希望把业务系统密钥直接交给 Agent；
• 希望不同 Agent 入口复用同一套任务状态与 Trace。

它不适合：

• 希望插件自动继承任意网页里的登录状态；
• 希望模型自行选择租户、用户、角色或管理员 route；
• 希望一个插件自动治理 Harness 中安装的所有其他工具；
• 没有准备业务系统最终权限校验，却想直接开放高风险写操作。

当前 Bundle 只治理通过这三个 BailingHub 工具提交的任务，不会自动拦截 Harness 中安装的其他插件和工具。

十三、第一次接入建议先验证什么

不要一开始就选择退款、删除账号或批量修改库存。

可以先选择一条低风险、后果明确且容易核对的 route，并完成下面这组检查：

• Harness 展开的 MCP 配置只有预期版本；
• Client Token 只允许目标 route；
• Base URL 使用 HTTPS，或位于可信 TLS 终止边界后的受控私网；
• Token 没有进入提示词、三个业务工具的参数和截图；
• 同一 Harness Profile 的 Shell 或其他工具不能读取这份业务凭据；
• 模型不能修改 route；
• 一项任务只生成一个稳定 request_id；
• 等待超时后查询同一个 job_id；
• 需要主体的操作在主体缺失时被拒绝；
• 需要审批的操作不能由模型自行批准；
• 业务系统仍执行对象级、租户级和状态级最终授权；
• Harness、BailingHub Trace 与业务日志能够关联同一次任务。

正常路径跑通，只能说明连接可用。负向路径也能按照预期失败，才说明这条业务边界开始具备可审查性。

结语：插件增加的是入口，不是权限

DeepSeek Harness 让开发者可以在本机组织 Agent、插件和工具，这为真实业务系统增加了一个很自然的新入口。

但入口越方便，越需要把信任边界讲清楚。

dsh-bailinghub 提供的不是“让 Harness 获得业务后台管理员权限”，而是把一条固定、可配置、可追踪的任务通道装配到 Harness 中：

模型提出任务
-> 固定插件暴露受限工具
-> 固定 route 接收任务
-> BailingHub 协调任务、必要审批与派发
-> 业务系统保留最终授权

真正值得追求的不是“Agent 能调用多少接口”，而是：

当 Agent 开始影响真实订单、库存、工单和客户数据时，我们仍然能够回答：它代表谁、能做什么、谁批准了什么、是否重复执行，以及最终是谁允许这项业务后果发生。

如果你已经有一套 BailingHub 和一个接入完成的业务 route，可以先从低风险、可核验的任务开始安装验证。

如果你还没有建立可信身份、审批和业务最终授权链路，也不要急着把管理员 Token 交给模型。

先把边界建立起来，再让 Agent 真正走进业务系统。

项目与反馈入口

• DeepSeek Harness：github.com/deepseek-ai…
• BailingHub：github.com/bailinghub/…
• DeepSeek Harness 社区插件：github.com/bailinghub/…
• npm 包：www.npmjs.com/package/dsh…
• 社区 Discussion：github.com/deepseek-ai…
• 插件问题反馈：github.com/bailinghub/…