Specs - это новый код

🔹 Наверное, тоже надо зафиксировать! Спеки - это новый код. Под спеками понимаю всю совокупность:

- memory bank с эпиками/фичами, гайдами, steering, design и прочими структурами.

- процессы для ИИ агентов + системпромпты агентов + кастомные команды

- докстринги всех видов: jsdoc, тэги, реферальные ссылки в коде

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

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

Думаю уже и язык реализации системы может особого значения не иметь - лишь бы в обучающей выборе модели пистутствовал! А паттерны модель все ранво обобщает - сможет на любом языке выразить.

#post
@deksden_notes

Оглавление постов в канале (и чат):

* Чат 💬 :: https://t.me/+B1fB3sZbaVthMDhi
* ‼️ Правила канала: https://t.me/deksden_notes/478

——
👉 2026.01 🆕 : скиллы от подписчиков https://t.me/deksden_notes/387


---

Статьи:

⚡️AI Software Engineering: От хаоса Vibe Coding к системной разработке с AI-агентами (хабр) - введение в меморибанк

Я - соавтор, с Дмитрием @filippov_dm :: https://t.me/deksden_notes/15

⚡️ Calude-Code: субагенты (хабр)
https://t.me/deksden_notes/88

⚡️ 6 советов от практиков AI coding:
С Тимуром @yatimur
https://habr.com/ru/articles/997098/
---

‼️ ИИ-Словарик: Термины из мира AI SWE :: https://t.me/deksden_notes/174
- Учить и повторять перед сном

——

Большая серия постов про #deksdenFlow - мой флоу разработки:

👉 вот стартовый пост: https://t.me/deksden_notes/197
остальные идут следом, и поиск по тегу #deksdenFlow собирает все по теме в канале! Пользуйте тег

——

## Посты (#post):

* Лимиты Anthropic's Claude / Claude Code (2) :: https://t.me/deksden_notes/4
* AI IDE vs AI SWE :: https://t.me/deksden_notes/6
* Specs - это новый код :: https://t.me/deksden_notes/8
* Когда возможностей модели не хватает (2) :: https://t.me/deksden_notes/11
* 🐞 Неприятный баг в Claude Desktop :: https://t.me/deksden_notes/35
* 📦 Memory bank через Obsidian :: https://t.me/deksden_notes/43
* 📦 Пакуем проекты с Repomix: https://t.me/deksden_notes/102
* ♊️ Планируем с Gemini : https://t.me/deksden_notes/104


## Серия статей про агентные процессы:

* 🔥 Субагенты в Claude Code :: https://t.me/deksden_notes/16
- ⏳ Обновление списка агентов Claude Code :: https://t.me/deksden_notes/29

* ⚡️ Агентные процессы (Agentic Workflows) в Claude Code (2) :: https://t.me/deksden_notes/27
* 🗃️ Операционная память для агентских процессов на Папках задач (4):: https://t.me/deksden_notes/36
- 🤓 Простой пример для простого примера - доносим смыслы : https://t.me/deksden_notes/42
* ⚛️ Атомарные Duo файлы :: https://t.me/deksden_notes/49
* 🧩 Управление агентным контекстом :: https://t.me/deksden_notes/50

-—

▶️ Контекст-инжиниринг для меморибанков:

* индексные файлы index.md : https://t.me/deksden_notes/46
* 📂 Фронтмэттр :: https://t.me/deksden_notes/45
* главный индекс меморибанка и прайминг контекста: https://t.me/deksden_notes/51
* 🔗 Аннотированные md ссылки :: https://t.me/deksden_notes/47
* атомарные файлы : https://t.me/deksden_notes/49 , https://t.me/deksden_notes/52
* С4 модель : https://t.me/deksden_notes/52
* XML-like теги : https://t.me/deksden_notes/73
* оверинжиниринг : https://t.me/deksden_notes/368
* Progressive Disclosure : пробеги по граблям Skills и меморибанки : https://t.me/deksden_notes/407

▶️ кейсы и разбор проблем с агентами:

* Vibe Coding мифы и "охотничьи рассказы" : https://t.me/deksden_notes/59
* Разбор vibe-кейса 1️⃣ : https://t.me/deksden_notes/60
* Модель не справляется : https://t.me/deksden_notes/262

▶️ Тактические приемы работы с агентами:

* планирование в СС : https://t.me/deksden_notes/64 и https://t.me/deksden_notes/65
* vibecoding в CC : https://t.me/deksden_notes/89 и https://t.me/deksden_notes/90
* вайбкодинг в Кодексе : https://t.me/deksden_notes/124
* Codex workflow для рефакторинга : https://t.me/deksden_notes/144
* Local multiagent flow : https://t.me/deksden_notes/146
* Прайминг - Специализированные сессии : https://t.me/deksden_notes/329
* Флоу Peter Steinberger : https://t.me/deksden_notes/331
* Прайминг, если нет меморибанка : https://t.me/deksden_notes/412
* Планирование с агентом: работа с контекстом после прайминга : https://t.me/deksden_notes/413

👉 (Продолжение оглавления тут: https://t.me/deksden_notes/475)

Когда возможностей модели не хватает
1/2

🧐 В общении пару раз сталкивался с таким кейсом при обсуждении AI SWE - Spec-driven development. Все соглашаются, что БЕЗ подготовки проекта к работе с AI SWE, использование ИИ для работы с проектом возможно только в режиме ИИ-ассистента программиста.

Но сложности случаются и в, казалось бы, грамотно подготовленном к AI SWE проекте, с детальными спецификациями и хорошо проработанными процессами. Мы можем получить ситуацию, когда ИИ-агент генерирует код откровенно низкого уровня.

❓ В чем может быть дело?

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

Допустим, у нас есть всё:

- действительно подробные инструкции;
- грамотно прописанные спецификации;
- процесс, разбитый на «правильные» этапы;
- код, структурированный на понятные модули;
- ясная и прописанная структура проекта;
- подробные JSDoc с перекрестными ссылками.

Казалось бы, идеальные условия. Но при генерации мы получаем код низкого качества: синтаксические ошибки, путаница в именах, падающие тесты, ошибки как в тестах, так и в коде.

Часто слышу: «Мы же говорили, ИИ не может!». И да, и нет. Когда модель сталкивается с задачей, сложность которой превышает её «емкость», она действительно может не справиться. Разберём, что происходит под капотом.

Например, нам известны параметры модели DeepSeek: 128 голов внимания, 61 слой. При обработке контекста 128 голов первого слоя ищут свои паттерны, затем 128 голов второго слоя обрабатывают контекст с учетом результатов первого, и так далее. Взаимосвязи простраиваются вглубь на протяжении всех 61 слоев. В итоге на стадии prefill создается KV Cache — «конспект» контекста. Далее начинается процесс декодирования, где для генерации каждого нового токена модель обращается к этому кэшу, чтобы понять, на что обратить внимание.

Вернёмся к нашим проблемам. В чем возникла сложность?

🚑 Общий диагноз: Да, в контексте модели есть все нужные требования, но из-за высокой общей сложности некоторым из них «не досталось» достаточного веса внимания и они проиграли в конкуренции за «бюджет внимания» модели. В результате нам кажется, что модель забыла или упустила какие то требования.

... (продолжение - https://t.me/deksden_notes/12)

#post

Когда возможностей модели не хватает
2/2 (начало - https://t.me/deksden_notes/11)

Что можно сделать?

1️⃣ Упростить контекст. Первое и самое прямолинейное решение — снизить когнитивную нагрузку. Уберите из контекста лишние файлы или нерелевантную информацию. Чем меньше в контексте «смысловых групп», тем проще модели выстроить между ними правильные связи. Если это практически возможно — сделайте это в первую очередь.

2️⃣ Повысить «читаемость» контекста для ИИ. Вы считаете, что у вас хорошо прописанные спецификации? Проверьте, реализованы ли в них эти техники:

- Жесткая структура: XML-теги для разметки семантических блоков, а внутри — Markdown с четкой иерархией и использованием разных маркеров списков для разных уровней.

- «Якоря» для внимания: Уникальные идентификаторы после каждого требования (так называемая «китайская запись», создающая сильную локальную ассоциацию и учитывающая казуальность трансформеров): "Функция должна быть асинхронной. ::ID-SPEC-FUNC-ASYNC-01::".

- Few-shot примеры: 1-2 коротких примера кода, который уже следует вашим спецификациям.

- Группировка: Раздельные блоки для требований к логике, стилю, тестам и т. д.


Часто именно эти детали отличают просто «хороший» промпт от стабильно «работающего».

3️⃣ Гранулировать задачу. Ваш процесс уже разбит на этапы? Проверьте, достаточно ли они мелкие. Часто решение кроется в том, чтобы разбить «большой» этап на несколько «микро-задач»:

- Сначала план, потом код: Первым шагом заставьте модель сгенерировать детальный implementation plan (список файлов, классов, функций).

- Генерация по плану: Следующими шагами давайте модели по одному пункту из её же плана.


4️⃣ Использовать итеративное «фокусное ревью». Если после генерации все равно остались ошибки, переходите к режиму исправления. Возьмите сгенерированный код и узкую подгруппу требований (например, только требования к безопасности) и дайте агенту команду проверить и исправить код только по этим пунктам. Так мы принудительно фокусируем всю «емкость» модели на очень маленьком срезе задачи.

⁉️ А если даже это не помогло?

Вероятность такого исхода крайне мала. Если модель не справляется с четкой, сфокусированной задачей, это почти всегда означает проблему в самом контексте. Вспоминаем главное правило: «Мусор на входе — мусор на выходе». Значит, нужно вернуться и проанализировать, не содержит ли промпт противоречивых инструкций или скрытой двусмысленности.

✨ Вывод: При грамотной инженерной проработке, сочетающей подготовку контекста, декомпозицию и итеративные исправления, процессы с использованием ИИ-агентов становятся предсказуемыми, надежными и качественными.

␄
#post

🌲Запускаем VS Coding Agents в JetBrains

IDE от JetBrains мною исторически любимы, я к ним привык - основной инструмент это шарм (PyCharm). Но с ассортиментом ai extensions для джетов всегда было хуже чем для VS Code-based IDEs.

Но вот какой проект нашелся: https://github.com/wecode-ai/RunVSAgent

В настоящее время поддерживают как минимум RooCode, что уже неплохо.

Я, конечно, за автономного агента без встраивания в IDE, и за 100% ai swe flow, но вдруг кому надо ассистента в IDE?) Можно пробовать

#link
@deksden_notes

⚡️Статья на хабре: AI Software Engineering: От хаоса Vibe Coding к системной разработке с AI-агентами (введение в меморибанк)

Я - соавтор, с Дмитрием @filippov_dm

https://habr.com/ru/articles/934806/

#link
@deksden_notes

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

Решил написать обзор фишки субагентов в Claude Code (далее - сокращаем до общепринятого СС).

⏳ История вопроса уходит к первому публичному релизу СС. В ту пору субагенты были "обычным" инструментом Task - так он указывался в интерфейсе, но в исходном коде они сразу были названы AgentTool. Давайте для ясности далее будем называть его задачей (именно так, не субагентом или агентом, - почему объясню далее).

Это был простой инструмент: основной агент (будем дальше для ясности называть его **оркестратором**), это тот, с которым вы непосредственно общаетесь интерактивным чатом, вызывает инструмент Task, передаёт ему "задание" (промпт). Далее задача работает в отдельном контексте самостоятельно и возвращет результат оркестратору. В ходе работы задачи в интерфейсе СС мы видим некие сообщения о происходящих действиях, и все это пишется в json в сессию. Если есть желание почитать подробнее - можно использовать инструменты типа Claudia.

#post

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

🔥 Субагенты в 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