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

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

Реализация через Действие

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

Это Действие-делегат получает три стандартных аргумента:

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

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

Проблема: Громоздкие инструменты и «смешение контекста»

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

1. Слишком большие схемы: У языковых моделей (LLM) есть предел того, сколько информации они могут обработать за раз. Если сложить много сложных Инструментов вместе, модель может запутаться и не сможет правильно выбрать нужный вариант.
2. Смешение контекста: Когда все Инструменты находятся в одной «комнате», языковую модель может сбить с толку лишняя информация. В итоге она может выбрать не тот Инструмент или неправильно его настроить.
3. Сложно использовать повторно: Инструмент, созданный для одного агента, нельзя просто так взять и отдать другому. Придётся тащить за собой всю его «комнату» с настройками.

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

Как вызвать делегата

Чтобы поручить выполнение задачи делегату, нужно в схеме Инструмента добавить свойство _delegate. Это свойство — как записка для системы, которая говорит: «Эту команду нужно выполнять не здесь, а передать внешнему исполнителю».

Свойство _delegate — это просто текст (string), и его можно использовать двумя способами:

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

  Указать на сохранённый Запрос: В тексте можно написать путь или интернет-адрес файла (JSON), который описывает отдельный Запрос. Представь, что это подробная инструкция для другой команды. Так один Инструмент может поручить свою работу совершенно другой, независимой инструкции.

• Создать анонимного делегата: Если написать специальное слово 'anonymous', то будет создан «анонимный» делегат. Это полезно, когда нужно быстро создать чистое, изолированное место для выполнения Вызова Инструмента, не создавая для этого отдельного файла с инструкциями. Система автоматически создаст для этого Вызова новую, пустую «комнату».

Выполнение в изолированном пространстве

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

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

Работа с большими схемами

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

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

Стратегии обработки делегатов

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

1. Обработка во время выполнения (по умолчанию)

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

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

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

Процесс выглядит так:

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

2. Предварительная обработка (опционально)

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

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

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

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

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

От Делегирования к Ограниченным контекстам

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