选择模式

不要按名字选模式。名字通常越看越像玄学。

更好的办法是问：我现在遇到的失败是什么？

先问：谁决定下一步？

flowchart TD
  A["从任务开始"] --> B{"一次模型调用能解决吗？"}
  B -->|能| ONE["一次模型调用"]
  B -->|不能| C{"步骤是否提前知道？"}
  C -->|是| WF["固定流程（Workflow）"]
  C -->|否| D{"下一步是否依赖工具返回？"}
  D -->|是| LOOP["Agent 循环"]
  D -->|否| PLAN["规划类模式"]
  LOOP --> E{"一个 Agent 是否背了太多职责？"}
  E -->|是| MA["多 Agent 协作"]
  E -->|否| SAFE["按需加可靠性、权限和评测"]

这张图背后只有三句话：

固定流程：代码决定路径。
Agent 循环：模型决定下一步动作。
多 Agent 协作：多个有专长的控制器一起做事。

按症状选

你遇到的问题	先看这个	为什么
输出格式总是坏	Structured Output	先把输出变成可解析、可校验、可修复的结构。
任务步骤固定	Prompt Chaining	把步骤写成显式流水线，方便测试和替换。
输入会流向不同任务	Routing	先分流，再给它对应的工具和流程。
需要工具，但不知道要调几次	ReAct	每轮都看工具返回，再决定下一步。
一次检索经常漏证据	Retrieval Loop	允许读完结果后改 query，再查一次。
回答必须带引用、可审计	Agentic RAG	用证据清单记录“哪个结论来自哪个来源”。
答案看起来合理但经常错	Maker-Checker 或 CoVe	在输出前加入审查、验证和修正。
多次运行结果波动大	Voting	多生成几个候选，再投票或融合。
计划会被新信息推翻	Planner-Executor-Replanner	把“重规划”变成显式步骤。
工具有依赖关系，或可以并行	LLM Compiler	把计划变成依赖图，再按依赖执行。
可能路线很多，需要试探	LATS	展开多条路径、评分、回传，再选更好的。
一个 Agent 职责太多	Manager-Worker	管理者拆任务，worker 各自负责一块。
专家 Agent 想像工具一样调用	Agents-as-Tools	把专家能力藏在工具边界后面。
任务中途要转给不同专家	Handoff	根据状态变化转交 ownership。
多个 Agent 需要讨论/互评	Group Chat	用 selector 管住讨论，不让它变群聊噪音。
长任务容易卡住或丢线索	Magentic Orchestration	用任务清单、进度账本、停滞检测来控住。
工具调用有风险	Policy + Guardrails + HITL	做权限检查、护栏拦截和人工确认。
不知道改动有没有变好	Tracing + Eval Harness	让行为可见，并能做回归测试。

推荐阅读顺序

如果你从零开始，按这个顺序读：

读完这些，再按自己的问题跳转。

成本规则

每个模式都是一笔交易。

模式家族	买到什么	付出什么
固定流程	可预测、好测试	步骤更固定
Agent 循环	能根据工具返回调整	延迟、成本、循环失败
可靠性	更可信	更多模型调用、更严格接口
检索	外部知识和引用	来源质量、引用质量
规划/搜索	更长任务跨度	预算和状态管理
多 Agent 协作	专业化、并行	协作开销、调试难度
权限/评测	可上线、可回归	更多日志、规则和测试

先从小的开始。只有当你能说清楚“现在到底坏在哪里”，再加下一层。