OpenFlow 完整教學:本地優先的 Coding-Agent 工作流編排器

§1 專案總覽與定位

1.1 OpenFlow 是什麼

OpenFlow 是一個本地優先 (local-first) 的命令列工作流執行器,專門用於編排外部 coding-agent CLI(如 OpenAI Codex CLI 的 codex exec、Google Gemini CLI 的 gemini -p)。它的核心設計理念是:

  • 不自己實作 AI agent:OpenFlow 只做協調(orchestration),不做推論(inference)
  • 受約束的 DSL:工作流語法是 JavaScript/TypeScript 子集,但禁止 import、shell、fs 等危險操作
  • Local-first:所有 run artifact 都持久化到本地 .openflow/runs/ 目錄,不需要雲端服務

1.2 解決什麼問題

現代 coding agent(Codex、Gemini 等)從終端機操作很方便,但當工程任務需要多個 prompt、多個 agent run、或不同 provider 時,缺少一個統一的「上層協調層」。OpenFlow 填補了這個空缺:

痛點OpenFlow 方案
大型任務需拆成多步驟工作流檔案 + phase()
想同時跑多個 agent reviewparallel() DSL
不同任務想用不同 providerper-agent provider 設定
agent 輸出需要結構化JSON Schema + structuredOutput
需要追溯每次 run 的細節.openflow/runs/<runId>/ artifact 持久化
CI 環境需要機器可讀輸出JSON / JSONL reporter

1.3 技術指標

指標
語言TypeScript
npm 套件@prmflow/openflow v0.2.0
Node.js 要求>= 20
授權MIT
原始碼行數~20,184 行
測試檔案89 個(Vitest)
相依套件commander + ajv + yaml(極精簡)
建立日期2026-06-05(非常新的專案)

§2 安裝與環境設定

2.1 前置需求

1# 確認 Node.js 版本 >= 20
2node --version
3
4# 確認 npm 可用
5npm --version

2.2 三種安裝方式

方式一:npx 直接執行(推薦試用)

1npx @prmflow/openflow --help
2npx @prmflow/openflow doctor

方式二:全域安裝

1npm install -g @prmflow/openflow
2openflow --help
3openflow doctor

方式三:本地開發

1git clone https://github.com/travisliu/openflow.git
2cd openflow
3npm install
4npm run build
5npx . --help

2.3 Provider CLI 安裝

OpenFlow 需要對應的 provider CLI 才能真正呼叫 AI agent:

Provider需要安裝用途
mock不需要(內建)測試、範例、CI
codexOpenAI Codex CLI程式碼正確性、安全審查
geminiGoogle Gemini CLIAPI 設計審查、綜合分析

2.4 設定檔

OpenFlow 的設定檔為 .openflow/config.yaml

 1defaultProvider: mock
 2concurrency: 4
 3timeoutMs: 900000
 4
 5providers:
 6  mock:
 7    command: mock
 8    responses:
 9      default:
10        text: "mock response"
11  codex:
12    command: codex
13    args: ["exec", "--json", "--ephemeral"]
14  gemini:
15    command: gemini
16    args: ["--output-format", "json", "--approval-mode", "plan"]
17    defaultModel: gemini-3-flash-preview
18    promptMode: stdin
19
20security:
21  allowShell: false
22  allowWorkflowImports: false
23  passEnv: []
24  redactEnv:
25    - "*_KEY"
26    - "*_TOKEN"
27    - "*_SECRET"
28    - "PASSWORD"
29
30reporting:
31  mode: pretty
32  verbose: false

§3 系統架構

3.1 整體架構圖


graph TB
    subgraph CLI["CLI 層"]
        RUN["openflow run"]
        VALIDATE["openflow validate"]
        DOCTOR["openflow doctor"]
    end

    subgraph CORE["核心引擎"]
        CONFIG["Config Loader
load → merge → validate"] WF_LOAD["Workflow Loader
parse → validate → sandbox"] RUNTIME["Runtime
DSL execution context"] SCHEDULER["Scheduler
concurrency + timeout + fail-fast"] EVENT_BUS["Event Bus
typed event emission"] end subgraph DSL["Workflow DSL"] AGENT["agent()"] PARALLEL["parallel()"] PIPELINE["pipeline()"] PHASE["phase()"] LOG["log()"] end subgraph PROVIDERS["Provider Adapters"] MOCK["MockAdapter"] CODEX["CodexExecAdapter"] GEMINI["GeminiCliAdapter"] REGISTRY["ProviderRegistry"] end subgraph OUTPUT["輸出層"] PRETTY["PrettyReporter"] JSON_R["JsonReporter"] JSONL_R["JsonlReporter"] ARTIFACTS["Artifact Store
.openflow/runs/"] end subgraph SECURITY["安全層"] SANDBOX["VM Sandbox
隔離執行環境"] VALIDATOR["Workflow Validator
AST 靜態分析"] ENV_REDACT["Env Redactor
secret 遮蔽"] STREAM_REDACT["Stream Redactor
跨 chunk secret 偵測"] end RUN --> CONFIG RUN --> WF_LOAD VALIDATE --> WF_LOAD DOCTOR --> CONFIG WF_LOAD --> SANDBOX WF_LOAD --> VALIDATOR SANDBOX --> RUNTIME RUNTIME --> DSL AGENT --> SCHEDULER PARALLEL --> SCHEDULER PIPELINE --> SCHEDULER SCHEDULER --> REGISTRY REGISTRY --> MOCK REGISTRY --> CODEX REGISTRY --> GEMINI CODEX --> ENV_REDACT GEMINI --> ENV_REDACT CODEX --> STREAM_REDACT GEMINI --> STREAM_REDACT EVENT_BUS --> PRETTY EVENT_BUS --> JSON_R EVENT_BUS --> JSONL_R RUNTIME --> ARTIFACTS

3.2 執行流程


sequenceDiagram
    participant User
    participant CLI
    participant Config
    participant Workflow
    participant Sandbox
    participant Scheduler
    participant Provider
    participant Artifacts

    User->>CLI: openflow run workflow.ts
    CLI->>Config: 載入 + 合併 config.yaml
    CLI->>Workflow: 解析 + AST 驗證 workflow.ts
    Workflow->>Sandbox: 建立 VM context(隔離)
    Sandbox->>Scheduler: 執行 DSL → 排程 agent task
    Scheduler->>Provider: spawn 外部 CLI process
    Provider-->>Scheduler: stdout/stderr + exit code
    Scheduler-->>Sandbox: AgentResult
    Sandbox-->>CLI: workflow 結果
    CLI->>Artifacts: 持久化 run artifact
    CLI-->>User: 輸出 report

3.3 模組依賴關係


graph LR
    CLI --> CONFIG
    CLI --> WORKFLOW
    CLI --> PIPELINE
    CLI --> OUTPUT
    WORKFLOW --> SANDBOX["sandbox.ts"]
    WORKFLOW --> DSL["dsl.ts"]
    WORKFLOW --> VALIDATE["validate.ts"]
    DSL --> AGENTS["agents/"]
    DSL --> PIPELINE
    AGENTS --> PROCESS["process-runner.ts"]
    AGENTS --> SECURITY["security/env.ts"]
    PIPELINE --> DSL
    OUTPUT --> EVENTS["event-bus.ts"]

§4 核心概念與 API

4.1 Workflow DSL 五大 Primitive

agent() — 呼叫單一 AI agent

 1const result = await agent({
 2  id: "code-review",          // 唯一識別(可選,自動產生)
 3  provider: "codex",           // provider 名稱
 4  prompt: "Review this code.", // prompt 文字
 5  model: "o4-mini",            // 指定模型(可選)
 6  timeoutMs: 60000,            // 超時設定(可選)
 7  cwd: "./src",                // 工作目錄(可選)
 8  schema: { ... },             // JSON Schema(可選)
 9  structuredOutput: {          // 結構化輸出設定(可選)
10    transport: "auto"
11  }
12});

回傳 AgentResult

1{
2  ok: boolean;
3  text: string;
4  agentId: string;
5  provider: string;
6  durationMs: number;
7  error?: { code: string; message: string; };
8  structured?: unknown;  // JSON Schema 驗證後的結構化資料
9}

parallel() — 並行執行多個 task

 1// 物件形式(具名結果)
 2const results = await parallel({
 3  codex: () => agent({ provider: "codex", prompt: "Review for bugs." }),
 4  gemini: () => agent({ provider: "gemini", prompt: "Review for design." })
 5});
 6// results.codex, results.gemini
 7
 8// 陣列形式
 9const results = await parallel([
10  () => agent({ prompt: "Task A" }),
11  () => agent({ prompt: "Task B" })
12]);
13// results[0], results[1]

pipeline() — 多階段資料處理管線

1const result = await pipeline(
2  ["file1.ts", "file2.ts"],  // items
3  [
4    { name: "review", run: (ctx) => ctx.agent({ prompt: `Review ${ctx.item}` }) },
5    { name: "fix",    run: (ctx) => ctx.agent({ prompt: `Fix issues in ${ctx.item}` }) }
6  ],
7  { strategy: "item-streaming", concurrency: 2, failFast: false }
8);

Pipeline 有兩種策略:

  • item-streaming:每個 item 獨立跑完所有 stage(適合 item 間無依賴)
  • stage-barrier:所有 item 跑完 stage N 才進 stage N+1(適合 stage 間有依賴)

phase() — 標記工作流進度

1phase("review");
2// ... review 相關 agent calls
3phase("summarize");
4// ... summarize 相關 agent calls

log() — 記錄操作資訊

1log("Starting review of 5 files", { fileCount: 5 });

4.2 Provider Adapter 機制

OpenFlow 的 provider adapter 負責:

  1. 建構命令:將 prompt 轉為 CLI 命令 + 參數
  2. 環境變數管理:只傳遞白名單 env,自動 redact secret
  3. 解析輸出:將 provider stdout 解析為正規化的 AgentResult
  4. 健康檢查doctor 命令用的可用性驗證
AdapterCLI 命令預設參數
CodexExecAdaptercodex exec --json --ephemeralpromptMode: arg
GeminiCliAdaptergemini --output-format json --approval-mode planpromptMode: stdin, model: gemini-3-flash-preview
MockAdapter內建(不 spawn process)responses 設定

4.3 Model 解析優先順序

1agent-level model
2  ↓ (若無)
3CLI --model 參數
4  ↓ (若無)
5provider config defaultModel
6  ↓ (若無)
7global config defaultModel
8  ↓ (若無)
9不傳 model 參數

4.4 結構化輸出

支援四種 transport 模式:

Transport行為
validate-onlyprompt 自帶格式指示,OpenFlow 只做回傳驗證
prompt將 JSON Schema 注入 prompt 尾部
native使用 provider 原生結構化輸出(目前 adapter 未支援)
auto自動選擇最佳 transport

§5 實戰範例

5.1 基本 Code Review 工作流

 1// workflows/basic-review.ts
 2export const meta = {
 3  name: "basic-review",
 4  description: "Single agent code review",
 5  phases: ["review"]
 6};
 7
 8phase("review");
 9
10const result = await agent({
11  id: "reviewer",
12  provider: "codex",
13  prompt: "Review the changed files for correctness issues."
14});
15
16export default result;

執行:

1openflow run workflows/basic-review.ts

5.2 多 Provider 並行 Review

 1// workflows/parallel-review.ts
 2export const meta = {
 3  name: "parallel-review",
 4  description: "Review with multiple providers in parallel",
 5  phases: ["review", "summarize"]
 6};
 7
 8phase("review");
 9
10const reviews = await parallel({
11  codex: () => agent({
12    id: "codex-review",
13    provider: "codex",
14    prompt: "Review the changed files for correctness issues."
15  }),
16  gemini: () => agent({
17    id: "gemini-review",
18    provider: "gemini",
19    prompt: "Review the changed files for API design issues."
20  })
21});
22
23phase("summarize");
24
25const summary = await agent({
26  id: "summary",
27  provider: "codex",
28  prompt: `Summarize these reviews:\n${JSON.stringify(reviews, null, 2)}`
29});
30
31export default { reviews, summary };

5.3 Pipeline 批次處理

 1// workflows/pipeline-review.ts
 2export const meta = {
 3  name: "pipeline-review",
 4  description: "Review multiple files through a pipeline"
 5};
 6
 7const changedFiles = ["src/auth.ts", "src/api.ts", "src/db.ts"];
 8
 9const result = await pipeline(
10  changedFiles,
11  [
12    {
13      name: "review",
14      run: (ctx) => ctx.agent({
15        prompt: `Review ${ctx.item} for security and correctness.`,
16        schema: {
17          type: "object",
18          properties: {
19            file: { type: "string" },
20            findings: { type: "array", items: { type: "string" } }
21          },
22          required: ["file", "findings"]
23        },
24        structuredOutput: { transport: "auto" }
25      })
26    }
27  ],
28  { strategy: "item-streaming", concurrency: 2 }
29);
30
31export default result;

5.4 使用 Mock Provider 做 CI 測試

 1// workflows/ci-smoke.ts
 2export const meta = {
 3  name: "ci-smoke",
 4  description: "CI smoke test using mock provider"
 5};
 6
 7phase("test");
 8
 9const result = await agent({
10  id: "smoke",
11  provider: "mock",
12  prompt: "Verify build artifacts exist."
13});
14
15export default result;
1# CI 環境跑 mock workflow
2openflow run workflows/ci-smoke.ts --reporter json

5.5 Dry Run 模式

1# 驗證工作流語法但不呼叫任何 provider
2openflow validate workflows/review.ts
3
4# 帶 mock 的 dry run
5openflow run workflows/review.ts --dry-run

§6 資安掃描報告

6.1 掃描方法

/tmp/openflow clone 執行以下 7 類 pattern grep:

  1. 硬編碼 secret(API key / token / password)
  2. .env 檔案
  3. eval / new Function 動態程式碼
  4. Shell injection(spawn / exec / execSync)
  5. 網路呼叫(fetch / http.request)
  6. 檔案寫入(writeFileSync / writeFile)
  7. 不安全反序列化(JSON.parse)
  8. 權限操作(chmod / chown)

6.2 掃描結果

類別結果燈號
硬編碼 secret未發現🟢 安全
.env 檔案未發現🟢 安全
eval / new Function1 處(測試檔驗證沙箱防護)🟢 安全(刻意測試)
Shell execution (spawn)1 處(process-runner.ts — 核心設計)🟡 注意
Shell execution (execSync)8 處(全部在 tests/cli/ 測試檔)🟢 安全(僅測試)
網路呼叫1 處(測試檔驗證 fetch 被禁止)🟢 安全(刻意測試)
檔案寫入多處(tests/ 內建立 fixture + run-store.ts artifact)🟢 安全(正常功能)
JSON.parse多處(解析 provider stdout + artifact)🟢 安全(正常功能)
chmod / chown未發現🟢 安全

6.3 深度安全分析

🟢 沙箱安全(高品質)

OpenFlow 在執行使用者定義的工作流時,使用 Node.js vm.createContext() 建立隔離的沙箱環境。沙箱具有以下防護:

  1. 獨立 VM context:global 物件與 host 隔離,無法透過 prototype pollution 逃逸
  2. 只暴露安全的 DSL 函式agent()parallel()pipeline()phase()log()
  3. 凍結 sandbox:Object.defineProperties 設定 writable: false + configurable: false
  4. AST 靜態分析:workflow validator 在執行前掃描禁止的 pattern:
    • import / require() — 禁止模組存取
    • process / fs / child_process — 禁止系統存取
    • globalThis / global / window — 禁止 global 物件
    • constructor / __proto__ — 防止 prototype 攻擊
    • Date.now() / Math.random() — 確保確定性
    • fetch() — 禁止網路存取
    • Function constructor — 禁止動態程式碼
    • shell() / read() / write() — 禁止未來保留函式

🟡 Process Spawning(需注意但設計合理)

process-runner.tsspawn() 是 OpenFlow 核心功能——它需要呼叫外部 provider CLI。安全措施:

  1. 環境變數白名單:只傳遞系統必要 env(PATH、HOME)+ 使用者明確 passEnv
  2. Secret 自動遮蔽shouldRedactEnvName() 用 pattern 匹配(*_KEY*_TOKEN*_SECRETPASSWORD
  3. Streaming Redactor:跨 chunk 的 secret 偵測,防止 secret 被分割到不同 chunk 而漏掉
  4. 設定強制security.allowShell 強制為 falsesecurity.allowWorkflowImports 強制為 false
  5. Config 驗證validateConfig() 在啟動時驗證所有安全設定

🟢 無外部 API 呼叫

OpenFlow 本身不做任何網路請求。所有 API 呼叫都由外部 provider CLI 處理,OpenFlow 只負責 spawn process 並讀取 stdout。

6.4 總結評估

 1整體資安評級:🟢 良好
 2
 3優點:
 4- 沙箱設計嚴謹(VM + AST 雙重防護)
 5- Secret 管理完善(pattern redact + streaming redactor)
 6- 無硬編碼憑證
 7- 環境變數白名單機制
 8- 最小權限原則(只暴露必要 DSL)
 9
10需關注:
11- process-runner.ts 的 spawn 是不可避免的攻擊面(但已有防護)
12- 專案非常新(建立僅 3 天),安全機制尚未經大量實戰驗證

§7 工作流 DSL 深入解析

7.1 工作流檔案結構

每個 OpenFlow 工作流都是一個 TypeScript 檔案,必須遵循嚴格的結構:

 1// 1. metadata(必須是第一個 top-level statement)
 2export const meta = {
 3  name: "workflow-name",       // 必須:工作流名稱
 4  description: "what it does", // 必須:描述
 5  phases: ["phase1", "phase2"] // 可選:phase 清單
 6};
 7
 8// 2. 工作流邏輯(使用 DSL primitive)
 9phase("phase1");
10const result = await agent({ ... });
11
12// 3. 預設匯出(回傳結果)
13export default result;

7.2 受約束的執行環境

工作流在沙箱中執行時,只能存取以下全域變數:

變數型別說明
agentfunction呼叫 AI agent
parallelfunction並行執行
pipelinefunction管線處理
phasefunction標記進度
logfunction記錄資訊
argsobject (frozen)使用者傳入的參數
cwdstring工作目錄
runIdstringrun 唯一 ID
artifactsDirstringartifact 目錄路徑

7.3 Pipeline 策略比較

特性item-streamingstage-barrier
執行方式每個 item 獨立跑完所有 stage所有 item 跑完 stage N 才進 N+1
適用場景item 間無依賴stage 間有依賴
失敗處理item 可獨立失敗可 failFast 中止全部
並行度item 層級stage 內 item 層級

§8 設定與進階用法

8.1 設定檔合併優先順序

1CLI 參數(最高優先)
23.openflow/config.yaml(專案層級)
45預設值(DEFAULT_CONFIG)

8.2 Reporter 模式

模式輸出格式適用場景
pretty彩色終端輸出本地開發
json完整 JSON 物件CI 自動化
jsonl每行一個 JSON event串流處理
1# 指定 reporter
2openflow run workflow.ts --reporter json
3openflow run workflow.ts --reporter jsonl

8.3 CLI 參數

 1openflow run <file> [options]
 2  --provider <name>   # 覆蓋預設 provider
 3  --model <name>      # 覆蓋預設 model
 4  --reporter <mode>   # pretty | json | jsonl
 5  --concurrency <n>   # 最大並行數
 6  --timeout-ms <ms>   # 全域超時
 7  --fail-fast         # 第一個失敗就中止
 8  --dry-run           # 不實際呼叫 provider
 9
10openflow validate <file>  # AST 驗證工作流
11openflow doctor           # 環境健康檢查

8.4 Artifact 結構

每次 run 產生的 artifact 結構:

1.openflow/runs/<runId>/
2├── manifest.json          # run metadata
3├── report.json            # 最終結果
4├── events.jsonl           # 所有 event 時間線
5└── agents/
6    └── <agentId>/
7        ├── prompt.txt     # 發送的 prompt
8        ├── raw-result.json    # provider 原始輸出
9        └── normalized-result.json  # 正規化後的結果

§9 與同類工具的比較

9.1 定位差異

工具定位差異
LangChainLLM 應用框架(Python)包含 LLM client、記憶、RAG 等完整堆疊
CrewAIMulti-agent 框架定義 agent 角色與互動模式
Dify / Flowise視覺化工作流Web UI 拖拉建構
OpenFlowCLI 編排器只做協調,不含 LLM client,依賴外部 CLI

9.2 OpenFlow 的獨特價值

  1. 零 vendor lock-in:provider 是可插拔的 adapter,新增 provider 只需實作 AgentAdapter interface
  2. 安全第一:VM 沙箱 + AST 驗證 + secret redaction,三層防護
  3. Developer-friendly:使用熟悉的 TypeScript 語法,不需學新語言
  4. CI-native:JSON/JSONL reporter + deterministic exit code,天生適合 CI/CD
  5. Offline-capable:mock provider 讓工作流在無 API 環境下也能測試

9.3 適用場景與限制

適合使用

  • 已有 Codex / Gemini CLI 的團隊想做多步驟自動化
  • CI/CD pipeline 整合 AI 審查
  • 需要 audit trail 的企業環境
  • 想用不同 provider 做不同任務的混合工作流

目前限制

  • 只支援 3 個 provider(mock / codex / gemini),擴展需手動
  • 無 retry 機制(roadmap 有規劃)
  • 無 approval gate(roadmap 有規劃)
  • 無 container/worktree 隔離(roadmap 有規劃)
  • 無 web UI(純 CLI)
  • 專案非常新(建立僅 3 天),社群與文件仍在成長中

§10 開發與貢獻

10.1 開發環境

1git clone https://github.com/travisliu/openflow.git
2cd openflow
3npm install
4npm run build
5npm test

10.2 專案結構

 1openflow/
 2├── src/                    # 原始碼(16 個模組目錄)
 3│   ├── cli/                #   CLI 命令定義
 4│   ├── config/             #   設定載入 / 合併 / 驗證
 5│   ├── workflow/           #   工作流解析 / 驗證 / 沙箱 / DSL
 6│   ├── pipeline/           #   pipeline 執行器
 7│   ├── orchestration/      #   scheduler / event-bus / cancellation
 8│   ├── agents/             #   provider adapter + process-runner
 9│   ├── output/             #   reporter(pretty / json / jsonl)
10│   ├── artifacts/          #   run artifact 持久化
11│   ├── security/           #   env redaction
12│   ├── structured/         #   結構化輸出處理
13│   ├── errors/             #   錯誤碼與 exit code
14│   ├── types/              #   共用型別
15│   ├── runtime/            #   public API
16│   └── doctors/            #   health check
17├── tests/                  # 測試(89 個測試檔)
18│   ├── unit/               #   單元測試
19│   ├── integration/        #   整合測試
20│   ├── cli/                #   CLI 端對端測試
21│   └── fixtures/           #   測試 fixture
22├── skills/                 # AI agent 工作流撰寫技能
23├── examples/               # 範例工作流
24└── workflows.example.ts    # 範例工作流入口

10.3 測試分布

類別測試檔數涵蓋模組
單元測試~60agents / artifacts / cli / config / errors / orchestration / output / pipeline / runtime / security / structured / workflow
整合測試~27CLI execution / pipeline / mock runs / schema validation / artifact persistence / reporter
CLI 測試1package-execution(npm pack + npx 驗證)
Contract 測試1API contract 驗證

10.4 設計原則(架構師必讀)

OpenFlow 遵循 7 項嚴格的架構邊界:

  1. Workflow DSL 不知道 provider 細節 — DSL 只描述「要做什麼」,不管「怎麼呼叫」
  2. Runtime 不直接 spawn process — 透過 scheduler → adapter → process-runner 三層間接
  3. Provider adapter 不擁有工作流失敗策略 — adapter 只回報結果,失敗策略由 orchestration 決定
  4. Process 執行與 provider 無關process-runner.ts 是通用的 process spawner
  5. 結構化輸出驗證是本地且 provider 獨立 — 不依賴 provider 的結構化 API
  6. Reporter 消費 event 但不控制執行 — reporter 是被動的觀察者
  7. Artifact 儲存是觀察與除錯的核心 — 每次 run 都完整記錄

§11 總結與建議

11.1 專案評估

面向評分說明
程式碼品質★★★★☆良好的模組分離、完整型別、豐富測試
安全性★★★★☆沙箱 + AST 驗證 + secret redaction 三層防護
可擴展性★★★★☆Adapter pattern 易於新增 provider
文件完整度★★★☆☆README 充實,但缺少 API reference 網站
成熟度★★☆☆☆非常新(3 天),無正式 release,無社群
實用性★★★☆☆概念優秀,但需要已安裝 provider CLI

11.2 使用建議

  1. 如果你已有 Codex / Gemini CLI:OpenFlow 是很好的協調層,可以立即使用
  2. 如果你只是評估:用 mock provider 體驗工作流概念,無需 API key
  3. 如果你想貢獻:這是加入新專案的好時機——專案剛起步,維護者可能歡迎 PR
  4. 如果你需要生產環境:建議觀望——專案太新,建議等幾個月穩定後再採用

11.3 未來發展(Roadmap)

根據 README 提到的 roadmap:

  • Plugin provider 系統
  • Retry 機制
  • Worktree / Container 隔離
  • Resumable runs
  • Approval gates
  • Automatic patch application
  • Static HTML report

11.4 學習資源