@local/deepseek-bot-army
Deepseek Bot Army — 为 DeepSeek Harness 提供拥有自己电脑的全天候 AI 队友：名册、群聊、@提及、审批、记忆、例程和心跳唤醒。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:tyxt-zvid/deepseek-bot-army#fc75baac287ef729e723084be6bffce0a99e0048Deepseek Bot Army 以 @local/deepseek-bot-army 发布，当前版本为 0.9.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
An always-on roster of AI teammates inside the DeepSeek Harness Web UI. Each Bot has a name, a job and its own computer; you message Bots like colleagues, hand them work, and come back when your approval is needed.
How the product works:
Every reply on the panel is a real Harness Session: an agent run with the Harness tools, real files, and a durable session log.
The first public test build of Deepseek Bot Army for DeepSeek Harness. It ships the feature set described below through v0.8.0 — approval-first execution, memory and routines, @ mentions, the per-chat team roster and heartbeat wake-ups — plus the Workspace Hub integration.
0.9.0This is a test release: expect rough edges, and the GUI/manual QA paths listed in Notes still need a human pass.
A Bots entry in the global sidebar opens the panel:
Approve / Request changes / Dismiss).@Bot routes a message to one teammate, @everyone wakes the team,
and a Bot can hand work to another with HANDOFF: @Name — ….@ (or press the @ button) to open a Bot picker, filter by
name, tag teammates with ↑/↓ + ↵ (or Tab), and close with Esc. Tagged Bots become removable chips above
the input and highlighted mention chips in the transcript; @everyone is offered in group chats.MEMORY: line; edit or delete entries.This bundle is designed to cooperate with the Workspace Hub plugin
(@local/dsh-workspace-hub), which owns a cross-conversation task board:
workspace_task tool sees the same board as the user's other
conversations. Deliverables still go to the shared computer folder; the board is the shared ledger.
Bind it in Bot settings → Workspace (leave empty for an isolated Bot).[Bot name] title), with status mapping
queued→todo, working→doing, review→blocked ("Deepseek Bot Army: ready for your review"),
done→done ("Approved in Deepseek Bot Army"), failed→blocked. The board is the cross-session
ledger; Deepseek Bot Army stays the execution/approval surface. Mirror failures never block a run.dispatch addressed to a Bot's session is surfaced in the
Bots panel as a "Dispatched via Workspace Hub" task with its own review gate, even though this
plugin did not start the turn.End-to-end this makes both directions work: board task → dispatch to a Bot session → the Bot reads/updates the same board task, writes its deliverable, and comes back for your approval in the Bots panel; and Bot Army panel tasks appear on the board for other conversations.
See docs/workspace-hub-integration.md for the coexistence study,
the runtime evidence and the integration roadmap.
| Deepseek Bot Army concept | Harness implementation |
|---|---|
| Bot | A durable Harness Session created through the Session controller, with a persona prompt |
| Bot's computer | One shared directory, $DSH_HOME/deepseek-bot-army/computer |
| Message thread | Plugin store ($DSH_HOME/deepseek-bot-army/state.json) with the Bot's Session as the long-running context |
| Task / approval | Plugin task record moving queued → working → review → done; nothing is auto-approved |
| Memory | MEMORY: control line parsed out of the reply, stored on the Bot, injected into its next prompt |
| Handoff | HANDOFF: @Name — … parsed out of the reply, creates and starts the teammate's task |
| @mention | Composer picker sends mentions: [botId…] with the message; the host resolves it against the chat's members, with typed @Name text as fallback |
| Routine | Per-Bot steps saved by "Teach a task", injected into every prompt and runnable on demand |
| Skill | Shared library injected into every Bot's prompt |
| Activity line | session/event tool/call mapped to verb labels |
| Streaming | agent/assistant-stream text deltas, with durable assistant/message as the final text |
Host/client communication is a same-origin JSON API under /deepseek-bot-army/api (guarded by the Harness
Connection service), which keeps the bundle plain JavaScript with no build step and no Client package
imports.
Deepseek Bot Army is distributed through the ZVID Plugins market index:
Install from the repository with the DSH plugin CLI:
dsh plugin --profile desktop add https://github.com/tyxt-zvid/deepseek-bot-army
Or install a release tarball (for example deepseek-bot-army-0.9.0.tgz):
dsh plugin --profile desktop add ./deepseek-bot-army-0.9.0.tgz
The bundle is named @local/deepseek-bot-army. It inserts the deepseek-bot-army Host row through
cordis.patch.yml and registers the sidebar entry and the main panel from client.js. If the panel
looks stale after an update, reload the Harness window once so the browser picks up the newest client
module (the Client HMR receiver usually reloads it automatically).
To work on the plugin itself, clone the repository and link that checkout as the bundle
@local/deepseek-bot-army in your Harness profile (install against the checkout directory rather than
a published version). The plugin stays plain JavaScript with no build step; npm test runs the
host-side test suite.
The plugin is built on Harness primitives, so some behaviours are deliberately substituted:
docs/approval-model.md).The Bots panel now implements the Apple HIG version generated by Open Design. Source and spec: docs/design-apple/.
bots-workbench.html — 156 KB single-file prototype with Light / Dark appearances, the full window shell, four views and two sheets.DESIGN.md — dual-appearance tokens, SF typography, 8pt rhythm, component and HIG rules.README.md — OpenDesign project id, skill / design-system binding, implementation notes and component mapping.The plugin keeps the existing data/actions, scopes the design CSS under .gpb-root, follows the Harness theme through useHostTheme(), removes the fake macOS window frame (the Host already provides one), and maps the design's sidebar, segmented controls, grouped lists, approval card, context panel, pages and sheets onto the live team state.
Historical: the earlier Linear-style design remains in docs/design/; it is no longer the rendered UI.
v0.5.0 introduces the action-level approval model:
lib/classify.js classifies each message as chat / task and returns needsConfirmation when it cannot tell. Uncertain messages render a confirmation card (派成任务 / 只是聊天 / 暂不处理) instead of guessing.tools/pre-execute and surface an action approval card with Allow once / Always allow / Deny. Read-only tools pass; grants persist per Bot and tool.ask-first (default) or allow-all, with per-tool Always-allow grants. Approvals for unattended work expire after 10 minutes; group chats never show approval cards.done; no post-hoc task review for new tasks.See docs/approval-model.md for the full model and known limitations.
v0.6.0 adds the next layer on top of the approval model:
lib/classify.js: refineIntentWithModel) decides chat/task. A timeout, missing model, or malformed answer falls back to the confirmation card.TEAM_MEMORY: or by the user in the Memory panel.nextRunAt, per-routine run records (last 20), failure counters and automatic pause after three failures.The dialog supports @ to mention/tag a specific Bot, so a message can address one teammate instead
of the whole group:
@ opens a list anchored above the input with the members of the current chat
(plus @everyone for group chats). Continue typing to filter by name or label, move with ↑/↓, insert with
↵ or Tab, dismiss with Esc or a click. The @ button in the composer bar opens the same picker at the caret.@Name token from the
draft. A chip appears for hand-typed mentions too, so the tagged set is always visible before sending.@Name tokens are rendered as highlighted mention chips in your messages and in Bot
replies (including HANDOFF: @Name lines).mentions: [botId…] and mentionEveryone alongside the text,
and the host trusts those signals first (structured @everyone > tagged Bots > group lead). Only when
no structured signal arrives (legacy client, old message, hand-typed mention) does the host parse the
text: @everyone with a word boundary, then longest @Name first with a left boundary so
bob@Example.com and @Bot 2 are not misread.mentions array, and a pending intent keeps
mentions / everyone, so the Bot that answers after a 派成任务/只是聊天 confirmation still receives the tags.The message itself is still authored as @Name text, so the stored transcript stays readable outside the UI.
Host-side routing and persistence are covered by npm test (test/routing.test.mjs).
A Bot is an ordinary Harness Session, so the Harness list_agents tool only lists the subagents that
Bot started — it never sees the other members of the group chat. In practice a group-chat Bot asked
"how many Bots are here?" answered "only me", and a teammate that was standing right there had to
introduce itself.
Every Bot run now receives the chat's roster as part of its team context:
## Team roster — this group chat has N Bots, one line per member: name (label,
and you on the reader's own line) plus a one-line description. A 1:1 chat lists the whole team
instead, because those Bots are the valid HANDOFF: targets.list_agents only lists subagents.list_agents, the host appends the same roster to
the tool result, so a Bot that reaches for the tool still gets the team list instead of "no subagents".Covered by npm test (test/roster.test.mjs): group count/names, subset groups, 1:1 handoff targets,
and the roster's presence in the composed prompt for both chat kinds.
Bots still wake on messages, handoffs, routines and external dispatch, but an idle Bot with unfinished work now checks in with itself:
lib/heartbeat.js): an interrupted
task/message after a restart, an orphan working task with no run, or a dropped dispatch. No model
call happens unless one of these exists, so healthy idle Bots cost nothing.idle / wait / resume / ask_user — and its text is fenced as untrusted data.The panel exposes it in Bot settings (on/off, interval, quiet hours, daily caps), the
Heartbeat context-panel section (mode, next check, last verdict, today’s counts, Check now) and
in-thread check-in cards. The full design, state machine and P3/P4 roadmap (follow-up control
lines, broader candidates, adaptive intervals) live in docs/heartbeat-model.md.
| File | Role |
|---|---|
index.js | Host half: store bootstrap, the JSON API, action dispatch |
lib/store.js | Durable team store (bots, threads, tasks, skills, activity), atomic JSON writes, shared computer file access |
lib/runtime.js | Bot execution through the Session controller, live activity, memory/handoff parsing, heartbeat admission/preemption, task settlement |
lib/heartbeat.js | Heartbeat P2: deterministic triage, digest, pulse call/parser, claims, budgets, scheduler |
lib/templates.js | Marketplace catalog and first-run roster |
lib/mirror.js | Optional one-way mirror of Deepseek Bot Army tasks onto the Workspace Hub board |
client.js | Web half: sidebar entry, panel, all views, composer @ mentions and modals |
test/routing.test.mjs | Host-side tests for mention routing, text fallback and mention persistence |
test/heartbeat.test.mjs | Heartbeat tests: triage, digest/parser, claims/budgets/check-ins, engine and runtime resume/preemption |
test/roster.test.mjs | Host-side tests for the per-chat team roster injected into Bot prompts |
locale/*.json | Plugin display metadata |
@Same Name wakes every Bot that shares that name, because text alone cannot disambiguate.npm test covers mention routing plus the heartbeat slice (triage, claims,
pulse parsing, budgets/check-ins, engine resume, runtime full-effort resume, preemption, stale-claim
rejection); node --check covers all host/client files; the client module is smoke-loaded through a
stub window.__ModuleLoader__ plus a React stub, with CSS brace and en/zh DICT parity checks.
Live GUI/manual QA — restart recovery in the Harness window, real approvals and the mobile layout —
still needs a human pass; this environment has no browser control.@ routing, routine creation and manual run, skill creation, and marketplace bot creation;
plus the Workspace Hub integration: board task mirroring todo→doing→blocked→done, a Bot session
reading/updating the same board, and a Workspace Hub dispatch surfacing in the Bots panel for review.