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 工作流——每天早上自动生成一份行业简报:
[[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 安全最佳实践:保护你的自动化工作流