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 review | parallel() DSL |
| 不同任務想用不同 provider | per-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 |
| codex | OpenAI Codex CLI | 程式碼正確性、安全審查 |
| gemini | Google Gemini CLI | API 設計審查、綜合分析 |
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 負責:
- 建構命令:將 prompt 轉為 CLI 命令 + 參數
- 環境變數管理:只傳遞白名單 env,自動 redact secret
- 解析輸出:將 provider stdout 解析為正規化的
AgentResult - 健康檢查:
doctor命令用的可用性驗證
| Adapter | CLI 命令 | 預設參數 |
|---|---|---|
| CodexExecAdapter | codex exec --json --ephemeral | promptMode: arg |
| GeminiCliAdapter | gemini --output-format json --approval-mode plan | promptMode: 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-only | prompt 自帶格式指示,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:
- 硬編碼 secret(API key / token / password)
.env檔案eval/new Function動態程式碼- Shell injection(spawn / exec / execSync)
- 網路呼叫(fetch / http.request)
- 檔案寫入(writeFileSync / writeFile)
- 不安全反序列化(JSON.parse)
- 權限操作(chmod / chown)
6.2 掃描結果
| 類別 | 結果 | 燈號 |
|---|---|---|
| 硬編碼 secret | 未發現 | 🟢 安全 |
| .env 檔案 | 未發現 | 🟢 安全 |
| eval / new Function | 1 處(測試檔驗證沙箱防護) | 🟢 安全(刻意測試) |
| 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() 建立隔離的沙箱環境。沙箱具有以下防護:
- 獨立 VM context:global 物件與 host 隔離,無法透過 prototype pollution 逃逸
- 只暴露安全的 DSL 函式:
agent()、parallel()、pipeline()、phase()、log() - 凍結 sandbox:Object.defineProperties 設定
writable: false+configurable: false - AST 靜態分析:workflow validator 在執行前掃描禁止的 pattern:
import/require()— 禁止模組存取process/fs/child_process— 禁止系統存取globalThis/global/window— 禁止 global 物件constructor/__proto__— 防止 prototype 攻擊Date.now()/Math.random()— 確保確定性fetch()— 禁止網路存取Functionconstructor — 禁止動態程式碼shell()/read()/write()— 禁止未來保留函式
🟡 Process Spawning(需注意但設計合理)
process-runner.ts 的 spawn() 是 OpenFlow 核心功能——它需要呼叫外部 provider CLI。安全措施:
- 環境變數白名單:只傳遞系統必要 env(PATH、HOME)+ 使用者明確 passEnv
- Secret 自動遮蔽:
shouldRedactEnvName()用 pattern 匹配(*_KEY、*_TOKEN、*_SECRET、PASSWORD) - Streaming Redactor:跨 chunk 的 secret 偵測,防止 secret 被分割到不同 chunk 而漏掉
- 設定強制:
security.allowShell強制為false,security.allowWorkflowImports強制為false - 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 受約束的執行環境
工作流在沙箱中執行時,只能存取以下全域變數:
| 變數 | 型別 | 說明 |
|---|---|---|
agent | function | 呼叫 AI agent |
parallel | function | 並行執行 |
pipeline | function | 管線處理 |
phase | function | 標記進度 |
log | function | 記錄資訊 |
args | object (frozen) | 使用者傳入的參數 |
cwd | string | 工作目錄 |
runId | string | run 唯一 ID |
artifactsDir | string | artifact 目錄路徑 |
7.3 Pipeline 策略比較
| 特性 | item-streaming | stage-barrier |
|---|---|---|
| 執行方式 | 每個 item 獨立跑完所有 stage | 所有 item 跑完 stage N 才進 N+1 |
| 適用場景 | item 間無依賴 | stage 間有依賴 |
| 失敗處理 | item 可獨立失敗 | 可 failFast 中止全部 |
| 並行度 | item 層級 | stage 內 item 層級 |
§8 設定與進階用法
8.1 設定檔合併優先順序
1CLI 參數(最高優先)
2 ↓
3.openflow/config.yaml(專案層級)
4 ↓
5預設值(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 定位差異
| 工具 | 定位 | 差異 |
|---|---|---|
| LangChain | LLM 應用框架(Python) | 包含 LLM client、記憶、RAG 等完整堆疊 |
| CrewAI | Multi-agent 框架 | 定義 agent 角色與互動模式 |
| Dify / Flowise | 視覺化工作流 | Web UI 拖拉建構 |
| OpenFlow | CLI 編排器 | 只做協調,不含 LLM client,依賴外部 CLI |
9.2 OpenFlow 的獨特價值
- 零 vendor lock-in:provider 是可插拔的 adapter,新增 provider 只需實作
AgentAdapterinterface - 安全第一:VM 沙箱 + AST 驗證 + secret redaction,三層防護
- Developer-friendly:使用熟悉的 TypeScript 語法,不需學新語言
- CI-native:JSON/JSONL reporter + deterministic exit code,天生適合 CI/CD
- 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 測試分布
| 類別 | 測試檔數 | 涵蓋模組 |
|---|---|---|
| 單元測試 | ~60 | agents / artifacts / cli / config / errors / orchestration / output / pipeline / runtime / security / structured / workflow |
| 整合測試 | ~27 | CLI execution / pipeline / mock runs / schema validation / artifact persistence / reporter |
| CLI 測試 | 1 | package-execution(npm pack + npx 驗證) |
| Contract 測試 | 1 | API contract 驗證 |
10.4 設計原則(架構師必讀)
OpenFlow 遵循 7 項嚴格的架構邊界:
- Workflow DSL 不知道 provider 細節 — DSL 只描述「要做什麼」,不管「怎麼呼叫」
- Runtime 不直接 spawn process — 透過 scheduler → adapter → process-runner 三層間接
- Provider adapter 不擁有工作流失敗策略 — adapter 只回報結果,失敗策略由 orchestration 決定
- Process 執行與 provider 無關 —
process-runner.ts是通用的 process spawner - 結構化輸出驗證是本地且 provider 獨立 — 不依賴 provider 的結構化 API
- Reporter 消費 event 但不控制執行 — reporter 是被動的觀察者
- Artifact 儲存是觀察與除錯的核心 — 每次 run 都完整記錄
§11 總結與建議
11.1 專案評估
| 面向 | 評分 | 說明 |
|---|---|---|
| 程式碼品質 | ★★★★☆ | 良好的模組分離、完整型別、豐富測試 |
| 安全性 | ★★★★☆ | 沙箱 + AST 驗證 + secret redaction 三層防護 |
| 可擴展性 | ★★★★☆ | Adapter pattern 易於新增 provider |
| 文件完整度 | ★★★☆☆ | README 充實,但缺少 API reference 網站 |
| 成熟度 | ★★☆☆☆ | 非常新(3 天),無正式 release,無社群 |
| 實用性 | ★★★☆☆ | 概念優秀,但需要已安裝 provider CLI |
11.2 使用建議
- 如果你已有 Codex / Gemini CLI:OpenFlow 是很好的協調層,可以立即使用
- 如果你只是評估:用 mock provider 體驗工作流概念,無需 API key
- 如果你想貢獻:這是加入新專案的好時機——專案剛起步,維護者可能歡迎 PR
- 如果你需要生產環境:建議觀望——專案太新,建議等幾個月穩定後再採用
11.3 未來發展(Roadmap)
根據 README 提到的 roadmap:
- Plugin provider 系統
- Retry 機制
- Worktree / Container 隔離
- Resumable runs
- Approval gates
- Automatic patch application
- Static HTML report
11.4 學習資源
- GitHub Repository
- npm Package
- Workflow Writer Skill — AI agent 撰寫工作流的完整指引
Comments