AI Agent 工程实践（08）：Workflow——什么时候应该拆成 Multi-Agent？

2401_85223846

139人浏览 · 2026-07-14 09:04:24

2401_85223846 · 2026-07-14 09:04:24 发布

发布时间：2026-07-11
标签：AI Agent｜LLM｜Multi-Agent｜Workflow｜架构设计｜工程实践

系列导航

上一篇：AI Agent 工程实践（07）：AI Agent 为什么需要 Skills，而不是 Prompt？
下一篇：AI Agent 工程实践（09）：AI Engineering OS v2——系统如何持续演化
本文是 [AI Agent 工程实践] 系列的第 08 篇。

去年我做第一个"正经" Agent 项目，一上来就画了 5 个 Agent：Planner、Researcher、Coder、Reviewer、Reporter。

架构图很漂亮，我发朋友圈都有人点赞。

然后我花了两周调它们之间的通信、状态同步、错误传播——最后发现，这些活儿一个 Agent 加个 Workflow 半天就能干完。

那 5 个 Agent 里，有 4 个的全部工作就是"把消息传给下一个"。

我踩的这个坑，太多人正在踩：一上来就上 Multi-Agent，以为 Agent 越多越强。 其实 80% 的项目，单 Agent 就够了。

本文你将学到

✓ 为什么"一上来就 Multi-Agent"是最常见的过度工程
✓ Single Agent → Workflow → Multi-Agent 的演进阈值在哪
✓ Planner / Executor / Reviewer 什么时候值得真正拆开
✓ 拆 Multi-Agent 的隐藏成本：通信、状态、调试

适合阅读

✓ 打算做多 Agent 系统、但不确定"要不要拆"的人
✓ 用 LangGraph / AutoGen / CrewAI 搭多智能体的开发者
✓ 想避开"为架构而架构"这个坑的人

问题背景

Multi-Agent 是这两年最被高估的概念。教程、demo、开源项目，张口就是"多智能体协作"，好像单 Agent 是上个时代的东西。

于是新人（包括去年的我）形成一个错觉：Agent 越多 = 系统越强。

真做起来才发现，拆多 Agent 引入了一堆单 Agent 根本没有的问题：

通信开销。 Agent 之间要传消息、对齐格式，光设计"谁跟谁说话"就够喝一壶。

状态同步。 每个 Agent 有自己的上下文，一个改了状态，其它怎么知道？很容易各说各话。

调试地狱。 出错时，是 Planner 规划错了？Executor 执行错了？还是消息在传递中丢了？责任链一长，根因难定位。

成本翻倍。 5 个 Agent = 5 份上下文、5 次 LLM 调用，token 和延迟成倍涨。

一句话：Multi-Agent 不是免费的架构升级，它是有沉重代价的分布式系统。 大多数时候，你付了分布式的代价，却没享受到分布式的收益。

错误尝试

第一次：一上来就 5 个 Agent

第一个项目，我照着"最佳实践"画了 Planner/Researcher/Coder/Reviewer/Reporter 五件套。

结果：两周耗在 Agent 间通信和状态同步上，真正的业务逻辑没写多少。最后复盘发现，4 个 Agent 的实际工作就是"把上一个的输出转给下一个"——这不是协作，这是击鼓传花。

第二次：全塞进一个 Agent 的巨型 Prompt

矫枉过正，我把 5 个 Agent 的活儿全塞进一个 Agent 的超长 prompt："你要先规划，再研究，再写代码，再审查……"

结果：又回到第 02 篇和第 07 篇的老问题——prompt 爆炸、步骤互相干扰、模型在长流程里丢步骤。把多步流程压进一个 prompt，不是单 Agent，是没有编排的混乱。

两次尝试指向同一个教训：单 Agent 和多 Agent 之间，缺了中间那一档——Workflow。大多数"需要多 Agent"的场景，其实只需要"单 Agent + Workflow"。

关键观察

我把做过的十几个 Agent 项目按"实际需要的架构"归了类：

项目复杂度	实际需要	占比
单一任务（问答、生成、审查）	Single Agent	~50%
多步但线性（规划→执行→检查）	Single Agent + Workflow	~30%
多步且需并行/异构专精	才真正需要 Multi-Agent	~20%

pie title 项目实际需要的架构分布
    "Single Agent 就够" : 50
    "Single + Workflow" : 30
    "真需要 Multi-Agent" : 20

80% 的项目不需要 Multi-Agent。

一上来拆多 Agent，不是把系统做强了，是把复杂度提前透支了。

定位真正原因

问题不在"该不该用 Multi-Agent"，而在没有一个清晰的升级阈值——大家凭"感觉高级"来选架构，而不是凭"任务是否真的需要"。

正确思路是把架构选择变成一条渐进升级链，每一档都有明确的触发条件：

Single Agent →（步骤变多）→ Workflow →（需要并行/异构专精）→ Multi-Agent

默认从最简单的开始，只有当前档位真扛不住了，才升级到下一档。 这和第 02 篇"不要在不需要分层的地方强行分层"、第 07 篇"一次性任务就别抽 Skill"是同一条原则：先满足需求，再谈架构升级。

最终方案：三档演进 + 拆分阈值

第一档：Single Agent（默认起点）

什么时候用：任务是单一的，或多步但简单到一个上下文能装下。

问答、代码生成、单文件审查——绝大多数任务属于这档。别被"单"字骗了，配好 Rule 和 Skill 的单 Agent，能力远超想象。这是默认档，没有明确理由不要离开它。

第二档：Single Agent + Workflow（多步但线性）

升级信号：任务有明确的多步骤，且步骤之间有依赖（先规划才能执行，先执行才能检查）。

这时候不用拆 Agent——同一个 Agent，按 Workflow 编排多步就行。Workflow 负责"步骤顺序和状态传递"，Agent 负责"每步执行"。

# workflow/code-task.yaml — 单 Agent 跑多步
agent: claude-code
steps:
  - name: plan
    skill: task-planning
  - name: execute
    skill: code-generation
  - name: review
    skill: code-review        # 同一个 Agent，换 skill 跑不同步骤

这一档能覆盖大多数"看起来需要多 Agent"的场景。 90% 想拆 Agent 的冲动，停在这里就够了。

第三档：Multi-Agent（真正需要才拆）

升级信号（满足其一才考虑）：

需要并行——多个子任务能同时跑（如同时研究 3 个技术方案），单 Agent 串行太慢
异构专精——不同步骤需要完全不同的模型/工具/上下文（如一个用代码模型、一个用检索模型），塞一个 Agent 里互相干扰
独立上下文——步骤之间上下文必须隔离（如审查者不该看到规划者的"思路"，以保持独立判断）

这三条，才是拆 Multi-Agent 的真正理由。 只是"步骤多"不算——那是 Workflow 的活。

Planner / Executor / Reviewer：什么时候值得拆

这是最经典的三角色。但它们不是"必须三个 Agent"，多数时候是一个 Agent 的三个阶段（Workflow）。真正值得拆成独立 Agent 的判据：

角色	值得拆成独立 Agent 的条件	否则
Planner	规划需要独立探索、试错、长上下文，会污染执行	当作 Workflow 的第一步
Executor	需要专门的工具/模型，或要并行多个	当作执行步骤
Reviewer	必须独立上下文——不看执行者思路才能客观	当作检查步骤

其中 Reviewer 是最有理由独立的——因为"独立判断"本身要求上下文隔离，这正好命中第三条拆分信号。而 Planner 和 Executor，多数时候留在同一个 Agent 里更省心。

实际收益

指标	一上来 5 Agent	按阈值渐进
开发周期	长（耗在通信/同步）	短（先跑通再升级）
调试难度	高（责任链长）	低（单点定位）
Token/延迟成本	高（N 份上下文）	低（按需拆）
架构合理性	常过度	匹配真实需求

为主观估算，非严格 A/B Test，但反映了"渐进升级"对避免过度工程的作用。

架构图 / 流程图

三档架构的升级路径

关键点：每一档都是"上一档扛不住了"才升级。默认停在 Single Agent，遇到多步升 Workflow，只有命中并行/异构/隔离才拆 Multi-Agent。

Planner-Executor-Reviewer 的两种形态

图片多样性：用了 Mermaid 的 pie / flowchart（含 subgraph）两种；发文时可再补一张 ProcessOn/draw.io 版的决策树，提升 CSDN 图片多样性得分。

代码或配置示例

同一个任务，三档写法对比

第一档 Single Agent——直接干：

result = agent.run(task)   # 就这么简单

第二档 Single + Workflow——多步但一个 Agent：

def run_workflow(task, agent):
    plan = agent.run(task, skill="planning")      # 步骤 1
    code = agent.run(plan, skill="coding")        # 步骤 2
    review = agent.run(code, skill="review")       # 步骤 3
    return review                                  # 线性传递，无跨 Agent 通信

第三档 Multi-Agent——仅当需要隔离/并行：

def run_multi_agent(task):
    plan = planner.run(task)                       # 独立 Agent
    # 并行执行多个子任务（这才是拆的理由）
    results = parallel([executor.run(sub) for sub in plan.subtasks])
    # Reviewer 独立上下文，不看 executor 的中间思路
    return reviewer.run(results, context="isolated")

对比很明显：从第一档到第三档，代码复杂度是跳级上升的。 没有并行/隔离的真实需求，第三档的复杂度就是纯亏。

架构选择判定（伪代码）

def choose_architecture(task) -> str:
    """按真实需求选架构，不凭'感觉高级'"""
    if task.is_single_step or task.fits_one_context:
        return "single_agent"                     # 默认档
    if task.is_linear_multi_step:
        return "single_agent_workflow"            # 多步但线性
    if task.needs_parallel or task.needs_isolation or task.needs_heterogeneous:
        return "multi_agent"                      # 才真正拆
    return "single_agent_workflow"                # 拿不准 → 保守选中间档

最后一行是关键：拿不准时选保守档。 和第 05 篇 Fallback"没把握就加载最少"一个哲学——宁可欠配，不可过度。

设计权衡

候选方案	优点	缺点	为什么不选（作为默认）
一上来 Multi-Agent	架构"高级"、可并行	通信/状态/调试成本高，多数是过度工程	80% 项目用不上，代价白付
全塞一个巨型 Prompt	无需编排	prompt 爆炸、丢步骤	不是单 Agent，是无编排的混乱
三档渐进（默认单 Agent）	匹配真实需求、成本可控	需判断升级时机	选择理由：唯一避免过度工程又留足扩展空间的路径

Multi-Agent 不是错的，过早用才是错的。 当你真的遇到并行、异构、上下文隔离的需求，该拆就拆——那时它是解药。判断标准就一句：不是"能不能拆"，而是"拆了到底解决什么单 Agent 解决不了的问题"。 答不上来，就别拆。

总结

✅ 80% 的项目不需要 Multi-Agent——一上来就拆是最常见的过度工程。
✅ 架构是三档渐进：Single Agent（默认）→ Workflow（多步线性）→ Multi-Agent（并行/异构/隔离），每档扛不住才升级。
✅ 大多数"想拆多 Agent"的冲动，用"单 Agent + Workflow"就能满足。
✅ Planner/Executor/Reviewer 多数是一个 Agent 的三个阶段；只有 Reviewer 因"需独立上下文"最有理由拆成独立 Agent。
✅ 拆的唯一理由是"解决单 Agent 解决不了的问题"（并行/异构/隔离），答不上来就别拆。