dsh-plugin-qq-bridge-v3
DeepSeek Harness 的进程内 QQ 官方机器人桥接：QQ 消息可在宿主内部启动或恢复真实的 DSH 会话，并将结果发送回 QQ。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:tbb051122/dsh-plugin-qq-bridge#49b8129f0a500c3977b6f17f82991ac30a7c80acPlugin Qq Bridge V3 以 dsh-plugin-qq-bridge-v3 发布，当前版本为 0.1.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
Bridge an official QQ bot to DeepSeek Harness (DSH) — in-process.
A message in QQ starts (or resumes) a real DSH session inside the host process. The session shows up in the desktop app's sidebar, can be opened and continued there, and the answer goes back to QQ as text, image or file. QQ is just one more input/output for a normal DSH session.
| Separate bridge process | This plugin | |
|---|---|---|
| Task execution | spawns dsh --profile qq --json | ctx.agents.create() / resume() inside the host |
| Where sessions live | only in that CLI profile | the host's own session store (visible in the GUI) |
| Permissions | env vars on the child process | per-session permission preset |
| Lifetime | you keep start-bridge.cmd running | lives as long as the DSH host |
The QQ protocol layer (token, gateway, passive-reply budget, chunking, workspaces, chat history) is shared with the standalone bridge; only the execution side is different.
agents, agentDefaultModel, agentPresets, permissionPresets,
sessionTitle and workspaceRegistry services (the desktop app does).dsh plugin add github:tbb051122/dsh-plugin-qq-bridge
Then restart the DSH host — host-side plugin code is only loaded at startup.
Config lives at <DSH_HOME>/qq-bridge/config.json (~/.dsh/qq-bridge/config.json by default).
Set QQ_BRIDGE_HOME to point the whole plugin at another directory (handy for testing).
A minimal config:
{
"appId": "your-app-id",
"appSecret": "your-app-secret",
"intents": 33554432,
"defaultCwd": "",
"allow": { "users": [], "groups": [] }
}
See config.example.json for every key.
Keys that matter for the plugin:
| Key | Meaning |
|---|---|
appId, appSecret | QQ bot credentials (from the QQ open platform). |
sandbox | Use the QQ sandbox environment instead of production. |
intents | Message subscription bitmask; 33554432 is C2C messages, add the group bit for group chats. |
defaultCwd | Working directory for new sessions. Point it at a registered DSH workspace to have QQ sessions appear there; leave empty for an isolated directory per session. |
agentPreset | Agent preset name; empty means the host default. |
permissionPreset | danger-full-access (default, unattended), workspace-write or read-only. |
attachWorkspace | When defaultCwd is a registered workspace, attach the session to it so the GUI shows it. |
allow.users / allow.groups | OpenID allow-lists. Empty means "locked": use /bind <code> with bindCode to pair. |
maxConcurrent, queueLimit | How many agent runs at once, how many conversations may queue. |
passiveWindowMs | The passive-reply window QQ gives you after a user message. |
taskTimeoutMs | Per-task timeout. |
selfTestOnBoot | Run one end-to-end self test on first boot and post the result to QQ. |
titlePrefix | Session title prefix (default QQ). |
/help, /id, /bind <code>, /new, /status, /stop,
/ws (list workspaces), /ws <name|index>, /ws 0 (back to the default directory),
/history [n].
Everything the plugin writes lives under <QQ_BRIDGE_HOME> (default <DSH_HOME>/qq-bridge):
config.json, state.json (session map, allow-lists), history/ (per session and workspace),
workspaces/ (workspace link index), tasks/ (default task root) and logs/.
The default permissionPreset is danger-full-access so an unattended QQ task can actually do its job.
Set it to workspace-write or read-only if the bot is reachable by anyone you do not trust, and keep
allow.users limited to people you know.
node lib/cli.mjs --mock --once "hello" # full pipeline with a fake runner and fake QQ
node lib/cli.mjs --selftest # config / workspace / runner checks
Set QQ_BRIDGE_HOME to a scratch directory so the mock run does not touch real data.
MIT