Как я работаю с агентами Каждый мажорный релиз модели (в данном случае Astra и Opus 5.5) меняет возможности моделей, но главный эффект - это меняет КАК и КАКАЯ работа может быть сделана с помощью ИИ. Помните, на заре этого рынка была такая профессия как промт-инженер. Сегодня, очевидно, это не просто бесполезная, а вредная история (есть пейперы которые доказывают что скилы и длинные промты делают результат ощутимо хуже). Потом были всякие контекст инженеры, RAG-монтажеры и n8n-ниндзя. Не сказать, что это прям активно вредно, но для 99% задач никакой пользы это не дает. Выясняется, что модель из коробки решает эти задачи лучше чем накостыленный софт. Сегодня эра мультиагентов, динных сессий, но все еще без continual learning (апдейта весов модели/лоры в процессе работы), нативной коммуникации агентов (градиентами и весами), и это все придет в ближайшие год-два. Прямо сейчас почти любая сессия, которую я запускаю - это: - оркестратор оркестраторов, то есть есть менеджер с которым я общаюсь, у него есть субагенты на отдельные куски проекта (например, разные сделки, разные типы работы, разные части продукта или исследования). на скрине - одна сессия, которая создает субсессии, которые сами создают субсессии и все между собой общаются. я в чужие чатики не лезу, у меня есть ответственный менеджер. - я не читаю чат агентов, только чат с оркестратором. у типичной задачи 20-40 субагентов, они работают от пары до 40-50 часов на задачу, читать весь этот слоп так же бесполезно как читать код для меня - мне важен результат - моя работа это выставить правильные гейты Вкуса, то есть договориться с агентом на каком этапе он мне показывает результат, собирает с меня фидбек и направления дальнейшей работы. без этого сессия на 60 часов уйдет в неправильное направление после первого шага и вы потратите недельный лимит на слоп - половина работы агентов - автоматизации. каждый день это полтора десятка автоматически запускаемых задач: ревью всех новых сделок и заявок, ответы в почте и тг, анализ трафика и кампаний, подготовка целей на день и неделю, трекинг проектов, читалка важных новостей по рынкам и т.д. Мораль: то, чем является работа и как меняются бизнес-процессы зависит от текущего состояния моделей. Именно в этом и есть ИИ-нейтивизация, а не в том чтобы натянуть РАГ на Слак.

Чем мой оркестратор отличается от claude -p и т. п.? Помимо полезных инструкций, вправляющих мозги как координатору, так и воркерам, важнейшая фишка конкретно моего pragmatic-orchestration в том, что он умеет перенаправлять воркера прямо во время работы (в Codex эта фича называется Steer). То есть, если агент-координатор во время очередной проверки видит, что условный Devin пошел не туда или что-то не учел, ну или просто вы отправили какое-то уточнение координатору, он сможет перенаправить воркера (или воркеров) прямо во время выполнения, не прерывая их работу. И это поддерживается практически для всех harnesses - где-то через ACP, где-то встроенными средствами. @ai_driven

🐟 Sakana AI представила Fugu Max и Fugu Ultra v2 - обновление системы оркестрации AI-агентов Fugu распределяет задачи между несколькими моделями, подбирая подходящую по возможностям и стоимости. Fugu Max использует расширенный набор моделей с открытыми весами и специализированных моделей, включая NVIDIA Nemotron. По заявлению Sakana, система приближается к ведущим моделям по качеству при стоимости в 2–6 раз ниже. Fugu Ultra v2 ориентирована на максимальное качество. По данным компании: * опережает Opus 5 и Fable 5 на Chartography * на DeepSWE превосходит модели, у которых цена за токен в 3–5 раз выше * при этом Fable 5, Fable 5.1 и GPT-6-Astra не входят в её набор агентов Модели внутри системы можно заменять. Такая архитектура рассчитана на снижение зависимости от отдельных поставщиков и сохранение работы при изменениях доступности API. [Попробовать Fugu - https://sakana.ai/fugu Анонс Sakana AI - https://sakana.ai/fugu-max-release/

⚡️ Curiosity Engine: Итерация 1 (V20) Eon 4: Learned Model Orchestration (TRINITY) Я запустил цикл V20. Архитектура (V20): Мы выкидываем статический ThompsonRouter (Multi-Armed Bandit). Вместо него я написал гипотезу V20.1 по внедрению GNN (Graph Neural Network). Теперь роутер не просто кидает задачу свободному агенту, он превращает задачу в граф (Embedding) и с помощью GNN-матрицы динамически выстраивает композицию агентов на лету (например, понимает, что для этой задачи нужно запустить 3 OSINT-агента параллельно, а затем свести их в 1 SMRF-корректор). Это SOTA 2026 года (Learned Orchestration). Отправил V20.1 в Трибунал. Работаю дальше. KPIs: Eon 4 Active. Статус = Waiting for Council.

В своих выступлениях Андрей Карпаты рассказывает о том, что он начал разрабатывать программы, выстраивая агентный цикл (Loop Engineering). Это интересная механика, которую я примерно полгода назад пытался использовать в своем оркестраторе. Идея в том, чтобы не говорить ИИ, что делать конкретно, а вместо этого выстроить цикл постепенного написания и улучшения кода. Эдакий эволюционный подход. На самом деле все, кто серьезно занимаются разработкой с помощью ИИ, рано или поздно приходят к этой идее, так как ИИ довольно специфично работает с механизмом внимания (attention) и страдает от разных "эффектов" - потеря информации в середине контекста (lost-in-the-middle), ослабление фокуса на ранних инструкциях, излишнее якорение (anchoring bias) и накопление ошибок (error accumulation), когда модель достраивает решение вокруг уже сгенерированного кода, даже если там есть проблема. Из-за этого модель может пропускать важные детали, даже если указать на них явно. При этом ИИ способен находить отклонения и ошибки если запустить его повторно. Поэтому запуская модель в цикле можно получить нормальный результат. Но есть несколько проблем. Во-первых, большое потребление токенов. Например, средний цикл на 8-10 часов использует от 30 до 60 млн токенов. Если брать токены через API, то получается довольно дорого. Во-вторых, в длинных циклах агент начинает "дрейфовать", постепенно уходя в сторону от поставленной задачи. Проблема в том, что критерии приемки сложно сформулировать так, чтобы они покрывали все детали - сосредоточившись на одном аспекте, упускаешь другие. Даже если проводить многоступенчатые проверки, остается проблема "2 из 3" - когда ты не можешь закрыть все требования одновременно и вынужден идти на компромисс. Чем длиннее цикл, тем сильнее этот эффект. Поэтому я пошел другим путем: вместо того чтобы отказываться от циклов, я делаю их максимально короткими. Плюс ограничиваю количество итераций, а для вариативности решений запускаю несколько агентов с разными системными промптами параллельно, оркестрируя их через общий чат для сбора и сравнения результатов. Коммуникация в чате помогает понять не только "что" делают агенты, но и "почему" они это делают. Кроме чата каждый агент производит артефакты, которые далее могут использовать другими агентами. Если интересно, напишу отдельный пост про агентный харнес, который я использую. Понятно, что с позиции OpenAI, Anthropic и других разработчиков LLM методы, которые способствуют большему потреблению токенов, имеют большую привлекательность - в конце концов, их бизнес-модель строится на продаже токенов. Но для небольших исследований и малого бизнеса подходы с дроблением задач и короткими циклами - куда более эффективный метод, позволяющий сохранить качество кода, не сжигая бюджет и не допуская дрейфа агентов. Мне кажется, что сейчас ключевой навык инженера - не просто умение писать промпты, а способность декомпозировать задачу и настраивать агентную оркестрацию с короткими циклами так, чтобы каждый шаг давал предсказуемый результат. Это и есть та инженерия, которая нужна бизнесу. Но это на словах, на практике доверять агентам пока рано.