Методология интерпретируемого контекста: файловая структура как архитектура агента

Современная оркестрация ИИ-агентов часто требует сложных фреймворков вроде CrewAI или LangChain, однако для последовательных процессов это создает избыточный инженерный overhead. Я изучил альтернативный подход, где управление задачами строится прямо на уровне файловой системы, избавляя разработчиков от громоздких надстроек.

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

ICM основан на 5 принципах

Описанная методология опирается на идеи классического Unix-pipeline и концепцию разделения зависимостей, предложенную Дейкстрой. Такой подход позволяет декомпозировать систему так, чтобы каждый отдельный модуль скрывал свою внутреннюю логику от остальных, упрощая внесение точечных правок.

Один этап — одна задача

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

Текст как универсальный интерфейс

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

Послойная загрузка контекста

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

Редактирование промежуточных артефактов

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

Настройка фабрики, а не продукта

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

Архитектура рабочего пространства

В основе методологии лежит особая папка, внутри которой ИИ-агент функционирует в рамках пятиуровневой контекстной иерархии. Такая организация заменяет громоздкие менеджеры состояний.

Слой 0 и Слой 1

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

Слой 2, 3 и 4

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

Пример организации директорий

Последовательное выполнение этапов гарантирует строгое разделение ответственности. Папка /output предыдущего шага автоматически становится входными данными для следующего узла цепи.

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

Главные плюсы ICM

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

Сокращение контекстного окна

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

Принцип DRY и документация

Структуру шагов можно легко переиспользовать простым копированием папок, а вспомогательную логику выносить в скрипты. При этом сами Markdown-файлы работают как живая документация в стиле Дональда Кнута.

Упрощение субагентов и независимость от моделей

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

Ограничения подхода

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

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