🔥 Субагенты в Claude Code
3/5
Продолжим.

Что нам дал инструмент "задача"? Уже стало неплохо за счёт важного свойства - самостоятельного контекста задачи. Можно было делать длинные сессии работы оркестратора, промптом заставляя вести основную работу внутри задач. В результате последовательные линейные воркфлоу даже из значительного количества шагов выполнялис в челом неплохо. Можно было довести длительность сессии работы оркестратора до десятков минут, а самые талантливые умудрялись "выжимать" часы! Это важно, потому что время отражает количество сделанной полезной работы.

Какие были подводные камни? Их было несколько:

- управление работой инструмента "задача" осуществлялось оркестратором, и полностью зависело от него; когда у оркестратора в контексте было много информации, происходила деградация внимания, и он уже не мог внимательно и с требуемыми деталями прописывать задачи.
- задача наследовала от родительского процесса инструменты, и нельзя было настроить инструменты, доступные отдельной "задаче", в результате чего аналитические или поисковые задачи работали в контексте с им абсолютно не нужным условным менеджером БД postgres.
- работа всей системы (оркестратора и задач) велась с выбранной моделью

☑️ Резюмируем проблемы: точность промпта, контекст инструментов, модель.

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


#post

🔥 Субагенты в Claude Code
4/5

🤖 Субагенты

Так мы жили до версии 1.0.60, в которой появились "Sub-Agents" - субагенты. В этой версии добавлены принципиально важные дополнения к функциональности субагентов:
- теперь мы можем объявлять разные типы субагентов в специальной папке "agents" конфигурации (для проекта или на уровне системного пользователя);
- указываем модель, которая будет использована для субагента: opus/sonnet/haiku
- указываем набор инструментов, доступный субагенту
- для визуальной индикации запуска субагента в UI можно указать цвет

‼️ Чем принципиально важны нововведения? ☝️
Отдельный системный промпт кардинально решает проблему качества работы субагента: он получает свои собственные, чётко определённые и с гарантией попадающие ему инструкции. Больше нет необходимости требовать от оркестратора прописывать какие то детали задания субагенту - эти детали можно просто внести в промпт субагента. Теперь можно с высокой точностью собрать контекст под задачу! Это решает проблему "забывания" и игнорирования инструкций, генерации кода с ошибками, и подобное.

Далее - указание модели. Теперь стало возможным задачи планирования и анализа проводить "более умной" моделью opus, а непосредственное написание кода - дефолтным Sonnet. А простые задачи делегировать быстрому haiku. Удобно, и дополнительно повышает качество работы!

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

В результате мы получили возможность очень точной настройки процессов, построенных на субагентах. Качество работы звсей системы аметно повысилось, особенно при выполнении сложных workflow с многими этапами.

▶️ Как происходит выбор агента? Когда СС необходимо запустить субагента, система смотрит список доступных ей агентов. В зависимости от контекста команды запуска, по описаниям субагентов выбирается нужный. Стартуется субагент с указанием нужной модели и инструментов, ему загружается его системный промпт, а также задание оркестратора, и субагент приступает к работе.

▶️ Чем "субагент" отличается от "задачи"? Задача не кастомизируется - нет отдельного промпта, только промпт от оркестратора. Нет выбора модели или инструментов. Технически "под капотом" это один и тот же инструмент agentTool, но возможности кастомизации субагентов выводят их на новый уровень, делая заметной инновацией.

#post

🔥 Субагенты в Claude Code
5/5
🏁 ИТОГИ

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

Какие остались ограничения? Пока "глубина" вызова субагентов - два элемента. То есть работает схема "оркестратор" - "субагент", но нельзя делать вызов "Оркестратор" - "субагент" - "субагент". То есть, если вы в вашем воркфлоу вызовете другой воркфлоу на субагентах, это не заработает, потому что субагенты другого воркфлоу не смогут запуститься.

В итоге, построить процессы классическим функциональным подходом не выходит. Однако "вызов" процесса можно сделать в inline стиле, когда мы инструктируем агента перейти к указанному процессу, а по завершении - продолжить с места вызова. Для "надёжности" можно прописать "возврат" к месту вызова как задачу в TodoWrite. В итоге работают и "подпрограммы", хотя и способ немного хлопотный, требует внимательного промптинга и отладки при первых запусках.

Ограничения вложенных вызовов - оно в дизайне, а не техническое. Можно предположить что ограничение вызвано желанием предотвратить рекурсивные вызовы неясной глубины, которые могут случиться из за неполной детерминированности агентского процесса. Все таки - это не код, который выполняется всегда одинаково, в агентских процессах возможны варианты. Однако в будущем возможно изменение этого подхода и/или появление механизмов контроля. Думаю, необходима практика - давайте её получать!

#post
␄

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

Grok 4 в доступе

Что конкуренция животворящая делает! Теперь Grok4 доступен без подписки

https://grok.com/

#news
@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

⚡️ Агентные процессы (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

⏳ Обновление списка агентов Claude Code

Небольшое, но важное уточнение. Если дорабатываете систему, и делаете новых агентов, то СПИСОК агентов загружается claude code ПРИ СТАРТЕ. То есть папка "agents/" обрабатывается и читается frontmatter у агентов ПРИ СТАРТЕ. Далее, похоже, эта информация НЕ обновляется, даже если вы обновили файлы на диске.

Например, вы добавили нового агента, и ждете чтобы workflows его подхватили. Нет, СС не "увидит" нового агента до перезапуска ("/clear" не помогает). Видимо, изменения модели или описания агента (вы можете яснее немного его обозвать) тоже подгружаются на старте.

Если вы меняете промпт агента, тут, вроде бы, попроще: он будет подгружаться при запуске нужного агента - изменения в промпте агент подхватит.

Общий вывод - чтобы не запутаться, перезапускайте сам СС при обновлении агентов! Благо флаг "--resume" вернет вас ровно в точку остановки предыдущей сессии.

П.с. Надо будет обновит пост про агентов

#post
@deksden_notes

☝️Agentic WFs vs традиционные алгоритмы

Прекрасный кейс родился у Дениса @ataden

У него совершенно гениальная способность встречать баги! В СС ему встретилось уже 2, и оба подтвердились на github. Очередной был вскрыт накануне, но оказался не багом, а фичей.

Исследуя траффик как СС "в потрохах" общается со своей штаб-квартирой, Денис обратил внимание, что файл CLAUDE.md совсем не упоминался в контексте, хотя документация говорит что он читается регулярно, как минимум - в начале сессии. То есть в контексте он быть должен, но его нету.

Ларчик открылся просто: имя файла на его машине было CLAUDE.MD (расширение написано крупными буквами). А ожидался файл CLAUDE.md (маленькие буквы в расшиении). Так как в СС файл грузится обычным ts кодом, а не промптом агента, то код не находил требуемого файла (с расширением ".md") и тихонько продолжал работу без каких либо жалоб.

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

Когда в чате CC попросили прочитать AGENTS.md, агент попытался, не нашёл файл, прочитал каталог, увидел похожий и молча загрузил его. Агентный код грузит файл.

То есть степень гибкости агентного процесса - она агентная! Вот какой интересный опыт 🔥

#post
@deksden_notes

📝 #sidenote Заметки на полях


Я уже как то упоминал, что инвесторы курсора на самом деле инвесторы в антропиков.


пруф: https://t.me/ai_machinelearning_big_data/8210


#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

😎 Совпадение?.. Не думаю!
#sidenotes


Только сейчас обратил внимание на то, что лимиты Жульеса при релизе смутно напоминают чего то ... Не могу вспомнить где я видел такую же кратность к базе - x5 / x20!..

" - Музыка навеяла!" (шикарный анекдот, конечно)



https://blog.google/technology/google-labs/jules-now-available/

#link
@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

🐞 Неприятный баг в 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

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


Буду потихоньку накидывать терминологии и концепций. Это статья логически связана с "Агентными процессами". Поговорим об Agentic memory и варианту реализации этого механизма на такой штуке как "Папка задач".

Операционной памятью агентов является контекст и только контекст, всегда. Нюанс в том, что его всегда не хватает.

По дизайну, механизм обмена информацией у оркестратора с агентами очень простой: "вызов" агента происходит как рядовой вызов/мультивызов инструмента (tool calls), только работа инструмента получается довольно долгой. При вызове оркестратор формирует как параметр вызова инструмента промпт, где указывает задание субагенту.

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

Мы видим, что течение информации довольно скромное: сообщение "оркестратор" -> "агент" в начале работы, сообщение "агент" -> "оркестратор" в конце. Не самая интенсивная коммуникация! Буквально в режиме "Здравствуй и прощай".

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

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

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

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

#post
@deksden_notes

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

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

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

(...продолжение, предыдущая часть тут: https://t.me/deksden_notes/38)


❓ А что за магическая цифра "разбивать по 5 файлов"?

На самом деле, именно 5 тут приведено просто для примера, но суть в том, что не надо делать такую задачу без ограничений количества файлов. Работа с файлами неслабо так нагружает контекст - все эти чтения фрагментов чтобы создать изменения, все они остаются в контексте. Если субагент получит неконтролируемого размера кучу файлов для обработки, уже у него кончится контекст - со всеми непредсказуемыми последствиями данного обстоятельства. А мы же хотим качественно и надёжно все сделать, да?

❓ Ок, но зачем так экономить контекст оркестратора? откуда такая сокральная ценность его контекста?

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

А что касается именно оркестратора - то его "чистый" контекст - это возможность выполнения сложных и продолжительных агентских процессов. 2-3 шага нашего примера процесса были не самыми простыми по логике выполнения, но "потратили" не более 1% контекста, значит смело можно делать процесс где таких шагов будет ещё 50.

☝️ Выводы

Сочетание приёмов и принципов:

- экономия контекста
- использование агентных процессов (врокфлоу на субагентах)
- конфигурирование агентов
- использование папки задач как механизма обмена

... позволяет "выжимать" потенциал Claude Code и реализовывать сложные, полезные и умные процессы!

Stay tuned, серия статей "to be continued"


␄
#post
@deksden_notes

⚡️🔥 Sonnet4 1m context (!!!)
#sidenote

Big if big!

Почти x2 к цене API на контекстах выше традиционных 200к, но, блин! Интересно

Ждём бенчей

https://www.anthropic.com/news/1m-context

---
UPD: В Claude Code .74 уже предлагает при заполнении контекста переключиться на модель sonnet[1m], но на подписках пока не работает:

API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"The long context beta is not yet available for this subscription."}}

---
UPD-2: Я так понимаю летний апдейт соннета - это как раз sonnet4[1m]

Уже .77 и все без release notes. Чего то прикручивают!

#link
@deksden_notes

🙇‍♂️ "Умные" вызовы "умных" агентов (smart calling)


Продолжим серию постов с "азбукой" агентных процессов - нам нужно выучить некоторые новые "буквы". Сегодня поговорим о "smart calling" - практическом приёме "умного" вызова "умного" агента. Этот приём пригодится для выстраивания сложных агентных процессов, и сможет некоторым образом повышать надёжность и usability работы.

▶️ Напомним базу

Оркестратор и агент общаются через контекст и промпты. Оркестратор при вызове пишет промпт для вызова агента, агент отрабатывает и пишет "сообщение" оркестратору с результатами работы.

Несмотря на явную аналогию с вызовом функции в классических алгоритмах, мы имеем нюансы: схема "вызова" никак не типизирована и ничем особенным не ограничена - просто текстовое сообщение. Впрочем, ровно как и ответ агента! Это имеет свои последствия.

ℹ️ Аргументы "вызова" - проверка, верификация

Первое, при старте агента если он специализирован на выполнении какой то работы, лучше верифицировать что ему сообщил оркестратор. "Проверить аргументы вызова", так сказать, а может быть ещё и верифицировать - формат, и наличие. То есть посмотреть, например, существует указанный файл или нет.

🛑 "Выбрасывание ошибки"

Что делаем если что то не в порядке и это критично, мы не можем исправить? Например, сказано что необходимо анализировать отчёт, а отчёта по указанному пути мы не нашли.

Мы "выбрасываем ошибку" - инструктируем агента что в таком случае мы прекращаем работу и пишем ясное сообщение о причинах.

🔃 Возврат результатов

Мы уже обсудили с вами на темах "agentic memory" и "папка задачи" важность беречь контекст оркестратора. Объёмные результаты мы помещаем в папку задачи. Короткие результаты возвращаем текстом, проинструктировав агента что при завершении работы он их должен сообщить.

🤓 Где же тут "умное" (smart)?

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

Тут инструкцию исполняет агент, а значит он может использовать всю свою нечёткую логику и когнитивные способности - нужно только попросить.

В контекст "агента" мы можем подгрузить описание блока функциональности с логикой работы. Допустим, у вас создан специальный агент по работе с базой документации в проекте (спецификации - описание эпиков и фич). Вы можете подгрузить правила оформления эпиков и фич в такого агента, и проинструктировать чтобы оркестратор сохранял описание эпиков и фич не через тул Writefile, а через этого специализированного агента.

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

Также можно применить приём "умные результаты": когда мы не только вернули запрошенные данные, но и дали пояснения к ним относительно их использования, а также контекста. Например, возвращаем статус эпика и говорим что с ним можно делать дальше (это специализированный агент возьмёт из описания ваших процессов работы с эпиком). Или агент создания папки задач вернёт подсказку, что папка задач создана с "точкой" в начале имени, это делает её "невидимой" среди обычных файлов, поэтому нужно применять специальные опции для bash команд для её обнаружения. Интересные результаты можно получить от инструкции в промпте агента "а также добавь в итоги работы то, что считаешь важным и необходимым".

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

␄
#post
@deksden_notes