Важное о ЭМ СИ ПИ – да, опять
_
Антропики опубликовали действительно важную статью о проблемах MCP серверов. О некоторых косяках я уже писал 👉тут, сейчас на работе мы разрабатываем проект, где эти проблемы раскрылись во всей красе и разрушили изначальные планы по срокам.
Что не так с текущим подходом
У нас есть supervisor агент, делегирующий работу на reAct субагентов, которые напрямую взаимодействуют с MCP тулами. Всё ломается, когда агент должен оркестрировать что-то сложнее чем "добавь нового пользователя". Например: "измени команду пользователя X на команду с названием Z".
Допустим, что наш MCP сервер это просто обёртка над RESTом с классическими CRUDами:
get_user(), update_user(), create_user(), delete_user(), get_team(), update_team()...
см. прикреплённую картинку для наглядности.
Проблема 1️⃣
Декларация ВСЕХ тулов включается в контекст при каждом вызове модели, даже если тебе нужно использовать 10% из них. В контекст летит куча мусора, который никак не помогает модели выполнить задачу. Единственные кто в выигрыше – провайдеры моделей, которые получают больше денег за токены из-за MCP серверов, которые ты накатил в своё IDE и забываешь их выключать когда они тебе не особо нужны 😏
Проблема 2️⃣
Промежуточные результаты жрут контекст. Чтобы изменить команду юзера X, нужно 3 вызова MCP тулов — каждый постепенно наполняет окно своим выводом и ошибками. О context management писал 👉тут.
Почему лучше дать модели писать код
На рабочих созвонах с другими AI-чадами мы пришли к выводу: надо дать модели возможность просто писать и исполнять код. Код модели пишут куда лучше, чем вызывают тулы, и это логично. До 2023 года парадигмы tool calling вообще не существовало – провайдеры тренируют модели вызывать тулы на синтетических данных, которых никогда не было на GitHub. Заставлять LLM работать через tool calling это как отправить Прелепина на месячные курсы китайского, а потом попросить написать роман на этом языке. Мб получится... но партия не будет довольна (ни та, ни та)! 😏
Решение от Anthropic
Вместо прямого вызова тулов представить MCP серверы как код-библиотеки. Агент взаимодействует с ними через написание и исполнение кода.
MCP серверы представляются как файловая структура с TypeScript функциями:
servers/
├── user_management/
│ ├── getUser.ts
│ ├── updateUser.ts
│ ├── createUser.ts
│ └── index.ts
├── team_management/
│ ├── getTeam.ts
│ ├── updateTeam.ts
│ ├── createTeam.ts
│ └── index.ts
Агент загружает в контекст только те тулы, которые нужны для задачи, исследуя файловую систему.
Что это даёт на практике?
• Progressive disclosure: Модель навигирует по файлам и читает определения по требованию, а не все сразу. В примере Anthropic это сокращает использование токенов со 150,000 до 2,000 – экономия 98.7%.
• Фильтрация данных: Агент обрабатывает большие датасеты в среде исполнения. Вместо загрузки 10,000 строк из таблицы, можно отфильтровать нужные в коде и вернуть только 5.
• Эффективный control flow: Циклы, условия и обработка ошибок через привычные паттерны кода вместо цепочки отдельных tool calls.
• Privacy: Промежуточные результаты остаются в среде исполнения и не попадают в контекст модели. Можно даже автоматически токенизировать PII — модель видит [EMAIL_1], а реальные данные текут напрямую между системами.
• State persistence: Агент может сохранять промежуточные результаты в файлы и создавать переиспользуемые функции. Это завязывается с концепцией Skills с которой я ещё не до конца разобрался и мнения на этот счёт не имею, но идея в том, что со временем агент САМ наращивает свой тулбокс высокоуровневых возможностей.
AI инжиниринг сейчас — это как web development до 2010. Всё пишется в сыром HTML/CSS + JS, ещё непонятно, что мы будем использовать через 3-5 лет. Однозначных best practices просто нет, все учатся на ходу.
Экспертов с 15+ годами опыта в этой сфере не существует, а интервью на AI Engineer часто проводят люди, которые сами перекатились в ИИ-тусовку буквально вчера. И, лично для меня, в этом и кайф этой ниши 🚀
[источник]
#dev_help #ai
@makebugger
_
Антропики опубликовали действительно важную статью о проблемах MCP серверов. О некоторых косяках я уже писал 👉тут, сейчас на работе мы разрабатываем проект, где эти проблемы раскрылись во всей красе и разрушили изначальные планы по срокам.
Что не так с текущим подходом
У нас есть supervisor агент, делегирующий работу на reAct субагентов, которые напрямую взаимодействуют с MCP тулами. Всё ломается, когда агент должен оркестрировать что-то сложнее чем "добавь нового пользователя". Например: "измени команду пользователя X на команду с названием Z".
Допустим, что наш MCP сервер это просто обёртка над RESTом с классическими CRUDами:
get_user(), update_user(), create_user(), delete_user(), get_team(), update_team()...
см. прикреплённую картинку для наглядности.
Проблема 1️⃣
Декларация ВСЕХ тулов включается в контекст при каждом вызове модели, даже если тебе нужно использовать 10% из них. В контекст летит куча мусора, который никак не помогает модели выполнить задачу. Единственные кто в выигрыше – провайдеры моделей, которые получают больше денег за токены из-за MCP серверов, которые ты накатил в своё IDE и забываешь их выключать когда они тебе не особо нужны 😏
Проблема 2️⃣
Промежуточные результаты жрут контекст. Чтобы изменить команду юзера X, нужно 3 вызова MCP тулов — каждый постепенно наполняет окно своим выводом и ошибками. О context management писал 👉тут.
Почему лучше дать модели писать код
На рабочих созвонах с другими AI-чадами мы пришли к выводу: надо дать модели возможность просто писать и исполнять код. Код модели пишут куда лучше, чем вызывают тулы, и это логично. До 2023 года парадигмы tool calling вообще не существовало – провайдеры тренируют модели вызывать тулы на синтетических данных, которых никогда не было на GitHub. Заставлять LLM работать через tool calling это как отправить Прелепина на месячные курсы китайского, а потом попросить написать роман на этом языке. Мб получится... но партия не будет довольна (ни та, ни та)! 😏
Решение от Anthropic
Вместо прямого вызова тулов представить MCP серверы как код-библиотеки. Агент взаимодействует с ними через написание и исполнение кода.
MCP серверы представляются как файловая структура с TypeScript функциями:
servers/
├── user_management/
│ ├── getUser.ts
│ ├── updateUser.ts
│ ├── createUser.ts
│ └── index.ts
├── team_management/
│ ├── getTeam.ts
│ ├── updateTeam.ts
│ ├── createTeam.ts
│ └── index.ts
Агент загружает в контекст только те тулы, которые нужны для задачи, исследуя файловую систему.
Что это даёт на практике?
• Progressive disclosure: Модель навигирует по файлам и читает определения по требованию, а не все сразу. В примере Anthropic это сокращает использование токенов со 150,000 до 2,000 – экономия 98.7%.
• Фильтрация данных: Агент обрабатывает большие датасеты в среде исполнения. Вместо загрузки 10,000 строк из таблицы, можно отфильтровать нужные в коде и вернуть только 5.
• Эффективный control flow: Циклы, условия и обработка ошибок через привычные паттерны кода вместо цепочки отдельных tool calls.
• Privacy: Промежуточные результаты остаются в среде исполнения и не попадают в контекст модели. Можно даже автоматически токенизировать PII — модель видит [EMAIL_1], а реальные данные текут напрямую между системами.
• State persistence: Агент может сохранять промежуточные результаты в файлы и создавать переиспользуемые функции. Это завязывается с концепцией Skills с которой я ещё не до конца разобрался и мнения на этот счёт не имею, но идея в том, что со временем агент САМ наращивает свой тулбокс высокоуровневых возможностей.
AI инжиниринг сейчас — это как web development до 2010. Всё пишется в сыром HTML/CSS + JS, ещё непонятно, что мы будем использовать через 3-5 лет. Однозначных best practices просто нет, все учатся на ходу.
Экспертов с 15+ годами опыта в этой сфере не существует, а интервью на AI Engineer часто проводят люди, которые сами перекатились в ИИ-тусовку буквально вчера. И, лично для меня, в этом и кайф этой ниши 🚀
[источник]
#dev_help #ai
@makebugger