DEKSDEN notes

🗃️ Операционная память для агентских процессов на Папках задач 4/4 (...продолжение, предыдущая часть тут: https://t.me/deksden_notes/38) ❓ А что за магическая цифра "разбивать по 5 файлов"? На самом деле, именно 5 тут приведено просто для примера, но суть в том, что не надо делать такую задачу без ограничений количества файлов. Работа с файлами неслабо так нагружает контекст - все эти чтения фрагментов чтобы создать изменения, все они остаются в контексте. Если субагент получит неконтролируемого размера кучу файлов для обработки, уже у него кончится контекст - со всеми непредсказуемыми последствиями данного обстоятельства. А мы же хотим качественно и надёжно все сделать, да? ❓ Ок, но зачем так экономить контекст оркестратора? откуда такая сокральная ценность его контекста? Частичный ответ был ранее - если контекст кончается, дальше - сложно и непредсказуемо. Единственный вариант - ресет контекста. Ну и субагент стартует с "чистым" контекстом, который далее грузится его системпромптом, и заданием оркестратора. А что касается именно оркестратора - то его "чистый" контекст - это возможность выполнения сложных и продолжительных агентских процессов. 2-3 шага нашего примера процесса были не самыми простыми по логике выполнения, но "потратили" не более 1% контекста, значит смело можно делать процесс где таких шагов будет ещё 50. ☝️ Выводы Сочетание приёмов и принципов: - экономия контекста - использование агентных процессов (врокфлоу на субагентах) - конфигурирование агентов - использование папки задач как механизма обмена ... позволяет "выжимать" потенциал Claude Code и реализовывать сложные, полезные и умные процессы! Stay tuned, серия статей "to be continued" ␄ #post @deksden_notes

🗃️ Операционная память для агентских процессов на Папках задач 3/4 ... (продолжение, предыдущая часть тут: https://t.me/deksden_notes/37) **А если - нет?** Промоделируем сессию AMA ❓ В чем смысл таких сложностей и "танцев с бубном"? Допустим, мы просто расписали промптом задачу в СС и он начал выполнение. В чем такой подход хуже? 1️⃣ Во-первых, когда вы станете расписывать такой промпт, вы обнаружите что он будет огромным. У нас на самом деле куча деталей о проекте: например, банальные где лежит код, где лежат тесты, где лежит документация. Куча сведений, например, как работать с документацией - что бывают оглавления файлов, что в разделах про модуль есть раздел "внешние" зависимости. надо не забыть обновить комменты в коде. При работе агентскими процессами мы инкапсулируем все детали в промпт специализированному агенту. Причём, у разных агентов - разные детали. Тому кто пишет код не обязательно знать как писать md документацию. 2️⃣ Во вторых, если у вас большой проект, контекст основного агента (только тут его не назовёшь уже оркестратором, он ничего не оркестрирует, а работает сам) забьётся вызовом инструментов и обработкой файлов очень быстро. Далее произойдёт автокомпакт (у кого он включён), и дальше - как повезёт! если агент "не забудет" задание, то продолжит работу. Может, слегка не в том ключе и не особо следуя инструкциям. ▶️ В итоге: будет сложнее, дольше, менее качественно. Скажут - "Я ж говорил, ИИ не тянет!", хотя - 💯 SKILL ISSUE. ❓ А в чем смысл создания папки задачи с уникальным идентификатором? Все очень просто: идентификатор даёт некоторую изолированность задачи. Если вы в одном сеансе СС работаете с базой данных, то другие сеансы могут рефакторить код. Задачи друг другу мешать не будут, случайного пересечения имён файлов тоже не случится. Аналогично - и идентификатор этапа, позволяет разделять файлы. ❓ А чего такой велосипед? Файлы - это как то примитивно Потому что - нет. Файлы - не примитивно, а традиционно и в каком то смысле enterprise grade. Достаточно вспомнить что есть unix way, где вся система - это взаимодействие через файлы, включая pipes. Напомню, что linux - это тот же unix, только попроще. И даже бородатые сисадмины не скажут что unix это примитивно. ❓ Может быть все таки более хайповый MCP Наверняка есть куча MCP которые могут служить памятью. Отличный выбор на самом деле, если подобрать подходящий по функциям. Один нюанс - его все таки надо устанавливать дополнительно, и каждого субагента промптить на его использование. По своей сути особой разницы нету. И там, и там - это будут тулколы для записи и чтения. ❓ Зачем такие сложности с группировкой файлов? Можно просто обработать один за одним Нет, нельзя. По тестовому кейсу у нас документация и код. Как минимум разделить придётся по типу файлов. А если уж делить, так слегка оптимизировать параллельностью. До 5-7 агентов СС спокойно запускает параллельно, что будет сильно быстрее последовательного вызова. ... (продолжение тут: https://t.me/deksden_notes/39)

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

🗃️ Операционная память для агентских процессов на Папках задач 1/4 Буду потихоньку накидывать терминологии и концепций. Это статья логически связана с "Агентными процессами". Поговорим об Agentic memory и варианту реализации этого механизма на такой штуке как "Папка задач". Операционной памятью агентов является контекст и только контекст, всегда. Нюанс в том, что его всегда не хватает. По дизайну, механизм обмена информацией у оркестратора с агентами очень простой: "вызов" агента происходит как рядовой вызов/мультивызов инструмента (tool calls), только работа инструмента получается довольно долгой. При вызове оркестратор формирует как параметр вызова инструмента промпт, где указывает задание субагенту. Агент грузит свой промпт, и стартует с сообщения оркестратора, выполняет работу, вызывает необходимое количество инструментов, и последнее сообщение агента будет "ответом" оркестратору, которое будет "сообщено" ему в его контекст как результат вызова инструмента "субагент". Мы видим, что течение информации довольно скромное: сообщение "оркестратор" -> "агент" в начале работы, сообщение "агент" -> "оркестратор" в конце. Не самая интенсивная коммуникация! Буквально в режиме "Здравствуй и прощай". При этом "заставить" оркестратора быть многословным и сообщить все детали агенту удаётся не всегда. Чем более "забит" контекст оркестратора, чем больше и разнообразнее там информация, тем сильнее "размывается" внимательность оркестратора. Если мы все детали процесса держим только в контексте, он будет не только забиваться, но и там будет много шума, что дополнительно "размывает" внимание. Что делать? Сильно ситуацию улучшила возможность создания типизированных субагентов, каждый со своим промптом. Теперь нам достаточно из оркестратора вызывать не просто агента, а "специального поискового агента по кодовой базе", в системном промпте которого мы сможем разместить все детали, как искать по кодовой базе, какая у неё структура, где смотреть детали и так далее. Оркестратору будет достаточно просто сообщить что нужно искать. Но для улучшения коммуникаций внутри агентных процессов мы можем использовать механизм "Папка задачи". ... (продолжение тут: https://t.me/deksden_notes/37) #post @deksden_notes

🐞 Неприятный баг в Claude Desktop В последней версии Claude Desktop обнаружился неприятный баг. Я его использую с Desktop Commander MCP для планирования, следовательно, со старта мне нужен Opus и поумнее, то есть "Extended thinking" включена. Стартую я новые чаты с проекта, для которого слегка прописано в Project Instructions чего и как, чтобы в промпт каждый раз не писать Баг: даже если включаешь Extended Thinking со старта, чат стартует без него. В итоге, мало того, что свежий опус думает по 3-4 секунды, так ещё и думание это включать отказывается! А мне это существенно даже для первого сообщения - контекст в claude desktop совсем не похож размером на AI Studio + Gemini 2.5 Pro. ☝️Workaround: останавливаем генерацию ответа, включаем extended thinking, редактируем запрос - генерация запускается уже в режиме thinking. PROFIT! П.с. Индикации окончания контекста так и нет - позор какой то, конечно. #post @deksden_notes

😇 Гугл - боги нейминга #sidenote Ура! Первые следы Gemini-3.0 обнаружены на просторах интернетов (видимо, в репо gemini cli). Нейминг меня прям расслабил! Подушню, но это забавно же: не gemini-3.0.-pro-beta, а gemini-beta чуть ниже gemini-experimental, не -exp, и v2 вместо 2.0! В общем, боги нейминга! 😁 Но тебе можно больше, если ты выпускаешь топовые модели, с топовыми бенчами, с самым большим контекстом. Если ещё агентность докрутят, точность тулколов, и внимание в cli соберут, и контекст ... - то совсем 🔥 Ждём, ждём #link @deksden_notes

😎 Совпадение?.. Не думаю! #sidenotes Только сейчас обратил внимание на то, что лимиты Жульеса при релизе смутно напоминают чего то ... Не могу вспомнить где я видел такую же кратность к базе - x5 / x20!.. " - Музыка навеяла!" (шикарный анекдот, конечно) https://blog.google/technology/google-labs/jules-now-available/ #link @deksden_notes

😬 Свежая идея: AI - чипы с трекингом (не только?) геолокации #sidenotes Omfg. И эти люди что то там говорили про HUAWEI ! "Все - одинаковые!" https://www.bloomberg.com/news/articles/2025-08-05/us-explores-better-location-trackers-for-ai-chips-official-says #link @deksden_notes

📝 #sidenote Заметки на полях Я уже как то упоминал, что инвесторы курсора на самом деле инвесторы в антропиков. пруф: https://t.me/ai_machinelearning_big_data/8210 #link @deksden_notes

☝️Agentic WFs vs традиционные алгоритмы Прекрасный кейс родился у Дениса @ataden У него совершенно гениальная способность встречать баги! В СС ему встретилось уже 2, и оба подтвердились на github. Очередной был вскрыт накануне, но оказался не багом, а фичей. Исследуя траффик как СС "в потрохах" общается со своей штаб-квартирой, Денис обратил внимание, что файл CLAUDE.md совсем не упоминался в контексте, хотя документация говорит что он читается регулярно, как минимум - в начале сессии. То есть в контексте он быть должен, но его нету. Ларчик открылся просто: имя файла на его машине было CLAUDE.MD (расширение написано крупными буквами). А ожидался файл CLAUDE.md (маленькие буквы в расшиении). Так как в СС файл грузится обычным ts кодом, а не промптом агента, то код не находил требуемого файла (с расширением ".md") и тихонько продолжал работу без каких либо жалоб. С этим разобрались, файл таки грузится (хотя и с нюансами), но зато получился шикарный пример отличия работы агентных процессов от традиционного кода. Когда в чате CC попросили прочитать AGENTS.md, агент попытался, не нашёл файл, прочитал каталог, увидел похожий и молча загрузил его. Агентный код грузит файл. То есть степень гибкости агентного процесса - она агентная! Вот какой интересный опыт 🔥 #post @deksden_notes

⏳ Обновление списка агентов Claude Code Небольшое, но важное уточнение. Если дорабатываете систему, и делаете новых агентов, то СПИСОК агентов загружается claude code ПРИ СТАРТЕ. То есть папка "agents/" обрабатывается и читается frontmatter у агентов ПРИ СТАРТЕ. Далее, похоже, эта информация НЕ обновляется, даже если вы обновили файлы на диске. Например, вы добавили нового агента, и ждете чтобы workflows его подхватили. Нет, СС не "увидит" нового агента до перезапуска ("/clear" не помогает). Видимо, изменения модели или описания агента (вы можете яснее немного его обозвать) тоже подгружаются на старте. Если вы меняете промпт агента, тут, вроде бы, попроще: он будет подгружаться при запуске нужного агента - изменения в промпте агент подхватит. Общий вывод - чтобы не запутаться, перезапускайте сам СС при обновлении агентов! Благо флаг "--resume" вернет вас ровно в точку остановки предыдущей сессии. П.с. Надо будет обновит пост про агентов #post @deksden_notes

⚡️ Агентные процессы (Agentic Workflows) в Claude Code 2/2 ( ... начало тут: https://t.me/deksden_notes/27 ) 4️⃣ "Вызовы" процессов Если нам нужно сделать "вызов" какого либо процесса в Claude Code, то я уже писал - сейчас существуют ограничения. Возможен только вариант "Оркестратор" - "Субагент", вариант "Оркестратор" - "Субагент" - "Субагент" уже не поддерживается. Поэтому попытка использовать субагента как "подпрограмму" не работает, потому что субагент лишается возможности вызова инструментов. Зато "goto" к какому то процессу можно сделать легко, просто сказав "А теперь продолжай с процесса Х". Что, если нам нужно не "goto", а имитация "вызова" процесса с возвратом в исходную точку? тут надо имитировать "стек", путем дополнительного инструктирования. В простых ситуациях, когда мы не очень ожидаем что оркестратор "забудет" наши инструкции, можно просто сказать "выполни процесс Х и после его завершения вернись и продолжай с этого места". Но есть нюанс: контекст. После выполнения процесса из за длительности и загрузки контекста, инструкция "возврата" может быть забыта. Можно попробовать имитировать "стек" путем создания специального файла md с текущим контекстом - куда мы попросим оркестратора записать где мы сейчас находимся, какая текущая задача, какой процесс мы выполняем, что важное для нее надо помнить, что нужно делать следом. И инструктируем "выполни процесс Х и после его завершения прочитай файл Y и следуй инструкциям в нем". В общем, с "вызовами" процессов - это исключительно творчество, в ожидании снятия ограничений на более надежные способы организации flow. 5️⃣ Внешние скрипты Важно понимать - у моделей есть свои ограничения. Им сложно выполнять детерминированную работу (прочитать 300 файлов, из них убрать 5 файлов по некоему критерию, остальные переместить в другую папку). Но иногда в процессах есть необходимость такие активности делать. Тут не нужно забывать о возможности легко вызвать любой внешний скрипт. Например, typescript-программу через tsx. Модель мало того, что может вызвать скрипт. Она вполне разумно и гибко может отреагировать на результаты его выполнения. А если вспомнить, что модель предварительно может написать код - то возможности и гибкость такого сетапа сложно недооценить. ✨ Что можно делать агентными процессами "Много чего" (ц) Агентные процессы дают огромную гибкость в быстром создании достаточно сложных процессов, которые традиционными алгоритмами делать намного дольше. Например, у меня недавно задача создания ETL системы импорта пачками docx, pdf, xlsx, xls, img (всех видов), с OCR, извлечения из них сущностей (смыслов), промежуточное накопление этих сущностей, презентация их пользователю, трансформация в иную логику структурирования с презентацией этой логики пользователю и наконец сохранение "в другом формате" итоговой документации, но со ссылками на "источники" - все это заняло у меня чуть больше полдня. А теперь оцените сколько нужно времени чтобы написать код, решающий такие задачи. Фактически, просто за счет формирования чистой логики этого процесса с минимальным ее структурированием уже получена система, которая делает работу. 🏅 Мораль: агентные процессы - прикольная и мощная штука Upd: - Нюансы загрузки списка агентов: https://t.me/deksden_notes/29 ␄ #post @deksden_notes

⚡️ Агентные процессы (Agentic Workflows) в Claude Code 1/2 Давайте поговорим о такой интересной штуке, как агентные процессы (workflows). ⚙️ Что такое агентные процессы (agentic workflows)? Их важно отличать от обычных алгоритмических процессов: · агентные процессы - это промпты для ИИ агентов, которые описывают некую последовательность действий · исполняет эти процессы ИИ агент, мы используем Claude Code · агентные процессы по своей структуре могут быть очень похожи на обычные алгоритмы - шаги, условные ветвления, циклы, "вызовы" других процессов, вызовы внешних команд · суть агентского процесса - в возможности использования логики ИИ модели в процессе непосредственно; · нечеткая логика ИИ является и самым сильным преимуществом, и важной особенностью процессов, с которой надо работать Использование этого подхода позволяет быстро собирать очень сложные системы, которые задействуют потенциал моделей и позволяют определять процессы, выполняющиеся часами. ❓ Как это сделать? Четких правил нет, я могу лишь обобщить практику, которую я использую. Уверен, что можно и нужно что то делать иначе, лучше, правильнее - но расскажу как я понимаю на сейчас. ⚠️ Важно: это мое субъективное мнение, которое совсем не претендует на правду, лишь резюмирует практику. Паттерны и приемы для работы с агентными процессами Я храню описание процессов в memory bank проекта в отдельной папке (wfs/) в виде md файлов. Чтобы запустить процесс, есть кастомная слеш команда, которая инструктирует агента прочитать некий файл и следовать инструкциям в нем. 1️⃣ Концепция "файлы-роутеры". Это такой md файл, инструкции в котором направляют агента для чтения других файлов, там буквально написано так: "Если (некое условие), то нужно прочитать файл (ссылка на файл) и выполнить инструкции в нем". Я использую этот прием для маршрутизации инструкции пользователя к нужному процессу. Если все процессы записать в один файл и "вызывать" нужный, то помимо "забивания" контекста ненужными в данный момент процессами, происходит размывание внимания и агент может отвлекаться на инструкции из других процессов или просто терять внимание на обработку ненужной информации. Поэтому цепочка "центральный роутер -> роутер группы процессов -> процесс" это стандарт в моем мемори банке. Пример: "index.md -> wf-dev -> wf-dev-1" запускает мой процесс "проработка эпика/фичи". 2️⃣ Концепция "mermaid схемы процесса". Интересный факт: модели лучше понимают "язык" диаграмм mermaid для описания последовательности действий, чем текстовое описание. Впрочем, если подумать, - это логично: диаграмма короче, нагляднее, структурно построена, следует определенному синтаксису. Видимо, обучающие выборки моделей включали изрядное количество диаграмм в md файлах - а это преимущественно mermaid. Мы можем использовать диаграммы для описания процесса: просто попросите агента вам ее сделать по тексту. Может быть вы удивитесь что она "не такая" - а на самом деле я пару раз так отлавливал недостаточно ясные формулировки в процессах (дело касалось циклов). Идеальный вариант, если агент проставит вам для каждого шага процесса уникальный идентификатор (для wf-dev-1 у меня шаги это DEV1-1, DEV1-2, и так далее). Идентифкация шага вносит дополнительную ясность модели. 3️⃣ Вызов субагента Самая важная часть вашего процесса. Я ВСЕГДА сейчас строю даже несложные процессы как взаимодействие центрального агента (всегда называю его оркестратором) и субагента. Почему? Экономия контекста, изоляция от спама результатами тулколов в центральный контекст. Задача оркестратора - только следить за выполнением основного процесса, а шаги мы все выполняем в субагентах. Если для шага требуется формировать специфический контекст - то делается специальный агент под такую задачу, для которого прописываем специфический промпт. Задача оркестратора - только передать то, с чем работаем. А "КАК" работать - специализированный агент уже знает сам. ... (продолжение: https://t.me/deksden_notes/28) #post @deksden_notes

Grok 4 в доступе Что конкуренция животворящая делает! Теперь Grok4 доступен без подписки https://grok.com/ #news @deksden_notes

Google Jules : фонтан новостей августа 2025 Буквально за короткое время у нас фонтан новостей от jules. Первая, и самая важная: julse теперь не бэта! У нас релиз! из хорошего: бесплатные задачи не отменили, они остаются. Коммерческие планы привязаны к AI подписке (Pro/Ultra). Higher access to the latest model (starting with Gemini 2.5 Pro) * Jules (free): 15 daily tasks, 3 concurrent * Jules (pro subs): 100 daily, 15 concurrent * Jules (ultra subs): 300 daily, 60 concurrent Из интересного: для pro/ultra туманно сказано что Higher access to the latest model (starting with Gemini 2.5 Pro). Намёк на 3.0?)) И технические улучшения: * bun runtime добавлен * теперь можно делать не просто branch с результатами работы, а сразу PR * для старта задач позволяют делать снэпшоты окружения после скрипта инициализации - старт задач более быстрый * интегрировали playwright в стандартный образ VM (!!!) и теперь можно обсуждать скриншоты и в целом проводить полноценные e2e тесты * добавлен агент-критик (!!!) и теперь весь сгенерированный код проходит такое вот ревью; значит когда я добавляю в каждый процесс этап ревью, это вполне принятый подход; * интерактивное планирование: задачу можно запустить в режиме обсуждения плана - важно когда план может быть не совсем очевидным для агента, и он готов его с вами обсудить в чате до утверждения; добавили поиск к агенту: он ищет документацию, сниппеты кода и подходы к решению каких то задач! реально усиливает работу с последними версями библиотек, которые могут быть не знакомы модели; Мощное развитие технологии! Jules радует значительно сильнее Gemini CLI. Когда же api для встраивания его в свой pipeline? https://jules.google/docs/changelog #news

🔥 Субагенты в Claude Code 5/5 🏁 ИТОГИ Система работы с субагентами в СС получила неплохое развитие в последнее время. Спасибо антропикам за продуманный дизайн системы и сделанные важные улучшения, они довольно полезные. Какие остались ограничения? Пока "глубина" вызова субагентов - два элемента. То есть работает схема "оркестратор" - "субагент", но нельзя делать вызов "Оркестратор" - "субагент" - "субагент". То есть, если вы в вашем воркфлоу вызовете другой воркфлоу на субагентах, это не заработает, потому что субагенты другого воркфлоу не смогут запуститься. В итоге, построить процессы классическим функциональным подходом не выходит. Однако "вызов" процесса можно сделать в inline стиле, когда мы инструктируем агента перейти к указанному процессу, а по завершении - продолжить с места вызова. Для "надёжности" можно прописать "возврат" к месту вызова как задачу в TodoWrite. В итоге работают и "подпрограммы", хотя и способ немного хлопотный, требует внимательного промптинга и отладки при первых запусках. Ограничения вложенных вызовов - оно в дизайне, а не техническое. Можно предположить что ограничение вызвано желанием предотвратить рекурсивные вызовы неясной глубины, которые могут случиться из за неполной детерминированности агентского процесса. Все таки - это не код, который выполняется всегда одинаково, в агентских процессах возможны варианты. Однако в будущем возможно изменение этого подхода и/или появление механизмов контроля. Думаю, необходима практика - давайте её получать! #post ␄

🔥 Субагенты в Claude Code 4/5 🤖 Субагенты Так мы жили до версии 1.0.60, в которой появились "Sub-Agents" - субагенты. В этой версии добавлены принципиально важные дополнения к функциональности субагентов: - теперь мы можем объявлять разные типы субагентов в специальной папке "agents" конфигурации (для проекта или на уровне системного пользователя); - указываем модель, которая будет использована для субагента: opus/sonnet/haiku - указываем набор инструментов, доступный субагенту - для визуальной индикации запуска субагента в UI можно указать цвет ‼️ Чем принципиально важны нововведения? ☝️ Отдельный системный промпт кардинально решает проблему качества работы субагента: он получает свои собственные, чётко определённые и с гарантией попадающие ему инструкции. Больше нет необходимости требовать от оркестратора прописывать какие то детали задания субагенту - эти детали можно просто внести в промпт субагента. Теперь можно с высокой точностью собрать контекст под задачу! Это решает проблему "забывания" и игнорирования инструкций, генерации кода с ошибками, и подобное. Далее - указание модели. Теперь стало возможным задачи планирования и анализа проводить "более умной" моделью opus, а непосредственное написание кода - дефолтным Sonnet. А простые задачи делегировать быстрому haiku. Удобно, и дополнительно повышает качество работы! Определения инструментов позволяют дополнительно настроить контекст субагента, выключив ненужные ему инструменты, или, наоборот, подключив нужные MCP. В результате мы получили возможность очень точной настройки процессов, построенных на субагентах. Качество работы звсей системы аметно повысилось, особенно при выполнении сложных workflow с многими этапами. ▶️ Как происходит выбор агента? Когда СС необходимо запустить субагента, система смотрит список доступных ей агентов. В зависимости от контекста команды запуска, по описаниям субагентов выбирается нужный. Стартуется субагент с указанием нужной модели и инструментов, ему загружается его системный промпт, а также задание оркестратора, и субагент приступает к работе. ▶️ Чем "субагент" отличается от "задачи"? Задача не кастомизируется - нет отдельного промпта, только промпт от оркестратора. Нет выбора модели или инструментов. Технически "под капотом" это один и тот же инструмент agentTool, но возможности кастомизации субагентов выводят их на новый уровень, делая заметной инновацией. #post

🔥 Субагенты в Claude Code 3/5 Продолжим. Что нам дал инструмент "задача"? Уже стало неплохо за счёт важного свойства - самостоятельного контекста задачи. Можно было делать длинные сессии работы оркестратора, промптом заставляя вести основную работу внутри задач. В результате последовательные линейные воркфлоу даже из значительного количества шагов выполнялис в челом неплохо. Можно было довести длительность сессии работы оркестратора до десятков минут, а самые талантливые умудрялись "выжимать" часы! Это важно, потому что время отражает количество сделанной полезной работы. Какие были подводные камни? Их было несколько: - управление работой инструмента "задача" осуществлялось оркестратором, и полностью зависело от него; когда у оркестратора в контексте было много информации, происходила деградация внимания, и он уже не мог внимательно и с требуемыми деталями прописывать задачи. - задача наследовала от родительского процесса инструменты, и нельзя было настроить инструменты, доступные отдельной "задаче", в результате чего аналитические или поисковые задачи работали в контексте с им абсолютно не нужным условным менеджером БД postgres. - работа всей системы (оркестратора и задач) велась с выбранной моделью ☑️ Резюмируем проблемы: точность промпта, контекст инструментов, модель. Что мы могли видеть в работе, симптомы проблем? При попытках прописать "навороченный" flow оркестратору на поздних шагах происходила некоторая деградация внимания оркестратора, и он мог "забыть" указать важные вещи. Далее: убедить оркестратора писать длиныне подробные промпты почти невозможно: они выходят краткие и без требуемых деталей. Далее: оркестратор может заниматься "самодеятельностью" и добавлять в промпт чего то "от себя" в зависимости от полученного контекста. Например, задача поиска информации могла потом чего то этой информацией обновить, если оркестратору показалось что это актуально. #post

🔥 Субагенты в Claude Code Простой пример с картинками - оркестратор и задача 2/5 Давайте рассмотрим простой с картинками - запустили СС, попросили промптом выполнить некую задачу и СС запускает инструмент Task (1). Можно увидеть что в ui действия задачи с инструментами отражаются, далее инструмент завершает работу, и отдаёт результат оркестратору, и оркестратор распоряжается ими в своём контексте. В нашем случае - сообщает пользователью (2). Обратите внимание что задача работала довольно долго, даже по такому несложному запросу. "Под капотом" происходит все немного более многословно - запустив Claudia и проанализировав сессию, можно увидеть запуск инструмента задачи, увидеть промпт от оркестратора, на английском кстати (3). Следом начинается лог работы задачи, запуск инструментов (4). Последнеё сообщение в сессии работы задачи это резюме работы. Именно оно возвращается оркестратору, который его использует в своём контексте (5). Видно, что задача работала на английском, а оркестратор - на русском. И по языку явно видно что итоговое сообщение пользователю было сформировано именно оркестратором, но на основании информации от задачи. Для просмотра сессии использована Claudia #post

🔥 Субагенты в Claude Code 1/5 Решил написать обзор фишки субагентов в Claude Code (далее - сокращаем до общепринятого СС). ⏳ История вопроса уходит к первому публичному релизу СС. В ту пору субагенты были "обычным" инструментом Task - так он указывался в интерфейсе, но в исходном коде они сразу были названы AgentTool. Давайте для ясности далее будем называть его задачей (именно так, не субагентом или агентом, - почему объясню далее). Это был простой инструмент: основной агент (будем дальше для ясности называть его **оркестратором**), это тот, с которым вы непосредственно общаетесь интерактивным чатом, вызывает инструмент Task, передаёт ему "задание" (промпт). Далее задача работает в отдельном контексте самостоятельно и возвращет результат оркестратору. В ходе работы задачи в интерфейсе СС мы видим некие сообщения о происходящих действиях, и все это пишется в json в сессию. Если есть желание почитать подробнее - можно использовать инструменты типа Claudia. #post (продолжение: https://t.me/deksden_notes/17)