Skills не конкурируют со скриптами / IaC. Terraform/Ansible/CI - это то, что должно делать “железо” детерминированно. Skill в таких местах скорее плейбук/процедура поверх инструментов: как собрать контекст, какие проверки обязательны, какие стоп-критерии, где нужен human approval, какой шаблон коммуникации, какие артефакты приложить в тикет и т.д. То есть навык описывает как правильно пользоваться уже существующими детерминированными инструментами.
Про ответственность тоже согласен. Прод остаётся за человеком, покрайней мере пока) "deployment skill” имеет право на жизнь в режиме dry-run: агент готовит план, запускает проверки, собирает результаты, оформляет список изменений/тикет/сообщение, а кнопка “поехали” - через человека или через строгий gate.
И да - ваш пример с саппортом очень близок к каноническому кейсу, особенно когда вход неструктурированный, а выход должен быть строгим.
Это ложится на skill-подход: один skill может быть “support-triage” (правила классификации + критерии уверенности + шаблоны ответов), а дальше - отдельные skills для ошибок логина, оплаты, ui и т.п. Такой разнос по навыкам - вместо огромного системного промпта получается библиотека процедур, которые подтягиваются по требованию.
Ага, Cursor постарались сблизить эти понятия. В их доках skills описаны как “agent-decided rules”, те агент сам решает, когда навык релевантен, и применяет его.
Но если смотреть шире Cursor’а, отличие всё же есть: rules - это фича конкретного продукта (Cursor) и его формат/механика применения, а agent skills - это открытый переносимый пакет процедуры, который может жить в репозитории и работать в разных агентах. Cursor, по сути, просто сделал мэппинг навыков и rules.
Поэтому rules == skills верно курсора, но смысл концепции skills в портируемости и упаковке процедур (не только один текст правила, а ещё assets/references/scripts и т.п.).
Спасибо за коммент, в целом вы правильно разложили про “retrieval vs reasoning”.
Да, такой подход как вы описали имеет место быть, тут главное - если мы уверены что в ответ только в одном куске, то держим контекст узким. Большое окно - как запасной вариант.
Интересно какие модели локальные или с бесплатных сервисов можно использовать чтобы попробовать свой мини агент сделать. Как я понимаю нужна модель с tool call.
По локальным моделям конечно все зависит от производительности железа для запуска. Есть есть условный мак на м-серии, можно начать с gptoss-20b. Поиграться точно хватит и туллколинг есть.
Как формировать контекст для каждого звена агента.Целесообразно ли делать subtask чтобы они исполнитель писал промт под запроса и он выполнялся в отдельном контексте, а потом только возвращал результат.
Таких вопросов, к сожалению, в процессе создания агента появляется достаточно много. Я бы рекомендовал ознакомиться с 12 Factor Agents и рекомендациями о том как строить агентов от Claude и Manus. Там достаточно применимых к практике вещей.
Было бы интересно посмотреть на агента типа deepreserch с возможностью расширения. Лучше даже без кода, а сам принцип и базовые промты с возможностью расширения.
У Валеры Ковальского и комьюнити есть проект SGR Deep Research, думаю что его изучение вполне может быть отправной точкой. И схемки есть :)
Вы правильно подметили две вещи.
Skills не конкурируют со скриптами / IaC.
Terraform/Ansible/CI - это то, что должно делать “железо” детерминированно. Skill в таких местах скорее плейбук/процедура поверх инструментов: как собрать контекст, какие проверки обязательны, какие стоп-критерии, где нужен human approval, какой шаблон коммуникации, какие артефакты приложить в тикет и т.д.
То есть навык описывает как правильно пользоваться уже существующими детерминированными инструментами.
Про ответственность тоже согласен. Прод остаётся за человеком, покрайней мере пока)
"deployment skill” имеет право на жизнь в режиме dry-run: агент готовит план, запускает проверки, собирает результаты, оформляет список изменений/тикет/сообщение, а кнопка “поехали” - через человека или через строгий gate.
И да - ваш пример с саппортом очень близок к каноническому кейсу, особенно когда вход неструктурированный, а выход должен быть строгим.
Это ложится на skill-подход: один skill может быть “support-triage” (правила классификации + критерии уверенности + шаблоны ответов), а дальше - отдельные skills для ошибок логина, оплаты, ui и т.п. Такой разнос по навыкам - вместо огромного системного промпта получается библиотека процедур, которые подтягиваются по требованию.
Ага, Cursor постарались сблизить эти понятия. В их доках skills описаны как “agent-decided rules”, те агент сам решает, когда навык релевантен, и применяет его.
Но если смотреть шире Cursor’а, отличие всё же есть: rules - это фича конкретного продукта (Cursor) и его формат/механика применения, а agent skills - это открытый переносимый пакет процедуры, который может жить в репозитории и работать в разных агентах. Cursor, по сути, просто сделал мэппинг навыков и rules.
Поэтому rules == skills верно курсора, но смысл концепции skills в портируемости и упаковке процедур (не только один текст правила, а ещё assets/references/scripts и т.п.).
Ну оперировать то он оперирует, но вопрос "насколько хорошо")
Тут кажется классика - в контексте накапливаются предыдущие размышления, подсчеты и тд - и "крыша начинает ехать".
Спасибо за коммент, в целом вы правильно разложили про “retrieval vs reasoning”.
Да, такой подход как вы описали имеет место быть, тут главное - если мы уверены что в ответ только в одном куске, то держим контекст узким. Большое окно - как запасной вариант.
По локальным моделям конечно все зависит от производительности железа для запуска. Есть есть условный мак на м-серии, можно начать с gptoss-20b. Поиграться точно хватит и туллколинг есть.
Таких вопросов, к сожалению, в процессе создания агента появляется достаточно много. Я бы рекомендовал ознакомиться с 12 Factor Agents и рекомендациями о том как строить агентов от Claude и Manus. Там достаточно применимых к практике вещей.
У Валеры Ковальского и комьюнити есть проект SGR Deep Research, думаю что его изучение вполне может быть отправной точкой. И схемки есть :)