AI Agent 有哪些常用设计模式，分别适合解决什么问题？

核心回答

常用模式可以按“谁决定步骤、怎样利用反馈、如何分工”来理解：ReAct边观察边行动；Plan-and-Execute先建立全局计划再执行；Reflection检查并修订结果；Router把请求交给合适能力；多Agent把可分离任务交给不同执行者；Workflow把确定步骤与状态交给代码控制。Tool Use是这些模式使用外部能力的基础，并非另一套互斥架构。

选型先看任务依赖和验证条件。路径固定就用简单链或工作流；每一步依赖新证据时用ReAct；目标可拆分的长任务可用计划执行；有可操作评价标准时再加入反思。模式可以组合，不必把一个系统贴成唯一标签。

几类模式各适合什么问题

ReAct适合故障调查、网页探索等任务：先查监控，再根据异常查日志，下一步由观察决定。它灵活，但容易出现重复调用或局部探索，需要保存状态、预算与停止条件。

Plan-and-Execute适合多阶段研搜、代码迁移等工作：先拆目标与依赖，再逐步获得结果。执行器内部仍可用ReAct处理不确定步骤；关键前提失效时局部重规划，避免错误计划一路执行到底。

Reflection或Evaluator-Optimizer适合有清楚反馈的修订，例如根据测试失败修复代码、按引用证据检查报告。评审应指出可操作问题，迭代有限停止；同一模型反复认同自己，不构成可靠验证。

Router适合领域边界明确的请求，把订单问题交给订单能力，知识问题交给检索能力。要处理多意图、未知意图和低置信度，路由错误会把后续处理带到错误轨道。

多Agent的主管—工作者模式适合并行研究独立方向，Handoff适合把会话控制权交给专家。它们增加通信、状态归并和成本；任务高度耦合时，一个Agent加清楚状态可能更合适。

一个组合例子

研搜任务用Planner确定问题和报告结构；Router选择数据库、知识库或网络检索；各分支内部用ReAct补材料；主Agent整合；最后按证据和覆盖要求复核。固定的产物保存、版本记录和结束判断仍由Workflow组织。

这里的亮点是让每种模式解决一个具体瓶颈，而不是同时堆满所有模式。对照简单基线比较结果质量、延迟、调用次数与恢复能力，才能判断增加的复杂度是否值得。

常见追问

Plan-and-Solve与Plan-and-Execute有什么区别？ 前者常指一次推理中先分解再求解；后者强调规划与实际工具执行分工，通常还涉及状态和执行反馈。

对应教程

参考资料