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