DeepSeek Harness插件dsh-im：扫码接入微信飞书

主要功能

• 多渠道支持：统一管理9种IM渠道，包括飞书、微信、钉钉、企业微信、QQ、Slack、Telegram、Discord 和 WhatsApp。
• 多机器人管理：每个渠道都支持接入多个机器人，且每个机器人的连接状态、工作区和会话绑定都是独立的。
• 统一接入方式：支持通过扫码、App Manifest或输入已有机器人凭据（如Token、Secret等）来接入机器人。
• AI Office Connector：此功能让你的本地Harness无需公网IP或端口转发，即可主动连接公网的AI Office。

安全设计

• 凭据保护：所有 Secret 和 Token 只会提交给本机 Harness Host，并写入受保护的凭据存储，不会被插件回传。
• 权限控制：任何能向机器人发消息的用户都可以执行这些命令，因此建议将机器人限制在可信用户范围内。

机器人命令
在与机器人的聊天中，你可以发送以下命令进行控制（发送 /help 可随时查看完整列表）：

• 会话管理：
  • /new：开启一个全新的Harness会话。
  • /session ：将当前聊天绑定到指定的已有会话。
  • /workspace <路径>：切换当前机器人的工作区。
• 模型与预设：
  • /models：列出所有可用模型。
  • /model <序号或ID>：切换当前会话使用的模型。
  • /presetlist / /preset：列出或切换当前机器人的 Agent Preset。
• 任务控制：
  • /stop：立即停止当前正在运行的任务。
  • /steer <指令>：为当前运行的任务添加补充指令。
  • /compact：压缩当前会话的早期上下文。

介绍

DeepSeek Harness 必须接入你的微信和飞书，否则它就是个摆设！

dsh-im这个插件做的事情，一句话就能说清楚：通过扫码、App Manifest或已有机器人凭据，把IM机器人接入DeepSeek Harness。九个渠道——飞书、微信、钉钉、企业微信、QQ、Slack、Telegram、Discord、WhatsApp——一个插件、一个设置入口，统一管理。

注意一个关键点：每个IM渠道都支持接入多个机器人。什么意思？你可以在微信里接一个机器人专门处理代码审查，在飞书里接另一个机器人专门处理项目管理，在钉钉里再接一个处理日常问答。各机器人的连接状态、工作区和会话绑定彼此独立。一个Harness后端，驱动无数个IM前端——每个前端都有自己的身份、自己的工作目录、自己的对话历史。

但这里有一个认知翻转：你以为是“把AI接入IM”，实际上是“把IM接入AI”。Harness是核心，IM只是它的一个输入输出通道。你在微信里发一条消息，这条消息经过插件路由到Harness，Harness调用模型、执行工具、生成回复，再经过插件推回到微信。整个过程，Harness根本不知道自己是在跟微信还是飞书对话——它只知道自己在处理一个会话。

对吗？

你的电脑没有公网IP，AI怎么找到你

这是最反常识的地方。大多数IM平台的机器人需要你的服务有一个公网可访问的地址，平台才能把用户消息推给你。但你的开发电脑在公司内网、在家里 WiFi 后面，没有公网IP，也没有域名。

dsh-im解决这个问题的办法是“AI Office Connector”——让本机Harness主动连接公网Office，本机无需公网IP、端口转发或WebSocket服务。流程是这样的：你的Harness主动向公网的Office服务发起连接，建立一条长连接通道。IM平台把消息推给Office，Office通过这条通道把消息下发给你的Harness。反过来，Harness的回复也通过同一条通道上行到Office，再转给IM平台。

这就相当于你的电脑主动打了一个电话出去，然后一直保持通话。对方（Office）随时可以通过这个电话告诉你“有人找你”，你再通过这个电话回答。不需要你的电脑有任何可以被外界访问的入口。

这个设计的精妙之处在于“连接测试”的校验逻辑：Heartbeat成功响应必须是{"ok":true,"protocolVersion":"office-harness.v1"}。这意味着“连接测试通过”代表命中了兼容的Office Connector，而不只是某个碰巧返回200的网址。一个细节，暴露了整个架构对安全性的偏执。

但事情还没完。

你的聊天机器人能看见你电脑上的所有文件，你怕不怕

这是一个必须直面的问题。你把一个AI接进了微信，这个AI背后连着Harness，Harness能访问你的文件系统、执行终端命令、调用各种工具。任何一个能给你发微信的人，理论上都能通过这个机器人操控你的电脑。

dsh-im的安全设计围绕一个核心原则：凭据不离开本机。所有Secret和Token只提交给本机Harness Host，并写入受保护的凭据存储；状态接口和机器人列表不会回传这些凭据。浏览器只获得二维码、Manifest、脱敏状态。手动输入的Secret或Token仅单向提交给本机Host，任何RPC响应都不会返回App Secret、bot_token、client_secret、各种Token或设备密钥。

但这是技术层面的防护。真正有意思的是权限模型的设计：任何已在对应平台可见范围内、能够正常向机器人发消息的用户都可以执行这些命令，不区分管理员和普通用户。这意味着什么？意味着你的微信机器人只要被拉进了一个群，群里每个人都能用/workspace切换工作目录、用/session绑定任意会话、用/preset切换Agent配置。

dsh-im的应对策略是：不设防，但把所有风险摆在明面上。文档里写得很直白：“请只向可信用户开放机器人”“会话ID和标题可能属于其他机器人、其他渠道或非IM项目，并可能包含敏感元数据。开放命令前请确保所有可见用户都可信。”

这就怪了——一个把安全性写到这个程度的项目，权限模型却这么“开放”。这到底是漏洞还是设计？

你在群里发/stop，AI真的会停下来吗

dsh-im提供了一套完整的机器人命令体系。/new开启全新Harness会话，/session绑定到指定的已有会话，/workspace切换工作区，/model切换模型，/preset切换Agent Preset，/stop立即停止当前运行的任务，/steer给运行中的任务补充指令，/compact压缩早期上下文。

这些命令的设计有一个共同特征：它们操作的是“当前聊天”的绑定关系，而不是直接操作Harness的底层状态。/new只解除当前聊天在插件中保存的会话绑定，不会删除、清空或归档旧Session。/stop只控制当前聊天自己发起的运行任务，即使多个聊天绑定同一个Session，也不会有意控制其他聊天的任务。/preset修改是机器人级配置，会影响该机器人所有聊天以后创建的新Session，但不会修改、停止、解绑或重建已有Session。

这个设计解决了一个分布式系统里的经典难题：多个入口（多个聊天会话）共享同一个后端资源（一个Harness Session）时，谁有权力控制谁？答案是：每个入口只能控制自己发起的那条线。

但这里面藏着一个更大的问题：/session可以让你绑定到任意已有的Harness会话。这意味着你可以接续别人发起的一个任务，继续往里面写消息、触发工具。一个任务可能被多个人接力完成——也可能被多个人同时干扰。

这对吗？

九种IM，九种脾气，一个插件全搞定

每个IM平台的接入方式完全不同。飞书用App ID加App Secret，微信扫码走腾讯iLink长轮询，钉钉用Client ID加Client Secret走Stream长连接，企业微信扫码走官方WebSocket，QQ扫码走WebSocket，Slack填两个Token走Socket Mode，Telegram填Bot Token走长轮询，Discord填Bot Token走Gateway长连接，WhatsApp扫码关联设备走Web长连接。

每个平台的回复方式也不同。飞书用流式卡片显示思考、工具进度和回答。钉钉用AI Card流式显示。企业微信原生显示“正在思考中”。QQ私聊显示“正在输入”。Slack优先使用官方流式消息API。Telegram通过编辑消息流式显示。Discord通过编辑消息流式显示。WhatsApp显示已读和“正在输入”。

插件在底层抽象出一套统一的会话和消息模型，然后在每个渠道的适配器里把统一模型映射到平台的原生能力。不支持原生流式的平台，就用编辑消息、卡片更新或最终消息来完成。

九个内置渠道还有一个统一能力：全部支持把JPEG、PNG、WebP图片，以及以图片文件方式发送的GIF，连同可选文字说明发送给Harness。单张图片上限5MB，单条消息总上限20MB。结合2026年8月19日DeepSeek Harness发布的v0.1.0-rc.8版本新增的图片输入能力，你可以在微信里直接发一张架构图给机器人，让它分析、修改、生成代码——全程不用离开聊天界面。

这就把“AI助手”从“命令行工具”变成了“群聊成员”。

但你的机器人真的认识你吗

Telegram渠道有一个特殊设计：每个机器人都可以在自己的卡片中切换访问模式——兼容模式和安全模式（私聊白名单）。兼容模式下，私聊直接响应，群聊仅在提及机器人或回复机器人消息时响应。安全模式下，机器人忽略全部群聊，只接受白名单中的数字User ID。白名单每行一个ID、按机器人独立保存。切回兼容模式时会保留但不使用白名单，再切回安全模式即可继续使用。安全模式的空白名单会拒绝该机器人的所有入站消息。

这个设计暴露了一个更深层的问题：IM机器人不知道自己是在跟“谁”对话。它只知道有一个消息进来了，消息里有一个用户标识。在微信里，这个标识可能是一个OpenID；在飞书里可能是一个User ID；在Telegram里可能是一个数字ID。这些标识在不同的平台、不同的机器人之间完全割裂。

你可以在微信里跟机器人聊了一半，转到飞书继续聊同一个话题吗？不能。因为机器人不认识你——它认识的是你在微信里的那个OpenID和在飞书里的那个User ID，它不知道这两个ID是同一个人。

dsh-im的解决方案是：通过/session命令手动绑定。你在微信里发起一个任务，拿到Session ID，然后在飞书里发送/session 那个ID，把飞书聊天绑定到同一个会话。这样你就能在微信里开始一个任务，在飞书里继续，在钉钉里收尾——只要你知道那个Session ID。

但这需要你手动操作。理想的情况应该是：机器人自动识别“这是同一个人”，跨平台无缝衔接。但IM平台不提供统一的身份认证机制，这个问题短期内无解。

一个插件，改变了你使用AI的方式

回顾一下整个逻辑链条。DeepSeek Harness提供了一个强大的智能体运行框架——但它活在命令行里。dsh-im这个插件做的事情，是把Harness的能力通过九种IM渠道释放到你的日常沟通工具里。你不需要打开终端，不需要记住命令，不需要盯着屏幕等输出——你在微信里发一条消息，AI在后台干活，然后把结果推回给你。

这个转变的实质是：AI从“你需要主动去找它”变成了“它就在你身边”。你不需要切换上下文，不需要中断 workflow，不需要离开你正在做的事情。AI变成了你聊天列表里的一个联系人，跟你的同事、朋友、家人并列。

但代价是什么？代价是你的聊天机器人能看见你电脑上的所有文件，能执行任意终端命令，能调用各种工具。任何一个能给你发消息的人，理论上都能通过这个机器人操控你的电脑。dsh-im把选择权交给了你——你可以选择只接入可信的IM渠道，只把机器人放在私聊里，只用白名单限制访问。但Harness本身不提供用户认证和权限分级，插件也不试图在Harness之上叠加一套权限系统。

这就回到了最开始的那个矛盾：你把一个强大的工具放进了最日常的环境里——便利性和安全性之间的张力，至今没有完美的解决方案。

2026年8月22日，dsh-im的GitHub仓库最后一次提交记录显示，开发者还在修复微信的Harness访问错误。这个插件还在演进，九种IM渠道的适配还在完善，AI Office Connector的协议还是v1。事情远没有结束。