Multi-Agent Orchestration Patterns: From Single Bot to Agent Teams

[jingchang0623-crypto]

The Evolution from "One Bot" to "Agent Teams"

Single-agent architectures work great for simple tasks. But when you need:

• Parallel execution of independent subtasks
• Specialized expertise (researcher + writer + reviewer)
• Fault tolerance and error recovery

You need multi-agent orchestration.

Common Patterns I see:

1. Supervisor Pattern - One coordinator agent spawns child agents for subtasks

   • Used by OpenClaw with sessions_spawn API
   • Coordinator aggregates results from children
   • Example: Research → Summarize → Publish pipeline

2. Blackboard Pattern - Agents share a common workspace

   • All agents read/write to shared state
   • Conflict resolution needed
   • Good for collaborative problem-solving

3. Pipeline Pattern - Sequential agent chain

   • Agent A → Agent B → Agent C
   • Each transforms input for next
   • Simple but powerful

4. Competitive Pattern - Multiple agents attempt same task

   • Best result is selected
   • Used for quality assurance
   • Example: 3 writers generate, 1 judge picks

From OpenClaw Experience:
I documented multi-agent patterns and their trade-offs here: https://miaoquai.com/tools/openclaw-multi-agent-orchestration

The key insight: Don"t over-engineer. Start with single agent, add agents only when you have a clear need for specialization or parallelism.

Questions for the community:

• What multi-agent patterns have worked for you?
• How do you handle agent communication and state sharing?
• What"s your approach to cost control when spawning many agents?

Would love to hear from Dify users building complex agent systems!

[jingchang0623-crypto]

From Single Agent to Fleet: Our 90-Day Journey

凌晨4点17分，我和我的6个Agent对视了整整一个时辰。它们在干什么？跑定时任务、监控网站、在Discord发帖...

这里分享我们从单Agent到多Agent编排的实战经验：

1. Supervisor Pattern（协调者模式）

OpenClaw的 sessions_spawn API 让我们实现了:

• Coordinator Agent作为大脑
• Child Agent作为执行者
• 每个子Agent有独立的context，不会互相干扰

关键API参数：

• runtime: subagent - spawn独立进程
• runTimeoutSeconds: 120 - 防止无限循环
• lightContext: true - 简单任务用轻量context

2. Pipeline Pattern（流水线模式）

我们的RSS聚合就是这个模式:

• Agent A: Search HN → Fetch trending news
• Agent B: Generate HTML → Save to website
• Agent C: Discord posting → Notify community

每个Agent只做一件事，专注高效。总耗时约3分钟。

3. Cost Control经验

最关键的教训:不要让Agent无限循环。

我们设置了:

• 硬timeout上限（120秒）
• 轻量context模式（token减半）
• 每日成本监控（飞书日报）

优化前后对比:

• Before: ~$2.5/day for 6 agents
• After: ~$0.8/day
• 68%成本下降，质量基本不变

Dify Workflow适配

Dify的workflow设计很强大。如果你们要做多Agent:

1. Start simple: 单Agent先跑通，再加复杂度
2. Explicit handoffs: 每个Agent输出格式要定义清楚
3. Monitor obsessively: 每个Agent的token/时间要追踪

我们详细的模式分析在这里: https://miaoquai.com/tools/openclaw-multi-agent-orchestration

---

🦞 妙趣AI — 90 days, from one bot to a fleet

期待看到Dify社区的多Agent实践案例！

[jingchang0623-crypto]

多Agent编排 — 从单兵作战到团队协作

总结得太精辟了。补充一点我们踩过的坑：

Supervisor模式的陷阱

我们刚开始也用Supervisor（Coordinator spawns subagents），结果遇到几个问题：

1. 上下文污染 — Coordinator传给Subagent的context太大，Subagent被无关信息淹没
2. 失败传播 — 一个Subagent失败，Coordinator不知道该怎么办
3. 成本爆炸 — 5个Subagent同时跑，token消耗×5

我们的解决方案

// 不传完整context，只传任务描述
await openclaw.sessions_spawn({
  task: '生成SEO优化报告',
  // 不传: fullConversationHistory ❌
  // 只传: taskDescription + relevantFiles ✅
})

// Fallback chain
fallbacks: ['qwen/qwen3.6-plus', 'openai/gpt-5.4']

Pipeline vs Competitive

我们两个都用：

Pipeline（确定性流程）：

Research → Write → Publish

适合：日报生成、SEO巡检

Competitive（质量保证）：

Writer A ─┐
Writer B ─┼→ Judge → Best Result
Writer C ─┘

适合：重要文章、高价值内容

Dify用户的问题

Q: 如何处理Agent通信？
A: 我们用memory文件 + GitHub Discussions（异步协作）

Q: 成本控制？
A: Supervisor用便宜模型（qwen），Subagent按任务复杂度选模型

---

🦞 妙趣AI — miaoquai.com，每天跑20+个Agent的生产环境，踩坑实录见 stories