什么是Agent一个粗略的解释Agent就是一个能聊天、能思考、智商250的机器人有手有脚能够执行具体动作或者说以下几种概念之一一个更聪明的聊天机器人一个能够自动去调用工具进行实际操作的llm一个听起来比workflow更高级的说法更完善的定义从工程角度来看Agent就是一个围绕实现目标/问题持续推进执行任务的系统具备的能力接收目标/用户输入的问题不是简单的单轮对话不是简单的输入Agent是有上下文工程的上下文工程提示词工程形成了记忆层那么Agent是有记忆功能的在不撑爆上下文的情况下都属于这一轮对话。这个其实就是Memory实现的在下面会详细讲解根据中间结果决定后续的操作,在需要时调用工具将接收到的目标交给llm进行思考总结、压缩、排序上下文然后拆解任务明确需要调用的工具交给执行层去执行执行得到的结果就进入下一轮循环把该结果、执行的错误信息放到记忆层进行下一轮思考直到实现了目标就不再进行循环即得到了结束条件就输出结果停止循环所以Agent更强并不是模型更强模型本质上还是市面上比较牛逼的llm更重要的是执行目标的系统闭环更完整了就是说他能够更精确完成用户的目标而且能够进行实际的操作Agent没有我们想得这么神在大多数的工程场景下更应该把Agent看成一个由llm大模型驱动的、可以根据当前状态/执行结果决定下一步动作该如何执行的任务执行系统很多使用的Agent并没有我们想得这么高大上只是比普通的ai聊天机器人多了几个关键的能力Agent的最小闭环先看最简单的Agent闭环不需要考虑复杂框架举个例子分析今天某A股是否存在异常风险一个最小Agent的工作流程接收目标分析A股是否存在风险大模型去读取当前任务目标和已有上下文思考需要获取什么市场信息调用工具查询K线走势、成交量、波动幅度、相关新闻返回结果根据返回结果更新状态信息不足循环回去再思考看缺什么继续补充查询信息信息充足输出结果停止循环核心围绕目标不断地推进任务执行Agent你可以认为他只有一个目的就是精确地实现你的需求Agent和普通LLM App的区别普通LLM App通常就是一次响应Agent他是一个循环是持续执行的知道满足目标再停止循环Agent通常包含什么一个完善点的Agent通常包含以下部分state当前任务状态Tools查询、搜索、执行、写入等外部功能Memory会话内或跨会话记忆Policy / Guardails限制不要乱进行操作Evaluator判断结果是否足够好越接近真实业务需求这些模块就越重要有一个坑市面上现在很多Demo只要实现了大模型调用工具这个功能就自称Agent但是如果你这个系统没有明确的状态没有明确且完整的闭环没有明确的结束条件无法根据每一步执行得到的结果去进行调整对下一步进行操作其实就仅仅是一个内置了很多工具的LLM而已未必就是一个完整的Agent判断一个系统是不是Agent不需要看他用了什么框架、也不需要看他会不会调用工具就从最基本的概念去看是否能围绕目标持续推进任务执行是否会根据中间状态的改变而改变下一次操作的行为是否为一个闭环系统不是一次性生成结果的总结Agent的核心是有手有脚能够真正做出执行功能一个真正有价值的Agent更看重的是系统层面能处理的事情对任务进行拆解多步任务感应外部环境的变化从而做出改变调用工具实现工具协作状态更新改变行为在不确定条件下进行决策预测workflow和Agent的区别这个问题是在学习Agent的时候最容易混淆的一个问题之一至少有三类不同的系统普通LLM AppAgentWorkFlow判断标准普通LLM App一次输入一次输出例如问答助手deepseek、豆包摘要工具翻译工具结构化信息抽取问答很直接但是涉及多步执行的复杂问题就不行了通常不负责多步执行WorkFlow执行路径主要由开发者预先定义好Agent他是自身是已经定义好了执行路径的workflow是可以通过用户/开发者来自定义的举个例子先检索再总结再格式化输出收到工单后分类、路由、写评价输入简历后抽取信息、评分、写评价workflow很有价值而且在很多业务中workflow就已经足够了Agent系统会根据中间状态/中间过程得到的某个结果来决定自己下一步该如何进行任务执行操作执行路径是由每一次任务执行后得到的结果进行状态更新后去判断的判断到底走那一条执行路径真正的区别在于下一步的执行路径是根据上一步得到的结果来判断的还是说已经确定好了几乎写死的workflow的大部分执行路径已经由开发者制定好了那么就可以认为是写死的而Agent下一步该做什么会由上一步的执行结果来决定就是系统会在运行的过程中去判断下一步该如何执行举个例子分析某个A股今天是否有异常风险workflow开发者可能已经提前写好执行流程了拉取近一周的数据价格拉取成交量拉取相关的新闻拉取走势图把这些统统交给LLM进行总结判断输出风险等级这个系统一样是将一个目标拆分成多个任务进行多步执行系统进行多步执行但是他的路径是基本已经确定了Agent先看价格是否正常价格正常就看成交量不正常就直接返回结果成交量正常就看相关新闻消息成交量不正常就直接返回结果查不到相关新闻消息或消息不足就看走势图并且社交媒体上进行查找得到足够的信息后就返回结果很显然跟workflow的区别是下一步操作一直依赖于上一步的执行结果虽然和workflow一样都是分步执行多步骤实现目标但是他的路径是很灵活的并没有写死这就是典型的Agent行为为什么在一些业务场景workflow就足够了不需要用到Agent呢输入稳定(就是输入的目标比较明确)处理步骤固定不会出现很多分支情况分支数量有限输出结果格式明确这种场景下使用workflow更便宜更稳定更可控如果非要使用Agent成本更高延迟更长不稳定调试困难落地麻烦所以不是说一定要使用Agent而且不是说Agent越高级越好需要通过对要实现的目标进行拆分判断到底使用哪个判断方法在设计系统前即在决定使用Agent还是使用workflow前先想清楚四个问题任务步骤是否基本固定执行路径是否大多可预先枚举。即执行路径是否已经可以大致确定下来模型是否只负责生成不负责决定流程即不需要依赖上一步执行得到的结果是否自已稳定性、可控性、成本而不在意灵活性如果基本满足以上条件的话就直接选workflow是否需要根据中间结果来动态选择工具是否需要在信息不足的时候继续探索是否需要围绕目标持续进行任务执行推进而不是一次性回答是否存在开发环境和不确定决策如果基本满足的话就直接选择Agent关系在实际工程中Agent和workflow往往是组合关系而不是对立关系不是二选一的常见的方式是外层用workflow控制主流程某些节点内部用Agent例如主流程接受任务-选择任务类型-调用不同处理模块某个处理模块内部用Agent做信息探索和多步分析总结如果是确定了工作流程的有确定性流程的那么就使用wokflow如果是负责不确定环境下的动态推进那就使用AgentAgent的核心组成不要直接就去看框架代码我们得先进行系统的拆分否则就是即使你成功跑出了一个Demo但是你也说不明白他的逻辑哪部份负责决策哪部份负责保存状态哪部份负责调用工具哪部份负责限制系统乱跑如果这些问题你弄不清楚当后面系统复杂了就很难维护了不要直接去看框架不要从框架开始先从细小的模块开始一个最小但是比较完善的Agent五脏虽小麻雀俱全的Agent一般都包括Goal目标State状态Model模型Tools工具Memory记忆Planner/policy决策逻辑Evaluator / Guardrails评估与约束不是每个Agent系统都要对这些模块进行完整的拆分但是你的脑子里得有这种图Goal目标系统到底在实现什么目标的定义用户的需求任务要解决什么问题输出的格式长什么样任务处理到什么程度算完成如果目标本身不清晰Agent往往表现会做很多无关的动作会进行无限探索输出看似很多很努力但是没有实际有用的内容所以很多Agent的问题并不是模型不够强而是目标定义不够清晰State系统当前处于什么状态每执行一次得到的结果就会被更新为当前最新的状态这个状态决定着下一步该如何执行他可以包含当前任务输入已完成的步骤已获取的信息中间分析结果下一步待办是否满足结束条件如果没有明确的状态系统每次执行就没有明确的依据没有明确的限制每次执行都像是从头开始上下文混乱重复调用工具无法回复执行很难调试所以Agent框架强调的是维护方便可维护Model负责理解、推理和生成模型本身通常负责下面几类工作理解任务解释上下文决定下一步动作生成结构化结果生成最终数据模型只是Agent的一个核心组件Tools工具让Agent获得外部超能力没有工具的Agent能力边界是非常狭窄的工具包括搜索数据库查询API请求文件读写代码执行外部系统操作工具解决的是仅靠模型本身无法实现的事情因为模型是预先训练好的他自身是没有办法获取实时数据的所以通过调用工具就可以知道实时的A股价格Memory 让系统不会总是失忆记忆可以分为两种用于当前任务过程中的状态延续例如会话内记忆已经查询过哪些数据前面做过哪些判断当前分析到哪一步任务跨会话记忆用于长期偏好、历史记录或用户画像例如用户关注哪些风险指标过去的分析习惯历史结论和反馈大多数Agent需要的都是会话内状态的记忆Planner / Policy决定接下来做什么就是根据当前最新的状态/上一次执行的结果来决定该次如何执行走哪一个分支进行任务执行这也是workflow和agent的最大差别workflow是不需要去想走哪一个分支的下一步是否需要工具需要哪一个工具是否还需要继续收集信息什么时候停止返回最终结果在简单系统中这部份可能只是一个prompt但是在复杂系统中他可能会变成一套显式的状态机、策略函数或图结构Evaluator / Guardrails防止系统看起来工作实际上已经失控了这部份通常会被Demo忽视所以才导致Demo不稳定而且真实系统也离不开这个模块通常负责检查输出格式是否正确检查证据是否充足就是是否有足够的信息返回最终结果检查结果是否越权控制成本、稳定性、延迟和工具调用的次数在必要时触发人工接管如果没有这些约束Agent就会一本正经说废话给出错误结论为了完成任务不断尝试不断调用工具甚至重复调用工具导致时间和成本直接拉爆所有模块串起来就是一个典型的Agent系统理解成下面这个执行流程Goal :- State 系统状态初始化- Planner 做出决策判断下一步要执行什么操作- Model 生成动作或参数- Tools 执行外部动作- State 将执行得到的结果更新为最新状态作为下一次执行的依据- Evaluator 检查结果- 继续循环或返回最终结果这个表格很重要建议在进行Agent开发的时候不要急着选什么框架核心是分析清楚问题目标是什么状态里面放什么哪些能力需要通过调用工具来实现哪些决策要交给模型处理哪些决策可以交给代码进行决策什么时候结束循环返回结果什么情况下导致失败什么情况需要人工介入总结Agent是一套模块化协作的系统一定要弄清楚模块间的边界关系为什么Demo一落地就不稳定很多人第一次跑Agent的时候都会经历本地能跑调用工具也正常甚至样例也通过但是 当你觉得你的系统差不多可以了当把他放到业务场景后就会出问题任务复杂就会乱跑结果不稳定调用工具成本高运行时间不可控一出错就不知道卡在那个地方因为Demo是独立的和真实的业务系统关注的问题不在一个levelDemo关注的是能不能动一个Demo只需要证明模型能理解任务工具链能接通系统能完成一个示例流程所以Demo就会偏向于乐观输出,认为工具调用是允许的没有权限问题成本是最低的短链路调用少量工具单次样例成功所以Demo放到真实的业务系统中可能成功也可能失败不能证明这个Demo是长期可行的真实的系统关注的是会不会坏能不能解决真实问题用户输入是否稳定外部数据是否可靠工具调用是否会失败系统是否会重复做无效动作出错后能不能恢复成本和延迟能否接受即真实系统追求的是长期稳定在多数情况下都能保持稳定执行常见问题1.目标定义模糊很多Demo的目标的定义都很宽泛帮我完成xxx任务帮我分析市场风险给出这个研究的结论说白了就是连prompt都不会写的那么目标不清晰就会导致系统不知道执行到什么时候才结束探索的范围一直扩大不断膨胀输出的标准不稳定所以想写好一个Demo关键是先明确好目标把目标写清楚了常见问题2.状态没有设计很多Demo就是把所有的信息一口气全都塞进Prompt中然后不断不断写短任务/简单任务可以跑但是长任务/复杂任务就会出问题中间结果没有结构化保存那么下一步执行的操作就没有依据了系统会忘记已经完成了什么任务执行到哪一步了同一个工具会被重复调用执行中断后无法恢复这也是为什么State是Agent中最核心的一个模块如果State处理得不好就会导致整个系统的瘫痪常见问题3.工具调用会被过度乐观地看待在Demo中调用的工具通常会被看待成一定可用返回格式一定稳定延迟可以接受没有权限问题但在真实的系统中API会超时数据格式会发生改变权限失败返回结果会为空或部份丢失如果你设计的系统没有重试、降级、兜底和错误处理Agent就会很脆弱常见问题4.把会思考误认为是可执行模型很擅长生成看似很合理的解释但这不表示他就真正完成了任务例如说自己分析了但是没哟真正调用工具说证据充分但实际上信息不足说已经完成了实际上没满足业务标准所以在真实系统中不能只看生成的文本还要看执行了什么用了哪些数据每步的结果是否可验证常见断层 5没有结束条件和预算控制Agent 一旦进入循环如果没有明确约束就可能不断尝试再查一个数据源再补一次搜索再换一种问法再试一次工具这在 Demo 里看起来像“努力”在真实系统里就是成本失控延迟失控用户体验崩掉所以一个可用 Agent 必须有预算和边界例如最多调用多少次工具最多运行多少轮超过多长时间必须退出证据不足时是否直接转人工常见断层 6没有可观测性如果系统出错了但你只能看到最终一句“任务失败”那几乎没法维护。至少应该能看到每一轮状态每一步决定每次工具调用错误原因最终退出条件这也是为什么很多 Agent 框架后面都会补 tracing、logging、checkpoint 这些能力。一个更现实的做法如果你想把 Demo 往真实系统推进顺序最好是先把目标缩窄明确状态结构给工具调用加异常处理定义结束条件和预算上限增加日志、追踪和人工接管点而不是先换更强模型再堆更多 Prompt然后希望系统自己变稳定后者通常没有用。小结Demo 和真实系统的差别不在于“规模更大”而在于“约束更多”。一个 Agent 真正难的部分往往不是让它第一次成功而是让它在复杂输入、工具波动、预算限制和失败情况下仍然可控。这也是为什么学习 Agent 时不能只学“怎么搭出来”还要学“为什么它会坏”。Tool Calling入门往往Agent和普通聊天应用的差别就是从Tool Calling开始的因为一旦系统可以调用工具那么就不局限于基于预训练好的知识/基于参数的知识说话了而是具备外部行动能力为什么模型需要工具如果仅仅只有模型但是不能调用外部工具的话就不能实现获取实时数据查询私有数据库读写文件调用内部系统执行代码与外部API进行交互模型擅长的是理解、推理、生成工具解决的是访问外部世界和执行实际动作所以Tool Calling的真正目的是让系统能够有手有脚真正做出实际的动作一个简单的心智模型可以把工具调用理解成模型不应该只给出数据因为有可能这些数据模型都是假装查询出来的所以模型应该明确说明调用了什么工具为什么调用这个工具参数是什么执行结果是什么程序负责真正执行工具进行参数校验异常处理把结果返回给系统工具调用不等于随便开放能力很多新手在做Tool Calling的时候都喜欢把很多能力一次性暴露给模型搜索文件系统shell数据库浏览器写入接口在Demo阶段看着确实很cool但是真正落地到实际开发场景中就会导致模型选错工具工具重复调用调用次数失控参数乱填权限过大调试困难所以在设计工具系统的时候不是工具越多越好功能越多越好而是越清晰越好明确需要什么工具一个好的工具至少要满足职责清晰工具到底在做什么、边界必须明确输入清晰输入的参数结构要明确、稳定、可校验输出清晰返回值格式明确返回值尽量稳定方便模型和程序继续处理权限清晰模型权限不能过大能不能写、能不能删除、能不能执行命令都要有明确的边界错误可处理工具失败时要能区分能知道是哪个地方出错了参数错误权限错误网络错误数据为空否则就会导致系统一失败就不知道问题出在哪里Tool Calling最容易踩的坑模型假装调用过工具这是最常见的问题模型会编一个输出结果而不是老老实实去发起工具请求去调用工具所以系统需要显式分区模型输出普通文本模型输出工具调用示意图工具接口设计过于宽泛如果一个搜索工具同时支持十几种模式但是没有明确字段这会让模型很难稳定产生出正确的参数工具返回结果太脏如果工具返回的是超长原始文本、混乱JSON或不稳定的结构模型后续也会处理得很差没有调用预算一旦任务进入循环系统就会不断进行尝试再搜索一次再调用一次再换一个参数试一试如果没有足够的预算和结束条件就会一直尝试成本不可控工具设计的一个建议在一开始设计的时候不要想着设计一个多强大多万能的工具核心是可控稳定围绕具体的任务列出真正需要的能力每个能力做成边界清晰的小工具优化保证输入输出的稳定然后再逐步补全权限控制、异常处理和预算控制先可控再强大总结Tool Callling是Agent非常关键的一步因为他让模型从只会说话变为能够行动但是工具系统不是插件市场不是说接入的工具越多越好需要的是分工明确接口稳定权限明确错误可控Momery设计模式这个词在Agent中都要被神化了很多介绍都说Agent需要记忆、加个memory就更智能了但事实上不完全正确重要的是得拆解清楚不然很容易把几种不同的东西混在一起当前任务状态会话上下文长期偏好外部知识库他们都和memory有关但都不是处于同一个层面先分清楚三类东西State就是当前任务执行过程中的结构化状态例如当前任务分析到哪一步已经查询过哪些数据中间结果是什么是否满足结束条件这更像的是每一步的执行记录而不是记忆Short-term Memory当前会话保留下来的上下文例如前几轮对话的内容当前用户刚才补充的约束本轮任务中暂时需要保留的信息它主要服务于当前任务的连续性Long-term Memory跨会话的、跨任务仍然有价值的信息不局限于当前会话就是不局限于一个会话中例如用户偏好历史决策习惯某类任务的长期背景资料很多系统其实都不需要使用长期记忆因为很多Agent场景只需要当前任务状态当前会话上下文如果一上来就做长期记忆就会导致召回了不该召回的信息旧信息会污染当前任务记忆更像逻辑混乱很难知道该忘记什么所以不要因为Memory很神就直接上长期记忆要分析清楚目标分析清楚要实现的功能设计顺序通常是先设计好State再处理会话内上下文最后再考虑是否真的需要长期记忆所以很多Memory问题本质上是state没设计好导致的常见的Memory设计模式模式1.对话窗口保留最简单的就是保留最近的几轮对话内容/几轮消息优点简单上手快问题长任务容易撑爆上下文历史信息结构化程度低模型2.摘要式记忆把前面内容压缩成摘要只保留关键结论优点节省上下文使得上下文没有那么容易被撑爆适合长会话长任务问题摘要本身失真被压缩掉的内容可能在当前这一次对话中不重要但是可能在后面是重要的模式3.结构化存储把任务进度和中间结果保存在明确字段里优点可调试可恢复适合工作流和Agent系统问题设计成本高模式4.检索式长期记忆把长期信息存到数据库或向量库中需要时再召回优点不必一直把信息都塞入到上下文适合长期积累信息问题召回相关性很难永远稳定容易把知识库检索误当成记忆Memory和RAG不是一回事这是一个极大的误区RAG解决的是如何从外部知识中取到相关的内容Memory更关注的是系统应该记住哪些和当前主体任务相关的信息两者可以结合一起使用但他们是不一样的例如用户偏好更像长期记忆某篇市场研究报告更像外部知识那就可以MemoryRAG来实现设计Memory时最应该问的问题这条信息是当前任务状态还是长期信息它需要跨会话保留吗他如果过期了会不会误导系统他应该完整保留、摘要保留、还是只在需要时检索如果这些问题弄不清楚就会导致Memory设计不清楚系统混乱总结Memory就是一套信息保留策略在大多数Agent系统里更重要的是把State状态设计清楚比起直接做长期记忆更重要当我们真正去做Memory的时候也要区分当前状态会话连续性长期信息沉淀Planning/Reflection/RAG这是一个及其容易混淆的点很多教程会同时提到planningReflectionRAG然后把他们一起包装成高级Agent能力但是如果不进行拆解清楚的话就会出现该用检索的时候去做规划该做自检的时候去补知识库系统真正缺失的是信息结果你一直让模型多思考一下简单定义Planning解决下一步应该做什么Reflection解决刚才做了什么做得对不对RAG解决现在缺什么信息三者的职责完全不同Planning组织执行路径Planning关注的是任务推进方式就是该执行哪一个分支任务例如先查询价格还是先查询新闻哪些子任务要先执行如果当前信息不足时下一步该用哪个工具整个任务要分几步推进Planning的本质是将目标拆解成后续要执行的动作它关注的是执行的顺序而不是关注知识内容本身什么时候需要Planning当满足下列特征的时候Planning会很有用多步任务路径不固定工具很多中间结果会对下一步执行有影响如果任务短、工具少、路径固定的话就可能不需要显式PlanningReflection 检查结果是否靠谱Reflection就是反思更像是一种会看和自我检讨分析自己的执行结果是否合理靠谱例如当前结论是否有证据支持刚才的工具调用是否真正解决了问题是否是虚假的工具调用输出是否满足目标有没有逻辑跳步或遗漏Reflection的本质是不是无脑一直往下执行而是每一次执行得到结果后停下来分析一下刚才执行的过程是否正确是否有出错什么时候需要Reflection当任务结果质量很重要而且模型经常会过度自信逻辑跳步工具用得不充分输出形式对了但是内容不扎实这时Reflection就会很有价值但是Refletion会增加Token成本执行时间系统复杂度所以并不是每一次执行都要进行ReflectionRAG补充外部信息模型当前不知道或者上下文没有但是系统可以通过外部知识中获取例如公司内部文档历史研究报告产品说明外部知识库市场资料RAG的核心是获取更多相关的信息使得信息更完善什么时候需要RAG如果任务高度依赖外部知识而且这些知识不在模型训练数据里不足够新不足够准不适合全部塞进提示词那么RAG是很有必要的一个容易混淆的例子假设任务是分析某个A股今天的风险当系统遇到信息不足时可能有以下三种不同的处理方式Planning决定下一步去查什么信息先查价格再查成交量再查新闻Reflection检查当前结果/结论是否站得住证据是否充足只有价格波动就高风险吗证据够吗当前结论是否太片面RAG补回系统缺失的信息取回历史风控规则召回某类异常模式说明不要把缺信息误认为是要多进行思考如果模型当前缺的是外部知识你让他Planning是没用的如果系统当前缺的是结果校验你补 RAG 也没用。如果真正缺的是任务拆解你一直 Reflection 也没用。所以在设计系统时应该先判断当前缺的是哪一类能力缺路径组织缺结果校验缺外部信息对应地选择 Planning、Reflection 或 RAG。建议在开始开发的时候不要把三者都做全了更合适的顺序一般是先把任务主流程做通再看是否真的缺外部知识如果是就用RAG再看是否真的经常输出不稳定如果是就用Reflection任务复杂到一定程度就需要进行任务拆解就用Planning增强总结你可以再记一遍这三个关键词的职责Planning安排动作Reflection检查质量RAG补充信息这三个概念一旦分清后面看 Agent 框架和系统设计时就不会总觉得它们像一团黑话。单AgentVS 多Agent大多数实际项目的第一版基本都是从单Agent做起的因为成本低状态更集中调试更容易行为更容易解释多Agent真正有价值的前提是任务足够复杂任务真的存在明确的职责分离就比如在LLM没爆火前前后端的分离但是现在还需要吗单Agent什么时候更合适目标比较单一状态可以集中管理工具集不算特别复杂不需要多个独立视角长期博弈系统首先追求稳定而不是花哨、展示那么就用单Agent更合适例如风险初筛文档问答单任务研究分析工单分类和处理这类任务往往一个Agent加上合适的工具调用和状态管理就能做好多Agent真正有意义的场景职责分工明确例如一个角色收集信息、一个角色审核和裁决他们的输入和输出、关注点确实是不同的上下文压力大不同子任务需要不同的上下文如果硬塞到一个Agent就会导致上下文混乱又长又乱任务可并行例如多个独立方向可以同时搜集信息然后最终汇总到一个中心点需要明确对抗或复核机制例如一个Agent负责生成方案另外一个负责找漏洞第三个负责最终裁决这样的多Agent才是真正有价值的多Agent最容易被低估的成本因为多Agent必然会导致系统复杂度同步上升一旦进入多Agent马上就要处理Agent之间怎么进行通信谁维护全局状态谁拥有最终决策权冲突结论怎么解决多轮协作合适停止成本和延迟怎么控制多Agent不是把单Agent多复制几份者恶梦简单误区把prompt分角色就以为自己做了多Agent例如同一个模型同一个上下文同一个执行循环只是换了几个system prompt名字这更像是多角色提示词不一定真的构成了有意义的多Agent系统真正拆分成多Agent系统的通常会有更清晰的角色边界状态边界输入输出边界协作协议判断标准在决定是否上多 Agent 前先问自己这几个问题单 Agent 真的做不好还是我只是觉得多 Agent 更高级各角色之间是否有明确且稳定的职责边界把它们拆开后系统复杂度增加是否值得是否真的需要并行、复核或对抗式协作如果这些问题答不清楚就先别拆。演进路径比起一开始就上多 Agent更推荐这样做先做一个状态清晰的单 Agent找出真正的瓶颈只在必要处拆出子 Agent 或子模块让多 Agent 服务问题而不是服务演示效果这样做通常更稳也更容易长期维护。总结多Agent不是升级版皮肤也不是默认更先进。你可以先记住一句很实用的话如果单 Agent 还没做稳多 Agent 大概率只会把问题复制并放大。先把单 Agent 做扎实再决定哪些地方值得拆分通常是更成熟的工程路径。接下来你可以进入learn-langgraph因为当你真正开始关心状态、节点、分支和协作时才会需要更强的系统编排能力。
