顺丰科技多智能体系统可观测性研究与实践
多智能体系统（Multi-Agent System）正从实验室走向工程化落地，但一个关键瓶颈也随之浮现——可观测性。系统内部究竟发生了什么？每个智能体调用了哪些工具？路由决策是否符合预期？如果这些问题得不到清晰答案，系统就只是一个黑盒。顺丰科技在这方面进行了探索性实践，基于OpenAI开源的Swar
多智能体系统（Multi-Agent System）正从实验室走向工程化落地，但一个关键瓶颈也随之浮现——可观测性。系统内部究竟发生了什么？每个智能体调用了哪些工具？路由决策是否符合预期？如果这些问题得不到清晰答案，系统就只是一个黑盒。顺丰科技在这方面进行了探索性实践，基于OpenAI开源的Swarm项目进行了定制化改造，致力于让多智能体系统实现“看得见、可回溯、能控制”。需要提前说明：本文并非介绍如何用Swarm搭建一个演示Demo，而是聚焦于如何提升多智能体系统的可观测性，分享实际踩坑后的思考与具体改造方案。核心讨论将围绕三个问题展开：多智能体系统的本质是什么、其可观测性面临哪些挑战、以及我们如何基于Swarm来动手解决。
先简要梳理一下讨论脉络。第一部分，明确定义多智能体系统及其适用场景。第二部分，重点剖析这类系统在可观测性方面面临的结构性难题。第三部分，详细介绍我们基于Swarm实施的可视化方案改进——从源码改造到数据持久化，再到展示层设计。最后是Q&A环节，回答一些大家普遍关心的问题。
多智能体系统介绍
1. 多智能体系统是什么
多智能体系统，顾名思义，是由多个智能体在同一个环境中协作解决问题。维基百科的定义较为宽泛，但本文讨论的智能体特指基于大语言模型（LLM）的系统组件。参考国外大学的一篇综述论文，多智能体系统的核心特征在于：由基于LLM的单个智能体组成，通过智能体间的通信、记忆共享或能力扩展，去处理单个智能体无法胜任的任务。
在顺丰内部，这类场景已有不少实际落地案例。举一个典型例子：根因分析（RCA）。现代云原生架构的复杂性——网络、中间件、底层组件、微服务层层叠加——导致告警或故障的根因难以快速定位。单一智能体很难在如此复杂的环境中收集足够信息并一次性给出答案。因此，多智能体系统成为必然选择。方案中，每个智能体负责一个具体方向：有的专门做数据探索，有的负责依赖关系检查，有的分析错误，有的做任务调度，还有一个判断分析是否完成。目标明确、工具独立，组合起来就能高效完成复杂的RCA任务。
同样的情况也出现在软件工程领域。产品开发、代码测试、版本发布管理——这些环节天然需要多角色协作。随着开源多智能体系统日益增多，为每个智能体分配一个角色、让它们协同达成目标，已变得可行。此外，业界还在探索多智能体系统在世界模拟和游戏场景中的应用：定义不同角色的智能体，让它们自主交流、逐步探索环境，从而模拟出真实世界的细节。这些场景都有一个共同特点——单个智能体搞不定，多智能体才是解法。
目前业界主流的开源多智能体系统中，几个有代表性的值得一说。
MetaGPT，来自中国开源社区。它定义了多种员工角色，比如人力资源、行政，目标是让智能体替人类完成尽可能多的任务。它还支持“人机交互”——定义了human agent的角色，让人类可以参与进来。这个框架比较成熟，但由于它能自动处理整个公司的协作任务，对可观测性和可信度的要求也更高。
CAMEL，国外的一个智能体生态项目，主要探索智能体的定义、记忆机制和交互模式，下面有多个子项目，设计原则的研究比较深入。
AutoGen，微软开源编程框架。与MetaGPT不同，它更侧重编程接口，让用户自己定义智能体之间的关系——平等或层级，通过配置来控制交互。举个例子，在上下级关系中，主管智能体可以主动去“找”其他智能体，这种编程范式比传统工作流更灵活。
AutoGPT，去年非常火的项目，通过内部多智能体协作，能理解用户意图、执行代码、做反思，智能化程度高。
GPT Researcher，专注论文和报告阅读、知识库分享、论文批改。
这几个框架各有所长，但一个共同的短板也很明显——过于复杂，可观测性差。就拿AutoGPT来说，用户很难参与其内部思考过程，想要扩展自己的智能体或迁移到其他场景，门槛很高。就在这个背景下，OpenAI开源了Swarm框架。它定位为educational framework，一个简单易学的研究平台。简洁的抽象、统一的接口设计——用户接口用Python函数，工具也通过Python定义，智能体间通信基于function call实现动态路由。功能上，Swarm的智能体内部记忆比较简单，但其价值在于提供了一条清晰的路径去理解和扩展多智能体系统的调度机制，这对提升可观测性很关键。
2. OpenAI Swarm 介绍
Swarm完全用Python实现，核心代码量只有大约500行，简洁、易上手。它兼容OpenAI的API接口——这意味着你可以不用OpenAI的模型，只要配置好API Key和服务地址，就能无缝切换到国内服务或本地部署的模型。Swarm直接使用了OpenAI的Python SDK，不与任何商业模型绑定。智能体及其工具全通过Python定义，支持历史对话记录，多轮对话没问题。官方提供了安装指南，example目录下有具体示例。即使是复杂场景，也可以用类似方式简化处理，比如最基础的单智能体场景，用法和直接调用Python SDK差不多。
多智能体系统的可观测性问题
即使系统搭建起来，可观测性仍然是一块硬骨头。
可观测性这个概念，指的是从系统外部推断其内部状态的能力。如果可观测性强，比如在AIOps场景或云原生服务中，我们就更能理解和管理系统。云原生服务的不确定性众所周知——端口可能动态分配到不同节点，所以必须依靠外部的流监控、统计信息、APM调用链等来增强可观测性，确保任务调度均衡、问题及时发现。
对LLM或多智能体系统而言，可观测性意味着：能否通过系统的最终输出或执行历史，反推出内部的路由决策是否正确、是否符合预期。要实现这一点，就必须加强可观测能力。一个系统是否可控，很大程度上取决于它是否可观测。例如，一个正常的快递订单流程应该走哪几步；当我们输入一个异常订单，系统能否按照预期去调整调度——这些信息都必须清晰可见。
如果只是跑一个多智能体脚本，拿到一个最终结果，这样的结果可信度不足、可控性也很差。想要重现同样的场景，调用流程可能已经变了样。因此，提升多智能体系统的可观测性和可控性是生产级应用的前提。
LLM自身就带有一些固有问题。首先，Transformer和神经网络架构天然解释性差。决策树能让人直观看到决策路径和阈值，但神经网络是矩阵运算直接出结果，内化的处理方式导致它不可解释。其次，LLM的幻觉和输出不稳定可以通过定义工作流和特定提示词来限制。工作流应用广泛，因为单一智能体通常无法完成所有业务，正确率也可能偏低。以自然语言转SQL（NL2SQL）为例，最先进的大模型在通用场景下正确率可能只有40%左右，远不够生产使用。解决方式是限定场景或定义工作流：不要求一次性生成完整SQL，而是先输出框架或业务指标，再逐步完善。结合业务流程和逻辑，就能有效控制输出。在顺丰内部，像LangChain、LangGraph这类自定义工作流软件已经实现了与业务流程结合的流程可控性。
但多智能体系统的目标其实是处理更泛化的场景——面对众多工作流，我们不希望对每个流程都单独定义，而是希望智能体自身具备动态路由调度的能力。此时，系统的可观测性就得靠外部机制来扩展了。
以顺丰快递的“收转运派”流程为例。我们可以定义多个智能体：客服智能体回答用户咨询，客户端APP智能体管理订单，订单处理系统智能体协调快递员，快递员和中转站各自执行揽收和转运。在这个场景中，工作流细节不完全明确，但每个智能体的角色和责任很清晰。它们通过彼此协作完成复杂流程。
当然，实际系统比这个描述要复杂得多。客户端APP里有一个下单工具，用户一操作，工具就通知订单调度系统分配任务。订单处理智能体拥有调度工具，用来安排快递员收件和派件；快递员智能体有执行工具。具体流程是：用户下单 → 订单信息传给订单处理系统 → 调度快递员揽收 → 快件到中转站 → 中转站通知订单处理系统安排派送。虽然内部调用关系复杂，但角色和职责可以清晰定义。
那么问题来了：当用户说“从深圳寄一台电脑到北京”，系统是怎么处理的？客户端APP识别出这不是客服咨询，直接调度到下单系统，最终输出文本信息。但问题是，仅靠大模型的输入和输出，根本不够。我们虽然定义了多个智能体及其之间的调用关系——这些关系可以用图表软件可视化——但在多智能体模型里，输入是自然语言，输出也是自然语言，内部调用关系完全不透明。这就是可观测性问题：你不知道自然语言输入经过了多少个智能体，它们是否激活并调用了特定工具，每个智能体有哪些工具、这次激活了哪个，工具的业务逻辑、输入输出参数、中间执行日志——这些在最终的自然语言输出里全看不见。
更麻烦的是，这种智能体调用模式让复现和重放变得困难。如果改了需求，或者在系统里增加了新的智能体，系统能否按预期执行？写单元测试也很棘手，因为温度参数一变、输入文本稍有不同，输出结果就会变。测试的一致性和可预测性都很难保证。
因此，要提升系统的可控性和可靠性，就必须增强可观测性和可视化能力，让内部工作流透明可见。
实际操作中，我们可能想测试多智能体系统的路由调度是否正确。但如果只有最终的大模型输出，根本无法评估调度准确性。如果要加客户回访流程，引入更多智能体，就得改造现有系统——不仅记录最终操作，还要追踪每个智能体在整个流程中的行为：调用了哪些工具、激活了哪些功能、执行了什么业务逻辑。只有掌握了这些，才能确保系统行为符合预期，为后续优化提供依据。
如何拓展 OpenAI Swarm 实现更好的可视化方案
1. 多智能体系统的可观测性实现
我们目前的工作还在起步阶段，目标就是提升可观测性。一个直接的做法是获取智能体在整个操作过程中的所有历史记录。具体来说，可以启用Swarm框架的内部日志，尤其是debug模式。开启后，能看到一部分中间调用链的信息——系统提示、用户输入、函数调用及其参数。随着处理深入，历史消息逐渐累积。通过调试日志，可以知道当前哪个智能体在处理任务，以及它发起的大模型调用的具体参数。当然，调试日志主要用来了解智能体行为。
第二个方面，基于统一的历史信息收集智能体响应的数据。系统会对这些信息做部分截取，但通过收集数据，能实现一定程度的可视化和存储。
第三个方面，收集函数运行信息。在多智能体系统中，每个智能体会调用多个Python函数。如果只靠打印日志，没法有效收集响应数据。因此我们对代码做了改造，通过全局上下文汇总信息，再用数据持久化技术保证数据长期保存。有了持久化数据，再开发可视化技术来提升可观测性。
整体架构设计是这样的：未来会支持OpenAI的Swarm、MetaGPT、AutoGen等多种框架。这些框架按特定响应格式提供运行历史数据，可能需要适当改造或通过全局上下文收集信息。我们开发了一个叫AgentInsight的服务，专门负责解析各智能体响应格式，实现多种可视化展示。例如，把交互过程做成类似聊天机器人的界面，每个智能体用不同图标表示，用户能看到任务调用了多少个智能体、哪个在处理、处理时间是多少。对于RCA这类复杂场景，可以做“作战室”式的展示——多个智能体同时排查，一个统一的智能体负责调度。简单场景则支持命令行输出和图表展示。
在智能体侧，我们扩展了Replay功能，允许用户指定以前运行过的场景回放到某个节点，然后在此基础上添加新智能体继续执行。这对复现和调试复杂工作流很有帮助。
2. 基于 OpenAI Swarm 的改造
改造工作主要包括几部分：理解Swarm源码、收集多智能体应用的Response信息、扩展Context支持Function信息、做可视化展示。
源码解析的重点是理解Swarm的整体实现原理，尤其是它如何调用OpenAI API、如何实现多轮对话——每个大模型输出后判断是否要交接给另一个，直到可以结束才输出最终结果。每个智能体的输出包含历史记录，还决定了是否需要传给下游智能体。
Swarm内部没有记忆功能，这是我们后续可以贡献回OpenAI的一个方向。我们打算添加持久化存储来保存历史数据，增强可观测性和可追溯性。
智能体的主要组件包括系统提示、使用的模型、可用的函数调用。这些元素决定了行为模式。函数调用以固定格式输出，包含角色信息，可以通过反射机制调用原生函数。
为了实现可视化，我们做了持久化改造——把所有历史数据写入本地JSON文件，补充必要信息，确保用户输入不丢失。持久化数据可以用来制作更复杂的可视化，比如命令行界面或动态图表。
可视化展示层面，命令行界面展示了智能体间的调用关系以及具体的Python函数和执行细节。
大部分上下文信息可以通过OpenAI的history message获取，但某些action执行日志需要额外补全。我们为每个function call设计了一个全局context variable，每次调用时追加函数执行信息，确保与代码顺序一致。抽象出一个方法，保证每次调用Python函数时都主动追加信息到context variable，方便后续持久化和可视化。
后续改造计划包括增加更多可视化格式，比如动态图、War room。历史记录重放功能已经实现，接下来会支持续写——向Swarm客户端传递一个历史的智能体调用关系，在新的智能体体系下继续执行新流程。还有前端界面控制：用户可以通过拖拽节点来定义预置工作流，实现动态调度。另外还会支持更多开源智能体系统，丰富技术生态。
Q&A
Q1：Multi-agent 和 Workflow 的区别是什么？下单的例子是否可以用 Workflow？
A1：确实，Workflow可以实现标准流程的集成定义。比如处理正常订单的收转运发流程，可以用LangChain等工具定义并串联多个对象，形成标准化工作流。但多智能体系统的优势在于灵活性和适应性。它不仅能处理标准流程，还能应对非标准请求——比如用户问了个客服类问题，MAS能根据具体情况调度到合适的客服智能体，而不是死板地走预设工作流。通过可视化日志可以看到，客户端APP接收到特定类型查询后会直接返回信息，不触发标准派送流程。大语言模型智能体可以根据用户输入动态调整调度路径。所以，工作流提供了更强的可控性和明确流程定义，但面对开放域问题或复杂场景时，多智能体系统的灵活性和自适应能力更胜一筹。遇到可观测性挑战，也是我们选择基于OpenAI Swarm做探索的原因。
Q2：Agent 框架的核心作用是什么？内置的 prompt 和 memory 组件真的有利于 Agent 应用的诞生吗？模型自身的能力是否更重要？
A2：Agent框架的核心作用是为开发者提供一个抽象层，简化智能体类创建、智能体间通信及内存管理，减少重复劳动，促进模块化设计。模型自身的推理能力和表达力当然重要，但一个好框架能极大推动Agent应用的开发和部署。定制化框架灵活性高，OpenAI Swarm这样轻量级的则因为简洁性和可扩展性而受欢迎。想快速上手的用户可能更适合MetaGPT或Research GPT；追求高定制化的项目，Swarm提供了灵活的基础架构。AgentUniverse等框架更专注特定场景，内部预置了多种智能体及其交互方式，适合演示，但实际业务可能需要调整。说到底，选择哪个框架取决于业务需求。
Q3：团队组织中，算法工程师在多智能体协作中可以做哪些工作？
A3：在顺丰科技，我们负责AI平台和大模型技术组件的开发，既有基于开源框架的工作，也有自主研发，比如Swarm、LangChain、LangGraph、Dify等。这些框架各有特点：工程化程度高的，主要由架构师和后端同学搭建；像Swarm这种纯Python接口的框架，则更适合编程能力强、有算法背景的工程师来做开发和优化。多智能体框架门槛在降低，算法工程师可以在更多方面发挥作用——比如实现多智能体间的动态调度逻辑、定义智能体行为模式，还能参与大模型推理优化，确保在生产环境高效运行。千问2.5这样的开源项目我们也测试过，效果不错，基本满足生产需求。所以算法工程师在多智能体协作中的角色越来越重要，尤其是在结合业务做定制化开发时。
Q4：关于新出的 MC 协议的影响？
A4：目前关于MC协议了解有限。但从原理上看，不依赖特定的调用机制（比如function call）也可以通过其他方式交互——比如JSON格式输出或结构化数据交换。很多功能可以用Python等高层语言实现，不需要底层或工具层额外支持。如果有具体疑问，可以会后交流。