[Перевод] Interpretable Context Methodology (Методология интерпретируемого контекста): структура директорий как архитектура агента

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

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

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

Этот подход позволяет избежать использования оркестрационного фреймворка и использования нескольких агентов. Один агент отвечает за оркестрацию. Структура директорий говорит агенту, что делать на каждом шаге процесса и даже если агенту надо делегировать задачу, эта же структура определяет контекст для sub-агентов.

Подход основан на идее Unix-pipeline. Система декомпозирована на основе того, что одни модули прячут от других модулей, что позволяет вносить изменения в логику модулей, не нарушая работу программы. Предложенный Дейкстрой подход “разделения зависимостей” позволяет модулям отвечать за единственную задачу. Разработчику остается лишь определить порядок выполнения задач.

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

1. Один этап, одна задача

   Каждый этап в рабочем пространстве отвечает за единственный шаг рабочего процесса и записывает результат работы в собственную директорию (например, /output).

2. Текст как интерфейс

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

3. Загрузка контекста слоями

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

4. Артeфакт этапа может быть отредактирован

   Каждый артeфакт этапа работу может быть открыт, проверен, отредактирован и сохранен человеком. Этот принцип является имплементацией принципа mixed-initiative Хорвица и парадигмы прямого манипулирования Шнайдермана. Человек работает с читаемыми, изменяемыми объектами; система продолжает работу с тем, что проверил человек.

5. Настраиваем фабрику, а не продукт

   Рабочее пространство настраивается единожды согласно предпочтениям пользователя и архитектурным решениям. После этого каждый прогон пайплайна производит новый результат, при этом конфигурация переиспользуется. Это имплементация принципа continius delivery (prod пайплайны должны быть повторяемыми).

Архитектура

Рабочее пространство Interpretable Context Methodology это директория. Агент работает в контекстной иерархии из 5 слоёв.

{структура}
├── Слой 0: AGENTS.md
│   ├── ~800 tok
│   ├── Где я?
├── Слой 1: CONTEXT.md
│   ├── ~300 tok
│   ├── Куда мне пойти?
├── Слой 2: СONTEXT.md текущего этапа
│   ├── ~200-500 tok
│   ├── Что мне делать?
{контент}
├── Слой 3: эталон
│   ├── ~500-2000 tok
│   ├── Каким правилам следовать?
├── Слой 4: Артефакты работы
│   ├── разнится
└───└── С чем я работаю?
```

Слой 0

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

Слой 1

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

Слой 2 и 3

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

Слой 4

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

Пример рабочего пространства

workspace/
├── AGENTS.md             Слой 0
├── CONTEXT.md            Слой 1
├── stages/       
│       01_research/
│       ├── CONTEXT.md    Слой 2
│       ├── references/   Слой 3
│       └── output/       Слой 4
│       02_script/
│       ├── CONTEXT.md    Слой 2
│       ├── references/   Слой 3
│       └── output/        Слой 4
│       03_production/
│       ├── CONTEXT.md    Слой 2
│       ├── references/   Слой 3
│       └── output/       Слой 4
├── _config/              Слой 3
├── shared/               Слой 3
└── setup/

Этапы выполняются последовательно. Ограничения контекста в директории обеспечивают разделение ответственности. Каждая /output предыдущего шага доступна следующему. Например, /output шага 01 становится входными данными для этапа 02. Если пользователь отредактирует 01_research/output − именно отредактированная версия станет входными данными для этапа 02_script.
_config содержит в себе материалы 3-го слоя, информацию и ограничения, одинаковые для каждого прогона пайплайна. Слой 2 это точки контроля. В этих файлах содержатся контракты и входные данные, которые уточняют какие файлы из Слоёв 2 и 4 агенту требуется загрузить, и какие секции этих файлов релевантны для текущего этапа.

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

Плюсы ICM

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

При имплементации этого подхода каждый из этапов пайплайна не загружает контекст на более чем ~5.6k tok для задачи, которая потребует 42k tok, если решается через монолитный skill. При длинном контексте перформанс модели неизбежно деградирует, этого мы и пытаемся избежать.

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

DRY (don’t repeat yourself)

При корректном определении CONTEXT.md шаги пайплайна можно переиспользовать просто скопировав директорию с шагом. Если часть работы можно описать с помощью скрипта, их можно вынести в отдельную директорию /scripts и переиспользоватьдля различных пайплайнов, получая один и тот же результат. К тому же будущие изменения (например, добавление логгирования) можно будет внести в один файл − и они распространятся на все пайплайны. DRY, как он был задуман.

CONTEXT.md как документация

В подобном дизайне пайплайна есть что-то от “грамотного программирования” Кнута. Markdown файлы одновременно служат инструкциями для агента и документацией о том, что конкретно выполняется на конкретном этапе пайплайна. Новый разработчик может просто прочитать CONTEXT.md файлы сверху вниз по структуре директорий и понять работу пайплайна, ни разу его не запустив.

Упрощение оркестрации субагентов

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

Model-agnostic подход

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

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

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

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

• Отладка не идеальна. Мы можем понять, с какого этапа что-то пошло не так, но не можем понять, из-за чего конкретно на предыдущем этапе возникла ошибка. Формулирование политики логгирования остается в качестве упражнения для читателя.