⚪️ Claude Workflows, еще немного оценок


Да, оркестратор сам себе пишет рельсы по которым потом бегает.

Материализованные детерминирвоанные воркфлоу это большой шаг вперед: работает сильно надежнее.

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

▶️ Оркестраторов было уже 4 штуки:

1️⃣ на агентных воркфлоу СС недетерминированный алгоритм (зато были красивые визуализации в mermaid диаграммах, которые понмиали агенты в том числе);
2️⃣ потом сделал сложный универсальный ai-kod, это был максимально навороченный комбайн - и бандлы, и скриптовые этапы, и observability, и свой DSL; как раз все паттерны паралелльности - fan-out, parallel с барьерами, суб-воркфлоу, что то про стек вызовов, трейсы, и тп;
3️⃣ потом сделал легкий dd-flow чисто под кодинг, ипользовал его под проекты с codex начиная с 5.1;
4️⃣ последним сделал снова гибридный кодинговый флоу, перенеся dd-flow на ванильный кодекс cli + легкая обвязка в виде хуков и своих cli.

👉 я немного в теме.

▶️ Вы же понимаете, что каждый Agent() в воркфлоу внутри себя может звать Agent Team? )) И вызвать суб-воркфлоу внутри которого снова будут агенты и agent team? We need to go deeper!

А если серьезно - то скромный на первый взгляд набор кубиков для флоу я оцениваю как весьма комплектным для ОЧЕНЬ сложных флоу. Не уверен даже что его стоит далее усложнять.

▶️ На таких кубиках вполне можно сделать то, что я называю dd-flow: свой SDLC:

хотелка ➡️ задача+сценарий ➡️ планирование ➡️ реализация ➡️ верификация сценарием на хотелку

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

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

▶️ почему оркестратор от антропиков все еще базовый, чего по фичам нету (хотя я не сторонних набить продукт фичами - не всегда полезно):

* нет встроенной политики ретраев - надежность работы нужно обеспечить самостоятельно, что сильно осложняет воркфлоу;
* нету встроенного мультисемплинга - я это пользую;
* не нашел политики работы с ошибками - как сбоями агентов (это больше в части ретраев), так и логическими ошибками в воркфлоу; для себя я делал отдельные цепочки во флоу для обработки логических exceptions;
* ноль документации как правильно применять: best practice хотя бы - типа, пояснялки про паттерны map/reduce, fan-out, про lessons learned и эвалы для флоу (как настраивать и отлаживать);
* не совсем внятно описана observability и какие имеем трейсы в системе и как их смотреть; я делал папку .runs где каждый ран воркфлоу лежал с папками для каждого "шага" воркфлоу; шаг содержал промпты агента, его артефакты которые он сгенерировал, и ответ агента (у меня был yaml зачем то, но думаю json надо ставить раз json output прижился);
* нету организации воркспейса для флоу - каждый будет выдумывать для себя; я делал описанную передачу отдельных файлов между шагами флоу; то есть оркестратор проверял не только наличие json по схеме в конце агентного хода, но и наличие пучка файлов с какими то детерминированными проверками; типа, чтобы не просто выполнить ревью и выдать вердикт, но и на каждый косяк оформить карточку;
* нет подходов к отладке флоу - для себя я делал на флоу "эвалы"; это когда берем стандартизированное состояние воркспейса для флоу, прогоняем какой то кусок флоу, и смотрим как флоу отработало; например, для флоу "ревью" берем заранее сделанное состояние подопытного репо с косяками, гоняем флоу, и проверяем потом что косяки найдены и правильно оформлены;

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

▶️ Если это кому то интересно, можно развернуть отдельные аспекты в отдельных постах - пишите комменты ⬇️


(ц) да, это сложно


@deksden_notes