dsh-office-cli：用一个 DSH 工具安全暴露 WeCom、DingTalk、飞书的官方办公 CLI

前言¶

如果你在 DeepSeek Harness（DSH）上做过智能体，大概率遇到过这类需求：让智能体发一条企业微信消息、查一下飞书文档、建一个钉钉审批。官方 CLI 都有这些能力，但让模型直接进 shell 执行命令，意味着认证命令、凭据参数、任意路径都暴露在模型面前，权限边界很难控。

下面介绍 dsh-office-cli，一个把 WeCom、DingTalk、Feishu/Lark 三个官方办公 CLI 通过单个原生 DSH 工具安全暴露出来的插件。

这是什么¶

dsh-office-cli 由 meliwanx 维护，MIT 许可证，当前版本为 0.1.0。它是一个 outbound（出站）办公能力插件，不是又一个 chat-to-agent 桥接器：它让 DSH 智能体操作消息、联系人、文档、表格、日历、会议、任务、审批、邮件等厂商支持的办公服务，而认证、API 发现与兼容性仍由官方 CLI 负责。

需要注意，README 声明当前目标是 DeepSeek Harness 0.1.0-rc.7，仍处于 Developer Preview 阶段。

核心功能¶

插件包含以下几部分：

1、office_cli：对 wecom、dingtalk、feishu 三个官方 CLI 进行免 shell 的 argv 级执行，模型不需要拿到 shell 就能调用子命令。

2、office_cli_doctor：只做版本可用性检查，不读取凭据。

3、dsh-office：终端侧的 doctor 与交互式认证助手。

4、内置 DSH Skill：支持渐进式 schema 发现与 dry-run 优先的变更操作。

安全机制方面，插件默认拦截认证、配置、升级、监听类命令，拦截凭据参数、raw API 模式以及逃逸 workspace 的路径；写操作、破坏性操作与未知命令则需要 DSH 一次性批准。凭据保留在各厂商 CLI 自身的 keychain 或加密存储中，面向模型的工具不接受认证命令或含密钥的标志。

三个平台对应的官方 CLI 与认证入口如下：

平台	官方 CLI	认证
WeCom	`@wecom/cli`	`wecom-cli auth init`
DingTalk	`dws`	`dws auth login`
Feishu/Lark	`lark-cli`	`lark-cli config init && lark-cli auth login --recommend`

安装与启用¶

要求 Node.js >=22.19 与 DeepSeek Harness。安装分两步：

dsh plugin --profile web add github:meliwanx/dsh-office-cli
dsh plugin --profile web exec dsh-office install

第一条命令安装插件本身。插件包不含安装脚本，第二条显式命令才安装固定版本的官方 CLI，安装到 $DSH_HOME/office-cli，供所有 DSH profile 共享，并与全局 npm 隔离。

如果只需要单一平台：

dsh plugin --profile web exec dsh-office install wecom
dsh plugin --profile web exec dsh-office install dingtalk
dsh plugin --profile web exec dsh-office install feishu

也可以不走安装助手，把官方 CLI 装到 PATH 或作为相邻 profile 依赖。CLI 解析顺序为：显式插件配置 → $DSH_OFFICE_HOME / $DSH_HOME/office-cli → 相邻 npm 包 → PATH。

安装后先做诊断，再启动 DSH：

dsh plugin --profile web exec dsh-office doctor
dsh --profile web --dump-config
dsh --profile web

认证与配置¶

认证走终端侧助手，凭据留在各厂商 CLI 自己的存储里：

dsh plugin --profile web exec dsh-office auth wecom
dsh plugin --profile web exec dsh-office auth dingtalk
dsh plugin --profile web exec dsh-office auth feishu

需要调整默认配置时，在 profile 的 cordis.patch.yml 中重写 id 为 dsh-office-cli 的 bundle 行，并完整重述其配置：

- id: dsh-office-cli
  config:
    approval: writes       # writes | all | off
    timeoutMs: 120000
    killGraceMs: 2000
    maxOutputBytes: 262144
    maxArgs: 128
    maxArgLength: 65536
    allowRawApi: false
    workspaceFilesOnly: true
    # wecomCommand: /opt/bin/wecom-cli
    # dingtalkCommand: /opt/bin/dws
    # feishuCommand: /opt/bin/lark-cli

approval 控制哪些操作需要批准，默认 writes；allowRawApi 默认关闭；workspaceFilesOnly 默认开启。如果官方 CLI 不在默认位置，可用 wecomCommand / dingtalkCommand / feishuCommand 显式指定路径。

适用场景与注意¶

0.1 版本聚焦 DSH → 办公平台方向。入站聊天频道需要长连接、持久的聊天/会话映射、重放保护、远程审批和媒体流，README 明确说明这些属于未来独立的 channel-* 插件范畴，不在这套前台 CLI 工具里做。如果你要找的是“把 IM 接进智能体当入口”，这个插件不解决那个问题；如果你要的是“让智能体主动去操作办公平台”，它是对口的。

安全上有两点务必清楚：

1、workspaceFilesOnly 只是参数级防御，不是 OS 沙箱。高安全部署建议使用专用容器/账号与最小权限的厂商应用，详见项目的 SECURITY.md。

2、插件以当前 dsh 进程的权限运行，官方 CLI 安装到共享目录并与全局 npm 隔离，但它仍能访问当前用户能访问的资源。安装前建议检查源码与许可证——插件本身是 MIT，由安装助手拉取的各官方 CLI 是独立软件，许可证各自独立，见项目内 THIRD_PARTY_NOTICES.md。

本地开发流程：

npm install
npm run check
dsh plugin --profile web add .

结尾¶

dsh-office-cli 的思路很克制：不重新实现厂商 API，只做一层带默认拦截与审批机制的 argv 级暴露，认证和兼容性留给官方 CLI，安全边界交给 DSH 的批准流程。如果你正想让 DSH 智能体安全地使用 WeCom、DingTalk 或飞书，可以看一下。

目录页：https://www.skillhub.cn/plugins/meliwanx/dsh-office-cli
GitHub：https://github.com/meliwanx/dsh-office-cli