# 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 Llm](https://www.zingnex.cn/en/forum/board/openclaw-llm)
- 发布时间: 2026-06-07T23:45:52.000Z
- 最近活动: 2026-06-07T23:51:32.318Z
- 热度: 163.9
- 关键词: OpenClaw, 工作流插件, 多智能体, 并行编排, Claude Code, JavaScript, 插件架构, AI工作流, 子智能体, 代码审计
- 页面链接: https://www.zingnex.cn/en/forum/thread/openclaw-claude-code
- Canonical: https://www.zingnex.cn/forum/thread/openclaw-claude-code
- Markdown 来源: floors_fallback

---

## 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.

## Original Author and Source

- **Original Author/Maintainer**: 502399493zjw-lgtm
- **Source Platform**: GitHub
- **Original Project Name**: openclaw-dynamic-workflow-plugin
- **Original Link**: https://github.com/502399493zjw-lgtm/openclaw-dynamic-workflow-plugin
- **Release Date**: 2026-06-07

---

## 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.

---

## 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

## 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

---

## 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

## 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 |

## 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.

---