303: Идеатор/Реактор

Реактор: Особый Idea Transformer, разработанный как универсальная среда исполнения для пошаговых взаимодействий агентов с состоянием. Он принимает состояние игры или процесса (Idea) и создаёт следующее состояние (Idea).
— Глоссарий

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

От специфики покера к протокольному подходу

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

Однако взаимодействие внутри нашей системы всё ещё жёстко привязано к специфической игровой нотации (формату истории рук в покере). Чтобы по-настоящему раскрыть потенциал нашей системы, мы выйдем за рамки этого ограничения.

Основой этого рефакторинга является принятие «Триплета Идеи» в качестве фундаментальной единицы коммуникации. Вместо отправки простого объекта состояния игры, каждое сообщение в системе будет самодостаточным триплетом:

Схема (Schema): JSON-схема, которая даёт универсальное семантическое определение состояния игры. Она не только делает данные самоописываемыми, но и содержит достаточно информации для определения следующего допустимого действия или перехода состояния.
Контекст (Context): Дополнительная информация, такая как правила игры, инструкции для бота или исторические данные, которая влияет на интерпретацию решения.
Решение (Solution): Фактическое состояние игры, соответствующее схеме.

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

Это делает Idea настоящим вычислительным примитивом — строительным блоком для создания сложных, развивающихся систем. В отличие от простого, недолговечного запроса к чат-боту, Idea — это самодостаточный артефакт с состоянием. Он упаковывает input (входные данные), output (solution — решение), правила (schema) и весь context своего создания в единый, переносимый блок. Это не просто вопрос; это вопрос, ответ и полная формула, которая их связывает, что позволяет создать постоянную, компонуемую систему, а не просто разовую транзакцию.

От Скрытого к Явному: Стратегия Кристаллизации

Эта архитектура позволяет использовать мощный подход, при котором игровая логика начинается с гибкого Скрытого Набора Правил (Latent Ruleset) и может постепенно кристаллизоваться в детерминированный Явный Набор Правил (Explicit Ruleset). Система спроектирована так, чтобы по умолчанию работать со Скрытым Набором Правил, рассматривая Явный Набор Правил как мощное, прогрессивное улучшение, а не как обязательное условие.

1. Скрытый Набор Правил

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

Здесь LLM выступает в роли «Универсального Интерпретатора», фактически становясь дилером и судьёй в игре. Она использует Schema и Context из триплета, чтобы понимать правила, проверять действия и грамотно продвигать состояние игры. Набор правил является «скрытым» — он содержится в обширных знаниях LLM и информации, предоставленной в триплете, а не в явном коде. Базовый «универсальный движок» будет минимальным, управляя только рассадкой участников и основной последовательностью ходов. LLM берёт на себя всё остальное, обеспечивая беспрецедентную адаптивность.

2. Явный Набор Правил

Для игр, где у нас есть специальный движок (например, наш существующий покерный движок), система работает в ускоренном, детерминированном режиме. Движок предоставляет Явный Набор Правил, который не заменяет основную функцию триплета, а мощно дополняет её. Он выполняет две основные функции:

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

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

3. От симуляции к спецификации: Новая парадигма разработки

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

Симуляция: Мы предоставляем Реактору триплет, описывающий новую игру (например, домино), даже совершенно новую. LLM, действуя как универсальный интерпретатор, начнёт симулировать игровой процесс.
Генерация: В процессе игры LLM генерирует логи, рассуждения и широкий спектр игровых сценариев.
Спецификация: Затем мы используем эти богатые, симулированные данные как сырьё для написания надёжной, проверенной в деле спецификации и полного набора тестов.

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

Агенты с состоянием и долгосрочная память

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

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

Бизнес-перспективы

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

Быстрое внедрение: Мы можем предложить клиентам возможность интегрировать новые игры и даже сложные бизнес-процессы с минимальными инженерными затратами. Универсальный путь позволяет нам запускать ботов для новой игры в тот момент, когда мы получаем её схему, ещё до реализации специального движка.
Чёткая спецификация: Мы можем предоставить клиентам или сторонним разработчикам чёткий формат спецификации (схему Schema состояния игры), позволяя им создавать новые игровые движки, которые напрямую подключаются к нашей среде исполнения. Наш подход «сначала симуляция» поможет нам и нашим партнёрам создавать эти спецификации быстрее и точнее.
Спецификация как услуга: Для клиентов, которым сложно определить сложные системы (например, программу членства или вознаграждений), мы можем рассматривать их процесс как «игру». Наш Реактор может симулировать процесс, используя Универсальный Путь, помогая им уточнить правила и автоматически создавая надёжную спецификацию и набор тестов. Это решает серьёзную бизнес-проблему и само по себе становится ценной услугой.
Мгновенная функциональность: Наша система может начать запускать ботов для новой игры в тот момент, когда мы получаем её схему, даже до того, как будет реализован специальный движок.

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

Соответствие общему видению

Этот стратегический сдвиг не просто улучшает наш игровой продукт; он объединяет всю нашу линейку продуктов под единым видением. Эта работа является прямым и практическим продолжением нашей цели по созданию децентрализованной, одноранговой сети для идей, как указано в Эдикте Автономности.

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

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

Реактор — это первый из многих подобных микросервисов, преобразующих идеи («Idea-Transformer»). Тот же протокол будет поддерживать компонуемую экосистему сервисов, включая:

Сервис-распознаватель (Resolver), который обогащает Idea, извлекая и встраивая связанные данные из базы данных.
Сервис статистики (Stats), который анализирует Idea и добавляет исторический или статистический контекст.
Сервис валидации (Validation), который проверяет Idea на соответствие набору правил и предоставляет обратную связь для повторных попыток.

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