企业官网建设流程全解析

如果你试着让两个 Agent 协作干活，大概率经历过这样的场面：A 生成了一段文字结果，直接丢给 B，B 却想拿到结构化 JSON；B 反问一句“请提供更详细的上下文”，A 又把它当成新指令开始新一轮输出；你夹在中间，既要调提示词，又要做格式清洗，还得自己维护一堆临时存消息的队列。忙活一整天，两个智能体终于能对话了，但代码已经耦合到连你自己都不想碰。这正是“多智能体开发”最真实的困境——单个 Agent 很好写，多个 Agent 协作起来却能让人血压飙升。

AgentScope 这类原生适配大模型的多智能体开发工具，解决的就是这一层问题。它的核心不是替你写 Agent 里的提示词，而是把 Agent 之间怎么说话、消息长什么样、任务如何编排、状态怎么记录这些脏活标准化。24.4 这个版本值得关注的点，不在于又多了几个模型接口，而在于暴露了一套更完整的“多智能体交互协议”设计思路。这篇文章不按官方文档念经，我只从实际搭建多智能体应用的角度，拆一拆 AgentScope 的架构设计、标准消息机制和工程化落地的关键细节。

1. 多智能体开发为什么难？AgentScope 的设计缘起

1.1 单体 Agent 到多 Agent：复杂度不是线性增长，是爆炸式增长

单个 Agent 的工程化其实已经很成熟了。给它一个大模型接口、一段系统提示词、一个外部工具集，再做好日志记录，你就能得到一个自动化助手。但一旦引入“多个”智能体，问题就完全变了性质。比如你设计一个客服系统，让导购 Agent 负责推荐商品，让售后 Agent 处理退换，让质检 Agent 监督对话合规性。表面上这是三个独立模块，实际上它们需要共享一份订单上下文、需要互相传递用户意图、需要知道“上一轮到底是谁在说话”，还得防止几个 Agent 同时调用写操作把订单状态改乱。

我自己最早做这类系统时，用的是“消息队列 + 回调函数”的土办法。每个 Agent 跑一个进程，消息通过队列投递，回调里做协议转换。结果就是：业务逻辑还没写完，光是把消息格式对齐就花了三周。每个 Agent 都认为自己该拿到一段“自然语言”，但不同 Agent 期望的格式、字段、语气完全不同。这种混乱不是代码能解决的，是缺少一套公共契约。

1.2 AgentScope 的解题思路：与其教每个 Agent 说话，不如统一一种消息语言

AgentScope 的核心主张很直接：多智能体系统的复杂度来源主要是三块——消息结构、任务编排、生命周期管理。它把这三块抽出来作为框架的核心抽象，而不是把“调用大模型”当作卖点。

在消息结构上，AgentScope 定义了一套统一的消息格式，每个 Agent 的输入和输出都围绕这套格式展开。消息里既有 content 这样的核心内容字段，也保留了 role、metadata 这类辅助信息。这么做的好处是，你可以把消息体当作标准业务对象去流转、记录、过滤，而不是面对一团乱麻的字符串。任务编排则负责把多个 Agent 串成图或管道，控制谁先执行、谁后执行、什么条件下分支。生命周期管理处理 Agent 的创建、通信、状态持久化和退出条件。

这套设计用一句话概括就是：它假设你会把大模型当“工具人”，而不是把大模型代码写进消息里。你的业务逻辑关注消息如何流动，Agent 本身只是流动过程中的处理节点。这让整个系统天然具备可调试、可回放、可扩展的工程基础。

1.3 “24.4” 版本带来的核心变化：协议优先、执行器升级

很多框架的版本号只是告诉你“我们修了 Bug，加了模型”。但 24.4 这个版本在 AgentScope 的迭代里，重点在把智能体交互这件事往“协议化”和“工程化”方向上进一步压实。表现到使用者面前，是配置体系更清晰、消息路由能力更稳定、模型接口适配更规范。

我在升级之后最明显的感受是：旧版本里，消息传递中经常出现因为模型返回格式差异导致的中断，新版本对模型输出的约束和解析处理明显更稳。另一个值得提的变化是任务执行链路更透明了，你可以在框架层面看到一条消息从 A Agent 发出，经过哪些过滤逻辑，最终被哪个 Agent 消费。这对排查“消息怎么突然就没了”这类问题特别有帮助。

如果你之前只把 AgentScope 当成一个“调大模型的封装库”，24.4 会让你重新认识它——它是一个真正面向多智能体生产环境的编排框架。

2. 核心概念拆解：Agent、Msg 与 Pipeline 是如何咬合的

2.1 Agent 不是 Chatbot，是“可编排的处理单元”

在 AgentScope 里，Agent 的定义比大多数人想象的要抽象。它不天然等于某个大模型实例，而是一个“能够接收消息、处理消息、返回消息”的执行单元。这个执行单元内部可以是大模型驱动的 ReAct 循环，也可以是一段本地规则代码，甚至可以是外部服务的 HTTP 调用。关键在于，对 Framework 来说，一切 Agent 都是黑盒处理节点，输入格式统一，输出格式统一。

把一个 Agent 想成一个自动售货机：你往里投一枚标准硬币（Msg），它给你掉出一瓶饮料（新 Msg）。至于这枚硬币是人民币还是游戏币，以及售货机内部是机械结构还是智能识别，都是内部实现细节。这种抽象的价值在工程上特别明显——你可以先用一个简单的 echo Agent 做系统联调，跑通后再换成真正的大模型 Agent，外层 Pipeline 和消息协议完全不用改。

最常见的 Agent 形态还是 ReAct 模式。AgentScope 内置的 ReActAgent 会按照“思考→行动→观察”的循环来处理任务，遇到需要工具调用的情况，会先输出一个工具调用请求，拿到结果后再继续推理。这其实就是把大模型的“思维链”和外部工具的“执行结果”组合成多步路由，最终返回一个自然语言的 answer 节点。24.4 对这类 Agent 的改进主要在工具调用的稳定性，对返回格式的解析不再只依赖正则硬匹配，而是结合模型输出规范做了多层校验。

2.2 Msg：多智能体之间的“通用货币”

如果说 Agent 是处理节点，那 Msg 就是节点间传递的唯一货币。AgentScope 的 Msg 不是简单包一层字符串，它的结构里同时包含了内容、角色、标识符和元信息。

你可以把 Msg 理解成快递面单。content 是包裹里的实物，role 是寄件方类型（用户、系统、助手），metadata 是面单上的备注信息（比如订单号、会话ID、时间戳）。如果你的 Agent 之间只传字符串，就像交接收快递时只看包裹外表，不拆开不知道里面是什么。而有了 Msg 结构，你可以在路由层直接根据 metadata 做消息分类、过滤、归档，根本不需要把内容解析出来。

这套消息设计在“多智能体会话历史”里尤其有用。每个 Agent 对话时，其实是在维护自己的小上下文窗口。framework 会从 Msg 流里抽取与当前 Agent 相关的历史消息，组装成这个 Agent 的对话上下文。这避免了所有 Agent 共享一份庞大 token 上下文导致的成本爆炸，也让每个 Agent 只关注自己职责范围内的信息。

2.3 Pipeline 与 DAG：编排不是聊天记录，是控制流

很多人第一次用 AgentScope 时会困惑：多智能体系统不就是让 A 和 B 互相对话吗？我给你一句，你给我一句，最后看结果。但真实业务里，多智能体协作远不是两条对话流水线，它是一个有分支、有汇聚、有条件的控制流。

AgentScope 里的 Pipeline 就是用来定义这种控制流的机制。它支持顺序执行、并行执行和条件分支。你可以把提示词生成 Agent、代码编写 Agent、代码评审 Agent 组织成一个流水线：先由生成 Agent 产出代码，再交给评审 Agent 判断质量，如果评分不达标就回到生成 Agent 重新修改，达到标准才进入下一步。这种“带圈的图”在纯对话模型里画不出来，但用 Pipeline 表达起来非常自然。

24.4 对 Pipeline 的增强我印象最深的是对“结构化状态”的支持。以前做分支切换经常需要外接一个 Coordinator Agent 来读结果、做判断，相当于让大模型去当 if-else。现在框架层面支持更多任务间的数据依赖关系，可以通过消息元数据直接声明“这个结果属于哪个分支”，分支节点会自动决策如何流转。这让编排逻辑从“让大模型猜”变成了“让框架按规则执行”。

2.4 为什么“标准化交互”是多智能体系统的生死线

我需要强调一点：标准化交互不是工程洁癖，是多智能体系统能否规模化扩展的前提。假设你有十个 Agent，如果没有统一消息协议，每两个 Agent 之间都要定制对接方式，对接关系就膨胀到了 45 种。每添加一个新 Agent，都要和现有所有 Agent 做兼容，系统复杂度直接把你拖垮。

而有了统一消息协议，新 Agent 只需要完成两件事：告诉框架“我能处理哪种 Msg”，以及“我输出的 Msg 长什么样”。对接成本从“点对点协商”降为“注册与发现”。这本质上和多智能体通信协议的价值是一致的——它不关心你内部用什么模型、什么工具，只关心你能理解和产出什么类型的标准消息。AgentScope 选择的这条路线，它的野心不止是简化开发，更是建立一套可以让智能体在生产环境长期演进的交互规范。

3. 实操入门：用 AgentScope 快速搭一个“策划+评审”双 Agent 协作流

3.1 环境准备与依赖安装

AgentScope 是一个 Python 框架，要求 Python 环境在 3.8 以上，安装过程很常规。直接使用包管理器安装即可：

pip install agentscope

安装完成后建议立刻验证一下导入是否正常：

import agentscope print(agentscope.__version__)

如果电脑里有多个 Python 环境，建议用虚拟环境隔离，避免依赖冲突。这个框架对系统的要求不高，CPU 环境也能跑通基础流程，因为真正的计算压力都在大模型 API 一侧。

3.2 大模型接入与配置管理

AgentScope 不绑定任何特定厂商，它提供的是“模型配置注册机制”。在 24.4 版本里，配置方式明显更工程化，我习惯用一个独立的 YAML 文件管理所有模型接入信息：

model_configs: - model_name: "planner_llm" model_type: "xxx_chat" # 以官方实际接入的模型类型为准 api_key: "YOUR_API_KEY" generate_args: temperature: 0.7 max_tokens: 2048 - model_name: "reviewer_llm" model_type: "xxx_chat" api_key: "YOUR_API_KEY" generate_args: temperature: 0.2 max_tokens: 1024

配置文件里给不同的 Agent 分配不同的模型参数，这在成本控制和角色区分上非常有用。比如策划 Agent 需要创造力，温度可以调高；评审 Agent 需要严谨，温度可以调低。如果你的模型服务支持多密钥负载均衡，也可以配置多个密钥轮换，但要注意把敏感配置从仓库里摘出去，用环境变量或密钥管理服务注入。

初始化方式很直接：

import agentscope agentscope.init(model_configs="./configs/model_configs.yaml")

3.3 最小可运行示例：让两个 Agent 协作生产一段文案

我们做一个简单但完整的案例：一个“文案策划 Agent”负责生成营销文案，一个“合规评审 Agent”负责检查文案是否包含敏感承诺词并给出修改意见。两个 Agent 共享一个工作流，先策划、后评审。

这里我给出一个基于 AgentScope 设计思路的示意骨架代码，具体类名以你安装版本的实际 API 为准，但整体流程是相通的：

from agentscope.agent import ReActAgent from agentscope.message import Msg # 初始化框架，加载模型配置 agentscope.init(model_configs="./configs/model_configs.yaml") # 定义策划 Agent planner = ReActAgent( name="planner", model_config_name="planner_llm", system_prompt=( "你是一位资深营销文案策划。" "根据用户的需求，输出完整文案。" "只输出最终文案，不要输出思考过程。" ), ) # 定义评审 Agent reviewer = ReActAgent( name="reviewer", model_config_name="reviewer_llm", system_prompt=( "你是一位广告合规评审专家。" "检查文案中是否有夸张、承诺效果、极限词等风险。" "返回 PASS 或 REVISE，并给出具体修改建议。" ), ) # 构造用户请求 request = Msg( name="user", content="为一款智能台灯写一段电商详情页文案，强调护眼和智能调光", role="user", ) # 第一阶段：策划 plan_msg = planner(request) print("策划输出：", plan_msg.content) # 第二阶段：评审 review_msg = reviewer(plan_msg) print("评审输出：", review_msg.content)

这段代码虽然简单，但它已经体现了 AgentScope 的全链路设计：通过框架初始化加载模型配置，Agent 根据配置建立大模型连接，消息以 Msg 对象在回合间流转，调用结果可以通过 content 字段取用。

3.4 让 Agent “会思考”：提示词与上下文组织技巧

AgentScope 不会帮你写提示词，但它对“上下文如何组织”给出了明确约束。ReActAgent 的 system_prompt 被放在对话最前端，用户消息和中间观察结果按照时间顺序排列。这意味着你的系统提示词必须足够清晰，告诉 Agent “什么是它的职责、什么情况下调用工具、最终以什么格式输出”。

实操中我有几个经验可以分享：

第一，Agent 的职责边界要在 system_prompt 里说透，不留给模型猜。比如评审 Agent 的提示词里，我会明确写清楚“只检查文案风险，不修改文案风格”“必须返回 PASS 或 REVISE 开头”，这样后续解析结果的代码才好写。

第二，如果多个 Agent 共享上下文，要谨慎使用全局历史。AgentScope 的消息路由机制允许你决定哪些历史消息对哪些 Agent 可见。两个 Agent 协作时，最常见的问题就是 B Agent 看到了 A 的内部思考过程，然后被带偏了。正确的做法是只把 A 的最终输出作为 B 的输入，而不是把 A 的完整 ReAct 记录全部丢给 B。

第三，别忘了在消息里带任务标识。当你的系统里同时存在多个协作任务时，metadata 里的 task_id 是消息路由的重要依据。没有任务标识，所有消息混在一起，Pipeline 根本没办法判断哪个消息属于哪个分支。这个细节看起来不起眼，但在并发场景里能救你命。

4. 标准化智能体交互：消息协议如何支撑复杂业务

4.1 消息路由与会话状态维护

多智能体系统跑起来之后，“消息该传给谁”就变成了核心问题。AgentScope 的做法不是像广播一样把消息发给所有 Agent，而是通过会话机制和 Pipeline 结构限定消息流动路径。在每个会话里，消息会按照拓扑关系流向指定的下游节点。

这个设计暗合事件驱动架构的思路。每个 Agent 既是消息消费者又是消息生产者，它消费上游传入的 Msg，处理后产出新的 Msg 传给下游。会话 ID 在整个流转过程中保持不变，方便你在外部建立“任务全局视图”。如果你需要做审计，比如追溯某条结论是怎么一步步得到的，只要按会话 ID 拉取所有消息记录即可。

24.4 版本里，路由规则定义得比早期版本灵活。你可以在 Agent 上声明自己感兴趣的 Msg 类型（比如“只处理 reviewer 结果”），框架在路由时会自动匹配，不再需要硬编码 if-else 判断消息来源。这解决了多 Agent 协作中“消息风暴”问题，每个 Agent 只关心与自己相关的消息，避免无关上下文污染推理。

4.2 工具调用与本地能力接入

多智能体系统不能只停留在“对话”，它必须能做事。AgentScope 对工具调用的支持，本质上是把外部函数变成 Agent 可感知的“能力单元”。在 ReAct 循环里，Agent 可以发起工具调用，框架负责实际执行工具，并把执行结果作为观察消息回传给 Agent。

定义一个工具并不复杂，核心就是注册函数并描述它的功能：

def query_stock_price(stock_code: str) -> str: """查询股票最新价格。""" # 这里调用你的行情数据源 return f"{stock_code}: 42.5 元" tool = Tool( name="query_stock_price", description="查询股票实时价格，输入股票代码，返回价格字符串", func=query_stock_price, )

然后把这个工具绑定到指定 Agent 上。框架会把工具的名称、参数说明、返回值格式统一编码到 Agent 的上下文里，大模型在需要时会“试图”调用工具。你收到工具调用请求后，框架自动执行并返回结果。整个过程对 Agent 来说透明，它只看到“查询动作”返回了结果，然后继续基于结果进行推理。

在设计工具时，有个经验很重要：工具 name 和 description 要写得像给另一个开发者的接口文档。大模型判断“什么时候该用哪个工具”，完全依赖这两个字段的描述质量。描述含糊，模型就会乱调用。描述不清楚参数含义，模型就会传错参数。

4.3 智能体交互中的“协议约定”：格式、回执与容错

标准化交互的另一半是“容错协议”。你没法假设模型输出永远符合预期，所以框架要在更底层做强校验。

在 AgentScope 里，我通常在两个层面做容错。第一层是模型输出结构校验：4.1 中提到的工具调用，框架会检查模型返回的 JSON 是否能解析、是否包含指定字段，如果解析失败可以触发重试。第二层是业务语义校验：这需要你自己在 Agent 逻辑里写规则，比如评审结果必须包含 PASS 或 REVISE 关键字，否则视为非法输出。

另一个容易忽略的协议约定是“回执”。在较长的 Pipeline 中，如果某个 Agent 处理超时或失败，系统需要一套状态反馈机制。我自己的做法是让每个 Agent 在返回结果时，通过 Msg 的 metadata 带上状态字段（success/failed/retry）。下游 Agent 看到 failed 状态时，可以选择走异常分支，而不是傻等。

注意：不要把 Agent 的异常处理全部押在提示词上。提示词可以让模型“大概率”遵循约定，但不能保证“必然”遵循。关键路径上必须用代码做硬校验，提示词只是提高通过的效率。

5. 调试、检查与性能优化：多智能体系统的工程化难点

5.1 日志记录与消息回放：让问题可追溯

我见过很多团队做多智能体 Demo 时跑得很欢，一上生产就头疼。最主要的原因就是：LLM 有随机性，同样的输入，今天跑通，明天可能跑歪。没有好的日志回放机制，排查问题就像大海捞针。

AgentScope 在这一块的价值很大。它的框架层级会记录消息流转的时间线：谁在什么时候发出了什么消息，哪个 Agent 消费了它，输出是什么。这些记录可以存储在本地数据库或日志文件里，回放时就能还原整个任务链路。

实操上，我建议给每一条消息都打上全局唯一的消息 ID，并记录上下消息的关联关系。这样当场定位问题只需要顺着消息链往下看，很快能找到“是哪条消息让评审 Agent 产生了错误判断”。24.4 版本对消息记录的持续性做了一些底层优化，长时间运行的任务重启后也能从最后断点续跑，这对生产环境的稳定性提升是实打实的。

5.2 Token 消耗与上下文长度管理：成本就是系统设计的一部分

多智能体系统最大的隐形开销是 Token。每个 Agent 都有一份自己的历史上下文，如果任务链路长、Agent 数量多，Token 量会以乘法级别增长。我在设计多智能体系统时，会像设计数据库索引一样设计上下文可见范围。

AgentScope 的消息隔离能力在这里派上用场。它允许每个 Agent 只看到与自己相关的那条消息链，而不是全量广播。比如最终决策 Agent 只需要看到各子任务的汇总结果，不需要看到子任务内部的完整思考链。把这类“过程消息”和“结论消息”分开，Token 开销能下降一个数量级。

另一个实用技巧是窗口压缩。当一个 Agent 的会话历史过长时，可以周期性把早期对话摘要成一段 summary 消息，替代原始长文本。虽然 AgentScope 提供了消息管理接口，但摘要策略得根据业务自己设计。我的经验是：摘要不能只压缩细节，要保留结论和待办事项。压缩后的上下文如果丢了关键结论，Agent 就会“失忆”。

5.3 并发执行与任务隔离：异步、串行怎么选

多智能体系统天然适合做任务并行，但并行也引入了资源竞争问题。AgentScope 支持 Pipeline 的并发分支，多个不相关的 Agent 可以同时运行。这在改写多个任务时非常有用，比如同时让三个 Agent 分别生成不同章节的内容，最后统一汇总。

但并发并不是越多越好。如果多个 Agent 共享同一个外部工具或数据库，要考虑写锁和资源限制。另一个经验是保险丝机制：给每个 Agent 的执行加超时控制，避免某个模型调用卡死，导致整个 Pipeline 一直挂着。模型 API 偶尔会有长尾延迟，没有超时兜底，整个系统会像一锅煮糊的粥。

性能优化的核心指标有三个：端到端时延、成功的任务比例、单任务平均 Token 成本。调优的时候，建议先用量化数据定位瓶颈，再动手改。很多时候瓶颈不是模型推理速度，而是消息在 Agent 间传递的序列化开销，或者外部工具调用的等待时间。

6. 常见问题与踩坑实录：那些文档不会告诉你的细节

6.1 模型返回结构不稳定的处理：重试与约束并行

多智能体系统里，模型返回不稳定是最常见的坑。你说让 Agent “返回 JSON”，它时而返回合法 JSON，时而夹带说明文字，有时干脆在 JSON 前加一段 Markdown 代码块标记。直接把字符串丢给 json.loads 只会得到一堆异常。

我的处理套路是三层：先做清洗，剥离代码块标记和多余说明；再做规范化，尝试解析；解析失败则触发一次带“严格格式要求”的重试。如果重试仍失败，这条消息就标记为 failed，走异常分支。关键路径上还可以给 Agent 的提示词里加入 few-shot 示例，这比单纯说“不要输出别的”要有效得多。

6.2 多智能体死循环与任务终止条件设计

当 A Agent 的输出总是让 B Agent 不满意，B 给出的修改意见又被 A 当作新一轮指令时，系统就进入了死循环。我见过最离谱的一次，两个 Agent 来回改了 30 多轮，消耗的 Token 让账单直接爆表。

必须在 Pipeline 层设置硬性终止条件，而不是指望 Agent 自己判断“该收手了”。具体做法有几种：一是限制最大迭代轮次，到点强制返回当前最优结果；二是设置接受阈值，比如评审分数达到 90 分就跳出循环；三是对消息内容做去重检测，如果 A 的输出连续两轮完全相同，就判定已经收敛，强制结束。这套逻辑应该写在编排层，不能留给大模型自觉。

6.3 上下文串扰与幻觉放大

多智能体系统的“幻觉”比单 Agent 更危险，因为错误信息会在 Agent 间反复传播、放大。比如情报收集 Agent 在信息不足时做了推测，这个不准确的推测被分析 Agent 当作既定事实，最终生成的报告就完全偏离实际。

控制手段是“观点与事实分离”。在最上游的数据收集 Agent 里，强制输出明确标注每条信息的置信度；下游 Agent 在系统提示词里被要求忽略低置信度信息。或者更简单：第 1 个 Agent 直接输出候选事实列表，不输出推理结论；第 2 个 Agent 再基于候选事实做判断。把“事实收集”和“推理决策”放进不同的 Agent，能显著降低幻觉传导。

6.4 升级到 24.4 版本后的兼容性问题

从旧版本升到 24.4，最需要关注的不是新功能，而是配置格式和消息对象结构的变化。前几年写的老代码里，有不少模块是直接操作消息对象的内部字段，升级后这些私有字段被调整或改名，代码就炸了。

我的建议是先小范围验证，不要直接全量升级。把新版本部署到测试环境，跑一遍你的核心 Pipeline，重点看消息对象在传递、序列化、日志输出三个环节是否兼容。如果业务代码里大量硬编码了旧消息字段名，建议在封装层做一次适配，不要在业务逻辑里裸操 Msg 内部结构。另外，升级后记得重新生成或迁移消息存储表结构，旧版本存的记录可能读不出来。

6.5 常见问题速查表

6.6 一个容易被忽略的坑：模型并发配额被打满

多智能体系统跑起来后，Agent 数量上去了，并发调用也上去了，模型服务的配额很容被打满。表现为系统频繁报“超限”“限流”或直接超时。这个问题在 Demo 阶段几乎不会暴露，因为量太小。但在准生产环境压测时一定会遇到。

应对方式首先是限流与退避：框架或代理层做并发限制，超过阈值就排队等待；其次是降级策略：核心 Agent 用高质量模型，非核心 Agent 可以用更轻量的模型甚至本地规则兜底。第三步才是扩配额和换服务商。很多人一上来就想着加钱扩配额，其实先做限流与任务降级，能把成本压下来不少。

7. 落地案例与效果评估：多智能体系统不是“跑通就算赢”

7.1 一个典型场景：自动化报告生成管线

以某内容团队的需求为例，他们需要每天生成一批行业分析简报。过去靠人工写，费时费力。使用 AgentScope 后，他们设计了五个 Agent 协同的 Pipeline：信息采集 Agent、数据清洗 Agent、核心观点提炼 Agent、文案撰写 Agent、合规复核 Agent。

信息采集 Agent 负责从数据源拉取当天新闻和指标，数据清洗 Agent 过滤低质和重复内容，观点提炼 Agent 总结三条核心洞察，文案撰写 Agent 组织成简报，最后合规复核 Agent 检查是否有敏感表述和事实性错误。这个流程里，Agent 之间只传递标准化 Msg，每个阶段产出的中间结果都可以被单独审计。整个管线跑一次大约消耗 8-10 万 Token，时间不到五分钟，而人工写作至少需要一小时。

这个案例给我的启发是：多智能体系统的价值不在“看起来智能”，而在“可重组、可审计、可替换”。如果团队想换掉观点提炼 Agent，不需要重写其他模块，只需要新 Agent 遵循相同的 Msg 协议即可。

7.2 像评估工程系统一样评估多智能体系统

很多人评估多智能体系统只看“最后一轮输出好不好”，这其实不够。多智能体系统的质量要拆成四层看：

第一层是单 Agent 准确率，单独测试每个 Agent 的任务完成质量；第二层是消息流转成功率，统计整个 Pipeline 里有多少消息在传递中丢失、变形、解析失败；第三层是端到端结果质量，可以请人工或自动化评测打分；第四层是资源消耗，记录每成功跑完一个任务的 Token 成本。

没有这套评估体系，你就会陷入“今天跑通就觉得行了，明天跑偏就觉得模型不行”的误区。事实上，很多问题不是模型的问题，是消息协议不严谨、编排逻辑有漏洞或上下文管理出了偏差。框架解决的是这些确定性问题，模型解决的是生成问题，两者必须分开施治。

7.3 在多智能体架构里保留人工回归的通道

虽然目标是无人工干预，但生产环境一定要保留人工回归的兜底。以报告生成管线为例，我会在合规复核 Agent 后面加一个“人工抽查”环节，每天抽 10% 的报告做人工质量检查。这个机制不需要重新搭系统，只需要把 Agent 输出的 Msg 汇总到一张人工审核列表里，审核通过后回写一个 status 字段。

这套“人在回路”的设计，本质上也是消息协议的一部分。人工审核的结论和 Agent 的结论用同一种消息格式表达，系统可以兼容并继续流转。多智能体系统越自动化，越需要这样一条安全绳——不是不信任技术，而是生产环境必须容忍技术偶尔掉链子。

7.4 再往后走：Agent 协作的组织形态会越来越像“专业分工”

AgentScope 这类框架长期演进下去，多智能体系统的开发会越来越像组织设计。你不再关注每个 Agent 用哪个模型、为什么这个 Agent 没回答对，而是关注消息协议清不清晰、任务边界明不明确、路由规则合不合理。就像公司管理一样，部门之间的接口协议越规范，组织协作效率越高。

回到 24.4 这个版本带来的变化，我认为最值得吸收的不是某个具体函数，而是“标准化交互”的思路。在多智能体系统里，让各个 Agent 说同一种语言、遵循同一种协议、在同一个编排框架下协同工作，这件事的长期价值，比任何一个模型能力的提升都重要得多。以后你写 Agent 应用，别先急着调模型，先把消息协议设计好——这能让你省掉无数个崩溃的深夜。