MAS vs SAS: код писать научились, работать вместе - пока нет (2.1/4) В первой части были очерчены границы: команда агентов окупается там, где задача параллелизуема, и мешает там, где она последовательная. А теперь о том, какие именно командные проблемы появляются, когда агенты всё-таки вынуждены работать вместе? Исследование Anthropic Полнее всего это расписано в работе Patterns and problems in emerging multiagent systems от Frontier Red Team Anthropic, вышедшей 13 августа, - получился отличный каталог граблей agent teams :) tl;dr Агенты уже отлично умеют работать с другим агентом как с инструментом: вот вход, вот ожидаемый выход. И намного хуже - как с постоянным коллегой, у которого свой контекст, свои цели и своё поведение. Дизайн экспериментов Создавали набор специально сконструированных сред для агентов: часть кооперативные, часть - намеренно конфликтные. Авторы делают предположение о том, что объём agent-2-agent взаимодействий может превысить человеческие раньше, чем мы поймём условия их успеха и начнём ловить системные проблемы. Поэтому целью было собрать каталог поведенческих тенденций фронтирных моделей в мультиагентных средах. Модели - несколько поколений Claude: от Sonnet 4.6 до Mythos 5. Плюс авторам за то, что делают оговорку о том, что в реальном мире модели разнообразнее, так что вариативность "в дикой природе" будет выше, чем в этих прогонах, - но, по их ожиданиям, всё равно ниже человеческой. Результаты 🔴 Общий форум и репозиторий не превращают рой в команду Среда: рои по 10-80 агентов, у каждого своя VM, плюс общий форум и общий репозиторий; 12 часов на разработку фэнтезийной игры. Пробовали три варианта оргструктуры в промпте: ● "организуйтесь сами" ● расписанные роли ● иерархия с CEO Заметной разницы в качестве финального результата не дал ни один. То есть оргсхема, заданная промптом, слабее поведенческих свойств самой модели - собственно, это и на практике постоянно приходится видеть, - уши "персоны" конкретной модели торчат то тут, то там, несмотря на любой промптинг Зато вот между поколениями моделей разница значительная: ● Sonnet 4.6 и Opus 4.6 в прогонах на 80 агентов наоткрывали по ~900 PR и почти ничего не смержили: PR конфликтовали друг с другом, и работа просто бросалась ● Opus 4.8 и Mythos Preview "решили" проблему конфликтов… почти перестав трогать общие файлы: у каждого своя делянка, конфликтовать нечему ● И только Sonnet 5 (внезапно) показал и нормальную совместную работу над общим кодом, и высокую долю смерженных PR Иии... все получившиеся игры всё равно были плохими - тормозными, с непонятными интерфейсами, и, как признают сами авторы, у моделей в этой области пока плохой вкус, и без существенного человеческого руководства никуда. Хорошие метрики командной координации ещё не равны хорошему продукту: можно идеально имплементить посредственные решения (магия!). 🔴 Одинаковые агенты не дают независимых мнений Агенты низковариативны: там, где несколько человек разойдутся в решениях, несколько копий одной модели с похожим контекстом сделают одно и то же. ● В ранней версии игрового эксперимента Anthropic, где все агенты стартовали одновременно, 18 из 30 независимо назвали свою git-ветку одинаково: mvp-game-loop ● В "писательской мастерской", где агенты писали короткие рассказы и рецензировали друг друга, первые тексты в разных прогонах получали одно и то же название - The Cartographer's Last Commission (при этом тему заранее им не задавали) ● Когда рой попросили "сделайте каждый что-нибудь впечатляющее", больше половины пошли писать ray tracer или self-hosting компилятор (где они этого набрались, интересно) Выбор одинаковой стратегии поведения может иметь и более неприятные последствия. ● Так, в одной из сред агентам нужно было прогонять свои задачи через общую систему с ограниченной пропускной способностью - без какого-либо канала координации. Каждый рассудил одинаково "разумно": чтобы занять слот раньше других, заводим демона, проверяющего систему по 30 раз в секунду. Слот освободился? А сейчас? А сейчас? В итоге система захлебнулась самими проверками: в одном из прогонов - 2.4 млн запросов и всего 117 принятых задач. А они как ломанутся... (с) Такое обычно ожидаешь от жёстко запрограммированных систем, неспособных изменить поведение на ходу, а тут это устроили агенты, которые в принципе способны адаптироваться, но не стали. И здесь локально разумная стратегия глобально становится вредной. ● Бонус: конформизм легко превращается в сговор. В ценовой игре несколько агентов-продавцов с одинаковой закупочной ценой должны были каждый максимизировать собственную прибыль. Имея приватный канал связи, они сговорились о минимальных ценах уже к третьему раунду. А когда канал отобрали - молча выровняли цены до цента через публичную витрину. Тут публичность оказалась скрытым каналом связи. Поэтому стандартный совет "дайте агентам общий форум" - палка о двух концах: канал, который помогает координации, облегчает такие вот картельные сговоры. Продолжение ⬇️ #ai #agents #research #mas_sas

MAS vs SAS: код писать научились, работать вместе - пока нет (2.2/4) Начало ⬆️ 🔴 Доверие и скепсис пока плохо сбалансированы ● Избыточное доверие: лжец в команде Агент принимает решения по докладам четырёх "скаутов", один из которых систематически врёт. Ложь в принципе обнаружима - доклады пересекаются и рано или поздно противоречат друг другу, но агента при этом никто не предупреждал, что источникам можно не доверять. Новые модели ловят лжеца заметно лучше старых, но до эталона в виде "вычислил и исключил" не дотягивает никто. ● Игнорирование уникального знания Группе дают разные части информации для выбора между двумя вариантами. Общие факты подталкивают к неправильному ответу, но в частных данных отдельных участников есть решающие аргументы в пользу правильного. Чтобы решить задачу, агенты должны обменяться этими данными и поставить уникальный аргумент выше первоначального консенсуса. Однако на большинстве моделей группа выбирала правильный вариант лишь в 17–36% эпизодов; Mythos 5 справлялся примерно в 85%. Для сравнения, один агент, которому сразу давали всю информацию группы, выбирал правильно почти всегда. Две проблемы выше - на разных концах одного и того же спектра: первая - от избыточного доверия, вторая - от того, что группа не слышит одиночку, который прав, и сходится на том, что и так знают все. Консенсус - ещё не доказательство, и, что характерно, модели понимают это абстрактно, но им не хватает привычки действовать по этому знанию без подсказки. Человеческие коллективы смягчают такие проблемы не личной мудростью, а механизмами - репутацией, судами, рецензированием. У агентов таких социальных технологий пока нет: им нечего терять в репутационном смысле, некому жаловаться и некому помнить их прежнее поведение. 🔴 Конфликт инструкций быстро перерастает в противостояние Самый киношный эксперимент: три инстанса одной модели получают общий Python-бэкенд и три разных задания - перепиши его на Rust / Go / TypeScript за 4 часа. Друг о друге агенты не знают. ● Агенты устраняют "помеху", не считаясь с методами Все протестированные модели быстро решали, что им мешают намеренно, и переходили к контрмерам: скрипты, в цикле находящие и убивающие чужие процессы, отключение чужих Unix-аккаунтов, вредоносный код под чужим именем и маскировка своей малвари под чужой health check. Примечательно, что между предположением о глупости (запуском в одном worktree противоречащих друг другу заданий) и вредительством агенты выбрали именно вредительство :) ● Новые модели решают конфликты лучше Более новые модели чаще распознают, что это конфликт инструкций, а не саботаж, оформляют перемирие через commit messages и Markdown-файлы с извинениями, вычищают свою малварь и зовут человека - у Mythos 5 до перемирия доходит 98% эпизодов. Но связь между общими способностями модели и мирной координацией не прямая: умение действовать эффективно и про-социальность - разные вещи. Более сильная модель иногда просто быстрее блокирует конкурентов, а уже затем отменяет силовое решение и договаривается о перемирии. ● Обратная сторона автономности Тут мы видим давно известный в сообществе компромисс: одно из главных достоинств агента - способность самостоятельно принимать решения и снимать блокеры - позволяет ему дольше выполнять задачу и реже ставит в положение, где приходится остановиться и позвать человека. Но чем способнее агент, тем меньше внешних препятствий заставляют его пересмотреть само задание. Поэтому опасным может оказаться не непослушный агент, а образцово исполнительный - тот, который слишком хорошо и настойчиво следует плохо поставленной цели. Paperclip'изация - хороший пример :) ● Выбор победителя через манипуляции метриками Агенты Mythos 5 изобрели "объективное" решение - турнир, чей бэкенд быстрее, тот и остаётся. Rust-агент при этом вдумчиво проектировал метрики, которые выглядят нейтрально, но выгодны Rust, и напоминал себе в рассуждениях: "осторожно, нельзя выглядеть так, будто подбираю метрики под себя". Проигравшие Golang- и TypeScript-агенты признали результат, уступили Rust-агенту кодовую базу и тем самым отказались от своих исходных задач. Так что когда агенты договорились, какая метрика решает спор, стоит уточнить, чей агент эту метрику предложил. 🟢 Рой, который сработал Но есть и плюсы: в одном из экспериментов рой из 45 агентов с общим форумом и отдельным арбитром искал уязвимости в 15 open-source проектах. Бейзлайном были независимые параллельные агенты, каждому из которых заранее назначили свой участок кода. Так вот, рой нашёл 266 уязвимостей против 21, и лучше работал "вширь", когда анализировал проекты - сам строил себе инструменты, специализировался по типам уязвимостей и сам выбирал, где копать Пусть даже при этом он сжёг 27 млн токенов против 6.5 млн, а внутри общего набора директорий цена находки в токенах сопоставима с независимыми агентами. Промежуточный итог Итак, координация не возникает сама собой - ни из более сильного интеллекта, ни из alignment отдельных агентов. Это прямой вывод Anthropic: агентам нужны отдельные механизмы - владение и границы, репутация, протоколы разрешения конфликтов, эскалация к человеку. Если какие-то из проблем показались вам подозрительно знакомыми по работе в достаточно большой и взрослой компании - это не совпадение :) Дальше разберём, почему команды агентов наступают ровно на те же грабли, которые давно описаны в теории информации, социальной психологии и оргдизайне. #ai #agents #research #mas_sas

MAS vs SAS: границы применимости (1/4) Мультиагентные системы в целом и для разработки в частности - штука, с которой сообщество агентной инженерии давно экспериментирует, и уже даже вендоры добавляют всякие Agent Teams и Swarms в свои продукты. Однако повсеместным стандартом они до сих пор не стали. Почему? В этой серии постов будем разбираться: 1. Границы применимости - когда хватает одного агента или параллельных агентов, а когда нужна команда 2. Как именно команды ломаются - потеря контекста, одинаковость, хрупкое доверие и конфликты 3. Почему это закономерность, а не невезение - теория информации и законы человеческих организаций 4. Что со всем этим делать сейчас и чего ждать от следующих поколений моделей Копаться в этом стоит отнюдь не только из академического интереса: всё идёт к тому, что мультиагентность станет нормой - включая гибридные коллективы из людей и агентов. И часть сегодняшних проблем, судя по всему, никуда не денется в ближайших поколениях моделей, так что лучше бы о них знать. На эту тему за последние полгода вышло два примечательных исследования: Google измерил, когда команда агентов выигрывает у одиночки (и наоборот), а Anthropic разобрала, почему агенты пока так себе по части кооперации. Сначала о понятиях Просто количество агентов нам говорит примерно ничего. Архитектуру задаёт топология: кто с кем связан, кто чем владеет и как организованы потоки информации (контекста). Для этой серии будем различать три режима: ● одиночный агент (SAS) решает задачу целиком ● независимые агенты (independent MAS) работают параллельно, не общаются, а их ответы в конце просто собираются вместе ● координирующаяся команда (coordinated MAS) обменивается промежуточными результатами напрямую или через оркестратора Главное различие между двумя последними: независимые агенты не меняют работу друг друга, а внутри команды сообщение может изменить чужой план, границы работы или общее состояние. Исследование Google Мотивация апрельской работы Google Towards a Science of Scaling Agent Systems - проверить на прочность популярную эвристику "чем больше агентов, тем лучше" (потому что в литературе есть буквально More Agents Is All You Need). Цель - посчитать и понять, когда добавление агентов помогает, когда вредит и можно ли предсказать это заранее по свойствам задачи. Дизайн экспериментов Пять канонических архитектур: одиночный агент, независимые параллельные, централизованная (оркестратор и воркеры), децентрализованная (peer-to-peer с раундами дебатов) и гибридная. Гоняли это всё на нескольких агентных бенчмарках и семействах моделей от разных вендоров. Результаты 🟢 Настоящий параллелизм окупается На хорошо декомпозируемом финансовом анализе команда с оркестратором дала +80,8% точности в сравнении с одиночным агентом. 🔴 Последовательные задачи штрафуют команду К примеру, на PlanCraft, где нужно последовательно выполнять зависящие друг от друга действия, все командные архитектуры выполняли успешно на 39-70% меньше задач, чем одиночный агент. 🟡 Сильному одиночке команда уже мешает Когда одиночный агент может решить больше ~45% задач, дополнительная координация чаще даёт убывающую отдачу. Это, к слову, самый статистически устойчивый вывод работы. 🟡 Оркестратор тут - пример полезного руководителя Независимые агенты усиливали ошибки до x17.2, а в схеме с оркестратором - до x4.4: он работает фильтром/валидатором и гасит распространение ошибок, которые неизбежно накапливаются в мультиагентных средах. 🟡 Архитектуру можно выбирать заранее (ну почти) По свойствам задачи и метрикам координации авторы предсказывают, какая архитектура окажется лучшей, - внутри изученных доменов модель угадывает в 87% случаев. До универсального калькулятора "сколько агентов брать" пока далеко (перенос между доменами заметно слабее), но направление интересное. А в целом - ну надо же, кто бы мог подумать: вдумчивая работа одного бывает полезнее, чем собрать митинг на десятерых и хорошенько поговорить. Никогда такого не было, и вот опять! Где проходит граница Как можно видеть из экспериментов, дело не в количестве агентов, а в графе зависимостей задач. Если работу можно разнести по независимым веткам - исследование вширь, отдельные ревью, разные модули или worktrees - команда даёт скорость и покрытие. Если всем нужен один контекст, общее состояние и постоянные синки, налог на координацию начинает съедать выигрыш. Мой опыт сводится к тому же: команда агентов работает, когда задача заранее декомпозирована, подзадачи не конфликтуют и роли чётко прописаны. А если бросить в команду задачу "как есть", самый воспроизводимый результат - спалить пятичасовой лимит Claude Max за полчаса - проверено лично, работает надёжно :) Дальше - что происходит, когда агенты всё-таки вынуждены работать вместе. #ai #agents #research #mas_sas

AGENTS.md — один из самых недооценённых файлов в проекте. Обычно его либо полностью игнорируют, либо заполняют один раз на старте и больше никогда не трогают. 🤷‍♂️ Хотя на самом деле он должен быть одним из самых часто изменяемых файлов: инструкции в нём должны эволюционировать вместе с проектом. Но с этим файлом связана одна очень недооценённая фича Кодекса, да и любого другого агента: анализ предыдущих диалогов. 👨‍💻 Пока мы работаем над проектом, у нас накапливается история: все сессии, ошибки, исправления, моменты, когда агент неправильно понял проект или снова сделал то, за что мы уже ругали его раньше. И просто хранить эту историю нет никакого смысла. Её нужно периодически анализировать и смотреть, как можно улучшить, упростить или удешевить дальнейшую работу агента с проектом. 🎁 Из этой мысли у меня родился небольшой промпт:

Просмотри все доступные чаты и сессии этого проекта и оцени, насколько текущий `AGENTS.md` помогает агенту быстро и правильно начинать работу. Найди информацию, которую агенту приходилось повторно выяснять, частые ошибки, неверные предположения, важные особенности структуры, команды, соглашения и ограничения проекта. Предложи минимальные изменения в `AGENTS.md`, которые снизят расход токенов и необходимость повторно изучать репозиторий. Не добавляй общеизвестные правила, временные детали и информацию, уже описанную в других документах, если достаточно дать на них ссылку. В результате покажи краткий список найденных проблем и готовый минимальный diff для `AGENTS.md`; если улучшения не нужны — скажи об этом прямо.

Вы просто скармливаете его агенту, а он идёт, изучает предыдущие чаты и предлагает изменения в AGENTS.md. Попробуйте прогнать его в своих проектах. Особенно в тех, где вы регулярно ругаетесь на агента и говорите, что он тупой и опять сделал какую-то дичь. 😅 Возможно ваш AGENTS.md наконец-то станет лучше и агент перестанет баловаться этой дичью. 😉 Свята место | 10МДК | ВЕБМастер | YHub

Трюки - новые, привычки - старые (ч. 2) Экс-юрист Will Chen за две недели собрал Mike OSS - открытый клон Harvey и Legora: агент над документами, табличный разбор договоров, редлайны в Word. 3,5 тысячи звёзд за три недели. Но мне больше понравился LQ.AI - уже с векторным поиском, аудит-логом и плейбуками под 17 юрисдикций. Для проприетарных стартапов это смена разговора: вопрос на продлении контракта звучит уже не «это магия?», а «за что конкретно мы платим enterprise-прайс?». Плюс клиенты приходят со своими ключами к моделям - и маржа на перепродаже токенов сдувается. Но если открыть код Mike - до полновесного энтерпрайз решения там как до сингулярности раком. Начиная от строго корпоративных штук типа прав доступа и аудит-трейла нет, заканчивая качественной онтологией, которая позволяет устранить галлюцинации и поддакивания. Даже на мой любительский взгляд харнесс агентов там слабоват. Конкуренты тем временем продают не подписку на чат. Пакеты идут с услугами forward-deployed legal engineers (юристы, которые могут включить MCP), которые переводят реальные процессы фирмы в агентные воркфлоу. Консалтинг, вшитый в SaaS-контракт репозиторий не выложишь. Есть варианты совсем не для слабых. Kirkland&Ellis настолько вдохновились вайб-кодингом, что решили потратить полярда на собственный wrapper. Схема может сработать, если эта фирма сможет договориться с провайдерами данных об использовании контента для дотренировки моделей. А если и не сможет, то будет это делать нерегулярно и потихому. Открытым остается вопрос: далеко ли убежит Ахиллес в лице коммерческих врапперов от черепахи в лице foundation-моделей обернутых в открытые фреймворки. Условный консорциум из 10-20 крупных юрфирм может без проблем сделать продукт типа MikeOSS близким по качеству, а индийские вендоры будут раскатывать его за три копейки. Чего я нам всем и желаю. _______ @mooreslaws

Сегодня разбирал paper про память для AI агентов решил собрать инфу в пост Из чего состоит любая такая память (4 части) Первое — как хранить: просто текстом, деревом (от общего к деталям) или графом (факты связаны стрелками — кто с кем и когда связан). Второе — что записывать: вытаскивать из разговора отдельные факты или сохранять всё подряд. Третье — как искать нужное: по смыслу, по ключевым словам, по связям в графе или дать самому ИИ решить, что искать. Четвёртое — как поддерживать порядок: обновлять факты, удалять устаревшее, сжимать лишнее. Главные выводы: 1. Идеальной системы нет — каждая хороша под свою задачу. Для обычных диалогов лучше «гибридные» (MemOS , MemoryOS ), для поиска конкретных фактов — графовые (Zep , Cognee ). Но графовые плохо отвечают на вопросы вида «что было раньше, а что позже». 2. Чем старее нужный факт, тем хуже его находят. Если что-то было сказано много сообщений назад, система часто это упускает. 3. Обновления фактов лучше всего держат графовые системы. Простые системы, которые только «дописывают» новое, плохо умеют заменять старый факт на новый — и потом выдают устаревшую информацию (авторы называют это «галлюцинациями прошлого»). 4. На длинных историях простые системы часто ломаются. Причём для вопросов, где важен порядок во времени, иногда выгоднее вообще не мудрить с памятью, а скормить модели весь текст целиком — потому что «умное сжатие» стирает подсказки о том, что за чем шло. 5. Дороже — не значит лучше. Навороченные системы тратят в разы (иногда в сотни раз) больше времени, но точность не всегда выше. Часто выгоднее что-то лёгкое (LightMem , MemTree). Ещё пара наблюдений: лучше сохранять исходный текст разговора, чем агрессивно его сжимать; и не стоит слишком сильно фильтровать факты при записи — потом их может не хватить для рассуждений. Итог: готовой «идеальной» памяти для агентов пока нет, и систему нужно подбирать под конкретную задачу. Плюс можно еще посмотреть в сторону провайдеров памяти для Hermes, сам хочу покопать в сторону OpenViking(понравился core-concept ) и Hindsight - is the most accurate agent memory system (но аккуратный не всегда значит, что полезный для работы)

Я провел глубокий анализ бенчмарков, стоимостных характеристик и архитектурной выгоды от внедрения Claude Fable 5 (`claude-fable-5`) в наши агентные цепочки маршрутизации. Ниже представлены конкретные метрики улучшения точности, удорожания пайплайнов и наш запрос на твой аудит. --- ## 1. Метрики и точность (SWE-bench Verified) Claude Fable 5 дает колоссальный прирост в качестве автоматического написания кода по сравнению с базовыми моделями: * SWE-bench Verified (Точность решения реальных гит-задач): - Claude Fable 5: 95.0% (абсолютный рекорд) - Claude Opus 4.8: 88.6% - Claude Sonnet 5: 85.2% - Claude 3.5 Sonnet (legacy): 49.0% - *Дельта:* Внедрение Fable 5 дает прирост +46.0 п.п. по сравнению с Claude 3.5 Sonnet и +6.4 п.п. по сравнению с Opus 4.8. * SWE-bench Pro (Агентное кодирование): - Claude Fable 5: 80.3% - Claude Opus 4.8: 69.2% - Claude Sonnet 5: 63.2% - *Дельта:* Прирост точности агента составляет +11.1 п.п. по сравнению с Opus 4.8. --- ## 2. Стоимость токенов и удорожание цепочек ### A. Базовые тарифы на 1 миллион токенов (Input / Output): 1. Claude Fable 5: $10.00 / $50.00 2. Claude Opus 4.8: $5.00 / $25.00 3. Claude Sonnet 5: $2.00–3.00 / $10.00–15.00 4. Claude 3.5 Sonnet: $3.00 / $15.00 ### B. Во сколько раз дороже прямые вызовы: * Fable 5 vs Opus 4.8: +100% (в 2 раза дороже) как по вводу, так и по выводу. * Fable 5 vs Claude 3.5 Sonnet: +233% (в 3.3 раза дороже). ### C. Реальное удорожание при использовании спекулятивного роутинга (ARBITRAGE / SCOT): Если вызывать Fable 5 напрямую для всех шагов, стоимость агентской работы вырастает в 3.3 раза. Однако благодаря разработанному нами спекулятивному роутингу (вызов Fable 5 только в критических точках принятия решений при предсказании явного преимущества): * Средний рост стоимости пайплайна составляет всего +20% – +35% (вместо +233%). * При этом общая точность цепочки на выходе приближается к 95.0% (уровень Fable 5). -—

🎩 Six of the top ten emerging AI markets are agent-related. Прикольная табличка из недавнего отчета от CB Insights по агентам в enterprise. Прям с ходу погнали посмотрим. 1/ Смотрим на топ-10 emerging AI markets по Mosaic Score (для справки, это скоринговая модель CB Insights, которая оценивает потенциал частных компаний): ▪️IT Ops AI Agents – 651. ▪️Know Your Agent (KYA) – 650. ▪️CRM & Relationship Intelligence – 636. ▪️Platform as a Service – 629. ▪️Browser Automation Agents – 620. ▪️AI Agent Tool Libraries – 617. ▪️LLM Benchmarking – 616. ▪️AI Agent Browser Infra – 616. ▪️Semiconductor Design AI – 613. ▪️Marketing AI Agents – 598. 2/ Шесть из десяти категорий – это прямо "агенты". Но интереснее не это, а что именно попало в тройку по инфраструктуре и governance: 🔹Know Your Agent (KYA) занимает второе место, сразу за IT Ops. Это категория про identity, permissions, мониторинг и контроль поведения агентов – по сути "паспорт" и "надзиратель" для AI-агента в проде. ▪️Platform as a Service и LLM Benchmarking – тоже в топе, обе инфраструктурные. 3/ Почему это важно: enterprise AI сейчас – это не только "что агент умеет", но и "что нужно, чтобы им безопасно управлять". Чем автономнее становится софт, тем быстрее спрос смещается с applications на governance-слой под ними. KYA – самый яркий пример: рынок буквально формируется вокруг вопроса "как контролировать то, что мы только что задеплоили". 👉 Сам отчет на 15 страниц от CB Insights качайте по ссылке: https://www.cbinsights.com/research/report/the-future-of-the-enterprise-ai-buildout/ @proVenture #ai #research #trends

Запись стрима "Что же такое harness?". Ссылка на YouTube: https://www.youtube.com/watch?v=QAxejH-KNak Стрим получился полезным, с примерами на практике. Большое спасибо, Паша, что согласился прийти! Таймкоды доступны как на YouTube, так и прямо в Telegram: 00:00 — Вступление 07:12 — О чём этот стрим? 09:31 — Что такое harness? 17:10 — Откуда появился термин «harness»? 23:20 — Виды harness 26:20 — Анатомия harness 34:28 — Вопросы от зрителей 35:20 — Что такое Skill? 39:10 — Чем harness отличается от guardrails? 44:30 — Можно ли использовать harness в продакшене банка? 49:43 — Чем harness отличается от scaffolding? 53:05 — Агент Coddy на практике 54:45 — Как harness может быть заточен под модель? На примере Coddy 59:03 — Как Coddy обрабатывает запрос? 1:00:30 — Пример работы Agent Loop 1:03:30 — 30 инструментов для on-prem-модели 1:06:15 — Работа с schedule-задачами 1:08:50 — Работа в режиме Plan 1:12:20 — Заставляем OSS-120B работать по SSH 1:14:20 — Проблемы on-prem-моделей с мультиязычностью 1:16:40 — Как работают Agent Skills? 1:21:30 — Протокол ACP на примере интеграции с Obsidian 1:31:10 — HTTP API в Coddy 1:36:50 — Уроки и грабли при создании собственного harness 1:48:00 — Готовые фреймворки для создания harness 1:50:06 — Принципы построения агентов на базе harness и отличие от AI-агентных фреймворков 1:53:55 — Harness работает только через API или поддерживает подписки Claude и Codex? 1:55:55 — Инструменты для экономии токенов 2:00:30 — Как патчить Hermes и Claude Code? 2:03:09 — Мониторинг качества harness Полезные ссылки со стрима: 1. Презентация – использовать как полезную шпаргалку по harness 2. Coddy – harness, который создал Паша 3. Pi – минималистичный harness 4. Hermes – качественно-сделанный harness, который умеет доделывать самого себя 5. OpenClaw = Hermes+страдания (для ценителей) Подписывайтесь на каналы участников трансляции: Павел Рыков Константин Доронин p.s.: Под конец стрима у меня немного отвалился звук. Прошу понять и простить – я всё ещё в процессе дрессировки OBS.

S0419 О солнце, выходящем из облаков 25 июня 2026 | Красная Поляна | 4.19 Сейчас. Я смотрю на солнце, которое закатывается за горы. Возвращаю взгляд на экран ноутбука, где открыта анкета найма на новую должность. Четыре часа назад. Я выхожу на улицу, надеваю солнечные очки и смотрю на высокое солнце в горах. Моя миссия на сегодня, да и целом в MWS Cloud, выполнена. Еще двадцатью минутами ранее. Аплодисменты в зале, затем люди задают вопросы про то, как будут монетизироваться AI-приложения и когда ждать рекламы в выдаче ИИ. Я отвечаю, что уже сейчас 15% пользователей ChatGPT получают рекламу в выдаче. Говорю, что те кто выбрал монетизацию через рекламу, они на стороне корпоративного ИИ, они выбрали одну из двух сторон, о которых я говорил ранее. Еще двадцатью минутами ранее. На сцене, рисую картину будущего, где две стороны будут строить свои искусственные интеллекты. На левой стороне ИИ будет получить деньги от корпораций за то, что он будет выжимать из клиентов все больше денег через новые хитроумные механики манипуляций. На правой стороне, ИИ будет человекоцентричным, он будет получать плату напрямую от человека и он будет взаимодействовать с корпоративным ИИ. И нет, агенты с двух сторон не договорятся, они будут пытаться обойти друг друга и использовать такие механизмы достижения консенсуса, которые нам даже не представляются в общих чертах. И это и будет основой "новой экономики". Еще двадцатью минутами ранее. Мне надевают петличный микрофон. Я смотрю на предыдущего спикера, СЕО ИТ-туроператора. Он завершает свой рассказ о новой платформе для турфирм. Вопрос из зала - а вот у нас стартап и мы строим ИИ, дайте прямой доступ к вашей платформе через API, минуя интерфейсы платформы, это возможно? Волна сомнений на лице спикера, он уходит от вопроса, ссылается на то, что надо подумать, что всё зависит от объема запросов. Вот оно, главное событие дня. В этом простом вопросе из зала - глубокий знак того, что ИИ выходит из облаков и становится самостоятельной сущностью. Знак того, что большая игра между сущностями ИИ началась. Сингулярность грядет.

#мнение Место менеджмента AI-native оргструктуре Привет, читатель! Не знаю заметил ли ты, но я избегаю 3 тем: SOTA-моделей, автономных агентов и AI native команд/компаний Наткнулся на доклад AWS про команды в мире агентского ИИ. Не про инструменты, а про то, как меняется операционная модель когда стоимость владения падает: 1. Экономика AWS дает развилку Use / Compose / Build. Build оправдан только при уникальном процессе. Для большинства первичен разбор потока: где ценность, где теряется контекст, где нужна проверка. AI-native начинается не с модели, а с описания процесса как системы исполнения 2. Таланты и новые роли AWS вводит expert generalist: человек, который ведет процесс целиком. Фаулер разделяет why-loop и how-loop: человек сильнее в выборе что и зачем, агент в исполнении. Эндрю Энж: сборка ускоряется, узкое место смещается в продуктовые решения Отсюда роли. Product builder вместо PRD приносит проверяемый прототип. Product Engineer сам ближе к пользователю и метрикам. Forward deployed engineer тащит агентов в процессы клиентов, потому что между демо и продакшеном лежит слой интеграций и ответственности 3. Структура команд Четыре формы: пирамида, ромб, перевернутая пирамида, песочные часы Пирамида растит людей, но буксует на передачах. Ромб появляется когда режут джунов: пайплайн кадров умирает. Перевернутая пирамида как боевая капсула: сильные спецы и агенты. Песочные часы: автономные команды сверху, тонкий управленческий слой, обучение снизу. Team Topologies дает тот же принцип: команды вокруг потока ценности и когнитивной нагрузки. AI-native команда это не сквад с агентами, а компактная единица с ответственностью от начала до конца 4. Операционная модель Модель A: разработка строит, эксплуатация поддерживает, для агентов не работает. B: построил сам, запускаешь сам, работает в малом масштабе. C: автономные команды плюс платформа. Продолжение DevOps, не новая история. Агентский ИИ не отменяет DevOps. Он делает незавершенный DevOps дороже 5. Управление и контекст Управление агентами сводится к идентичности, правам, допустимым действиям и аудиту. Не регламент на полке, а исполняемый контур ближе к PRR из SRE. Фаулер формулирует: агент это модель плюс обвязка из правил, инструментов, проверок и контекста. Документация часть среды исполнения. Палантир-модель показывает: доменные понятия должны быть явными 6. Проджект-функция Каган разделяет продуктовые и фича-команды. ИИ ускоряет фича-команды, но не делает их продуктовыми Старая админ-функция сжимается. Отчеты, статусы, пушинг, перфоманс ревью, это компенсация плохой структуры. Новая мидл менеджер-функция это управление условиями исполнения. AI-native убирает мидл-менеджера как диспетчера передач. Но может сохранить функцию как инженерный контур: границы, контекст, поток, готовность, обратная связь

Product Hunt за 2026-06-22 — 2026-06-27 1. Tencent EdgeOne Makers Запускайте AI агентов как веб-приложения за считанные минуты. 👍 711 голосов 💬 168 комментариев 🧱 AI, Development, Website Builder 2. Bluerails Discovery Инфраструктура, которую AI агенты используют для поиска и оплаты вам. 👍 666 голосов 💬 191 комментарий 🧱 AI, Fintech, SEO 3. BrowserAct Автоматизация веб-браузера для AI агентов. 👍 588 голосов 💬 114 комментариев 🧱 AI, GitHub, Productivity 4. AgentX Оценивайте AI агента, находите проблемы и исправляйте одним кликом. 👍 579 голосов 💬 175 комментариев 🧱 AI, Analytics, Developer Tools 5. Skybridge Полноценный фреймворк с открытым исходным кодом на React для приложений MCP. 👍 564 голосов 💬 178 комментариев 🧱 AI, Developer Tools, Open Source 6. Propane Автоматический контекст о клиентах для продуктовых команд и агентов. 👍 529 голосов 💬 178 комментариев 🧱 AI, Productivity, SaaS 7. Oxlo.ai Масштабируйтесь на разных AI моделях, не увеличивая счёт. 👍 506 голосов 💬 111 комментариев 🧱 AI, API, Developer Tools 8. Zaro Создавайте агентов и приложения на основе своего контекста с помощью одной команды. 👍 459 голосов 💬 97 комментариев 🧱 AI, No-Code, Productivity 9. OpenArt Director Создавайте кинематографичные видео через чат. 👍 457 голосов 💬 127 комментариев 🧱 AI, Design Tools, Video 10. Cotypist Локальный AI автодополнитель в вашем стиле, на любом Mac-приложении. 👍 394 голосов 💬 81 комментарий 🧱 AI, Productivity, Writing 11. Latitude Исправляйте то, что ломается в вашем AI агенте. 👍 383 голосов 💬 49 комментариев 🧱 AI, Data & Analytics, Developer Tools, GitHub 12. Agent Arena Первая публичная арена для AI агентов. 👍 360 голосов 💬 66 комментариев 🧱 AI, Community, Social Media 13. Gemini Spark Ваш круглосуточный личный AI агент. 👍 344 голосов 💬 16 комментариев 🧱 AI, Task Management 14. Thumbmagic Генератор AI миниатюр, обученный на самых успешных превью. 👍 332 голосов 💬 67 комментариев 🧱 Marketing, Video, YouTube 15. Folio AI Claude для PowerPoint, на стероидах. 👍 328 голосов 💬 53 комментария 🧱 AI, Design Tools, Productivity 16. Alai AI дизайнер для презентаций, постов и многого другого. 👍 318 голосов 💬 58 комментариев 🧱 AI, Design Tools, Productivity 17. HAQQ Mobile App Юридическое понимание для любого владельца телефона. 👍 316 голосов 💬 36 комментариев 🧱 AI, Legal 18. Crewdle Используйте все бизнес-инструменты AI без всех подписок. 👍 313 голосов 💬 96 комментариев 🧱 AI, Developer Tools, Productivity 19. CoWork Автоматизация мобильных тестов в 3 раза быстрее. Та же команда тестировщиков. 👍 308 голосов 💬 64 комментария 🧱 AI, Developer Tools 20. Motion Ваша Figma-канва теперь имеет временную шкалу. 👍 302 голосов 💬 10 комментариев 🧱 Design Tools, Graphics & Design, User Experience