013: Агент/Делегат

Паттерн Делегирования решает критическую задачу масштабирования и композиции возможностей агентов. Он предоставляет мощный механизм для выполнения Инструментов в изолированных средах («песочницах»), предотвращая смешение контекстов и обеспечивая настоящую переиспользуемость. Делегируя Вызов внешнему делегату — будь то определение другого Запроса или Активность в подзапросе — система может создавать сложное агентное поведение из автономных, независимо разработанных компонентов.

Реализация как Активность

Концептуально, делегирование — это не новый или отдельный протокол, а мощное применение существующей системы Активностей. Выполнение делегата обрабатывается специальной, универсальной «всеобъемлющей» Активностью, которая регистрируется системой для обработки любого Вызова, содержащего свойство _delegate.

Эта Активность Делегирования получает три стандартных аргумента:

• call: Полный объект вызова, включая параметры, предназначенные для подзапроса.
• tool: Схема инструмента, из которой активность считывает свойство _delegate, чтобы знать, что вызывать.
• context: Массив сообщений, ограниченных из родительского контекста, которые будут перенаправлены в подзапрос.

Логика активности проста: она использует эти три аргумента для сборки и выполнения нового, изолированного Запроса. Эта элегантная реализация демонстрирует мощь основных протоколов: благодаря надежности сигнатуры Activity, даже сложные паттерны, такие как делегирование, могут быть построены поверх нее как стандартная реализация, не требуя нового набора правил.

Проблема: Монолитные инструменты и смешение контекстов

По мере роста возможностей агентов, определение всех Инструментов в едином, монолитном контексте становится непрактичным.

1. Большие схемы: У LLM есть практические ограничения на сложность схем, которые они могут обработать в одном запросе. Объединение множества сложных Инструментов может превысить эти лимиты, мешая LLM правильно обработать доступные опции.
2. Смешение контекстов: Когда все Инструменты работают в одном контексте, LLM может подвергаться влиянию нерелевантной информации, что приводит к неправильному выбору Инструмента или заполнению параметров.
3. Отсутствие переиспользуемости: Инструмент, определенный для одного агента, нелегко перенести к другому, не захватив с собой весь его контекст.

Делегирование решает эти проблемы, вводя Делегированную Изоляцию — способ делегировать Вызов внешней, изолированной среде выполнения.

Вызов Делегата

Делегированное выполнение обозначается свойством _delegate в схеме Инструмента. Это свойство указывает системе рассматривать Вызов не как встроенную операцию, а как запрос к внешнему делегату.

Свойство _delegate — это string и может использоваться двумя способами:

• Сохраненный, переиспользуемый Запрос — это наиболее распространенная форма Идеи. Паттерн Делегирования — это основной механизм для композиции этих Идей в более сложные системы. Подробнее см. в 101: Концепция/Идея.

  Ссылка на сохраненный Запрос: Строка может быть путем или URL-адресом к JSON-файлу, который определяет автономный Запрос — JSON-объект, содержащий свойства context и schema. Это позволяет Инструменту делегировать свое выполнение совершенно отдельному набору инструкций.

• Создание анонимного делегата: Строковый литерал 'anonymous' обозначает анонимного делегата. Это используется для создания свежей, изолированной среды выполнения для Вызова Инструмента (скрытого или явного) без необходимости в промежуточном JSON-файле. Он автоматически создает новый, пустой контекст для Вызова.

Выполнение в изолированной среде

Делегат предоставляет «чистую комнату» для выполнения. Вместо выполнения в оживленном контексте родительского агента, Вызов обрабатывается в новой, автономной сессии. Контекст для этого подзапроса тщательно конструируется, а не наследуется.

Здесь Ограниченный контекст становится критически важным. Свойство _scopes в схеме Инструмента действует как мост, явно объявляя, какие части родительского контекста должны быть «импортированы» в выделенное рабочее пространство делегата. Это дает родительскому агенту точный контроль над тем, что может видеть делегат, предотвращая смешение контекстов и обеспечивая настоящую инкапсуляцию.

Обработка больших схем

Делегирование также предлагает решение для управления Инструментами с очень большими или сложными схемами вывода. Вместо включения массивной схемы _output в основной запрос — что потенциально может вытеснить другие инструменты — Инструмент может быть определен только с его параметрами input и указателем _delegate.

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

Стратегии разрешения делегатов

Инструмент становится Делегатом, просто включив свойство _delegate в свою схему. Это сигнализирует о том, что Вызов должен быть делегирован. Ключевой вопрос — когда это делегирование разрешается. Система поддерживает две стратегии, позволяющие найти компромисс между строгой безопасностью и динамической гибкостью.

1. Разрешение во время выполнения (по умолчанию)

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

Этот метод открывает мощную парадигму, невозможную в традиционном коде: LLM действует как интеллектуальный «клей». Агент может сгенерировать Вызов с параметрами, которые не идеально соответствуют ожидаемой input схеме делегата. Во время выполнения система собирает контекст делегата и предоставленные вызывающей стороной входные данные, и задачей LLM в подзапросе становится преодоление этого разрыва.

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

Процесс выглядит следующим образом:

1. Агент генерирует Вызов к модульному Инструменту.
2. Исполнитель видит свойство _delegate и инициирует процесс делегирования.
3. Сборка контекста: Исполнитель получает файл определения делегата (если он не анонимный) и собирает базовый контекст. Затем он использует _scopes для добавления контекста вызывающей стороны.
4. Сопоставление ввода: params из Вызова упаковываются в Входное Сообщение и добавляются в контекст. Именно здесь вступает в игру «клеящая» способность LLM, так как она будет использовать эти входные данные для выполнения логики делегата, даже если схемы не совпадают идеально.
5. Выполнение: Создается новый, изолированный Запрос с объединенным контекстом. Результат возвращается как вывод исходного Вызова.

2. Заранее разрешение (опционально)

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

В этом режиме система предварительно загружает определение Запроса делегата и объединяет его input схему со схемой параметров Инструмента. Это позволяет LLM агента видеть точные требования делегата с самого начала, гарантируя, что сгенерированный Вызов будет идеально сформирован и типобезопасен. Важно отметить, что это предварительное слияние может также включать _output схему делегата, обеспечивая строгий контракт для ожидаемого результата.

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

// ВЫЗОВ, СГЕНЕРИРОВАННЫЙ ОРКЕСТРАТОРОМ
{
  "_tool": "sendMessage",
  "_delegate": "http://example.com/agents/speaker_EN",
  "userId": "u_123",
  "text": "Hello, world!"
}

// ИТОГОВЫЙ КОНТЕКСТ ДЛЯ ПОДЗАПРОСА
[
  {
    "type": "system",
    "message": "Вы — эксперт по обмену сообщениями на английском языке."
  },
  {
    "type": "input",
    // Это необработанные входные данные, предоставленные вызывающим агентом.
    "input": {
      "userId": "u_123",
      "text": "Hello, world!"
    },
    // Это ожидаемый формат входных данных для делегата
    "schema": {
      "type": "object",
      "properties": {
        "recipientId": { "type": "string" },
        "messageBody": { "type": "string" }
      }
    }
  }
]

От делегирования к областям видимости

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