为什么Agent架构选择比模型选择更重要
很多人在构建AI应用时花了大量时间对比GPT-4o和Claude哪个好，却忽略了一个更关键的问题：你的Agent用哪种架构模式来调度模型。模型决定了智商上限，架构决定了能力下限。一个用对架构的GPT-4o-mini，实际表现往往好过用错架构的GPT-4o。
Anthropic在2024年发布Agent构建指南时明确说了一句话：大多数AI应用其实不需要Agent，用单次LLM调用加工具就够了。真正需要Agent的是那些任务步骤不确定、需要根据中间结果决定下一步的场景。这个判断很实际。下面聊三种主流Agent架构，各自适合什么场景，以及选错了会怎样。
ReAct模式：推理加行动的循环
ReAct是Reasoning and Acting的缩写，2022年由Yao Shunyu等人在 Princeton 提出论文《ReAct: Synergizing Reasoning and Acting in Language Models》。核心思路是让模型交替进行思考（Thought）和行动（Action），每一步先推理自己该做什么，执行后观察结果，再决定下一步。
一个典型的ReAct循环长这样：
Thought: 用户想查上海明天的天气，我需要调用天气API
Action: get_weather(city="上海", date="2026-11-05")
Observation: 上海 2026-11-05 多云 18-25度
Thought: 拿到天气数据了，可以回答用户了
Answer: 上海明天多云，气温18到25度，适合外出。ReAct的优势在于灵活性。模型可以动态决定下一步做什么，遇到错误能自己调整方向。Yao等人的实验显示，在HotpotQA多跳问答任务上，ReAct比纯CoT（Chain of Thought）准确率高出约10个百分点，因为模型可以通过工具调用获取外部信息来补充自身知识。
但ReAct的代价也很明显。每一步都要让模型做一次完整推理，token消耗随步骤数线性增长。一个5步的任务意味着5次LLM调用，每次都要带上之前的完整上下文。成本方面，用GPT-4o跑一个5步ReAct任务，token消耗大约是单次调用的8-12倍，因为每步的上下文在累积。延迟也成倍增加，5步任务的总延迟可能是单次调用的5-8倍。
ReAct适合的场景：任务步骤不可预测、需要根据中间结果灵活调整、对延迟不敏感的后台任务。比如复杂的数据分析、多步骤的信息检索、需要试错的代码调试。不适合实时对话、简单查询、成本敏感的高频调用。
Plan-and-Execute：先规划再执行
Plan-and-Execute模式把Agent的工作分成两个阶段。第一阶段用大模型做全局规划，把任务拆成一系列明确的子任务。第二阶段逐个执行每个子任务，可以用更小更便宜的模型。
比如用户问”帮我分析竞品的定价策略并给出建议”，Plan阶段会输出：
1. 搜索竞品A的定价信息
2. 搜索竞品B的定价信息
3. 搜索竞品C的定价信息
4. 对比三个竞品的定价模型
5. 结合行业基准给出建议然后执行阶段依次完成每个步骤。
这个模式的好处是成本可控。规划用一次大模型调用，执行可以用小模型。LangChain在2024年的Agent文档中把Plan-and-Execute列为推荐模式之一，理由是它比ReAct更可预测，步骤数提前知道，不会陷入无限循环。
但Plan-and-Execute的弱点是不够灵活。如果第3步发现竞品C根本不存在，规划好的第5步”结合三个竞品”就执行不了。有些实现加了重新规划（replan）机制，执行中遇到偏差时回到规划阶段调整计划，但这又增加了复杂度。
适合场景：步骤可以提前预估的任务、需要并行执行子任务的场景、对成本敏感但能接受一定延迟的工作流。比如批量内容生成、多源数据汇总报告、定期数据分析。
Function Calling驱动：让模型自己决定调用什么
OpenAI在2023年6月推出Function Calling后，这成了最简单也最常用的”伪Agent”模式。你给模型一组工具定义，模型在对话中自主决定是否调用工具、调用哪个。本质上这不是Agent，而是单次调用中的工具增强。
它的最大优势是简单。一个API调用搞定，不需要维护多步状态，不需要循环控制逻辑。对于大多数应用场景，Anthropic的Agent构建指南说得对：这就够了。
OpenAI的Function Calling设计让模型输出结构化的工具调用JSON，比让模型输出自然语言再解析可靠得多。根据OpenAI官方文档，Function Calling的结构化输出格式让工具调用的准确率从自由文本模式的约85%提升到98%以上。
但单轮Function Calling处理不了多步任务。用户问”最近一周AI领域有什么大新闻，帮我总结成500字”，你需要先搜索再总结，一步搞不定。这时候要么用ReAct循环，要么用Plan-and-Execute拆步骤。
一个折中方案是Function Calling + 多轮对话。第一轮模型调用搜索工具，拿到结果后第二轮让它总结。本质上是手动版的ReAct，你能控制每一步，但需要自己写控制逻辑。
三种模式的成本和延迟对比
用一个实际场景来对比：用户要”查三个城市天气并找出最热的那个”。
ReAct模式需要5-7次LLM调用（每步一次，包括最终总结），每次上下文累积增长。用GPT-4o估算，总token约4000-6000，成本约$0.06-$0.09，延迟10-15秒。
Plan-and-Execute需要1次规划调用（GPT-4o，约800 token）+ 3次执行调用（可以用GPT-4o-mini，每次约200 token）+ 1次总结（GPT-4o，约500 token）。总token约1900，成本约$0.015，延迟8-12秒。比ReAct便宜4-6倍。
Function Calling方式需要2次调用：第一次并行查三个城市天气，第二次比较结果。总token约1200，成本约$0.01，延迟3-5秒。但前提是工具能并行调用，且任务不需要中间决策。
所以选型逻辑其实很清晰：能用Function Calling解决的不要上Agent，能用Plan-and-Execute解决的不要上ReAct。ReAct是最后手段，只在任务步骤完全不可预测时才用。
三个决策问题帮你选架构
第一个问题：你的任务能在一次LLM调用中完成吗？能的话用Function Calling，不需要Agent。90%的AI应用场景到这里就结束了。
第二个问题：任务步骤能提前列出来吗？能的话用Plan-and-Execute。好处是成本可控、步骤可审计、能用小模型跑执行阶段。
第三个问题：任务需要根据中间结果动态决策吗？是的话才用ReAct。用之前算好成本预算，设置最大步数限制，不然一个复杂任务能烧掉你一天的API额度。
还有一个实操建议：不管选哪种架构，都加上超时和异常处理。模型调用会失败，工具会返回错误，网络会超时。生产环境中最常见的Agent故障不是模型能力问题，而是某个工具调用卡住导致整个流程阻塞。设置每步超时30秒，整体任务超时5分钟，失败时记录上下文方便排查。
Agent架构不是越复杂越好。能解决问题最简单的那个就是对的。Anthropic的建议值得记住：先从最简单的方案开始，遇到瓶颈再加复杂度，而不是一上来就搭一个ReAct循环然后发现70%的请求其实一步就能搞定。
