上个月接到一个需求，客户开口就说：“帮我搭一个多智能体协作系统。”我听完第一反应不是打开笔记本，而是追问了一句：你说的“多智能体协作”，到底是想解决什么问题？
这个问题真的不是抬杠。市面上一眼望去全是能叫得上号的东西——Dify、AgentScope 2.0、AutoGen、LangGraph、MetaGPT、CrewAI，再加上各团队自己封装的那些被称作harness工程（约束型工程化方案）的内部架子。光“用什么平台搭”这几个字，就能把经验不少的人绕晕。更麻烦的是，这些方案背后的协作模式、工程复杂度、可控性和成本逻辑完全不是一个物种。为了给同样在这个路口纠结的读者一个参考，我把自己的选型思路、平台梳理和一套能跑通的搭建实操整理在下面，尽量一次说清楚。
1. 多智能体协作到底在“协作”什么：先给平台选型打个底
1.1 多智能体系统的核心架构与运行原理
在选平台之前，我一直觉得有必要先拆清楚：我们说的“多智能体协作”，底层到底是个什么样的系统在跑。
用一句大白话说，它就是一个“虚拟项目组”。你给每个成员（agent）分配一个身份，比如调研员、数据分析师、文案写手、代码审查员，然后让它们围绕同一个目标各自干活，再把各自的结果汇总成最终输出。听起来简单，但实际系统里有几个核心部件是任何平台都绕不开的。
第一个是角色定义与提示词管理。每个agent是什么身份、有什么人设、被允许调用哪些工具、输出格式是什么，这些都要有明确配置。第二个是通信与消息传递机制。稍微正式一点的说法是消息总线或消息路由，决定了A给B的结果怎么传、有没有格式约束、有没有异步排队。第三个是记忆与会话状态。全局状态和局部状态要分开，否则所有agent都背着一整段冗长历史，token很快爆掉。第四个是任务编排与调度，也就是谁先执行、谁后执行、失败之后是重试还是找人接管。
这个结构很像公司里一个跨职能项目组的运作方式：大家各司其职，靠会议和文档交换信息，负责人按照里程碑推进度，出了问题逐级汇报。我之所以反复用这个类比，是因为它对后续的平台选型有直接影响——有的平台把“通信和调度”做得很透明（workflow感强），有的平台刻意让agent之间自由对话（对话感强），你选的不是工具，而是你更认同哪一种项目组文化。
1.2 任务规划与拆解，到底是agent的能力还是模型的能力？
这是我在技术群里被问过最多次的一个问题，也是很多人选型时容易想错的点。先说结论：底层“思考”是模型的能力，而“怎么拆、拆完怎么验证、怎么重组”其实是agent框架和提示词工程决定的。
模型负责的是把一个大目标推理成可执行的子任务。比如“写一份新能源汽车市场分析报告”，模型能在语义层面上理解它需要行业数据、竞品信息、用户洞察、趋势预测这几个维度。但如果你真的让一个agent直接跑，结果往往是“想得很好，执行走样”——因为模型输出规划之后，框架并没有强制每个子任务都被正确执行、校验、再传递。
所以实操中真正拉开差距的是三件事：有没有把拆解结果结构化（是输出一份待办清单还是随口一段话）；有没有中间校验环节（每个子任务完成后是否有人检查产出质量）；以及子任务之间的依赖关系是否被显式处理（数据收集没完成，分析任务不应启动）。
我的经验是，在配置较好的大模型上（比如现在常见的DeepSeek开放平台、通义、Kimi这类），任务规划的效果主要取决于上下文设计和约束条件。把工具清单、角色背景、输出模板塞得越清晰，拆解质量越高。而platform的价值，就在于把这些约束固化成代码层面的流程，让模型少“自由发挥”。所以别再纠结“这是agent还是模型的能力”了，两边都重要，但模型管想，框架管落地。
1.3 harness工程和多智能体协同框架，差在哪？
很多文章把“harness”当成一种核心技术或者某个组件，其实它更像是一种工程哲学，翻译成中文最接近“约束工程”或“牵引框架”。它强调的是：把agent当作可以被约束的执行单元，通过一套严格的流程制度去控制它们的行为。这套制度包括输入输出Schema、状态机、人工审批节点、审计日志、异常重试策略等。
多智能体协同框架则更强调“让agent之间相对自由地协作”。比如AutoGen的聊天群组，MetaGPT那套模拟软件公司的分工，CrewAI的角色团队，它们都鼓励agent在目标范围内自主交流、商量着来。好处是灵活、泛化能力强，适合探索和研究；坏处是失控风险高，对话一旦发散，流程就可能偏离业务预期。
拿“多智能体企业采购助手”这类场景举例：采购涉及供应商筛选、比价、合同草拟、合规审查，每一环都有明确的输入输出、状态流转和人工审批。这时候用自由协同框架，agent可能在合同环节“发挥创意”，改出一个合规部门看都不敢看的条款。但用harness工程把合同生成限定为“只按模板填充、律师修改处必须标记、超过预算阈值自动转人工”之后，风险就能被压在一个可控范围内。所以我的判断是：业务落地选偏harness的方向，研究探索选偏框架的方向，而市面上的成熟平台，其实都在往这两个方向的交叉点走。
2. 主流的开源平台与框架，一次说清各自的定位
2.1 AgentScope 2.0：国产开源框架里的轻量选项
先聊AgentScope 2.0，因为在中文社区里它的讨论度和易用性都很突出。它是由阿里开源的，最新2.0版本被问到最多的一点就是“支不支持A2A模式的智能体协作”。答案是支持。A2A（Agent-to-Agent）是Google提出的一种开放协议，目标是让不同厂商的agent可以互相发现、通信和协作，AgentScope 2.0把这个协议纳入了自己的通信层。
这带来的直接好处是：如果你的系统里有不同团队、不同模型、甚至不同平台开发的agent，它们之间可以通过标准协议对话，而不是靠硬编码的接口一个套一个。我在实际测试中的感受是，AgentScope 2.0更重视轻量化和开发体验，安装简单，Python环境跑起来很快，适合做原型验证，也适合在已有系统里嵌入agent能力。
对比之下，你如果只是想做一个快速Demo，没必要直接上Dify这种重量级平台，AgentScope的学习成本会低很多。它的缺点是生态相对AutoGen这种老牌框架要小，中文文档虽然友好，但某些高级功能的示例代码还不太全，需要自己啃源码。不过在“多智能体协作”这个具体目标上，它的定位是准的：提供角色管理、消息通信、工具调用和分布式调度，不绑架你的架构。
2.2 其他几个常被摆在一起对比的框架
AutoGen是微软研究院出品的框架，主打会话式协作，几个ConversableAgent可以在一个GroupChat里互相讨论，最后由管理员agent收口。它的适用场景非常广，从客服多轮对话到模拟角色扮演都能做，但正因为自由度高，生产环境里容易出现对话漂移和token失控，需要花很多心思在约束层。
LangGraph则明显走了另一条路：用图来表达工作流，节点是agent行为，边是状态转移。它把“自由协作”改造成了“受控状态机”，每个步骤都清晰可见，可追溯。我很喜欢它的一点是，你可以把某个节点设置成人工介入，这在业务流程里特别实用。代价是心智负担稍重，需要你先想明白图的拓扑结构，再写代码，对新手不算友好。
MetaGPT和CrewAI各有侧重。MetaGPT把标准作业程序（SOP）理念融化在多agent协作中，适合软件研发项目的角色扮演式拆解，输入一句话需求就能产出需求文档、设计文档和代码的雏形，但是工程化落地需要二次开发。CrewAI以“创建团队”为核心，角色、目标、任务分离得清清楚楚，结构简洁，中文社区案例也不少，适合快速构建小规模协作。
这类框架的共同痛点是，它们只解决了“agent之间怎么协作”，没解决“怎么运维、监控、计费、权限管理”。真要上生产，你还是得自己补基础设施。这也是为什么很多团队最后会回头去看Dify这类集成度更高的平台。
2.3 可视化平台：Dify、Coze这类低代码方案适合谁？
Dify和Coze（扣子）代表另一类方案，它们把多智能体协作变成了“界面上的连线游戏”，很大程度上避免了写代码。
Dify是目前开源社区热度极高的LLM应用开发平台，它提供可视化的工作流编排，可以把多个agent节点串成一条流水线，每个节点配置模型、提示词和工具，节点之间自动传递结构化的数据。它还内置知识库（RAG）、外部API接入和完整的面板管理，非常适合做RagFlow这类知识库项目之上的业务系统。我周围不少团队就是用Dify做企业内部的问答机器人、文档助手、采购交互流程，开发效率提升明显。
Coze（扣子）则是字节跳动出品的智能体开发平台，在国内开发环境和多端发布上有优势，尤其是对接微信、飞书、抖音等平台很方便，插件生态丰富，适合个人开发者快速发布一个可交互的智能体。它相对于Dify更偏“产品化”，限制也更多，适合快速验证想法，不太适合做深度定制。
如果你问该选哪个：没有统一答案。要求快速上线、界面化管理、团队里没有太多纯代码开发人员，优先选Dify或Coze。要求完全掌控状态流、与公司现有系统深度集成、对schema和协议有强约束要求，那就回到AgentScope、LangGraph这类代码框架。
2.4 我的选型标准：看场景、看团队、看成本
最后说一条比较实用的选型心法：不追框架热度，只看三个边界。
第一个是场景边界。研究探索型任务，比如“试试多智能体能不能自动做行业研究”“写个虚拟辩论赛”，选AutoGen或AgentScope这类灵活框架；业务流程型任务，比如“供应商比价后自动生成采购合同”，选Dify工作流或用LangGraph自建；快速Demo验证，Coze足够，画个界面丢给业务朋友看，半天就能出结论。
第二个是团队边界。团队有2名以上能写代码、能看源码的工程师，完全可以选代码框架，后续扩展不受平台限制；团队以业务产品经理为主，没有人愿意天天折腾SDK，那可视化平台是唯一合理选择。
第三个是成本边界。这里说的成本不只是钱，还包括维护减肥成本。AgentScope或LangGraph这类方案，初期开发时间更长，后续运维需要自己盯；Dify和Coze开箱即用，但定制化也意味着要在它的框架里借力打力。成本角度还要算token消耗。自由协作框架里agent来回对话，token是线性增长甚至超线性增长的；状态机式的工作流，虽然每次任务都要重复走流程，但token是可控的。做预算时请一定把这一点算进去。
3. 实操：用AgentScope 2.0从零搭一个双智能体协作Demo
3.1 基础环境准备和模型接入
纸上谈兵半天，不如跑一个Demo。下面这套流程是我自己走通过的一条路径，尽量写得傻瓜一点。
基础环境是Python 3.10+，推荐建一个独立虚拟环境，避免依赖冲突。然后安装AgentScope：
pip install agentscopeAgentScope支持很多模型接入方式。如果你已经在用DeepSeek开放平台，只需要把它配置成OpenAI兼容模式；如果你的模型是通义、Kimi这类国产模型，也都有对应的配置方式，重点是把api_key和base_url写对。示例配置是这样的，实际参数以你所用版本的官方文档为准：
import agentscope agentscope.init( model_configs={ "config_name": "deepseek", "model_type": "openai", "model_name": "deepseek-chat", "api_key": "YOUR_API_KEY", "base_url": "https://api.deepseek.com" } )配置完模型，建议先打印一条最简单的消息做连通性测试，确认网络、密钥、模型名都没问题，再往下写业务逻辑。别问我为什么强调这一步，我在不同平台浪费过的半小时都够写好几个agent了。
3.2 定义两个角色的协作流程
Demo目标定为“调研并输出一份简短报告”，两个agent角色：一个研究员（Researcher），负责围绕主题收集资料；一个写手（Writer），负责把调研结果整理成文。
在AgentScope里，每个agent本质上是一个继承了AgentBase类、实现了reply方法的对象。类里定义它的角色、提示词和可调用的工具，reply方法决定拿到输入后返回什么。下面是一段流程示意代码（非完整可跑版本，正式开发请以官方文档和SDK为准）：
import agentscope from agentscope.agent import AgentBase class Researcher(AgentBase): def __init__(self, name="researcher", **kwargs): super().__init__(name=name, **kwargs) self.sys_prompt = "你是一名行业研究员，擅长查找和汇总资料。" def reply(self, x=None): # x是上一个节点传入的消息 topic = x["content"] prompt = f"请围绕主题「{topic}」收集要点资料，输出结构化列表。" response = self.model(prompt) return {"role": "assistant", "content": response} class Writer(AgentBase): def __init__(self, name="writer", **kwargs): super().__init__(name=name, **kwargs) self.sys_prompt = "你是一名报告撰写者，擅长把材料整理成通顺简洁的文章。" def reply(self, x=None): material = x["content"] prompt = f"根据以下调研材料，写一段150字的报告摘要：\n{material}" response = self.model(prompt) return {"role": "assistant", "content": response}接下来是流程编排。最简单的方式是用AgentScope内置的Pipeline或团队协调器，把两个agent串行执行：先跑Research，把结果传给Writer，最后输出报告。在只接模型、没接其他工具的情况下，这个Demo跑通只需要几分钟。跑通之后，建议立刻改动Prompt里的一个约束条件，观察输出风格的变化，这能帮你建立“协作质量和提示词强相关”的直觉。
3.3 跑通后，Demo离业务系统还差什么？
很多读者跑通上面的流程后会觉得：“就这？”没错，真正的挑战在后面。Demo只能证明“两个agent可以协作”，但它离业务系统还差四件事。
第一件事是工具调用。真实场景里，agent需要查数据库、调用搜索API、请求采购系统接口，而不是纯靠模型内部知识。AgentScope和大多数框架都支持Function Calling，你只需要把工具注册成函数列表，agent会自主决定什么时候调用。第二件事是记忆持久化。Demo里的上下文都在内存里，进程重启就没了。业务系统需要把会话状态、中间产出物存到数据库里，至少保证异常恢复后还能接着跑。第三件事是权限和审计。谁触发了任务、每一步做了什么、用了哪些数据，都要留痕，这在企业采购、金融、政务场景里是硬要求。第四件事是人工介入。状态机里至少要有一个节点能随时“拉停”，让人类接管，不然系统运营起来你会非常焦虑。
这些差距，平台只能帮你解决一部分，剩下的需要你在架构设计里补上。
4. 业务侧怎么落地：以“企业采购助手”为例拆解多智能体设计
4.1 采购场景适合拆成哪些智能体角色
用“企业采购助手”这个场景来做多智能体设计的例子，是因为它链条清晰、角色分明，是了解业务落地的绝佳样本。
先看采购业务天然存在的环节：需求接收、供应商筛选、比价、合同草拟、合规审查、审批建议。这些环节相互依赖，且错误成本高。把它拆成多智能体系统后，每个环节对应一个或一组agent：
需求理解agent负责解析需求方提交的自然语言描述，比如“需要采购50台开发笔记本，预算不超过60万”，把它转成结构化的需求字段。供应商检索agent根据需求字段去供应商库或外部平台搜索候选名单。比价分析agent对候选供应商的价格、交期、历史合作记录做对比，并输出推荐排名。合同生成agent基于采购模板和比价结果生成合同初稿。合规审查agent检查合同和价格是否满足公司采购制度，比如违规条款、超预算预警、黑名单供应商识别。
这五个角色加起来就是一个完整的“多智能体采购小组”，它们之间的协作不是模糊聊天，而是严格的输入输出对接。
4.2 任务流转与人工审批节点的设计
设计完整套角色后，核心问题是任务怎么流转。以“预算超限”为例：比价分析agent算出最优供应商报价后，如果价格超过需求agent设定的阈值，它不能自己拍板继续推进，必须把结果反馈给合规审查agent，同时将整个决策链路上的中间数据完整传给上游，由人工审批节点介入。
这就是所谓“人工审批节点”的典型设计方式。在多智能体协作平台里，人工介入不是“事后看报告”，而是作为流程中的一个节点存在。它在Dify工作流中可以是“人工确认”组件，在LangGraph里可以是interrupt节点，在自研harness里就是一个待办任务状态。关键是要把决策依据结构化地呈现给审批人，而不是塞给人类一大段对话记录让人自己琢磨。
我强烈建议你在设计流程时，把每个需要人工介入的节点标出来，然后问自己三个问题：这里能不能由agent自动完成？自动完成的风险是什么？如果出错，兜底方案是什么？只有答案都是“可以自动”“风险可控”“有兜底”时，才把这个节点设成免人工。否则，宁可多放一个人工确认。
4.3 为什么这类业务更倾向harness工程而不是自由协作
有些读者可能会问：AutoGen那种自由聊天模式不也能完成采购流程吗？理论上能，但实践中风险太高。
自由协作模式下，agent之间的对话自然且灵活，但也意味着不可控。比价分析agent可能在交流中“领悟”出一个合同条款调整建议；合同生成agent可能为了让文案更通顺，擅自改掉固定条款；合规审查agent如果没有拿到明确的约束规则，可能会给出过于宽松的审查意见。这些在自由框架里很难预防，因为agent的对话内容本质上是模型推理的结果，概率性永远存在。
harness工程的核心就是把“灵活”收起来，把“可控”放到第一位。采购流程里，每一个agent的输入输出都有固定schema，合同生成只允许使用模板，条款改动必须标注原因，任何跨状态的操作都要落审计日志。你做得越多，系统就越像一个带规则引擎的业务系统，而不是一个自由流浪的AI聊天室。
从平台选择来说，这意味着两种路径：用Dify这样的人工审批+工作流节点去编排，快速上线，但高度依赖平台能力边界；用LangGraph或自研harness架构去自建状态机，完全可控，但开发成本高。我在实际项目中，一般先用Dify做原型，验证业务流程逻辑，再根据复杂度和定制需求，决定要不要下沉到代码层。
5. 踩坑记录：多智能体协作平台落地中的典型问题
5.1 智能体之间互相“甩锅”，上下文接不上
最常见的坑：两个agent协作时，传入的message内容没有结构化，导致下游agent看不懂上游的输出。我之前调一个“资料收集+报告生成”的双agent系统时，研究员输出了一堆Markdown标题、无序列表和备注，写手直接把这堆内容当成正文引用，结果报告里全是乱七八糟的格式。
排查思路很简单：在上游agent输出时强加结构约束，让返回结果必须包含指定的字段，比如“references”“summary”“raw_data”。这样下游agent拿到的就是干净的JSON或字典，而不是一大段对话文本。再配合平台的trace功能，每一步都能看到消息流在哪里断掉。只要消息格式统一了，80%的协作问题都能解决。
5.2 上下文越来越长，token成本直接失控
自由协作类框架最容易踩这个坑。多个agent共享一个GroupChat历史，每个agent看到的都是全部聊天记录，token消耗随轮次线性增长。有一次我给客户搭了一个多轮讨论的Demo，跑了20多轮，账单比预期翻了三倍。
控制token成本的办法有几种：给每个agent设置只读最近N条消息的视野，而不是全量历史；把中间产出物抽取出来存进知识库，后续agent只查关键信息；给协作流程设置最大轮数，比如“最多讨论3轮，第3轮必须收敛出结论”。如果平台支持子图或子流程，尽量把长流程切成短流程段，每段独立记忆。这些手段都不复杂，但要在架构初期就规划好，后期再补很麻烦。
5.3 agent工具调用陷入死循环
另一个典型的“坑”是agent在工具调用上陷入循环：它调用了搜索工具，觉得结果不够，又调用一次，再觉得不够，又调用一次，甚至在函数调用参数里出现重复的同一个查询。这个问题本质是模型“不确定”，反复尝试追求更完美的答案，但它并不真正理解外部系统的限制。
解决办法有两个方向。一是在提示词里明确工具的使用策略：优先用已有信息，不要重复调用同一个工具，调用前想清楚三次还查不到就升级为人工。二是在框架层面做工具调用次数的限流和超时控制。AgentScope、LangGraph这类框架都支持为每个节点设置最大执行次数或超时时间，配好后，循环重试会被强制打断，至少不会让账单在半夜悄悄燃烧。
5.4 排查技巧：日志、trace和沙箱
多智能体系统比单智能体系统难调试得多，因为问题可能出在prompt、上下文、工具调用、模型配置等多个层面。我的排查习惯是三层递进。
先看trace。AgentScope和LangGraph都提供了比较完整的调用链追踪，每一条消息从哪里来到哪里去、模型请求耗时多少、输出内容是什么，都在trace里。运行一次任务后，我会习惯性地把trace拉出来看一遍，重点检查有没有节点没被调用、有没有消息被重复传递。再看日志。业务平台里，每个agent要打印自己的入参、出参和关键决策，不要嫌日志多，出bug的时候就知道多香了。最后是沙箱。给agent的工具调用做一个“假数据版”沙箱，比如把搜索API换成返回固定结果集的本地函数，把数据库操作封装成内存副本，这样能快速定位问题到底出在agent逻辑还是外部依赖。
如果已经排查了一轮还是找不到原因，还有一个笨但有效的方法：只保留一个agent，把其他agent的节点暂时注释掉，看单个agent能不能正确完成任务。能，说明问题出在协作链路；不能，说明那个agent自身的prompt或工具配置有问题。这种“二分定位法”在多智能体项目里特别实用。
最后分享一个我自己的习惯：现在接到“多智能体”需求，第一反应不是选最新框架，而是先在纸上画一张任务流转图，标清楚每个角色、输入输出、人工介入点和异常兜底策略。这张图画完，平台选择自然就有了。画图的过程中，你要是不自觉地把某个步骤画成了“自由讨论”，那就要警惕了——业务系统里“自由”越少，越可控。按这张图去做选型和设计，通常你就不会在那些花哨的平台功能里迷路。
