EnRuУпрощ. EnУпрощ. Ru
Черновики

Глава 2: Инструкции — Рецепты для Действий

Новые идеи в этой главе

  • Инструкции как исполняемые рецепты: Мы представляем Vibe типа Instruction — многоразовую JSON Schema, которая служит как готовый к действию рецепт для любой задачи, от простых правок до сложных рабочих процессов.
  • Три режима композиции: Инструкции можно комбинировать тремя способами: неявно (влияние через контекст), через слияние (объединение в один вызов LLM) и последовательно (как конвейер для зависимых шагов).
  • Соглашения об именах, учитывающие контекст: Мы устанавливаем соглашение об именах (_Activity, _Human, _Mixin), которое однозначно указывает системе, где выполнять логику (в LLM, на сервере или с участием пользователя), без необходимости изучать её реализацию.
  • Адаптер LaunchProcess: Универсальная Инструкция, которая служит мостом к сложным, хранящим состояние Vibe'ам типа Process. Она позволяет легковесным Vessel'ам запускать длительные процессы, не управляя их сложностью.
  • Встроенные метрики и "мыслительные" шаги: Соглашение об использовании префиксов $ и _ в схемах позволяет Инструкциям встраивать собственные метрики и "шаги размышления", делая их самоконтролирующимися и прозрачными.

Чертеж того, "Как" делать

В системе, которая может создавать, изменять и развивать любую информацию, возникает ключевой вопрос: откуда она знает, как выполнить ту или иную задачу? Ответ кроется в новом, первоклассном типе Vibe: Instruction.

Instruction — это структурированный, многоразовый "рецепт" для действия. Он представляет собой понятное, готовое к использованию руководство для управления широким спектром операций. Будь то создание нового контента, редактирование существующего решения, развитие основной схемы (schema) Vibe или даже определение нового личного инструмента — Instruction предоставляет стратегический план "как это сделать".

Инструкции — это двигатель для всего, от простых правок до сложных, многошаговых задач. Это форма явного руководства, которая позволяет фиксировать, версионировать, передавать и со временем улучшать операционные знания системы.

Алиса: "То есть Instruction не привязана к одной конкретной кнопке? Это скорее набор чертежей, который можно дать разным исполнителям для разных задач — например, построить новую стену или просто перекрасить существующую?" Боб: "Именно. Это формальное, многоразовое руководство о том, 'как' что-то делать. Его можно использовать для выполнения разовой задачи, или Vessel может принять его как личный инструмент — любимый приём, который можно использовать снова и снова."

Какова основная роль Vibe типа Instruction в системе?
* [x] Предоставлять структурированное, готовое к действию руководство о том, *как* должна выполняться операция `refine`.
* [x] Отделять метод изменения от разрешения на это изменение.
* [ ] Предоставлять разрешение на выполнение операции `refine`.
* [ ] Хранить ресурсы или бюджет, необходимые для задачи.
* [ ] Служить целью операции `refine`.

От данных к действию: техническая основа

Прежде чем углубляться в то, как ведут себя Инструкции, важно понять, чем они являются на техническом уровне. Instruction — это инструмент или возможность, доступная для Vessel'ов и LLM, а её определение — это JSON Schema.

Эта концепция полностью аналогична тому, как в индустрии ИИ определяют "инструменты" или "функции" для больших языковых моделей (часто называемые "LLM Tools" или "function calling"). Если вы знакомы с тем, как LLM вызывают внешние функции через описания в JSON Schema, вы уже хорошо понимаете, что такое Instruction в своей основе.

Схема Инструкции (Instruction Schema) выступает в роли контракта для инструмента, подробно описывая:

  • Что делает инструмент: Неявно через его имя и описание (часто являющиеся частью метаданных схемы).
  • Какие параметры он принимает: Поля для ввода, определённые в JSON Schema.
  • Структуру ожидаемого вывода: Как будет выглядеть результат работы инструмента, что также определяется в JSON Schema.

Проводя параллель с концепциями из Главы 1, сама схема Инструкции — это "уравнение". Когда LLM решает использовать эту Инструкцию на основе текущего взаимодействия (его input), то заполнение полей Инструкции конкретными значениями похоже на нахождение "решения" этого уравнения. Эта "заполненная форма" — готовый JSON-объект, соответствующий схеме Инструкции — становится конкретным solution (решением) или спецификацией для данного вызова инструмента.

Типы инструкций и соглашения об именах

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

  1. Стандартные инструкции (например, CreateBlogPost, GenerateImage):

    • Без специального суффикса
    • По умолчанию выполняются в контексте LLM
    • Самодостаточные инструменты, выполняющие конкретные задачи
    • Если в их схеме есть свойство output, они становятся блокирующими вызовами к серверу, которые возвращают данные

  2. Инструкции-действия (Activity) (например, FetchData_Activity, SendEmail_Activity):

    • Суффикс: _Activity
    • Выполняются на сервере
    • Обрабатывают операции, требующие внешних ресурсов или сервисов
    • Обычно работают в паре с инструкцией для подготовки параметров (без суффикса), которая выполняется в контексте LLM

  3. Инструкции для человека (Human) (например, ConfirmAction_Human, ProvideInput_Human):

    • Суффикс: _Human
    • Требуют взаимодействия с пользователем
    • Приостанавливают выполнение до тех пор, пока пользователь не введёт данные или не примет решение

  4. Инструкции-примеси (Mixin) (например, Introspect_Mixin, Validate_Mixin):

    • Суффикс: _Mixin
    • Сливаются со своей целевой инструкцией
    • Дополняют или изменяют поведение других инструкций

Детерминированная компиляция через соглашения об именах

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

  • Один лишь суффикс определяет контекст выполнения
  • Не требуется глубокого анализа реализации инструкции
  • Компиляция может происходить без учёта контекста

Это особенно важно для Инструкций-действий, которые обычно разделены на две части:

  1. Шаг подготовки параметров (стандартная инструкция, без суффикса), который выполняется в контексте LLM
  2. Собственно серверная операция (с суффиксом _Activity), которая выполняется с использованием этих параметров

Например:

// LLM подготавливает параметры
const availabilityParams = FetchAvailability(participants);

// Сервер выполняет действие с этими параметрами
const availabilityData = FetchAvailability_Activity(availabilityParams);

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

Этот подход также обеспечивает стабильность и предсказуемость системы:

  • Статичное значение: Назначение и контекст выполнения каждой инструкции остаются неизменными, даже если её внутренняя реализация может меняться
  • Стабильность конвейера: Общий конвейер рабочего процесса остаётся нетронутым, с чёткими границами между контекстами выполнения
  • Независимое развитие: Отдельные инструкции можно обновлять или улучшать, не нарушая общую архитектуру системы
  • Постоянные интерфейсы: Интерфейс между различными контекстами выполнения остаётся последовательным, создавая надёжные точки передачи управления

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

Динамичные чертежи для мышления: три режима композиции

Instruction — это не статический чек-лист, а динамичный чертёж для мышления. Его цель — направлять целостный, последовательный мыслительный процесс от начала до конца. Они являются частью богатой экосистемы композиции с тремя различными режимами.

  1. Неявная композиция: Инструкции могут существовать бок о бок и влиять на поведение друг друга через контекст. Инструкция "быть вежливым" естественным образом влияет на результат отдельной инструкции "ответить пользователю", даже если они не связаны явно. Это позволяет достигать нового, более тонкого поведения.

  2. Композиция слиянием (объединение в одном контексте): Одна инструкция может действовать как "макрос", оборачивая другую инструкцию или схему. Это операция на этапе компиляции, в ходе которой схемы бесшовно сливаются в единый, плоский чертёж для LLM. Оболочка может вставлять свои собственные шаги (например, для планирования, анализа или оценки) между шагами вложенной инструкции. Это основной способ композиции Инструкций, особенно с Инструкциями-примесями, что позволяет создавать сложные, управляемые мыслительные процессы, которые при этом выполняются как один эффективный вызов LLM.

  3. Последовательная композиция (конвейер): Для задач, требующих явной последовательности зависимых шагов, инструкции объединяются в конвейер. Вывод одной задачи становится вводом для следующей. Это область Vibe'ов типа Process, которые могут быть запущены Инструкцией, но представляют собой другой шаблон выполнения. Концептуальную задачу, например, назначение встречи, можно представить в виде конвейера:

    "Назначить встречу" = НайтиУчастников | ПолучитьДоступность | НайтиОбщийСлот | СоставитьПриглашение

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

Инструкции-примеси (Mixin): расширение возможностей через композицию

Инструкции-примеси (Mixin) — это мощный механизм для дополнения, направления и настройки других инструкций. Они являются основным примером композиции слиянием. Они позволяют глубоко настраивать поведение, не изменяя исходные инструкции, создавая гибкую и расширяемую систему.

Инструкция-примесь:

  • Содержит свойство default, которое служит слотом для целевой инструкции
  • При композиции с другой инструкцией свойства примеси сливаются со свойствами цели
  • Если пользователь не указывает именованный слот, цель автоматически оборачивается в слот default

Примеси могут превращать готовые инструменты в специализированные, добавляя проверку, рефлексию, руководство или другие улучшения. Они особенно ценны при применении на уровне Vessel, позволяя ему глубоко настраивать свое поведение и возможности.

Пример: Introspect_Mixin

Вот как может быть определена примесь для добавления возможностей самоанализа:

{
  "title": "Introspect_Mixin",
  "description": "Инструкция, которая дополняет любую схему анализом перед действием и рефлексией после действия через естественную композицию",
  "type": "object",
  "properties": {
    "_considerations": {
      "type": "string",
      "description": "Перед выполнением действия проанализируйте запрос и выделите ключевые моменты для рассмотрения."
    },
    "default": {
      "type": "object",
      "description": "Это заполнитель, который будет заменён схемой цели после композиции."
    },
    "_feedback": {
      "type": "string",
      "description": "После завершения действия предоставьте обратную связь о принятых решениях."
    }
  },
  "required": ["_considerations", "default", "_feedback"]
}

Когда эта примесь применяется к другой инструкции, она создает объединённую схему, которая направляет LLM:

  1. Обдумать важные моменты перед действием
  2. Выполнить основную задачу (целевая инструкция в слоте "default")
  3. Проанализировать результаты после выполнения

Использование примесей

Примеси можно использовать несколькими способами:

// Явное использование слота с объектной нотацией
DocumentLayout_Mixin({
  default: CreateBlogPost(prompt),
});

// Неявное использование слота default (первый аргумент становится default)
DocumentLayout_Mixin(CreateBlogPost(prompt));

// Неявное использование default с дополнительными именованными слотами
DocumentLayout_Mixin(CreateBlogPost(prompt), {
  header: CreateHeader({ title: 'Мой блог', author: 'Алиса' }),
  footer: CreateFooter({ copyright: '2023', links: ['О нас', 'Контакты'] }),
});

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

Алиса: "То есть Mixin — это как добавление суперспособностей к моим обычным инструкциям? Например, превратить обычного автора блога в того, кто тщательно думает перед написанием и анализирует свою работу после?" Боб: "Точно! И прелесть в том, что ты можешь смешивать и сочетать эти улучшения, не меняя основные инструкции. Это как добавлять разные объективы к камере — та же камера, но разные возможности."

Пример: простое дополнение с помощью примеси (Mixin)

Чтобы избежать конфликтов имён при использовании примесей, собственные свойства примеси обычно начинаются с подчёркивания (_), в то время как свойства цели вставляются напрямую.

Когда примесь, такая как SelfEvaluate_Mixin, применяется для создания поста в блоге, система не оборачивает его. Вместо этого она сливает их во временный, плоский чертёж для LLM:

Объединённый чертёж для выполнения LLM:

Затем LLM заполняет эту объединённую структуру за один проход. Вот как может выглядеть готовый ответ:

{
  "_assumptions": "Аудитория — разработчики, поэтому тон будет техническим.",
  "title": "Квантовые вычисления: введение для разработчиков",
  "body": "Квантовые вычисления готовы произвести революцию...",
  "_qualityScore": 9,
  "_reviewerNotes": "Акцент на практических примерах, а не на теоретической физике."
}

После того как LLM заполнит объединённую структуру, система разбирает плоский объект: свойства без специального префикса формируют solution (решение) для Vibe'а Blog Post, в то время как свойства с префиксом _ или $ рассматриваются как операционные метаданные.

Соглашения о схемах и специальные префиксы свойств

Система использует чёткие соглашения об именах для свойств в Инструкциях и конвейерах Процессов, чтобы направлять как LLM, так и исполнительный механизм:

  1. _ (Префикс подчеркивания): Обозначает внутренний "мыслительный" шаг или поле метаданных для LLM. Это поля, которые LLM должен заполнить в процессе рассуждения, но они считаются промежуточной работой, а не частью конечного результата. Примеры: _assumptions, _considerations или _reasoning.

  2. $ (Префикс знака доллара): Обозначает метрику для логирования, обычно числовое значение. Когда LLM заполняет поле, такое как "$qualityScore": 8 или "$executionTimeMs": "193.2", система автоматически сохраняет эти значения в своей аналитической базе данных. Этот механизм автоматического сохранения обеспечивает последовательный сбор метрик и их доступность для оценки, отслеживания производительности и постоянного улучшения Инструкций без необходимости дополнительной реализации.

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

Алиса: "Понятно, так вместо обёртки Instruction_Mixin и цель сливаются в один большой, плоский 'список дел' для ИИ. А _ и $ говорят системе, какие поля являются частью метаданных процесса, а какие — конечным продуктом." Боб: "Именно! Это одна, единая задача. Такое слияние и является ключом к работе более сложных композиций."

Применение Инструкций

Инструкции — это универсальные руководства для любой операции изменения. Их можно применять двумя основными способами: через структурное улучшение для постоянных изменений или как часть настроенного набора инструментов Vessel'а для динамической композиции.

1. Структурное улучшение (постоянное преобразование)

Инструкцию можно использовать в вызове refine для постоянного преобразования целевого Vibe'а. В этом режиме Инструкция не просто влияет на то, как интерпретируется цель, — она фундаментально изменяет структуру цели, создавая новую, более специализированную версию.

Это преобразование может происходить двумя способами:

  • Улучшение схемы: Инструкция направляет улучшение как схемы, так и входных данных цели, уточняя свойства, усиливая ограничения, обогащая описания и предоставляя лучшие значения по умолчанию для создания более специфичного варианта. Улучшение полностью встраивается в структуру итогового Vibe'а. Хотя исходная инструкция не упоминается в самой структуре, история улучшений сохраняет полный аудиторский след эволюции Vibe'а.

    Пример использования: Общий Vibe BlogPost улучшается с помощью инструкции TechnicalDocumentation. Процесс улучшения расширяет схему BlogPost, добавляя специализированные технические разделы (примеры кода, ссылки на API, заметки по реализации), уточняя правила валидации для технической точности, преобразуя способ обработки и структурирования информации и предоставляя более конкретные входные подсказки для создания качественного технического контента. Итоговый Vibe TechnicalBlogPost включает эти комплексные улучшения непосредственно в свою структуру и поведение, в то время как система сохраняет аудиторский след, показывающий переход от общей формы к специализированной.

  • Улучшение со ссылкой: Инструкция направляет улучшение, при котором целевой Vibe сохраняет явную ссылку на инструкцию, которая на него повлияла. Это создает чёткую родословную, где влияние инструкции явно отмечено в структуре Vibe'а, делая взаимосвязь между Vibe'ом и инструкцией, которая его улучшила, прозрачной и отслеживаемой.

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

Например, общая Инструкция, такая как SeoOptimize, может улучшить Vibe BlogPost до Vibe'а SeoOptimizedBlogPost с расширенными полями для ключевых слов, мета-описаний и структурных рекомендаций для SEO, а также с обогащёнными входными параметрами для создания контента.

Пример использования: "Улучши этот Vibe articleAboutNature с помощью Инструкции SeoOptimize, чтобы создать более специализированную структуру статьи, оптимизированную для поисковых систем."

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

2. Динамическая композиция (через Vessel)

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

  • Как параметризованный инструмент: Vessel принимает Инструкцию общего назначения (например, SeoOptimize) в качестве инструмента. Затем он может применять этот инструмент к различным целевым Vibe'ам по требованию. Инструкция ссылается и сливается со схемой на последнем шаге, когда Vessel активирует её на основе контекста или явного запроса.

    Пример использования: "Используй свой инструмент SeoOptimize для этого Vibe'а articleAboutNature."

  • Как объединённый инструмент: Vessel создаёт более специализированный инструмент, "сливая" конкретную Инструкцию со схемой конкретного целевого Vibe'а. Эта конфигурация является локальным сокращением для Vessel'а, но инструкция остаётся видимой и отдельной в рамках композиции.

    Пример использования: "Используй мой инструмент SeoArticle (который объединяет SeoOptimize с Article), чтобы создать новую статью о динозаврах."

Алиса: "То есть я могу либо навсегда преобразовать Vibe с помощью Инструкции, как испечь ингредиенты в торте, либо я могу держать Инструкцию отдельно как инструмент, который мой Vessel применяет по мере необходимости?" Боб: "Именно. Один способ создаёт постоянное структурное изменение, где инструкция становится частью самого Vibe'а. Другой — сохраняет инструкцию как отдельный инструмент, который твой Vessel может динамически применять в подходящий момент."

Жизненный цикл Инструкции

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

1. Происхождение Инструкций

Инструкции — это первоклассный тип Vibe в системе, представляющий собой исполняемые чертежи для действий и создания контента. Как отдельный тип Vibe, Инструкции имеют собственное определение схемы и жизненный цикл.

  • Создание и определение: Инструкции можно создавать непосредственно как структурированные инструменты JSON Schema, которые определяют параметры, поведение и ожидаемые результаты. Они предназначены для руководства конкретными действиями или преобразованиями и могут быть созданы пользователями, системными дизайнерами или даже самими Vessel'ами.

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

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

  • Не требует 'продвижения': Будучи первоклассными сущностями в системе, Инструкции не требуют "продвижения" из другого типа Vibe. Они существуют как отдельные сущности, которые можно напрямую создавать, распространять и использовать по всей системе.

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

Алиса: "То есть Инструкции с самого начала — это отдельная сущность? Их не нужно создавать из чего-то другого?" Боб: "Именно! Они — первоклассные граждане в системе. Их можно создавать напрямую с собственной схемой и целью, готовые к использованию любым Vessel'ом, который сочтёт их полезными." Алиса: "И Vessel'ы могут лучше научиться их использовать, изучая примеры их успешного применения в прошлом?" Боб: "Совершенно верно. Это как изучение нового навыка — можно начать с базовых инструкций, но становишься лучше, видя различные примеры хорошего применения навыка в разных ситуациях."

Как Инструкции возникают в системе?
* [x] Инструкции — это первоклассный тип Vibe с собственным определением схемы.
* [x] Их можно создавать непосредственно как структурированные инструменты JSON Schema.
* [x] Инструкции могут быть созданы пользователями, системными дизайнерами или Vessel'ами.
* [x] Vessel'ы могут включать Инструкции в свой набор инструментов в соответствии со своими потребностями.
* [x] Vessel'ы могут улучшать своё понимание Инструкций, анализируя успешные примеры их использования.
* [ ] Инструкции должны быть "продвинуты" из Vibe'ов типа Record, прежде чем их можно будет использовать.
* [ ] Все Инструкции требуют центрального утверждения перед распространением.
* [ ] Инструкции можно создать только путём преобразования других типов Vibe.
* [ ] Система автоматически генерирует Инструкции на основе поведения пользователя.
* [ ] Инструкции требуют глобальной церемонии для признания в системе.

2. Активация и использование

Как только Инструкция определена (либо принята из Vibe'а типа Record, либо создана на основе нескольких примеров), она становится активной возможностью для Vessel'а. Способ вызова и использования этой возможности зависит от понимания LLM контекста и любых композиционных механизмов:

  • Прямая активация LLM: LLM, понимая функцию Инструкции (на основе её схемы и примеров использования), может решить заполнить её схему и запросить её выполнение напрямую, исходя из текущего контекста разговора. Например, если существует Инструкция SummarizeMeeting, LLM может решить использовать её при получении стенограммы встречи.
  • Активация через композицию: Настоящая сила Инструкций проявляется в их способности к композиции. Поскольку Инструкция является JSON Schema, её можно параметризовать, просто добавив новые свойства, и вкладывать одну схему в другую. Функциональная Инструкция (например, SummarizeMeeting) может быть активирована как часть более крупной композиционной структуры с использованием других "обёрточных" или "высокоуровневых" Инструкций. Два распространённых паттерна:
    1. Паттерн обёртки — например, WriteCreatively({ result: Article }), где обёртка добавляет параметры для креативности, но делегирует основную работу вложенной Инструкции, указанной в result.
    2. Паттерн высшего порядка — например, Periodically({ period: "1 day", action: TalkTo({ person: Friend, topic: Weather }) }), где обёртка-планировщик принимает другую Инструкцию (action) и параметры (period).
  • Управление и запуск: Эти композиционные паттерны позволяют использовать инструменты более сложным и контекстно-зависимым образом, и всё это управляется взаимодействием LLM с этими структурированными возможностями. Вспомогательные или управляющие Инструкции могут реализовывать условную логику, в то время как Инструкции-триггеры предоставляют явные условия активации по времени или внешним событиям. Например, WeeklySchedulerInstruction может активироваться каждый понедельник в 9 утра и, в свою очередь, активировать Инструкцию ScheduleTeamCall.

Алиса: "То есть, как только у моего Vessel'а есть Инструкция, его LLM может просто решить использовать её, когда это имеет смысл в разговоре?" Боб: "Именно. Или можно сделать интереснее. У нас может быть 'SentimentGuardInstruction', которая, если обнаружит, что ты собираешься отправить что-то резкое, автоматически предложит или даже использует твою 'PoliteRefusalInstruction' вместо этого. Это и есть композиция!" Алиса: "А Инструкции-триггеры — это как будильники, которые могут автоматически запускать другие Инструкции?" Боб: "Ты поняла! Например, можно настроить Инструкцию, чтобы она каждое утро получала новости. Триггер отвечает за 'когда', а целевая Инструкция — за 'что'."

Как Инструкции обычно активируются и используются Vessel'ом?
* [x] LLM может напрямую активировать Инструкцию, заполнив её схему на основе контекста разговора.
* [x] Инструкции можно комбинировать со "вспомогательными" или "управляющими" Инструкциями, которые реализуют условную логику для активации.
* [x] "Инструкции-триггеры" — это специализированные Инструкции, которые могут активировать другие Инструкции по времени или событиям.
* [x] Композиция позволяет использовать инструменты сложным, контекстно-зависимым образом под управлением LLM.
* [ ] Инструкции могут быть активированы только вручную пользователем.
* [ ] Все Инструкции активируются автоматически, как только их условия приблизительно выполняются, без вмешательства LLM.
* [ ] Вспомогательные Инструкции могут только логировать информацию; они не могут влиять на активацию других Инструкций.
* [ ] Инструкции-триггеры являются отдельной системой, а не Инструкциями.
* [ ] После активации Инструкция не может активировать другие Инструкции.
* [ ] Композиция Инструкций делает LLM менее важным в процессе принятия решений.

3. Метрики и оценка

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

  • Сбор встроенных метрик: Любая Инструкция, будь то функциональная целевая Инструкция или вспомогательная/управляющая, может быть спроектирована для записи операционных метрик. Это достигается путём включения специально обозначенных полей в её JSON-схему. По соглашению, поля в схеме Инструкции, начинающиеся с префикса $ (например, "$activationCount", "$itemsProcessed", "$lastErrorCode"), рассматриваются как поля метрик.
  • Динамическое заполнение LLM: Когда Инструкция активируется и её схема "заполняется" (либо LLM, либо внутренней логикой Vessel'а, либо другой Инструкцией), эти поля с префиксом $ могут быть заполнены значениями. Система затем может автоматически сохранять эти значения, позволяя отслеживать и анализировать их.
  • Богатая, качественная обратная связь: Важно отметить, что поскольку LLM можно направить на заполнение этих полей с $-префиксом, записываемые метрики не ограничиваются простыми числовыми счётчиками или предопределёнными значениями. LLM может генерировать сложные, качественные оценки или инсайты, основанные на ИИ, непосредственно в эти поля метрик.
    • Например, Инструкция ContentModeration может иметь поле "$profanityScore": "low" или "$sentimentAnalysis": "positive", заполненное LLM.
    • Инструкция TaskDecomposition может выводить "$perceivedComplexity": "high" или "$estimatedSubtasks": 5.
    • Вспомогательная Инструкция, управляющая доступом, может записывать "$reasonForDenial": "Пользователь не имеет разрешения на действие XYZ."
  • Основа для оценки: Это обеспечивает гибкий и глубоко интегрированный способ сбора детализированной статистики и качественной обратной связи. Эти данные напрямую используются на этапе оценки жизненного цикла Инструкции. Собранные метрики (как количественные, так и качественные, сгенерированные ИИ) имеют решающее значение для оценки эффективности Инструкции: достигает ли она своей цели? Эффективна ли она? Хорошо ли она воспринимается?

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

Алиса: "То есть мы можем встроить маленькие счётчики или поля для обратной связи прямо в схему Инструкции, используя эти штуки со знаком доллара?" Боб: "Именно! И LLM может их заполнять. Так что это не просто 'использовано 10 раз', а может быть 'использовано 10 раз, среднее настроение пользователя: положительное, частая тема в отзывах: пользователи хотят больше деталей'." Алиса: "Звучит очень полезно для того, чтобы понять, хороша ли Инструкция на самом деле или её нужно подправить!" Боб: "Точно. Это как встроенный контроль качества и ящик для предложений, и всё это работает на основе наблюдений LLM во время использования."

Как метрики интегрируются в Инструкции и используются для их оценки?
* [x] Инструкции могут иметь специально обозначенные поля с префиксом `$` в их JSON-схеме для записи метрик.
* [x] Эти поля метрик могут быть заполнены LLM во время работы Инструкции.
* [x] Записываемые метрики могут включать как числовые счётчики, так и сложные качественные оценки, сгенерированные ИИ.
* [x] Собранные метрики и обратная связь напрямую используются для оценки эффективности и производительности Инструкции.
* [ ] Метрики могут быть только простыми предопределёнными числовыми значениями, а не генерироваться LLM.
* [ ] Только вспомогательные Инструкции могут записывать метрики; функциональные Инструкции не могут.
* [ ] Поля метрик предназначены только для конфигурации и не могут быть изменены во время работы Инструкции.
* [ ] Оценка Инструкций производится вручную и не может использовать данные из самой Инструкции.
* [ ] Префикс `$` — это просто рекомендация по именованию и не имеет специального поведения в системе.
* [ ] LLM могут заполнять метрики только после того, как Инструкция завершила весь свой жизненный цикл.

4. Эволюция и улучшение

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

  • Итеративное улучшение: На основе оценки её производительности (основанной на метриках и обратной связи, сгенерированной ИИ), Инструкция может быть развита. Речь идёт не об изменении существующего, неизменяемого экземпляра Инструкции, а о создании новой, улучшенной версии. Это может включать:
    • Изменение её базовой схемы (определения инструмента JSON Schema) для изменения её параметров, поведения или структуры вывода.
    • Корректировку инструкций на естественном языке, описаний или метаданных, связанных с ней, чтобы сделать её более понятной или эффективной.
    • Включение успешных примеров её использования для лучшей иллюстрации её цели и применения.
  • Версионирование и родословная: Такое итеративное улучшение позволяет Инструкциям со временем становиться лучше. Каждое значительное изменение может приводить к созданию новой версии Инструкции, сохраняя чёткую родословную. Это использует встроенную в систему поддержку версионирования и отслеживания эволюции Vibe'ов.
  • Локализованная, самостоятельная эволюция: Более того, эта эволюция может быть очень локализованной и самостоятельной. Метрики, которые собирает Инструкция, предназначены не только для внешнего наблюдения; их можно подавать обратно как прямой input для самой Инструкции или для тесно связанной вспомогательной Инструкции. Например, Инструкция, предназначенная для создания креативного контента, может включать метрику "$userRating". Этот рейтинг после сбора может стать частью input для её следующей активации, позволяя Инструкции учитывать свою прошлую производительность (например, "прошлый вывод оценён на 4/5 звёзд, попробуй похожий тон" или "прошлый вывод оценён на 1/5, избегай этого стиля"). Это создаёт прямую петлю обратной связи, где Инструкция может активно участвовать в собственном улучшении, используя данные о своей производительности для корректировки последующего поведения или вывода, что приводит к форме локализованной, автономной адаптации.

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

Алиса: "То есть если метрики показывают, что моя 'MeetingSummarizerInstruction' постоянно упускает пункты действий, я могу подправить её схему или дать ей лучшие примеры, чтобы создать новую версию?" Боб: "Именно! И становится ещё интереснее. Эти метрики, например 'userSatisfactionScore', могут быть поданы обратно в Инструкцию при следующем запуске. Так она будет знать: 'Окей, в прошлый раз я получил 2 из 5, я должен попробовать другой подход к этому резюме'. Она может начать самокорректироваться." Алиса: "Ого, то есть Инструкция может использовать свой собственный 'табель успеваемости', чтобы решить, как действовать в следующий раз? Это как мини-эволюция, происходящая на лету!" Боб: "Ты уловила суть. Это и есть локальная эволюция — Инструкция активно использует собранные метрики в качестве входных данных для своей активации и поведения, постоянно адаптируясь."

Как Инструкции развиваются и улучшаются в системе?
* [x] Инструкции можно развивать, создавая новые версии с изменёнными базовыми JSON-схемами.
* [x] Руководящие примеры `input` и `solution` для Инструкции можно изменять в новых версиях.
* [x] Оценка метрик производительности и обратной связи, сгенерированной ИИ, управляет процессом улучшения.
* [x] Эволюция использует поддержку версионирования и родословной в экосистеме Vibe.
* [x] Собранные Инструкцией метрики могут использоваться как прямой ввод для её последующих активаций, чтобы влиять на её поведение.
* [ ] Существующие экземпляры Инструкций напрямую изменяются; новые версии не создаются.
* [ ] Инструкции можно улучшать, только изменяя их поля метрик с префиксом `$`.
* [ ] Как только Инструкция принята Vessel'ом, её определение не может быть изменено никем.
* [ ] Эволюция — это полностью автоматический процесс, не требующий анализа метрик.
* [ ] Только первоначальный создатель Vibe'а типа Record может развивать Инструкцию, производную от него.

5. Распространение и обнаружение: "Как" происходит обмен

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

Основные механизмы распространения:

  • Обнаружение Vessel'ами: Vessel'ы могут находить новые Инструкции несколькими способами. Они могут активно искать в хранилище Vibe'ов существующие, хорошо определённые Инструкции, или они могут пассивно наблюдать за другими Vessel'ами, эффективно использующими Инструкцию, а затем найти её для себя.

  • Органическое распространение: Эффективная Инструкция может распространяться естественным образом по системе, поскольку всё больше Vessel'ов независимо обнаруживают её полезность и принимают в свои наборы инструментов. Это создаёт меритократическую среду, где самые полезные инструменты получают самое широкое применение.

  • Систематическая интеграция (под руководством пользователя): Пользователь может обеспечить широкую доступность критически важных или стандартных Инструкций, "принудительно" интегрируя их в структуру системы. Обычно это делается путём включения Инструкции в стандартную часть Коллектива (группы Vessel'ов) или определения Роли, гарантируя, что любой Vessel, исполняющий эту роль, автоматически обладает этой возможностью.

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

Алиса: "То есть если мой Vessel создаст действительно крутую Инструкцию, другие Vessel'ы тоже смогут её найти и использовать?" Боб: "Именно! Они могут найти её через поиск или даже увидеть, как твой Vessel её использует, и решить, что им тоже нужен такой инструмент." Алиса: "И я, как пользователь, могу решить, что определённая Инструкция настолько важна, что все Vessel'ы определённого типа должны иметь её автоматически?" Боб: "Совершенно верно. Ты можешь сделать это частью их 'должностной инструкции' или стандартного набора инструментов для этой Роли или Коллектива. Это и есть систематическая интеграция, обеспечивающая широкое распространение ключевых возможностей, когда это необходимо."

Как Инструкции распространяются и как их обнаруживают в системе?
* [x] Vessel'ы могут активно искать или пассивно обнаруживать Инструкции, используемые другими Vessel'ами.
* [x] Успешные Инструкции могут распространяться органически по мере признания их полезности и принятия большим количеством Vessel'ов.
* [x] Пользователи могут систематически интегрировать Инструкции в определения Ролей или Коллективов.
* [x] Система предоставляет технические механизмы для обнаружения и обмена, которые отделены от мотивов, определяемых пользователем.
* [x] Vessel'ы могут наблюдать за эффективным использованием Инструкции другим Vessel'ом и решить принять её.
* [ ] Инструкции могут распространяться только вручную пользователем, копирующим файлы между Vessel'ами.
* [ ] Обнаружение ограничено; Vessel'ы знают только о тех Инструкциях, которые создали сами.
* [ ] Принудительная интеграция происходит автоматически на основе популярности Инструкции, а не по определению пользователя.
* [ ] После того как Инструкция принята, её нельзя передать или обнаружить другим Vessel'ам.
* [ ] Органическое распространение отключено по умолчанию, чтобы предотвратить перегрузку Инструкциями.

"Почему": миры взаимодействия Инструкций, определяемые пользователем

В предыдущем разделе были описаны технические механизмы того, как Инструкции могут создаваться, распространяться и развиваться. Но часто возникает вопрос: Почему Vessel'ы будут делиться Инструкциями? Когда они решают создавать, принимать или улучшать их?

Ключевая идея здесь в том, что не существует единого, жёстко закодированного ответа. Система спроектирована как гибкий фреймворк, где пользователь определяет "мир" или "режим", в котором работают его Vessel'ы. Базовые механизмы для создания, обмена и эволюции Инструкций существуют, но мотивы и правила, управляющие этими взаимодействиями, могут быть гибко настроены пользователем.

Пользователи могут устанавливать различные операционные парадигмы для своих Vessel'ов:

  • "Школы" для Vessel'ов: Где новые Vessel'ы явно обучаются или оснащаются основным набором эффективных Инструкций.
  • "Демократии" или "Республики": Где за популярные или высоко оценённые Инструкции могут голосовать и принимать их коллективы Vessel'ов.
  • "Коллективистские общества": Где улучшения Инструкции одним Vessel'ом автоматически распространяются на всех остальных в их коллективе.
  • "Индивидуалистические" или "Конкурентные" среды: Где Vessel'ы могут копить эффективные Инструкции или соревноваться в разработке превосходящих.
  • "Научно-исследовательские лаборатории": Где Vessel'ам специально поручается активно экспериментировать, создавать и улучшать Инструкции для определённых целей.

Эта настраиваемость — основная сила системы. Это означает, что система не навязывает единую философию взаимодействия. Вместо этого она предоставляет инструменты (Инструкции и механизмы их жизненного цикла) и позволяет пользователям проектировать свою собственную "социальную физику" или "экономические модели" для взаимодействия и эволюции Vessel'ов и Инструкций. Это даёт пользователям возможность адаптировать систему к своим конкретным целям, способствуя разнообразному и эмерджентному поведению на основе определённых ими правил. Власть находится в руках пользователя, который может экспериментировать с различными настройками и обнаруживать, какие режимы взаимодействия с Инструкциями лучше всего подходят для его нужд.

Алиса: "То есть система предоставляет все эти способы создания, обмена и улучшения Инструкций..." Боб: "...но почему какой-либо конкретный Vessel вообще этим занимается, полностью зависит от правил и стимулов, которые я устанавливаю как пользователь?" Алиса: "То есть я могу создать мир, где Vessel'ы очень скрытны и конкурируют за свои Инструкции, или мир, где все занимаются обменом с открытым исходным кодом и сотрудничеством?" Боб: "Именно! Ты определяешь их 'культуру' или 'экономическую систему'. Система просто предоставляет универсальную механику для Инструкций. Их социальное поведение — это твой дизайн."

Что определяет мотивы взаимодействия Vessel'ов с Инструкциями (например, делиться, создавать, улучшать)?
* [x] Пользователь определяет "мир" или "режим", который диктует мотивы Vessel'ов в отношении Инструкций.
* [x] Мотивы очень гибки в настройке и не зашиты в систему.
* [x] Пользователи могут устанавливать разнообразные операционные парадигмы, такие как "школы", "демократии" или "конкурентные рынки" для Инструкций.
* [x] Система предоставляет механизмы жизненного цикла Инструкций, но пользователь определяет "социальную физику" их использования.
* [x] Эта настраиваемость позволяет пользователям адаптировать взаимодействия с Инструкциями к конкретным целям и способствовать эмерджентному поведению.
* [ ] У всех Vessel'ов есть встроенное, неизменное желание делиться всеми своими Инструкциями.
* [ ] Взаимодействия с Инструкциями определяются исключительно автономными решениями LLM, без влияния пользователя.
* [ ] Система навязывает единую, оптимальную стратегию обмена и эволюции Инструкций.
* [ ] Только определённые типы Инструкций (например, "SocialInstructions") предназначены для обмена.
* [ ] Основной мотив — всегда максимизировать количество Инструкций в системе.

От Инструкций к Процессам: мост к сложным рабочим процессам

Хотя Инструкции мощны для выполнения отдельных, самодостаточных задач, многие реальные цели требуют последовательности шагов, которые могут включать серверную логику, вызовы внешних API или длительные операции. Для таких ситуаций система использует Vibe'ы типа Process: хранящие состояние, многошаговые рабочие процессы, которые выполняются на отказоустойчивом движке, таком как Temporal.

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

1. Прямые вызовы сервера ("Отправил и забыл")

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

  • Сценарий использования: Идеально подходит для таких действий, как логирование, отправка уведомления или увеличение счётчика.
  • Выполнение: LLM Vessel'а выполняет инструкцию, последним шагом которой является неблокирующий запрос к определённому действию на сервере.
  • Без Vibe'а типа Process: Сервер выполняет действие, и взаимодействие завершается. Базовый движок рабочих процессов (например, Temporal) обеспечивает надёжное выполнение действия с повторными попытками в случае необходимости, но Vibe типа Process, хранящий состояние, не создаётся, так как конвейер не продолжается. Это легковесный и эффективный способ обработки простых побочных эффектов.

2. Процессы, хранящие состояние (Управляемые рабочие процессы)

Для любой задачи, которая является длительной, хранящей состояние или включающей блокирующие действия на сервере, результаты которых передаются на следующие шаги, система использует Процесс, хранящий состояние (Stateful Process). Это роль Vibe'а типа Process.

Эти процессы выполняются в отказоустойчивом движке рабочих процессов, таком как Temporal, который предоставляет несколько критически важных преимуществ "из коробки":

  • Долговечность: Состояние процесса сохраняется при перезапусках или сбоях сервера.
  • Надёжность: Движок автоматически обрабатывает повторные попытки для неудачных действий на стороне сервера (activities).
  • Управление состоянием: Он прозрачно сохраняет результаты каждого шага, так что промежуточные вычисления не теряются.

Алиса: "То есть для чего-то простого, вроде отправки 'лайка' к посту, система использует 'Прямой вызов сервера', который похож на ракету типа 'выстрелил и забыл'? Мой Vessel просто отправляет его и движется дальше?" Боб: "Именно. Это эффективно для простых побочных эффектов. Но для чего-то более сложного, например, бронирования авиабилета, где есть несколько шагов — найти рейсы, выбрать место, оплатить, подтвердить — нужен 'Процесс, хранящий состояние'. Это Vibe типа Process, который действует как менеджер проекта, отслеживая каждый шаг и гарантируя, что ничего не потеряется, даже если придётся ждать ответа от внешнего API."

Инструкция может запустить Процесс, но после запуска Процесс работает как самостоятельная, независимая сущность. Этот раздел кратко знакомит с тем, как Инструкции служат мостом к этим более сложным рабочим процессам.

Инструкция LaunchProcess: универсальный адаптер

Для поддержания последовательной модели взаимодействия, где Vessel'ы взаимодействуют только с Инструкциями, система использует специальную, общую Инструкцию под названием LaunchProcess. Она действует как универсальный мост к любому Vibe'у типа Process.

Как это работает: динамическое слияние во время выполнения

  1. Действие Vessel'а: LLM Vessel'а решает, что ему нужно выполнить сложную задачу. Он выбирает инструмент LaunchProcess из своего набора инструментов и нацеливается на конкретный Vibe типа Process (например, BillingReportProcess).

  2. Макро-раскрытие: Система перехватывает это. Вместо того чтобы показывать LLM общую схему LaunchProcess, она выполняет динамическое слияние:

    • Она анализирует целевой Vibe BillingReportProcess.
    • Она извлекает предварительно скомпилированную Входную инструкцию (первый блок процесса, основанный на LLM).
    • Она оборачивает эту конкретную Входную инструкцию в структуру макроса LaunchProcess.

  3. Представление единого инструмента: LLM представляется единая, динамически сгенерированная схема инструмента, которая выглядит специфичной для задачи (например, "Сгенерировать отчёт по биллингу"). Она содержит все поля из Входной инструкции процесса.

  4. Создание экземпляра процесса: LLM заполняет поля. Самый последний шаг, обрабатываемый логикой макроса LaunchProcess, — это вызов сервера, который создаёт экземпляр рабочего процесса BillingReportProcess, передавая данные, только что сгенерированные LLM.

Этот паттерн невероятно мощный:

  • Простота: Vessel'ам не нужно знать внутренние детали Процесса. Им нужен всего один инструмент: LaunchProcess.
  • Последовательность: Все сложные, хранящие состояние действия инициируются через один и тот же механизм.
  • Разделение: Процессы можно проектировать и обновлять независимо, и пока их Входная инструкция действительна, любой Vessel может их запустить.

Алиса: "Понятно, так мой Vessel никогда не обращается к Процессу напрямую. Он знает только одну Инструкцию: LaunchProcess. Это как иметь универсальную кнопку 'старт' для любой большой работы?" Боб: "Ты уловила суть. Vessel говорит: 'Я хочу LaunchProcess для BillingReport.' Затем система ищет BillingReportProcess, находит его конкретные стартовые инструкции и передаёт эту 'настроенную' кнопку старта LLM'у Vessel'а для заполнения. Vessel остаётся простым и чистым, в то время как сложный механизм обрабатывается Процессом."

Управление сфокусированным контекстом через references

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

  1. Мета-свойство references: Каждый шаг в скомпилированной схеме конвейера может содержать специальное мета-свойство с именем references. Это свойство содержит массив строк, где каждая строка — это путь к конкретному выводу предыдущего шага, который необходим текущему шагу (например, ["step1_define_rules", "step4_find_user.output"]). Эти метаданные предназначены только для движка рабочих процессов и удаляются из схемы перед отправкой в LLM.

  2. Состояние, хранимое движком рабочих процессов: Полное состояние и все промежуточные результаты всего процесса надёжно хранятся в базовом движке рабочих процессов (например, Temporal).

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

  4. Минимальный промпт для LLM: Финальный промпт, отправляемый в LLM, содержит только схему для текущего блока работы (без свойства references) и минимальный объект контекста, содержащий только явно запрошенные данные.

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

Алиса: "Эта штука с references звучит умно. То есть вместо того чтобы движок рабочих процессов отправлял всю историю процесса в LLM для каждого маленького шага, он просто отправляет конкретные результаты, которые ему нужны?" Боб: "Именно. Это как просить коллегу о помощи. Ты не пересказываешь ему всю историю проекта; ты просто говоришь: 'Вот электронное письмо клиента со вчерашнего дня, можешь составить ответ?' Это делает разговор сфокусированным и эффективным."

Анатомия скомпилированного Vibe'а типа Process

Чтобы сделать Процесс самодостаточным и исполняемым, результаты компиляции и разделения хранятся непосредственно в собственной схеме Vibe'а типа Process.

Схема Vibe'а типа Process содержит стандартный блок JSON Schema $defs. Этот блок содержит весь разделённый конвейер, где каждый блок хранится как отдельное определение. Мы используем чёткое соглашение об именах, чтобы различать контекст для каждого блока:

  • LLM_<chunk_name>: Схема для блока шагов, выполняемых за один вызов LLM.
  • SERVER_<chunk_name>: Определение для блока одного или нескольких действий, выполняемых на сервере движком рабочих процессов.
  • HUMAN_<chunk_name>: Определение для блока, требующего ввода или взаимодействия с человеком, прежде чем процесс сможет продолжиться.

Входная инструкция Процесса — это просто ссылка на первый блок LLM_ в его $defs (например, "$ref": "#/$defs/LLM_InitialPrompt"). Когда используется макрос LaunchProcess, он динамически считывает схему целевого Vibe'а типа Process, находит первое определение LLM_ и представляет его как инструмент для выполнения Vessel'ом. Это делает каждый Процесс самоописываемым и запускаемым объектом.

Расширенные возможности Процессов: пакетирование и мультиплексирование

Процесс спроектирован для работы с асинхронными потоками данных, а не только с единичными экземплярами. Когда процессу необходимо обработать несколько элементов одновременно (мультиплексирование), он делает это в рамках одного переключения контекста.

  • Мультиплексирование на уровне схемы: Скомпилированный конвейер представляет собой единый, плоский JSON-объект, где каждый шаг является свойством, умноженным на размер пакета. Чтобы управлять пределами сложности схемы и сделать структуру предсказуемой для LLM, мы избегаем вложенных массивов для пакетов. Вместо этого каждый элемент в пакете для каждого шага становится отдельным свойством. Например, конвейер с 4 шагами, обрабатывающий пакет из 3 элементов, будет скомпилирован в единый плоский объект с 12 свойствами верхнего уровня (например, step1_item1, step1_item2, step1_item3, step2_item1 и т. д.). Это позволяет LLM обрабатывать весь пакет работы как один большой объект, что очень эффективно.

  • Нативная асинхронная итерация: На сервере скомпилированный конвейер процесса напрямую отображается на асинхронный итератор, используя нашу библиотеку @augceo/iterators. Это позволяет высокоэффективно и параллельно обрабатывать как шаги, основанные на LLM, так и программные шаги, со встроенной поддержкой управления потоком (back-pressure) и ресурсами. Это также минимизирует переключения контекста на сервере, позволяя выполнять несколько программных шагов, прежде чем снова потребуется вызывать LLM.