这两年玩多智能体（Agent）的人越来越多，但很多人卡在同一个地方：单个 Agent 好写，多个 Agent 一协作就乱套。AgentScope 这个系统，我是在一个内部项目里接触到的，用下来最大的感受是它把多智能体开发的复杂度降了一个量级。如果你正在找一套能直接落地、支持分布式部署、方便接各种大模型的多智能体框架，这篇分享值得你花几分钟看完。它不是一个用来演示的玩具项目，而是从消息通信、流程编排到资源调度都有完整设计的生产级框架。我会拆解它为什么值得用，核心能力有哪些，2.0 版本在 RAG 上的变化，以及 Java 团队怎么低成本接入。

1. AgentScope 为什么值得关注：先搞懂多智能体开发难在哪

1.1 单 Agent 和多 Agent 的差别不在“数量”

很多人以为多智能体应用就是多定义几个 Agent，让它们各说各的。真正动手后才发现，难点在于三个魔鬼细节：信息怎么传、流程怎么控制、状态怎么同步。单 Agent 里这些都不用操心，一个循环加一个上下文窗口就够了。但多 Agent 是多个独立的推理单元在协作，A 的输出要成为 B 的输入，B 中间可能还要调用外部工具，然后结果再回流给 C。用普通代码写，就是到处穿插 if-else 和全局变量，最后代码比业务本身还复杂。

AgentScope 的解决思路很直接：把所有交互统一成消息，把智能体之间的协作抽象成几条固定流程，把运行过程交给底层的运行时去调度。开发者只需要关注每个 Agent 的职责和它处理的消息类型，剩下的通信细节、并发控制、进程生命周期，框架都接住了。我最早用另一个框架写了一个 6 智能体的项目，改了 3 版，每次都是死在消息串线和状态覆盖上。换到 AgentScope 之后，同样的场景只用了两天就稳定跑起来了，这不是工具偏见，而是它的抽象方式天然适合多智能体这种网状交互。

1.2 消息、智能体、流程、运行时：四大抽象各管一摊

AgentScope 的核心设计可以拆成四样东西：消息（Message）、智能体（Agent）、流程（Pipeline）和运行时（Runtime）。消息是智能体之间传递数据的最小单位，不只是字符串，还能带结构化字段、来源、去向、元数据；智能体封装了一个“接收消息、处理消息、产出新消息”的完整逻辑，你可以把大模型调用、工具函数、业务规则都塞在里面；流程定义了智能体之间以什么顺序、什么模式协作；运行时则负责把这一切跑起来，包括进程调度、通信传输和错误重试。

这四层分得很清楚，好处是排查问题的时候不用到处猜。消息内容不对，查 Message；智能体不回话，查 Agent 内部的模型配置和提示词；协作顺序不对，查 Pipeline；信息半天没到，查 Runtime 的通信配置。我自己调试时就靠这个思路快速定位了问题。对比市面上一些把全部逻辑塞在一个 Agent 基类里的框架，这种分层是一眼就能看出的优势。尤其当你需要把某个 Agent 单独拆出去部署到独立机器上时，AgentScope 里你只需要调整它的注册方式，业务代码完全不用动，这种灵活性在项目膨胀后才会真正感激。

2. 核心能力拆解：消息、智能体、流程与工具调用

2.1 Message 对象：协作的“快递单”

在 AgentScope 里，消息不是普通的字符串，而是一个有结构的对象。除了 content 之外，它还经常携带 name、id、to、metadata 这些字段。你可以把它想象成一张快递单：谁寄的、寄给谁、里面装了什么、有什么备注都写清楚。这样在分布式环境下，接收方拿到消息后不需要自己猜上下文，直接从字段里就能定位。我之前用普通函数传参的方式写过多智能体系统，每个函数都要处理一个又一个参数，消息一多就忘了哪些字段在哪个环节被改过。

实际使用中，我给消息加了一个自定义的 metadata，里面存了用户会话 ID 和当前轮次。多个智能体协作时，只需要在每个 Agent 里透传这个 metadata，下游拿到后就能把整个链路的日志串联起来。这个做法在排查“到底是哪一步产生了错误答案”时特别管用。官方文档里可能没有专门强调，但只要是上过生产的团队，我建议第一时间就把消息 ID 和业务流程 ID 打进 metadata。另一个容易被忽略的小细节是 Message 的 role 字段，别小看这个字段，它在多轮对话和流程追溯时是判断消息来源的关键依据。如果所有消息都混在一起不区分角色，后面做审计和可视化会非常痛苦。

2.2 Agent 抽象与提示词管理：别再把提示词写得又臭又长

Agent 在 AgentScope 里是一个可扩展的基类。你只需要继承它，实现一个 reply 方法，接收上游消息，返回新的消息。内部具体怎么处理，完全由开发者决定：可以是调一次大模型，也可以是先做检索再组装提示词，甚至可以直接做规则匹配。这个设计的灵活性让我在处理一些不需要大模型参与的环节时可以直接跳过模型调用，省下不少成本。比如一个格式校验 Agent，我可以让它用正则表达式去检查上一个 Agent 输出的 JSON 结构，完全不需要走模型。

提示词管理方面，框架允许在 Agent 初始化时传入 system prompt 和示例。和很多人想象的不同，多智能体项目里提示词不是越长越好，每个 Agent 只需知道自己该干什么、给上游要什么。如果你把全部角色说明塞给同一个 Agent，那和单 Agent 没有区别，反而因为上下文混乱导致输出不稳定。我踩过这个坑：一开始把一个 Agent 的 system prompt 写了两千多字，结果它频繁把别的主体的任务也干了。后来把职责收敛到五句话，效果立刻稳定。现在我的习惯是每个 Agent 的 system prompt 尽量控制在 100 到 300 字之间，只交代角色边界、输入输出格式和最重要的约束，其余细节通过示例或工具描述来补充。

2.3 流程编排：对话、顺序执行还是会合模式

AgentScope 提供了几种常用的流程模式。最简单的是一条链，比如 A 处理完交给 B，B 处理完交给 C。再复杂一点的是对话模式，两个或多个 Agent 在同一个话题下你来我往。还有一种会合模式，多个 Agent 的结果收集到一起，再由一个汇总 Agent 合并。不同模式对应不同业务场景。比如做一个活动策划系统，可以用链式流程让调研 Agent 先产出信息，再由策划 Agent 生成方案；做一个辩论系统，就需要对话模式来让多个 Agent 互相驳斥；做一个信息抽取系统，会合模式更适合，分头抽不同字段，最后统一合并成 JSON。

在编排流程时，我最看重的是“声明式描述”这件事。AgentScope 里你不需要手写消息路由的 if-else，只要把流程结构声明出来，运行时就会按照定义去调度。这让我能把注意力放在业务逻辑上，而不是维护一堆事件分发代码。还有一个使用技巧：复杂流程可以拆成多个子 Pipeline。我之前做了一个内容生产系统，整体是一个大 Pipeline，里面有调研、撰写、审核、润色四个阶段，每个阶段内部又各自有一个小的多 Agent 子流程。用这种嵌套结构组织代码，清晰度和可维护性都高很多。

2.4 工具调用与外部 API 集成：给 Agent 装上“手和脚”

在多智能体场景里，工具调用是常常被忽略的一环。Agent 发现问题之后，如果没法去查数据库、调接口、操作文件，那就只是个聊天机器人。AgentScope 支持让 Agent 在生成回复之前请求调用预设的工具，收到工具结果后再继续生成最终回复。你可以在工具函数里封装数据库查询、订单状态查询、天气查询等等。这个机制本质上给了 Agent 一个外部世界接口，让它的回答有事实支撑而不是全靠模型记忆。

实际项目中，我把公司内部的一个 SQL 查询接口封装成了工具函数，给数据 Agent 调用。关键点是工具函数必须要做超时控制和异常兜底。Agent 如果连续 3 次调用工具失败，应该让它把“暂时无法获取数据”如实写进回复，而不是硬编一个假结果。这个边界如果不提前设定，上线后一定会出现一本正经胡说八道的情况。另一个经验是工具描述一定要写清楚参数含义和返回结构。大模型会根据描述来决定怎么调用工具，如果描述含糊，它就可能传错参数或者不知道什么时候该用这个工具。把工具描述当作 SDK 文档来写，听起来夸张，但确实是最有效的方式。

3. AgentScope 2.0 的更新重点：RAG as a Service 到底香在哪

3.1 为什么 RAG 要打包成“服务”而不是继续做“库”

AgentScope 2.0 的一个大变化是把 RAG 能力从单纯的 Python 库升级成了独立服务。很多人不理解，为什么我本地装一个向量库再引几个依赖不就行了？答案是多智能体环境下，共享知识库是个很棘手的问题。每个 Agent 各建各的索引，会造成资源浪费、知识版本不一致，后续维护也是灾难。尤其当你的系统里有 5 个以上的 Agent 都需要查同一个企业知识库时，本地库方案会迅速变成一场混战，每个 Agent 都要重复录入、切分、向量化，还难以保证大家用同一份数据。

RAG as a Service 把知识库的上传、切分、向量化、检索统一收敛成一个独立服务，所有 Agent 都通过同一个接口去访问。这样知识内容只需要维护一份，更新一次，所有智能体立刻都能用到新知识。我对比过之前每个 Agent 各自去调用 Embedding 接口的方案，除了慢一倍，还经常因为不同 Agent 用了不同的切分策略，导致同一个问题检索出来的片段完全不一样。中心化的 RAG 服务能强制大家用同一套切分和向量化配置，这个价值在调试知识质量时尤其明显。

3.2 快速搭建一个知识库检索增强智能体

2.0 里，接入 RAG 服务的流程比想象中简单。第一步，启动 RAG 服务并上传文档，服务会自动切分成 chunk 并生成向量。第二步，在 Agent 的配置里挂上 RAG 服务的地址和知识库 ID。第三步，Agent 在处理消息前先检索相关知识，再拼进提示词上下文。我在一个问答机器人项目里试过接入流程，从上传文档到跑通一次带知识库的回答，只花了几十分钟。检索到的片段会被框架自动注入到 prompt 的 context 区域，不用我手动拼字符串。

这一点对新手特别友好，因为手动拼提示词经常会漏掉“只基于给定资料回答”的约束，导致模型开始自由发挥。框架内置的注入方式会在检索内容后面固定带上回答约束，实测可以把幻觉率明显压下来。我还发现服务化的 RAG 让知识更新变得特别干净。在旧方案里，每次更新文档我都会担心旧的向量残留，导致模型引用过期信息。换成 RAG 服务后，删除知识库重建索引是分钟级的事情，我可以放心地让业务人员直接维护文档，不需要理解底层向量化的概念。

3.3 多模型兼容与动态路由：同一个 Agent 换个模型就能跑

2.0 版本的另一个改进是模型层做了更干净的抽象。你的业务逻辑不需要关心背后的大模型是哪个，只需要在运行时配置里指定模型名称和对应的 API Key。如果你在成本敏感场景下想用便宜的模型，重度推理场景再换更强的模型，只需要切换配置项，不需要改 Agent 代码。这一点对我这种经常要对比不同模型效果的人来说非常省事，之前手动切换模型意味着改所有 Agent 内部的调用代码，现在只改一个配置文件。

我自己常用的是把简单意图识别交给较小的模型，把复杂方案生成交给更大的模型，两者并存不会冲突。AgentScope 的模型封装会统一处理请求重试、超时和 token 限制。这块的体验比我自己手搓 API 调用层顺畅得多，少写了不少重复的 try-except。如果你的项目有模型迁移需求，比如从开源私有化模型切到商业 API，几乎不用改业务逻辑，这也是 2.0 值得升级的理由之一。另外，多模型并存的时候建议把模型实例的名称作为 Agent 构造参数传进去，这样每个 Agent 用哪个模型一目了然，以后排错也方便。

4. Java 团队怎么接入 AgentScope：非 Python 环境的落地路径

4.1 核心是 Python，但不需要你的主应用用 Python

聊到 AgentScope 很多人会问：我们团队主力是 Java，这框架是不是用不了？其实没那么绝对。AgentScope 的核心运行环境是 Python，但不代表你的主业务系统必须变成 Python。你可以把 AgentScope 部署成一个独立的智能体服务平台，对外暴露 HTTP 接口，Java 服务通过 REST API 去调用。平台里的每个智能体或者每个 Pipeline 对应一个 endpoint，Java 侧发一个 POST 请求，消息体里带上用户输入和会话 ID，平台处理完返回结果。这个思路在微服务架构里很常见，把智能体当作一个独立的计算单元对待。

我在一个 Java 后台项目里就是这么接的，Java 端只需要封装一个 Feign Client，把平台地址配置好，业务代码里调用起来和调本地服务没有本质区别。维护上，Python 侧更像是核心服务，Java 侧是业务壳，两者各自迭代、各自发布。相比把 Java 和 Python 代码硬糅在一个进程里，这种服务化隔离反而更干净。如果你的公司对依赖安全要求严格，把 Python 服务放在独立容器里也能降低依赖冲突的风险。

4.2 用消息队列解耦：异步场景的正确姿势

如果是同步请求，走 REST 就够了。但很多业务是异步的，比如用户上传一个文件，后台要经过多个智能体分析，整个过程可能耗时几十秒。这时候 Java 端如果一直同步等，体验会很差。更好的做法是把任务提交到消息队列，AgentScope 侧消费后异步处理，处理完成再把结果回调到 Java 服务或者写入结果表。我在项目中用 Kafka 做了两个 topic，一个接收任务，一个返回结果。Java 端把业务参数封装成 JSON 发到任务 topic，Python 侧的消费者拿到后调用对应的 Pipeline，完成后把结果发回结果 topic。Java 端监听结果 topic，再推送给前端。

整个过程两端完全解耦，哪一端升级都不影响另一端，排查问题也很清晰。如果你所在的团队已经有用 RabbitMQ 或者 RocketMQ，原理一模一样。需要额外注意的是消息体里一定要带一个唯一的任务 ID，方便后续追踪。另外在消费端要做到幂等，避免同一个任务因为重试被处理两次。因为 AgentScope 的 Pipeline 调用通常不是轻量操作，重复执行不仅浪费资源，还可能产生错误结果。

4.3 一个 Java 接入的调用示例

假设你已经把 AgentScope 服务部署到内网，并且给某个 Pipeline 暴露了一个/invoke/pipeline的接口，Java 端的调用方式会非常直白。下面的伪代码展示了最基础的一种写法：用 RestTemplate 构造一个 JSON 请求体，里面带上 Pipeline 名称、用户输入和会话 ID，然后 POST 到对应接口，最后取返回结果。这段代码我在实际项目中简化过很多次，最终留下的就是这几行核心逻辑。

RestTemplate rest = new RestTemplate(); String url = "http://agent-scope-service:8080/invoke/pipeline"; Map<String, Object> body = new HashMap<>(); body.put("pipeline_name", "content_review_pipeline"); body.put("input", "这份文档需要做一次合规审核"); body.put("session_id", "order-20250901-001"); HttpHeaders headers = new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_JSON); HttpEntity<Map<String, Object>> request = new HttpEntity<>(body, headers); Map response = rest.postForObject(url, request, Map.class); System.out.println(response.get("result"));

这个示例里唯一要注意的是超时时间。AgentScope 的 Pipeline 内部可能有多轮模型调用，耗时会比普通接口长不少。Java 端的 HTTP Client 一定要把 read timeout 设置到 60 秒以上，否则很容易出现“服务端还在跑，客户端已经超时断开”的诡异现象。踩了这个坑之后，我的习惯是把智能体服务的接口超时单独调长，不要让全局超时配置影响它。如果你的场景允许，还可以在前端增加一个轮询接口，Java 端先返回一个任务 ID，再通过单独的查询接口拿结果，这样能从根本上绕开 HTTP 超时问题。

5. 从 0 到 1 跑通一个 AgentScope 项目：完整实操过程

5.1 环境准备与安装，先避开依赖的雷

安装 AgentScope 前，建议用一个干净的 Python 环境，我用的是 3.10。直接执行 pip 安装 AgentScope，2.0 版本还需要额外安装 RAG 服务的相关依赖。我的建议是不要一上来就安装所有推荐的依赖包，先装核心包，跑通最简单示例，再按需安装。我第一次安装时贪心，把文档里提到的扩展包都装上了，结果某个底层依赖版本冲突，花了一晚上才搞定。后来学乖了，官方文档里的安装命令其实分了好几类，核心包、分布式包、RAG 包。按需装，就是最好的避坑。

安装完成后，可以用agentscope --version验证一下版本。如果命令提示找不到，大概率是环境变量或者虚拟环境没激活的问题。在 Windows 和 Linux 上安装时，有些底层包需要编译依赖，提前装好 build-essential 或者对应平台工具链能省很多麻烦。我建议使用虚拟环境而不是直接装到系统 Python 里，这样不同项目之间的依赖不会互相污染，我自己就吃过全局环境的亏。

5.2 写一个“策划+执行”的双智能体示例

为了快速验证，我写了一个最简单的“策划+执行”场景。第一个 Agent 负责生成一份活动方案，第二个 Agent 负责挑毛病并给出修改建议，两者通过 Pipeline 串联。完整的核心代码并不长，下面这一段就足够跑起来。

import agentscope from agentscope.agent import AgentBase from agentscope.message import Msg agentscope.init(model_configs={ "config_name": "my_llm", "model_type": "openai_chat", "model_name": "gpt-4o-mini", "api_key": "YOUR_API_KEY", }) class PlannerAgent(AgentBase): def reply(self, x: Msg) -> Msg: prompt = "你是一名活动策划，请输出一份简洁的策划草案。输入：" + x.content response = self.model(prompt) return Msg(name="planner", content=response, role="assistant") class ReviewerAgent(AgentBase): def reply(self, x: Msg) -> Msg: prompt = "你是一名严格的评审，请指出以下方案的风险，并给出修改建议。方案：" + x.content response = self.model(prompt) return Msg(name="reviewer", content=response, role="assistant")

然后你可以把两个 Agent 放进同一个 Pipeline，依次执行。注意不同版本的 AgentScope 在返回结果类型上可能有一点差别，实际写的时候以你安装版本的 API 文档为准。整体结构就是这样：每个 Agent 只处理传入的 Msg，返回新的 Msg。

from agentscope.pipeline import Pipeline pipeline = Pipeline() pipeline.add(PlannerAgent(...)) pipeline.add(ReviewerAgent(...)) final = pipeline.run(Msg(name="user", content="办一场公司十周年庆，预算5万")) print(final.content)

跑通这个示例之后，你基本就掌握了 AgentScope 的核心用法。后面再往复杂方向扩展，比如并行分支、会合汇总，原理是一脉相承的。如果你在配置 API Key 时遇到模型连接失败，先检查网络白名单或环境变量里是否有代理设置，再看模型名称是否正确。很多时候模型名称写错是很隐蔽的错误，比如把带版本号和不带版本号的名称搞混。

5.3 分布式运行与可视化监控

如果只是本地跑两个 Agent，AgentScope 的分布式优势体现不出来。真正的价值在于把多个 Agent 部署到不同进程或机器上，由服务端统一调度。AgentScope 支持通过 actor 模式远程注册 Agent，每个 Agent 可以注册到独立的进程里，通过服务端协调通信。我在实测中把三个不同的 Agent 分别跑在三台机器上，用 AgentScope 自带的服务端把它们组织成一个 Pipeline。跑起来之后，打开监控页面能看到每条消息的流向和每个 Agent 的状态。

监控面板是我特别喜欢的一个功能，因为多智能体项目一旦跑起来，你特别需要知道消息当前卡在哪个 Agent、该 Agent 已经处理了多少轮。如果没有可视化，出了问题只能靠日志猜，效率很低。而且监控面板还能看到每条消息的耗时，这对发现性能瓶颈特别有帮助。之前我发现一个检索 Agent 平均耗时 3 秒，排查下来是它每次处理消息都重新加载了一遍知识库索引，后来改成启动时预加载一次，就把耗时降到了 300 毫秒以下。这种问题不看监控很难发现。

5.4 资源分配和性能调优的心得

分布式部署下，资源分配会直接影响整体吞吐。我的经验是：把大模型调用密集的 Agent 单独放一台 GPU 机器，纯逻辑或检索型 Agent 放 CPU 机器即可。通信方面，AgentScope 默认支持多种后端，本地进程之间和生产环境之间的配置不太一样。如果只是本地演示，用默认配置就好；如果跨机器，需要把通信地址写成对端可达的 IP，不要用 localhost。这一点我在第一次部署时就踩了坑，所有 Agent 都在同一台机器上跑没事，一拆开就互相找不到，最后检查发现配置里写的还是原来的回环地址。

性能调优方面，最容易忽略的是并发度。Pipeline 里如果有些 Agent 彼此没有依赖，你可以用并行模式让它们同时跑，而不是一个一个排队。我之前的项目里，四个相互独立的审核 Agent 串行执行时耗时接近 40 秒，改成并行后直接降到 15 秒以内。排优先级的时候，先梳理 Agent 之间的依赖关系，把无依赖的放并行分支，收益非常明显。另一个适合压测的工具是 locust，我拿它给整个 Agent 服务做过一次简单的并发压测，能比较直观地看出通信层的瓶颈在哪里。

6. 常见问题与排查技巧实录

6.1 模型调用超时与重试

最常遇到的问题就是模型调用超时。多智能体项目里，一次请求可能要触发多次模型调用，任何一个环节超时，整个 Pipeline 就会卡住。排查思路是先在单个 Agent 上单独测试模型响应是否正常，排除模型服务本身问题。接着检查 AgentScope 的重试配置，建议把 max_retries 设为 2-3 次，重试间退避时间 1 到 2 秒。如果业务对实时性要求高，可以把超时时间调短，超时后直接返回“需要人工介入”的结果，避免无限等待拖垮整个链路。

另外，如果你的模型 API 有并发限制，内部多个 Agent 同时调用时容易触发限流。这时需要给模型调用加信号量或令牌桶限流。我在一个 8 智能体项目里就遇到了这个问题，所有 Agent 同时向同一个模型端点发请求，导致 429 频繁出现。后来在 Agent 层做了简单的请求合并排队，情况立刻改善。这里有个小技巧：把限流逻辑放在 Agent 的基类里统一处理，而不是在每个 Agent 里独立实现，可以让代码整洁很多。

6.2 消息流阻塞与死锁

多智能体的死锁问题在分布式场景下真的会遇到。典型表现是消息一直不往下传递，监控面板上看到某个 Agent 的状态一直是 running。最常见的原因是 Agent 内部的 while 循环没有退出条件，或者 Pipeline 中两个 Agent 互相等待对方结果，形成了循环依赖。如果是简单的顺序流程，遇到这种问题通常会带一条明显的依赖环，但如果是复杂的嵌套流程，定位起来就没那么容易了。

我建议在编写每一个 Agent 时都内置最大轮次保护。不管业务多复杂，同一对 Agent 之间来回交互超过 5 轮就强制结束，把当前结果返回给用户。这个“安全阀”几乎能消灭 90% 的死锁问题。另一个排查技巧是打开 AgentScope 的调试日志，把消息流向打出来，用时间戳对照，很快就能定位到卡住的环节。如果日志量太大，可以按 Agent 名过滤，只保留当前可疑的 Agent 相关日志。

6.3 进程间通信参数配置

跨机器部署时，进程间通信是绕不开的配置项。我遇到过的坑是多个 Agent 在同一台机器上跑没问题，换到分布式环境后消息丢失或延迟陡然变大。排查后发现是默认的通信配置只适合本机回环，跨机器必须显式配置正确的通信地址和端口，还要确保防火墙放开对应的端口。另外，如果你用了容器化部署，端口映射和网络模式也要和这个通信配置保持一致。我曾经因为 Docker 的 bridge 网络导致容器之间无法直接访问，花了一个下午才排查出来。

配置完成后，建议先用一个最小双 Agent 场景做连通性测试，不要一上来就跑完整业务。如果消息传递正常，再逐步增加 Agent 数量和消息并发量。从简单到复杂去验证，能帮你把网络问题隔离出来，不至于混在业务逻辑里难排查。这个习惯帮我省了非常多的时间。还有一个小建议：把 Agent 的注册信息维护在一个统一的配置文件中，而不是散落在代码里。分布式环境下，节点一变多，配置维护就是一个隐藏的复杂度来源，集中管理能减少误配。

6.4 提示词输出格式不可控

多智能体场景里，A Agent 输出的内容要作为 B Agent 的输入。如果 A 输出的格式不稳定，B 很容易解析失败。我一开始让 A 直接输出 JSON，但大模型偶尔会在 JSON 外包一层解释文字，B 拿去解析直接报错。后来处理方法是在 A 的提示词里强制要求只输出 JSON，并且在 B 内部做好容错，如果解析失败就提取代码块内容再解析一次。更稳妥的方案是使用嵌套消息结构，把 A 的输出分成内容、结构化字段等几部分，下游需要什么字段直接从消息体里取，不依赖大模型每次都能完美输出纯文本。

AgentScope 的消息本身就是结构化的，善用这个能力，你的多智能体系统会健壮很多。我还习惯在每个 Agent 的回复消息里额外存一个 status 字段，表示这次处理是成功、部分成功还是失败。下游 Agent 收到消息后先判断 status，再决定继续处理还是走降级逻辑。这个设计让我避免了大量因为上游输出异常而导致的连锁错误。最后提醒一句：多智能体系统里不要信任任何一个 Agent 的输出格式，所有边界都做好校验和默认值，才能保证整体链路稳定。

最后说一点个人体会。AgentScope 不是那种一上来就让你写一堆配置的框架，它的核心抽象非常有限，但每个抽象都踩在了多智能体开发的痛点上。我实际用下来，最大的收获不是省了多少代码，而是它逼着我用消息、流程、运行时这套思维去重新审视自己的应用，很多之前纠缠不清的逻辑一下子就理顺了。后面如果你的场景需要知识库增强或 Java 服务接入，2.0 的 RAG 服务和 HTTP 暴露模式都能给你留出明确的扩展路径。建议你从一个最小的双智能体场景开始，先把这套消息和流程的感觉找回来，再逐步叠加复杂度。