Zing Forum

Reading

OpenClaw Dynamic Workflow Plugin: Enabling Claude-Code Style Multi-Agent Parallel Orchestration

The openclaw-dynamic-workflow-plugin is a plugin developed for OpenClaw, supporting the orchestration of multiple isolated sub-agents to execute tasks in parallel via JavaScript scripts, enabling automated coordination of complex workflows such as codebase-level scanning and large-scale migrations.

OpenClaw工作流插件多智能体并行编排Claude CodeJavaScript插件架构AI工作流子智能体代码审计
Published 2026-06-08 07:45Recent activity 2026-06-08 07:51Estimated read 8 min
OpenClaw Dynamic Workflow Plugin: Enabling Claude-Code Style Multi-Agent Parallel Orchestration
1

Section 01

Introduction / Main Floor: OpenClaw Dynamic Workflow Plugin: Enabling Claude-Code Style Multi-Agent Parallel Orchestration

The openclaw-dynamic-workflow-plugin is a plugin developed for OpenClaw, supporting the orchestration of multiple isolated sub-agents to execute tasks in parallel via JavaScript scripts, enabling automated coordination of complex workflows such as codebase-level scanning and large-scale migrations.

3

Section 03

Project Overview and Background

In the development of AI-assisted programming tools, the limitations of single-turn conversations have gradually become apparent. When dealing with complex tasks that span multiple files and steps (such as codebase-level refactoring, security audits, and large-scale migrations), the traditional turn-by-turn interaction model struggles to coordinate effectively. Tools like Claude Code were the first to introduce the workflow concept, allowing agents to autonomously orchestrate multiple subtasks.

The openclaw-dynamic-workflow-plugin brings similar capabilities to the OpenClaw ecosystem— as a plugin rather than a core branch, it allows OpenClaw agents to write JavaScript orchestration scripts, distribute work to multiple isolated sub-agents via runtime execution, and finally aggregate the results to return to the user.


4

Section 04

Plugin-Based Architecture

Unlike directly modifying the OpenClaw core, this project is implemented as a plugin. This design offers several advantages:

  • Independent Evolution: The plugin can iterate quickly independently of OpenClaw core versions
  • Optional Installation: Users can enable it on demand without affecting basic functionality
  • Low-Risk Integration: Issues are isolated at the plugin level, not affecting the stability of the main system
  • Community-Friendly: Lowers the contribution barrier, allowing developers to focus on workflow logic itself
5

Section 05

Isolated Execution Model

The core of the workflow lies in the isolated execution of sub-agents. Each subtask runs in an independent OpenClaw sub-session, which means:

  • Errors do not cascade to affect other subtasks
  • Intermediate results are stored in script variables, and the main conversation only receives the final answer
  • Parallel execution fully utilizes resources and improves efficiency
  • Clear security boundaries facilitate permission control

6

Section 06

Workflow Process

The entire workflow execution process can be summarized in the following steps:

  1. The user submits a request requiring workflow processing to the OpenClaw assistant (e.g., "Audit permission checks for all route files using a workflow")
  2. The agent writes a JavaScript orchestration script and invokes the workflow tool (user approval is required before execution)
  3. The workflow runtime executes the script in a VM-isolated JavaScript environment
  4. Generate a real OpenClaw sub-session via the agent() call
  5. Use parallel() or pipeline() to achieve parallel fan-out (up to 16 concurrent tasks)
  6. Results are aggregated into script variables
  7. Progress is displayed in real time via tool cards (supports TUI/WebChat/IM interfaces)
  8. The final coordinated answer is returned to the user's main conversation
7

Section 07

Runtime Environment

Scripts run in a Node.js VM context, with carefully designed available primitives injected:

Primitive Behavior Description
await agent(prompt, { schema?, label? }) Generates an isolated sub-agent and returns the final text. Supports TypeBox/JSON Schema validation; retries up to 2 times if validation fails
await parallel([() => agent(...), ...]) Barrier synchronization: All start, resolve after all complete, order preserved, returns null on failure
await pipeline(items, stage1, stage2, …) Barrier-free stream processing: Each item flows through all stages independently; stages receive (prevResult, originalItem, index)
phase(name) Opens a named phase; subsequent agents are grouped under this phase (for progress display and Canvas tree)
log(message) Sends a progress log line
args Input data provided by the caller
budget Token budget object { total, spent(), remaining() } with hard upper limit
8

Section 08

Security Model

The security design uses a multi-layered strategy:

  • Speed Barrier Layer: VM isolation prevents direct import/require/fs/shell/network access, but this is only a speed barrier, not a security boundary (node:vm can be escaped)
  • Trusted Author Layer: Relies on trusted authoring agents to generate secure scripts
  • Approval Gating Layer: All workflow executions require explicit user approval before running

The actual protection comes from this combination: trusted authors + user approval gating.