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

Создаем свои скиллы (часть 4) Что касается создания своих скиллов – тут я обычно беру skill-creator от Anthropic. Очень мощная штука: проводит по всему флоу создания, задаёт уточняющие вопросы и помогает написать евалы – чтобы при доработке скилла сразу видеть, что старые сценарии не сломались. Скиллов общего назначения сейчас супер много, и, как по мне, имеет смысл находить что-то популярное и местами подточить под себя. Сам я пишу скиллы под около-рутинные задачи – там, где хочу передать агенту экспертизу. Например, на работе периодически нужно делать релиз-ноты – и в продукте, и на информационных площадках. Процесс довольно топорный: 1. Достать из таск-трекера то, что вошло в релиз 2. Методом пристального взгляда отфильтровать то, что важно пользователям 3. Сформулировать всё на пользовательском языке, перевести на английский 4. Найти в кодовой базе json, который отвечает за релиз-ноты, и дописать нужное – то же самое для английского ... N. Закоммитить, запушить N+1. Взять эти релиз-ноты, расписать подробнее по шаблону и разложить по площадкам Руками это задача на час минимум. Топорно с агентом – минут пятнадцать. Со скиллом – три минуты. Или, например, скилл для постов: проверить грамматику, поставить нужный тег и опубликовать из Obsidian, применив телеграммное форматирование (вручную это очень заморочно). Аналогично есть скилл для моего таск-менеджера TickTick. Надиктовал задачу – а он уже знает, в какое место её положить, какую дату поставить, какие теги навесить. Очень удобно. Ещё пара моментов: – Скиллы стоит делать от сценариев. Обычно сначала просто решаешь задачу через агента, а потом понимаешь, что это можно обернуть в скилл – Не жди, что заработает с первого раза – особенно на сложных скиллах. Это инкрементальный процесс: нашёл, где не работает – подточил, написал евал – и так из раза в раз – skill.md не резиновый. Общая рекомендация Anthropic – не больше 5000 токенов, но и это кажется дофигамба. Держим skill.md маленьким, остальное выносим в references – Не пиши в скилле общеизвестное. Как понять, что лишнее? Только опытным путём: есть сомнения – удаляешь кусок информации и смотришь, как работает. Опять же, skill-creator при прогоне евалов сам подсказывает, что можно улучшить #devfm #ai

#agents #llm

Где брать скиллы (часть 3) С тем, как устроены скиллы, разобрались, даже в движении. А где их брать? Мне нравится простой каталог skills.sh. Удобно, что можно отсортировать по популярности или посмотреть, что сейчас набирает обороты – можно позалипать, вдохновиться. Из тех, чем сам пользуюсь: frontend-design – уже про него рассказывал. Лучший способ получить адекватный дизайн, когда дизайнера рядом нет. brainstorming – запускаешь перед началом работы над задачей, и агент начинает задавать уточняющие вопросы. После 5–6 вопросов требования становятся заметно полнее. На практике брейншторм почти всегда поднимает что-то, о чём не подумал или отложил на потом. pptx – скилл от антропика для работы с презентациями. Два режима: с нуля (чтобы было не вырви глаз) или создать по существующему шаблону – очень удобно. У ребят есть аналогичные скиллы и для pdf, docx, xlsx – тоже стоит присмотреться. playwright-skill – никогда написание тестов не было таким простым и бесплатным. Если необходимость unit-тестов для агента ещё под вопросом, то полноценные e2e – мастхев, и плейрайт-скилл сильно облегчает задачу. Делитесь, какими скиллами пользуетесь – интересно собрать подборку. #devfm #ai

#agents #llm

Что там с MCP Когда придумали MCP – это было чудо чудесное. Агент общается с любым внешним сервисом через единый протокол, и тебе не нужно писать обвязку под каждую интеграцию. MCP-серверы стали городить как не в себя. Потом начали вылезать технические нюансы. Описания тулов жрут контекст – подключил несколько серверов, и половина окна занята ещё до первого запроса. Ещё одна проблема, которую я часто вижу на практике. Владелец сервиса, который пишет свой MCP, просто повторяет в нём свой API. В итоге появляются десятки тулов, между которыми агент путается. И вот вышло новое видео от Anthropic – про текущее состояние MCP и планы дальше. MCP – это про коммуникацию с внешними сервисами, и в этой области он реально полезен. А проблема забитого контекста – это не про протокол, а про клиента. Решается с помощью progressive disclosure: нужные тулы подгружаются на лету, по аналогии со скиллами. Ближайшие планы: – Stateless transport – чтобы MCP-сервера можно было хостить как обычный stateless REST. Сейчас streamable HTTP плохо масштабируется – Server discovery – клиент автоматически находит MCP-сервер сайта по well-known URL. Заходит браузер или агент на сайт – и сразу видит, есть ли у него MCP – Skills over MCP – сервер сможет отдавать не только тулы, но и инструкции с доменными знаниями. То есть сервер сам учит агента, как им пользоваться – TypeScript и Python SDK – с учётом набитых шишек ребята будут активно переделывать SDK В общем MCP никуда не исчезают, а продолжают развиваться в своей нише. #ai

#agents #llm

Все ли так классно со скиллами – часть 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