这一章要回答什么

前面我们已经有了：

  • 一个明确场景
  • 一套够用的技术栈

接下来真正决定项目能不能站住的，是这件事：

一个多 Agent 系统最小要有哪些执行部件，才能真正跑起来？

这章就围绕当前项目的第一条核心主线来讲：

  • 任务怎么创建
  • Agent 怎么分工
  • 执行流怎么串起来
  • 状态和日志怎么落库

当前项目里的 4 个 Agent

这个项目最后收敛成了 4 个固定 Agent：

  • Dispatcher
  • Research
  • Writer
  • Reviewer

这个拆法并不是唯一正确答案，但它很适合当前写作场景。

Dispatcher：先把方向定下来

它负责的不是直接写正文，而是：

  • 理解用户选题
  • 给出标题候选
  • 收敛文章主线

这是整个任务的第一层“方向锚点”。

Research：把内容素材先整理清楚

它负责：

  • 围绕选题做研究摘要
  • 提炼文章可以使用的线索
  • 把后续写作需要的背景准备好

这一步让 Writer 不需要从零开始瞎猜。

Writer：把内容真正写出来

它会承担两次关键任务：

  • 先生成提纲和初稿
  • 再根据审核意见生成修订稿

这也是为什么 Writer 在执行流里会出现两次。

Reviewer：做质量闸门和审稿

它不是简单“给点建议”，而是负责判断：

  • 内容有没有跑题
  • 是否存在结构和表达问题
  • 是否达到了进入下一步的最低标准

项目后期还把它升级成了结构化“质量闸门”。

当前项目的主执行流是什么

当前项目的主链路是一个固定串行流程：

  1. 创建任务
  2. Dispatcher / plan
  3. Research / research
  4. Writer / draft
  5. Reviewer / review
  6. Writer / revision

对应到系统里，就是：

plan -> research -> draft -> review -> revision

这条流程的核心特点是：

  • 由代码控制顺序
  • 由 Agent 负责内容生成
  • 关键节点可以暂停做人工确认

这是一种很典型、也很适合 MVP 的设计。

为什么第一版一定要做“固定流程”

很多人第一次做 Agent，很容易想让系统一开始就完全自治。
但这往往会带来几个问题：

  • 结果不稳定
  • 很难复现
  • 很难解释为什么会跑成这样
  • 很难做失败恢复

所以当前项目选择的是：

代码控制流程，模型负责内容。

这句话非常重要。

它意味着：

  • 哪一步先执行、哪一步后执行，由程序决定
  • 每一步给什么上下文，由程序决定
  • 什么时候暂停给用户看，由程序决定
  • 模型只在这个框架里生成内容

这能极大提升系统的可控性。

一个“能跑”的执行流，最少要有哪几类部件

如果把当前项目抽象一下，一个最小可运行的多 Agent 系统，至少要有这些东西。

1. 任务对象

必须先有一个“任务”，把整个流程串起来。

当前项目里的任务大致包含：

  • 选题
  • 角度
  • 读者
  • 风格
  • 字数
  • 中间产物
  • 当前状态

没有任务对象，整个系统就只是几次分散的模型调用。

2. 流程控制器

你需要一个地方决定：

  • 现在该跑哪个 Agent
  • 上一步成功没有
  • 下一步是什么
  • 出错后怎么处理

当前项目里，这个角色主要由 article_pipeline.py 承担。

3. Agent 执行器

每个 Agent 自己要知道：

  • 它接收什么上下文
  • 它要调用什么模型
  • 它的输出怎么解析

这一层对应当前项目里的：

  • dispatcher.py
  • research.py
  • writer.py
  • reviewer.py

4. 状态持久化

如果流程状态不落库，系统一旦出错或重启，任务就会丢。

当前项目很早就把这些存下来了：

  • 任务主状态
  • 当前 Agent / 当前步骤
  • 步骤日志
  • 错误信息
  • 审批记录

这就是为什么后面能支持重试、中断、审批和调试。

5. 结果产物存储

不仅要知道“流程跑到哪了”，还要存下每一步产出的内容。

比如：

  • title
  • research_markdown
  • outline_markdown
  • draft_markdown
  • review_notes
  • final_markdown

这能让任务详情页真正有内容可看。

当前项目为什么一开始就保留日志

一个多 Agent 系统如果没有日志，几乎无法调试。

当前项目从比较早的阶段就保留了这些信息：

  • 每一步由谁执行
  • 这一步是什么类型
  • 输入摘要是什么
  • 输出摘要是什么
  • 有没有报错
  • Token 使用量

后面又逐步扩展成：

  • Prompt 调试
  • Context Breakdown
  • LLM Call
  • 质量闸门

这说明一个重要经验：

日志不是“系统做完后再补”的东西，而是系统一开始就该带上的能力。

执行流后来是怎么继续长大的

第一版的执行流只要能跑通就行，但随着系统继续演进，当前项目在这条主线里又长出了很多真实能力。

加了人工审批

系统不是一路自动跑完，而是在关键节点暂停给用户确认：

  • dispatcher_done
  • writer_done
  • revision_done

这让多 Agent 系统变成了“人机协作”而不是纯黑盒。

加了质量检查

随着任务量变多，就会发现：

  • Dispatcher 有时会偏题
  • Writer 有时会生成明显不合格的初稿

于是项目又补了：

  • Dispatcher 后的一致性检查
  • Reviewer 的结构化质量闸门

加了自动回炉

如果 Reviewer 判断是 rewrite，系统不会立刻把低质量内容丢给用户，而是会自动回炉 Writer 一次，再次审稿后才继续。

这一步让执行流从“只是顺序执行”，变成“会做最低限度的自动自救”。

这一章的结论

第一个可运行版本，不需要很复杂，但必须具备这些最小能力：

  • 有任务
  • 有固定 Agent 分工
  • 有明确执行流
  • 有状态持久化
  • 有步骤日志
  • 有产物存储

当前项目的经验是：

先让系统稳定地按固定流程跑起来，再在这条主线上逐步补审批、质量控制、自动回炉。

下一章看什么

当执行流跑通以后，项目其实还只是“能执行”。
要把它变成一个真正的产品，还需要一层新的东西：

后台工作台。

下一章我们就讲，为什么多 Agent 系统不能只停留在一个表单和一个按钮，而必须做成任务中心、模型配置、Agent 管理都齐全的工作台。