Протоколы Bloom: Evaluate ⏱ 9 мин оценка источника

MCP — контракт, не магия

🧊 Won't Have 💧 Could Have ☀️ Should Have 🔥 Must Have
☀️ Should Have
Лечит главную иллюзию модуля: «подключили по MCP — значит, готово». Прочитаешь — перестанешь верить, что разъём чинит то, что за ним.

🤔 Зачем это читать

Полгода назад на совещании решили: подключаем AI-агента ко всем нашим системам по MCP (Model Context Protocol — единый стандарт подключения AI к инструментам и данным, разбирали в прошлой теме). Подрядчик сказал волшебное: «MCP — это USB-C для AI, воткнул и работает». Воткнули. Агент получил доступ к складу, к базе договоров, к CRM (программа, где хранятся клиенты и сделки). А теперь он «тупит»: путает остатки, в ответ клиенту вставляет куски из чужого договора, на простой вопрос «сколько лосося на складе» выдаёт три абзаца воды и одну неверную цифру. И на разборе все смотрят друг на друга: «Мы же всё подключили правильно. Почему он врёт?»

Знакомо? Это самый частый шок второго месяца: разъём подключили — а агент всё равно «давится». И вывод напрашивается ложный: «значит, модель слабая, давайте купим помощнее». Деньги уходят на новую модель, а агент продолжает врать — потому что дело было вообще не в нём.

Вот в чём суть, и это нерв всей темы: MCP стандартизирует разъём, но не делает кривой источник хорошим. Если за красивым единым штуцером — ржавая труба с грязной водой, блюдо ты всё равно испортишь. Разъём чинит проблему «как подключить». Он не чинит проблему «что течёт по трубе».

После этой темы ты сможешь оценить набор источников за разъёмом и сказать, какой из них готов для агента, какой нет и что чинить в первую очередь. Это навык не «подключателя», а владельца, который умеет показать пальцем: «вот эта труба ржавая, агент тут будет давиться, пока её не починим».

Задержись на 10 секунд. Вспомни одну систему на своей работе, которую ты считаешь «беспорядочной»: данные кривые, выгружается только всё разом без фильтра, отчёты приходят картинкой или сканом PDF, на ошибку выдаёт «что-то пошло не так» без объяснений. Держи её в голове до конца страницы. К финалу ты увидишь, готова ли она к тому, чтобы за неё дёргал AI-агент, — и поймёшь, что чинить раньше, чем покупать модель.

🔌 Единый штуцер есть. А что за ним?

В прошлой теме мы разобрали радостную сторону MCP: единый стандарт разъёмов на кухне. Раньше под каждую пару «прибор × система подачи» городили свой переходник — это проблема M×N (когда каждый инструмент надо отдельно прикручивать к каждой модели, «каждый с каждым»). MCP сводит этот зоопарк к одному штуцеру: подключил источник один раз по стандарту — пользуется любой совместимый агент. Удобно, по-настоящему полезно. Но именно тут и подстерегает иллюзия.

Представь: на кухне поставили шикарный единый штуцер для воды — золочёный, евростандарт, любой смеситель прикручивается за секунду. Красота. Только вот за штуцером, в стене, — старая ржавая труба. И из этого красивого крана течёт ржавая, мутная вода. Сменишь смеситель на ещё более дорогой? Вода чище не станет. Поставишь повара получше? Он сварит суп на той же ржавой воде. Проблема не в разъёме и не в поваре. Проблема — в трубе за разъёмом.

Вот это и есть вся тема одной картинкой. MCP — это про штуцер. А агент «давится» из-за трубы.

Разъём стандартный — а труба за ним любая
🧑‍🍳
Агент
Просит данные через стандартный разъём. Получает то, что течёт.
🔌
Штуцер (MCP)
Стандартный разъём. Решает «как подключить». Не трогает то, что за ним.
🪠
Труба (источник)
Твоя система за разъёмом. Чистая или ржавая — решает всё.
Стандартный штуцер не меняет воду в трубе. Хочешь, чтобы агент не давился, — чини трубу, а не покупай ещё один смеситель (модель).

И сразу важная оговорка в духе всего курса: тут нет «главного» или «лучшего» протокола. MCP — это самый распространённый сегодня способ так подключаться, и с конца 2025 года это уже общий стандарт, а не разработка одной фирмы — за ним больше не стоит чей-то отдельный бренд (передан в независимый фонд, на момент весны 2026). Но речь не о том, чей он. Речь о принципе: любой единый разъём — это контракт о форме подключения, а не гарантия качества того, что по нему придёт.

🪠 Из чего состоит «ржавая труба»

Давай без метафоры, конкретно. Что именно делает источник «ржавым» — то есть таким, на котором агент будет спотыкаться, как бы хорошо его ни подключили? Три типичные болезни. Заметь: про две из них — про грязные данные — мы подробно говорили в теме 7.4 — Грязные данные. Здесь та же беда, только вид сбоку: не «модель сочинит на мусоре», а «инструмент за разъёмом отдаёт мусор, и агент в нём тонет».

Видишь общее? Во всех трёх случаях источник перекладывает свою работу на агента — «разбирайся сам». А агент «разбирается» так, как умеет: достраивает правдоподобное. Помнишь сквозное про модель — она не «знает», а угадывает, что обычно идёт дальше. Сунь ей кучу мусора без структуры — получишь уверенно поданную ерунду. Garbage in — plausible garbage out (мусор на входе — правдоподобный мусор на выходе).

🛠 Что значит «хорошая труба»: сильная поддержка на стороне инструмента

Теперь зеркально — каким должен быть источник, чтобы агент за разъёмом не давился. Ключевое слово — детерминированная поддержка (детерминированная — значит работающая по жёстким правилам, всегда одинаково и предсказуемо, без «как сегодня сложится»). Грязную работу должен делать сам инструмент — обычным кодом, до того как данные дойдут до агента. Три рычага, прямо противоположные трём болезням:

Ржавая труба → починенная труба
🎯
Фильтр и сортировка
Было: «выгрузи всё» — 40 000 строк.
Стало: сервер сам отбирает только лосось и сортирует — агент получает короткий точный список.
📄
Формат текст / Markdown
Было: скан-картинка, PDF с печатями.
Стало: чистый текст — агент читает без догадок и не сочиняет.
🚦
Внятные ошибки
Было: пустота или «что-то пошло не так».
Стало: чёткое «нет данных по клиенту № 4471» — агент знает, что данных нет, и не врёт.
Чем больше грязной работы берёт на себя инструмент обычным кодом по жёстким правилам, тем меньше остаётся «угадывать» агенту — и тем реже он врёт.

Покажу разницу псевдокодом — чтобы было видно, что вся «починка трубы» делается обычными человеческими правилами на стороне инструмента, а не магией модели:

Псевдокод (на пальцах) · ржавая труба vs починенная — на запрос «остаток лосося» # это НЕ настоящий код, а логика на человеческом языке

# --- РЖАВАЯ ТРУБА: всю работу свалили на агента ---
запрос: «дай данные склада»
труба отдаёт: ВЕСЬ склад, 40 000 строк, вперемешку, файлом-картинкой
# агент сам ищет лосося в куче → путается, выдаёт неверную цифру

# --- ПОЧИНЕННАЯ ТРУБА: инструмент сделал грязную работу сам ---
запрос: товар = «лосось»
инструмент сам: отобрал только лосося, сложил по складам, вернул текстом
если товара нет в базе → вернуть внятное «нет такой позиции»
ответ агенту: «Лосось: склад А — 12 кг, склад Б — 3 кг»
# агенту нечего выдумывать — данные короткие, точные, на понятном языке

И ещё одна вещь, про которую честно стоит знать, раз уж речь о подключении чужих инструментов по стандарту. У открытости разъёма есть оборотная сторона — безопасность. Две угрозы, о которых сегодня говорят чаще всего (по данным исследователей безопасности, на момент весны 2026):

Глубоко в безопасность нырять сейчас не будем — это отдельная большая тема (контроль качества и риски — модуль 11.x и далее, скоро). Запомни рамку: стандартный разъём упрощает подключение — и ровно поэтому требует разборчивости в том, что и кого ты через него впускаешь.

💡 Главный вывод: оценивай трубу, а не наличие штуцера

Сложи всё вместе. Когда тебе говорят «мы всё подключили по MCP», правильная реакция владельца — не «отлично, готово», а вопрос про трубу за разъёмом:

Запомни одной фразой: агенты не заменяют нормальную интеграцию магически. MCP стандартизирует разъём — это его работа, и она полезная. Но за хорошим разъёмом должна стоять хорошая труба: сильная детерминированная поддержка на стороне инструмента. Нет её — никакая «модель помощнее» не спасёт. Есть — даже скромный агент работает чисто.

И прежде чем смотреть на чужие источники: ту беспорядочную систему, что ты держишь в голове с начала страницы, — к какому вердикту ты бы её сейчас отнёс? Подержи свой ответ. Сначала примерим рамку на четырёх чужих трубах — потом вернёшься к своей.

🎮 Аудит источников за разъёмом

Тебе принесли четыре источника. Все уже подключены по MCP — штуцер на месте, разъём одинаковый. Твоя задача как владельца — оценить трубу за каждым: готов источник к работе с агентом или нет, и если нет — что чинить в первую очередь. Это и есть навык этой темы: смотреть не на «есть ли MCP», а на качество того, что за ним. По каждому источнику — твой вердикт, и сразу разбор. Это не экзамен, а тренировка чутья.

📖 Ключевые понятия

MCP как контракт о форме
Model Context Protocol — единый стандарт подключения AI к инструментам и данным. Он договаривается о форме разъёма (как воткнуться), но ничего не обещает про качество того, что по нему придёт. Самый распространённый сегодня способ подключаться; с конца 2025 — общий стандарт, не разработка одной фирмы (передан в независимый фонд, на момент весны 2026). Контракт, а не магия.
Источник за разъёмом
Та самая «труба»: твоя система (склад, договоры, CRM), к которой агент тянется через MCP. Может быть чистой или ржавой — и именно она, а не разъём, решает, будет агент работать чисто или давиться.
Детерминированная поддержка на стороне инструмента
Грязную работу делает сам источник обычным кодом по жёстким правилам, до того как данные дойдут до агента: фильтрует и сортирует (не «выгрузи всё»), отдаёт текст/Markdown (не PDF/картинку), внятно сообщает об ошибках (не молчит). Чем её больше — тем меньше агенту приходится «угадывать».
Garbage in — plausible garbage out
Мусор на входе — правдоподобный мусор на выходе. Если за разъёмом источник отдаёт кашу, агент не остановится — он достроит уверенную ерунду. Та же беда, что с грязными данными, только источник подаёт мусор через инструмент.
Внедрение инструкций и отравление инструмента (prompt injection / tool poisoning)
Оборотная сторона открытого разъёма. Injection — вредная команда спрятана в самих данных. Tool poisoning — спрятана в описании подключаемого инструмента. Подключаешь чужое по стандарту — впускаешь и его правила; разборчивость обязательна.

🛡️ Частые заблуждения

«Подключили всё по MCP — значит, агент готов к работе»

MCP решает только «как воткнуться». Он не трогает то, что за разъёмом. Если источник вываливает всё разом, отдаёт сканы-картинки и молчит про ошибки — агент будет давиться при любом, самом правильном подключении. «Подключено» и «готово» — разные вещи: первое про штуцер, второе про трубу за ним.

«Агент тупит на наших данных — надо купить модель помощнее»

Самый дорогой ложный вывод. Если агент тонет в выгрузке «всё разом» или читает скан-картинку, проблема в трубе, а не в поваре. Модель помощнее будет так же давиться тем же мусором — ты просто заплатишь больше за тот же неверный ответ. Сначала чини источник: фильтрация, формат, внятные ошибки. Часто после этого хватает и скромной модели.

«MCP — это интеграция под ключ, нормальная подготовка систем больше не нужна»

Наоборот. Стандартный разъём убирает рутину переходников, но работа по подготовке источника — фильтры, форматы, обработка ошибок — никуда не девается, её всё так же делает обычный код. Агенты не заменяют нормальную интеграцию магически. MCP экономит на проводах, а не на трубах.

🧠 AI-чутьё (AI Judgment)

Оценивай не «есть ли MCP», а качество источника за ним

Вот рамка, которую стоит носить с собой: к любому «мы подключили это по MCP» мысленно прикладывай вопрос — а что за разъёмом, и в каком оно состоянии? Наличие стандартного штуцера — это хорошо и удобно, но это ответ на вопрос «как подключить», а не на вопрос «будет ли работать». Работать будет ровно настолько, насколько чиста труба за разъёмом.

Практическая проверка из трёх вопросов, которую можно задать на любом совещании, не будучи технарём: источник сам отбирает и сортирует нужное — или отдаёт «всё разом»? Он отдаёт текст — или скан-картинку и PDF? Он внятно сообщает, когда данных нет или случилась ошибка — или молчит и подсовывает пустоту? Три «плохих» ответа — и никакая модель не спасёт; три «хороших» — и агент работает чисто даже без дорогого повара.

И главный антидот от самой дорогой ошибки: когда агент «тупит и врёт» на твоих системах, первый рефлекс не «купим модель помощнее», а «покажите мне трубу». Это прямое продолжение разговора про грязные данные: garbage in — plausible garbage out работает и через самый красивый разъём. Сила в работе с AI — не подключить побольше, а уметь сказать «вот эта труба ржавая, чиним её раньше, чем платим за модель».

🎯 Практика

Одно задание на пять-семь минут — превращает «оцени трубу» из абзаца в конкретный диагноз твоей системы.

  1. Возьми ту «беспорядочную» систему со своей работы, которую держал в голове с начала страницы (склад, договоры, отчёты, CRM).
  2. Прогони её через три проверки трубы. Отбирает ли она нужное сама или умеет только «выгрузить всё»? В каком формате отдаёт — текст или сканы/PDF/картинки? Что показывает на ошибке — внятное сообщение или пустоту и «что-то пошло не так»?
  3. По каждому пункту — честная галочка или крестик. Где крестики — это и есть что чинить раньше, чем подключать к агенту. Реши, что чинишь первым (обычно «выгрузи всё» бьёт больнее остального). Заметь, как страх «агент будет врать» сменился спокойным «вот список ремонта трубы».

Помнишь иллюзию из начала — «подключили по MCP, а агент врёт, значит модель слабая»? Теперь видно: дело почти всегда в трубе за разъёмом. Стандартный штуцер не меняет воду. Хочешь, чтобы агент не давился, — сначала почини источник, и только потом думай про модель.

🔗 Что дальше

Связанные темы:

Дальше в модуле: