Forwarded from nlp_daily
Китайская команда опять все украла разобрала архитектуру сlaude сode и собрала её заново с нуля - в 12 пошаговых сессиях.
Ядро агента - один цикл: отправь запрос → получи ответ → если LLM просит вызвать инструмент, выполни и верни результат → повтори. Всё остальное — надстройки.
Что добавляется по шагам:
- dispatch map для инструментов
- планирование через TodoWrite
- субагенты с независимым контекстом
- 3-уровневое сжатие контекста
- мульти-агентные команды через JSONL mailbox
- изоляция через worktrees
Главный инсайт проекта: семь бед один bash-инструмент покрывает 80% задач кодинг-агента. Сохрани в тг избранное и обязательно заботай (когда-нибудь точно)
Ядро агента - один цикл: отправь запрос → получи ответ → если LLM просит вызвать инструмент, выполни и верни результат → повтори. Всё остальное — надстройки.
Что добавляется по шагам:
- dispatch map для инструментов
- планирование через TodoWrite
- субагенты с независимым контекстом
- 3-уровневое сжатие контекста
- мульти-агентные команды через JSONL mailbox
- изоляция через worktrees
Главный инсайт проекта: с
Forwarded from Остриков пилит агентов
Открываем воскресную рубрику #лёшапочиталгодноту, буду читать статьи умных людей и делиться 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 сек, а у вас хорошая многопоточность, вы за это время можете отправить тысячи запросов, не попавших в кэш
———
Уперся в лимит сообщения, на этом все!
Увидимся в новых сериях😡
Сегодня в разборе - три статьи от Сергея Нотевского про кеширование промтов, которые форвардил несколько дней назад: 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 сек, а у вас хорошая многопоточность, вы за это время можете отправить тысячи запросов, не попавших в кэш
———
Уперся в лимит сообщения, на этом все!
Увидимся в новых сериях
Please open Telegram to view this post
VIEW IN TELEGRAM
Коллеги, всем спасибо за 600!
Расскажите откуда вы вообще на канале?
И наверно как вы заметили я вообще не успеваю вычитывать посты и собирать крутую информацию в крутые теги, поэтому накидайте пожалуйста крутых ссылочек с вашими ботами, которые собирают дайджесты из новых постов в каналах - я попробую придумать что-нибудь покруче!
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Тимлид Очевидность | Евгений Антонов
Я принес. Простой, самый базовый совет, как выглядеть крутым менеджером
Есть у меня знакомый опытный менеджер, который через прикол выдал чистую правду.
Звучит гротескно, но жиза 🙂 https://t.me/badTechProject/2043
Я бы еще добавил умение отвечать на такие вопросы:
1. В чем РЕАЛЬНАЯ цель проекта? Официальную-то мы все знаем, а вот на самом деле у кого что отвалится, кому надо выслужиться, премию получить или по-пацански выглядеть – это надо понимать.
2. Кто за что отвечает и кто наделен полномочиями? Чтобы не играть в игру «горячая картошка» на проекте с кучей команд и исполнителей. И чтобы понимать кому и куда эскалировать, и кому про что отчитываться.
3. Какие мы уже видим риски? Сюрприз, но если на старте проекта, где все вроде бы уже кивнули и сказали «изян, сделаем», явно спросить, кто какие риски уже видит прямо сейчас, то откроетсяпортал в ад много всего интересного.
4. Что будет, если не успеем в срок? Да, очень круто успевать в срок, но давайте честно, всякое бывает. Поэтому надо заранее понимать, где можно в срок не успеть, но его сдвинуть, и всем будет неприятно, но приемлемо. А, где наоборот, срыв срока - это капец беда, нет денег, потеря репутации, запоротый запуск анонсированного проекта. Вот там надо будет думать не о том, чтобы куда-то срок подвинуть, а какнакостылить вовремя оптимизировать работу.
Есть у меня знакомый опытный менеджер, который через прикол выдал чистую правду.
Звучит гротескно, но жиза 🙂 https://t.me/badTechProject/2043
Я бы еще добавил умение отвечать на такие вопросы:
1. В чем РЕАЛЬНАЯ цель проекта? Официальную-то мы все знаем, а вот на самом деле у кого что отвалится, кому надо выслужиться, премию получить или по-пацански выглядеть – это надо понимать.
2. Кто за что отвечает и кто наделен полномочиями? Чтобы не играть в игру «горячая картошка» на проекте с кучей команд и исполнителей. И чтобы понимать кому и куда эскалировать, и кому про что отчитываться.
3. Какие мы уже видим риски? Сюрприз, но если на старте проекта, где все вроде бы уже кивнули и сказали «изян, сделаем», явно спросить, кто какие риски уже видит прямо сейчас, то откроется
4. Что будет, если не успеем в срок? Да, очень круто успевать в срок, но давайте честно, всякое бывает. Поэтому надо заранее понимать, где можно в срок не успеть, но его сдвинуть, и всем будет неприятно, но приемлемо. А, где наоборот, срыв срока - это капец беда, нет денег, потеря репутации, запоротый запуск анонсированного проекта. Вот там надо будет думать не о том, чтобы куда-то срок подвинуть, а как
Telegram
Плохой менеджер Артём Арюткин
Простой, самый базовый совет, как выглядеть крутым менеджером
Вот вы офигеете, но вот, чтобы всегда выглядеть крутым менеджером вам достаточно знать ответы всего на несколько вопросов:
1.
Кто мой стейкхолдер.
2.
Кто мои потребители (ТОП 5)
3.
Текущее состояние…
Вот вы офигеете, но вот, чтобы всегда выглядеть крутым менеджером вам достаточно знать ответы всего на несколько вопросов:
1.
Кто мой стейкхолдер.
2.
Кто мои потребители (ТОП 5)
3.
Текущее состояние…
Forwarded from DevFM
Скиллы в агентах – часть 1: база
Скиллы для агентов продолжают набирать популярность. Поэтому хочется пройтись по этой теме. Первая часть – база.
Скилл – это модульная инструкция для агента, которая подгружается в контекст по необходимости. По сути – ещё один способ заставить агента работать так, как вам надо. Но с парой важных отличий.
Модульность
Скилл – это обычная папка. Внутри обязательный
В
Progressive disclosure
В отличие от правил (rules) или
Думаю, именно поэтому скиллы набирают такую популярность.
В проектах, которые я видел, бывает куча рулов, которые грузятся по умолчанию, и контекст забит ещё до того, как ты начал работать. С MCP та же история (хотя с этим пытаются бороться – писал тут). Добавил несколько MCP-серверов, и добрая часть контекстного окна уходит под описания тулов, которые в этой сессии даже не пригодятся. Всё это осложняется тем, что обычный пользователь агентов не сразу поймёт, в чём у него проблема, будет страдать и не понимать, почему агент тупит на ровном месте.
Скиллы этой боли лишены. Можно иметь десятки скиллов – и практически нулевую нагрузку на контекст, пока они реально не понадобятся. А значит, в агента можно паковать большое количество экспертизы: как у вас устроены миграции, как правильно собрать релиз, как команда делает код-ревью.
Чтобы лучше разобраться, как работают скиллы – подготовил визуализацию.
В следующем посте посмотрим, а так ли всё хорошо с этими вашими скиллами.
#devfm #ai
Скиллы для агентов продолжают набирать популярность. Поэтому хочется пройтись по этой теме. Первая часть – база.
Скилл – это модульная инструкция для агента, которая подгружается в контекст по необходимости. По сути – ещё один способ заставить агента работать так, как вам надо. Но с парой важных отличий.
Модульность
Скилл – это обычная папка. Внутри обязательный
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
Forwarded from DevFM
Все ли так классно со скиллами – часть 2
В моём окружении скиллы едут и бибикают – периодически слышу: теперь ни рулы, ни MCP не нужны, скиллы всё заменят. Давайте разбираться.
Skills vs rules/
Идея звучит соблазнительно: все командные правила кладём в скиллы, агент сам подтянет нужный.
На эту тему ребята из Vercel недавно выпустили статью. У них была задача дать ai-агентам актуальную документацию по собственному API. Сравнили два подхода – скиллы и
Скилл периодически не срабатывал. Что ожидаемо – обещание "агент сам подтянет скилл, когда нужно" оказалось зыбкой почвой. Если же в промпте прямо написать "используй скилл" – срабатывает чаще, но появляется сайд-эффект: агент якорится на документации из скилла и перестаёт смотреть контекст проекта.
С
Вывод: скиллы хорошо работают под конкретные сценарии – скилл по проведению ревью, скилл миграции. А для пассивных знаний о проекте лучше подходят rules/
Skills + CLI vs MCP
Следующий заход, который я слышу всё чаще: давайте выкинем MCP, обернём походы во внешние сервисы в cli-утилиты, а в скилл положим инструкцию, как дергать cli. Идея – блеск. Ну по крайней мере на первый взгляд.
Во многом разделяю позицию автора статьи – делать так не стоит.
MCP – это по сути абстракция над API. LLM не нужно знать, как устроен сервис: достаточно вызвать
А когда ту же задачу пытаются переложить на скиллы, начинаются нюансы:
– К скиллу нужно ещё доставить cli-утилиту. А если в окружении нет консоли – всё, приехали
– Обновление непрозрачное: не до конца понятно, как раскатывать обновления скиллов
– Аутентификация – туман войны, как параноидально управлять токенами изнутри скилла – до конца неясно
– Скиллы обещают экономить контекст, но это не всегда так. Нужен тебе буквально один вызов, а в контекст улетает весь
– Поддержка скиллов у агентов вроде есть, но у каждого свои нюансы. Универсальности, на которую хотелось бы рассчитывать, нет
Итого: скиллы – не замена MCP, а другой инструмент под другие задачи. А что имеет смысл попробовать – skill over MCP. MCP остаётся слоем соединения с сервисом, а Skill добавляется поверх как слой знаний о том, как этим MCP правильно пользоваться.
В следующем посте посмотрим, что сейчас происходит с MCP.
#ai
В моём окружении скиллы едут и бибикают – периодически слышу: теперь ни рулы, ни 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
Forwarded from DevFM
Что там с 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
Когда придумали 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
Telegram
DevFM
Новый взгляд на MCP
Сложно сейчас представить использование AI-агентов без MCP-серверов.
MCP позволяет агенту подключаться к различным внешним системам, чтобы запрашивать данные, выполнять операции и выстраивать сложные цепочки взаимодействий.
Но текущий…
Сложно сейчас представить использование AI-агентов без MCP-серверов.
MCP позволяет агенту подключаться к различным внешним системам, чтобы запрашивать данные, выполнять операции и выстраивать сложные цепочки взаимодействий.
Но текущий…
Forwarded from DevFM
Где брать скиллы (часть 3)
С тем, как устроены скиллы, разобрались, даже в движении. А где их брать?
Мне нравится простой каталог skills.sh. Удобно, что можно отсортировать по популярности или посмотреть, что сейчас набирает обороты – можно позалипать, вдохновиться.
Из тех, чем сам пользуюсь:
frontend-design – уже про него рассказывал. Лучший способ получить адекватный дизайн, когда дизайнера рядом нет.
brainstorming – запускаешь перед началом работы над задачей, и агент начинает задавать уточняющие вопросы. После 5–6 вопросов требования становятся заметно полнее. На практике брейншторм почти всегда поднимает что-то, о чём не подумал или отложил на потом.
pptx – скилл от антропика для работы с презентациями. Два режима: с нуля (чтобы было не вырви глаз) или создать по существующему шаблону – очень удобно. У ребят есть аналогичные скиллы и для pdf, docx, xlsx – тоже стоит присмотреться.
playwright-skill – никогда написание тестов не было таким простым и бесплатным. Если необходимость unit-тестов для агента ещё под вопросом, то полноценные e2e – мастхев, и плейрайт-скилл сильно облегчает задачу.
Делитесь, какими скиллами пользуетесь – интересно собрать подборку.
#devfm #ai
С тем, как устроены скиллы, разобрались, даже в движении. А где их брать?
Мне нравится простой каталог skills.sh. Удобно, что можно отсортировать по популярности или посмотреть, что сейчас набирает обороты – можно позалипать, вдохновиться.
Из тех, чем сам пользуюсь:
frontend-design – уже про него рассказывал. Лучший способ получить адекватный дизайн, когда дизайнера рядом нет.
brainstorming – запускаешь перед началом работы над задачей, и агент начинает задавать уточняющие вопросы. После 5–6 вопросов требования становятся заметно полнее. На практике брейншторм почти всегда поднимает что-то, о чём не подумал или отложил на потом.
pptx – скилл от антропика для работы с презентациями. Два режима: с нуля (чтобы было не вырви глаз) или создать по существующему шаблону – очень удобно. У ребят есть аналогичные скиллы и для pdf, docx, xlsx – тоже стоит присмотреться.
playwright-skill – никогда написание тестов не было таким простым и бесплатным. Если необходимость unit-тестов для агента ещё под вопросом, то полноценные e2e – мастхев, и плейрайт-скилл сильно облегчает задачу.
Делитесь, какими скиллами пользуетесь – интересно собрать подборку.
#devfm #ai
Telegram
DevFM
Скиллы в агентах – часть 1: база
Скиллы для агентов продолжают набирать популярность. Поэтому хочется пройтись по этой теме. Первая часть – база.
Скилл – это модульная инструкция для агента, которая подгружается в контекст по необходимости. По сути – ещё…
Скиллы для агентов продолжают набирать популярность. Поэтому хочется пройтись по этой теме. Первая часть – база.
Скилл – это модульная инструкция для агента, которая подгружается в контекст по необходимости. По сути – ещё…
Forwarded from DevFM
Создаем свои скиллы (часть 4)
Что касается создания своих скиллов – тут я обычно беру skill-creator от Anthropic. Очень мощная штука: проводит по всему флоу создания, задаёт уточняющие вопросы и помогает написать евалы – чтобы при доработке скилла сразу видеть, что старые сценарии не сломались.
Скиллов общего назначения сейчас супер много, и, как по мне, имеет смысл находить что-то популярное и местами подточить под себя. Сам я пишу скиллы под около-рутинные задачи – там, где хочу передать агенту экспертизу.
Например, на работе периодически нужно делать релиз-ноты – и в продукте, и на информационных площадках. Процесс довольно топорный:
1. Достать из таск-трекера то, что вошло в релиз
2. Методом пристального взгляда отфильтровать то, что важно пользователям
3. Сформулировать всё на пользовательском языке, перевести на английский
4. Найти в кодовой базе json, который отвечает за релиз-ноты, и дописать нужное – то же самое для английского
...
N. Закоммитить, запушить
N+1. Взять эти релиз-ноты, расписать подробнее по шаблону и разложить по площадкам
Руками это задача на час минимум. Топорно с агентом – минут пятнадцать. Со скиллом – три минуты.
Или, например, скилл для постов: проверить грамматику, поставить нужный тег и опубликовать из Obsidian, применив телеграммное форматирование (вручную это очень заморочно).
Аналогично есть скилл для моего таск-менеджера TickTick. Надиктовал задачу – а он уже знает, в какое место её положить, какую дату поставить, какие теги навесить. Очень удобно.
Ещё пара моментов:
– Скиллы стоит делать от сценариев. Обычно сначала просто решаешь задачу через агента, а потом понимаешь, что это можно обернуть в скилл
– Не жди, что заработает с первого раза – особенно на сложных скиллах. Это инкрементальный процесс: нашёл, где не работает – подточил, написал евал – и так из раза в раз
–
– Не пиши в скилле общеизвестное. Как понять, что лишнее? Только опытным путём: есть сомнения – удаляешь кусок информации и смотришь, как работает. Опять же, skill-creator при прогоне евалов сам подсказывает, что можно улучшить
#devfm #ai
Что касается создания своих скиллов – тут я обычно беру skill-creator от Anthropic. Очень мощная штука: проводит по всему флоу создания, задаёт уточняющие вопросы и помогает написать евалы – чтобы при доработке скилла сразу видеть, что старые сценарии не сломались.
Скиллов общего назначения сейчас супер много, и, как по мне, имеет смысл находить что-то популярное и местами подточить под себя. Сам я пишу скиллы под около-рутинные задачи – там, где хочу передать агенту экспертизу.
Например, на работе периодически нужно делать релиз-ноты – и в продукте, и на информационных площадках. Процесс довольно топорный:
1. Достать из таск-трекера то, что вошло в релиз
2. Методом пристального взгляда отфильтровать то, что важно пользователям
3. Сформулировать всё на пользовательском языке, перевести на английский
4. Найти в кодовой базе json, который отвечает за релиз-ноты, и дописать нужное – то же самое для английского
...
N. Закоммитить, запушить
N+1. Взять эти релиз-ноты, расписать подробнее по шаблону и разложить по площадкам
Руками это задача на час минимум. Топорно с агентом – минут пятнадцать. Со скиллом – три минуты.
Или, например, скилл для постов: проверить грамматику, поставить нужный тег и опубликовать из Obsidian, применив телеграммное форматирование (вручную это очень заморочно).
Аналогично есть скилл для моего таск-менеджера TickTick. Надиктовал задачу – а он уже знает, в какое место её положить, какую дату поставить, какие теги навесить. Очень удобно.
Ещё пара моментов:
– Скиллы стоит делать от сценариев. Обычно сначала просто решаешь задачу через агента, а потом понимаешь, что это можно обернуть в скилл
– Не жди, что заработает с первого раза – особенно на сложных скиллах. Это инкрементальный процесс: нашёл, где не работает – подточил, написал евал – и так из раза в раз
–
skill.md не резиновый. Общая рекомендация Anthropic – не больше 5000 токенов, но и это кажется дофигамба. Держим skill.md маленьким, остальное выносим в references– Не пиши в скилле общеизвестное. Как понять, что лишнее? Только опытным путём: есть сомнения – удаляешь кусок информации и смотришь, как работает. Опять же, skill-creator при прогоне евалов сам подсказывает, что можно улучшить
#devfm #ai
GitHub
skills/skills/skill-creator at main · anthropics/skills
Public repository for Agent Skills. Contribute to anthropics/skills development by creating an account on GitHub.
Forwarded from DevFM
Голосовой ввод и visul explainer – чтобы структурировать мысли
Я давно использую visual explainer не только для презентаций. Один из полезных сценариев - структурировать свои мысли: выделить основные блоки, связи между ними и места, где чего-то не хватает.
Недавно мне нужно было подготовить стратегию дальнейшего движения нашего продукта. В целом понимание, что и зачем делать, уже было, но не складывалась картинка, как это презентовать.
Здесь хорошо сработала связка голосового ввода в Handy и скилла visual explainer.
Я просто начал надиктовывать свои мысли: что думаю, почему это важно, какие части связаны между собой. Если где-то было понимание, как я хочу это видеть, тут же надиктовывал: вот это сгруппировать с этим, это вынести отдельно, здесь показать связь.
В этом как раз плюс голосового ввода: обычно, когда пишешь, так или иначе пытаешься писать связно. А тут просто говоришь, как думаешь, и можно даже перескакивать между идеями.
Получившийся текст я отдал агенту с visual explainer и попросил структурировать.
Конечно, он не сделал готовый результат с первого раза. Не было истории, где агент взял все мои мысли, правильно структурировал их и сразу выдал готовую презентацию.
Но когда я посмотрел на первую визуализацию, стало намного понятнее, что не так: этот блок должен быть иначе, эта связь потерялась, вот здесь нужно сгруппировать по-другому. Где-то агент действительно попал, но главное - появился конкретный вариант, который уже можно править. По сути, это решило проблему белого листа: когда перед тобой есть первая версия, проще понять, как должно быть на самом деле.
Итоговый воркфлоу такой: надиктовываем поток мыслей, просим структурировать, от получившегося результата отталкиваемся и правим до нормальной презентации за несколько итераций. Уже делал так несколько раз - попробуйте.
#ai #devfm
Я давно использую visual explainer не только для презентаций. Один из полезных сценариев - структурировать свои мысли: выделить основные блоки, связи между ними и места, где чего-то не хватает.
Недавно мне нужно было подготовить стратегию дальнейшего движения нашего продукта. В целом понимание, что и зачем делать, уже было, но не складывалась картинка, как это презентовать.
Здесь хорошо сработала связка голосового ввода в Handy и скилла visual explainer.
Я просто начал надиктовывать свои мысли: что думаю, почему это важно, какие части связаны между собой. Если где-то было понимание, как я хочу это видеть, тут же надиктовывал: вот это сгруппировать с этим, это вынести отдельно, здесь показать связь.
В этом как раз плюс голосового ввода: обычно, когда пишешь, так или иначе пытаешься писать связно. А тут просто говоришь, как думаешь, и можно даже перескакивать между идеями.
Получившийся текст я отдал агенту с visual explainer и попросил структурировать.
Конечно, он не сделал готовый результат с первого раза. Не было истории, где агент взял все мои мысли, правильно структурировал их и сразу выдал готовую презентацию.
Но когда я посмотрел на первую визуализацию, стало намного понятнее, что не так: этот блок должен быть иначе, эта связь потерялась, вот здесь нужно сгруппировать по-другому. Где-то агент действительно попал, но главное - появился конкретный вариант, который уже можно править. По сути, это решило проблему белого листа: когда перед тобой есть первая версия, проще понять, как должно быть на самом деле.
Итоговый воркфлоу такой: надиктовываем поток мыслей, просим структурировать, от получившегося результата отталкиваемся и правим до нормальной презентации за несколько итераций. Уже делал так несколько раз - попробуйте.
#ai #devfm
GitHub
GitHub - nicobailon/visual-explainer: Agent skill that generates rich HTML pages or slide decks for diagrams, diff reviews, plan…
Agent skill that generates rich HTML pages or slide decks for diagrams, diff reviews, plan audits, data tables, and project recaps - nicobailon/visual-explainer
Forwarded from Рыба-шарп
Max Dama on Automated Trading
Недавно видел в Реддите дискуссию о том, кто из quant-инфлюенсеров - Christina Qi или Giuseppe Paleologo (Gappy) - прав. Дискуссия предсказуемо пришла к тому, что ни Кристина, ни Гаппи не обладают необходимой квалификацией!
Я не настолько радикален - все-таки Кристина несколько лет была CEO своего хедж-фонда, а сейчас СЕО компании DataBento, которая продает данные для трейдинга. Гаппи же сейчас Global Head of Quant Research в Balyasny. Так что что-то об индустрии они знают!
Если же вы хотите реально что-то понять, то советую читать Max Dama on Automated Trading. Это текст меньше, чем на 60 страниц, который написан настолько хорошо, что я жалею, что его написал не я! Max Dama написал его, когда был студентом, а сейчас он партнер в Headlands!
http://isomorphisms.sdf.org/maxdama.pdf
https://www.reddit.com/r/quant/comments/1k4nivo/what_are_your_thoughts_on_the_christina_qi_vs/
#хеджфонды
Подписаться на канал https://t.me/rybasharp
Недавно видел в Реддите дискуссию о том, кто из quant-инфлюенсеров - Christina Qi или Giuseppe Paleologo (Gappy) - прав. Дискуссия предсказуемо пришла к тому, что ни Кристина, ни Гаппи не обладают необходимой квалификацией!
Я не настолько радикален - все-таки Кристина несколько лет была CEO своего хедж-фонда, а сейчас СЕО компании DataBento, которая продает данные для трейдинга. Гаппи же сейчас Global Head of Quant Research в Balyasny. Так что что-то об индустрии они знают!
Если же вы хотите реально что-то понять, то советую читать Max Dama on Automated Trading. Это текст меньше, чем на 60 страниц, который написан настолько хорошо, что я жалею, что его написал не я! Max Dama написал его, когда был студентом, а сейчас он партнер в Headlands!
http://isomorphisms.sdf.org/maxdama.pdf
https://www.reddit.com/r/quant/comments/1k4nivo/what_are_your_thoughts_on_the_christina_qi_vs/
#хеджфонды
Подписаться на канал https://t.me/rybasharp