001: Агент/Запрос

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

Контекст: Конвейер Сообщений

Основой Запроса является его контекст: массив объектов Message. Каждый Message — это простая структура, содержащая role (например, "system", "user" или "assistant") и content. Эта структура позволяет представить LLM насыщенный, многоэтапный диалог.

В отличие от типичной чат-модели, где сообщения постоянно добавляются в растущую историю, контекст для каждого Запроса — это полностью управляемый, автономный пакет. Он тщательно создается для конкретной задачи и не "загрязняется" предыдущими, не связанными с ней взаимодействиями. Ответы LLM не добавляются обратно автоматически; контекст пересоздается для каждого нового вычисления. Это гарантирует воспроизводимость процесса и то, что LLM имеет именно ту информацию, которая ей нужна, без риска усечения контекста или "забывания" важных деталей.

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

Простой массив Message может выглядеть так:

[
  { "role": "system", "content": "Вы — полезный ассистент." },
  { "role": "user", "content": "Какая столица Франции?" }
]

Система расширяет эту базовую структуру Message, позволяя полю content содержать не только текст, но и специализированные объекты, называемые пользовательскими типами контента. Например, вместо строки, контент сообщения может быть структурированным объектом, таким как { "type": "input", "input": { ... } }.

Эта возможность делает контекст основной точкой расширения в системе.

Каждый пользовательский тип контента регистрируется с обработчиком, и эти обработчики образуют конвейер обработки. Перед отправкой Запроса в LLM, конвейер обрабатывает каждое сообщение в контексте. Обработчик сообщения может динамически изменять основные компоненты Запроса:

• Конфигурация LLM: Настройка таких параметров, как модель, температура или другие опции.
• Схема: Изменение JSON-схемы, которой должен соответствовать конечный вывод.
• Контекст: Изменение итогового списка сообщений, которые будут отправлены в LLM, например, путем преобразования пользовательского типа в текстовое представление или добавления новых сообщений.

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

Схема: Направляя Решение

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

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

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

Исполнение и Решение

После обработки контекста итоговый массив сообщений и схема отправляются в LLM одним запросом. Ответ LLM — это решение — структурированный документ в формате JSON, который строго соответствует предоставленной схеме.

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

Например, если схема сначала требует поле для мета-рассуждений (например, "thought_process"), а затем поле для конечных данных, LLM вынуждена сначала сформулировать свои рассуждения, прежде чем выдать ответ. Первоначальное рассуждение становится частью контекста, который влияет на генерацию последующих данных. Этот мощный механизм позволяет нам направлять мышление LLM, давая нам значительный контроль над конечным результатом, формируя сам путь, по которому она к нему приходит.

От Структурированного Вывода к Действенным Выборам

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

Следующий документ, 002: Агент/Инструмент, представляет протокол для определения этих возможностей.