Neuro SAN 即您所需 — 一个数据驱动的多智能体编排框架（扩展版）
作者：Deepak Singh
欢迎深入了解 Neuro AI 智能体网络系统 (Neuro SAN)，这是一个全新的数据驱动多智能体编排框架，正在改变我们构建智能系统的方式。
这是一篇富有洞察力的长篇阅读，涵盖了从核心概念、独特技术特性到实际示例以及与其他流行平台的比较等方方面面。无论您是机器学习工程师、解决方案架构师、好奇的产品经理还是充满热情的学生，这里都有适合每个人的内容。
那么，拿起您最喜欢的咖啡杯（或茶），找一个舒适的地方，让我们一起探索为什么 Neuro SAN 可能是您下一个大型 AI 项目的完美选择！
多智能体编排简介
多智能体编排允许开发者和业务用户构建**AI 智能体团队**，协同解决复杂任务。在过去一年中，涌现出众多框架来编排**多智能体 AI 系统**——使自主或协作 AI 智能体能够协同规划、推理和行动。AWS 和谷歌等行业领导者已经推出了自己的多智能体解决方案，并且已经提出了像**模型上下文协议 (MCP)** 这样的开放标准，通过统一接口（本质上是“AI 应用程序的 USB-C 端口”）将 AI 模型与数据和工具连接起来。这些框架旨在克服依赖单个大型语言模型 (LLM) 或智能体来完成复杂任务的局限性。多智能体编排器不是期望一个 AI 成为无所不知的专家（这通常不现实——类似于您期望获得博士学位，结果却得到了一个高中实习生），而是将问题分解为更小的部分，并将其分配给可以协作的专业智能体。
什么是 Neuro SAN？
Neuro SAN 是这些框架中最新的一个，起源于旧金山的 Cognizant AI Lab。它采用了一种独特的**数据驱动**方法进行多智能体编排，允许以声明方式而非硬编码逻辑定义整个智能体网络。在这篇文章中，我们将介绍 Neuro SAN 的核心概念和设计，强调其技术优势，并展示它与其他平台的区别。它允许用户——从机器学习工程师到业务领域专家——使用声明式配置文件（HOCON 格式）快速构建复杂的多智能体应用程序，而无需进行大量编码。
Neuro SAN 使得多个大型语言模型（LLM）驱动的智能体能够协作解决复杂任务，通过自适应的智能体间通信协议动态委派子任务。这种方法解决了单智能体系统固有的局限性，即没有任何一个模型拥有解决多方面问题所需的所有专业知识或上下文。
高层架构：
架构说明
- 在 Neuro SAN 中，智能体在定义的网络中相互交互（有时使用 AAOSA 协议），其中一个智能体分解并将其任务或操作委派给其下游智能体。当所有下游智能体都通过完成某个操作或对委派的用户查询或任务做出响应时，前端智能体会整合响应并将其发送回用户。
- Neuro-AI 多智能体加速器中的智能体网络是灵活的。一个网络可以是分层的、顺序的、DAG（有向无环图）导向的，并且每个节点都可以是单个智能体，甚至可以是另一个智能体网络。因此，一个智能体可以连接到多个下游智能体，而这些智能体又可以连接到网络中的其他智能体。
Neuro-SAN 的核心概念与设计
Neuro SAN 的核心设计理念是让**多个由 LLM 驱动的智能体协同工作**，以处理对任何单一 LLM 或智能体而言过于复杂的任务。其动机很简单：如果一个 AI 智能体无法处理整个问题，那就创建一个智能体团队，它们之间相互通信并分工协作。一个智能体可以决定自己处理用户查询，也可以将子任务委派给其他辅助智能体——这就像一个项目经理智能体寻求专业智能体的帮助一样。
数据驱动的定义
Neuro SAN 设计的一个突出特点是，这些多智能体网络完全在**数据配置文件**中指定，而不是通过代码。Neuro-SAN 使用 HOCON 格式（想象一下 JSON，但带有注释和其他便利功能）来定义智能体、它们之间的关系和行为。这意味着智能体如何交互的逻辑被捕获在一个声明式配置文件（一个“.hocon”文件）中，该文件可以由人类编辑。实际上，这允许**主题专家**或架构师——而不仅仅是程序员——通过编辑配置来设计复杂的智能体网络，描述每个智能体的功能以及它们如何连接。然后，Neuro SAN 引擎在运行时解释此配置以相应地启动智能体。这种数据驱动的方法**大大降低了**创建和调整多智能体系统的门槛：您不必为编排编写自定义 Python 代码；您只需在配置中描述它。
智能体编排机制
在底层，Neuro SAN 提供了一个灵活的编排循环，用于管理智能体之间的通信。智能体使用自然语言（提示）进行对话，但遵循结构化的协议来决定如何路由查询。默认情况下，Neuro SAN 智能体遵循一种称为 **AAOSA**（自适应智能体导向软件架构）的交互模式，它实质上为每个智能体提供了如何响应“查询”的指导方针。一个智能体会检查它是否是合适的响应者；如果不是，它知道如何调用其他智能体来寻求帮助。这种*智能体间通信协议*确保查询动态地传递给最适合处理它们的智能体，而无需人工手动路由问题。这是一种内置于智能体行为中的分散式决策机制（我们很快会更深入地探讨 AAOSA）。
另一个核心设计元素是**分层智能体**。通常，一个智能体（例如，“领队”或协调智能体）充当用户的主要接口，它可以将子任务委托给下游专业智能体。这允许将复杂的任务分解为任务层次结构中较小的任务。**Neuro SAN 原生支持此类层次结构，甚至支持嵌套智能体网络**。事实上，一个*智能体网络*可以将其流程的一部分调用另一个子网络，从而实现智能体团队的重用和模块化设计。
代码工具集成
现实世界的任务通常涉及纯 LLM 无法执行的操作（例如查询数据库、进行大量计算或调用外部 API）。Neuro SAN 通过允许智能体调用**代码工具**来解决这个问题——本质上是执行 LLM 领域之外确定性操作的自定义 Python 函数或类。这些工具无缝集成到智能体网络中。在 HOCON 配置中，除了函数调用，您可以声明一个智能体可以使用某些工具，并且智能体的提示将被设计为在适当的时候调用这些工具（类似于高级 LLM 中的函数调用）。重要的区别是，Neuro-SAN 将这些工具视为智能体网络中的一流公民：智能体可以“要求”工具做某事，并将其结果作为其推理循环的一部分返回。这开辟了一种混合解决问题的方法——部分是自然语言（LLM 推理），部分是传统编程。主题专家可以在配置中定义“智能体 A 应该使用工具 X 来获取数据 Y”，开发人员可以单独用 Python 实现工具 X。这种**LLM 驱动的步骤和确定性代码步骤的编织**是 Neuro-SAN 中强大的设计范式。
灵活部署
Neuro SAN 作为 Python 库提供，可以嵌入到您自己的应用程序中运行，也可以作为独立服务运行。您可以通过编程方式导入和实例化智能体网络来直接集成它，或者您可以运行 Neuro-SAN 服务器，该服务器通过 HTTP/gRPC 端点向外部客户端公开智能体网络。服务器模式对于企业设置很有用，在这种设置中，集中的智能体编排服务由许多客户端共享（例如，各种应用程序可以查询的微服务来利用智能体团队）。由于智能体的整个配置是数据驱动的，因此部署新的或更新的智能体网络就像更改服务器上的配置文件一样简单——无需重新部署代码。这使得 Neuro-SAN 对于快速原型设计和迭代很有吸引力：调整 HOCON 文件，重新加载清单，您就可以立即获得修改后的多智能体行为。
总而言之，Neuro SAN 的设计理念是**将多智能体逻辑的“定义”（在数据配置中处理）与执行引擎（Neuro-SAN 运行时）分离**。这产生了一个高度适应的系统：添加新智能体、更改智能体的提示或工具，或重新连接智能体层次结构，都只需编辑配置，而不是编写新的 Python 类。非工程师可以为塑造 AI 系统的行为做出贡献，而开发人员可以专注于实现任何必要的工具或自定义集成。接下来，让我们探讨使 Neuro-SAN 独一无二的一些关键技术特性。
技术优势与独特功能
Neuro SAN 提供了多项技术优势和新颖功能，使其区别于其他多智能体编排框架。
**AAOSA——自适应智能体通信协议：** Neuro-SAN 智能体遵循 AAOSA 协议进行智能体间通信。实际上，这意味着每个智能体都可以*自适应地决定*它是否能够处理查询，或者是否应该请求另一个智能体协助。AAOSA 为智能体提供了推迟或委托任务的标准化方式：例如，一个智能体可能有一个 aaosa_instructions 规则，规定“如果你（智能体）不确定或查询超出你的范围，请制定一个子查询并将其转发给一个合适的专业智能体。”该协议导致问题在网络中动态路由，而无需单个固定的中心路由器。智能体本质上是自我路由的：如果智能体 A 收到一个关于财务的问题，并且它知道智能体 B 是财务专家，则 A 将调用 B 来回答。这种**去中心化决策编排**（受智能体导向对话管理研究的启发）内置于 Neuro-SAN 的默认智能体行为中。好处是灵活性——系统可以通过让智能体以连贯的方式相互交流来处理需要多步推理或多种专业知识的查询。
**多智能体系统的数据驱动定义：** 如前所述，Neuro-SAN 使用纯数据配置（HOCON 文件）来定义智能体网络。无需硬编码智能体逻辑——角色、LLM 配置、提示、函数、工具使用和网络拓扑都通过配置进行描述。这种方法意味着**更快的开发周期**和更简单的维护：调整智能体的行为通常就像编辑配置文件中的一行代码一样简单（例如，更改 LLM 模型或添加新工具）。它还为领域专家直接编写或调整 AI 逻辑提供了机会。例如，产品经理可以在配置中更新“需求分析师”智能体的提示，以包含新的指导方针，而无需请求开发人员更改代码。此外，由于配置是声明性的，因此更容易**版本控制和审计**智能体网络随时间的变化（配置文件充当系统的文档）。简而言之，Neuro-SAN 将多智能体编排视为**配置，而非编码**，这是与其他代码密集型框架相比的独特之处。
**智能体间秘密数据（Sly-Data）用于安全信息共享：** Neuro-SAN 提供了一种称为 **sly_data** 的机制，允许智能体在正常的 LLM 对话流**之外**共享某些数据。这本质上是一个用于私人或敏感数据的通道，不应在提示或模型完成中公开。例如，如果一个智能体作为任务的一部分获取了 API 密钥或用户的个人信息，它可以将这些数据放入 sly_data，而不是直接告诉另一个智能体。sly_data 在后台在智能体之间移动，因此大型语言模型永远不会直接“看到”它。这对于维护隐私和安全至关重要——例如，将运行总计、数据库 ID 或凭据保留在自然语言上下文之外（防止 LLM 意外泄露或更改它们）。Neuro-SAN 的配置允许您精确指定哪些 sly_data 字段可以在哪些智能体之间共享或返回给客户端。默认情况下，除非明确允许，否则不共享任何内容，这符合**安全默认**的立场。实际上，sly_data 充当了一个**安全黑板**，智能体可以在其中存储状态信息（计数器、中间结果）并沿链传递，而不会污染对话上下文。此功能不仅提高了安全性，还有助于状态管理——智能体可以在提示令牌之外维护某些事实的内存（例如累积成本或用户配置文件）。
**支持代码工具和外部集成：** Neuro SAN 不仅仅将智能体限制在 LLM 文本操作上——智能体可以调用**代码工具**（Python 函数或外部 API）来执行操作。这包括与外部系统甚至其他智能体框架的集成。例如，Neuro SAN 已展示智能体通过 **MCP（模型上下文协议）** 调用外部服务来计算身体质量指数，或者将查询委托给 Salesforce **AgentForce** 智能体来处理 CRM 请求，或者调用 **Agentspace** 智能体来执行数据库搜索。在这些情况下，Neuro-SAN 智能体有效地将外部智能体或服务视为工具：它制定请求，通过（MCP 或 API）发送请求，然后处理响应。此功能意味着 Neuro SAN 可以充当**编排中心**，连接多个系统。无论是连接到专有企业工具、其他编排框架（例如连接到 *CrewAI* 或 *A2A* 管道），还是在工具中利用 LangChain 等库，Neuro SAN 都**旨在集成**而非孤立存在。配置驱动的方法也适用于此——您可以指定一个使用 Anthropic API 或调用 Google Agentspace 端点的工具，Neuro SAN 智能体将把它作为其推理的一部分使用。通过简单的接口支持代码工具，Neuro SAN 允许在需要时将**确定性操作**（数据库查询、数学计算、触发动作）注入到智能体的工作流程中。这极大地扩展了多智能体系统除了聊天或编写文本之外可以做的事情。
**动态智能体网络创建（智能体网络设计器）：** Neuro-SAN 甚至包含一个元智能体，称为**智能体网络设计器**——本质上，这是一个*创建其他智能体网络的智能体*。这是 Neuro-SAN 提供的一个示例多智能体系统，它可以从用户那里获取高级描述，并为自定义智能体网络生成新的 HOCON 配置。实际上，您可以告诉智能体网络设计器类似“我需要一个零售公司客户支持中心的智能体团队”之类的话，它将尝试生成一个 .hocon 文件，定义适合该场景的智能体（可能是*支持智能体*、*产品查询智能体*、*退货政策智能体*等）。它会将该配置保存到您的注册表目录中，甚至建议示例查询。这展示了数据驱动网络的强大功能：Neuro-SAN 可以根据用户意图以编程方式编写自己的配置。运行时动态创建智能体网络对于快速原型设计或即时生成专业智能体团队可能很有用。这是*AI 辅助 AI 开发*的一瞥。虽然此功能目前是一个演示，但它强调了 Neuro-SAN 的灵活性——该框架不限于静态、预定义网络；新的智能体配置可以动态启动和部署。
**智能体特定上下文和日志记录：** 在 Neuro SAN 中，网络中的每个智能体都可以拥有自己的**上下文和配置**，并根据其角色进行定制。例如，一个智能体可能使用快速、经济的 LLM（用于简单任务），而另一个智能体可能使用功能更强大的模型，具有更大的上下文窗口（用于复杂推理）。HOCON 配置允许您指定每个智能体的 LLM 设置——模型名称、端点、温度、最大令牌等。这意味着您可以通过将正确的模型与正确的子任务匹配来优化成本和性能（例如，摘要智能体可以使用较小的 70b 参数模型，而策略智能体可以使用 GPT-4o）。智能体甚至可以在其配置中定义备用模型选项（如果主要 API 失败或关闭），从而提高可靠性。此外，Neuro-SAN 还提供**强大的日志记录和调试支持**。当您运行智能体网络时，您可以启用详细日志，跟踪每个智能体的思维过程、工具调用和智能体间消息的每一步。这对于开发人员理解和解决多智能体推理问题非常有价值。Neuro-SAN 的日志可以显示，例如，智能体 A 何时将任务移交给智能体 B，发送了什么提示，返回了什么工具输出，以及最终答案是如何组成的。该框架甚至提供了测试基础设施（数据驱动的测试用例和自动化评估器）来评估您的智能体的性能并对故障模式进行分类。所有这些功能使其**对开发人员友好**——您可以深入了解智能体推理的“黑箱”，并快速迭代。
工具与外部系统集成
Neuro SAN 最强大的方面之一是它能够将工具和外部系统直接集成到智能体的工作流程中。Neuro SAN 中的“编码工具”通常是一段实现特定功能的 Python 代码——例如，计算器、数据库查询或 Web API 调用。工具符合简单的接口：通常是一个继承自 CodedTool 的类，带有一个 async_invoke 或 invoke 方法，该方法接受一些参数和 sly_data，并返回结果。由于 Neuro SAN 智能体可以根据需要调用这些工具，因此您可以为智能体增强**超出 LLM 原生能力的功能**。
例如，假设一个智能体需要获取某个城市的当前天气。与其依赖 LLM “知道”天气（如果不是基于实时数据训练，它就无法做到），不如实现一个调用天气 API 的 `WeatherLookupTool` 编码工具。在智能体的 HOCON 配置中，您将此工具声明在智能体的工具列表中。现在，当被问及天气时，智能体将学习（根据其指令）调用 `WeatherLookupTool` 并使用其返回的数据来组织答案。Neuro-SAN 处理底层逻辑：智能体的提示可能包含调用工具的模式或指令，当 LLM 输出一个调用（例如，指示使用哪个工具以及带有什么参数的 JSON）时，框架会执行实际的 Python 函数，然后将输出反馈回智能体的上下文。这类似于 OpenAI 函数调用或 LangChain 工具的工作方式，但在这里它是在 Neuro-SAN 自己的运行时环境中进行编排的。
从开发人员的角度来看，添加一个代码工具非常简单。您编写一个 Python 函数或类，然后在配置中引用它。以下是 Neuro SAN 演示中代码工具实现的简化示例，一个 **Accountant** 工具，它维护一个运行成本计数器（我们稍后将详细检查此示例）
class AccountantSly(CodedTool):
def invoke(self, args: Dict[str, Any],
sly_data: Dict[str, Any]) -> Dict[str, Any]:
# Get the current running cost (default to 0.0 if not set)
running_cost = float(sly_data.get("running_cost", 0.0))
# Increment the running cost (e.g., add cost of current operation)
updated_running_cost = running_cost + 3.0
# Update the sly_data so the new cost persists
sly_data["running_cost"] = updated_running_cost
# Return the updated cost as the tool's output
return { "running_cost": updated_running_cost }
}
（代码改编自 [Accountant 工具实现][62]，它更新了 `sly_data` 中的 `running_cost` 变量。）
在此片段中，该工具从 sly_data（如果存在）读取值 `running_cost`，递增它，将其存储回去，并返回新值。使用此工具的智能体并不知道成本是如何计算的——它只知道每当它回答一个问题时，它都应该调用 `AccountantSly` 来更新成本总计。Neuro SAN 的运行时将根据配置将工具返回的数据合并到智能体的最终答案中（或合并到 sly_data 中以向上游传递）。这种设计清晰地分离了关注点：LLM 智能体专注于回答问题，而代码工具处理精确的会计逻辑，LLM 不会弄错计算或泄露内部状态。
除了编码工具，Neuro SAN 的集成能力还允许它与**外部智能体系统**进行接口。我们已经提到它如何通过 MCP 或 Salesforce 的 AgentForce 调用智能体。该框架的开放性意味着如果您有另一个编排系统，您可以将其封装为工具。例如，您可以有一个 Neuro SAN 智能体，它在某些触发器下，向 *Google Agentspace* 智能体或 AWS Lambda 函数（在工具中使用 Boto3）发送请求——有效地让 Neuro SAN 将云服务协调为其推理的一部分。这使得 Neuro SAN 在企业环境中具有高度可扩展性：它不是一个孤立的智能体孤岛，而是一个可以适时指挥其他“乐器”（服务、API、数据库、其他智能体）的指挥家。
一个具体的例子是计算 BMI（身体质量指数）的智能体网络，它通过 MCP 调用外部服务。在配置中，一个智能体被设置了一个工具，该工具本质上是一个指向远程“BMI 计算器”智能体的 MCP 客户端。当用户问 Neuro SAN“根据我的身高和体重，我的 BMI 是多少？”时，Neuro SAN 的智能体调用外部 BMI 智能体（通过 MCP），然后将结果返回给用户。在另一个示例中，Neuro SAN 将与 CRM 相关的查询委托给 Salesforce Agentforce：Neuro SAN 智能体识别查询是关于检索客户记录的，因此它使用一个查询 Agentforce API 的编码工具，有效地让 Salesforce 的智能体处理它。从最终用户的角度来看，这是无缝的——他们询问了 Neuro SAN，它给出了答案，但在底层，Neuro SAN 引入了专业外部系统的帮助。
**工具集成是安全和受控的**。由于工具可以访问 sly_data 并且是配置的一部分，因此您可以对流入或流出工具的数据进行细粒度控制。根据设计，工具只接收您明确传递的参数（通常来自 LLM 的输出）和 sly_data（我们注意到，它不包含对话文本，除非您在那里放置了某些内容）。这意味着，例如，您可以确保 API 密钥保留在 sly_data 中，并且仅由工具调用插入，绝不会在提示中泄露。Neuro SAN 的日志还将显示所有工具调用，因此您可以审计发生了哪些外部交互。
总而言之，Neuro SAN 的工具和集成框架将其转变为**LLM 推理与更广泛的软件和服务世界之间的桥梁**。您的多智能体系统不仅限于聊天——它可以执行操作、实时获取信息，并根据需要利用其他 AI 服务。这大大增强了 Neuro SAN 智能体网络在实际应用中的实用性。
可扩展性与开发者支持
Neuro SAN 在构建时考虑了可扩展性，认识到 AI 生态系统发展迅速，每个项目可能都有独特的需求。可扩展性的一个关键点是其**与 LLM 无关的设计**。您不局限于单一模型或提供商——数据驱动的配置允许为不同的智能体插入不同的 LLM，并且添加对新提供商的支持非常简单。开箱即用，Neuro-SAN 支持 OpenAI、Anthropic、Azure、Ollama（用于运行本地模型）等提供商，可在 HOCON 文件中配置。如果新的“热门”模型发布，您可以通过在配置中指定其 API 来集成它，而无需更改协调器代码。这种模块化也扩展到**回退模型**：您可以为智能体列出备用模型，以便在主模型不可用时尝试，从而提高可靠性。例如，一个智能体可以首先尝试 OpenAI 的 GPT-4，如果失败（网络问题或速率限制），则自动切换到 Anthropic Claude 模型。
该框架也**与云无关**且与环境无关——因为它纯粹是 Python，您可以在任何平台（本地机器、本地服务器或任何云虚拟机/容器）上运行 Neuro SAN，甚至可以将其与容器编排集成。事实上，Neuro SAN 提供了 Docker 构建脚本，可以轻松部署服务器组件。这使得开发人员可以轻松地从开发环境迁移到生产环境：您可以将您的智能体网络容器化并将其部署到 API 后面。
为了调试和开发，Neuro SAN 提供了丰富的支持。如前所述，它会记录智能体推理步骤的详细跟踪。还有一个**基于网络的开发者 UI**（称为 *NSFlow*，我们将在演示中使用）提供了一个聊天界面，用于与智能体网络交互并实时可视化日志。在开发者模式下运行 Neuro SAN 时，您可以看到每个传递的消息、每个调用的工具以及最终答案的组成方式，这对于理解复杂的智能体行为非常有帮助。日志可以定向到文件（例如，`logs/server.log` 和 `logs/nsflow.log`）以供以后分析。
开发者支持的另一个方面是包含的**测试框架**。Neuro SAN 允许您以数据驱动的方式为您的智能体网络编写测试用例（例如，指定输入和预期输出或结果）。然后，您可以运行这些测试来验证对配置的更改没有破坏任何东西。此外，“评估器”实用程序可以帮助对故障进行分类——例如，如果智能体给出了不正确的答案，评估器（它本身可以是一个 LLM）会尝试分类是由于事实错误、推理错误、在应该使用工具时没有使用工具等原因。这种元 AI 评估可以引导开发人员找到问题的根本原因，并迭代改进系统。
Neuro SAN 的开源性质意味着开发人员可以检查源代码、贡献改进并构建自定义扩展。如果某些功能没有开箱即用——例如您需要一种新型模块或新的第三方集成——您通常可以通过实现一个新组件（可能是新的工具接口或自定义智能体类）来扩展框架，然后通过配置使用它。该项目相对年轻，但有一个活跃的开发路线图。Cognizant 的 AI Lab 最初孵化了它，现在它已向社区开放，这通常意味着快速迭代和功能添加。
至关重要的是，**安全性和治理**也被视为首要考虑，这对于企业使用非常重要。Neuro SAN 的配置驱动策略（sly_data 和其他消息传递的 `allow` 字段）让开发人员*明确定义数据可以在何处流动*，从而防止秘密意外泄露。例如，您可以确保某个私有数据块永远不会传递到 LLM 提示中，因为不允许它向下游流动。这种防护措施内置于您设计智能体网络的方式中。而且因为所有内容都在配置中，所以对智能体网络的安全审查就像审查 HOCON 文件以查找允许的数据通道和授权的工具使用一样简单。
从支持的角度来看，Neuro SAN 提供了文档、用户指南和示例（在 `neuro-san-demos` 存储库中），以帮助新用户入门。社区可以在 GitHub 讨论中讨论想法，并且可以针对错误或功能请求提交问题——典型的开源项目支持渠道。总而言之，Neuro SAN 旨在**适应性强**（适应新模型、新工具、新模式）和**对开发人员友好**，以便团队能够自信地构建和维护复杂的 AI 智能体系统。
运行时与性能
在运行时特性和性能方面，Neuro SAN 旨在处理编排多个智能体的需求，这可能是资源密集型的。每个智能体都可能调用 LLM 或工具，因此协调效率至关重要。Neuro SAN 的运行时是用 Python 实现的，利用异步特性尽可能地进行并行操作（例如，如果一个智能体可以同时调用两个工具，或者多个智能体可以并发操作，框架可以利用异步调用）。该设计避免了大量的轮询或阻塞；相反，它是基于智能体输出的事件驱动的。这意味着如果一个智能体的响应触发另一个智能体调用，Neuro SAN 会将其作为事件处理并保持系统响应。
一个重要的方面是多智能体对话中的**可扩展性**。Neuro SAN 的服务器模式旨在用于生产规模——它可以通过为每个会话管理单独的上下文来处理多个并发会话（例如，多个用户每个都有自己的智能体团队对话）。智能体和工具在会话之间是无状态的（除非您将它们绑定到数据库或外部内存），因此您可以通过在负载均衡器后面运行 Neuro SAN 服务的多个实例来水平扩展（如果需要）。协调器的轻量级特性（因为它只是传递消息和调用 API）意味着瓶颈通常是 LLM 调用本身，而不是编排逻辑。因此，扩展 Neuro SAN 主要涉及扩展后端 LLM 计算（例如，使用 OpenAI 的自动扩展 API，或托管本地模型的多个副本）。
Neuro SAN **已准备好应对高并发和大数据负载**。它提供了**中央服务循环**等功能，可以在容器中或作为后台进程运行，以持续处理智能体任务。文档指出“规模化的服务器就绪性”，表明它已设计为在企业负载下保持健壮。此外，Neuro-SAN 网络可以在需要时**跨多个主机分发**——由于一个智能体可以通过 HTTP/gRPC 调用另一个智能体，您可以将智能体网络的不同部分部署在不同的服务器上（例如，一个处理私有数据的本地安全智能体和一个处理通用查询的云智能体），并且 Neuro SAN 将在它们之间进行协调。术语“分布式智能体网络”用于描述这种情况。这意味着您的多智能体系统不限于一个进程或一台机器；它可以是一个相互调用的 Neuro SAN 服务网络。这对于非常大型的系统或与传统基础设施集成很有用。
在性能优化方面，由于每个智能体的行为都明确指定，您可以调整提示大小和工具使用等参数，以优化响应时间。例如，如果您有一个包含 5 个智能体的链，并且您关心延迟，那么您可以使用更小、更快的模型进行中间步骤以节省时间，仅在绝对必要时才使用大型模型。Neuro SAN 通过配置为您提供了这种控制。它还支持图像或其他数据等**模态**（通过工具），如果您的智能体需要处理非文本输入，但这当然取决于您插入的工具或模型。
需要注意的是，作为一个基于 Python 的编排器，Neuro SAN 与高度优化的底层系统相比会存在一定的开销。然而，其优势在于灵活性和易用性。在许多企业 AI 场景中，与多秒级的 LLM 调用相比，编排中几百毫秒的差异可以忽略不计。因此，Neuro SAN 的性能足以满足典型的用例（如果您需要，可以分析并优化工具调用中的特定瓶颈或切换到更快的模型端点等）。该框架也不会施加显著的内存开销——每个代理本质上是一个具有一些提示和状态的数据结构。
另一个与性能相关的功能是**日志和监控挂钩**。Neuro SAN 可以配置为输出与监控工具兼容的跟踪。例如，您可以将日志发送到 Elastic 或使用 CloudWatch 来跟踪托管的 Neuro-SAN 实例的使用情况、响应时间、故障率等。这使得它在生产环境中可行，因为可观察性很重要。如果智能体运行缓慢或特定工具容易出错，日志将有助于查明，从而进行性能调优。
Neuro-SAN 中的日志记录、追踪与可观察性
可观察性是任何生产级 AI 系统的一个关键方面，尤其是在处理复杂的多智能体交互时。Neuro SAN 强调强大的**追踪、日志记录和可观察性功能**，帮助开发人员和操作人员精确理解智能体网络在运行时如何表现。
丰富的日志记录和追踪
Neuro SAN 提供详细的结构化日志，捕获智能体工作流中的每一个关键步骤。当智能体网络运行时，智能体之间的每次交互——例如**提示、智能体间通信、工具调用和响应**——都会被详细记录。这些日志包括时间戳、智能体标识符、提示输入、LLM 输出、工具调用及其结果以及使用指标，从而能够深入了解多智能体对话的内部运作。
例如，以下是 Neuro-SAN 日志条目对于智能体交互的几个简化示例
[2025-05-15 22:46:21]: "token_accounting": {"time_taken_in_seconds": 18.29955291748047, "total_cost": 0.041325, "successful_requests": 6.0, "completion_tokens": 1097.0, "total_tokens": 13815.0, "prompt_tokens": 12718.0}
[2025-05-15 22:46:26]: airline_policy (NeuroSan): {"origin": ["Airline 360 Assistant", "Baggage_Handling", "Checked_Baggage", "ExtractDocs"]}
[2025-05-15 22:46:32]: "response":
{
"type": "AGENT_FRAMEWORK",
"text": "Here's the information regarding the checked baggage policy:
1. **Size and Weight Regulations**:
- The maximum size of a checked bag is 30 in x 20 in x 12 in (76 cm x 52 cm x 30 cm) or 62 total inches, including handles and wheels.
- Weight limits vary by cabin class and MileagePlus status:
- Economy & Premium Economy: 50 pounds (23 kilograms)
- Business, First, and Polaris Business Class: 70 pounds (32 kilograms)
- Premier Silver, Gold, Platinum, and 1K members: 70 pounds (32 kilograms)
2. **Baggage Fees**:
- Fees for the first and second checked bag may vary based on travel route and will increase by $5 in most markets starting February 24, 2024.
- Use the baggage fee calculator to determine exact costs.
3. **Prohibited Items**:
- Ensure to pack liquids over 3.4 oz (100 ml) in your checked bags and place all liquids in a resealable bag.
4. **Additional Information**:
- You can track your bag status and location using the airline app.
- Certain bag policies may apply for oversized, overweight, or extra bags.
For more detailed information and to access the baggage fee calculator, please visit the [Checked Baggage app page].",
"chat_context": {
"chat_histories": [
{
"origin": [{ "tool": "Airline 360 Assistant", "instantiation_index": 1 }],
"messages": [
{
"type": "SYSTEM",
"text": "<redacted>",
"origin": [{ "tool": "Airline 360 Assistant", "instantiation_index": 1 }]
},
{
"type": "HUMAN",
"text": "hi",
"origin": [{ "tool": "Airline 360 Assistant", "instantiation_index": 1 }]
},
{
"type": "AI",
"text": "Hello! How can I assist you with airline related policies today?",
"origin": [{ "tool": "Airline 360 Assistant", "instantiation_index": 1 }]
},
{
"type": "HUMAN",
"text": "what all can you help me with?",
"origin": [{ "tool": "Airline 360 Assistant", "instantiation_index": 1 }]
},
{
"type": "AI",
"text": "I can respond to inquiries related to checked baggage policies, including size, weight, and security regulations, as well as information on prohibited items, international travel, baggage related queries and premium member-specific benefits.\n\nIf you have a specific question or task related to airline policies, feel free to ask!",
"origin": [{ "tool": "Airline 360 Assistant", "instantiation_index": 1 }]
},
{
"type": "HUMAN",
"text": "ok what's the policy in checked baggage?",
"origin": [{ "tool": "Airline 360 Assistant", "instantiation_index": 1 }]
},
{
"type": "AI",
"text": "Here's the information regarding the checked baggage policy:\n\n1. **Size and Weight Regulations**: \n - The maximum size of a checked bag is 30 in x 20 in x 12 in (76 cm x 52 cm x 30 cm) or 62 total inches, including handles and wheels.\n - Weight limits vary by cabin class and MileagePlus status:\n - Economy & Premium Economy: 50 pounds (23 kilograms)\n - Business, First, and Polaris Business Class: 70 pounds (32 kilograms)\n - Premier Silver, Gold, Platinum, and 1K members: 70 pounds (32 kilograms)\n\n2. **Baggage Fees**:\n - Fees for the first and second checked bag may vary based on travel route and will increase by $5 in most markets starting February 24, 2024.\n - Use the baggage fee calculator to determine exact costs.\n\n3. **Prohibited Items**:\n - Ensure to pack liquids over 3.4 oz (100 ml) in your checked bags and place all liquids in a resealable bag.\n\n4. **Additional Information**:\n - You can track your bag status and location using the airline app.\n - Certain bag policies may apply for oversized, overweight, or extra bags.\n\nFor more detailed information and to access the baggage fee calculator, please visit the [Checked Baggage app page]",
"origin": [{ "tool": "Airline 360 Assistant", "instantiation_index": 1 }, { "tool": "Baggage_Handling", "instantiation_index": 1 }, { "tool": "Checked_Baggage", "instantiation_index": 1 }]
},
]
}
]
}
}
这种结构化日志格式支持强大的可观察性模式，使得重建智能体在任何步骤或时间戳之间精确做了什么，排除意外行为或审计智能体决策变得非常简单。
Neuro SAN 保持强大的会话级可追溯性，为每个对话或智能体交互流分配唯一的会话 ID。基于会话的跟踪允许开发人员跟踪请求或用户交互通过各种智能体的完整生命周期，从而轻松查明问题或瓶颈。
Neuro SAN 的日志清晰简洁地追踪了整个交互链，使开发人员能够立即查明延迟或错误发生的位置以及哪些智能体或工具负责。
与可观察性工具集成
Neuro SAN 的日志与行业标准的日志记录和可观察性平台兼容。您可以轻松地将 Neuro SAN 日志导入到以下系统中：
- **Elastic Stack (ELK)** 用于详细分析和搜索。
- **Prometheus 和 Grafana** 用于实时指标和仪表板可视化。
- **AWS CloudWatch 或 Google Cloud Operations** 用于集成的云监控解决方案。这种灵活性使得运营团队能够快速可视化关键性能指标，例如智能体响应时间、故障率和系统吞吐量，并为异常行为设置主动警报。
一个实际示例
让我们通过一个具体的例子来将这一切落到实处。我们将使用 Neuro SAN 提供的一个演示智能体网络，名为 **“Music Nerd Pro Sly”**。此示例展示了几个关键功能：多个智能体（包括一个代码工具智能体）、智能体间通信、sly_data 的使用以及如何运行系统。通过逐步讲解，您可以了解 Neuro-SAN 的实际工作方式。
music_nerd_pro_sly.hocon 智能体网络概述
Music Nerd Pro Sly 是一个简单的智能体网络，旨在回答有关音乐的问题（特别是 1960 年代以来的音乐），并记录已回答问题的数量（作为“运行成本”）。它由一个**领队智能体**——与用户交互的主智能体——和一个辅助智能体组成，该辅助智能体实际上是作为代码工具（**Accountant** 工具）实现的，负责增加计数器。领队智能体是一个基于 LLM 的智能体，对音乐历史了如指掌。当用户提出音乐问题时，领队智能体将回答它，但它也会每次调用 Accountant 工具来更新运行成本。sly_data 在此网络中的使用很重要：运行成本值存储在 sly_data 中，因此它不会在对话中暴露，但它会传递回用户（并在回合之间保持）。
所有这些都在 `music_nerd_pro_sly.hocon` 配置文件中定义。在该文件中，您将在领队智能体的配置中看到类似以下内容
"allow": {
"to_upstream": {
"sly_data": {
"running_cost": true
}
}
}
此片段（在领队智能体的定义下）告诉 Neuro SAN，sly_data 中的 `running_cost` 字段应**上游**传递——即，允许传播回调用此智能体的任何内容（最终是客户端）。简单来说，这意味着“将 running_cost 包含在返回给用户的输出中”。相反，如果没有此设置，running_cost 将隐藏在 sly_data 中，不会离开智能体。该配置还确保 `running_cost` 被适当地重置或初始化。
领队智能体的提示旨在鼓励它回答音乐问题，然后在每次回答后调用 Accountant 工具。同时，Accountant 不是作为典型的 LLM 智能体定义的，而是在 `coded_tools` 部分下定义的。它没有提示；相反，它链接到一段我们将接下来解释的 Python 代码。
Accountant.py 代码工具简要说明
Accountant 工具（在演示中的 `accounting.py` 中实现）是一个简单的 Python 类，每次调用它时都会增加一个变量 `running_cost`。我们在上面的工具部分看到了它的一个版本。从概念上讲，您可以将其视为维护一个计数器（从 0 开始），每次回答问题时都会增加一定数量。在演示中，他们将每个问题视为花费 3.00 美元，因此理想情况下，第一个响应应将 running_cost 设置为 3.0，第二个设置为 6.0，依此类推。领队智能体对计算一无所知；它只是调用 Accountant 工具并返回一个更新的数字。sly_data 机制确保 `running_cost` 在回合之间持久存在：在第一个问题之后，sly_data 可能在会话级别包含 `{"running_cost": 3.0}`，以便当用户提出后续问题时，领队智能体可以将其带入，并且 Accountant 将其增加到 6.0。
这里重要的是**工具负责记账**，而 LLM 智能体专注于领域知识（音乐）。这种关注点分离正是 Neuro SAN 鼓励集成编码工具的原因。如果我们试图让 LLM 自己跟踪计数，它可能会出错或忘记数字。相反，LLM 每次都只是调用 Accountant，而 Accountant 可靠地更新计数。用户会得到一个包含音乐答案和更新的运行成本的组合答案，而 LLM 无需明确推理算术。
环境设置
要运行此示例，您需要安装 Neuro SAN 并可访问适当的 LLM（默认配置使用名为“gpt-4o”的模型，在演示中可能指通过 OpenAI API 的 GPT-4 或本地 GPT-4 替代方案）。以下是设置的快速指南
克隆工作室存储库
git clone https://github.com/cognizant-ai-lab/neuro-san-studio
cd neuro-san-demos
创建虚拟环境并安装所需组件
python -m venv .venv
source .venv/bin/activate && export PYTHONPATH=`pwd`
pip install -r requirements.txt
**配置 API 凭据：** Neuro SAN 需要访问您计划使用的任何 LLM 的 API。如果您使用 OpenAI 的 GPT 模型，请设置您的 `OPENAI_API_KEY` 环境变量
export OPENAI_API_KEY="sk-..." # replace with your actual API key
如果需要，对任何其他提供商（例如，`ANTHROPIC_API_KEY`）执行相同操作，或配置本地模型。默认情况下，演示可能假定 OpenAI 用于 GPT-4。确保您有权访问该模型，或者将配置调整为您可以使用的模型（例如，如果 GPT-4 不可用，HOCON 可以切换为使用 Anthropic 模型）。
**获取演示文件：** 确保您拥有 `music_nerd_pro_sly.hocon` 文件和 `Accountant` 工具代码。如果您通过 pip 安装，这些演示文件可能包含在软件包的示例中，或者您可以从 neuro-san-demos 存储库获取它们。将 `.hocon` 文件放在 Neuro SAN 的注册表目录中（或调整环境变量以将 Neuro SAN 指向该文件），并确保 `accounting.py` 工具代码在编码工具路径中可用。
现在，运行 Neuro SAN 主要有两种方式：直接通过 CLI，或通过 `nsflow` Web 客户端。我们将使用 `nsflow` 来获得交互式体验。
运行 Neuro SAN 服务器和 nsflow 客户端
Neuro SAN 附带一个方便的一体化启动器，用于开发。从项目根目录（或您配置的工作目录）中，只需运行
python -m run
此命令同时启动 Neuro SAN 后端服务和基于 FastAPI-React 的 Web UI (nsflow) 以进行交互。运行命令后，请等待几秒钟加载所有代理，然后您应该会看到日志，指示服务器已准备就绪且 UI 已启动。
打开浏览器并导航到 http://127.0.0.1:4173。您将看到 NSFlow 界面。这是一个简单的类似聊天的界面，专为开发人员使用而定制。在左上角的侧边栏中，您会看到它已连接到在 localhost:30013 运行的 Neuro-SAN 服务器。在此侧边栏中，您可以从可用代理网络列表中选择 – 选择 **“music_nerd_pro_sly”**（名称派生自 .hocon 文件）。这会告诉客户端使用哪个代理网络进行对话。
现在您可以开始提问了！让我们来看一个示例交互
- 用户提问：“Which band wrote *Yellow Submarine?*”（哪个乐队创作了《黄 Submarine》？）—— 这是向音乐领域代理提出的问题。
- 代理回答： 主持人代理（音乐专家）将回答：“The Beatles wrote Yellow Submarine.”（披头士乐队创作了《黄 Submarine》。）同时，它会调用 Accountant 工具，将 running_cost 从 0 增加到 1。由于我们允许 running_cost 向上游传播，最终输出回 UI 将包含该成本。因此用户看到类似这样的内容
{
"answer": "The song 'Yellow Submarine' was written by The Beatles, specifically by John Lennon and Paul McCartney. It was sung by Ringo Starr and released on their 1966 album 'Revolver'.",
"running_cost": "3.0"
}
- 在 nsflow UI 中，它可能以友好的方式显示，但本质上代理的响应 JSON 包含答案和运行成本。我们得到了正确的音乐答案，以及一个
running_cost为 3.0，表示目前已进行一次查询。 - 后续问题： 现在用户提问：“Where are they from?”（他们来自哪里？）—— 由于我们正在继续相同的会话，主持人代理知道“他们”指的是披头士乐队（Neuro-SAN 通过处理代理的记忆或对话来保留对话上下文）。它再次调用 Accountant 工具。该工具查看 sly_data 中现有的 running_cost (3.0)，将其增加，并返回 6.0。主持人包含此信息，因此响应变为
{
"answer": "The Beatles are from Liverpool, England. They formed in 1960 and became one of the most influential and successful bands in the history of popular music.",
"running_cost": "6.0"
}
对于用户来说，看起来人工智能总是能记住提问了多少个问题并更新成本。从系统角度来看，我们看到 *sly_data 允许我们在轮次之间安全地传递状态*，并且工具每次都完成了它的工作。LLM 代理只专注于知识部分（谁创作了这首歌，乐队来自哪里）—— 它不必在提示中明确记住计数，这是一个很好的设计，因为它减少了令牌使用和出错的可能性。
在幕后，如果您检查运行 python -m run 的终端，您将看到日志输出。您会注意到指示调用 AccountantSly 工具的行，并打印其调试信息（代码在调用时会打印消息）。您还会看到发送给 LLM 的提示（其中包括使用工具和之前对话的指令）。此日志对于验证一切是否按预期工作非常有用。例如，您可能会看到在第一个问题之后，sly_data 中有 running_cost: 3.0，而在第二个问题之后，它有 6.0，这证实了状态得到了维护。
这个实时示例总结了几件事
- 多代理编排： 即使在这种简单的形式中，我们也有两个“代理”（一个 LLM 代理和一个编码工具代理）协同工作。用户只与主持人代理交互，但该代理内部依赖另一个组件来完成任务。
- 数据驱动配置实践： 我们从未编写任何代码将“他们来自哪里？”路由到特定代理——系统通过上下文和 AAOSA 协议自行解决。我们所做的只是设置配置并实现一个小型工具。Neuro-SAN 遵循配置中的规则，处理了决定每个查询做什么的繁重工作。
- 状态管理和 sly_data： 示例强调了 sly_data 如何携带一个简单的状态（计数器）并将其与正常对话分开。用户看到了该状态的结果（运行成本），但 LLM 看到的提示不一定包含“运行成本是 X”（除非我们这样设计）。状态是单独管理的，仅在输出中合并，这要归功于
allow.to_upstream.sly_data配置。 - 工具集成： 会计师工具作为代理推理的一部分被无缝调用。从用户的角度来看，AI 似乎总是知道总成本。实际上，后台正在调用一个经典函数。这种模式可以扩展——想象一个在披头士乐队琐事数据库中搜索更多信息的工具；如果需要额外数据，主持人可以调用它。Neuro-SAN 将负责将查询传递给该工具并将结果返回给代理。
- 易于扩展： 如果我们想扩展这个网络——例如，添加一个提供琐事或将答案翻译成西班牙语的代理——我们可以通过编辑 HOCON 文件（并可能添加一个翻译工具或新代理）来实现。Neuro-SAN 将允许主持人也调用这些代理。这个例子虽然简单，但可以作为构建更复杂的代理网络的垫脚石。
使用 nsflow 客户端： 我们在上面的描述中已经使用了 NSFlow。值得注意的是一些功能：nsflow 将记录对话，您甚至可以上传或下载聊天记录。它主要是一个开发人员 UI，因此不适合生产环境中的最终用户，但对于演示和测试来说非常棒。如果您更喜欢控制台交互，Neuro-SAN 还提供了一个 CLI 程序 agent_cli.py – 您可以在单独的终端中运行它，连接到正在运行的服务，进行纯文本聊天。例如
# In one terminal, run the server only (if not using python -m run):
python -m neuro_san.service.agent_main_loop --port 30011
# In another, run the CLI client:
python -m neuro_san.client.agent_cli --connection service --agent music_nerd_pro_sly
这将连接到端口 30011 上的服务，并与 music_nerd_pro_sly 代理网络发起聊天。然后您可以在终端中输入相同的问题并获得相同的结果。NSFlow 方法通过 Web 界面更加用户友好。
完成后，您可以通过在终端窗口中按 Ctrl+C 来停止服务器（这将优雅地关闭 UI 和后端）。
点击下方图片或点击此处链接，观看 Neuro SAN 音乐狂人实时演示：
通过这个实时演示，我们看到了 Neuro SAN 如何以数据驱动的方式编排多代理交互。一个代理回答了一个问题，而另一个代理悄悄地维护了状态，所有这些都由 Neuro SAN 框架协调。重要的是，我们没有硬编码“如果用户问第二个问题则执行 X”——这一切都源于代理设计。这说明了 **Neuro SAN 声明式多代理框架的强大之处：** 通过指定代理是**什么**以及能做**什么**，系统就能找出**如何**做。
我们鼓励您进一步探索。neuro-san-demos 仓库包含其他示例（例如，一个 airline_policy.hocon 展示了更复杂的多步决策过程，或与外部 API 的集成示例）。玩转任何给定的示例网络，或使用 agent_network_designer 创建您自己的网络。玩得开心！
与其他多代理编排平台的比较
目前有许多多代理框架可用。这些平台的设计理念和功能集各不相同——从 **Neuro SAN** 的数据驱动代理网络到以代码为中心的框架，如 **PydanticAI**、工作流图系统，如 **LangGraph**、企业级解决方案，如 **CrewAI** 和 **Microsoft Autogen**、创新型代理库，如 **Agno**，以及实用 SDK，如 **LiteLLM**。下面，我们将 Neuro-SAN 与 CrewAI、LangGraph、Autogen、Agno、PydanticAI、Agent-Squad、ADK 在核心概念、独特功能、产品特性、可扩展性和性能方面进行比较。文末的总结表重点介绍了哪些平台支持关键功能（数字孪生建模、内存、工具集成、多代理协作、测试、可视化、UI 工具、配置灵活性、自定义工具、插件兼容性等）。
总结
Neuro SAN 是多代理 AI 领域激动人心的发展。通过将数据驱动配置与强大的代理间通信协议相结合，它使各种用户能够创建复杂的 AI 代理网络。正如演示所显示，您不需要编写大量代码即可获得复杂、编排的行为——您可以专注于代理社会的*设计*。凭借 sly_data 用于安全数据处理、集成编码工具和动态网络生成等功能，Neuro SAN 为 AI 解决方案提供了一个**多功能的试验场**。无论您是希望对代理协作进行精细控制的机器学习工程师，还是将 AI 集成到业务工作流中的解决方案架构师，亦或是尝试 AI“社会”未来的学生，Neuro SAN 都提供了一个强大的框架，将您的多代理想法变为现实。我们所演示的实时示例只是冰山一角——有了 Neuro-SAN，编排专业代理的可能性只受限于您的想象力（也许还有您的配置文件大小！）。立即试用 Neuro SAN，体验数据驱动的多代理编排框架如何将您的 AI 应用程序提升到新的水平。今天就试用 Neuro SAN 吧。玩得开心！
参考
GitHub — cognizant-ai-lab/neuro-san-studio: 展示 neuro-san 的基本演示