LLM Agent五种核心模式与实战指南：从ReAct到多Agent协作

1. 为什么会问问题已经不够用了——LLM Agent模式的底层动因我最初接触大模型应用时走了很长一段弯路把提示词写得天花乱坠上下文塞满各种规则期待模型一次性输出完美结果。结果很现实——在稍微复杂点的真实任务面前单次对话的LLM表现就像一位只有短期记忆、从不检查作业的实习生开头思路清晰中间开始跑偏最后给你一个自信满满的错误答案。问题不在于模型不够聪明而在于单次推理的交互结构有天然的天花板。一个标准的LLM调用是输入一个prompt输出一段文本这个结构里没有反馈回路、没有工具调用、没有多步决策。可现实世界的问题往往需要多步操作先查资料、再推理、然后写代码、跑代码、看报错、再修……如果每一步都靠人把结果手动拼进下一轮prompt体验会非常糟糕。Agent模式解决的就是这件事把一次性问答改造成循环决策系统。模型不再只是回答者而是扮演一个能观察环境、决定行动、评估结果、调整策略的决策者。我的理解是LLM从知道很多到能办事中间隔着的正是这套循环结构——没有Agent这层骨架再强的模型也只是一本会说话的百科全书。这篇文章我会按实战视角拆解目前被验证有效的5种Agent模式ReAct、反思、规划、记忆增强、多Agent协作。每种模式都会讲清楚它解决什么问题、核心机制怎么转、适配什么场景以及我在调这些系统时踩过的坑。内容尽量不做纯理论复述只写我验证过、能落地的东西。2. ReAct模式推理与行动的交叉循环Agent的入门必修课2.1 为什么推理必须和行动绑定ReActReasoning Acting是目前几乎所有Agent框架的地基。它的核心思想很朴素让模型在思考Thought和行动Action之间交替进行每次行动之后把观察Observation反馈回来再继续思考。为什么要这么设计我自己的体会是LLM的内部知识是静态的——它训练时学到的世界会在某个时间点截止它在预测下一个token时也不会真的去查数据库、算算术、跑代码。如果只让它想它只能在肚子里编如果只让它做它就是没有方向的乱撞。ReAct把这两件事拆成交替的步骤恰好契合了人在解决复杂问题时的自然方式边想边做、边做边修正。举一个具体例子。用户问帮我查一下昨天的天气并且和去年同一天比一比如果只靠单次prompt模型大概率会编一个天气数据因为它无法真正访问天气API或者承认自己不知道。而在ReAct模式下模型可以先生成Thought我需要查询昨天和去年同一天的天气数据先调用天气API然后生成ActionSearchWeather(城市北京, 日期昨天)等API返回结果后再生成下一步Thought昨天是晴天现在查去年同一天再调用API……直到拿到两组数据后最后生成Final Answer对比两者差异。关键在于这个循环不需要人干预。所有Thought和Action都由模型生成工具结果自动注入上下文模型再基于新信息继续下一步。这等于在LLM外面套了一圈传感器执行器让它可以感知真实世界的反馈。2.2 最典型的ReAct工作流长什么样我用一个实际搭建过的搜索问答Agent来拆解ReAct的完整运行过程。假设任务是帮我整理某开源项目最近三个月的版本更新亮点。第一轮循环用户输入任务描述。系统组装系统提示词明确告诉模型你有SearchWeb、FetchPage两个工具可用。请按Thought → Action → Observation循环执行直到收集足够信息后输出Final Answer。模型生成Thought我需要先找到该项目的仓库主页或发布页面。模型生成Action以结构化文本或JSON格式{tool: SearchWeb, query: 项目名称 releases 2025}。Agent框架拦截这个JSON执行工具函数SearchWeb返回搜索结果列表。框架把结果追加到上下文作为Observation。第二轮循环模型看到Observation生成新的Thought搜索结果里有官方发布页面我需要抓取这个页面的内容。生成Action{tool: FetchPage, url: https://xxx/releases}。框架执行FetchPage返回页面正文文本可能是Markdown转纯文本。Observation追加回上下文。这样反复几轮后模型觉得信息够了就会生成Final Answer对整个Agent循环终止。这种Thought/Action/Observation的三元组格式不同框架的叫法略有差异有的叫Reasoning/Action/Result有的直接让模型输出JSON但本质一样。实现时最大的坑是Action的格式解析。如果是用纯文本输出工具调用大模型经常会把引号写错、字段名写歪、甚至嵌套错JSON。我建议直接在提示词里给一个工具的调用schema要求模型严格按JSON输出然后再用JSON解析器去解析解析失败就重试一次。实测这样能把工具调用出错率从百分之十几降到个位数。2.3 ReAct的局限很容易陷入空转ReAct虽好但在做复杂任务时有个明显问题——它每一步都要靠模型现想而模型的推理路径可能很长、又不稳定。我自己在跑一些多步任务时经常看到模型在一个问题上反复横跳同一个搜索query换个说法搜了三次或者连续调用同一个工具却不改变参数。原因很简单ReAct没有全局规划的概念。模型每一步只看到当前观察像在一个迷宫里只靠手电筒照眼前几米的路很容易原地绕圈。这一步部分是提示词的问题可以在system提示词里加不要重复相似动作部分是模式本身的局限。另外ReAct会消耗大量token。每一步的Thought、Action、Observation都会往上下文里塞内容一个看起来简单的任务跑下来调用token经常比我预想的多5-10倍。如果你的项目对延迟和费用敏感后续要思考是否值得用更结构化、更省token的约束方式。ReAct目前最适合的场景在我看来是任务有明确的信息获取或工具操作需求步骤数量不多3-8步且每一步的反馈比较明确。比如搜索问答、工具调用、简单的API编排、SQL查询生成等。它还非常适合做最小可用Agent的起步方案——因为它不需要额外的规划模块或记忆模块一个模型几个工具函数就能跑起来。3. 反思模式让模型当自己的教练用批判-修改循环替代一次定稿3.1 单次生成和自我修正之间的差距如果你试着让同一款大模型回答一道复杂的数学题或者写一段带并发处理的Python脚本大概率会得到第一印象级别的答案看着像模像样但中间藏着至少一个逻辑漏洞或隐藏bug。这不是模型笨而是自回归生成机制本身就决定了——生成第二句话的时候模型并不知道第一句话会在10步之后埋下什么样的错误。反思模式Reflection的思路很直接不让模型一次生成最终答案而是让它先产出草稿再以批判者的身份去评价自己的草稿找到漏洞最后根据批判意见生成修订版。这就像写文章要写初稿、自审、改稿一样——通过把生成者和评估者两个角色分离避开自己给自己挑错的心理障碍。这里的核心洞察是让同一个模型扮演评估者并不是让它重新做一遍题而是给它一套评估标准。你在prompt里给它一个清晰的检查清单比如是否考虑了边界条件是否遵守了输出格式是否有逻辑跳跃它会按清单逐项对照找出问题。这比让它再仔细想想有效得多。3.2 一种最简单的反思循环实现方式我写过一段极简的反思Agent用两个阶段的prompt就能搭起来核心逻辑伪代码如下# 阶段一草稿生成 draft_prompt f请完成以下任务 {task} 要求 - 给出完整、可直接运行的方案 - 不要解释你的思路 draft generate(draft_prompt) # 阶段二批判评估 critique_prompt f请扮演一名严格的代码审查专家对以下答案进行审查。 任务原文{task} 待审查答案 {draft} 请逐项检查 1. 逻辑正确性是否有推理漏洞 2. 边界条件是否遗漏了空输入、极端值、并发冲突 3. 完整度是否漏掉了关键步骤 4. 可读性方案是否清晰 输出格式 - 先列出每个问题点带编号 - 最后总结需要修改的关键点最多3条 critique generate(critique_prompt) # 阶段三修订 revised_draft generate( f这是你的草稿{draft} 这是审查意见{critique} 请根据审查意见重写答案保留原有方案的长处修复所有指出的问题。 )三段式用完大多数任务的答案质量都会有明显提升——尤其适合代码生成、技术方案设计、复杂写作。我实测过一个案例让模型写一段处理Excel的Python脚本草稿版本表头判断逻辑有bug反思循环后修订版本把异常分支补全了还主动加了空文件检查。这就是自我修正的价值。3.3 反思模式的三种进阶姿态三段式是入门。进阶玩法有很多变体我在不同项目里用过三种效果差异很大第一多轮滚动反思。草稿→批判→修订后再把修订稿再扔回批判阶段如此迭代N轮。理论上能持续改善但实际上迭代到第3-4轮之后提升非常有限消耗的token却线性增长。我的经验是除非任务对正确性要求极高比如生成SQL、正则表达式否则两轮反思就够了第三轮边际收益约等于零。第二测试驱动的反思。对代码类任务比模型自己审自己更可靠的是让模型写测试、跑测试、按测试结果修改代码。这里反思的批判者不再是模型而是真实运行环境。我在一些代码生成Agent里就是这么干的让Agent生成代码→自动构造单元测试→运行→把失败的测试信息喂给模型→修改→重跑。这个循环往往比纯模型自我批判收敛快得多因为它有真实的地面真值ground truth反馈。第三双模型互审。用两个不同倾向的模型交替扮演审查者。比如让一个更细致的小模型做批判大模型做修改因为批评和修改其实需要不同的能力特性。不过这种方式成本偏高适合对质量要求极高的离线任务不适合在线交互场景。反思模式的代价也很清楚每次循环都是多次模型调用延迟和费用会成倍增加。对于一次问答这种实时任务如果模型首轮回答质量已经不错再加反思循环性价比就很低。我通常只把它用在质量优先、延迟不敏感的场景离线处理、批量生成、代码修复、复杂方案设计。4. 规划模式把大任务拆成可执行子任务用先计划后执行消灭瞎忙4.1 规划和单步执行的本质区别如果你需要Agent完成一个包含多个步骤、步骤之间有依赖关系的任务比如调研一个行业→整理数据→生成一份分析报告你会很快感受到ReAct的局限。ReAct的问题是它没有全局视图——每一步都是走一步看一步走到第三步时可能已经忘了最初的立项目标。规划模式Plan-and-Execute的思路正好相反先让模型把大任务拆解成一系列子任务plan再按顺序、或按依赖关系逐一执行这些子任务。执行阶段甚至可以用专门的执行器来完成不一定非要模型自己动手。换句话说规划者负责想清楚做什么执行者负责具体怎么做。这种想和做分离的模式我更愿意用项目管理来类比ReAct像一个边看边做、随时改方案的自由职业者规划模式则像项目经理先出甘特图再分配给不同执行者照着干。对于复杂度较高的任务后者明显更可控。4.2 一次典型的规划Agent执行流程我把一个行业研究报告生成Agent作为示例展示规划模式的工作方式。第一步输入任务分析新能源汽车充电桩市场的竞争格局输出一份3000字的分析报告。第二步规划器LLM生成计划1. 搜索充电桩行业最新市场报告提取市场规模数据依赖无 2. 搜索主要玩家厂商A、厂商B、厂商C的公开动态依赖任务1 3. 搜索政策环境相关信息依赖无 4. 汇总以上信息形成竞争格局分析框架依赖1、2、3 5. 撰写3000字报告包含市场规模、竞争格局、政策影响、趋势预测依赖4第三步执行器逐个或按拓扑序执行子任务。每个子任务执行完后把结果存入一个任务结果容器。第四步后续任务读取前面任务的结果作为上下文继续执行。第五步第5个子任务汇总所有结果生成最终报告。这个流程有两个关键设计一是计划是显式的、可修改的——如果某个子任务执行后发现信息不足可以回溯修改计划二是任务之间的依赖关系由计划决定而非执行时随机应变。4.3 计划-执行的依赖处理技巧真正做规划模式时难点不在拆解计划而在管理任务之间的依赖。我踩过几次坑后总结出几套处理方式串行依赖最朴素的方案按计划线性执行前一个任务的输出作为后一个任务的输入。简单可控但浪费了并行机会。并行依赖计划生成后做一次依赖分析筛选出相互独立的任务批次并行执行再在依赖点同步。这能明显缩短总时间但需要额外的调度器。比如上面的任务2和任务3互相独立可以和任务1并行。动态依赖更高级的做法在执行过程中允许模型根据中间结果调整后续计划。相当于计划-执行-再计划-再执行的双循环。这更接近真实工作流的灵活性但也更容易跑飞——毕竟每一步都可能改变原定路径任务的完成时间会变得不可控。我自己做过的某项目中用了一个简化版的规划模式把计划冻结在内存里每个子任务有独立的状态pending/running/finished/failed执行器遇到失败子任务会先重试如果连续失败超过N次就触发重新规划。这个设计在稳定性上比完全动态规划好很多至少在任务失败时有一个明确的兜底路径而不是让模型自由发挥。规划模式适合的场景一句话总结就是任务结构相对清晰、步骤明确、需要稳定产出的场景——比加业务报告生成、数据流水线、长文写作有明确章节结构、多源信息聚合。它不太适合探索性极强的开放式任务因为那些任务连自己也说不清下一步要干嘛。另外规划的token成本是一次性的——虽然比ReAct多了一次规划调用但执行阶段通常更节省总体费用反而可能更低。5. 记忆增强模式给Agent装上持久记忆力从金鱼进化为真正的助手5.1 上下文窗口不是记忆它只是一张便利贴很多人把上下文够长等同于Agent有记忆这是一个我在实践中反复纠正过的误解。上下文窗口确实能放进去很多内容但有几个致命问题一次对话结束后上下文就丢了。下次会话从零开始。即使在同一会话里一旦上下文塞满最早的信息就会被挤出去。上下文越长模型聚焦关键信息越困难——它的注意力会被无关细节稀释。真正的记忆增强是把信息存储到Agent系统外部向量数据库、文件、缓存在需要的时候动态检索并注入上下文。这就像做笔记而不是死记硬背重要信息永远在笔记里但每次思考时只把相关几页翻出来看。这项技术最通用的形态就是RAG检索增强生成。RAG的思想很简单不要试图把所有知识塞进prompt而是把资料向量化存储用户提问时先做语义检索把相关的几段内容取出来再一起交给模型。5.2 一个最小可用的记忆层怎么搭我搭过好几版记忆增强Agent最终沉淀下来一个比较顺手的最小架构向量库选型小规模项目直接用轻量级向量库比如sqlite-vec或chroma大规模再上专业的向量数据库。记忆类型拆成两路短期记忆当前会话内的历史消息、用户偏好、中间决策结果以列表或摘要形式保存随对话持续更新。长期记忆跨会话的用户画像、历史任务结果、领域知识持久化到向量库按需检索。写入规则不能什么都往记忆里塞。我现在做的是先摘要后存储——每当对话到达某个关键节点触发一次摘要生成把当前会话的重要信息压缩成几百字的摘要存入记忆库。这个机制避免记忆库被冗余信息污染。读取规则在每次模型调用前根据当前用户输入做一次语义检索取出Top-K条记忆片段混入上下文。K一般取3-5太多会重演上下文过长的问题太少又发挥不了记忆的作用。我做过一个很简单的测试来验证记忆增强的效果让Agent记住用户的偏好我不喜欢甜食写菜谱时不要放糖。无记忆的Agent每次新会话都要重新交代一次有记忆的Agent第二次会话就能自动规避甜食。直观感受到的差别非常大。5.3 记忆增强的隐性坑噪音比遗忘更要命很多人担心Agent会忘记信息但我实际使用下来真正影响体验的是检索噪音。当你检索Top-K条记忆时经常会把不相关的旧记忆也抓进来而这些噪音记忆会误导模型让它产生答非所问的效果。我踩过的一个具体坑是在调研类Agent里给用户推荐过的旧资料片段被检索出来模型误以为用户还在关注旧话题结果新问题的回答明显偏离了主题。复盘发现就是检索阶段的关键词匹配出了问题。解决方式我总结了几条metadata过滤每条记忆存储时打上标签来源、时间、任务类型、关联实体检索时先按metadata过滤再向量检索。这比纯语义检索靠谱得多。时间衰减权重越新的记忆权重越高新会话时旧记忆的排序排在后面防止陈旧信息占据太多注意力。摘要分级长期记忆存摘要的摘要而不是原始对话原文细节放正文概要放标引层。这样检索时能更快定位到真正有用的内容。记忆增强模式适合一切需要延续性的Agent个人助手、客服系统、学习辅导、用户偏好分析、跨会话项目管理。它通常不是独立存在而是和其他模式组合使用——比如ReAct 记忆增强让每一步行动都能参考历史经验。我的经验是任何打算长期使用的Agent都要认真考虑记忆层否则它对每个用户永远是第一天认识你的陌生人。6. 多Agent协作模式让多个模型各司其职像团队作战一样解决问题6.1 为什么要让多个Agent协作而不是造一个全能Agent单个Agent的能力上限不是由模型决定的而是由它的单一身份和单一上下文决定的。一个Agent既要负责规划、又要负责执行、又要负责审查——角色过多时往往哪个都做不精。尤其在复杂任务里模型的注意力会被不同角色的要求扯碎。多Agent协作的思路是把任务拆给多个各司其职的Agent每个Agent有独立的角色设定、工具集和上下文它们通过消息传递互相配合。像一支小型创业团队产品经理负责需求拆解、工程师负责代码实现、QA负责测试、设计师负责界面设计——大家各管一摊消息互传最终拼出完整结果。我特别认同一个类比单Agent更像全栈工程师开发一个项目多Agent更像一支敏捷团队开发同一个项目。全栈工程师能力越强、什么都能干但项目复杂后一个人同时切换多个角色上下文效率会急剧下降。而敏捷团队每个角色只需要聚焦自己的那一块消息通过标准接口传递反而更能保持状态清晰。6.2 一种常用的编排方式角色群聊这里我用一个Web应用开发团队的Agent架构作为例子来说明多Agent协作的实际形态。用某框架比如AutoGen风格的对话调度创建四个角色ProductManager规划需求拆解任务Developer编写代码调用代码执行工具Tester运行测试报告bugDesigner生成UI描述执行时会经历类似这样的对话流PM用户需要做一个带登录页面的待办事项应用。需求拆解为1. 登录功能2. 待办增删改查3. 数据持久化。Developer收到需求创建项目结构编写登录页面组件和后端API代码。代码执行后返回结果Tester运行了现有测试发现登录接口在空密码时返回500错误。报告给Developer。Developer修复空密码校验逻辑补充测试用例。循环交替……这个过程中每个Agent的上下文都只包含和自己角色相关的内容。Developer不需要知道UI配色细节Tester不需要理解业务需求全貌。这正是多Agent的效率来源——上下文隔离度越高各自专注度越好。6.3 多Agent协作的三条实战经验多Agent看着很酷落地起来却非常容易失控。我在做某模拟项目时总结了不少经验第一消息传递结构比角色数量重要。很多人以为Agent越多越强结果十个Agent互相扯皮收敛极其困难。我实测发现3-5个Agent基本是甜点区超过7个消息流转的复杂度呈指数上升产出反而下降。关键是设计清晰的消息流——谁和谁能对话谁只接收不回复必须有明确规范。第二用管理者-执行者替代全员自由讨论。全员自由讨论是灾难的开始每个人都想发言最终话题岔到天边。更好的结构是一个Manager Agent负责拆解任务、分派消息、汇总结果其余Worker Agent只和Manager交互不做横向通信。这等于给团队加了一个项目经理避免混乱。第三给每个Agent独立的工具权限但统一的输出约束。比如Developer能执行代码Tester能运行测试脚本但所有Agent都必须输出结构化消息JSON消息必须包含sender、receiver、action、payload等字段。这样调度器才能可靠地路由消息而不是靠模型自觉。多Agent协作最适合的场景非常明确复杂软件开发、多角色内容生成研究写作校对、模拟仿真如商业场景的角色扮演推演、复杂任务流水线。它的代价也最明显成本高、延迟高、调试难——每个角色都是一个独立模型实例整个系统的token消耗呈倍速增长。所以我通常建议先确认能不能用单Agent 规划模式解决确认解决不了再上多Agent。多Agent是最后的选择不是第一的选择。7. 面对真实项目时如何从5种模式里选出合适的组合7.1 五种模式的选型决策表不同模式的取舍我整理了一张选型表这也是我个人在项目启动时参考的判断逻辑模式核心机制最擅长解决的问题最大短板典型费用/延迟特征适合任务类型ReAct推理-行动-观察循环信息获取工具调用易空转无全局规划单轮token消耗小但轮次多搜索问答、API调用、轻量任务反思生成-批判-修改循环初稿质量不高需自我修正多轮调用成本翻倍3次调用起步费用高代码生成、技术方案、复杂写作规划先拆解再执行任务依赖管理多步骤、多依赖的复杂任务计划僵化探索性差规划一次执行多次总体可控报告生成、数据处理流水线记忆向量检索持久存储需要跨会话延续性的场景检索噪音会误导额外存储检索成本个人助手、客服、偏好建模多Agent多角色分工协作需要角色分离的复杂项目成本高、调试难、易失控多个模型实例并发成本最高软件开发、多人协同模拟7.2 我从踩坑里归纳的组合套路单一模式用久了会发现真实项目几乎都是复合模式。我把最常用的组合套路写出来供参考第一ReAct 记忆。这是最稳妥的起步组合。ReAct负责工具调用和行动决策记忆负责提供历史背景。搭一个常见的客服机器人就会用到用户问我之前报修过什么问题Agent先从记忆库检索该用户的历史工单然后带着这些信息调用工单系统的API查询当前状态。没有记忆的ReAct做不了这件事没有ReAct的记忆只能做答疑机器人。第二规划 反思。这个组合适合高质量长文输出类任务。先让规划器拆出文章大纲规划每一章由生成器写初稿再用反思循环做批判和修订。我发现这类组合产出的文章质量明显高于单次生成尤其是有明确论证结构的任务行业分析、竞品调研、技术选型评估。第三多Agent 记忆。这是最重型的模式。每个子Agent都绑定一个共享记忆库其中一个Agent负责把每轮关键结论写入记忆。适合那种跨多天、持续进展的大型任务比如一个持续追踪某个行业动态的系统每天定时唤醒从最新资讯中提取变化并存入记忆库多个分析Agent分别关注不同维度最终由汇总Agent输出周报。7.3 决策时的三条理性建议经验之谈面对一个新项目决策顺序建议这样先用最便宜的方案验证核心链路。别一上来就搭多Agent。我的习惯是先手工模拟一遍Agent流程实际调用LLM API逐轮调试确认每一步的提示词都能稳定产出预期结果再考虑封装框架。先让流程跑通再谈模式升级。按错误代价选模式。如果任务的错误代价低写个文案、取个昵称单次生成就够了别加反思如果错误代价高生成SQL、写正则、重构代码必须上反思而且最好是带测试反馈的那种如果任务跨度大、周期长规划模式是刚需。模式的价值取决于你对错误的容忍度。警惕过度Agent化。有些任务明明一个查询就能搞定硬要拆成规划执行反思多Agent纯粹是无谓消耗token。我发现一个很有效的判断标准如果一个人在熟练状态下10分钟内能做完就不要用10层Agent编排如果一个人需要好几个小时、还要来回查资料、反复修改那才值得Agent化。8. 实操经验我在跑Agent项目时反复踩过的四个隐形陷阱8.1 Token成本失控预算悄然翻倍Agent最大的隐性成本不是模型单价而是循环次数。我跑过一个ReAct任务本来预计8轮完成结果模型在一个搜索query上卡了5轮反复换措辞搜索最终token消耗接近预算的三倍。控制成本我目前觉得最有效的做法是对每轮操作设置最大次数比如最多8次工具调用超过就强制进入收尾阶段工具输出做截断——网页抓取只保留正文开头几千字符不要整页塞进去每轮循环后把Observervation做一次压缩总结再放回上下文避免上下文无限膨胀。8.2 提示词里没约束工具的边界后果很严重这也是血泪教训。有一次我没在系统提示词里限制工具调用范围Agent居然尝试调用了一个不存在的工具名然后不断报错重试白白浪费了大量token。后来我在所有Agent提示词里都强制加这几条明确列出可用工具清单和用途明确说明不可调用列表之外的任何工具工具参数必须符合schema违背则直接报错并不重试。8.3 评估Agent质量比评估模型回答难一个量级单次回答可以用是否包含关键信息来判断质量但Agent是多步决策过程每一步都可能出错。我发现最有效的评估方式是过程指标 结果指标双轨制过程指标工具调用失败率、无效循环次数、平均每任务轮数、上下文膨胀速度结果指标最终答案准确性、任务完成率、用户满意度先盯过程指标。过程指标稳定了结果指标基本不会太差过程指标烂结果时好时坏都是运气。8.4 不要迷信最新框架回到问题本身最后一条经验可能有点反直觉Agent项目失败十有八九不是框架不够强而是我对任务的定义不够清楚。框架只解决如何编排解决不了任务到底要做什么。我在做一个信息聚合类Agent的时候换了三个框架才意识到真正的问题是我连最终输出的报告到底给谁看、需要什么深度、格式是什么都没想清楚。把这些问题定义明白之后我用最基础的ReAct提示词就解决了根本不需要上多Agent。先想清楚任务边界再选模式别让框架替你想问题。如果你正打算用一个LLM Agent项目我的建议是先画清楚你的任务流程图——有哪些输入、有哪些工具、每一步的输入输出是什么、哪里可能出错。这张图画出来模式选择其实是水到渠成的事。前面讲的5种模式它们不是互相竞争的关系而是像工具箱里的不同工具真正的高手是按需组合、按场景切换不是抱着一种模式走天下。