Интересное что-то

Все ли так классно со скиллами – часть 2

В моём окружении скиллы едут и бибикают – периодически слышу: теперь ни рулы, ни MCP не нужны, скиллы всё заменят. Давайте разбираться.

Skills vs rules/agents.md
Идея звучит соблазнительно: все командные правила кладём в скиллы, агент сам подтянет нужный.

На эту тему ребята из Vercel недавно выпустили статью. У них была задача дать ai-агентам актуальную документацию по собственному API. Сравнили два подхода – скиллы и agents.md. Получилось любопытно.

Скилл периодически не срабатывал. Что ожидаемо – обещание "агент сам подтянет скилл, когда нужно" оказалось зыбкой почвой. Если же в промпте прямо написать "используй скилл" – срабатывает чаще, но появляется сайд-эффект: агент якорится на документации из скилла и перестаёт смотреть контекст проекта.

С agents.md такой истории не случилось. По сути, убирается точка принятия решения – информация всегда в контексте, и гадать "а надо ли сходить за докой" не приходится. А чтобы контекст не переполнялся, в agents.md кладут не всю доку, а сжатый индекс – указатель, где смотреть по какой функциональности.

Вывод: скиллы хорошо работают под конкретные сценарии – скилл по проведению ревью, скилл миграции. А для пассивных знаний о проекте лучше подходят rules/agents.md.

Skills + CLI vs MCP
Следующий заход, который я слышу всё чаще: давайте выкинем MCP, обернём походы во внешние сервисы в cli-утилиты, а в скилл положим инструкцию, как дергать cli. Идея – блеск. Ну по крайней мере на первый взгляд.

Во многом разделяю позицию автора статьи – делать так не стоит.

MCP – это по сути абстракция над API. LLM не нужно знать, как устроен сервис: достаточно вызвать service.do_x(), а MCP-сервер делает всё остальное. Коннектор между моделью и сервисом, где все шероховатости спрятаны.

А когда ту же задачу пытаются переложить на скиллы, начинаются нюансы:
– К скиллу нужно ещё доставить cli-утилиту. А если в окружении нет консоли – всё, приехали
– Обновление непрозрачное: не до конца понятно, как раскатывать обновления скиллов
– Аутентификация – туман войны, как параноидально управлять токенами изнутри скилла – до конца неясно
– Скиллы обещают экономить контекст, но это не всегда так. Нужен тебе буквально один вызов, а в контекст улетает весь SKILL.md
– Поддержка скиллов у агентов вроде есть, но у каждого свои нюансы. Универсальности, на которую хотелось бы рассчитывать, нет

Итого: скиллы – не замена MCP, а другой инструмент под другие задачи. А что имеет смысл попробовать – skill over MCP. MCP остаётся слоем соединения с сервисом, а Skill добавляется поверх как слой знаний о том, как этим MCP правильно пользоваться.

В следующем посте посмотрим, что сейчас происходит с MCP.

#ai

Скиллы в агентах – часть 1: база

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

Скилл – это модульная инструкция для агента, которая подгружается в контекст по необходимости. По сути – ещё один способ заставить агента работать так, как вам надо. Но с парой важных отличий.

Модульность
Скилл – это обычная папка. Внутри обязательный SKILL.md – основная инструкция, которую читает агент: что делает скилл, когда его применять и как именно действовать. Рядом можно положить что угодно: референсы, примеры, вспомогательные скрипты, которые агент вызывает по ходу работы.

my-skill/
├── SKILL.md
├── references/
│ └── examples.md
└── scripts/
└── helper.py

В SKILL.md обязателен фронтматтер с двумя полями – name и description.

Progressive disclosure
В отличие от правил (rules) или agents.md, которые грузятся в начале каждой сессии, тело скилла в контекст не попадает. Изначально там только name и description из фронтматтера – буквально пара строк. Агент сам решает, нужен ли скилл под текущую задачу, и только тогда подтягивает содержимое.

Думаю, именно поэтому скиллы набирают такую популярность.

В проектах, которые я видел, бывает куча рулов, которые грузятся по умолчанию, и контекст забит ещё до того, как ты начал работать. С MCP та же история (хотя с этим пытаются бороться – писал тут). Добавил несколько MCP-серверов, и добрая часть контекстного окна уходит под описания тулов, которые в этой сессии даже не пригодятся. Всё это осложняется тем, что обычный пользователь агентов не сразу поймёт, в чём у него проблема, будет страдать и не понимать, почему агент тупит на ровном месте.

Скиллы этой боли лишены. Можно иметь десятки скиллов – и практически нулевую нагрузку на контекст, пока они реально не понадобятся. А значит, в агента можно паковать большое количество экспертизы: как у вас устроены миграции, как правильно собрать релиз, как команда делает код-ревью.

Чтобы лучше разобраться, как работают скиллы – подготовил визуализацию.

В следующем посте посмотрим, а так ли всё хорошо с этими вашими скиллами.

#devfm #ai

#agents #llm

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

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

Звучит гротескно, но жиза 🙂 https://t.me/badTechProject/2043

Я бы еще добавил умение отвечать на такие вопросы:

1. В чем РЕАЛЬНАЯ цель проекта? Официальную-то мы все знаем, а вот на самом деле у кого что отвалится, кому надо выслужиться, премию получить или по-пацански выглядеть – это надо понимать.

2. Кто за что отвечает и кто наделен полномочиями? Чтобы не играть в игру «горячая картошка» на проекте с кучей команд и исполнителей. И чтобы понимать кому и куда эскалировать, и кому про что отчитываться.

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

4. Что будет, если не успеем в срок? Да, очень круто успевать в срок, но давайте честно, всякое бывает. Поэтому надо заранее понимать, где можно в срок не успеть, но его сдвинуть, и всем будет неприятно, но приемлемо. А, где наоборот, срыв срока - это капец беда, нет денег, потеря репутации, запоротый запуск анонсированного проекта. Вот там надо будет думать не о том, чтобы куда-то срок подвинуть, а как накостылить вовремя оптимизировать работу.

#softskills #career

6️⃣0️⃣0️⃣

Коллеги, всем спасибо за 600!

Расскажите откуда вы вообще на канале?

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

Открываем воскресную рубрику #лёшапочиталгодноту, буду читать статьи умных людей и делиться TLDR. Надеюсь, не сольюсь через одну неделю.

Сегодня в разборе - три статьи от Сергея Нотевского про кеширование промтов, которые форвардил несколько дней назад: https://t.me/sergeinotevskii/622

Еще раз, статьи - золото:

- Главное понятие, с которым нужно подружиться: KV-cache hit rate, то есть как часто ответы вашей LLM достаются из кэша, а также процент вашего промта, который кешируется

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

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

- Промт лучше структурировать так: Tools, System, Messages. Брейкпоинты кэша ставить либо в конце System, либо в начале Messages, в зависимости от того, насколько динамичные у вас диалоги и какая часть из них одинаковая. Для Tools обязательно используйте sort_keys=True, иначе некоторые библиотеки могут случайно менять порядок тулзов, и кеширования не будет вообще. Плюс думайте про динамические списки тулзов - озможно, такая оптимизация убьет вам всю экономику и агент будет стоить в пять раз дороже

- cache_control нужно ставить ни в коем случае не в системный промпт, а на уровне API Anthropic в нужные JSON-блоки обращения в модель

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

- Если вы используете OpenRouter вместо походов напрямую, он добавляет дополнительный уровень маршрутизации между внутренними провайдерами, и ваш запрос может попасть на непрогретый сервер без кэша (Bedrock вместо Vertex), и вы получите кэш-мисс

- У антропиков можно явно выставить руками кеш-брейкпоинты, но не больше четырех. Например, парочку в секциях System и один в Messages. Тогда если у нас что-то меняется в конце System, сработает первый в System, а если ничего не будет меняться, сработает последний Messages закеширована будет большая часть промта

- У антропиков есть два варианта кэширования на пять минут и на час разной по стоимости. Первый обойдется на 25% дороже, а второй в два раза. Зато чтение из кэша обойдется в 10 раз дешевле стандартной стоимости

- Также кеш влияет на время ответа от модели. Например, на промпте в 50 000 токенов без кэша время ответа может быть 12 секунд, а с кэшом 1 секунду

- У провайдеров есть минимальный размер промта для кэширования. Например, у Haiku это 4000 символов, у других моделей порядка 1000. То есть если у вас слишком простой промт, то кэширование будет доступно лишь при определенном наполнении истории

- В том же Anthropic кэширование работает не на уровне API ключей, а на уровне Workspace, для того чтобы нам было удобно иметь много разных проектов, агентов и не плодить для них разные API ключи

- Кэш живет ограниченное количество времени. Где-то это час, где-то пять минут, где-то больше. Помните, что он не вечен

- С точки зрения мониторинга hit rate и latency ответа не должны сильно бегать от релиза к релизу и в течение дня, когда у вас система прогрета. Посматривайте на эти графики

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

———
Уперся в лимит сообщения, на этом все!

Увидимся в новых сериях 😡

#agents #prompt

Китайская команда опять все украла разобрала архитектуру сlaude сode и собрала её заново с нуля - в 12 пошаговых сессиях.

Ядро агента - один цикл: отправь запрос → получи ответ → если LLM просит вызвать инструмент, выполни и верни результат → повтори. Всё остальное — надстройки.

Что добавляется по шагам:
- dispatch map для инструментов
- планирование через TodoWrite
- субагенты с независимым контекстом
- 3-уровневое сжатие контекста
- мульти-агентные команды через JSONL mailbox
- изоляция через worktrees

Главный инсайт проекта: семь бед один bash-инструмент покрывает 80% задач кодинг-агента. Сохрани в тг избранное и обязательно заботай (когда-нибудь точно)

#agents

TL:DR к статье, для тех кто не тимлид и не руководитель, но хочет резко прокачать свою работу с агентами

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

Для этого, путем многих итераций был создан скилл brainstorm. Он организует весь этот цикл. Просто попробуйте. Работает в Codex, Claude Code, и более менее других популярных агентах. Обычно, в промпте я триггерю скилл вручную и начинаю фразу "давай спроектируем/продумаем и тд". Крайне полезно после перечислить UserStory или верхнеуровневые требования. Самая крутая фича этого скила: возможность обсудить проблему/подход/решение с агентом и когда вопрос уточнен, он сам возвращается на прежний трек последовательных вопросов-ответов. Без форка сессии, с сохранением в контексте потока мыслей и гипотез.

Далее. Эту спеку я перекладываю в скилл Planner. Этот скилл разбивает спеку на спринты так, чтобы с 90% вероятностью 1 спринт уложился в 1 контекстное окно и выполнен за 1 заход. Кто бы что ни говорил, а 1М контекста в клоде либо оверюзает токены, либо качество деградирует. Модель держит форму до 400К, но после ... такое себе. GPT 5.5 стал есть драматически меньше токенов и я перестал сталкиваться с ухудшением результатов после автокомпакта.

На выходе обоих скиллов я получаю 2 артекфакта: спека + план. Далее я приступаю к методичной работе plan-implement используя простейший промпт, как например этот, когда делал дешборды аналитики в Prospect Guide:

Бери в работу Sprint 1 плана content-section-analytics-plan.md

И финалочка - скилл code-review. Через него я прогоняю результат работы по спринту.

/code-review Sprint 1 of content-section-analytics-plan.md

Не доверяясь целиком машине, ревьюю глазами, правлю, слежу за полной тестов и тд. В масштабе 1 спринта, делать это комфортно, есть возможность сверяться со спекой.

Вы вероятно спросите, почему это лучше популярного набора скилов superpowers, в котором есть brainstorm, write-plan, implement и другие?

1. Их brainstorm не дает подумать или изменить решение. Задает 3-4 вопроса, зачастую просто подтверждая указанные требования и фиксирует их в спеке. Я хочу, чтобы вопросов было больше, они были глубже, агент фильтровал их по значимости, исследовал код и нашел проблемы, невидимые с поверхности и обсудил и со мной. А потом убедился, что он правильно понял мое намерение.

2. write-plan пишет готовые вставки куда код воткнуть. Это дичь, которая меня дико бесила. Я хочу, чтобы спека и план формулировали ЧТО я хочу и КАК это лучше сделать, а не впихивали в план готовые куски кода, чтобы потом растасовать их по файлам. Ну и этот план нереально рабивать на куски. Useless вообщем. Хорошо для замены примитивного промптинга, но для серьезной работы никуда не годится.

Вот мой пак скилов завернутый в набор Skillforce на Github, забирайте, пользуйтесь, кидайте идеи и фидбек. Ставятся на изи, стандартным способом в любой репозиторий.

Подписывайтесь на MachineHead и делитесь с друзьями! Stay tuned! ✌️

#agents #llm #petproject

Топ-15 сайтов для подготовке к собесу, когда до него осталось три дня😎

Сейчас очень много подборок ресурсов по подготовке к собесам, но часто, когда времени мало, ты не успеваешь пройти все темы. Поэтому ниже я подготовил свой топ-ресурсов, который будет полезен каждому:
1. Когда сказали, что на кодинге будет мл задачи
2. Быстрые вопросы про LLM и docker в виде карточек
3. Архитектура AI-агентов, когда нужно выделиться
4. Понимание процессов в команде и разработке(методичка от моего бро)
5. Как правильно выбирать компанию
6. Хендбук от яндекса по мл, самая лучшая теория
7. Кейсы по MLSD, которые точно спросят
8. Если совсем все забыл и теорию надо вспоминать с нуля
9. Все, что тебе нужно знать про промпты
10. Практика по коду, меняя душная, чем на leetcode
11. Деплой и лучшие практики
12. Самое визуальное обьяснение LLM
13. Лучшая статья про трансформеры
14. Как работают нейронные сети
15. Все, что нужно быстро вспомнить про вероятности

💗 - если нужно больше таких подборок

#ml #systemdesign #interview

Как я сейчас пишу longreads на важные для меня темы (Рубрика #Writing)

Решил поделиться рецептом того, как сейчас пишу важные и сложные для меня статьи на технические темы. Из последнего это статьи «IDP is Dead? Нет, умирает монополия GUI» и «Agent-first IDP: как платформы к агентам готовят бигтехи и облака».

- Для меня все начинается обычно с того, что какой-то вопрос становится достаточно важным с точки зрения работы или своего внутреннего проекта
- Дальше это все доходит до потребности с этим разобраться и выработать какой-то план или стратегию достижения цели
- Обычно у меня к тому моменту есть опыт + открытые вопросы + примерный план что делать, который я рассказывал людям, чье мнение и фидбек для меня ценны
- Дальше я ухожу делать deep research обычно сразу в трех инструментах от Anthropic, OpenAI и Perplexity - обычно у меня есть определенное мнение + research questions + опорные тезисы + статьи, которые я вкидываю как обязательные к рассмотрению
- Дальше изучаю результаты, делаю факт-чекинг и читаю/смотрю приведенные источники
- Обычно самое интересное рождается в тех местах, где разные сервисы расходятся - это повод задать доп. вопросы + попросить кросс-ревью
- Дальше у меня в голове собирается некоторый план того, как двигаться в нужную сторону и дальше я обычно пишу тезисный план, который отдаю внешнему сервису
- Дальше делаю ревью документа сам + несколько итераций ревью с разными моделями
- Потом делаю визуализации нужных моментов для финальной статьи - я очень люблю схемы и визуализацию основных моментов

На выходе у меня обычно получается md, pdf и html версия статьи, которую я финально прогоняю через ревью и корректирую если требуется. Ну и в самом финале идет публикация самой статьи, причем в зависимости от платформы это может быть как простой процесс, так и сложный (например, в Medium движке нет таблиц и других важных элментов, поэтому приходится много вставлять изображениями).

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

#Writing #Research #Productivity

#agents #llm #petproject

Прочитал интересную (и применимую) статью Rethinking Early Stopping: Refine, Then Calibrate.

Часто в курсах по машинному обучению говорят, что ошибку системы можно разложить на bias, variance, noise. На некоторых редких курсах даже учат, как это считать и что с этим делать дальше.

Попробуем посмотреть на эту проблему с другой стороны. В задачах вероятностной классификации loss для proper scoring rules можно разложить на: calibration и refinement.

Калибровка — мы сказали, что вероятность 80%. Сколько из взятых образцов будут принадлежать к классу 1? (Считать это можно через ECE — Expected Calibration Error).

Refinement — насколько хорошо модель разделяет классы. Допустим, модель выдала скор 0.9, все образцы оказались класса 1, а все, что ниже — класса 0. Модель откалибрована так себе, но разделяет классно. Собственно, если бы модель была откалибрована, мы могли бы выбирать отсечку вероятностно через саму вероятность.

Легко представить и обратную ситуацию: модель прекрасно откалибрована, но разделяет плохо. Например, модель, которая всегда предсказывает вероятность 50% для честной монетки, идеально откалибрована, но её разделяющая способность минимальна.

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

Это плохо. Калибровку часто можно существенно поправить потом post-hoc методами, поэтому остановка обучения по лоссу на валидации может привести к ситуации, что мы взяли далеко не лучший чекпойнт.

Что делать?

Сохранить несколько чекпойнтов модели.
Откалибровать каждый из них одинаковым методом.
Только после этого сравнивать их по loss.

В таком случае для каждого чекпойнта мы отдельно минимизируем доступную calibration error выбранным post-hoc методом (ссылка на запись вебинара), а разница в loss начинает лучше отражать именно качество разделения классов. Соответственно, мы выбираем модель с лучшей разделяющей способностью, а не ту, которая случайно оказалась лучше откалибрована на данном этапе обучения.

Проверили на датасетах для computer vision и 196 табличных датасетах — так и оказалось, победа.

Может ли это хотя бы частично объяснять эффекты вроде grokking или double descent?
Там мы тоже наблюдаем нетривиальную динамику loss во времени. Возможно, на ранних этапах обучения модель в основном улучшает калибровку, затем временно жертвует ей ради построения более качественной разделяющей поверхности, а потом начинает улучшать уже обе составляющие одновременно.
#ArticleReview

#ml

⚙️ Меня немного запарило, что все кодинг агенты не умеют из коробки делать актуальных на сегодня агентов, потому что внутри – модели еще не обучены всем современным агентским трюкам – поэтому я прошелся по исходникам Codex, Claude Code и других популярных уроков по созданию агентов, работу с кешами, авто-сжатием контекста и тп, и собрал скилл agents-best-practices который чинит эту проблему – причем, там отдельно прописано, что эти знания для всех видов агентов, не только для кодинга:

Там нет кода, есть текстовые справочники на темы – мне помогло:

Архитектура агентного harness
Как устроить runtime вокруг модели: контекст, инструменты, permissions, память, наблюдаемость и остановочные условия.

Agentic loop
Базовый цикл: модель → tool call → валидация → permission check → выполнение → observation → следующий шаг или финальный ответ.

System prompts и инструкции
Как проектировать слои промптов: global, workspace, domain-specific, task-level и runtime reminders.

Tools и permissions
Как делать инструменты узкими, типизированными, безопасными, проверяемыми и разделёнными по risk class.

Planning mode
Как отделять планирование от исполнения: read-only exploration, план-артефакт, approval и потом мутации.

Goal-like loop
Как задавать долгоживущие цели с budget, checkpoints, validation criteria и stop condition. Это вместо Ralph Loop.

Context, memory и auto-compaction
Как управлять контекстом, делать retrieval, сохранять рабочее состояние и сжимать историю без потери критичных данных.

Prompt caching и cost-aware context
Как строить стабильные prompt-prefixes, deterministic tool ordering и cache-friendly agent runtime.

Skills и progressive disclosure
Как подключать reusable workflows: короткий skill index сначала, полные инструкции только при необходимости.

MCP и external connectors
Как подключать внешние системы через governed connectors: namespacing, auth, permissions, audit logs и least privilege.

Security, approvals и sandboxing
Prompt injection, secrets, approval flows, draft-vs-commit, sandbox для open-world tools.

Observability и evals
Как логировать agent runs, tool calls, approvals, compactions, failures и тестировать harness на реальные failure modes.

Provider API patterns
Практики для OpenAI, Anthropic и OpenAI-compatible API без привязки к одному провайдеру.

Checklists и coverage audit
Готовые списки для проверки: перед запуском, перед добавлением tools, перед подключением skills/connectors и перед продом.

#agents