"⚪️ 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"