LLM-pres_context_engineering_visual_compact_v9

1.

Не делай промпт длиннее.
Сделай context умнее.
Rules • Skills • Agents • MCP
уже не просто отвечает на запросы.
“ LLM
Она формирует вокруг себя среду для корректной
и точной работы
1
Context engineering для LLM-агентов

2.

Главный тезис
“ Промпт — это входная команда.
Context engineering — это рабочая среда, в которой агенту сложно
сделать неправильно.
Prompt
что попросили
Context
что агент знает
Verification
как проверили
Новый фокус: не “как точнее попросить”, а “как собрать систему вокруг задачи”.
2
Context engineering для LLM-агентов

3.

Почему prompt-only подход ломается в реальной
разработке
?
Prompt-only
✓
догадки
• Знает только
формулировку задачи
• Rules: что соблюдать
• Skill: какой маршрут пройти
• Догадывается о правилах
• MCP + checks: чем
проверить
• Может изменить код без
проверки
Итог: «кажется, готово»
Context
engineering
факты
Итог: проверенное решение
Промпт задаёт цель. Контекст даёт маршрут, инструменты и проверку.
3
Context engineering для LLM-агентов

4.

Маршрут митапа
4
1
2
3
4
Кто чем является
Rules
Skills
Agents
5
6
MCP
Decision model
Context engineering для LLM-агентов

5.

Rules
Rules: правила игры
Постоянный контекст проекта
Что должно быть всегда под рукой
1
Запуск
install / build
2
Структура
папки, naming, code style
3
Границы
архитектура и do-not правила
4
Готовность обязательные проверки test / lint
Не Rules
Редкие процедуры • длинные чек-листы
требования одной задачи → Skill
Rules автоматически попадают в context: «как мы работаем всегда».
5
Context engineering для LLM-агентов

6.

Rules
Пример RULES
# Правила проекта
- Все backend-изменения требуют тестов.
- Новые UI-компоненты кладём в shared/ui.
- На каждый UI-компонент пишем unit-тест
- Перед финальным ответом запускаем lint и
tests.
- Изменения интерфейса проверяем в браузере
перед завершением задачи.
- В summary пишем, что именно проверили.
## Без approval не делаем
- массовый refactor
- изменение API
- команды, требующие sudo, затрагивающую
систему пользователя
6
Почему это rules
• применяется почти всегда
• коротко и без воды
• влияет на все задачи
• описывает “как у нас принято”
Что сюда не кладём
• длинный release checklist
• browser-debugging workflow
• большие reference docs
Context engineering для LLM-агентов

7.

Rules
Как разработчику создавать rules
1
2
3
Собрать
повторяющиеся
замечания
Сжать rule в
короткий
формат
Добавить
команды
проверки
Компонент
лежит не на
своем месте
test / lint / build
“Забыли
тесты”
“ Хороший rules-файл похож на дорожные знаки.
Плохой — на юридический договор, который никто не читает.
7
Context engineering для LLM-агентов

8.

Skills
Skills: инструкция для агента, а не исполнитель
Skill описывает порядок работы. Agent выполняет эту работу.
Skill
ИНСТРУКЦИЯ
Agent
ИСПОЛНИТЕЛЬ
• Когда применять
• Получает конкретную задачу
• Пошаговый workflow
• Загружает Rules и нужный
Skill
• Tools, проверки, output
• Сам ничего не выполняет
• Работает с кодом и MCP
• Проверяет и возвращает
результат
Skill объясняет как. Agent принимает решения и делает.
8
Context engineering для LLM-агентов

9.

Skills
Что внутри skill
browser-debugging/
SKILL.md
references/
browser-checklist.md
assets/
report-template.md
scripts/
collect-console-log.sh
Metadata
name + description — крючок для выбора. Skill можно
вызвать явно или агент сам выберет его по описанию.
Procedure
пошаговый workflow: research → plan → execute → verify
→ report.
Output contract
что вернуть: summary, files changed, checks run, risks, next
actions.
Rules подключаются как постоянный контекст. Skills подключаются прямым запросом или по совпадению с description.
9
Context engineering для LLM-агентов

10.

Skills
Пример SKILL: browser-debugging
--name: browser-debugging
description: Используй, когда UI-баг нужно воспроизвести и
проверить в браузере.
--# Browser debugging
## Когда применять
- баг виден только в интерфейсе
- есть console/network ошибки
- нужно проверить сценарий пользователя
## Процедура
1. Открой страницу через Playwright MCP.
2. Воспроизведи действие, вызывающее проблему.
3. Проверь console и network.
4. Найди код, который влияет на сценарий.
5. Исправь.
6. Повтори проверку в браузере.
Почему это skill
Это повторяемый workflow. Он говорит, как
вести browser-debugging, но сам ничего не
исполняет.
Кто исполняет
Top-level agent или отдельный browser-tester
subagent.
Через что подключаемся
## Output
- что воспроизведено
- что исправлено
- какие проверки выполнены
10
Playwright MCP даёт browser tools.
Context engineering для LLM-агентов

11.

Skills
Как разработчику создавать skill
Если повторяешь prompt второй раз — возможно, это уже skill
Когда использовать?
Какие шаги?
Какие tools/MCP?
Как проверить?
Какой output?
“ Хороший skill не говорит “будь внимательным”.
Он говорит, какой маршрут пройти и как доказать, что результат готов.
11
Context engineering для LLM-агентов

12.

Skills
Skill vs Rule
Нужно почти всегда?
→
Rules
Нужна иногда, но повторяется?
→
Skill
Это длинная процедура?
→
Skill
Это короткий запрет / convention?
→
Rules
“ Rules — это рельсы.
Skill — это маршрут.
12
Context engineering для LLM-агентов

13.

Agents
Agent: исполнитель, но слово перегружено
Один термин — три уровня
СЕЙЧАС РАБОТАЕТ
Top-level agent
Текущая сессия. Координирует задачу и выбирает
skills, MCP и subagents.
ОПИСАНИЕ
Agent definition
Статический профиль роли: instructions, tools,
permissions и output.
ЗАПУСК
Agent instance
Конкретный запуск роли под конкретную задачу в
отдельном context.
Один термин, но разные сущности: сессия, профиль роли и конкретный запуск.
13
Context engineering для LLM-агентов

14.

Agents
Agent definition vs Agent instance
ПРОФИЛЬ
ЗАПУСК
runtime / spawn
Agent definition
• роль и instructions
Agent instance
1 definition → N instances
• tools / permissions / MCP
• output contract
• конкретная задача
• отдельный context и tool calls
1
2
3
• result summary
Agent definition = class. Agent instance = object.
14
Context engineering для LLM-агентов

15.

Agents
Top-level agent: главный координатор
Skills
Rules
User task
Tools
Top-level
agent
Artifacts
Result + summary
что сделано и как проверено
MCP
Subagents
15
Context engineering для LLM-агентов

16.

Agents
Пример AGENT: security-reviewer
name: security-reviewer
description: Проверяет изменения на риски безопасности.
tools:
- Read
- Grep
- Bash
instructions:
Ты security-reviewer.
Не редактируй файлы.
Проверь auth, permissions, injection,
secrets и утечки памяти.
instructions
Этот текст описывает роль и границы.
Он существует до задачи.
Instance
Появляется, когда runtime запускает
reviewer для конкретного scope.
output:
RESULT: PASS / ISSUES_FOUND / BLOCKED
SCOPE: что проверял
FINDINGS: severity, file, evidence, fix
CONFIDENCE: high / medium / low
Конкретная роль + понятный output
contract.
16
Context engineering для LLM-агентов

17.

Agents
Как разработчику писать agent definition
17
Role
Scope
Boundaries
что за исполнитель?
что он проверяет / делает?
что ему запрещено?
Tools
Permissions
Output contract
что ему нужно для работы?
read-only или write?
как parent поймёт результат?
Context engineering для LLM-агентов

18.

Agents
Checkpoint: кто чем является
18
Rules
что соблюдать всегда
Skill
как выполнять тип задачи
Agent definition
какая роль может быть запущена
Agent instance
кто прямо сейчас выполняет задачу
Top-level agent
кто координирует текущую сессию
Context engineering для LLM-агентов

19.

MCP
MCP: единый способ подключить агента к внешним системам
MCP — это разъём между агентом и
внешней системой.
Подключает
браузер • Redmine • GitHub • DB • API
Даёт агенту
tools • resources • prompts
Не делает
не выбирает стратегию и не заменяет
Skill
Agent решает, что вызвать. MCP только стандартизирует доступ.
19
Context engineering для LLM-агентов

20.

MCP
MCP архитектура: Host → Client → Server
Кто с кем говорит
20
Host / IDE
Cursor, VS Code, Codex,
Claude Code
MCP Client
connection inside host
Host
Client
Server
управляет UX, сессией,
permissions, несколькими clients
одно protocol-подключение к
одному server
выставляет tools / resources /
prompts
MCP Server
capabilities provider
Context engineering для LLM-агентов

21.

MCP
MCP: tools + resources + prompts
MCP-сервер может дать один или несколько типов возможностей.
…
Tools
Resources
Prompts
Выполнить действие
Прочитать данные
Запустить готовый шаблон
open page • create issue • query API
Redmine task • coverage • DB schema
типовой сценарий сообщения
Prompts ≠ Rules / Skill
Tool — сделать. Resource — прочитать. Prompt — запустить шаблон.
21
Context engineering для LLM-агентов

22.

MCP examples
MCP examples: Playwright / Redmine / Coverage
Три системы — три разных типа контекста для top-level agent.
✓
TASK
Playwright MCP
Redmine MCP
• Открыть страницу и повторить
сценарий
• Прочитать задачу, статус и
комментарии
• Проверить console/network
после fix
• Взять acceptance criteria и
связи
Coverage MCP
• Найти missed lines / branches
• Сравнить coverage before /
after
UI-баги и e2e-сценарии
Работа от реального контекста задачи
Тесты по рискам, а не ради процента
npx @playwright/mcp@latest
MCP не думает за агента — он даёт ему факты и действия внешних систем.
22
Context engineering для LLM-агентов

23.

MCP
Skill + MCP + Agent: сильная связка
Skill
как делать
Agent
кто делает
MCP
через что
browser-debugging skill:
1. воспроизвести баг
2. открыть страницу через playwright MCP
3. проверить console/network
4. исправить код
5. повторить проверку
6. вернуть verification report
Rules и Skills наполняют контекст. Top-level agent выбирает маршрут. MCP даёт внешние данные и действия.
23
Context engineering для LLM-агентов

24.

Decision
model
Decision model: 2 шага
Два вопроса, чтобы не складывать всё в один prompt.
1
Определи природу
всегда • повторяется • роль
внешний доступ • результат
2
Выбери слой
Rules • Skill • Agent • MCP
Prompt • Artifact
Rules = всегда • Skill = как • Agent = кто • MCP = через что
24
Context engineering для LLM-агентов

25.

Decision
model
Decision model на примерах
Что хотим добавить
Что используем
Почему
“Не редактируем generated-файлы”
Rules
почти всегда актуальное do-not правило
“Как отлаживать UI-баг пошагово”
Skill
повторяемый workflow
“Нужен отдельный browser-tester”
Agent definition
профиль роли с tools и output contract
“Запусти browser-tester для этого бага”
Subagent instance
конкретный запуск роли под задачу
“Дай агенту браузерные действия”
“Сохрани отчёт проверки”
Playwright
Artifact
внешний tool/capability
результат должен пережить сессию
Главная мысль
Prompt — только для “что сделать сейчас”. Повторяемое, постоянное, внешнее и проверочное — в отдельные слои.
25
Context engineering для LLM-агентов

26.

Создание
Архитектура проекта: где что лежит
Пример раскладки для репозитория, где агенту понятно, где правила, workflows, роли и подключения
.ai/
rules.md
agents.md
Rules
AGENTS.md / CLAUDE.md
Постоянные правила: команды, conventions, donot, definition of done.
Skills
skills/*/SKILL.md
Переиспользуемые playbooks: browser-debugging,
coverage-improvement, migration.
Agents
.codex/agents/*.toml
.claude/agents/*.md
Роли: reviewer, explorer, browser-tester.
MCP
.vscode/mcp.json
.codex/config.toml
Подключения: Playwright, Redmine, Coverage.
Artifacts
reports/ai/, PLAN.md, VERIFICATION.md
То, что остаётся после сессии.
# rules проекта
skills/
browser-debugging/
SKILL.md
# workflow для UI-багов
coverage-improvement/
SKILL.md
# workflow для тестов
agents/
security-reviewer.toml # agent definition
.codex/
config.toml
# sandbox / MCP
.cursor/
config.toml
# sandbox / MCP
reports/ai/
PLAN.md
# artifact
VERIFICATION.md
# artifact
26
Названия директорий условные.
Context engineering для LLM-агентов

27.

Финал
Финальная карта
Как всё собирается в один workflow
Rules
MCP
User
Top-level
agent
Tools /
Resources
Skills
Agents /
Subagents
Results
27
Context engineering для LLM-агентов