经常有人拿这个问题来问我想做多智能体推荐几个好用的AI工具。说实话每次听到这个问法我都觉得方向偏了。多智能体协作场景下的工具选型和普通“选个AI工具”完全是两码事甚至可以说你先把“哪个模型最强”这个问题放一放才能真正把多智能体系统跑起来。过去大半年我自己从单Agent应用一步步迁移到多智能体架构中间换过三轮工具链踩过不少坑也把市面主流的几类方案都试了一圈。这篇内容不打算给你一份“十大AI工具排行榜”而是想聊清楚一个更本质的问题多智能体协作到底需要工具链具备哪些能力以及你该怎么按自己的场景去匹配。适合正在做AI应用开发的工程师、准备引入多智能体的技术负责人还有那些被“多智能体”概念吸引但还没理清头绪的个人开发者。1. 多智能体场景对工具的真实需求别拿单智能体思维来套先把最核心的观念掰扯清楚。很多人在选工具时脑子里想的是“哪个AI能力更强”这其实是单智能体时代的思维惯性。多智能体的难点从来不是“单个智能体聪不聪明”而是“一群智能体能不能有条理地协作”。1.1 多智能体不是“多个AI排队回答问题”而是组织行为打个比方。单Agent应用就像一个全能实习生你给它一个任务它从头干到尾能力强弱直接决定结果好坏。但多智能体系统是一个项目组——里面有做需求的、写代码的、搞测试的、盯运维的你需要管理的不是一个实习生的个人能力而是这组人之间的分工、沟通、同步和冲突仲裁。我见过不少人搭建多智能体其实就是写个循环让几个Agent轮流调用同一个模型接口把上一个Agent的输出拼到下一个Agent的提示词里。这种实现方式也能跑但本质上只是“多个AI排队”并没有真正的协作结构。一旦任务复杂起来你很快会发现信息传递靠拼字符串上下文越滚越长Agent之间相互甩锅出问题根本不知道是谁的责任。真正的多智能体协作对工具链提出了三个单Agent时代根本不会遇到的要求编排能力谁来决定下一步任务分给哪个Agent任务之间的依赖关系怎么表达分支、并行、重试、终止条件谁来控制通信机制Agent之间怎么交换信息是直接传消息还是通过共享空间读写消息是同步阻塞还是异步解耦状态一致性多个Agent并行操作时全局状态怎么保持一致两个Agent同时修改同一份数据怎么办系统崩溃后怎么恢复这三个问题才是选型的真正出发点。你去看一个工具适不适合做多智能体不要先看它的模型列表有多长而是要看它对这三件事的支持到了什么程度。1.2 工具链的核心矛盾编排、通信、状态一致性我把选型时最该关注的三个技术点展开一下因为后面聊具体工具时都会落到这上面。先说编排。多智能体的任务流不是线性的它更像一张图有分支、有合并、有循环。比如一个内容生产系统可能需要策划Agent先产出大纲然后写作Agent和配图Agent并行工作最后再由审核Agent统一把关。这种拓扑结构如果工具只支持“顺序调用”或者“简单的链式调用”你很快就得用一堆if-else去补逻辑代码会变得极其难维护。所以框架层面对有向图DAG甚至更复杂拓扑的支持是第一道分水岭。再说通信。Agent之间怎么传递信息直接影响系统的灵活度和性能。目前主流有三种模式第一种是直接消息传递比如Agent A调用Agent B把结果当作参数传过去简单直观但耦合度高第二种是共享黑板模式所有Agent往一个公共空间里写信息、读信息彼此不直接依赖适合并行度高的大规模系统第三种是事件总线模式Agent通过发布和订阅事件来驱动协作解耦最彻底但调试难度也最大。不同工具对这三种模式的支持力度完全不一样后面我会展开说。最后是状态一致性。多智能体系统本质上是分布式系统分布式系统里最难的就是状态管理。两个Agent同时拿到的上下文不一致、某个Agent的中间结果没落盘导致崩溃后无法恢复、并行任务写同一个存储导致数据覆盖……这些问题在Agent数量少的时候不明显一旦上到五个以上就会成为日常。所以工具是否支持持久化、检查点、共享状态的可控读写是选型时最容易忽略却最致命的指标。1.3 为什么“最强的那个模型”往往不是首选再聊一个反直觉的点。很多人选工具时眼睛只盯着“能不能接GPT-5、Claude最新版”好像模型越强系统就越强。我的实测经验恰恰相反在多智能体场景里模型本身的能力远没有工具链的组织能力重要。原因很简单。单Agent拼的是“上限”模型越强单次输出的天花板越高。但多智能体拼的是“下限的稳定性”——整个系统的可靠性取决于最脆弱的那个环节。一个中等能力的模型如果被妥善地编排进合适的角色、拿到清晰的任务边界和上下文产出的稳定性可能远超一个全能大模型在混乱协作中的表现。反过来哪怕每个Agent都用了最强模型一旦编排混乱、信息传递丢失、状态不同步整体效果也是灾难。我自己做过一个对照实验同一个任务方案A用三个不同模型跑在一个开源框架上方案B用最强模型跑在单Agent链路上。结果是方案B在简单任务上赢方案A在复杂任务上赢而且方案A的token成本低了将近一半。这背后的原因就是任务被解耦后每个Agent的提示词更聚焦上下文更短模型反而不容易被无关信息干扰。所以我的建议是先确定你的任务需不需要多智能体需要的话把选型重心放在编排、通信、状态管理这些“组织能力”上模型能力只要达到基准线即可。2. 市面工具的派系地图框架、平台、周边谁在做什么市面上的工具看着眼花缭乱但如果你把视角拉高一点会发现其实就三大派系底层开发框架、可视化编排平台、周边支撑生态。三者解决的问题完全不同也对应着不同的人群。2.1 底层开发框架给写代码的人用的“半成品车间”底层框架是“代码优先”的方案适合想自己掌控一切细节的开发者。目前用得最广的几个我逐个说下我的实际体验。LangGraph是我个人用得最顺手的。它对标的场景就是复杂状态流核心抽象是“图”节点Node表示Agent或工具调用边Edge表示流转关系状态State在整张图里显式传递。这个设计天然契合多智能体需求——每个Agent是一个节点Agent之间通过共享状态通信条件分支用边的路由逻辑控制。它的学习曲线比较陡因为你得先理解“图计算”的思维模式但一旦掌握复杂拓扑的控制力是其他方式给不了的。它还内置了检查点机制支持中断和恢复这对长任务系统非常重要。CrewAI的定位更加“角色化”。它的核心抽象是Crew团队、Agent角色和Task任务让每个Agent扮演一个角色比如“市场分析师”“内容写手”然后定义角色之间的协作方式。相比LangGraphCrewAI的抽象层次更高上手更快特别适合快速搭建“角色分工型”协作。但代价是灵活性受限——你对底层流程的控制力不如LangGraph一旦遇到非标准的协作模式反而要费劲去绕。AutoGen是另一个有代表性的方案它主打“对话驱动”和“自动组队”。在AutoGen的世界里Agent之间通过对话来解决问题可以由一个Agent自动决定要不要拉另一个Agent进来。这种模式很智能但也意味着行为有不确定性生产环境里不太好控制。它在学术研究和快速原型验证里用得很多真要上生产就得自己在外面包一层监控和约束。还有一个值得留意的趋势是dsh多智能体这类新兴方案——它们把环境抽象做得更彻底Agent不只通过消息协作还能共享一套执行环境里的资源和状态。这类方案还在快速演进中不建议作为首选但值得保持关注特别是当你的系统需要Agent与环境有大量交互时。2.2 可视化编排平台低代码时代的快速验证选择如果你不想写太多代码或者业务人员也要参与配置可视化编排平台是更现实的选择。这一派的代表是Dify、Coze这类带有工作流画布的平台。我最早做多智能体原型时用的是这类工具。它们的核心优势是“所见即所得”——你可以拖拽节点把Agent之间的关系画出来每一步的输入输出都能直接看到调试效率很高。对需要快速验证想法、或者让非技术同事参与协作配置的团队来说这是个巨大的优势。但它们的短板也很明显。第一平台对复杂拓扑的支持有限节点多了之后画布会变得很难维护第二在自定义逻辑方面可视化节点再灵活也比不上代码遇到特殊需求时你会发现“没法表达”第三也是最关键的——平台绑定意味着迁移成本高如果项目做大了需要迁到代码框架上几乎等于重写。我的建议是如果你做的是内部工具、原型验证或者业务逻辑相对标准可视化平台完全够用如果你的目标是做一个长期演进、需要深度定制的产品那么可视化平台顶多用来做前期验证最终还是要落到代码框架上。2.3 周边支撑生态MCP协议、可观测性、记忆层怎么融入选型这一派最容易被忽视但恰恰是多智能体工程化的胜负手。周边生态主要解决三件事连接、观测、记忆。连接层最大变量是MCPModel Context Protocol模型上下文协议。它的思路相当于给AI工具生态定了一个“USB-C接口标准”——Agent通过MCP统一接入外部工具和数据源不需要为每个工具写一套专属适配。在我现在搭的系统里所有的工具接入都是MCP方式换工具、加工具都变得很轻。它对多智能体的价值尤其大多个Agent可以共享一套工具服务器工具能力可以复用权限管控也更集中。早期对MCP的诟病主要是生态不成熟但最近这半年工具数量涨得很快基本主流的服务都有第三方或官方MCP实现。现在选型时“是否支持MCP”已经是我的一票否决项。可观测性这一层LangSmith、Langfuse这类工具的价值怎么说都不为过。多智能体系统是一个典型的分布式系统没有全链路的trace、token统计、输入输出日志出了问题你连“哪个Agent干了什么”都说不清。我把可观测性当成刚需而不是锦上添花的选项。选型时一定要问这个框架/平台能不能方便地接上trace系统每一步的输入输出能不能留痕记忆层则是多智能体能不能“越用越聪明”的关键。短期的对话上下文、长期的用户偏好、全局共享的业务状态这三类信息需要不同的存储方案。向量数据库比如Chroma、Milvus、Redis加向量插件承担了一部分长期记忆的职责而全局工作状态的管理通常要依赖框架层的状态持久化能力。选型时重点看框架对记忆与状态管理的原生支持度这比你自己在外部拼一套要靠谱得多。派系代表工具核心优势典型短板适合人群底层框架LangGraph、CrewAI、AutoGen灵活可控、适合复杂拓扑学习成本高、需要写代码有开发能力的团队可视化平台Dify、Coze等上手快、调试直观复杂逻辑受限、绑定平台业务人员、原型验证周边生态MCP工具、LangSmith、向量库解决连接/观测/记忆刚需本身不解决编排问题所有生产级系统3. 按你的身份与场景对号入座选型不是选工具是选组合把工具基本面讲完之后很多人还是会纠结那到底选哪个这个问题的答案不取决于工具,取决于你的团队规模、技术栈和业务场景。我把它拆成两类人群和四类典型场景来聊。3.1 独立开发者和小团队用开源框架起手控制Agent数量独立开发者和三五人小团队核心约束是预算有限、人手少、试错成本高。所以选型原则是能用开源解决的绝不用商业闭源能用一个工具的别拆成三个。我的推荐组合是LangGraph或CrewAI做主体架构模型API用Kimi、DeepSeek这类性价比较高的国产接口来压成本可观测性先接Langfuse社区版或直接打日志撑住MCP接入作为工具层统一入口。这套组合里框架是开源的模型按量付费可以控制预算周边工具都有免费层初期基本零固定成本。小团队最要克制的是Agent数量。我的实际体会是三个Agent以内的系统复杂度还在人的掌控范围内一旦超过五个通信编排和排障成本会指数级上升这时候没有专职人力和配套工具项目很容易烂尾。建议新手起步时控制在三到五个Agent把角色边界划清楚跑通了再逐步增加。另外小团队选型时别把“别人用什么”当决策依据。看到社区里有人用某个框架做了很酷的Demo不意味着它也适合你的场景。先把你自己的任务流程画出来再去看工具能不能覆盖这个顺序不能反。3.2 中大型团队和企业把权限、审计、治理放在第一位中大型团队选型要复杂得多因为多智能体系统一旦接入生产就不只是技术问题了还涉及权限、审计、成本治理、多项目隔离——这些往往比模型效果更让人头疼。这个体量下我见到的成功案例大多是“可视化平台底层框架混搭”的混合架构。比如用Dify这类平台承接业务人员的自助流程编排同时允许技术团队用代码框架开发需要深度定制的核心链路两类系统通过统一的网关和MCP工具层打通。这样兼顾了业务侧的灵活和技术侧的深度。企业级选型有几个必须重点确认的能力第一有没有细粒度的权限控制能不能做到不同团队、不同项目之间的Agent和数据严格隔离第二有没有完整的操作审计日志所有Agent的工具调用和执行记录要能回溯第三成本治理能力多智能体系统的token消耗是单Agent的好几倍平台能不能按项目、按Agent维度统计成本直接决定了月底要不要“吃土”第四私有化部署能力很多企业对数据出境和数据主权有硬性要求纯云端方案直接出局。如果你所在的企业在云厂商的生态里已经投入很深那么优先考虑平台自带的多智能体编排能力会比重新引入一套新框架更容易过合规和运维的评审。这不算最灵活的方案但往往是最容易落地的方案。3.3 从场景反推工具四个典型场景的选型思考路径比“选工具”更重要的是“从场景推理工具”。我拿四个最常见的场景具体说说思考路径你可以照着这个思路套自己的需求。代码协作场景。多智能体在代码领域的核心价值是需求拆解Agent负责把产品需求拆成开发任务编码Agent负责实现审查Agent负责找问题测试Agent负责跑验证。这类场景对工具链的要求很特殊每个Agent需要能真正读写代码仓库、运行测试命令、拿到执行结果甚至操作CI/CD流水线。所以选型的重点不是Agent框架本身而是代码沙箱环境和CI/CD集成能力。如果一个工具只能让Agent“写代码片段”但无法在隔离环境里运行和验证那它对代码场景的价值就要大打折扣。内容生产流水线。策划Agent出选题和提纲写作Agent起草校对Agent查事实和语病发布Agent排版分发。这类场景的特点是对执行环境要求低但非常依赖稳定的模板和上下文传递。我的经验是这种结构化程度高的流水线用可视化平台完全够用不需要上重量级框架。把每个角色的输出模板定义清楚比任何花哨的运行时能力都管用。客服售后场景。意图识别Agent先分流FAQ检索Agent负责知识库问答工单Agent处理需要转人工的复杂问题最后还有一个人机切换机制保底。这个场景最要命的是延迟和可靠性用户等不起。所以在工具选型上除了看编排能力还必须考虑模型服务的响应速度和工具调用的稳定性同时知识库的检索质量往往直接决定客服系统的体验上限。调研报告场景。多智能体可以用来做信息收集、交叉验证、归纳分析。搜索引擎Agent负责检索材料阅读Agent负责提取关键信息分析Agent负责交叉验证不同来源的结论写作Agent负责组织成文。这个场景的关键约束在于搜索与阅读工具的质量——检索覆盖面和内容解析精度直接决定了最终报告的质量。工具链要能把每个Agent检索到的信息来源可靠地保留下来方便后续追溯校验避免AI生成幻觉内容。4. 决定成败的硬指标通信协议、工具调用与记忆共享就算上面说的派系和场景你都看明白了到了真刀真枪选型的时候还是会发现很多工具的宣传语长得差不多宣传页面都写着“支持多智能体”。这时候你需要一套硬指标去分辨谁在裸泳。下面这三个维度是我踩过坑之后沉淀出来的核心评判标准。4.1 通信机制直接传消息、共享黑板还是事件总线我在前面提过通信模式有三种。选型时你先要搞清楚手里的工具原生支持哪种这决定了你之后能搭建多复杂的协作关系。直接消息传递是最容易理解的模式Agent A调用Agent B传递参数等待结果。LangGraph早期的节点间通过共享状态传递数据本质上接近这个模式的“改良版”——不是点对点传消息而是大家都往状态里写基于路由来决定下一跳。这种模式的优点是调试简单、因果链清晰缺点是高耦合Agent之间的关系一变代码就要跟着改。共享黑板模式更适合大数量Agent的并行协作。所有Agent读写同一个工作空间彼此看不见对方只跟黑板打交道。缺点是需要设计好读写权限和命名空间否则很容易出现数据冲突。某些框架的“共享状态”就带有这个味道但没有完全做到黑板模式那样彻底的解耦。事件总线模式是最工程化、也是扩展性最强的方式。Agent通过发布事件和订阅事件来协作发布者不知道谁会消费自己的消息订阅者也不知道消息是谁发的。这种模式天然适合事件驱动架构Agent可以随时加入或退出而不影响系统其他部分。代价是调试复杂度极高一条请求的完整链路需要跨多个事件追踪。在实际项目中我看到很多生产级方案最终都会走到事件总线这条路上来所以选型时不妨提前考察工具对事件机制的支持度。4.2 工具调用能力不是“能调”就行关键看治理能力多智能体系统里工具调用是一项核心能力——Agent需要靠工具去查数据库、调API、操作外部系统。但工具调用的深度比很多人想象得复杂。第一层是“能不能调”。最基本的工具定义和参数解析能力现在主流框架都支持只是调用的规范程度有所差异。第二层是“怎么发现”。在多智能体场景里可能有几十个工具Agent怎么知道该用哪个工具的定义、描述、参数schema写得清不清楚直接决定Agent的选择准确率。第三层是“允不允许调”。工具级权限控制是企业落地的硬要求不同Agent对同一工具的访问权限可能完全不同。第四层是“调了之后怎么办”失败重试、超时处理、幂等设计——这些工程细节决定了一次工具调用失败后系统能不能优雅降级而不是直接崩掉。MCP在这个背景下的价值就体现出来了。你不需要给每个Agent单独接入工具而是在一个地方配置好工具服务器所有Agent通过统一的协议去调用。权限管控从“散落在各部门”变成“集中管理”记账和审计也顺理成章。所以我的选型清单里有一条框架对MCP的支持是要原生支持还是需要自己写适配层原生支持的会省掉很多事。4.3 记忆与状态管理上下文飞轮是整个系统最大的成本黑洞我在项目里见过最惨烈的教训是系统上线三周后token费用失控。原因说起来特别简单每个Agent在处理新任务时都把整个对话历史塞进了模型上下文。随着Agent之间的信息持续传递上下文像滚雪球一样越来越大每个Agent都在重复读取大量冗余信息成本以指数级增长。这个问题在工具层面其实有解但前提是你选型时关注了记忆和状态管理能力。我把信息分成三类来处理。第一类是短期上下文属于单个Agent当次任务需要的信息用完后应该被丢弃或归档不该无限制累积。第二类是长期记忆属于Agent在长时间维度需要持续携带的用户偏好、领域知识等应该存在外部存储里而不是每次现传给模型。第三类是全局状态属于多个Agent共享的公共信息比如整个任务当前执行到哪一步、哪些资源已经被占用。全局状态的管理是最难的它要求存储层既有一致性保障又有并发控制能力。选型时你要确认框架是否支持状态持久化、是否提供检查点机制让系统可以中断恢复、是否能精细控制哪些信息该进入模型上下文哪些不该进。这几个能力决定了你的系统跑到后面是“越来越贵但越来越笨”还是“越用越顺越用越省”。5. 实测中的坑多智能体工具最常见的三类问题与排查思路工具选完只是开始真正把系统跑起来之后你会遇到一堆文档里找不到的问题。我把多智能体场景下我踩过、也帮别人排查过的高频问题整理出来每个问题都附上我的排查思路希望能帮你绕开这些坑。5.1 上下文飞轮效应Agent之间互相传递的信息越滚越大现象是这样的系统刚上线时一切正常跑了一周之后开始变慢再往后直接面临成本失控。打开日志一看每个Agent的prompt里都堆着几千行历史记录——上一轮对话的输出成了下一轮对话的输入几个Agent之间来回传信息量翻倍增长真正有用的信息被淹没在历史垃圾里。排查思路不是一上来就改代码而是先做“信息审计”。把系统跑两个典型任务打印出每个Agent完整的输入和输出然后用一个笨办法看哪些字段是必需的哪些字段是上一步传来的、但本步根本用不到的。这个审计一做完你会发现大部分上下文都是冗余的。解决的思路有几个方向一是给每个Agent设置上下文窗口上限超过就自动裁剪或摘要二是在信息链路里加一个专门的“摘要Agent”定期把长对话压缩成结构化摘要再传给下游三是把历史信息搬到外部存储模型只通过检索拿当前任务需要的片段。我自己的实践经验是先做第三个因为它的效果最直接——模型上下文保持短而精确成本立刻降下来。5.2 工具调用冲突两个Agent同时操作同一份数据多智能体系统里Agent之间没有天然的“锁”概念。我遇到过一次真实事故一个运营数据报表系统里写数据Agent和清洗数据Agent同时在跑都往同一个数据表里写内容结果互相覆盖最终报表里的数据乱成一团。排查了半天发现两个Agent的调用日志显示它们的执行时间完全重叠而框架层没有提供任何工具级互斥能力。这个问题的根源在于多Agent框架在设计时往往默认Agent之间是“友好协作”的但生产环境里的资源冲突是常态。排查顺序建议是先看是不是任务建模出了问题把本不该并行的任务设计成了并行再看工具本身有没有做幂等设计——如果工具调用是幂等的就算重复执行也不会产生坏结果最后才是考虑引入锁机制或队列机制强行让同一资源的操作串行化。谈到工具调用还得提醒一句市面上有些工具宣称“自动化执行”但实际上只是把提示词拼好真正操作还是要人工到网页里点一遍。这类“半自动工具”用在单Agent场景问题不大但放进多智能体协作流里会让链路随时断掉。踩过这种坑之后我对选型新增了一条要求所有Agent要用的工具必须是API级可编程调用的不支持API的就不要纳入协作链路。5.3 可观测性缺失没有链路追踪就没法谈排障多智能体系统本质上是一个分布式系统这句话我在前面说过一次这里想再强调一遍。分布式系统的一大定律是没有可观测性就没有系统可靠性。有一次线上系统出了一个诡异的问题用户反馈某些请求的响应内容牛头不对马嘴。我打开了所有Agent的日志发现日志是断的——某个Agent在某个环节没有任何记录。因为没有全链路追踪根本不知道上下文在哪个环节丢了后来去翻代码才发现那个Agent在处理特定输入时走了一条异常分支抛了异常直接返回了空结果而调用方没有做空值校验。从那之后我对可观测性的要求变得非常具体第一每个Agent的每次执行必须有trace能看到完整调用链第二每个环节的输入输出要留痕能回溯出模型收到的完整上下文第三工具调用的记录要单独记包括调了哪个工具、传了什么参数、返回了什么结果、耗时多少。这三样到位了排障就是从“猜谜”变成“看表”。选型时如果工具在这块支持不好要么自己额外接一层日志系统要么干脆换工具。6. 我的选型决策清单从四个问题出发匹配最优解聊了这么多最后给一份可以直接照着用的决策清单。我不打算给一个“万能答案”因为不存在这种东西。但你可以通过回答下面四个问题快速收敛出适合自己的工具组合。6.1 选型前先回答四个问题第一个问题你的任务真的需要多智能体吗如果任务可以拆成一个标准的线性工作流那单Agent加工作流引擎就够了硬上多智能体只会增加成本和排障难度。判断标准很简单你的任务里有没有需要专业分工、并行处理、以及不同角色之间需要来回协商的部分没有就不需要。第二个问题你的团队有没有能力驾驭复杂的编排框架LangGraph这类工具上限很高但学习曲线陡峭如果你团队里没有资深工程师或者项目周期很紧我更推荐先用低代码平台跑通业务再逐步往框架迁移。第三个问题你的系统对实时性的要求有多高多智能体之间的通信、调度都是有延迟的如果你要做的是实时客服这类强交互场景那么框架的调度开销、模型服务的响应速度都要纳入考量。某些强调“深度思考”的框架虽然结果好但推理延迟完全扛不住实时场景。第四个问题成本预算是按什么基准设计的多智能体系统的token消耗远高于单Agent如果你只按单Agent的消耗量来规划预算上线后一定会超。建议按“高峰期并发任务数×每任务平均Agent调用次数×单次调用token均值”来粗估月度成本再乘以一个1.5到2的系数作为安全余量。6.2 我的最终建议先跑通再优化后治理按我现在的经验来看多智能体工具选型其实不是一个“一次性决策”而是一个“螺旋式演进”的过程。第一阶段的目标是把一条最小链路跑通工具选简单的Agent数量克制一点能出结果就行第二阶段的目标是优化质量和成本引入可观测性、做上下文治理、迭代提示词第三阶段才是上治理手段做权限、审计、多项目隔离这些企业级能力。所以如果你现在正站在选型路口我的建议很朴素先去试。用你能快速上手的那套工具搭一个三个Agent的最小系统跑几个和你的业务真实相关的任务你很快就会得到比任何工具测评都靠谱的答案。工具没有绝对的优劣只有适配与不适配。我自己也是在跑通第一个粗糙版本之后才真正想明白这事的。多智能体这趟水很深但沿着这条路线走至少不会在源头就迷路。