🗃️ Операционная память для агентских процессов на Папках задач
2/4

... (продолжение, начало тут: https://t.me/deksden_notes/35)


🗄️ Механизм "Папка задачи"

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

📝 Системные промпты агентов могут предусматривать чтение из папки задачи деталей своего задания, которые никак бы не вместились в сообщение оркестратора.
Результаты работы агента со всеми деталями могут быть записаны в файл. Не всегда возможно уместить эти детали в ответ оркестратору.

Чтобы стало понятнее, давайте рассмотрим конкретный пример агентного процесса.

✨**Пример кейса:**

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

Как для данного кейса может выглядеть выполнение агентного процесса:

‣ задача оркестратора: переименовать функцию Х из модуля ХУ.ts

‣ оркестратор вызывает субагента "создать папку задачи" и получает новую папку задачи `.tasks/TASK-032/, идентификатор задачи TASK-032.

‣ оркестратор запускает первый этап процесса - найти затронутые файлы вызывая агента "исследователь" с задачей: идентификатор задачи TASK-032, идентификатор этапа S-01, результат нужно будет поместить в файлы вида "TASK-032-S-01-final-report-{file_type-XX}.md", задача - найти где в кодовой базе используется функция Х из модуля XY.ts.

Исследователь должен отсортировать файлы в два списка, по типу файла (file_type) - если это файл кода, то в список "-code", если это документация, то в список "-docs".

Чтобы облегчить обработку длинных списков, каждый из них обработаем и сгруппируем в группы не более 5 файлов.

Группу файлов будем писать в отдельный файл с суффиксом "-code-XX" или "-docs-XX" (вы же помните что мы разбили код/документация).

Вернуть нужно итоговый список созданных файлов (сколько то файлов -code-XX и -docs-XX), допонительно сказать сколько таких файлов всего получилось.

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

‣ управление возвращается оркестратору - он просто видит результары работы "исследователей" со списками файлов, содержимое файлов его особо не интересует

‣ далее оркестратор начинает обрабатывать список файлов, делать вызовы агента "писатель кода" по 5 штук параллельно, для всех полученных файлов кода

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

‣ похожую операцию повторим для параллельного запуска агента "писатель документации", который знает детали как правильно обновлять документацию. Например, нужно будет не забыть обновить оглавление файла, или список внешних зависимостей модуля/функции;

‣ система завершит работу. Даже если у нас был неслабый проект и 200 упоминаний по коду/документации, мы получим полностью обновлённую кодовую базу, с переименованными комментариями и правильно сформированной документацией; при этом контекст оркестратора будет "забит" только списком файлов, что вряд ли "скушает" его даже на 1%.


... (продолжение тут: https://t.me/deksden_notes/38)

#post
@deksden_notes