OpenFang 自動化工作流建置指南

7分鐘閱讀

單個 Agent 能做的事有限,多個 Agent 編排才能實現端到端自動化。本文透過四個完整案例——每日產業簡報(簡單 Pipeline)、競品監控與預警(Fan-out + 條件分支)、內容生產流水線(多 Agent 協作)、客戶支援分類與升級(條件路由)——帶你掌握 OpenFang 工作流引擎的全部能力。

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 工作流——每天早上自動生成一份產業簡報:

toml
[[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 之間的依賴關係。

案例二:競品監控與預警(並行 + 彙整)

這個工作流同時監控多個競品動態,將並行採集的結果彙整分析:

toml
[[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 配圖:

toml
[[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——這意味著配圖生成和事實核查會並行執行,減少整體等待時間。

案例四:客戶支援分類與升級(條件路由)

這是一個智慧客服工作流,根據問題類型自動路由到不同的處理流程:

toml
[[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 模式測試工作流:

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

工作流最佳實踐

  1. 設定合理的逾時時間:每個 Task 應設定 timeout,防止單一步驟卡住整個流程
  2. 添加重試機制:網路請求類 Task 配置 retry = 3 和指數退避
  3. 使用條件判斷:避免不必要的 Task 執行,節省 API 呼叫成本
  4. 記錄執行日誌:配置 log_level = "debug" 用於問題排查
  5. 監控工作流健康:將工作流指標接入 Prometheus/Grafana

常見問題

一個工作流最多支援多少個 Task?
無硬性限制。但建議單個工作流的 Task 數控制在 20 個以內,以確保可維護性。更複雜的流程應拆分為多個子工作流。
如何處理 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 的輸出、以及全域配置變數。

下一步