智能体设计模式全景

架构是套在随机策略之上的控制结构。

单次 LLM 调用是一个从上下文到 token 概率分布的函数。它没有记忆，无法行动，也不保证正确。智能体架构是你包裹在这次调用之外的确定性脚手架：决定何时再次调用模型、往其上下文里放什么、它可以调用哪些工具、何时停止的那个循环。关于可靠性的一切有趣之处都活在脚手架里，而非提示词里。

这个视角之所以重要，是因为它告诉你该把精力花在哪里。你无法让模型变得确定，但你可以让控制流变得确定、可观测、有边界。好的架构把一个无界、不可预测的生成过程转化为一个有界状态机，其中每一次状态转移都可被检视。模式之间的差异在于施加多少结构以及在何处施加。

区分每种模式的五个坐标轴。

本节中的每一种架构都可以定位在五个坐标轴上。学一次，后续的深入解析就会变成相互比较，而不是一堆技巧的罗列。

• 规划视野（planning horizon）。智能体是逐步决策（ReAct），还是预先承诺一个多步计划（plan-and-execute）？短视野适应意外；长视野在多阶段任务上保持连贯。
• 自我修正。是否存在显式的验证-修订步骤（反思、评估者-优化者），还是智能体信任自己的第一份输出？自我修正在结构可校验的任务上以延迟与 token 换质量。
• 分支。智能体追求单一轨迹，还是探索多条并择优（树/图搜索、best-of-N）？分支以乘性成本换取困难推理上的鲁棒性。
• 分解拓扑。一个带许多工具的智能体，还是由路由器或监督者协调的多个窄范围智能体？分解隔离上下文与故障，但增加交接开销。
• 状态归属。谁持有真相——线性消息历史、外部草稿区/黑板，还是带类型的图状态？这决定了你如何调试、恢复与审计。

多数生产系统不是单一模式，而是组合：一个路由器分派到一个 plan-and-execute 工作者，其执行器使用一个带反思门控的 ReAct 工具循环再返回结果。这些坐标轴让你能精确描述这种组合，而不是含糊地挥手说"一个智能体"。

为什么架构是可靠性杠杆，而非能力杠杆。

一个常见错误是把架构当作让模型"更聪明"的手段。它们不是。模型的能力上限在推理时已被固定。架构改变的是结果的分布：它削去灾难性失败的长尾，抬高平庸运行的下限，通常以延迟、token 与工程复杂度为代价。

具体而言，同一个基础模型在同一个任务上：

# Illustrative — pass rate on a 200-task internal eval
single call (no tools)           41%
+ tool loop (ReAct-style)        68%
+ reflection gate before return  74%
+ best-of-3 with selector        79%   # ~3x token cost
+ task-specific verifier         88%   # biggest single jump

从这类数字可得两个教训。第一，早期结构（给模型工具和一个循环）是最便宜、最大的收益——这就是下一篇从 ReAct 开始的原因。第二，通用的自我改进循环回报递减；来自任务特定校验器的跃升远超通用反思，因为可校验的正确性胜过模型给自己打分。

如何阅读本节其余部分。

后续文章按结构从少到多排列。ReAct 是最小可用循环。Plan-and-execute 加上规划视野。反思加上自我修正。搜索策略加上分支。路由与多智能体编排加上分解。工具错误恢复是横切关注点，决定了上述任何一种能否在真实工具面前存活。

对每一种，心中始终持有三个问题，因为本节的验收标准就是每种模式都要给出三者：它何时见效？它何时反而有害？你买入的是什么具体权衡？一个没有失败模式的模式，是你尚未理解的模式。