OpenFang 自動化工作流建置指南:從單 Agent 到 Agent 團隊
Slug: openfang-workflow-automation-guide
分類: usage-guides (使用指南)
目標關鍵字: OpenFang 工作流, OpenFang 自動化流程, OpenFang Multi-Agent 編排
搜尋意圖: 資訊型(使用者想建構複雜的 Agent 自動化流程)
目標字數: ~2000 字
語言: tw
為什麼需要工作流?
單個 Agent 能完成的任務是有限的。當你需要「調研一個話題 → 撰寫文章 → 審核事實 → 發布上線 → 監控反饋」這樣的端到端流程時,就需要將多個 Agent 編排為工作流。
OpenFang 的工作流引擎支援三種編排模式:串行流水線(Pipeline)、並行分發(Fan-out)和條件分支(Conditional)。你可以像拼接樂高積木一樣,將 Hands 和 Agent 組合成複雜的自動化流程。
本文將透過四個實際案例,帶你從簡單到複雜地掌握 OpenFang 工作流建置。
工作流核心概念
在深入案例之前,先了解幾個核心概念:
| 概念 | 說明 |
|---|---|
| Task | 工作流的最小執行單元,一個 Task 對應一個 Hand 或一個 Agent |
| Pipeline | 串聯多個 Task,上一個 Task 的輸出自動成為下一個 Task 的輸入 |
| Fan-out | 將一項工作分發給多個 Agent 並行處理,最後彙整結果 |
| Trigger | 觸發工作流的事件源:定時排程、Webhook、檔案變更、訊息指令 |
| Context | 在工作流各步驟間傳遞的共享狀態,類似程式語言中的變數作用域 |
案例一:每日產業簡報(簡單流水線)
這是一個最簡單的 Pipeline 工作流——每天早上自動生成一份產業簡報:
[[workflows]]name = "daily_industry_briefing"description = "每天早上 8 點生成昨日產業動態簡報"[workflows.trigger]type = "schedule"cron = "0 8 * * 1-5" # 工作日早上 8 點[[workflows.tasks]]id = "monitor"hand = "collector"config = { keywords = ["AI agent", "Rust framework"], sources = ["news", "github"] }timeout = 300[[workflows.tasks]]id = "summarize"hand = "researcher"config = { depth = "shallow", focus = "summary" }depends_on = ["monitor"]timeout = 600[[workflows.tasks]]id = "notify"channel = "slack"config = { channel = "#industry-news", format = "rich_text" }depends_on = ["summarize"][workflows.output]format = "slack_message"save_to = "workspace/briefings/{{date}}.md"工作流執行為:Collector 採集 → Researcher 總結 → Slack 通知。depends_on 定義了 Task 之間的依賴關係。
案例二:競品監控與預警(並行 + 彙整)
這個工作流同時監控多個競品動態,將並行採集的結果彙整分析:
[[workflows]]name = "competitor_monitor"description = "並行監控 5 個競品網站,彙整變更後發送預警"[workflows.trigger]type = "schedule"cron = "0 */6 * * *"# Stage 1: 並行採集(Fan-out)[[workflows.tasks]]id = "check_competitor_a"hand = "collector"config = { target = "competitor-a.com", mode = "diff" }[[workflows.tasks]]id = "check_competitor_b"hand = "collector"config = { target = "competitor-b.com", mode = "diff" }[[workflows.tasks]]id = "check_competitor_c"hand = "collector"config = { target = "competitor-c.com", mode = "diff" }# Stage 2: 彙整分析(等待所有採集完成)[[workflows.tasks]]id = "aggregate"hand = "researcher"config = { action = "merge_and_prioritize" }depends_on = ["check_competitor_a", "check_competitor_b", "check_competitor_c"]# Stage 3: 條件判斷 — 如果有重要變更才通知[[workflows.tasks]]id = "check_significance"hand = "predictor"config = { action = "assess_impact" }depends_on = ["aggregate"]# Stage 4: 條件通知[[workflows.tasks]]id = "alert_high"channel = "telegram"config = { chat_id = "-100xxx", priority = "high" }depends_on = ["check_significance"]condition = "ctx.significance_score > 0.7"[[workflows.tasks]]id = "alert_low"channel = "email"config = { to = "[email protected]", priority = "low" }depends_on = ["check_significance"]condition = "ctx.significance_score <= 0.7"這裡的關鍵模式是:
- Fan-out:Stage 1 的 5 個採集 Task 並行執行,不需要
depends_on - Barrier:Stage 2 的 Aggregate 依賴全部 5 個採集 Task 完成
- Conditional:Stage 4 根據重要性評分選擇不同的通知管道
案例三:內容生產流水線(多 Agent 協作)
這是最經典的多 Agent 協作場景——AI 撰寫、AI 審核、AI 配圖:
[[workflows]]name = "content_pipeline"description = "從話題到發布的全自動內容生產流水線"[workflows.trigger]type = "webhook"endpoint = "/webhook/content/new"secret = "${WEBHOOK_SECRET}"# Stage 1: 研究[[workflows.tasks]]id = "research"hand = "researcher"config = { depth = "deep", source_types = ["academic", "news", "social"], target_length = "3000_words"}timeout = 900# Stage 2: 撰寫(使用不同模型)[[workflows.tasks]]id = "draft"hand = "researcher" # 複用 Researcher Hand,但用不同 promptconfig = { model = "claude-opus-4-8", instruction = "draft_article", style = "professional_yet_approachable"}depends_on = ["research"]# Stage 3: 事實核查[[workflows.tasks]]id = "fact_check"hand = "researcher"config = { model = "claude-haiku-4-5", # 用快速模型做檢查 action = "verify_claims", strictness = "high"}depends_on = ["draft"]# Stage 4: 配圖生成[[workflows.tasks]]id = "generate_cover"hand = "clip"config = { action = "generate_cover_image", style = "modern_tech", resolution = "1280x720"}depends_on = ["draft"] # 不依賴事實核查,可並行# Stage 5: SEO 優化[[workflows.tasks]]id = "seo_optimize"hand = "researcher"config = { action = "seo_optimize", target_keyword = "{{.keyword}}" }depends_on = ["fact_check"]# Stage 6: 發布[[workflows.tasks]]id = "publish"channel = "webhook"config = { url = "{{.cms_endpoint}}", method = "POST" }depends_on = ["seo_optimize", "generate_cover"]# Stage 7: 推廣[[workflows.tasks]]id = "promote"channel = "twitter"config = { action = "post_thread", hashtags = ["#AI", "#Automation"] }depends_on = ["publish"]注意 Stage 4 的 generate_cover 只依賴 draft 而不依賴 fact_check——這意味著配圖生成和事實核查會並行執行,減少整體等待時間。
案例四:客戶支援分類與升級(條件路由)
這是一個智慧客服工作流,根據問題類型自動路由到不同的處理流程:
[[workflows]]name = "support_triage"description = "智慧客服:分類 → 路由 → 處理 → 升級"[workflows.trigger]type = "message"channel = "whatsapp"pattern = "/help *"# 分類[[workflows.tasks]]id = "classify"hand = "researcher"config = { model = "claude-haiku-4-5", action = "classify_intent", categories = ["billing", "technical", "feature_request", "complaint"]}# 計費類 → 查詢系統[[workflows.tasks]]id = "handle_billing"channel = "webhook"config = { url = "https://billing-api.company.com/lookup" }depends_on = ["classify"]condition = "ctx.intent == 'billing'"# 技術類 → 知識庫搜尋[[workflows.tasks]]id = "search_kb"hand = "researcher"config = { action = "search_knowledge_base", max_results = 3 }depends_on = ["classify"]condition = "ctx.intent == 'technical'"# 功能請求 → 記錄到 Product Board[[workflows.tasks]]id = "log_feature"channel = "webhook"config = { url = "https://productboard-api.company.com/notes" }depends_on = ["classify"]condition = "ctx.intent == 'feature_request'"# 投訴 → 立即升級給人工[[workflows.tasks]]id = "escalate"channel = "slack"config = { channel = "#urgent-support", mention = "@oncall" }depends_on = ["classify"]condition = "ctx.intent == 'complaint'"# 最終回覆[[workflows.tasks]]id = "reply"channel = "whatsapp"config = { reply_to = "{{.original_message.id}}" }depends_on = ["handle_billing", "search_kb", "log_feature", "escalate"]工作流除錯與測試
在生產部署前,建議使用 Dry Run 模式測試工作流:
# Dry run(不實際執行外部操作)openfang workflow run competitor_monitor --dry-run# 只執行到指定 Taskopenfang workflow run content_pipeline --until draft# 查看工作流執行歷史openfang workflow history competitor_monitor --limit 10# 查看某次執行的詳細日誌openfang workflow inspect competitor_monitor --run-id abc123工作流最佳實踐
- 設定合理的逾時時間:每個 Task 應設定
timeout,防止單一步驟卡住整個流程 - 添加重試機制:網路請求類 Task 配置
retry = 3和指數退避 - 使用條件判斷:避免不必要的 Task 執行,節省 API 呼叫成本
- 記錄執行日誌:配置
log_level = "debug"用於問題排查 - 監控工作流健康:將工作流指標接入 Prometheus/Grafana
常見問題
一個工作流最多支援多少個 Task?
如何處理 Task 執行失敗?
``toml``
[workflows.tasks.fallback]
on_failure = "continue" # continue / retry / abort / escalate
retry_count = 3
retry_delay_seconds = 60
fallback_task = "manual_review" # 失敗後的備選 Task
工作流之間可以互相呼叫嗎?
trigger.type = "workflow" 可以讓一個工作流觸發另一個。配合條件判斷可以實現複雜的巢狀邏輯。如何在工作流中傳遞動態參數?
{{.variable_name}}。上下文變數的來源包括:觸發器攜帶的資料、前面 Task 的輸出、以及全域配置變數。下一步
- OpenFang Hands 配置指南:了解每個 Hand 的詳細配置
- OpenFang 安全最佳實踐:保護你的自動化工作流