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