103: Концепция/Идеатор

Введение

Этот документ описывает протокол для Идеаторов и Трансформеров Идей как исполняемых компонентов на основе сервисов. Он основан на фундаментальном документе 101: Концепция/Идея, который определяет основную структуру данных, и описывает, как Idea преобразуется в функциональную, вызываемую сущность.

Подробнее о различных моделях хостинга и развертывания читайте в 102: Концепция/Суверенитет.

От Идеи к Идеатору

Идеатор — это не отдельная сущность, а функциональная роль, которую может выполнять любая Idea. Его можно рассматривать как функцию, которая выполняет работу, преобразуя входные данные в выходные в скрытом пространстве. Это означает, что его логика не обязательно определяется явным кодом, а вместо этого основана на богатом context самой Idea — её схемах, примерах и инструкциях на естественном языке, которые интерпретируются LLM.

Главный признак того, что Idea является Идеатором — это наличие в context сообщения с type: "input". Это сообщение определяет схему данных, которые ожидает Идеатор. Исполняемый Идеатор может также включать сообщение в context с type: "code", указывающее на явную реализацию.

Трансформер Идей: Частный случай

Распространенный и мощный паттерн — это Идеатор, входными данными для которого является другая Idea. Мы называем этот специфический тип Идеатора Трансформером Идей. Именно это позволяет создавать композиционные конвейеры, в которых Идеи связываются в цепочки и развиваются.

Реализации и Композиция

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

Множество реализаций

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

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

Композиция и Системы Высшего Порядка

В этой экосистеме нет понятия «приватного API». Все сервисы созданы для взаимодействия через их публичные, основанные на контрактах интерфейсы.

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

Например, система Реактор — это Ideator высшего порядка. Для управления игрой она может:

1. Принять Idea состояния игры через свой публичный API.
2. Внутренне вызвать публичный сервис Player для создания и управления идентификаторами игроков.
3. Вызвать публичный сервис Storage для записи истории игры.
4. Вернуть новую Idea состояния игры через свой публичный API.

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