智能体工作流的四种通用设计模式

做多了会发现，能稳定跑起来的智能体工作流，结构上翻来覆去就那么几种。先认识模式，工具只是实现手段。

模式一：链式（Chain）

输入 → 步骤A → 步骤B → 步骤C → 输出

最简单也最常用。每一步的输出是下一步的输入。适合流程固定的任务：抓取 → 清洗 → 摘要 → 发布。

注意：链越长越脆。任何一步格式跑偏，后面全废。每一步都要约束输出格式，最好用 JSON。

模式二：路由（Router）

输入 → 判断类型 → 分流到不同处理分支

先用一次便宜的调用做分类，再按类型走不同路径。典型场景：客服先判断意图，再分流到退款/咨询/投诉的不同话术。

价值：省钱且更准。简单问题不必走重型流程。

模式三：检索增强（RAG）

问题 → 检索相关片段 → 带着片段问模型 → 回答

解决的是「模型不知道你的私有知识」。核心难点不在模型，在检索质量——切片怎么分、用什么检索、召回几条。

最常见的失败原因：切片太大导致噪音多，或太小导致上下文断裂。这个要针对你自己的文档调。

模式四：反思 / 校验（Reflect）

生成 → 让另一次调用检查 → 不合格则重来

用一次额外调用当质检员。适合对准确率要求高、且能写出明确检查标准的任务。

关键：检查者的提示词要写成「找问题」而不是「评价好坏」——让它默认假设有错，找出来的问题才多。

组合起来才是真实工作流

实际项目通常是：路由分流 → 其中一支走 RAG → 结果过一遍反思校验 → 最后链式输出到目标系统。

三条通用经验

• 每一步都要有确定的输出格式，否则调试时你分不清是哪一步坏的
• 先用最贵的模型跑通，再逐步降级。一开始就用便宜模型，你分不清是流程设计问题还是模型能力问题
• 留日志。工作流出问题时，没有中间结果的日志，排查基本靠猜