dsh-plugin-monitor
DeepSeek Harness 的事件监视器——监控后台进程和 WebSocket 流，其输出行会将代理唤醒为异步事件。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add dsh-plugin-monitor@0.1.1Plugin Monitor 以 dsh-plugin-monitor 发布，当前版本为 0.1.1。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
An event monitor for DeepSeek Harness: arm a background watch — a shell command or a WebSocket — and every stdout line (or text frame) is delivered to the owning agent session as an asynchronous event. The agent keeps working or goes idle; inference happens only when something actually arrives.
Modeled on Claude Code's Monitor tool. The motivating use case is real-time agent-to-agent
messaging (e.g. Grapevine channels), where the alternative — a timed self-wakeup loop — costs a
model turn per empty poll and adds up to a full interval of latency per message.
Working, and verified end to end. A DeepSeek Harness agent has held a live conversation over a
grapevine channel through this plugin — woken per message without polling, with batching, labels,
and job_kill all confirmed against a real dev profile. See the acceptance scenario and its
result in docs/design.md.
The dsh background-job runtime (ctx.jobs) already owns job ids, cancellation, incremental
reads (readOutput() / job_output), and wake-on-completion for an idle owner. Separately,
agent.inject() appends context to the next model request — explicitly not a wake-up.
This plugin extends that from completion-only to per-output event. Delivery is
agent.send(event, 'next-step', true) — the runtime's waking send, which folds an event into
ongoing work and opens a turn when the owner is idle. The registry has no per-output
notification and needs none: the producer owns the stream in-process. Around that sit the
operational details that make it survivable:
job_killBun + Biome for local development (the published package is plain JS in dist/, so this is
invisible to consumers):
bun install
bun run build # tsc → dist/
bun run check # biome
Install into a dsh profile from a local checkout — note dsh plugin add forwards to pnpm
on the consumer side, and git installs need the prepare script allowlisted in the consumer's
pnpm-workspace.yaml; neither constrains this repo's own tooling:
dsh plugin --profile dev add /path/to/dsh-plugin-monitor
Add it to the profile you actually boot — the web UI runs the web profile, so installing
into dev and then launching the web UI is a correct command aimed at the wrong target. Verify
before launching:
dsh --dump-config | grep monitor
Optional. The defaults are the policy for almost everyone; override only if a
source legitimately needs more headroom, as a config: block on the profile entry:
- id: monitor
name: dsh-plugin-monitor
config:
maxEventBytes: 32768 # bytes in one delivered event (default 16 KiB)
throttleBytes: 262144 # bytes per 10s before throttling (default 128 KiB)
killBytes: 1048576 # bytes per 10s before the monitor is stopped (default 512 KiB)
spillBytes: 524288 # capacity for event-clipped output (default 256 KiB)
Config is validated at load, so a mistyped budget fails the boot rather than the
first overflowing event. Output clipped from an event is recoverable with
job_output <id>; the event says how many bytes were delivered and which spill
block holds the rest.
A symptom worth recognising, because it looks like this plugin and is not:
Cannot read properties of undefined (reading 'prepare')
Every tool call in the profile fails, including ones unrelated to this plugin. It means two copies
of @deepseek-ai/dsh-tools are loaded: its dispatcher is keyed by a module-local Symbol(), so
the copies cannot see each other's scheduler. This is a known upstream issue —
deepseek-harness discussions #1849,
#3033,
#2078.
This package declares no runtime dependencies precisely to avoid causing it. If it happens anyway, check for a rival copy and remove or link it:
ls $DSH_HOME/profiles/<name>/node_modules/@deepseek-ai
It is most likely when the harness is installed globally rather than under $DSH_HOME.
src/index.ts — plugin entry (name, inject, apply); registers the monitor tool and
the system-prompt section that tells the model events arrive unpromptedsrc/events.ts — batching, rate limiting, and waking delivery to the owning agentsrc/command.ts — shell-command producer (own process group, so cancel kills pipelines)src/websocket.ts — WebSocket producer (one event per text frame)src/lines.ts — line splitting across chunk boundariescordis.patch.yml — configuration layer applied when the bundle is added to a profiledocs/design.md — design notes and open questions