简介：本文围绕AI Agent工程落地中最棘手的范式选型问题展开，系统对比CoT、ReAct、Reflexion、ToT与Multi-Agent五大范式的核心机制、能力边界与工程成本。文章给出了可量化的成本参考区间、四步选型决策流以及Multi-Agent的适用判据与通信拓扑建议，帮助开发者在“效果”与“账单”之间做出理性权衡，避免陷入“炫技式架构”陷阱。
很多团队在落地AI Agent时，习惯性地把五大范式当成并列的“单选菜单”：要么用ReAct，要么上Multi-Agent。这种思维是第一个需要破除的误区。从实现机理来看，这五个范式并不是互斥的架构方案，而是可以在不同层次叠加的能力组件：
因此，做选型时正确的思考方式不是“我选哪个范式”，而是“我以哪个范式为主干，搭配哪些增强能力”。举个实际例子：一个典型的客服Agent，底层是ReAct循环（负责工具调用与多轮交互），在遇到用户情绪激烈时需要CoT先冷静分析意图，在连续两次回答错误时触发Reflexion机制进行策略调整——这是常见且合理的组合方式。
为了便于决策，我们将五大范式的关键能力拆解为六个维度逐一对比。以下分析基于业界公认的实现方式与经验数据，供选型参考：
CoT不支持工具调用，它的输出只是纯文本推理过程。ReAct原生支持工具调用，其“Thought-Action-Observation”循环天然适配函数调用场景。Reflexion不改变ReAct的工具调用方式，只是在循环末尾增加反思提示。ToT本身不强制工具调用，可以设计为纯推理路径探索，也可以在每个节点调用工具，但实现复杂度会显著上升。Multi-Agent天然支持工具调用，而且多个Agent可以各自绑定不同的工具集。
Reflexion的纠错能力最强，因为它把“反思”显式建模为一步，模型会针对失败原因生成新的计划。ToT的纠错能力属于“间接纠错”，它通过评估多条路径的分数来淘汰低质量的推理线索，本质上是一种搜索剪枝，纠错粒度较粗。Multi-Agent的纠错依赖Agent之间的互相审查或评审Agent的反馈，效果中上但需要额外的通信开销。裸ReAct几乎没有纠错能力，一旦规划出错会沿着错误方向走到底。
ToT和Multi-Agent支持并行探索，前者是推理路径并行，后者是任务执行并行。CoT、ReAct、Reflexion都是线性流程，同一时间只推进一条路径。这意味着ToT和Multi-Agent在面对“方案空间大、单条路径成功率低”的问题时，理论上能找到更优解，但代价是Token消耗与计算资源的成倍增长。
ReAct循环天然会产生长上下文——每轮工具调用结果都需要追加到对话历史中，轮次多了之后容易超出模型上下文窗口。Reflexion因为要追加反思内容和重试序列，上下文膨胀更快。ToT需要同时维护多条路径的完整推理轨迹，对长上下文的需求最极端。Multi-Agent通过把任务分给多个Agent来避免单个上下文过大，各Agent的上下文是隔离的，但需要额外的通信机制来同步状态。
从工程角度，CoT几乎零成本，不需要任何工具接入或状态管理。ReAct需要一个工具注册中心与执行沙箱，成本低。Reflexion需要额外设计反思模板和重试机制，成本中低。ToT需要实现路径管理、评分函数与分支控制，成本高。Multi-Agent则需要考虑Agent通信协议、任务编排、状态一致性、异常恢复等问题，成本在所有范式中最高。
CoT与ReAct的推理过程均为线性，可以通过日志完整回放，调试相对容易。Reflexion可观测性中等，需要区分正常推理与反思步骤。ToT的调试难度高，因为涉及多路径的并发追踪。Multi-Agent的调试难度最高，问题可能出在单Agent内部，也可能出在Agent之间的消息传递或任务交接环节。
一个值得深入思考的现象是：虽然学术界和业界都在探索各种高级范式，但绝大多数生产环境的Agent框架，其底层循环仍然是ReAct。这并非因为其他范式不好，而是ReAct在成本、性能、可控性之间取得了最平衡的折中。
ReAct的线性“思考-行动-观察”循环天然适配人的监督习惯。在一个可预期的流程中，每个步骤都是可验证的，你可以在任何一步暂停、注入人工干预、修改行动参数。而ToT的多路径并行机制往往导致行为不可预测——模型可能会在某条意外路径上花费大量Token，人工介入困难。
ReAct的设计初衷就是“在推理过程中调用工具”，它不需要额外的前置规划步骤。在一次用户请求中，如果需要连续调用数据库查询、外部API、计算结果等多个工具，ReAct循环只需要按顺序执行即可，无需额外的调度开销。Reflexion在每次反思后都要重新展开推理，Token消耗明显上升；ToT则需要同时维持多条路径的推理，成本更高。
ReAct循环的一个隐含优点是故障域是“单线程”的——出错了就在当前循环内调整，不会波及其他执行单元。Multi-Agent恰恰相反，一个Agent的错误可能通过通信链路传导给其他Agent，导致雪崩效应。对于大多数业务场景来说，这种跨单元的故障传染是不可接受的。
以一个日常的客服问答场景为例：处理一单常规咨询，ReAct模式往往消耗1.5K到4K Token，响应时间在2到5秒之间；切换到Reflexion模式，因为要附加反思与重试，Token消耗会上升到6K到12K；如果使用ToT维持5条平行路径，Token消耗大约在10K到25K；Multi-Agent配合2-3个Agent做任务分解与汇总，Token消耗通常在8K到20K之间。这个成本差距意味着：在日请求量达到十万级后，ReAct与ToT的API费用差异可能是数万元级别的差距。
Multi-Agent不是“灵丹妙药”，引入它意味着要承担通信开销、状态一致性问题、调试复杂度等额外负担。以下情况才是Multi-Agent的合理使用场景：
如果一个复杂任务可以拆成几个互相依赖较小的子任务，而且每个子任务需要不同的工具集或专业知识，那么Multi-Agent的自然分工优势就能发挥作用。例如：一个“行业研究报告生成”任务，可以拆解为“数据采集Agent”（负责抓取和整理数据）、“数据分析Agent”（负责统计与图表生成）、“文案撰写Agent”（负责最终报告行文）。三个子任务之间通过结构化的中间文件或消息传递交互，而不是互相依赖推理上下文。
当任务需要处理的信息量超过了模型上下文窗口的限制时，单Agent会面临“遗忘”问题——早期的关键信息被后来加入的内容挤出上下文。Multi-Agent通过将不同的信息片段分给不同的Agent来规避这个问题，每个Agent只在自身的上下文窗口内工作。不过，需要注意：Agent之间的信息同步也需要通过某种机制完成，这依然会消耗通信成本。
在某些决策类场景中，需要从多个角度审视同一问题。例如，一个编程任务可以拆为“代码生成Agent”和“代码审查Agent”，前者负责写代码，后者负责找出漏洞。这种“生成-校验”的分工方式比单Agent在同一个上下文里既写又审要更有效，因为模型在同时扮演两个角色时，可能会受到角色混淆的影响。
一旦决定使用Multi-Agent，下一个问题是“Agent之间怎么通信”。常见的通信拓扑有三种：星型（一个中心Agent协调所有子Agent的输入输出）、链式（Agent按流水线顺序传递中间结果）、全连通（所有Agent都可互相发现并通信）。从工程稳定性角度，推荐以星型为主——中心Agent负责任务分发、结果汇总、容错处理，子Agent之间避免直接通信，这样可以极大降低通信链路故障的排查难度。
基于上述分析，我们给出一个简化但可执行的选型流程，适用于大部分业务场景：
第一步：评估是否需要外部工具调用。
如果不需要调用任何API、数据库或计算引擎，直接把CoT作为默认方案，零成本且响应最快。如果需要外部工具，进入第二步。
第二步：评估单轮任务的成功率预期。
如果业务场景中80%以上的请求在单轮ReAct + 工具调用后能得到满意结果，就不需要引入Reflexion或ToT。只有当失败率明显偏高且用户无法接受时，才考虑反射或多路径探索。具体判断方法：在测试集上统计ReAct的首次通过率，如果低于70%，考虑加Reflexion；如果仍不满意，再评估ToT。
第三步：评估任务规模与上下文需求。
如果任务需要读取超过2万Token的参考资料，或者需要对话历史超过数轮才能完成，那么考虑用Multi-Agent拆分任务，或使用外部存储来管理上下文。此时需要明确：拆分的收益必须大于通信开销，否则不做。
第四步：预估Token成本与延迟预算。
在选定候选方案后，用模拟数据做一轮成本计算。如果Multi-Agent的Token消耗是单Agent的8倍以上，且业务不支持这个成本，可以退一步使用简化版的ReAct增强（例如加入更详细的CoT提示词来降低错误率）。
以一个“智能工单系统”为例说明选型落地过程：用户提交一个技术工单，Agent需要理解问题、查询知识库、生成解决方案，并在必要时提交给人工审核。
这个案例展示了范式选型的核心思想：以ReAct为底座，Reflexion作为日常增强，ToT作为兜底机制，Multi-Agent仅在特定子任务中引入。最终效果是整体成本比全量使用Multi-Agent低了60%以上，同时关键指标（首次解决率）提升了20个百分点。
AI Agent的范式选型不是“多选题”，而是一道“组合优化题”。ReAct之所以是生产环境的中流砥柱，是因为它在成本、可控性与能力之间取得了最稳妥的平衡。ToT和Multi-Agent虽然在某些维度上表现惊艳，但它们的资源消耗与调试难度决定了它们必须被用在刀刃上。选型的核心法则是：从最简模型开始验证，以数据驱动决定是否升级，永远不要让架构的复杂度超过问题的复杂度。