Внутри многопроцессорной системы: заметки по архитектуре для создателей криптовалют

Представьте криптовалютную компанию, которая продает свои услуги бизнесу и нуждается в программном обеспечении, способном отслеживать протоколы DeFi, оценивать ликвидность, анализировать риски смарт-контрактов, корректировать структуру казны, выявлять необычные транзакции и даже выполнять сделки в соответствии с заранее установленными правилами. Один искусственный интеллект, обладающий всеми этими функциями, быстро оказывается перегруженным. Ему приходится анализировать рыночные данные, запрашивать информацию из инфраструктуры блокчейна, оценивать риски, вызывать API, принимать решения о заработке денег и подписывать транзакции — всё это в рамках одного цикла обработки информации. Тестирование, масштабирование и обеспечение безопасности подобного решения очень быстро становятся сложной задачей.

Обычный ответ заключается в разделении работы между специализированными агентами и добавлении слоя оркестрации сверху. Это не просто несколько языковых моделей, общающихся друг с другом. Речь идет о программной архитектуре, в которой рассуждения моделей, логика приложения, данные, инструменты, разрешения и процесс выполнения намеренно разделены. Далее рассматривается, как все эти компоненты взаимодействуют, и что следует учитывать при создании производственных систем в этой области.

Что считается многопроцессорной системой

Несколько специализированных агентов, сотрудничающих над задачей, которую ни один из них не может выполнить в одиночку — вот таково определение. Удобная формула для отдельного агента:

Агент = ИИ-модель + инструкции + контекст + инструменты + состояние + цикл выполнения

Для группы добавляется второй уровень:

Агенты + оркестрация + общее состояние + коммуникация + правила

Платформа для управления капиталом может включать в себя следующие компоненты:

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
```

Предположим, от исследовательского агента требуется сравнить протоколы кредитования в сфере DeFi. Он соберёт список таких протоколов, получит информацию о их текущем TVL, узнает ставки кредитования, проанализирует уровень ликвидности, выберет наиболее подходящие варианты и передаст их агенту по управлению рисками. Модель обеспечивает логику принятия решений, в то время как приложение, окружающее её, контролирует то, что фактически выполняется. Это разделение важно, поскольку модель не должна выполнять задачи, которые лучше справляется обычное программное обеспечение. Для умножения суммы в 50 000 долларов на 8,2% не требуется использование LLM, поскольку обычная функция работает быстрее, дешевле и всегда даёт одинаковый результат.

Оркестратор

Оркестратор является центром управления. Он определяет, какой агент будет выполнять задачу, какие инструкции ему передать, что будет выполняться далее, какие задачи могут выполняться параллельно, когда работа будет завершена и что делать в случае сбоя агента. Существует два основных стиля работы оркестратора.

Оркестрация на основе моделей. Управляющая модель выбирает необходимого специалиста.

           ```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) и три поля статуса (риск, политика и выполнение), начинающиеся со значений pending, pending и not started соответственно.

Агент исследований заполняет такие поля, как протоколы кандидатов, результаты эффективности и рыночные данные. Агент оценки добавляет оценку и свои выводы по вопросам безопасности. Агент выполнения видит только то, что необходимо для выполнения его задачи. Структура остаётся чёткой:

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

Общая запись также значительно упрощает приостановку, возобновление, аудит и отладку рабочего процесса.

Коммуникация: передача задач и агенты как инструменты

Агенты сотрудничают двумя полезными способами. При передаче задачи контроль переходит от одного агента к другому.

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

Передача ответственности уместна в моменты смены обязанностей: по завершении исследования рынка оценкой кандидатов занимается специалист по рискам. Когда агент используется как инструмент, один агент вызывает другого и сохраняет контроль.

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

Руководитель может попросить специалиста по рискам протестировать протокол с учётом критериев компании, получить структурированный ответ и продолжить работу. Это полезно, когда одному центральному специалисту необходимо объединить мнения нескольких экспертов.

Слой инструментов

Специалист не может самостоятельно взаимодействовать с блокчейном или базой данных. Инструменты служат связующим звеном. Специалисту по криптовалютам могут быть предоставлены интерфейсы RPC для блокчейна, API с рыночными данными, агрегаторы DEX, индексаторы, базы данных рисков, инфраструктура кошельков и внутренние системы управления финансами, доступные через такие операции, как get_balance(), read_contract(), estimate_gas(), simulate_transaction() и submit_transaction().

Предоставьте каждому агенту минимальные права, необходимые для выполнения его функций. Агенту для исследований может хватить только функций read_market_data() и read_protocol_data(). Агенту для выполнения операций могут понадобиться функции simulate_transaction() и submit_transaction(). Нет никаких оснований предоставлять каждому агенту права на управление кошельком или транзакциями, а ограниченные полномочия снижают риски в случае неправильного поведения или компрометации агента.

Граница между ИИ и блокчейном

Это, возможно, самый важный аспект проектирования криптовалютных продуктов. Результаты работы модели имеют вероятностный характер, тогда как выполнение операций в блокчейне является детерминированным и зачастую не подлежит отмене. Поэтому ни один агент не должен напрямую контролировать окончательную транзакцию. Более безопасный подход выглядит следующим образом:

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

Представьте, что агент решает обменять 50 000 USDC на ETH. Слой выполнения должен независимо проверить, является ли USDC одобренным активом, а ETH — одобренным пунктом назначения, не превышает ли сумма лимит пользователя, является ли допустимым смещение цены, верен ли получатель, проходит ли транзакция без ошибок и требуется ли подтверждение от пользователя. Агент предлагает действие, а детерминистический слой решает, можно ли его выполнить. Финансовые системы основаны на таком разделении функций.

Ограничения и обработка сбоев

Каждое решение ИИ должно соответствовать установленным детерминистическим ограничениям. В конфигурации может быть указано: максимальная сумма транзакции — 50 000 долларов, максимальное смещение цены — 0,5%, минимальный уровень ликвидности — 5 млн долларов, разрешенные сети — Ethereum, Arbitrum и Base. Модель не может обойти эти ограничения, изменив формулировку ответа.

Также помните, что наличие корректной структуры не является доказательством правильности содержимого. Результат вида {"risk_score": 0.04} может быть совершенно правильно сформирован, но основываться на полностью ошибочных рассуждениях. Система обработки данных должна проверять формат, бизнес-правила, актуальность данных, надежность источников, а также результаты вызовов финальных инструментов:

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

Идемпотентность. Рассмотрим ситуацию, когда отправка данных завершается из-за истечения времени. Агент может решить, что транзакция провалилась, и попытаться снова, однако первая попытка могла уже быть успешной, что приведёт к дублированию финансовой операции. Служба выполнения должна присваивать каждому запросу уникальный идентификатор, например exec_829192, и связывать его с соответствующей транзакцией. Если тот же запрос поступает снова, служба возвращает уже существующий результат и не отправляет ничего нового. В финансовых рабочих процессах эта характеристика является обязательной.

Наблюдаемость

Обычные логи недостаточны для систем агентов, поскольку инженерам необходим полный путь принятия решений. Для каждого шага необходимо фиксировать, какой агент его выполнил, какую модель он использовал, какие инструменты с какими параметрами были вызваны, что было получено в ответ, какие правила были применены, сколько времени занял каждый шаг и какая транзакция в итоге была отправлена. При сбое транзакции необходимо иметь возможность определить, кто принял решение, на основе каких данных, какое правило её одобрило, как была сформирована транзакция и что на самом деле произошло в сети. Без такой степени прозрачности работа этих систем в производственных условиях превращается в угадывание.

Помимо основных компонентов, в производственной версии необходимо добавить механизмы управления идентификацией и доступом, хранение ключей, систему для сохранения состояния, ограничение нагрузки, мониторинг, тестирование и журнал аудита. Демо-версии никогда не показывают этих элементов, однако именно они определяют, сможет ли решение работать в масштабах крупных предприятий.

Распределённые системы с встроенными LLM

Самый ясный способ увидеть эту проблему — это перестать рассматривать многокомпонентную систему как совокупность чат-ботов. Это распределённая система, в которой некоторые решения принимаются вероятностным образом с помощью модели, поэтому все классические вопросы по-прежнему актуальны: управление состоянием, аутентификация, авторизация, конкурентность, повторные попытки, идемпотентность, восстановление после сбоев, проверка данных и возможность наблюдения за процессами.

Модель выполняет функцию слоя рассуждений, а архитектура — слоя управления. Когда на кону стоят реальные активы и необратимые транзакции, эта разница имеет огромное значение. Хорошо спроектированная система не стремится к неограниченной автономии; она стремится к контролируемой автономии: агенты могут свободно рассуждать, сотрудничать и адаптироваться, в то время как детерминистский программный код отвечает за разрешения, финансовые ограничения, проверку данных и выполнение операций.

Вывод

Секрет не в наличии нескольких моделей, а в разбиении сложных рабочих процессов на меньшие, специализированные элементы, которые можно контролировать. Для B2B-криптовалют этот принцип можно сформулировать просто:

• Логические решения принимают агенты.
• Загрузка данных и выполнение операций — задача инструментов.
• Координация осуществляется оркестратором.
• Бизнес-правила реализуются с помощью политик.
• Транзакции проходят через слой выполнения, который их контролирует.
• Окончательное урегулирование происходит непосредственно в блокчейне.

Когда эти функции разделены, систему легче масштабировать, тестировать, защищать и аудитировать. Цель не в том, чтобы сделать ИИ кажущимся умным, а в том, чтобы сделать сложные рабочие процессы, основанные на ИИ, достаточно надежными для промышленного использования.