Лекция
Если упростить, практически любой современный ИИ-агент для написания кода (например, встроенный агент в IDE, автономный coding agent или система с субагентами) работает как цикл "планирование → выполнение → проверка → исправление".
Вот примерная архитектура.

Это "дирижер".
Он:
Например:
Сделай интернет-магазин на FastAPI с React.
Главный агент не пишет весь код сам.
Он может решить:
Он разбивает задачу.
Например:
Создать API ↓ Создать модели ↓ Создать миграции ↓ Создать роуты ↓ Добавить JWT ↓ Написать тесты
Это может быть дерево задач.
Backend ├── auth ├── users ├── products ├── orders └── payments
Это отдельные экземпляры LLM со своей ролью.
Например.
Получает только задачу:
Он вообще не знает про React.
Получает:
Получает:
Получает:
Получает:
Представим один агент.
Контекст:
LLM начинает забывать детали.
А если разделить:
Backend Agent
Frontend Agent
Каждый использует меньше контекста.
Практически ни один современный coding agent не ограничивается только генерацией текста.
Если говорить о современных агентных системах, то навыки (Skills), MCP-серверы и Tools (инструменты) — это три разных уровня абстракции, хотя на практике они работают вместе.
Можно представить это так:
Запрос пользователя
│
▼
Главный агент
│
├─────────────┬──────────────┐
▼ ▼ ▼
Skills MCP Servers Tools
│ │ │
└─────────────┴──────────────┘
│
▼
Выполнение
Инструмент делает одно конкретное действие.
Обычно он умеет:
То есть:
read_file(path)
write_file(path)
run_terminal(cmd)
search_web(query)
У инструмента обычно нет логики.
Он просто выполняет команду.
То есть цикл выглядит так:
LLM ↓ создать файл ↓ запустить тест ↓ увидеть ошибку ↓ исправить файл ↓ повторить
Навык — это уже мини-процесс, состоящий из нескольких шагов.
Например:
Навык "Создать REST API"
↓
прочитать структуру проекта
↓
создать модели
↓
создать контроллеры
↓
создать тесты
↓
обновить README
Он может использовать десятки инструментов внутри.
То есть
Skill
↓
Tool
↓
Tool
↓
Tool
↓
Tool
Навык отвечает на вопрос:
Как выполнить типичную задачу?
Например:
Skill: Добавить новую страницу
↓
создать файл
↓
добавить маршрут
↓
обновить меню
↓
написать тест
MCP (Model Context Protocol) — это протокол, а не инструмент и не навык.
Он отвечает за связь между агентом и внешней системой.
Например:
IDE
↓
MCP
↓
GitHub
или
LLM
↓
MCP
↓
PostgreSQL
или
LLM
↓
MCP
↓
Docker
или
LLM
↓
MCP
↓
Figma
Сам MCP ничего не делает.
Он говорит:
"Вот список функций, которые предоставляет эта система."
Например:
GitHub MCP
↓
list_repositories()
↓
create_issue()
↓
merge_pull_request()
↓
create_branch()
Для агента это выглядит как набор новых инструментов.
Другой пример:
Postgres MCP
↓
execute_sql()
↓
list_tables()
↓
describe_table()
Допустим есть навык
Исправить баг
Он может делать следующее:
1 Прочитать issue
2 Найти код
3 Исправить
4 Запустить тесты
5 Создать PR
Внутри используются:
GitHub MCP
↓
get_issue()
Filesystem Tool
↓
read_file()
Terminal Tool
↓
pytest
GitHub MCP
↓
create_pull_request()
То есть один навык может использовать одновременно:
Agent
↓
Skill
↓
Tool
↓
MCP Server
↓
Реальная система
Например:
Навык Создать Pull Request
↓
git diff
↓
git commit
↓
GitHub MCP
↓
create_pull_request()
Иногда MCP сам предоставляет готовый навык.
Например сервер CI может иметь:
deploy_application()
rollback()
create_release()
Для агента это уже почти навыки, хотя технически они приходят как инструменты через MCP.
Одновременно ли используются?
Да.
Например агент получает задачу:
"Исправь ошибку и создай Pull Request."
Он может сделать примерно следующее:
Skill "Исправить баг"
↓
Filesystem Tool
↓
Terminal Tool
↓
Git Tool
↓
GitHub MCP
↓
Browser MCP
↓
Skill "Code Review"
↓
GitHub MCP
Все это работает в одном цикле.
Краткое сравнение
| Компонент | Что это | Основная роль |
|---|---|---|
| Tool | Отдельное действие | «Прочитай файл», «запусти команду», «выполни SQL» |
| Skill | Сценарий из нескольких шагов | «Добавить API», «Исправить баг», «Подготовить релиз» |
| MCP | Протокол подключения | Дает агенту доступ к возможностям внешних систем (GitHub, IDE, базы данных, Docker и др.) |
Главное отличие в том, что MCP не конкурирует с Tools. Наоборот, MCP чаще всего является способом предоставить агенту новые инструменты. А Skills находятся уровнем выше: они координируют использование этих инструментов (локальных и полученных через MCP) для решения законченной задачи.
Это самое важное.
Почти все агенты работают примерно так.
Пока задача не выполнена:
Например:
Шаг 1 Создать app.py ↓ Шаг 2 Запустить pytest ↓ Ошибка ↓ Исправить ↓ Запустить снова ↓ Ошибка ↓ Исправить ↓ Все тесты зеленые
Есть несколько уровней памяти.
Контекст текущего диалога.
Например:
Мы используем FastAPI.
План задач.
✔ Backend ✔ Database Tests Docs
Может хранить:
стиль кода предпочтения архитектуру предыдущие решения
Очень часто используется отдельный агент.
Он ничего не пишет.
Он только ищет ошибки.
Например:
Backend Agent написал код. ↓ Reviewer Agent ↓ Нашел баг ↓ Вернул замечания ↓ Backend Agent исправил
Это похоже на процесс Code Review.
Отдельный агент может заниматься исключительно ошибками.
Например.
pytest ↓ FAIL ↓ Debug Agent ↓ читает stacktrace ↓ исправляет ↓ повторяет
В итоге все можно представить так:
Пользователь ↓ Главный агент ↓ План ↓ Субагенты ↓ Код ↓ Компиляция ↓ Тесты ↓ Ошибки ↓ Исправление ↓ Тесты ↓ Ошибки ↓ Исправление ↓ Готово
Обычно субагенты не общаются друг с другом напрямую. Вместо этого они обмениваются информацией через главного агента.
Пример:
Frontend Agent
│
▼
Главный агент
▲
│
Backend Agent
Или через общие артефакты проекта:
Главный агент может передать одному субагенту результаты другого, например: "Backend завершил API, теперь используй эту OpenAPI-спецификацию для генерации клиента".
На практике современные системы (например, агенты в IDE или автономные coding agents) часто добавляют еще несколько компонентов:
while not task.completed():
plan = planner.next_step()
agent = orchestrator.select_agent(plan)
result = agent.execute(plan)
repository.apply(result)
report = tester.run()
if report.failed:
debugger.fix(report)
else:
planner.mark_done()
Именно этот цикл — планирование → выполнение → проверка → исправление — лежит в основе большинства современных ИИ-агентов для программирования. Различия между системами в основном заключаются в качестве планирования, эффективности выбора контекста, наборе доступных инструментов, организации субагентов и глубине автоматизации.
Комментарии