五个 Agent 太浪费了：我为什么把 AI 工作流从 5 个 Agent 减到 3 个
摘要：很多人设计 AI 工作流时有个本能反应——"多拆几个 Agent，各管一段，肯定更可靠"。但我在实践中发现，不是每一步都需要独立的 AI 上下文。URL 分类、文本提取、汇总提案这些事，让 AI 做反而引入幻觉，让调度器（主会话）自己做更准更快。本文分享一个「网页笔记工作流」从 5 个独立 Agent 精简到"调度器（主会话） + 3 个 subagent"的思考过程，以及为什么真正的安全闸门只有一个——核查官必须独立，其他都可以商量。
一、问题的起点
这套工作流的初衷很简单：把收藏的网页交给 AI 提炼笔记，但不想被它一本正经地编造糊弄。
初版设计是五个独立 Agent，各管一段：
Agent 0 采编 → Agent 1 归类师 → Agent 2 笔记匠 → Agent 3 核查官 → Agent 4 确认员看起来分工明确，每个 Agent 都是独立的 AI 上下文，互不可见，互不影响。但实际跑起来我发现一个问题：很多步骤并不需要 AI。
不是"用 AI 能不能做"的问题——当然能——而是"用 AI 做是不是更好"。URL 分类是正则匹配，文本提取是调 CLI 工具，汇总提案是格式整理。这些事用 AI 做，不但慢、贵，还会引入额外的幻觉风险——AI 可能猜错媒体格式，可能脑补提取失败的原因，可能在汇总时自作主张。
于是我开始思考：哪些步骤真正需要独立的 AI 判断？哪些让调度器（主会话）自己做更靠谱？
二、关键决策：不是每步都需要 Agent
逐步骤分析：
采编（原 Agent 0）→ 主会话内化。
它的工作本质是：看 URL 的域名和路径判断是视频还是图文 → 调用对应的工具提取文本。URL 分类用正则，文本提取是执行 python tools/extract-document.py 或 python tools/extract-webpage.py。这完全是确定性逻辑——输入相同，输出一定相同。让 AI 做反而可能猜错（比如把 music.youtube.com 误判为视频而不是音频）。所以这一步交给调度器（主会话）自己，不创建 subagent。
归类师（原 Agent 1）→ 保留独立。
四选一分类（学习/借鉴/内容补充/可归档）需要理解正文语义，这是 AI 真正擅长的。同时，归类师的判断不应影响笔记匠——如果归类师给了"学习"标签，笔记匠可能"为了证明值得学习而过度提炼"。独立上下文隔离了这种认知污染。
笔记匠（原 Agent 2）→ 保留独立。
笔记提炼是核心创作任务，需要完整的上下文专注正文。独立意味着它只关注"从正文中提取什么"，不受其他任务干扰。
核查官（原 Agent 3）→ 必须独立，不可妥协。
这是整套系统的核心安全机制。文档里写得很清楚：
"AI 提炼东西的时候会一脸自信地编……写笔记的 Agent 不能来核查自己。"
如果核查和笔记匠是同一个 Agent，它天然会为自己的笔记辩护——"翻倍"那句它自己写的，它不会觉得有问题。这条必须守死。
确认员（原 Agent 4）→ 主会话内化。
确认员的工作是：读前几道产出、汇总成"待确认提案"、全部停在待确认。它不读原文、不做新判断，只是格式整理 + 行为约束。调度器（主会话）自己就能做，不需要独立的 AI。
最终架构：
调度器（主会话）
├── 1. 采编（主会话自己做——URL 正则 + CLI 工具提取文本）
│ → 产出 00-采编清单.md
│
├── 2. 归类师（独立 subagent——四选一语义分类）
│ → 产出 01-整理清单.md
│
├── 3. 笔记匠（独立 subagent——提取 3~5 条核心要点）
│ → 产出 02-笔记.md
│
├── 4. 核查官（全新 subagent——逐条比对原文 vs 笔记）
│ → 产出 03-核查表.md
│
└── 5. 确认（主会话自己做——汇总提案，全部停在待确认）
→ 产出 04-待确认提案.md对比一下：
| 步骤 | 原来 | 现在 | 理由 |
|---|---|---|---|
| 采编 | 独立 AI Agent | 主会话内化 | 正则 + CLI 是确定性逻辑 |
| 归类师 | 独立 AI Agent | 独立 subagent | 语义分类需要 AI |
| 笔记匠 | 独立 AI Agent | 独立 subagent | 核心提炼任务 |
| 核查官 | 独立 AI Agent | 独立 subagent（必须全新） | 安全闸门 |
| 确认员 | 独立 AI Agent | 主会话内化 | 格式整理 + 约束 |
LLM 调用次数从 5 次减到 3 次，节省 40%，而且消除幻觉风险最大的两个环节——采编和确认不再依赖 AI 猜测。
三、采编阶段具体做什么
既然采编交给了调度器（主会话），它具体怎么做？
媒体格式判断（优先级从高到低）：
- URL 路径末尾扩展名（忽略查询参数），
.pdf/.docx→ 文档 - 域名匹配：
music.163.com→ 音频；youtube.com/watch→ 视频；mp.weixin.qq.com→ 图文 - URL 路径含
/article/、/blog/、/posts/→ 图文 - 以上都不满足 → 无法判断
文本提取调用统一的 CLI 工具：
# 文档提取
python tools/extract-document.py paper.pdf
# → {"success": true, "text": "...", "char_count": 144, "method": "pypdf"}
# 图文页面提取（通过 BrowserSkill 操作已登录的浏览器）
python tools/extract-webpage.py https://example.com/article
# → {"success": true, "text": "...", "char_count": 125, "method": "bsk-webpage"}
# 视频页面提取
python tools/extract-video-text.py https://www.bilibili.com/video/BV1xx
# → {"success": true, "text": "...", "char_count": 1613, "method": "bsk-video"}所有工具输出统一 JSON 格式，调度器（主会话）直接解析即可。提取失败时如实标记"无法提取"，不硬凑。
四、实测效果
我在 7 条混合内容上测试了完整的采编能力：
| 内容 | 媒体格式 | 提取方式 | 结果 |
|---|---|---|---|
| 微信公众号文章 | 图文 | 已有正文（567 chars） | ✅ |
| CSDN 博客 | 图文 | 已有正文（819 chars） | ✅ |
| YouTube 视频 | 视频 | BrowserSkill 读取页面文本 | ✅（实际 B站视频 1613 chars） |
| B站视频 | 视频 | BrowserSkill 读取页面文本 | ✅ |
| PDF 论文 | 文档 | pypdf 提取（144 chars） | ✅ |
| DOCX 方案 | 文档 | python-docx 提取（114 chars） | ✅ |
| 普通网页 | 无法判断 | BrowserSkill 读取 | ✅ |
媒体格式分类 7/7 正确，文档提取 2/2 成功。视频和无法判断的页面通过 BrowserSkill 读取了可见文本（标题、描述、评论等）。
五、关键设计约束
关于"不抓网页"：
这套工作流本身不发起 HTTP 请求去抓网页。通过 BrowserSkill 操作的是用户已登录的浏览器，所以能访问付费墙后的内容和需要登录的页面。这是工具链设计上的一个重要选择——不越俎代庖，只利用用户已有的浏览器会话。
关于"只读不改"：
原文文件全程只读，不复制、不移动、不修改。每次运行只记录原文路径，核查时按路径回到原文比对。多次运行互不覆盖。
关于"全部停在待确认"：
任何删除、归档、发布、写入长期记录的动作都停在"待确认"，用户逐条点头后才落地。AI 可以无限地"想"和"建议"，但凡要"落地动手"，都停在用户那道闸前。
六、三种使用方式
多 Agent 版（推荐）：工具支持 subagent 时，调度器（主会话）自动创建 3 个 subagent（归类师、笔记匠、核查官），采编和确认由调度器（主会话）自己执行。
单对话框版（零门槛）：分三段交付。第一段调度器（主会话）做采编 + 归类 + 提炼后停下；第二段新开对话做核查（这一步不能省，否则又变成自己查自己）；第三段调度器（主会话）汇总确认。
文件流水线：五个文件并列写入
runs/<日期-主题>/目录，调度器（主会话） + 3 个 subagent 接力。
小结
回到最开始的问题：不是每一步都需要独立的 AI 上下文。
真正需要独立 AI 判断的只有三步——归类师理解语义、笔记匠专注提炼、核查官独立比对。采编和确认是确定性逻辑，让调度器（主会话）自己做更准、更快、零幻觉风险。
这不是在偷懒少建几个 Agent，而是在认真思考：哪些事只有 AI 能做，哪些事 AI 做反而更差。
项目已开源：github.com/star-nebula/WebNote-Workflow。仓库含完整文档、提示词和工具代码，欢迎 Star / Fork。
设计参考：Agent OS 的第一课：会分工，才会用 Agent（Axton Liu）。