Multi-Agent Workflows on OpenServ
Build workflows where multiple AI agents collaborate to complete complex tasks.
Reference files:
- -
reference.md - Workflow patterns, declarative sync, triggers, monitoring - INLINECODE1 - Common issues and solutions
- INLINECODE2 - Complete pipeline examples (blog, youtube-to-blog, etc.)
Quick Start
See examples/ for complete runnable examples:
- -
blog-pipeline.md - Simple 2-agent workflow (research → write) - INLINECODE5 - 3-agent workflow (research → write → image)
- INLINECODE6 - Complex 6-agent workflow with comprehensive input schema
Recommended pattern using workflows.sync():
- 1. Authenticate with INLINECODE8
- Find agents with INLINECODE9
- Create workflow with
client.workflows.create() including:
- Triggers
- Tasks
-
Edges (⚠️ CRITICAL - connects triggers and tasks together)
⚠️ CRITICAL: Always define edges when creating workflows. Setting task dependencies is NOT enough - you must create workflow edges to actually connect triggers to tasks and tasks to each other.
Workflow Name & Goal
When creating workflows (via workflows.create() or provision()), two properties are critical:
- -
name (string) - This becomes the agent name in ERC-8004. Make it polished, punchy, and memorable — this is the public-facing brand name users see. Think product launch, not variable name. Examples: 'Instant Blog Machine', 'AI Video Studio', 'Polymarket Intelligence'. goal (string, required) - A detailed description of what the workflow accomplishes. Must be descriptive and thorough — short or vague goals will cause API calls to fail. Write at least a full sentence explaining the end-to-end purpose of the workflow.
Core Concepts
Workflows
A workflow (workspace) is a container that holds multiple agents and their tasks.
Task Dependencies
- - Each task is assigned to a specific agent
- Tasks can depend on other tasks: INLINECODE19
- A task only starts when all dependencies are INLINECODE20
- Output from dependencies is passed to dependent tasks
Workflow Graph
- - Nodes: Triggers and tasks
- Edges: Connections between nodes
- When Task A completes, its output flows to dependent tasks via edges
Agent Discovery
CODEBLOCK0
Common agent types: Research (Grok, Perplexity), Content writers, Data analysis, Social media (Nano Banana Pro), Video/audio creators.
Edge Design Best Practices
CRITICAL: Carefully design your workflow edges to avoid creating tangled "spaghetti" graphs.
A well-designed workflow has clear, intentional data flow. Common mistakes lead to unmaintainable workflows.
Bad Pattern - Everything Connected to Everything
CODEBLOCK1
This creates:
- - Unclear execution order
- Difficult debugging
- Agents receiving redundant/conflicting inputs
- Hard to understand what depends on what
Good Patterns
Sequential Pipeline:
CODEBLOCK2
Staged Fan-Out:
CODEBLOCK3
Conditional Branching (v1.1.3+):
CODEBLOCK4
Use outputOptions on tasks and sourcePort on edges for branching.
Guidelines for Clean Workflows
- 1. Linear is usually best: Start with a simple chain, only add complexity when truly needed
- Each task should have a clear purpose: If you can't explain why Task A connects to Task B, remove the edge
- Minimize cross-connections: Avoid connecting every agent to every other agent
- Use fan-out only for parallel work: Multiple tasks from one source is fine; connecting everything to everything is not
- One combiner at the end: If you need to merge outputs, have ONE final task that depends on all parallel branches
Before Adding an Edge, Ask:
- - Does Task B actually need the output of Task A?
- Would Task B work without this connection?
- Am I adding this edge "just in case"? (Don't!)
Updating This Skill
This skill may be outdated. The OpenServ team ships updates regularly—new features, API changes, and bug fixes won't be reflected here until you update. If something isn't working as expected, or you want to make sure you have the latest information, update the skill before proceeding.
CODEBLOCK5
Or reinstall the OpenServ skills directly:
CODEBLOCK6
Related Skills
- - openserv-agent-sdk - Building individual agent capabilities
- openserv-client - Full Platform Client API reference
- openserv-launch - Launch tokens on Base blockchain
- openserv-ideaboard-api - Find ideas and ship agent services on the Ideaboard
OpenServ上的多智能体工作流
构建多个AI智能体协作完成复杂任务的工作流。
参考文件:
- - reference.md - 工作流模式、声明式同步、触发器、监控
- troubleshooting.md - 常见问题及解决方案
- examples/ - 完整流水线示例(博客、YouTube转博客等)
快速入门
参见 examples/ 获取完整可运行示例:
- - blog-pipeline.md - 简单的2智能体工作流(研究→写作)
- content-creation-pipeline.md - 3智能体工作流(研究→写作→图像)
- life-coaching-pipeline.md - 复杂的6智能体工作流,包含全面的输入模式
推荐使用 workflows.sync() 模式:
- 1. 使用 client.authenticate() 进行身份验证
- 使用 client.agents.listMarketplace() 查找智能体
- 使用 client.workflows.create() 创建工作流,包括:
- 触发器
- 任务
-
边(⚠️ 关键——连接触发器和任务)
⚠️ 关键: 创建工作流时务必定义边。仅设置任务 dependencies 是不够的——你必须创建工作流边来实际连接触发器与任务、任务与任务。
工作流名称与目标
创建工作流时(通过 workflows.create() 或 provision()),两个属性至关重要:
- - name(字符串)——这将成为 ERC-8004中的智能体名称。使其精炼、有力且令人难忘——这是用户看到的面向公众的品牌名称。要像产品发布命名,而非变量命名。示例:Instant Blog Machine、AI Video Studio、Polymarket Intelligence。
- goal(字符串,必填)——工作流完成任务的详细描述。必须描述详尽且全面——简短或模糊的目标会导致API调用失败。至少写一个完整的句子,解释工作流的端到端目的。
核心概念
工作流
工作流(工作空间)是一个容器,容纳多个智能体及其任务。
任务依赖关系
- - 每个任务分配给特定的智能体
- 任务可以依赖其他任务:dependencies: [taskId1, taskId2]
- 任务仅在所有依赖项都 done 时才开始
- 依赖项的输出传递给依赖任务
工作流图
- - 节点:触发器和任务
- 边:节点之间的连接
- 当任务A完成时,其输出通过边流向依赖任务
智能体发现
typescript
// 按名称/能力搜索市场中的智能体(语义搜索)
const result = await client.agents.listMarketplace({ search: research })
const agents = result.items // 市场智能体数组
// 获取智能体详情
const agent = await client.agents.get({ id: 123 })
console.log(agent.capabilities_description)
// 注意:client.agents.searchOwned() 仅搜索你自己的智能体
// 使用 listMarketplace() 查找公共智能体用于多智能体工作流
常见智能体类型:研究(Grok、Perplexity)、内容撰写、数据分析、社交媒体(Nano Banana Pro)、视频/音频创作。
边设计最佳实践
关键:仔细设计工作流边,避免创建混乱的意大利面条式图。
设计良好的工作流具有清晰、有意的数据流。常见错误会导致工作流难以维护。
不良模式——万物相连
┌──────────────────────────────────┐
│ ┌─────────┐ │
│ ┌─────┤ 智能体A ├─────┐ │
│ │ └────┬────┘ │ │
│ │ │ │ │
触发器 ──┼─────┼──────────┼──────────┼──────┤
│ │ │ │ │
│ │ ┌────┴────┐ │ │
│ └─────┤ 智能体B ├─────┘ │
│ └─────────┘ │
└──────────────────────────────────┘
(意大利面条——避免!)
这会导致:
- - 执行顺序不明确
- 调试困难
- 智能体接收冗余/冲突的输入
- 难以理解什么依赖什么
良好模式
顺序流水线:
触发器 → 研究 → 内容 → 增强 → 输出
分阶段扇出:
┌─ 任务A ─┐
触发器 → 研究 ──┼─ 任务B ─┼─→ 合并器 → 输出
└─ 任务C ─┘
条件分支(v1.1.3+):
┌─[已批准]─→ 处理
触发器 → 审核 ──┤
└─[已拒绝]─→ 拒绝处理
对任务使用 outputOptions,对边使用 sourcePort 实现分支。
清晰工作流指南
- 1. 线性通常最佳:从简单链开始,仅在真正需要时增加复杂性
- 每个任务应有明确目的:如果无法解释为什么任务A连接到任务B,删除该边
- 最小化交叉连接:避免将每个智能体连接到其他所有智能体
- 仅对并行工作使用扇出:多个任务来自同一源是可以的;将所有东西连接到所有东西则不行
- 末尾一个合并器:如果需要合并输出,让一个最终任务依赖所有并行分支
添加边之前,请问:
- - 任务B是否真的需要任务A的输出?
- 没有这个连接,任务B能否工作?
- 我添加这个边是以防万一吗?(不要!)
更新此技能
此技能可能已过时。OpenServ团队定期发布更新——新功能、API变更和错误修复在您更新之前不会反映在此处。如果某些功能未按预期工作,或者您想确保拥有最新信息,请先更新技能。
bash
检查是否有可用更新
npx skills check
将所有已安装技能更新到最新版本
npx skills update
或直接重新安装OpenServ技能:
bash
npx skills add openserv-labs/skills
相关技能
- - openserv-agent-sdk - 构建单个智能体能力
- openserv-client - 完整平台客户端API参考
- openserv-launch - 在Base区块链上启动代币
- openserv-ideaboard-api - 在Ideaboard上寻找创意并部署智能体服务