"🗃️ Операционная память для агентских процессов на Папках задач 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"