★ FEATURED ARTICLE 最近几个月多Agent这个词在圈子里热度一直很高。很多人都在问单Agent还没玩明白搞一群Agent真的有用吗我的答案是真的有用但前提是你要把“怎么分工”和“怎么配合”想清楚。我自己从最早用单Agent跑一个完整流程到后来尝试用多个Agent模拟一个个人AI团队中间踩了不少坑也总结出了一套相对稳定的搭建方法。这篇文章我不讲那些飘在空中的概念而是把我实际搭建多Agent系统、调试协作流程、优化成本和质量的完整过程写出来目标是让一个有一定编程基础的人看完就能动手搭出自己的第一支“AI小团队”。这套方法适合谁适合折腾过单个Agent、但感觉它处理长链路任务时又乱又容易断的人也适合那些每天要处理大量信息整理、方案撰写、数据分析和代码编写任务的效率控以及想用开源或API方式组建自动化工作流的开发者。无论你是刚接触多Agent的小白还是已经在用的进阶玩家这篇文章里都有能直接“抄作业”的配置和技巧。最重要的是我会告诉你哪些坑是网上教程不会写的。1. 为什么需要多Agent从单体到团队的演进1.1 单体Agent的瓶颈我们先看一个很常见的场景。你想让一个Agent帮你完成“收集某个主题的行业资料、整理成结构化的调研报告、再生成一份适合汇报的PPT大纲”这样一个完整的任务链条。用单Agent做的时候你会发现几个很头疼的问题。第一是上下文窗口有限。大模型的上下文窗口再大也是有限的当Agent一边要记住原始需求、一边要装下几十篇资料的内容、还要承载不断生成的中间草稿时窗口很快就会逼近极限。一旦超限轻则早期信息被“遗忘”重则直接报错。第二是角色混乱。又是信息收集、又是分析洞察、又是内容创作这些任务所需的指令风格、输出格式和思维模式完全不同塞进同一个系统提示词里Agent很容易在切换时出现“精神分裂”表现为写分析时突然开始吟诗写摘要时又开始列一堆没用的数据。第三是故障定位困难。当最终结果不对时你根本不知道是收集阶段漏了资料还是分析阶段理解错了还是最后生成阶段格式乱了因为所有过程都混在一起没有中间产物可以检查。还有一个隐藏问题单Agent在长链路任务中一旦某个环节出现偏差后面所有步骤都会被带偏。这就像一个人既当厨师又当服务员又当收银员忙起来肯定会出错而且你很难发现是哪一步出了问题。1.2 多Agent协作的核心价值多Agent的思路很简单把一个大而全的Agent拆成多个小而专的Agent让它们像公司团队一样分工合作。一个负责收集资料一个负责分析整理一个负责写最终报告每个Agent只需要聚焦自己那一亩三分地。这样做的好处非常实际。第一角色提示词可以做得非常聚焦。比如分析Agent的提示词里不需要强调“注意收集资料时要用什么搜索策略”它只需要知道“你的任务是把给定资料转化为结构化洞察”。每个Agent的指令简单了模型的表现自然更稳定。第二中间产物是结构化的、可校验的。多Agent流程中Agent A的输出是Agent B的输入这个输入是存下来的文件或数据结构你随时可以停下来检查收集Agent抓回来的资料够不够、分析Agent的结论靠不靠谱。第三并行成为可能。某些不依赖前后的环节比如“收集行业趋势资料”和“收集竞品公开信息”这两个子任务可以完全并行执行耗时直接从两倍缩短到一倍。第四迭代成本低。当你发现最终报告质量不行时只需要调整报告撰写Agent的提示词而不需要动收集和分析流程调试速度快得多。我用一个生活化的类比单Agent像全栈程序员独自接项目从需求分析到部署上线全得自己来虽然也能做但项目一复杂就很容易翻车多Agent像组建了一个小型工作室有人负责产品、有人负责UI、有人负责后端专业的人做专业的事每个人只需要把手上的活干好最终由负责人统一汇总。你不需要每个成员都是全才只需要把协作流程设计好就能完成远超个人能力的任务。1.3 明确你的目标和场景不过多Agent不是银弹。我见过很多朋友听说多Agent好上来就搭了七八个Agent互相聊天结果一顿折腾下来任务没完成反而产生了大量无意义的中间对话和费用消耗。所以在动手之前一定要先判断你的任务适不适合多Agent。适合多Agent的任务通常有三个特征一是任务链条长包含明显不同的阶段比如“信息采集→分析→生成”二是需要多种专业能力比如既要写代码又要写说明文档三是需要中间校验或人工审批比如生成营销文案之前需要先由策略Agent确认方向对不对。反之如果只是一个简单的“把这段摘要翻译成英文”或“帮我把这段代码注释补全”那单Agent就绰绰有余强行上多Agent反而增加了系统的复杂度和延迟。我建议先按这个思路做一次“任务拆解预演”把你要做的事情写在纸上按阶段分成3到5个子任务明确每个子任务的输入是什么、输出是什么、谁负责。如果你能画出这样一张流程草图说明你的任务适合多Agent如果画不出来说明任务本身还不够清晰先回去把需求理清楚再谈搭建。2. 整体架构设计思路从需求到协同2.1 角色定义与任务分解多Agent系统里最核心的设计决策就是角色定义。一个Agent角色不是简单给它起个名字叫“分析师”就完事了它本质上是“角色提示词 可调用的工具 可供读取的记忆”三部分的组合。角色提示词是灵魂。一份好的角色提示词至少包含四块内容角色定位你是谁、职责边界你做什么、不做什么、工作流程拿到输入后先干什么再干什么、输出规范用什么样的格式返回结果。职责边界尤其重要否则两个Agent很容易抢活。比如你定义一个“信息收集Agent”只负责检索和整理原始资料那么哪怕它觉得某个资料里的观点很精辟也不应该直接写进分析结论里而应该把它原样放进“原始素材库”交给下游分析Agent去加工。任务分解则决定了每个Agent的粒度。我的经验是开始阶段宁可多拆几个Agent也不要让一个Agent同时兼顾两个不相关的事。比如“市场数据抓取”和“财报文本分析”就该是两个Agent而不是一个“市场分析Agent”全包。因为后者会给提示词带来压力而且以后你想单独更换某一环节的技术方案时会牵一发而动全身。下面是我常用的一个角色定义表你可以参考角色Agent职责范围输入输出资料收集Agent搜索、抓取、过滤原始资料主题关键词、搜索约束结构化的资料条目列表含来源、时间、摘要分析洞察Agent对资料进行归纳、对比、提炼资料条目列表核心发现、趋势判断、关键数据方案撰写Agent将洞察转化为完整文章或方案核心发现列表、目标读者结构化长文草稿质量校验Agent检查内容完整性与一致性长文草稿问题清单与修改建议注意这张表中的“输入”和“输出”都是明确的数据结构而不是模糊的“相关资料”。这非常重要因为Agent之间的协作是靠这些可解析的中间数据流通的如果你的输出格式是自由文本下游Agent解析起来就很容易出问题。2.2 通信与协作机制多Agent之间的协作机制我总结下来主要有三种模式顺序管道、星形编排、网状协商。顺序管道是最容易理解的方式Agent A处理完把结果交给Agent BAgent B再交给Agent C一条线走到底。这种方式适合流程固定、阶段清晰的任务比如“收集→分析→生成”。优点是实现简单、调试容易缺点是如果某个环节特别耗时整条链路都会卡在那里。星形编排是有一个“调度Agent”或“中央协调器”负责接收总任务、拆解后分发给多个专家Agent再回收结果进行汇总。这种方式适合子任务可以并行的场景比如同时让“技术调研Agent”和“市场调研Agent”分别干活最后由总编Agent汇总成报告。网状协商则是让所有Agent直接互相沟通大家通过消息机制自由协作适合复杂开放性问题但实现难度最高也最容易出现“跑题大聊天”的情况。我在实际项目里用得最多的是前两种的混合主流程用顺序管道主流程里的某些独立子环节用星形并行。新手我不建议一开始就碰网状协商因为你很难控制Agent之间的对话走向很容易出现两个Agent围绕一句话来回讨论十几轮成本飙高但结论毫无进展。2.3 共享记忆与状态管理一个经常被忽视的问题是Agent之间的数据传递不仅仅是“给一句话”那么简单还涉及记忆与状态的管理。如果你的系统只是跑一次性任务那还好但如果是做一个长期可复用的“个人AI团队”你就要考虑每个Agent是否需要记住历史交互以及整个系统的状态如何保存。长期记忆通常落在外部存储里比如向量数据库或普通的结构化文件。每个Agent在执行任务前可以先检索与自己职责相关的历史记录比如“这个用户上次提出的偏好是格式要简洁”“上次方案里已经被否掉了某个技术方向”帮助它做更贴合上下文的决策。短期记忆则是指当前任务上下文通常在Agent间的消息体中传递不必每个Agent都保存全量对话历史。状态管理要解决的核心问题是防丢失和防错乱。我出过一个很典型的bug两个Agent同时写同一个状态文件结果后写的覆盖了先写的导致整个流程数据对不上。后来我规定每个Agent拥有自己独立的“输出槽位”只允许它写入自己的目录由调度方来做最终合并才彻底解决了冲突。这个原则听起来简单但在设计初期特别容易被忽略。2.4 框架选型常用方案的取舍市面上的多Agent框架大概分三类。第一类是角色编排框架核心概念是让开发人员定义多个角色再声明角色之间的关系和流程框架负责底层调度。这类框架适合业务逻辑相对固定的团队组建场景上手快文档齐全。第二类是对话协同框架强调让多个Agent通过自然语言对话来完成任务适用开放性问题但可控性弱一些需要设置好对话轮数上限。第三类是图流程式框架把Agent当作图中的一个节点节点之间的流转由边来定义逻辑最清晰但实现起来需要更多工程基础。我自己在选型时有一条原则不要被框架绑架。框架没有最好只有最适合。你的核心流程是稳定的顺序链路就用轻一点的角色编排框架如果你的需求是每个任务都可能走完全不同的流程那图流程式框架才更像你需要的。新手我的建议是从简单方案入手先用代码硬编码把一套流程跑通感受一下Agent之间协作的痛点和乐趣再决定要不要引入框架。硬编码的好处是每个环节都在你的掌控之内出问题了你一眼就能定位框架当然省事但出了问题你还要先查框架的调度日志多了一层排查成本。3. 核心实操搭建最小可运行的多Agent系统3.1 环境配置与基础依赖纸上谈兵完了我们直接开始动手。这里我以最常见的Python环境为例目标是搭一个最小系统三个Agent分别负责收集资料、提炼洞察、撰写报告按顺序协作完成一次“主题调研”任务。先准备环境。我用的Python版本是3.10以上安装好大模型API的调用库和基础工具库即可。这些库不是某个特定平台的专属而是通用的HTTP请求和数据处理工具。基础代码如下# 只需要标准的HTTP请求库和文本处理库 import os import json import requests from typing import List, Dict from dataclasses import dataclass, asdict这里我建议把大模型的API地址和密钥存放在环境变量里而不是直接写死在源码中export LLM_API_BASEhttps://your-api-endpoint export LLM_API_KEYyour-secret-key一切准备就绪后我们来封装一个统一的“调用一次大模型”的函数。这个函数是整个多Agent系统的最小单元所有Agent最终都是反复调用这个函数来完成自己的职责。def call_llm(system_prompt: str, user_prompt: str, temperature: float 0.3) - str: headers { Authorization: fBearer {os.environ[LLM_API_KEY]}, Content-Type: application/json } payload { model: your-model-name, messages: [ {role: system, content: system_prompt}, {role: user, content: user_prompt} ], temperature: temperature, } resp requests.post(f{os.environ[LLM_API_BASE]}/chat/completions, headersheaders, jsonpayload) resp.raise_for_status() return resp.json()[choices][0][message][content]温度参数在Agent协作里很有讲究。信息收集和数据提炼类的Agent我建议用0.2到0.3让输出更稳定方案撰写和创意类的Agent可以用0.7到0.8给模型留一点发挥空间。3.2 定义角色写一个能干活的分析师Agent接下来是定义角色。为了让Agent的输出能被下游稳定解析也为了让整个系统的中间产物可以检查我给每个Agent都设计了结构化的输出格式。不要只依赖自然语言约定而是要在提示词里给出明确模板并要求Agent只返回合法的JSON或Markdown结构。以分析洞察Agent为例。它的职责是接收一批资料条目输出结构化的核心洞察。我的角色提示词长这样ANALYST_SYSTEM_PROMPT 你是一个资深行业分析专家擅长从大量原始资料中提炼关键脉络。 你的任务包括 1. 对输入的资料进行归纳识别共性与矛盾点 2. 提炼出最多5条核心洞察每条洞察需包含事实依据 3. 标注每条洞察的可信度高/中/低并简要说明理由。 输出必须严格遵循以下JSON结构 { insights: [ { title: 洞察标题, summary: 简短解释, evidence: [支持该洞察的资料原文摘录或来源编号], confidence: 高/中/低 } ], summary: 整体研判结论不超过200字 } 不要输出任何与JSON格式无关的说明文字。 用户消息部分就是把上游收集Agent的输出以结构化形式喂进来比如“以下是从资料收集中获得的条目列表”后面跟着JSON数组。注意这里我已经把上游输出的JSON直接传给分析Agent而不是粘贴一大段杂乱无章的网络抓取内容。这个设计决定了你的Agent能不能稳定工作因为模型对结构化输入的解析能力远高于对乱糟糟自由文本的解析能力。3.3 定义协作流程让Agent真正“配合”角色定义好之后我们写协作流程。最简单的顺序管道用代码表示就是def run_pipeline(topic: str): # 步骤1收集资料 collect_result collect_agent.run(topictopic) # 步骤2分析资料 analysis_result analyst_agent.run(materialscollect_result) # 步骤3撰写报告 report writer_agent.run(insightsanalysis_result) return report每个Agent的run方法内部本质上就是调用之前实现的call_llm函数。这里我不建议直接把“收集的结果字符串”传给分析Agent而是建议先让收集Agent返回一个JSON列表再传给下一个Agent。用一个稍微完整一点的例子展示# 收集Agent返回的示例结果 collect_output [ {source_id: 001, title: 某行业报告摘要, content: ..., url: ..., date: 2025-01-10}, {source_id: 002, title: 某专家访谈要点, content: ..., url: ..., date: 2025-01-15} ] # 将结构化数据序列化后传给分析Agent materials_json json.dumps(collect_output, ensure_asciiFalse) analysis_text call_llm( system_promptANALYST_SYSTEM_PROMPT, user_promptf请分析以下资料\n{materials_json}, temperature0.2 ) # 解析分析结果 try: analysis_data json.loads(analysis_text) except json.JSONDecodeError: # 容错如果模型返回了多余说明文字尝试提取首个 { 到最后一个 } 之间的内容 start analysis_text.find({) end analysis_text.rfind(}) 1 analysis_data json.loads(analysis_text[start:end])这里有一段处理JSON解析失败的容错逻辑是我在实际调试中踩过很多次坑后总结出来的。大模型有时候不听话会输出“以下是结果{...}”之类的内容直接json.loads就会失败。提取首个“{”到末尾“}”之间的内容能救回绝大多数情况。3.4 从简单到复杂引入工具与中间环节当你把最小流程跑通之后就可以开始考虑引入工具和中间环节了。工具的引入方式很简单给Agent的提示词里声明它可以调用哪些工具然后在Agent的输出中预留一个字段由外部执行器来实际调用工具。比如给信息收集Agent加一个“搜索工具”SEARCH_TOOL_SCHEMA { type: function, function: { name: web_search, description: 搜索公开网络信息, parameters: { type: object, properties: { query: {type: string}, num_results: {type: integer} } } } }Agent的输出会变成“我想搜索‘某关键词’请执行web_search”然后由你的代码把真实搜索结果注入回对话再让Agent基于结果继续分析。这就是经典的ReAct循环结构它让Agent有了行动能力而不仅仅是坐在那里空想。中间环节还包括人工审批节点。我习惯在质量校验Agent之后加一个“确认”环节用简单的小提示让用户确认内容质量是否过关如果不过关是让校验Agent继续修改还是直接终止流程。这个环节在自动化系统里看起来像是多余的但在真实的多Agent项目里非常有用因为AI生成的内容偶尔会有“一本正经胡说八道”的情况人工把一道关能避免下面几个环节白白消耗算力。4. 深入优化从能跑到跑得好4.1 上下文窗口与记忆管理最小系统跑通后你会遇到第一个实战冲击上下文窗口不够用。尤其是当信息收集Agent抓了十几篇资料每篇内容又很长的时候分析Agent的输入窗口很快就爆了。我常用的方案是“分块摘要再汇总”。先让信息收集Agent对每篇长文档分别生成摘要再把摘要列表中传给分析Agent如果摘要列表还是太长就先分组让分析Agent先对每组做一个子分析最后再汇总成全局洞察。这个过程很像人类处理大量资料的方式先快速泛读每篇摘要再重点深入研究几个方向而不是一上来就把所有原文塞进脑子里。另外考虑到成本与响应速度不需要每个Agent都拥有全量历史记忆。我通常只为“调度层面的管理Agent”保留跨轮次的长记忆而业务Agent只保存当前任务上下文。也就是说每次任务执行完成后业务Agent的短期记忆就被清空只有关键结论写入外部存储。4.2 任务分配的自动化与动态调整当你有了4到5个固定Agent之后“下一步该调用哪个Agent”就不能再硬编码写死了。比如同样一个任务有时候分析Agent可以一步到位但有时候需要“技术拆解Agent”先介入再交给分析Agent。这时候可以考虑引入一个“路由层”。路由层有两种做法。第一种是基于规则的路由比如根据用户任务文本里的关键词、任务长度、任务类型来判断走哪条Agent链路。第二种是基于调度的Agent它本身也是一个Agent专职负责“阅读当前任务和可用Agent列表决定调用顺序”。我用第二种的体验是它确实能处理更复杂的分配问题尤其适合任务意图非常好辨认但链路结构不固定的场景。不过要提醒一句调度Agent本身也是一层调用多一层调用就多一层成本和延迟。如果你的流程是高度固定的硬编码顺序管道反而更稳。4.3 可观测性日志与追踪多Agent系统最大的噩梦就是“不知道哪一步错了”。为此我强烈建议你在写第一个版本时就加入结构化日志。我在每两个Agent之间传递数据时都会记录一步日志输出结构化JSON{ step: collect_agent, run_id: run_001, input_topic: 多Agent实践, output_item_count: 12, token_cost: 5821, latency_ms: 3200 }当整个流程跑完后把所有日志汇总起来你就能看到每一步的耗时、Token消耗和输出数量。如果某次任务报告质量突然下降先看日志里哪一步的输出异常再单独把那个Agent拎出来测试。不要等到报告出来发现不对才一脸懵地去翻所有代码。4.4 性能、成本与质量平衡多Agent最大的隐性成本是Token消耗。每个Agent之间传数据都是Token每个Agent自己内部的多轮对话也是Token。如果放任不管跑一次完整流程的账单会非常“感人”。我的优化思路有三个。第一个是让轻量级的小模型承担非核心环节。比如信息收集阶段的摘要工作对模型推理能力要求不高用小模型降低成本只有最终方案撰写、复杂分析这类任务才动用能力更强的大模型。第二个是缓存复用。如果同一个话题当天跑了很多次资料收集结果可以直接读缓存不需要每次都重新搜。第三个是精简单步输入。给Agent只传递它真正需要的字段而不是把上游输出整个JSON完整丢过去因为很多元信息下游根本用不到。这三个优化做下来我实测单次流程成本可以下降40%到60%而且报告质量几乎没有变化。5. 常见问题与排查技巧实录5.1 Agent互相“踢皮球”怎么办最常见的问题就是两个Agent互相把任务推给对方谁也不产出最终结论。比如分析Agent说“详细方案请由方案Agent输出”方案Agent又说“我的分析依据不足请分析Agent补充”。最深层的原因通常是没有一个Agent被明确指定为“最终负责人”。解决方法是彻底说清楚“最终责任在谁”并且给准时打住的条件。比如明确指出“方案Agent是最终产出责任人即使输入信息不足以做完美决策也必须基于现有信息输出一个可用的草稿并在文末标注风险项”。另一个办法是设置最大协作轮数比如在同一轮协作流程中最多只允许两轮互相反馈超过两轮后直接由预设的兜底Agent接管。兜底Agent的设计很重要它需要在信息不完整的情况下也能产出一个“够用”的结果而不是追求完美。5.2 上下文被撑爆有段时间我的资料收集Agent抓回的原始内容越来越多分析Agent的输入窗口一直在爆炸边缘试探。我用过的有效手段按优先级排列先做显著压缩每篇原文在收集阶段就生成300字以内的摘要再做字段裁剪分析Agent根本不需要原文URL和日期时就不要把这两列传给它最后做分批处理如果单批还是超出窗口就让分析Agent先分批产出阶段结论最后再做一次汇总。记住一个原则不是所有信息都值得进Agent上下文窗口。窗口就是你的“内存”有限资源应该留给高价值内容。5.3 角色边界模糊、输出互相覆盖这是新手最容易忽略的多个Agent的输出格式没做隔离导致下游Agent根本分不清某段内容是哪个角色写的。解决思路是给每个Agent的输出定义严格的Schema甚至用不同文件或不同字段名做隔离。比如收集Agent的输出统一以“source_item”为根字段分析Agent的输出统一以“analysis_result”为根字段这样下游Agent解析时只需抓取对应根字段即可不会抓错。你在做调试时也更容易定位输出异常来自哪一个环节。5.4 工具调用失败与异常处理工具调用在Agent协作中非常常见但也最容易脆断。比如搜索接口返回超时网络抓取模块遇到反爬代码执行Agent遇到编译错误。如果不做异常处理整个流程会卡在等待中。我给所有工具调用统一增加了三层保护第一层是重试一般来说重试3次、每次间隔递增能解决绝大多数临时性故障第二层是降级如果搜索工具挂了就退回到基于已有缓存数据或提前准备的静态资料库继续后面的环节第三层是熔断连续失败超过5次就直接终止当前分支并返回一条明确的错误信息给上游让调度层决定是换个Agent还是让用户介入。不要以为“Agent会自己发现工具调不通”实际上模型经常无法准确感知外部工具的真实状态。5.5 调试与测试的实用技巧多Agent系统的调试方法和传统软件开发有很大区别。传统代码是确定性执行的多Agent系统则充满了随机性同样的输入下一次跑可能就结果不同。我干活时的落地方案是第一把中间产物全部落盘每个Agent的输入输出都以文件形式保存第二固定随机性在测试时把模型温度设为0并把需要对比的不同版本写在不同日志目录里第三构造“迷你沙盘”不跑全流程只把出问题的那个Agent单独拎出来用之前记录的真实输入喂给它反复调整提示词直到输出稳定。这套调试三角法我用了很多项目效率非常高。另外我总会在正式运行之前先准备三到五个不同类型的“测试任务”每次改动系统后都跑一遍确认没有引入回归问题。没有测试集的多Agent项目迟早会翻车。6. 个人经验总结与后续扩展方向6.1 我踩过的坑第一个坑是过度并行。最开始我试图把所有子任务都并行跑结果多个Agent同时调用资源不仅响应变慢而且最终合并时数据逻辑经常冲突。后来我规定只有真正互不依赖的子任务才允许并行其他保持一致有序执行。第二个坑是角色提示词里塞了太多约束。我为了让Agent“表现更好”在一份提示词里写了近千字的规则和限制结果Agent反而变得畏首畏尾经常输出“抱歉根据你的要求我无法完成”。后来我学会做减法只保留最关键的角色定义、核心流程和输出格式要求其他细节留给模型自己发挥。越是紧密的约束越容易锁死模型的主动性和灵活度。第三个坑是直接从正式环境开始迭代。我早期很着急直接拿真实任务反复试错每次都消耗不少Token而且问题五花八门很难判断是系统bug还是提示词问题。后来我改成先用模拟数据把整个流程跑通再切换到真实任务迭代速度反而快了很多。6.2 后续可以做的扩展一个可以明显的扩展方向是给AI团队加上“长期成长能力”。比如可以设计一个“复盘Agent”在每次任务结束后阅读全流程日志和高层结果把得到的经验写回记忆库。下次遇到同类任务时其他Agent就能检索到“上次这种任务在方案撰写阶段踩过坑需要在最终稿中避免某个写法”。这等于让AI团队在一次次实践中积累经验。另一个方向是引入多人协作版。目前的Agent都挂在一个人下面未来可以设计成几个用户共享同一个多Agent平台每个用户有自己的专属Agent但底层共享资料库和知识库。这已经超出了个人AI工作流的范畴更像一个组织级的知识协作系统了。最后我真诚建议所有刚接触多Agent的朋友先不要想着一次搭一个完美的系统哪怕是三四个Agent组成的玩具级流程只要能稳定跑通一次完整任务就已经赢了80%。先把流程跑通再逐步加角色、加工具、加记忆你会发现多Agent真正厉害的地方不在于单个模型的能力有多强而在于你把复杂任务拆得足够好、协作机制设计得足够顺一批能力平庸的Agent也能干出令人惊讶的活。我自己做完第一版看到三个Agent分别处理不同模块、最后拼装出完整报告并且能互相校验时那种感觉就像真的“带了一个AI团队”它会持续学习也会持续变化而你是那个控制局面的负责人。
阅读完成 · 觉得有帮助？
