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