开篇在AI应用开发里我为什么推荐AgentScope如果你最近在折腾大模型应用大概率已经感受过那种单点Demo秒出、一上复杂场景就抓瞎的憋屈感。调通一个ChatBot容易但要做成多个模型协同、既能检索知识库又能编排工作流、还得扛住企业级并发的系统难度完全不是一个量级。我第一次接触到AgentScope是在做一个内部知识问答平台的时候。当时面临着几个很现实的问题团队里有同事用LangChain有人用AutoGen各有各的道理但真要凑在一起干活发现大家其实都在重复造轮子。后来我系统性地把AgentScope从入门到源码层面研究了一遍又在一个中型项目里落地了AgentScope 2.0那个阶段踩了不少坑也积累了不少经验今天把使用心得整理出来希望对正在选型或正在纠结技术路线的朋友有帮助。这篇文章会从AgentScope是什么、为什么值得用、以及在Java企业级环境里怎么落地这几个维度展开还会把2.0版本重点推的RAG as Service和多Agent配置单独拿出来讲清楚。没有那么多高高在上的概念就是实际开发里会碰到的东西你能直接拿去用的东西。1. 先说清楚AgentScope到底解决的是什么问题1.1 多智能体协作不是玩具式的多轮对话很多刚接触这个概念的人以为多个Agent就是在代码里写几个角色然后让它们互相喊话。如果你的业务就这么简单那确实框架不框架的差别不大。但真实场景远没有这么轻松。我举一个自己做过项目的配置一套供应链风险预警系统。里面有一个数据采集Agent负责对接外部API拉取物流状态有一个识别Agent负责从非结构化文本里抽取异常信息有一个分析Agent接入大模型做归因判断还有一个通知Agent在确认风险等级后自动生成报告并推送给相关岗位。这四个Agent之间并不是简单的你问我答而是需要并行执行、条件触发、结果路由这些能力。AgentScope的设计目标就是把这种复杂的协作流程变成一种可描述、可编排的工程模型。它内置了消息传递机制Agent之间不直接互相调用方法而是通过消息总线进行通信。这个设计一开始看会觉得多一层抽象但真正跑起来会发现它换来的好处太明显了每个Agent可以被独立替换、独立升级消息可以回溯整个调用链可以监控。这在调试和运维阶段救了我无数次。1.2 它的定位不是重框架是把复杂留给自己、把简单留给开发者我在刚开始看AgentScope文档的时候一个很直观的感受就是它没有把我当傻子。它会给你提供高度抽象的API但也允许你在底层做细粒度的控制。举个例子在别的框架里你如果想要自定义一个记忆管理策略往往得绕过框架自带的高层封装甚至要去改框架源码。但在AgentScope里你可以直接通过配置项插拔记忆模块也可以用Python类去实现自己的记忆策略再用ReagentPipeline挂载进去。这种双向开放的思路拉低的不仅是你进入项目的门槛也拉低了你在项目中期做定制化改造的难度。我记得我们团队第一次做灰度测试时产品经理要求临时加一个敏感词预过滤Agent我们只花了半天时间就把这个Agent写出来挂到了原有pipeline里。这种体验在传统开发流程里很难想象框架帮我把底层消息调度、并发控制、生命周期管理全部处理好了我只需要关心业务逻辑本身。1.3 适合谁用、不适合谁用我的建议是如果你的项目里只有一个模型调用、一个提示词模板那完全没必要上AgentScope直接用API SDK就够了。但当你的业务开始出现以下任何一个信号就应该认真考虑这类框架业务逻辑里出现了角色分工不同模型或不同Prompt承担不同职能需要把工具调用、外部API、知识库检索编排到一个统一流程里需要可视化监控Agent的运行状态、消息流转你预感未来会有并发、可靠性、可回滚这些工程化诉求信号一旦出现AgentScope就是那个能陪你从原型走到生产的框架。它不是唯一的选项但以我体验下来的结果看它是目前把易用性和工程可靠性平衡得比较好的一个。2. 深入体验之后我觉得AgentScope最核心的五个设计2.1 消息驱动的通信范式让Agent之间真正解耦AgentScope最核心的抽象就是消息。在框架内部Agent之间交换的所有数据都被包装成一个消息对象里面有发送者、接收者、内容类型、元数据这些字段。你在写Agent的时候不需要关心你的队友延迟有多高、返回格式长什么样只需要声明自己监听哪类消息、产出哪类消息。这里我用一个生活中的类比来解释这就像公司里不同部门之间通过工单系统协同而不是直接跑到隔壁工位问。好处是什么呢一旦问问题这件动作被标准化成工单那谁来处理这个工单就可以动态调整缺人了可以由另一个部门顶上工单也可以通过流程引擎自动路由。AgentScope对Agent之间通信的处理就是这个思路。它不是最快的路径但它是最好维护的路径。在实际落地中这个机制给我带来的最大红利是故障隔离。有一个阶段我们部署的某个第三方模型经常超时如果是硬编码调用链一次超时可能导致整个流程挂掉。但在消息驱动的架构下这个模型所在的Agent可以被单独配置超时和熔断策略其他Agent完全不受影响照常处理自己的任务。2.2 高度可插拔的组件体系拧螺丝就能换功能AgentScope的架构里像模型API、记忆存储、工具集合、提示词模板、输出解析这些能力全部被设计成可替换的组件。你换了模型商不用改业务代码只需改一行配置你想从内存记忆换成数据库记忆也只需要替换一个类。这个设计我喜欢称之为拧螺丝式开发。它带来的一个隐性好处是团队成员之间并行开发的冲突少了。你在写知识库处理我在写Agent编排逻辑最终只需要在配置层做整合。对于开发周期紧张的项目来说这个价值是无法用代码量衡量的。2.3 内置了完整的MsgHub消息中心支撑分布式部署如果你的Agent只在单机、单进程环境里跑那自己用队列也能实现协作。但AgentScope 2.0在更早的版本基础上把消息中心这只隐形的手独立成了服务支持跨进程、跨节点的消息传递与路由。也就是说你可以把Agent A部署在GPU机器上Agent B部署在CPU机器上它们之间通过网络通信协作。这一点在企业级环境里非常关键。因为大多数企业不可能让每个Agent都跑在贵得要死的GPU服务器上。有了这种分布式的消息中心你就可以按需分配算力。比如把大模型推理Agent放到GPU集群把逻辑处理Agent放到普通容器里成本瞬间就降下来了。2.4 内置了Filter机制让干预变得极其优雅Filter是AgentScope里一个容易被低估但实用性极高的特性。它可以在消息发送前、接收后、Agent执行业务逻辑之前这些节点插入自定义的检查、转换、增强逻辑。最典型的用法是做安全审核。我们项目里有一个需求所有发给大模型的内容需要先经过去隐私化处理大模型返回的内容再经过一轮敏感词扫描才能发给用户。加了AgentScope之后这两个环节被做成了两个Filter挂到消息链路上完全不用改业务逻辑。后来有一次安全团队要求调整黑名单规则我们升级一次配置几十秒就完成了一点都没有打扰到核心逻辑。2.5 从开发到生产的无缝感确实难得很多框架开发时很爽部署时就露出原型了。AgentScope在这方面的体验相当出色。本地可以用分布式模式跑一组进程部署到生产时依然可以沿用同一套配置只是把宿主机地址换成真实的服务地址而已。它还提供了API服务化能力可以直接把Agent应用打包成一个HTTP服务暴露给它方调用。这样你在做前后端分离时前端同学不需要关心你后面是几个Agent在协作他只需要调用一个统一接口拿回一个标准响应。这种开发和生产环境一致性所省的沟通成本和心智负担你用一次就会上瘾。3. 重点拆解AgentScope 2.0RAG as Service和开箱即用的多Agent编排3.1 RAG as Service到底是什么为什么不是一句口号RAG检索增强生成是当下企业落地大模型最高频的方式。但RAG的落地复杂度其实很高不是丢个向量库进去就行。数据切块、索引管理、召回策略、重排序、上下文裁剪、和提示词的拼接每个环节都需要精密配合。AgentScope 2.0提出的RAG as Service就是把这些复杂度收敛成一个后端服务开发者只需通过一个接口传入用户问题就能拿到包含检索结果和模型答案的完整回复。它把这个过程当成一个独立的服务来对待意味着你可以像调用普通的API一样调用RAG能力甚至可以在多个Agent之间共享同一个RAG服务。从我的实践反馈来看这个设计对中小团队、对项目紧的团队太友好了。你不需要自己研究向量数据库的索引参数不需要维护一套分块策略的代码框架把这些沉淀成了可复用的能力。当然如果你想深度调优也没问题它的下层能力仍然是开放可配置的只是给了你用最简单路径先跑起来的选项。3.2 一个RAG服务是怎么组织起来的要理解RAG as Service的精髓得先知道它内部组织起了哪几样东西。我在项目里配的RAG服务包含以下几个核心组件文档解析器负责把PDF、Word、Markdown这些非结构化文档转成纯文本分块策略按照语义边界、固定长度等规则把文档切成适合向量化的片段向量存储保存文本片段对应的向量表示检索器根据用户问题的向量从存储里召回最相关的片段重排序器对召回的片段做精细化筛选把真正相关的排到前面提示词模板将用户问题检索片段拼成符合模型要求的输入AgentScope 2.0通过配置项把这些环节串成了一条流水线。你更新一个文档服务内部会自动完成切块、向量化、入库的流程不需要你关心底层的调度。而每个环节都有对应的设置项可以微调。比如分块长度默认是512个Token但如果你处理的是合同文本可能需要调整到256甚至128因为合同条款语义集中过大的分块反而会引入噪声。3.3 多Agent调用配置到底怎么配才能不打架很多人在社区问AgentScope 2.0如何配置多Agent调用尤其是Agent之间怎么避免消息混乱、怎么控制调用顺序。这里分享一下我实践中摸索出来的配置思路。首先在配置层面每个Agent需要用唯一的name来标识。AgentScope靠这个标识来路由消息如果重名轻则消息错投重则直接抛异常。这个点看起来基础但线上出问题最多的恰恰是这种低级错误。其次Agent之间的协作方式建议优先用Pipeline模式而不是自由对话模式。Pipeline模式就像工厂里的流水线前一个Agent加工完把半成品交给下一个Agent。比如在内容审核场景里风险识别Agent必须先于人工复核Agent执行这种强依赖关系放在流水线里逻辑会非常明确。具体配置时我用的是如下形式agents: risk_detect: role: detector model: qwen-max memory: shared_kb human_review: role: reviewer model: qwen-plus depends_on: risk_detect pipeline: - risk_detect - human_review这段配置表达的意思是risk_detect先跑跑完后把结果送给human_review。依赖关系清晰任何人接手这个项目看配置能秒懂整个流程。如果你需要更复杂的并行路由AgentScope也支持消息订阅模式。比如通知Agent同时监听风险分析结果和用户反馈意见两类消息谁先到谁触发。这种模式灵活性更高但代价是排查问题的难度变大因为消息的到来顺序不确定。我建议初学者从Pipeline开始等熟悉了再挑战并行。3.4 AgentScope 2.0版本里那些不起眼但救命的升级除了RAG as Service和多Agent配置2.0版本还有一些细节层面的升级用完就不想回去了。一个是模型网关的完善。它统一了对各大模型商的调用协议你可以在同一个流程里混用不同厂商的模型而不需要维护多套SDK。项目里最省心的一幕就是评估阶段发现A厂商的新模型效果好直接在配置里把模型名换掉十分钟完成切换业务零感知。另一个是运行指标的暴露。2.0版本把每次Agent调用的耗时、Token消耗、成功失败率这些指标都暴露出来可以直接接进已有的监控体系。对运维来说这个能力让大模型应用不再是黑盒出了问题可以先从指标判断方向而不是盲目猜。4. Java版企业级实战从API调用到生产落地的完整路径4.1 AgentScope Java版是谁为什么企业会被它吸引虽然Python是AI开发的首选但在企业环境里Java仍然是后端的统治级语言。很多公司的核心技术栈就是Java你不可能为了一个AI框架把所有服务都推倒重写。AgentScope Java版的出现解决了这个最后一公里的问题。Java版的核心定位你可以把它理解成Python版的企业级镜像。它的通信协议与Python版同源也就是说你可以混用Java Agent和Python Agent。举例说明你在Python环境里跑着一个文本分析Agent然后在Java的Spring Boot服务里封装一个调度Agent两个Agent之间可以通过MsgHub进行通信。这种跨语言协作的能力对大型企业来说价值是巨大的因为它允许不同语言栈的团队各自负责自己擅长的部分。4.2 上手AgentScope Java的正确姿势Maven依赖和Spring集成Java版接入方式非常简洁使用Maven依赖你只需要引入核心包再配合你的Spring Boot工程做一些基础配置。dependency groupIdcom.alibaba.agentscope/groupId artifactIdagentscope-java/artifactId version2.0.0/version /dependency引入依赖后建议先搭一个最基础的消息链路让两个Agent通过框架互相发一条消息。我见过太多人一上来就配复杂的RAG结果出了问题都不知道是框架的问题还是自己配置的问题。先跑通最小闭环再层层加码这种增量式开发在引入新框架时是最稳妥的。4.3 拿来就能用的一个Java Agent示例以做一个自动总结并分派工单的Agent为例我给你展示一个完整的Java代码结构public class TicketAnalyzeAgent extends AgentBase { Override protected Message process(Message input) { String ticketContent (String) input.getContent(); String analysis callLlm(请提取工单中的紧急程度和问题类型。工单内容如下 ticketContent); return new Message( this.getName(), dispatch_agent, analysis ); } }你自定义的Agent只需要继承AgentBase实现process方法框架就会自动接管消息的分发。上面这段代码的逻辑是收到工单消息后调用大模型做分析然后以消息的形式把分析结果转发给dispatch_agent。要启动这个Agent也很简单public static void main(String[] args) { AgentBase agent new TicketAnalyzeAgent(); agent.setName(ticket_analyze_agent); MsgHub hub MsgHub.getInstance(); hub.register(agent); hub.start(); }看到没整个流程完全不涉及底层的网络通信、线程调度框架把这些全部封装好了。这也回答了很多人Java做AI开发会不会很繁琐的疑问——跟写普通业务接口差不多只不过你的方法不再是从Controller接参数而是从消息总线拿消息。4.4 企业级部署Java Agent的核心避坑点Java版在企业级部署时有几个坑是我亲身踩过的说给你听能省不少时间。第一点是JVM内存设置尤其是你的Agent需要加载本地向量模型时。默认的JVM堆内存往往不够用频繁Full GC会让Agent响应慢得像卡死。建议至少把堆内存设置在4GB以上并且要评估本地模型大小给足内存余量。我踩过这个坑加本地Embedding模型后两个请求下来就内存溢出了。第二点是线程池配置。AgentScope Java版默认的并发数在本地开发环境是够用的但一旦上了生产如果你预估每秒有几十甚至上百个请求进来必须重写线程池参数。不重写的话高并发下排队现象会非常严重你甚至会误以为是框架性能不行。实话说框架本身性能没的问题是你没有给它足够的资源。第三点是网络超时。AgentScope跨进程通信依赖网络如果你在有负载均衡的Kubernetes环境里部署网络抖动会比较常见。建议在Agent配置里设置合理的超时时间和重试次数否则偶发的主机漂移就能让你的调用链断掉。这些在文档里可能不起眼但生产环境的可靠度就是靠这些细节堆起来的。4.5 当我们谈企业级实战时到底在谈什么企业级实战这个词已经被说烂了但真正经历过的都知道它包含什么。它意味着你要面对几百个Agent的并发注册、要处理消息路由的负载均衡、要保证掉线后Agent能自动重连、要有权限控制防止乱调用。AgentScope Java版在这些方面已经做了不少工程沉淀。它的MsgHub支持配置多个实例也自带服务发现能力多个服务之间即使是 Kubernetes 容器化部署也能通过服务名互相访问。加上它内置了消息NACK机制Agent处理失败会把消息重新放回队列重试不会直接把消息丢掉。对必须不丢消息的企业业务来说这是底线能力的保障。5. 新手最容易踩的坑我帮你提前排掉5.1 明确你的项目边界别凡事都要上智能体在分享技术细节之前我想先泼一盆冷水。AgentScope 2.0确实好用但请不要为了用框架而用框架。很多人在项目初期被多智能体这个概念冲昏头脑明明一个提示词模板可以解决的需求非要拆三个Agent。结果就是调试困难、Token成本飙升、用户体验还很差。这个话题值得认真对待如果业务是问一个知识库问题这种简单的问答场景直接用RAG服务包装一个接口就够了不需要搭建多Agent协作系统。我在实践中养成了一个判断准则只有当整个任务链路中出现了三种及以上不同的职责时才值得去拆Agent。如果你的任务只有入口、处理、出口用传统SDK方式会更轻巧、更稳。合适的工具用在合适的场景里才是工程成熟的标志。5.2 别忽视消息内容的序列化设计AgentScope的消息在跨进程传递时会经过序列化和反序列化。一个非常常见的坑是你在消息里放了一个自定义的Python对象然后这个Agent在另一个进程里那边根本识别不了这个对象直接崩溃。我的建议是所有跨Agent的消息内容尽量使用JSON字符串或者简单的基础类型。如果确实需要传复杂结构你可以考虑在消息里放一个数据引用比如数据库记录ID然后让接收方自己取数。这个方案既解决了序列化问题也让消息体变小了传输效率反而更高。5.3 把日志打印当成一等公民AgentScope的调试不像普通程序那样直观因为Agent的运行是异步的、甚至横跨多个进程。如果日志不做好出了问题你就像在伸手不见五指的房间里找钥匙。这里我给出一套亲测可用的日志规范每条消息发送和接收必须记录消息ID、发送者、接收者、时间戳每个Agent的process方法进入和退出都要打日志调用大模型的步骤记录下Token消耗和响应耗时异常处理里记录堆栈信息并且要保留当时的上下文消息内容这套规范看起来繁琐但真到了排查线上问题的时候你会发现每一条日志都有它的用处。有一次我们定位一个消息丢失问题最后就是靠日志时序还原了完整的过程原来是消息投递成功但Agent在处理时抛了个异常异常没被捕获消息就消失了。没有日志这个问题根本无从查起。5.4 RAG调优里分块和重排序是提效最大的环节如果你用了AgentScope 2.0的RAG服务先别急着调大模型提示词。以我的经验来看大多数回答不满意的问题根源不在模型而在检索质量上。分块大小很关键。我以合同场景举例一份合同里往往包含多个不同维度的条款如果分块过大一个块里揉进了几个不同的主题检索时就会出现看似相关、实则混淆的情况如果分块过小语义会被切碎检索出来的片段信息量又不够模型生成完整回答。分块大小没有银弹需要靠测试集来验证。另外重排序器值得关注。初版RAG很多时候召回结果排序并不理想而一个高质量的重排序器可能就换来20%以上的效果提升。5.5 先跑通再优化一次系统性的错误示范看了不少社区里的提问帖发现一个普遍现象很多人一上来就想搭一个完美的Agent系统既要多Agent协作又要RAG又要流式输出一个工程恨不得包含所有特性。结果呢配了两星期还没跑通然后就断定框架不行。这显然是心态问题在作怪。我用AgentScope的经验不管项目多复杂永远是先做最小集一个Agent、一个模型、一个Prompt先把链路跑通然后逐步加第二个Agent确认协作正常后再引入RAG再加入Filter最后再调监控和日志。每一层都验证过再往下一层走你踩坑的速度反而最快因为你不用在找坑上浪费太多时间。6. 从能用到好用两个模式化的实战配置参考6.1 RAG as Service落地配置参考这里我给出一份企业落地RAG服务时可以直接参考的配置思路rag_service: embedding: model: text-embedding-v2 dimension: 1024 chunk: strategy: semantic max_tokens: 256 overlap: 20 retriever: top_k: 8 score_threshold: 0.35 rerank: enabled: true model: rerank-v2 prompt_template: | 请根据以下资料回答问题。如果资料中没有答案 请明确回复资料中未找到相关信息。 问题{question} 资料{context}参数说明top_k设置为8配合重排序能保证召回充足又不过度引入噪声。score_threshold设为0.35是为了过滤掉那些语义距离过远的无效片段。太低了会增加幻觉风险太高了可能什么也召不回。overlap设置为20个Token用来缓解分块边界信息被切断的问题。别小看这20个Token它经常能让答案的连贯性上一个台阶。如果你发现回答质量不佳优先调整分块的大小和重排序模型这两个选项对最终效果的影响最大。6.2 多Agent编排的两种模式哪种适合你多Agent编排方式上我归纳出两种最佳实践Pipeline模式适合有固定先后顺序的业务。例如客服工单处理流先做意图识别再做信息补全再做知识库检索最后生成回复。这种模式逻辑清晰链路直观是首选。Workflow模式适合有分支流向的业务。例如自动报销审核流如果你的报销金额在500元以下Agent自动通过金额在500到5000元之间转给财务主管复核金额大于5000元直接转给部门负责人审批。这种分支场景AgentScope也支持只需要在消息内容中指定路由字段接收方通过配置订阅对应路由的消息即可。它比Pipeline灵活但也会增加系统复杂性需要自己权衡。就我个人的体会初学阶段建议至少把Pipeline吃透它覆盖了80%以上的业务场景。6.3 梳理Agent业务边界时用职责表代替拍脑袋在设计Agent时我非常推荐团队用一张职责表来规划Agent的边界避免Agent职责重叠。字段可以包含Agent名称、所属模块、核心职责、依赖的Agent、输出内容格式。为什么非要做这张表因为多Agent系统最怕你中有我、我中有你。如果你发现两个Agent经常处理相同类型的输入或者产出类似的结果你就应该考虑是不是需要合并。一张清晰的职责表能帮你在设计阶段就发现这类问题而不是等代码写了两千行之后才去重构。磨刀不误砍柴工这张表格值得多花半小时好好画清楚。7. 排查问题和调优的实战心得7.1 如果AgentA没有收到消息该怎么查我在社区里看到的最常见的问题就是我发了消息但另一个Agent没有反应。排查这个问题我有一套固定的路径按顺序检查基本能覆盖绝大多数情况。第一步确认两个Agent是否注册到了同一个MsgHub实例。很多人在本地调试时启动了两个独立进程但配了不同的MsgHub消息当然不会互通。第二步确认发送者的消息里接收者字段是否填了目标事件接收者的名称。填错了的话框架会默认丢弃这条消息。第三步去消息汇总视图看事件流转状态信息检查消息是否成功进入了队列。这一步能快速区分是根本没发出去还是发出去了但处理失败。这套路径我每次排查都有效它比乱改配置要高效得多。7.2 性能不够快先别甩锅给框架AgentScope太慢了是一个经常被提出的观点但真相往往并非如此。如果你的Agent单次调用耗时在几秒先排查是不是同时存在多次LLM调用如果单个流程里串联了5个Agent、每个Agent都调用了一次模型总耗时就约等于5倍的单次调用耗时这换成哪家框架都一样。优化性能的第一个着力点减少串行调用。如果Agent A的输出不依赖Agent B的完整结果就把方案设计成并行触发。第二个着力点使用流式输出让用户在收到全量回复之前先看到部分内容体感上会快很多。第三个着力点启用缓存。对于一些重复性高、结果确定的问题配置语义缓存之后命中缓存时就能直接返回结果不需要再调用模型。这三招之后性能问题通常能解决大半。7.3 Token成本过高问题往往出在上下文污染你可能会发现明明一个简单问题每次调用却消耗了大量Token。这八成是上下文管理出了问题也就是你的Agent在构造输入时塞入了太多无关历史信息。AgentScope提供了消息清理和消息摘要机制。我的建议是对于长会话定期用模型对历史消息做摘要把摘要作为新的上下文输入而不是把所有历史消息全部塞入提示词。这一步是省成本最有效的手段没有之一。根据我的经验这种方式可以让Token消耗降低30%到50%而且在大多数情况下回答质量不会下降。如果你用的模型支持外部记忆能力也可以把部分上下文托管到记忆服务里而不是全部塞进对话窗口。最后再说点实在的AgentScope这个好东西如果你只是把它当成一个多Agent聊天框架那真的有点屈才了。它真正的价值在于帮你把从原型到生产这条路铺平让非AI方向的工程师也能快速上手搭建可控、可观测、可运维的大模型应用。我个人在实际项目里最大的感受是AgentScope把我在工程化上80%的重复劳动省掉了让我能把时间花在需要真正动脑子的地方比如Agent职责边界的设计、RAG效果调优、以及应对业务变化的流程重构。这大概是所有好的开发框架的共同特质在需要你创造力的地方给你留足空间在不需要你操心的细节上替你兜底。如果你正准备开始我的建议很简单找一台机器、装好Python环境或者Java环境从官方文档的快速入门教程开始先跑通一个多Agent协作的示例再用自己的业务需求去替换示例里的逻辑。等你亲手把一个实际场景跑起来、亲眼看到Agent之间传递消息时你就能理解我为什么说它牛逼了。另外也建议你把官方文档好好读一遍AgentScope的文档写得相当良心不少人所谓踩坑的经历其实在文档里早就写明了。好就说这些希望对正在做技术选型或已经入坑的你有帮助。有问题欢迎在评论区交流。
