Scoped skills, MCP и memory

1. От инструментов к знаниям: четыре слоя capability

Когда вы впервые начинаете настраивать subagent’ов, очень легко зациклиться на поле tools и решить, что работа почти сделана. Ловушка понятная: инструменты видны сразу и создают приятное ощущение контроля. Но хороший агент определяется не только набором «рук» — ещё и набором «знаний». Read, Bash, Edit отвечают лишь на вопрос о действиях. Они не говорят, по какой процедуре агент работает, куда смотрит и что тащит из прошлых задач.

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

test-strategy

Здесь особенно важна одна мысль: принцип least privilege применяется не только к tools, а сразу ко всем четырём слоям. Reviewer не занимается миграциями — migration-plan skill ему не нужен. Tester не анализирует внешнюю документацию — не нужен docs lookup. Роль не требует памяти — отсутствие memory не «недонастроенный агент», а дисциплина.

Хороший способ проверить конфигурацию — задать себе неприятный, но полезный вопрос: уберу этот skill, MCP или память — агент перестанет выполнять роль? Ответ «нет, просто ему спокойнее, потому что в чемодане лежит всё подряд» означает лишний контекст. А он для агента — как лишние вкладки в браузере: вроде всё важное, а сосредоточиться уже невозможно.

2. Scoped skills: свой workflow на роль

Со skills особенно легко ошибиться, потому что skill кажется безобидным — «всего лишь инструкция», не база данных, не запись в прод. И именно здесь многие подключают агенту все skills команды «на всякий случай». Агент начинает мыслить слишком широко, узкая роль расползается.

Вспомните, как устроен Workflow Kit в команде. Там нет одного большого skill «делай всё хорошо» — там отдельные артефакты под разные типы повторяемой работы: pr-review, test-strategy, migration-plan, release-notes, возможно, ещё issue-analysis. У разных ролей разные процедуры мышления. Reviewer читает diff, ищет риски, возвращает findings по severity. Tester думает уровнями тестов, edge cases, regression checks. Migration assistant читает changelog, ищет breaking changes, собирает compatibility picture. Дай всем всё сразу — получишь агента с богатым внутренним миром и слабой фокусировкой.

Внутри Workflow Kit:

workflow-kit/
  .claude/
    skills/
      pr-review/
      test-strategy/
      migration-plan/
    agents/
      reviewer.md
      tester.md
      migration-assistant.md

И дальше важно, чтобы reviewer.md тянул только review-skill, а tester.md — только тестовый workflow:

---
name: reviewer
tools: [Read, Grep, Bash]
skills:
  - pr-review   # чек-лист diff, evidence, severity
---

---
name: tester
tools: [Read, Grep, Bash, Edit]
skills:
  - test-strategy   # уровни тестов, edge cases, regression
---

Эти два примера похожи внешне, но мыслят по-разному. Reviewer не должен советовать миграционный план только потому, что в проекте лежит красивый skill migration-plan. Tester не должен посреди проверки refund diff переключаться в автора release notes. Агент с десятью skills похож на студента перед экзаменом: конспектов много, ясности мало.

Здесь есть ещё одна тонкая, но очень важная грань: skill не даёт новых прав. Reviewer подключён к pr-review, но без Edit — останется read-only. Skills описывают, как думать, tools определяют, что можно сделать руками. Поэтому scoped skill — не замена permission design, а его продолжение.

3. Scoped MCP: внешние источники привязаны к роли

С MCP хочется поступить как с power tools в гараже: пусть лежат у всех, вдруг пригодятся. С внешними источниками это особенно опасно. Лишний skill создаёт шум в мышлении. Лишний MCP создаёт шум в мышлении и лишнюю поверхность риска.

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

Для обычного reviewer на PR в Commerce OS внешние источники чаще всего не нужны: есть diff, файлы, тесты, команда локальных проверок. У tester хватает кода, существующих тестов и локального Bash. А вот migration assistant — совсем другое дело: ему реально нужен read-only доступ к docs lookup, чтобы сверяться с официальными changelog’ами и migration notes. Не база пользователей, не админка магазина, не платёжная система — один конкретный внешний канал для одной конкретной роли.

## MCP
- docs-lookup (read-only)
- без доступа к БД
- без внешних write-actions

В такой форме граница видна особенно хорошо: агент получает не «MCP в целом», а один конкретный внешний источник в режиме чтения. Read-only и write-capable — два разных мира. Read-only рискует тем, что принесёт в контекст слишком много данных или мусор. Write-capable уже может изменить внешнее состояние системы. Отсюда привычка: можно обойтись без MCP — обходимся; нельзя — сначала думаем о read-only.

Представьте: tester пишет regression test для refund flow. Подключите ему по умолчанию docs lookup, DB MCP и внешний issue tracker — и он пойдёт гулять по внешнему миру там, где задача решается чтением двух test-файлов и одного service-класса. Умнее он не станет. Он просто будет отвлекаться дороже.

4. Scoped memory: без цифрового хлама

Memory кажется самой уютной частью конфигурации. Кажется, будто сейчас мы научим агента «запоминать важное» — и дальше всё станет только лучше. На практике memory — место, где особенно быстро копится усталость системы. Хорошая memory экономит повторение стабильных фактов. Плохая консервирует случайные догадки и превращает их в привычки.

Поэтому первое правило здесь очень простое: не каждому агенту нужна память. Новый агент без memory — нормальный старт. Особенно про reviewer: ему часто помогает свежий взгляд, а не ассоциации из прошлых diff’ов.

Если память всё же нужна, кладите только стабильные, проверенные, повторяемые факты. Не «кажется, payment tests сегодня флакали, давайте их больше не трогать», а «integration tests лежат в таком-то каталоге» или «regression tests по refund ищем по префиксу Refund». Memory хранит договорённости и устойчивые паттерны, а не эмоциональные воспоминания агента о тяжёлом вторнике.

Локальная память роли tester:

# tester memory
- unit tests лежат в `backend/src/test/java`
- regression tests для refund ищем по префиксу `Refund`

Такой формат хорош тем, что он короткий и почти не оставляет пространства для фантазии. Но даже здесь важно помнить: как только память становится общей для команды, она перестаёт быть личной заметкой и превращается в общее поведение — а оно должно проходить review. Иначе у вас не «умный агент команды», а распределённая система распространения устаревших убеждений. Выглядит буднично: кто-то однажды добавил в memory фразу про flaky tests, и через месяц tester обходит важные проверки с невинным видом «я так запомнил».

5. Пример agents/tester.md: узкий контур знаний

Теория особенно быстро проясняется, когда вы собираете одного агента целиком. Возьмём agents/tester.md из Workflow Kit: он помогает на Commerce OS в задачах вроде bugfix в refund sorting или regression-проверок вокруг inbox. Нужен агент, который читает код, запускает тестовые команды, предлагает тест-дизайн и, если роль разрешает, редактирует только test-файлы. Ему не нужен review-skill, migration-plan, внешний docs lookup и память обо всех инцидентах компании. Берём собранный набор tools и доводим до рабочего профиля: один scoped skill, локальная память, те же жёсткие границы на редактирование.

Такой файл выглядит так:

---
name: tester
description: проектирует и запускает тесты для текущего diff; production-код не меняет
tools: [Read, Grep, Bash, Edit]
skills:
  - test-strategy
memory:
  scope: agent-local
---

## Ограничения
Редактируй только файлы в `src/test` и `tests/`.
Не используй внешние MCP servers, если это не указано отдельно.

В этом примере видно сразу несколько инженерных решений. Edit есть, но это не «широкое право на всё подряд»: ограничение на test-файлы закреплено в инструкции и, по возможности, техническими рамками проекта. Skill ровно один — test-strategy, этого хватает мыслить в правильной плоскости: unit, integration, API, regression, edge cases. Memory локальная: короткие ролевые заметки можно, но всё подряд в основную сессию не тащит и на другие роли не влияет.

А вот migration assistant, напротив, будет собран иначе:

---
name: migration-assistant
tools: [Read, Grep, Bash]
skills:
  - migration-plan
mcp:
  - docs-lookup   # read-only
---

Здесь уже нет Edit, зато появляется один внешний read-only источник — этой роли реально нужно читать официальные руководства и changelog’и. Заметьте, насколько полезно сравнивать такие агенты рядом: не потому, что у них «разные профессии», а потому что у них разный минимально достаточный контур знаний. А если задаче нужен только read-only анализ без правки test-файлов — это не новый агент с нуля, а более узкий режим того же tester. В этом и главная инженерная идея scoped design.

6. Как это выглядит в Workflow Kit

Когда вы настраиваете одного агента, всё довольно понятно. Настоящая красота scoped-подхода видна на уровне набора ролей. Workflow Kit перестаёт быть свалкой «полезных штук для Claude» и становится системой: у каждой роли свои tools, skill, внешний источник, подход к памяти. Тут доверяешь не уверенности тона, а предсказуемости поведения.

pr-review

test-strategy

migration-plan

Обратите внимание: таблица очень скучная. И это прекрасно. Хороший Workflow Kit редко выглядит эффектно — он выглядит так, будто кто-то слишком спокойно и педантично продумал границы. Reviewer не получает migration-plan, чтобы не видеть миграции в каждом rename. Tester не получает DB MCP, чтобы не искать внешнюю причину там, где сначала нужно написать regression test. Migration assistant не получает Edit, потому что его задача — собрать картину совместимости, а не в порыве вдохновения переписать полпроекта.

Именно поэтому scoped capability почти всегда повышает не только безопасность, но и качество результата. Чем уже контур знаний роли, тем меньше ложных срабатываний, контекстной пыли и соблазна «помочь ещё вот здесь, раз уж открыл файл». В хорошем Workflow Kit агент не чувствует себя всемогущим. Он чувствует себя уместным. А это для инженерного результата куда полезнее.

1

Задача

Claude code, 12 уровень, 1 лекция

Недоступна

Ограничение MCP и memory у `migration-assistant`

Ограничение MCP и memory у `migration-assistant`

Открыть

1

Задача

Claude code, 12 уровень, 1 лекция

Недоступна

Сужение набора skills у субагента

Сужение набора skills у субагента

Открыть