
В конце 2024 года Anthropic представила Model Context Protocol (MCP) - протокол, позволяющий языковым моделям подключаться к внешним инструментам по единым правилам, без индивидуальных интеграций. Идея была в том, чтобы отделить модель от конкретных API и предоставить ей универсальный интерфейс для взаимодействия с файлами, базами данных и облачными сервисами.
С ростом числа MCP-инструментов в реальных агентах стало заметно ограничение: модель начала получать слишком много промежуточных данных. Это увеличивает количество токенов и время отклика, а в сложных цепочках действий приводит к ошибкам.
Anthropic предложила решение: вынести выполнение операций в отдельную среду исполнения кода, сохранив за моделью только роль планировщика.
В чём была проблема
Типичный сценарий до обновления выглядел так:
Агент вызывает инструмент для получения данных.
Инструмент возвращает данные в модель.
Модель формирует следующую команду, снова включая данные в контекст.
Если документ большой (например, 200 KB текста), он полностью проходит через модель, хотя модели часто нужно лишь понимать последовательность действий, а не сам текст.
Это приводит к:
Последствие |
Причина |
|---|---|
Рост токенов |
Данные хранятся в контексте |
Медленнее ответы |
Увеличение контекстного окна |
Хрупкость цепочек |
Ошибка в данных → ошибка в планировании |
Модель здесь выступает как транспорт, что ей не нужно.
Новое решение: модель планирует, код выполняет
Anthropic добавила в MCP возможность выполнения кода в отдельной песочнице (sandbox).
Теперь модель не переносит данные между инструментами, а генерирует код, который сам работает с MCP-серверами. То есть модель занимается логикой, а обработка данных вынесена из контекста.
Пример
Допустим, агент должен:
прочитать стенограмму встречи,
выделить решения,
добавить их в Notion.
Схема с исполнением кода
import * as files from "./servers/files";
import * as notion from "./servers/notion";
const raw = await files.readFile({ path: "./meeting.txt" });
const text = raw.content;
const keyPoints = text
.split("\n")
.filter(line => line.startsWith("- ") || line.startsWith("* "))
.map(line => line.replace(/^[-*]\s*/, ""))
.join("\n");
await notion.createPage({
databaseId: "db123",
title: "Решения по встрече",
content: keyPoints
});
return `Добавлено пунктов: ${keyPoints.split("\n").length}`;
Модели возвращается только строка:
"Добавлено пунктов: 17"
А не весь документ.
Зачем это всё
Подход |
Что делает модель |
Поток данных |
Стоимость |
|---|---|---|---|
До обновления |
Анализ + передача |
Большие данные проходят через LLM |
Высокая |
После обновления |
Только планирование |
Передаётся только итог |
Ниже |
На длинных цепочках взаимодействий разница в стоимости может быть на порядок.
Безопасность
Anthropic обращает внимание, что выполнение кода должно быть:
изолировано (Docker / gVisor / Firecracker)
ограничено по ресурсам
с контролем доступа к сети и файловой системе
То есть это не «модель получила доступ к компьютеру», а ограниченная вычислительная среда с предсказуемыми API.
Где такой подход уместен
Хорошо работает в:
корпоративных ассистентах
автоматизации документооборота
извлечении и структурировании информации
интеграциях CRM / Wiki / облаков
Мало полезен в задачах «просто поговорить» - там нет данных, которые нужно переносить или трансформировать.
Выводы
Anthropic постепенно смещает роль модели в сторону планировщика задач, а не универсального вычислителя.
MCP с исполнением кода делает агентов практичным инструментом, который может не только «объяснять, что делать», но и выполнять конечные действия за пределами модели.
Это делает ИИ-агентов:
быстрее,
надёжнее,
дешевле при работе с большими данными.
Подробнее в блоге Anthropic
Комментарии (3)

artem_prozorov
06.11.2025 07:07Вопрос к автору: можно ли привести другой пример реализации? Указанный пример с формированием пунктов из стенограммы выглядит слишком упрощенным. Ну то есть, если можно с помощью регулярного выражения выдернуть пункты из текста и создать их, то зачем здесь вообще LLM?
jakobz
Если не надо было бы инфоповод и хайпануть, могли бы вместо этого хитрого протокола, просто REST API с OpenAPI-спекой подключать.
С этой новой прекрасной идеей, ждём новую версию протокола, где для Tool можно схему ответа указать. А то там сейчас тупо текст, и как модель сможет написать код, который как-то результат обработает - не ясно.