多智能体系统内部：加密货币开发者的架构笔记

想象这样一家面向企业销售的加密货币公司：它需要能够监控去中心化金融协议、评估流动性、判断智能合约风险、重新平衡资金池、标记异常交易，甚至还能根据预设策略自动执行交易的软件。如果让一个人工智能代理承担所有这些功能，它将会负担过重。它必须在同一个推理循环中读取市场数据、查询区块链基础设施、评估风险、调用API、做出盈利决策并签署交易。要测试、扩展及保障这类系统的安全性，难度会迅速上升。

通常的解决方案是将任务分配给不同的专用智能体，并在之上添加一个协调层。这并非简单的多个语言模型相互对话，而是一种软件架构，其中模型推理、应用逻辑、数据、工具、权限和执行流程都被刻意分开处理。下文将阐述这些组成部分如何协同工作，以及该领域的生产系统构建者应考虑哪些因素。

何为多智能体系统

多个专用智能体共同完成超出单个智能体处理能力的任务：这就是其定义。对于单个智能体，有一个简洁的公式：

智能体 = AI模型 + 指令 + 上下文 + 工具 + 状态 + 执行循环

对于多个智能体组成的群体，则需要在之上再叠加一层：

智能体 + 协调机制 + 共享状态 + 通信机制 + 规则策略

一个财富管理平台可能包含以下这些组件：

1. 负责收集协议和市场数据的研究代理。
2. 负责评估合约、流动性及协议风险的风险代理。
3. 负责比较各种投资机会并计算资产分配比例的投资组合代理。
4. 负责执行公司业务规则合规性的合规代理。
5. 负责准备并提交交易请求的执行代理。
6. 负责确认链上实际发生情况的监控代理。

以如下指令为例：将50,000美元的USDC投入当前最安全的收益项目，前提是该协议符合风险政策且交易执行成本低于0.5%。由于这需要多种不同的技能，系统会将其拆分为一系列流程步骤来处理：

```text
User Request
     ↓
Orchestrator
     ↓
Research Agent
     ↓
Risk Agent
     ↓
Portfolio Agent
     ↓
Policy Check
     ↓
Execution Agent
     ↓
Blockchain
     ↓
Verification
```

每个智能体只处理一个小问题，无需解决整个工作流程。

生产系统的层次结构

有七个组成部分反复出现：智能体运行时环境、协调器、共享状态、工具层、策略与安全层、执行基础设施以及可观测性模块。每个部分都对应一个特定的工程问题。

智能体运行时环境

运行时环境用于启动一个智能体。在实际生产环境中，智能体并非简单的输入提示与输出响应的关系，它的运行方式更像是一个循环：

  ```text
Input
 ↓
Build Context
 ↓
Ask Model to Reason
 ↓
Choose Action
 ↓
Call Tool / Agent / Return Result
 ↓
Receive Result
 ↓
Update Context
 ↓
Reason Again
```

假设某研究人员被要求比较去中心化金融借贷协议，它会先获取这些协议的列表，查询其当前的总价值锁定金额，了解借贷利率，比较流动性状况，选出最优方案后交给风险评估人员。模型负责提供推理过程，而围绕它的应用程序则控制实际执行操作。明确这种分工很重要，因为模型不应承担普通软件能更高效完成的任务。将50,000美元乘以8.2%这一操作根本不需要大型语言模型，因为普通函数就能更快、更便宜地得出相同结果。

协调器

协调器相当于控制中心，它负责决定由哪个智能体执行任务、向该智能体传递什么指令、下一步该执行什么操作、哪些任务可以并行处理、工作何时完成，以及当某个智能体出现故障时该如何处理。协调器主要有两种实现方式。

模型驱动的编排。 一个监控模型会挑选出它所需的专用模型。

           ```text
        Supervisor Agent
              │
        ┌─────┼─────┐
        ▼     ▼     ▼
   Research  Risk  Analytics
```

监管方可能会认为首先需要协议数据，于是它会调用研究代理；一旦得到结果后，又会判断需要安全评估，进而调用风险代理。这种方式虽然灵活，但路由可能会变得不可预测，额外的模型调用也会不断增加，成本随之上升。

代码驱动的编排。应用程序负责确定执行顺序。

```text
Research
   ↓
Risk Analysis
   ↓
Policy Check
   ↓
Simulation
   ↓
Approval
   ↓
Execution
```

这个版本更易于测试和管控。

两种方式的结合。对于B2B金融产品，最有效的方案往往是将两者结合使用：让模型做出判断，同时让代码执行规则。模型可能会认为协议A能带来最佳的风险调整后收益，而应用程序则坚持要求任何超过50,000美元的金额都需要进一步审批。由人工智能提出建议，再由软件来强制执行。

共享状态

各处理单元需要了解之前步骤的成果。将整个对话内容同步给每个单元会浪费精力，因此系统会以结构化的方式记录工作流程。

对于USDC的请求，该记录会包含资产类型（USDC）、金额（50000）、区块链网络（Ethereum）、候选协议列表（Aave和Morpho），以及三个状态字段（风险、政策与执行状态），初始值分别为待处理、待处理和未开始。

研究代理负责填写候选协议、产出结果以及市场数据等字段。风险代理则会添加评分及其安全检测结果。执行代理仅能看到完成工作所需的信息。整体结构十分清晰：

               ```text
                Shared State
                    │
         ┌──────────┼──────────┐
         ▼          ▼          ▼
    Research      Risk     Execution
     Agent        Agent     Agent
        └──────────┼──────────┘
                   ▼
             Updated State
```

共享记录还能让工作流更易于暂停、恢复、审计和调试。

沟通：交接与代理作为工具

代理可以通过两种方式协同工作。在交接过程中，控制权会从一名代理传递给另一名代理。

```text
Research Agent
↓
Risk Agent
↓
Portfolio Agent
```

交接适用于责任转移的时刻：市场调研完成后，风险评估人员负责对候选对象进行评估。当某位评估人员被用作工具时，会由一位评估人员调用另一位并保持控制权。

     ```text
      Supervisor
      /    |   \
 Research Risk Analytics
```

主管可以要求风险评估人员根据公司的标准对相关协议进行测试，从而获得结构化的答复并继续推进工作。当一名核心人员需要整合多份专业意见时，这种方式尤为有用。

工具层

单个评估人员无法直接操作区块链或数据库。工具起到了连接作用。加密资产评估人员可以通过诸如 get_balance()、read_contract()、estimate_gas()、simulate_transaction() 和 submit_transaction() 这样的接口，使用区块链 RPC、市场数据 API、去中心化交易所聚合器、索引工具、风险数据库、钱包基础设施以及内部资金管理系统等资源。

应为每个智能体授予其完成工作所必需的最小权限。研究型智能体可能仅需read_market_data()和read_protocol_data()功能；执行型智能体则可拥有simulate_transaction()和submit_transaction()功能。没有理由将钱包或交易权限授予所有智能体，严格的权限控制能在某个智能体行为不当或被攻破时限制损失。

AI与区块链之间的界限

这或许是加密货币产品中最重要的设计要点。模型输出具有概率性，而区块链上的操作则是确定性的，且往往无法撤销。因此，任何智能体都不应直接控制最终交易。更安全的处理方式如下：

```text
Agent Decision
     ↓
Schema Validation
     ↓
Policy Check
     ↓
Risk Check
     ↓
Transaction Simulation
     ↓
Authorization
     ↓
  Signing
     ↓
Blockchain
```

假设该代理决定将50,000美元的USDC兑换成ETH。执行层应独立检查USDC是否为已批准的资产、ETH是否为已批准的目标资产、交易金额是否在用户的限额范围内、滑点是否可接受、接收方是否正确、交易模拟结果是否正常，以及用户是否需要确认。代理提出操作建议后，确定性层会判断该操作是否可行。金融系统正是建立在这样的分工之上的。

约束机制与故障处理

应对每一个AI决策设置确定性限制。配置文件中可能会规定：最高交易金额50,000美元，最高滑点0.5%，最低流动性500万美元，允许使用的链为Ethereum、Arbitrum和Base。模型无法通过改变表述方式来绕过这些数值限制。

请记住，合理的结构并不能证明内容是正确的。{"risk_score": 0.04}这样的输出虽然格式完美，但其背后的推理可能完全错误。生产系统应当检查格式、业务规则、数据的新鲜度、数据来源的可靠性，以及最终工具调用的结果：

```text
Agent Output
     ↓
Schema Validation
     ↓
Business Validation
    ↓
Data Validation
    ↓
Tool Execution
    ↓
Result Verification
```

幂等性。假设某次提交操作超时了。代理程序可能会判定该交易失败并尝试再次提交，但实际上第一次尝试可能已经成功，这样就会导致同一笔金融操作被重复处理。执行服务应为每个请求分配一个唯一的标识符，比如exec_829192，并将其与最终产生的交易关联起来。如果相同的请求再次出现，服务会直接返回之前的处理结果，而不会再次提交新数据。在金融业务流程中，这一特性是不可或缺的。

可观测性

对于智能体系统而言，单纯的日志记录远远不够，因为工程师需要了解完整的决策路径。对于每一个步骤，都需要记录是哪个智能体执行的、它使用了哪种模型、调用了哪些工具及参数是什么、得到了什么反馈、触发了哪些策略、每个步骤耗时多久，以及最终哪笔交易被发出。当交易失败时，应当能够明确是谁做出了决策、基于什么数据、哪项策略批准了该交易、交易是如何构建的，以及链上实际发生了什么。如果没有这样的透明度，将这些系统投入生产就只能靠猜测。

在核心功能之外，生产环境部署还必须包含身份与访问控制、密钥管理、状态存储、流量限制、监控功能、性能评估以及审计追踪机制。演示版本通常不会展示这些内容，但它们决定了该系统是否能在企业级规模上正常运行。

内置大语言模型的分布式系统

要认清这一挑战，最直接的方法就是停止将多智能体系统视为一堆聊天机器人。它其实是一个分布式系统，某些决策是由模型以概率方式做出的，因此所有传统问题依然存在：状态管理、身份认证、权限控制、并发处理、重试机制、幂等性、故障恢复、数据验证以及可观测性。

模型负责推理，而架构则承担控制功能。当涉及真实资产和不可逆交易时，这种差异就显得极为重要。一个设计良好的系统不会追求无限制的自主性，而是追求受控的自主性：智能体可以自由地进行推理、协作和适应，而确定性软件则负责处理权限、财务限制、数据验证及执行流程。

核心要点

关键不在于拥有多个模型，而在于将复杂的工作流程拆解为更小、更专业的可控制单元。对于B2B加密货币而言，这一原则可以明确表述为：

• 推理功能由智能体承担。
• 数据检索与操作由工具负责。
• 协调工作由调度器完成。
• 业务规则通过策略来强制执行。
• 交易会经过执行层进行处理并加以控制。
• 最终结算在区块链上完成。

一旦这些职责被明确划分，系统就更容易扩展、测试、保障安全并进行审计。其目标并非让人工智能显得聪明，而是让复杂的AI驱动型工作流程具备足够的可靠性，从而可用于实际生产环境。