Introduction

The core design philosophy of DeepSeek Harness is “everything is a plugin.” When building automated workflows, in addition to invoking Agents directly through conversation, you often also need to handle periodic tasks or external event triggers. Traditional Cron methods can only execute predefined scripts at fixed times and lack intelligent decision-making and autonomous processing capabilities.

dsh-reactor is an event-driven autonomous Agent runtime for DeepSeek Harness. It transforms an Agent from an “on-call assistant” into a “daemon that proactively senses the environment and autonomously accomplishes goals.” By defining event sources, condition evaluation, and goals through plugins (the ECG pattern), it allows the LLM to continuously observe the environment in the background. Once the conditions are met, it launches an isolated Session and uses the ReAct mechanism to autonomously complete the task.

Plugin Overview

  • Positioning: An event-driven autonomous Agent runtime (ECG) for DeepSeek Harness.
  • Developer: snhna-a.
  • Category: Workflow.
  • Core value: Replaces fixed-time scheduling with event-driven execution, enabling the Agent to autonomously perceive changes and perform tasks in the background.

Installation and Activation

This plugin is provided as a community contribution and is not an official DeepSeek product. Before installing, please ensure that your DeepSeek Harness version meets the requirement (≥ 0.1.2-rc.1).

  1. Run the following command to install the plugin:
dsh plugin --profile web add dsh-reactor
  1. After installation, restart the dsh web service.

  2. A clock-themed visual widget will appear in the bottom-right corner of the DSH Web interface. You can drag it to adjust its position or click it to open the management panel and check the rule status.

Core Features

dsh-reactor provides a complete event-handling and Agent-execution mechanism:

  • ECG runtime: Upgrades traditional ECA (Event-Condition-Action) to ECG (Event-Condition-Goal). After an event occurs, the condition is evaluated first to decide whether the Agent should be launched.
  • Multiple event sources: Supports obtaining external or local events through http-poll (polling), file-watch (file monitoring), command (command execution), and webhook (push reception).
  • Condition evaluation: Uses JSONPath to extract data, combined with operators (eq/ne/gt/contains/exists/changed) and logical composition (AND/OR) to determine whether an event should trigger.
  • Goal mode: This is the recommended execution method. It runs in an isolated Agent Session. The LLM receives the goal description and event context, then uses the ReAct mechanism to autonomously decide how to complete the task (such as reading files, running commands, or calling tools).
  • Deterministic verification: After the task completes, the system automatically performs verification (such as checking file existence or command exit code). Only verification success is considered a successful task.
  • Intelligent recovery: The system includes a failure classification mechanism that can identify error types such as transient (temporary faults) and repairable (fixable issues), and automatically retries.
  • Auditability: Provides a full execution trace, recording the decision chain, Token consumption, and execution details for each trigger.

Typical Usage

After installation, you can directly define rules in DSH conversations using natural language. The Agent will automatically call tool interfaces such as reactor_define to create background rules.

The following are typical scenarios based on the plugin’s feature description:

  1. Monitor GitHub commits and automatically pull and build when HEAD changes:

    “Help me monitor the latest commit at https://api.github.com/repos/snhna-a/dsh-reactor. When HEAD changes, run git pull in the C:\work\dsh-reactor directory to get the latest code, then run npm run build, and tell me the result.”

  2. Monitor local configuration file changes and trigger a notification:

    “Monitor the deploy.json file. When the version field changes, send a webhook notification.”

  3. Periodically analyze code changes:

    “Run git log --oneline -1 every 5 minutes. When the output changes, analyze this commit in a new session.”

  4. Proactively diagnose and repair errors:

    “Poll and monitor a website’s API. When the status becomes error, let the Agent automatically diagnose and repair it.”

Security and Precautions

  • Permission control: In Goal mode, use the permissionPreset parameter to control the Agent’s capability boundaries and prevent it from performing unexpected operations.
  • Data storage: All rules and historical data are stored locally under the ~/.dsh/reactor/ directory and are not uploaded to third-party servers.
  • Webhook security: By default, the Webhook listens only on the local loopback address. If you need to expose the service externally, you must configure webhookToken and use TLS encryption.
  • Shell execution: The plugin executes commands within the DSH runtime environment and trusts only rules created by you. It is recommended to carefully review rule content before executing Shell actions.