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 字 语言: zh


为什么需要工作流?

单个 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 的输出、以及全局配置变量。

下一步