背景
上一篇讲了为什么做这个对比、为什么选这三个框架。
这一篇讲我们要实现一个什么东西，为什么要拆成多个 agent
后面的各家的实现都建在这条pipline上，所以先把它说清楚。
要实现的：一条写博客的流水线
单个 agent 没什么难度：挂几个工具、写段提示词、跑一轮对话，三个框架写出来差不多，看不出区别，跟 QuickStart 是一个问题。
所以得挑一个稍微成熟一点的场景。想来想去选了写技术博客，因为它天然就是多角色的：有一个人写，有用户来读。在这个基础上，我又加了一个编辑来审。
三个角色各管一段：
| 角色 | 干什么 |
|---|---|
| 执笔 | 把主题和笔记写成初稿，再按意见修订，是唯一有写权限的角色 |
| 读者视角 | 照着做能不能跑通、哪里看不懂、哪里会卡住 |
| 编辑视角 | 查事实性错误、编造的数据、跑不通的命令、结论和依据对不上 |
做的过程中又补了一个运营视角（标题和搜索词匹不匹配、标签怎么打、开头能不能留住人），凑成三个审核视角。
串起来是这样一条流水线：
执笔写初稿 ↓ 三个视角并行审核（编辑 / 读者 / 运营） ↓ 汇总判定 ↓ 不通过 → 执笔按意见修订 → 复审，最多三轮为什么要拆成多个 Agent
一个角色的时候，三家框架写出来的东西几乎一样，体现不出差别。角色一多，事情才开始有意思：
- 谁先谁后、能不能并行
- 上下文怎么在角色之间传
- 一个角色能不能干另一个角色的活
- 某个角色跑歪了，谁来兜
这些问题单 agent 根本碰不到，而它们恰恰是各个框架差别最大的地方。编排放在哪、谁决定下一步、数据怎么流转，三家给的答案完全不同，得有多个角色才逼得出来。
为什么要加一个审稿的环节
加审稿不是为了凑角色。AI 写技术文章会犯一些很稳定的错
- 编数据、给跑不通的命令、结论和依据对不上
- 而且 prompt 劝不住，改了提示词照样犯。所以得把「写」和「挑错」分成两拨人：执笔只管写，另外立一套专门挑错的角色来审。
审稿这边我没有只放一个人，而是拆成三个视角：编辑、读者、运营。这么拆有两个原因。
- 一是一个审核员顾不过来。事实性、可读性、运营这三类问题要是全塞给一个 agent 打分，它哪类都容易审得浅、审得漏。三个视角各盯一类，覆盖面才够。
- 二是要让它们各判各的。三个视角互相不看对方的意见——要是能看到彼此的判断，就会互相带偏：运营看见编辑判了个 blocker，容易跟着把自己的意见也说重。彼此隔开，每一份意见才是独立的。
- 三个视角里，只有编辑能判 blocker。blocker 会直接挡住发布，这个权力要是也给运营，它就会拿「标题不够吸引人」去卡一篇技术上没问题的文章。所以能判 blocker 的资格只给编辑——那个真正对「读者照着做会不会出事」负责的视角。
还有一条更根本的：判定权不在模型手上。模型只负责按等级给意见，每条标上 blocker / major / minor；能不能发布由一个函数按这些等级算——有 blocker 就不可发布，只剩 major 就建议修订后发布，都没有才是可以发布。
ifmissingorblockers>0:status="blocked"# ❌ 不可发布elifmajors>0:status="needs_revision"# ⚠️ 建议修订后发布else:status="publishable"# ✅ 可以发布模型压根没有「宣布可以发」这个动作可用。这么分是因为模型会为了把流程走完而说「可以发了」，函数不会。
小结
这一篇就两件事：
一、我们要做的是一条写博客的流水线，一个人写、三个视角审、不通过就修订复审。选这个场景是因为它天然多角色，能把框架的差别逼出来。
二、两个设计选择——拆成多个 agent，是为了让编排、并行、上下文传递这些问题浮出来；单独加一个编辑，是因为 AI 写技术文章会犯 prompt 劝不住的错，而且判定权得攥在函数手里，不能交给模型。
具体每个角色怎么写、编排怎么摆，下一篇从 LangChain 开始动手。
