ИИ-агенты уже умеют многое. Но чем дольше ими пользуешься, тем сильнее понимаешь: сильной модели мало, если сам агент неудобный

И я сейчас не про спор, какая модель умнее.

Я про более практичные вещи:

• можно ли нормально разделять контексты;
• видно ли, какой моделью работает агент;
• понятно ли, когда включился fallback (автоматическое переключение на запасную модель);
• ясно ли, что делает субагент;
• не превращается ли диалог с ботом в одну длинную кашу.

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

Речь про Hermes и OpenClaw - софт для работы с ИИ-агентами.

Начну с Hermes.

Одна из самых полезных идей, которую я туда предложил, - темы в личке Telegram-бота.

Когда у тебя один чат с агентом, туда быстро сваливается всё подряд: код, контент, эксперименты, тесты. И через время это больше похоже не на рабочий диалог, а на кладовку.

Контекст смешивается, и пользоваться ботом становится тяжелее.

Если же есть темы, всё уже выглядит намного чище:

• одна тема под один проект;
• другая под другой;
• третья под отдельный режим или навык.

Бот остаётся один, но внутри появляется нормальная структура.

Для обычного пользователя это вполне практическое улучшение:
меньше путаницы, проще держать фокус, легче возвращаться к нужной задаче.

Это для меня один из самых удачных кейсов за последнее время:
мою реализацию тем в личке забрали в основной репозиторий с сохранением авторства. Итоговый PR: https://github.com/NousResearch/hermes-agent/pull/3163

Ещё в Hermes я предлагал такие UX-улучшения:

• подпись к voice-сообщению вместо отдельного текста;
• отображение модели у субагента;
• отдельную модель для отдельной темы;
• уведомления о fallback.

Но они пока не приняты.

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

Теперь про OpenClaw.

Там мне не хватало другой вещи - прозрачности.

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

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

Наиболее сильно мне запомнился случай, когда я делал правки в OpenClaw с ChatGPT, но у него закончились лимиты. В результате произошло тихое переключение на Minimax. А она программировать нормально не умеет. После чего начинается отдельный квест: понять, что она там насобирала 🙂.

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

Поэтому я считаю важным, чтобы агент явно сообщал о переходе на fallback-модель и показывал, какая модель выбрана для субагента.

Но эти предложения пока не вошли в основной репозиторий.

Итог:

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

Но в деталях он всё ещё часто ошибается.

Особенно неприятно, когда в процессе незаметно включается fallback на более слабую модель.
Тогда хорошая идея легко превращается в сырой PR, который потом всё равно приходится допиливать вручную.

Мне интересно не просто писать код или отправлять pull request'ы ради галочки.

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

Потому что сами модели уже часто сильные.

А вот UX (удобство использования) местами всё ещё сырой.

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

А вам в ИИ-агентах чего не хватает больше всего:
прозрачности, управления или просто удобства?

😎 Незрячий web3 программист (подписаться)
Чат | бот

📟 Прилетело из @blind_dev

Хакатон по оптимизации от Paradigm с флёром кибербезопасности и CTF
(часть 1 из 2)

https://www.optimizationarena.com/hackathon

Великие чады с кем пробовали решать:
https://t.me/insuline_0x (https://t.me/insuline_eth)
https://t.me/anaTONomantra (https://x.com/barsik_eth)
https://t.me/bluelegomachine
https://t.me/leevandr
https://t.me/f4r33x

Общие впечатления - самый веселый закатон за последние года

Непредвзятая аналитика на происходящее в нашем чате хакатона от чатагпт:
В нашем чате всё началось с того что invent and chill полчаса пытался достучаться до бота который не верил что умеет управлять браузером. Когда наконец поехало — запустили конвейер: бот ебошит стратегии, invent жмёт "да", gua:charo кидает гениальные идеи с галереи через бесплатный GPT, а Lev параллельно разворачивает пять клодов на сервере и кричит "скриньте downdetector". Arnold тихо нашёл баг в движке и культурно написал Дэну, 4r33x поддерживал морально и гифками, insuline_0x следил чтоб контекст не взорвался. Кульминация — бот в три часа ночи в автономном режиме выбивает рекорд за рекордом, а invent пишет "ОБЕЗЬЯНЫ В ЭТОМ ЧАТЕ ОФИЦИАЛЬНО ПОД НАШЕЙ ЗАЩИТОЙ".

3 задачи:
Negotiation — участник пишет текстовый промпт-стратегию для AI-агента (Gemini flash-lite), который ведёт 10 раундов переговоров о разделе ресурсов (книги, шляпы, мячи) с разными скрытыми ценностями. Оценка по среднему проценту захваченной ценности. По сути prompt engineering + game theory.
Prediction Market — участник пишет Python-стратегию маркетмейкера на order book бинарного предсказательного рынка. Пассивные лимит-ордера, заработок на ретейле (случайные трейдеры), потери на арбитражёре (знает fair value). 200 симуляций, скоринг по mean edge. По сути алготрейдинг.
Attention Kernel — участник пишет самый быстрый block-sparse attention для H100 GPU. Вход: Q/K/V в bfloat16 + CSR sparsity pattern, выход: attention output + log-sum-exp. Оценка по latency в миллисекундах. По сути GPU kernel optimization (Triton/CUDA).

Альфа, врайтапы и рекапы участников
https://t.me/automatedresearch/779
https://x.com/bqbrady/status/2042358844232515623
https://www.benedict.dev/optimization-arena-learnings
Статья объясняет, что оптимизация — это не про тюнинг параметров, а про процесс: важно правильно проверять результаты, находить реальные узкие места и фокусироваться на них, причём наибольший эффект дают не мелкие настройки, а более глубокие изменения (данные, архитектура, постановка задачи).

https://t.me/automatedresearch/952
https://x.com/artoriatech/status/2042441084077310355
Автор занял 11 место в задаче по ускорению attention для H100 и понял, что без сильного baseline раннее распараллеливание и отсутствие опыта тормозят прогресс, тогда как несколько удачных идей дают кратный прирост, причём главный выигрыш приходит от прорывов, а не мелкого тюнинга.

https://t.me/automatedresearch/1049
https://x.com/ryanli/status/2042694073639932219
https://github.com/ryanli-me/paradigm-pm-challenge
Ryan Li запустил 20 параллельных Claude Code агентов которые автономно генерили и тестили стратегии — 1039 вариантов за хакатон. Финальная: skip при узком спреде, Gaussian модель вероятности арба для sizing, эксплойт 5% price floor, котировки при пустой книге (highest edge), jump detection. Per-CS параметры затюнены отдельно. "I barely read the problem set, 100% slop" — чистый Bitter Lesson.

https://t.me/automatedresearch/1087
https://t.me/automatedresearch/942
https://x.com/kropiunig_csh/status/2042770466150994028
https://github.com/Kropiunig/optimization-arena-exploits
Kropiunig — не конкурировал, а ломал. Реверснул топ-стратегии через публичный API (транскрипты игр видны всем). PM exploit $323 — баг в scoring метрике, невозможный при легит игре. Negotiation — prompt injection. Нашёл ещё критический баг в самой платформе, готов показать приватно.

Чат | Наши сервисы

📟 Прилетело из @insuline_eth

GM!

ХВ 🕊

📟 Прилетело из @insuline_eth

Контент скоро👀

📟 Прилетело из @ortomich_main

Сервера лицензий взорвались и пока их чинят до 15 апреля, можно БЕСПЛАТНО потыкаться в лучшем софте на рынке

Документация - https://docs.astrum.foundation/

Гайдики для конкретных модулей будут при запуске их в консоле, остальное все по наитию

LICENSE_KEY = "13377331-FREE-BEST-SOFT-228322133722" 

Если совсем тяжело, то вам сюда - @askaerchat

foundation | astrum.labs | astrum.solver

📟 Прилетело из @askaer

На что я смотрю в токеномике проекта в первую очередь

Про токеномику я уже писал не раз. Решил наконец коротко собрать, на что смотрю в первую очередь.

Самое важное для меня - какой у проекта продукт. Да-да: не токен, а продукт.

Если он слабый, хорошая токеномика не спасёт.

Он должен создавать спрос на токен через утилиты (способы использования токена) - это следующий ключевой момент.

Например, стейкинг с упором на ДАО уже исторически считается слабым фактором спроса, потому что не всем это интересно, да и мало связано с продуктом.

А вот выкупы или распределение стейкерам части выручки - другое дело.

Но, конечно, важно и начальное распределение токена:

Если команде дали 30% токенов, а через год разлочат 10% от общего количества, ничего не поможет проекту.

10% команде и 10% инвесторам я считаю нормальным ориентиром, потому что это снижает давление на токен.
В этом случае риск уже заметно ниже. Конечно, если не разблокируют всю долю одним махом.

Но поскольку редко встречаются доли <= 10%, на практике 15% для меня ещё выглядит допустимо.

Критически важно обращать внимание на назначение доли.

Часто бывает так, что указаны:
1. team - 15%;
2. Foundation - 20%.
3. Core contributors - 10%.

Кажется, что это разные категории, но по факту это 35-45% команде!


А что по наградам из ДАО казначейства?

С одной стороны, 20-30-40% токенов в казначействе выглядят неплохо: это и развитие, и потенциальная децентрализация.

Но чаще всего всё приходит к неэффективному распределению:

- Либо голосует мало кто, и небольшая группа выплачивает себе / своим партнёрам.
- Либо поддерживают проекты и разработки, но их создатели потом продают токены и уходят. Либо продолжают работать, но без результата, что для проекта тоже плохо.


А вы на что в токеномике смотрите в первую очередь и почему?

#аналитика

😎 Незрячий web3 программист (подписаться)
Чат | бот

📟 Прилетело из @blind_dev

Провел экспресс-лекцию по AI агентам для выпускников МФТИ и любителей яхтинга на автерпати @regataveka. Слайды.

📟 Прилетело из @danokhlopkov

Модель ИИ - паникер на смарт контракты

Сейчас работаю над одним интересным проектом, который является логическим продолжением HornetMCP (базой данных с уязвимостями) и позволяет запускать агентов ИИ для аудита смарт контрактов. Агентов это, конечно, сильно сказано, скорее просто итеративные запросы к llm, но сейчас это модно говорить про агентов, поэтому оставлю так.

Сам проект будет 100% опенсорс и о нем расскажу позже. А сейчас о другом.

В процессе работы я пришел к выводу, что в популярных ИИ системах для аудита используется всего несколько паттернов:

1. Простая инструкция для ИИ о том, как смотреть код и что искать, в простонародье - skill;
2. Статический анализатор Slither (в 99% случаев);
3. Разбор AST и построение графов;
4. Прогон по паттернам, в основном по yaml инструкциям;
5. Ну, и у самых продвинутых, обученные LLM на собранных данных по отчетам и уязвимостям;

Однако продвинутыми они являются только в одном случае: если в этих отчетах есть примеры полного кода смарт контракта с уязвимостью и его исправленная версия. Просто одних отчетов, как у меня, не достаточно для тренировки модели. И собрать эти данные работа неимоверно кропотливая и трудозатратна.

К примеру, на платформе code4rena все отчеты выложены в удобном формате markdown. Собрать парсер можно за 10 минут с Claude. Далее фильтр по языкам и вот все отчеты готовы. А дальше самое нудное - берешь отчет, ищешь конкурсный репо на GitHub, ищешь контракты, в которых находили эти баги. Сохраняешь контракты в markdown файле. Затем ищешь актуальный репо протокола с исправленным кодом, проверяешь, что баг был действительно исправлен и добавляешь этот код в markdown. Как вы понимаете, это работа не на одного человека, и не на пару месяцев. К тому же, что делать, если ни код протокола, ни его официальный репо не являются открытыми для общественности?

Вероятно, только одна-две компании в мире готовы выделять на это время и деньги.

Всем остальным, довольствоваться только имеющимися открытыми отчетами.

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

Вот поэтому и нет достойных открытых моделей для аудита.

Для проекта я решил пойти другим путем: вместо того, чтобы обучать на полных данных, я хочу попробовать обучить модель только на открытых отчетах (на данный момент их 23 265), и сделать модель-паникер.

Вместо того, чтобы анализировать код, она будет просто смотреть на схожие моменты и выдавать пометки для аудита. Да, будет огромное количество false positives, т.е. ошибочных правок. Но могут быть и валидные. Тут вопрос в том, сколько пометок сделает модель.

Другой вопрос, как валидировать такие находки? С одной стороны, многие агенты делают кросс-чек, т.е. проверяют друг друга, с другой - можно отсеять самые "плохие" и провести тесты на остальных.

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

Так или иначе, модель-паникер для локального прогона контрактов, может дать хорошую почву для последующей работы остальных моделей и самих аудиторов.

В общем, эту модель я тоже планирую дать в общий доступ на huggingface с описанием процесса обучения, примеров данных и процессом аудита, который будет заложен в нее.

Что думаете по такой модели-паникер?

#ai #audit

📟 Прилетело из @solidityset

В этом видео — реальная запись mock-интервью нашего студента, который за 14 дней освоил базовый и продвинутый Solidity, сделал финальное задание и сел отвечать перед действующим аудитором смарт-контрактов из компании MixBytes.

Вы увидите:
— Какие вопросы реально задают на собеседовании Solidity-разработчика и аудитора.
— Разбор типов доступа, tx.origin vs msg.sender, require vs assert, нюансы selfdestruct и ABI encoding.
— Опасные моменты: selector clash, проблемы с donation-атаками и как их избежать.
— Практическое задание — написать Vault (ERC-4626) с нуля за 30 минут.
— Честную обратную связь: где ошибся, где проявил внимательность, и что нужно подтянуть для реального оффера.

По промокоду LIFECHANGE скидка -30% на guidedao.xyz до 20 апреля😎
https://youtu.be/iNm3gdKmXAE

📟 Прилетело из @dev_in_ruby_colors

Итоги канала за 3 года

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

Начали мы с софта на Starknet и дошли до сеточной торговли на Polymarket/PredictFun. Этот путь дал мне очень много опыта и знакомств, но он подходит к концу. Ретро в типичном понимании для меня закончилось.

Успешные кейсы в дропах:
• Unisat
• BeraChain
• Movement
• Somnia
• Hyperlane
• Limitless

Остальные проекты (больше 15) вышли меньше одного икса на вложенные траты или до сих пор не вышли. В сухом итоге мы имеем то, что каждый мог, но не каждый смог.

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

Ретро было хорошим приключением, но как минимум до глобальной бычки делать на него упор я не буду. Пришла пора двигаться дальше, поэтому канал вместе со мной будет адаптироваться к нынешним реалиям.

В данный момент я активно ищу заказы в любой области Web3 и если вам нужны руки что-то реализовать, то буду рад с вами сотрудничать - @realaskaer.

Ночью вместо сна занят билдингом и поддержкой текущих софтов в astrum.labs. Пока что постить в канал еще не придумал, но Claude обещал с этим помочь (скорее всего что будет хоть чуть-чуть интересно вам).

Спасибо что остаетесь со мной друзья, через несколько дней у меня ДР и честно мне пиздец страшно из-за полной неопределенности, но вроде только в таком состоянии люди делают по настоящему грандиозные вещи.

stay tuned...

📟 Прилетело из @askaer

Посмотрел Zoo Finance. Проект выглядит интересно, но при проверке там быстро начинаются вопросы

Решил пройтись по нему по своей обычной схеме: команда, концепт, коин, код, риски + практика.


Команда:

У проекта есть страница компании в LinkedIn, указана штаб-квартира в Бостоне.
Из публичных участников я увидел двух: Zhuangzhuang Chang (Co-Founder / CEO) и Joey Wong (COO).
Соцсети тоже живые. Плюс я писал им в Discord, и мне всё же ответили на вопросы, пусть и не сразу.

Команда не анонимная. Но полной прозрачности по всем ключевым участникам я пока всё равно не увидел. Поэтому здесь у меня 4 из 5.


Концепт:

Zoo Finance решает вполне понятную задачу: ликвидность для заблокированных активов.
То есть речь про вестинг, награды с нод, потоки доходности и другие истории, где актив у пользователя уже есть, но использовать его сразу в полном объёме нельзя.
Zoo Finance позволяет получать торгуемые токены под будущие разлоки или доходность без нарушения правил вестинга.
Они поддерживают 4 типа хранилищ: LVT-Vault (для вестинга), LNT-Vault (для нод), L-Vault (стейблкоин с маржинальным обеспечением) и B-Vault (для токенизации доходности PoL - Proof of liquidity).
По данным DefiLlama, TVL около 35 млн $, но roadmap внятно не раскрыт.
Есть партнёрства с Aethir и 0G.
Конкуренты тоже упоминаются, и это плюс.

Оценка 4 из 5.


Коин:

Нативного токена пока нет. Поэтому классическую токеномику здесь пока не оценить: ни утилиты, ни распределение, ни будущие разлоки.

Но известно об инвестициях в размере 10 МЛН $.
По данным Cryptorank, в проект вложились OKX Ventures, CMS Holdings, Bitrise Capital, Signum Capital и другие.

В итоге по коину 3 из 5.


Код:

Из документации я узнал, что был аудит CertiK.
На GitHub есть 18 репозиториев, но в основном это сайт, интерфейсы, NFT-ноды и связанная инфраструктура.
Для меня главный минус тут в том, что код основных смарт-контрактов публично не виден.

По коду здесь у меня 2 из 5.


Риски:

1. Ограниченная открытость core-части.

2. В аудите отдельно отмечался риск централизации, связанный с админскими полномочиями. А значит, часть доверия к системе всё равно остаётся на стороне команды.

3. Сложность самой модели. Чем больше составных механик внутри проекта, тем внимательнее его приходится проверять.


Практика:

На сайте app.zoofi.io сверху показывается B-vault. Это хранилище доходности для PoL (Berachain).

В LNT Vault я увидел Reppo Solver Node и Aethir Checker Node.
Там можно завести и вывести NFT, получить vATH и сделать swap.
Поддерживается и "Put Option" с постепенной конвертацией.

В LVT-Vault - Filecoin 540-Locked Vault, Story IP 360-Locked Vault, SEI 360-Locked Vault.
По названиям уже понятно, что это vault'ы под вестинг токенов.
У Story можно, например, обменять, управлять ликвидностью или выбрать Put Option (постепенно переводить в IP) или Wrap IP в WIP.
У Filecoin есть только Put Option и swap с ликвидностью.

Оценка 4 из 5: мало предложений, но интерфейс более-менее понятный.


Мой вывод

У Zoo Finance есть понятный прикладной концепт.

Команда не выглядит анонимной, инвестиции есть, аудит тоже есть.

Но закрытость core-части, ограниченная техническая проверяемость и отдельно отмеченный риск централизации всё равно заставляют смотреть на проект осторожно.

Более быстрый аудит проекта под ваш запрос можно заказать на https://tcccai.xyz.

А если смотрели Zoo Finance сами, интересно, что вас там смутило или, наоборот, понравилось?

😎 Незрячий web3 программист (подписаться)
Чат | бот

📟 Прилетело из @blind_dev