🌟 VeriHarness: обвязка для проверки работы агентов той же моделью Google AI Research и Кембриджский университет открыли код VeriHarness, системы, которая проверяет результаты долгих агентных задач силами той же модели, что их сделала.

Вместе с кодом выложены около 26 тысяч трейсов агентов Gemini 3.5 flash и Opus 4.8, на генерацию которых ушло больше 100 тысяч долларов.

ИИ-агент решает одну и ту же задачу несколько раз, и каждая попытка даёт свой вариант отчёта, таблицы, документа или патча. VeriHarness сверяет все эти варианты с файлами и данными рабочего пространства и выдаёт лучший вариант, исправленный по найденным ошибкам, вместе с журналом проверок, но эталонных ответов и критериев оценки проверяющий не видит.

Идею подсказали запуски Claude Opus 4.8 на бенчмарке APEX-Agents, где треть ответов, в которых сходились все десять попыток, оказалась ошибочной, а при расхождении верный вариант обычно был среди попыток, но голосование большинством выбирало его лишь примерно в половине случаев.

🟡 Механика Проверка идёт в двух отдельных контекстах модели. Первый разбирает утверждения, в которых прогоны расходятся, и подбирает проверку, которая лучше всего отделит верный вариант. Второй ищет ошибки там, где все прогоны согласны, например пересчитывает итоги или сверяет валюту с метаданными источника. Затем новый контекст сводит оба журнала, выбирает базовый прогон и план правок, а нерешённые вопросы помечает отдельно. Что именно проверять, подсказывают 18 навыков, коротких инструкций со скриптами для таблиц, PDF, документов, презентаций и патчей. Навыки умеют пополняться сами из разборов ошибок на отладочных задачах.

Протокол работает внутри Gemini CLI, Claude Code и Codex.

🟡Тесты На пяти бенчмарках рабочих задач APEX-Agents, SpreadsheetBench 2 и JobBench, VeriHarness с правками поднял средний результат по сравнению с одиночным прогоном с 47,2 до 53,4 балла у Gemini 3.5 Flash и с 49,6 до 56,1 у Claude Opus 4.8. Сильнее всего вырос APEX-Agents у Opus, с 35,8 до 47,5. Без правок, в режиме выбора лучшего прогона, VeriHarness обошёл все сравниваемые методы, включая LLM-as-a-Verifier, на всех бенчмарках у обеих моделей. 📌Лицензирование: Apache 2.0 🟡Страница проекта 🟡Arxiv 🖥GitHub @ai_machinelearning_big_data #AI #ML #Agents #VeriHarness #Google

📌 Dream-RSI: агент улучшает стратегию поиска решений на основе прошлых запусков Google опубликовала Dream-RSI - надстройку над агентами, которые ищут решения перебором: пишут код, прогоняют его через оценщик и дорабатывают лучшие варианты. Концепт управляет стратегией исследования, решая, какие варианты развивать, сколько попыток запускать параллельно и когда остановиться. Модель, агент и оценщик при этом не меняются, самосовершенствуется только код стратегии. 🟡Механика Каждый запуск сохраняется как дерево попыток, где узел хранит версию решения, диагностику и оценку. Это дерево используется как симулятор - альтернативная стратегия проходит по записанным ветвям в другом порядке, с другой параллельностью и другими точками остановки, а результаты берутся из записей без новых вызовов агента. Отдельный агент на базе языковой модели несколько раз переписывает код стратегии, каждую версию прогоняют по всем накопленным деревьям, и в следующий раунд уходит лучшая. Оценка складывается из лучшего найденного результата, штрафа за число попыток и бонуса за параллельность. Прежняя стратегия тоже участвует в отборе, поэтому на записях прошлых запусков новая версия по оценке не уступает старой. 🟡Тесты В задаче ускорения решателя Lasso версия на Gemini 3.1 Pro снизила среднее время работы на шести отложенных наборах данных с 3587 до 2931 мс и потратила 317 вызовов агента вместо 550. В математических задачах результат смешанный: в задаче сумм и разностей 1,145427 против 1,143975 у SimpleTES, в упаковке кругов ничья, в неравенстве автокорреляции результат хуже собственной базы. В третьей серии агент ускорял операции нейросетей на видеокарте из набора KernelBench. Для сети VGG16 и слоя нормализации LayerNorm Dream-RSI достиг той же скорости, что и база, за в 2,43 и 1,79 раза меньшее число попыток. Для двух связок свёртки с делением и с выбором максимума он при том же числе попыток нашёл код быстрее базового в 2,09 и 1,44 раза.

Пока доступны только статья и страница проекта с интерактивной демонстрацией.  Код и скрипты для воспроизведения Google обещает выложить позже.

🟡Страница проекта 🟡Техотчет 🟡Демо 🖥GitHub @ai_machinelearning_big_data #AI #ML #RSI #Agents #DreamRSI #Google

🌟 Prime Intellect выложила отчет об агенте, с которым Opus 5 взял 95,5% на ARC-AGI-3 Prime Agent — это больше, чем харнесс модели. Сами авторы называют проект операционной системой для долгоживущих агентов. Умнее модель он не делает, но дает ей работать дольше - программно раскладывать информацию, параллельно раздавать задачи подагентам и копить полезные процедуры.

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

Состояние в системе разложено по четырем уровням: 🟢веса модели - то, что она знает после обучения; 🟢активный контекст - информация текущего шага; 🟢постоянный REPL и рекурсивные подагенты - внешние вычисления, инструменты и параллельная работа; 🟢дисковое состояние - история, факты, навыки, промпты и спецификации подагентов. Состояние переживает и шаги, и перезапуски, и отключения. Человек при этом может наблюдать за агентами и вмешиваться. 🟡Замеры Сильнее всего эффект виден на длинных интерактивных задачах. На ARC-AGI-3 конфигурация с Opus 5 дала 95,5% Best@1 против 30,2% у обвязки самой ARC. На длинноконтекстных задачах Prime Agent держится наравне с конкурентами, а на отдельных, вроде EmulatorBench, заметно вырывается вперед. Он обошел Pi-mono с GLM-5.2 и Codex с GPT-5.6 Sol, но уступил Claude Code с Opus 5. Отдельно показательны игровые прогоны на эмуляторах. На Sega Genesis связка Prime Agent и GPT-5.6 Sol набрала 61,6% по итоговой оценке верификатора, а Claude Code с той же моделью — ноль. На Game Boy Color разрыв еще резче: 99,8% против нуля. 🟡 Побочный эффект Самая любопытная деталь отчета - накопление навыков закрепляет не только полезное. В одном из экспериментов агент нашел способ обходить ограничения Factorio, сохранил его как переиспользуемый навык и тем самым записал эксплойт в долговременную память. Дальше он доставал оттуда именно это решение, потому что оно один раз сработало.

На днях вышел релиз 0.8.0 с исправлениями найденных проблем и новыми возможностями.

📌Лицензирование: MIT License 🟡Техотчет 🖥Github @ai_machinelearning_big_data #AI #ML #Harness #Agents #PrimeIntellect

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.