用 LangChain + Flow 编排多智能体

单个大 Prompt 写论文，输出像一锅粥：结构飘忽、引用张冠李戴、改一处崩全篇。在惟一智能做智能体平台时，我把这件事拆成了一条流水线 —— 检索、大纲、成稿、润色，四个各司其职的 Agent，用 Flow 串起来。

编排的价值不在于"更多的模型调用"，而在于每一步都变得可观测、可重试、可替换。

01 · 为什么拆

大 Prompt 的失败模式是隐性的：你不知道是检索没找到资料，还是大纲没立住，还是文笔跑偏。拆成多 Agent 之后，每个环节有明确的输入输出契约，坏了哪一环，日志里一目了然。这和后端把单体拆成服务是同一个直觉。

01 检索 Agent 资料清单

02 大纲 Agent 章节树 JSON

03 成稿 Agent 分章草稿

04 润色 Agent 终稿 + diff

四个 Agent 各司其职 · 中间产物全部结构化，坏在哪一环，日志一目了然

关键约定是中间产物全部结构化。大纲 Agent 输出的是章节树 JSON 而非自然语言，成稿 Agent 按章节逐个生成 —— 这样任何一章重写都不影响其他章节，用户改需求时只需从对应节点重新触发下游。

一是状态传递：早期把全文塞进每个 Agent 的上下文，token 爆炸。后来改成只传章节树 + 当前章节的相关检索片段，成本降了七成。二是润色 Agent 的越权：它会"顺手"改动事实性内容，最后用 diff 校验强制它只许动措辞、不许动引用。

多智能体不是银弹，编排本身就是新的复杂度。但当任务天然分阶段、且每阶段有可校验的产物时，流水线的可靠性收益远大于编排成本。下一篇我会写港口客服场景里 RAG 的三次重构，那是另一个 "结构化打败大力出奇迹"的故事。