Статическая конфигурация workflow

Обзор

Статическая конфигурация workflow — это практика объявления курируемых правил, стандартов, чек-листов и инструкций как глобальных переменных в variableRegistry workflow со значением default. Они намеренно размещены так, чтобы агент видел их на каждом соответствующем шаге, обеспечивая стабильное поведение на протяжении всего workflow.

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

Когда использовать

Используйте статическую конфигурацию workflow когда:

Агент должен следовать определённым правилам стабильно на нескольких шагах
Инструкции курируемые и стабильные (не генерируются во время выполнения)
Контент необходим для качества workflow (не опциональные справочные данные)
Вам нужно, чтобы движок workflow гарантировал доставку инструкций агенту

Как это работает

variableRegistry (со значениями default):
  planning_standards: "1. Each step must have tests... 2. No code in plan..."
  code_quality_rules: "1. Fix root cause, not symptoms... 2. Test after changes..."
  validation_checklist: "□ Requirements met □ Tests pass □ No regressions"

Step directive: "Create plan following {{planning_standards}}"
→ Движок workflow внедряет значение default из реестра в директиву
→ Агент видит правила каждый раз, без дополнительного ввода-вывода, без риска галлюцинаций

Почему не файлы?

Хранение критических инструкций во внешних файлах и просьба агенту их читать создаёт Вынесение критических инструкций в файлы:

Подход	Гарантия доставки	Стоимость ввода-вывода	Риск галлюцинаций
Значение default в variableRegistry	✅ Движок внедряет в директиву	Нет	Нет — текст буквальный
Внешний файл	❌ Агент может пропустить или прочитать выборочно	Дополнительное чтение на каждом шаге	Высокий — агент может вспомнить по памяти

Примеры

Хорошо: Стандарты планирования в workflow разработки

{
  "variableRegistry": {
    "planning_standards": {
      "type": "string",
      "description": "Rules agent must follow when creating plans",
      "default": "PLANNING STANDARDS:\n1. Each step implements functionality + tests\n2. No testing-only steps\n3. Verification criteria required..."
    }
  }
}

Директива ссылается: "Create development plan following {{planning_standards}}"

Хорошо: Чек-лист валидации

{
  "variableRegistry": {
    "validation_checklist": {
      "type": "string",
      "description": "Quality gates for code review",
      "default": "CHECKLIST:\n□ All tests pass\n□ No type errors\n□ Coverage maintained\n□ No security issues"
    }
  }
}

Не этот паттерн: Динамические результаты извлечения

// ❌ Это динамические данные в переменных workflow, а не статическая конфигурация
{
  "inputSchema": {
    "extraction_results": { "type": "object" }
  }
}
// Данные генерируются во время выполнения, растут неограниченно

Отличие от динамических данных

Характеристика	Статическая конфигурация (✅)	Злоупотребление динамическими данными (❌)
Когда создаётся	При проектировании workflow	Во время выполнения
Источник контента	Курируется автором workflow	Генерируется агентом/инструментами
Размер	Известный и ограниченный	Потенциально неограниченный
Назначение	Управление поведением агента	Передача данных между шагами
Изменения	Только при редактировании workflow	Каждое выполнение

Статическая конфигурация или playbook

Дефолт реестра хранит текст, который принадлежит этому процессу и меняется вместе с ним. Playbook хранит именованный текст поведения, живущий сам по себе: стандарт ревью, тон, определение готовности. Узел называет его как {{playbook:review-standard}} или {{playbook:@owner/name}} — для опубликованного playbook другого аккаунта.

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

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

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

Когда тексту нужен адрес

Источником текста в любом случае остаётся default реестра. Меняется другое: записывает ли запуск этот текст ещё и на диск.

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

Владелец workspace записывает его один раз, в том же ходе, где и так создаёт workspace, а последующие директивы называют путь:

{
  "directive": "Use the applicable sections of {{workspace_path}}/authoring-reference.md. The path is canonical; reread unchanged content only when it is absent, uncertain, or changed."
}

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