[Перевод] Interpretable Context Methodology: структура директорий как архитектура агента

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

Суть события

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

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

Детали

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

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

Практический шаблон выглядит так: CONTEXT.md описывает этап, input содержит материалы текущего прогона, output — его проверяемый результат, а scripts — повторяемые действия вроде преобразования формата или проверки поля. Такую директорию можно копировать для нового процесса, меняя только входные данные.

Контекст

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

Но ICM не универсален. Методология рассчитана прежде всего на последовательные пайплайны. Циклические обмены между множеством агентов, параллельные запуски и изоляция состояния потребуют очереди и дополнительной инфраструктуры. Отладка тоже неполна: по папкам видно, на каком шаге появилась проблема, но не всегда видно, почему предыдущий шаг пришёл к ошибочному выводу.

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

Что дальше

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

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