Достаточно ли MCP, чтобы дать ИИ-агентам общий контекст?

MCP хватает, чтобы дотянуться до каждого источника в вашей компании, и не хватает, чтобы заставить хотя бы два из них договориться. Откройте нормативную схему Model Context Protocol в ревизии 2025-11-25 и прочитайте тип Resource. Девять полей. Два обязательных: uri и name. Семь опциональных: title, description, icons, mimeType, annotations, size и _meta. Ни одно из них не фиксирует, где этот ресурс стоит в иерархии вашей компании, какой он версии и какой из двух противоречащих ресурсов побеждает. В конце 2025 года я находился внутри маркетплейса совместных поездок: меня наняли, чтобы я варился в повседневной работе его инженерной организации и нашёл то, что сломается на due diligence инвестора. И то, что я нашёл, было не в коде. Агент отфильтровал по слову, которое понимал каждый человек в компании, база данных не нашла совпадений, ошибки не возникло, а пользователи перестали видеть поездки, которые сами же и забронировали.

Моя позиция там задаёт границы того, что я могу рассказать. Я не участвовал во внедрении ИИ и не писал и не проверял код из этой истории. Всё задание в том и состояло, чтобы замечать происходящее, и вот что оно принесло. Компания остаётся анонимной. На одной детали продукта держится всё остальное: поездка была одной из центральных сущностей, а продуктовая команда, маркетинг, технические диаграммы и код называли её каждый по-своему.

Тип Resource в MCP объявляет девять полей, и ни одно из них не говорит, какой источник прав

Вот всё, что Model Context Protocol сообщает агенту о ресурсе. Спецификация прямо говорит, что источником истины служит её TypeScript-схема, а не текстовые страницы: «the source of truth for all protocol messages and structures». И в этой схеме, ревизия 2025-11-25, Resource объявляет девять полей, если распутать наследование: шесть на самом типе плюс name и title из BaseMetadata и icons из Icons. Два обязательных: uri и name. Семь опциональных: title, description, icons, mimeType, annotations, size и _meta. А теперь найдите в этом списке поле, которое скажет агенту, по какому из слов trip, offer или carona база данных на самом деле найдёт совпадение. Такого поля нет, и это отсутствие не оплошность. Собственный обзор архитектуры спецификации гласит, что MCP «focuses solely on the protocol for context exchange» и что он «does not dictate how AI applications use LLMs or manage the provided context».

Ближе всего к ранжированию источника протокол подходит через priority, число от 0.0 до 1.0, которое сервер сам объявляет для собственного ресурса, причём спецификация говорит, что значение 1 означает «most important». Ближе всего к свежести он подходит через lastModified, отметку времени в формате ISO 8601, фиксирующую, когда ресурс менялся в последний раз, а это факт о байтах, а не об истине. Оба живут в опциональных annotations ресурса, которые сервер пишет о себе сам и которые никто не проверяет. Позиция спецификации по поводу самоописания виднее всего на соседнем типе. В разделе о типе Tool спецификация несёт предупреждение в нормативных формулировках: клиенты «MUST consider tool annotations to be untrusted unless they come from trusted servers». Это предупреждение относится к инструментам, так что напрямую про priority оно не говорит. Показывает оно другое: позицию протокола его же нормативным голосом. Когда сервер описывает сам себя, инстинкт спецификации велит предупредить клиента, чтобы тот не верил.

Ничто из этого не является изъяном MCP. Это протокол, который делает свою работу и отказывается от той, что никогда ему не принадлежала. Беда начинается тогда, когда компания принимает достижимость за готовность, подключает к агенту девять источников и предполагает, что где-то по дороге что-то решает, какой из них прав. Обычно эту роль приписывают поиску, который ранжирует фрагменты по сходству и оставляет авторитетность там, где её нашёл: MCP и RAG работают на разных уровнях, и ни один из них не является тем уровнем, который решает (на английском).

Почему ИИ-агент возвращает пустой результат без ошибки: слово было допустимым, а сущность нет

У придуманного Tony Hoare null было одно искупающее свойство. Он падал. Представляя свой доклад на QCon London 2009, Hoare назвал нулевую ссылку 1965 года своей «billion-dollar mistake»: он ставил себе целью сделать любое использование ссылки «absolutely safe, with checking performed automatically by the compiler», всё равно не удержался и добавил null, и тот стал причиной «innumerable errors, vulnerabilities, and system crashes». Падение оказывается подарком. Оно останавливает программу, называет строку и указывает на себя. То, что маркетплейс выпустил в декабре 2025 года, сделало обратное. Назовём это семантическим нулём: результат, структурно допустимый и семантически пустой, где запрос выполнился, типы сошлись, вернулось ноль строк, и ничто в системе не знало, что слово было неверным.

Словарь вырос по функциям, как он растёт везде:

Люди переходили между этими словами без усилий. В разговоре равнозначность была очевидной. Потом один метод отфильтровал по строке offer там, где исполняемый контракт определял trips. Фильтр принял строку, отработал штатно, не нашёл ни одной записи и не вернул ничего. Ничего не упало. Ошибки не возникло.

Большая часть продукта продолжала работать, и это позволило компании пережить случившееся и одновременно скрыло его. Пользователи по-прежнему могли бронировать поездки, а более общие экраны по-прежнему запрашивали trips. Дефект сидел ровно в одном фильтре, том, что отбирал запланированные поездки пользователя для персонализированного экрана и построенных на нём уведомлений. Почти целиком корректный релиз спрятал как раз те записи, которые больше всего значили для того, кто их искал. Очередь поддержки была тем местом, где это вылезло: за одну ночь главной жалобой в компании, где главной жалобой обычно была отмена поездки, стало то, что люди не находят свои поездки.

Вот почему семантический инцидент переживает обычные проверки. Тест, смотрящий только на ответ, проходит. Проверка типов принимает строку. Мониторинг, следящий только за ошибками, классифицирует запрос как успешный, потому что таким он и был. Если ни один тест не утверждает, что пользователь с запланированными trips не может получить пустую коллекцию, когда другой артефакт говорит offer, во всём конвейере эту поломку попросту никто не ищет.

Более новая ревизия MCP не станет решать смысл, потому что смыслом владеют конечные точки

Очевидное возражение против подсчёта полей состоит в том, что число полей меняется. Кто-нибудь добавит поле авторитетности в одной из будущих ревизий, и что тогда? Тогда ничего, и причине сорок лет. В 1984 году в ACM Transactions on Computer Systems Saltzer, Reed и Clark дали этому принципу имя: «The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system.»

Они говорили о надёжности. О проверке ошибок, шифровании, повторяющихся сообщениях. Про смысл они не написали ни слова, и это я расширяю их аргумент, а не цитирую их. Но посмотрите, на чём держится их собственный пример с дубликатами. Сеть не может подавить повторные сообщения приложения, пишут они, потому что эти дубликаты «look like different messages to the communication system», так что подавление «must be accomplished by the application itself with knowledge of how to detect its own duplicates». Что считать одним и тем же сообщением, решает приложение, и протоколу это решение не видно. Вопрос определения уже несёт нагрузку внутри их аргумента о надёжности. Такова здесь общая закономерность, и для словаря она работает тоже. Одна ли сущность offer и trips, знает только ваша компания: это знание живёт в головах людей, позволивших словам разойтись. В самом канале его никогда не было, и никакая ревизия его туда не положит.

Доступ не означает договорённости. Протокол делает достижимым каждый авторизованный источник, не заставляя хотя бы два из них означать одно и то же, и это формулировка на уровне протокола того же закона, из-за которого ИИ-стек рождается с расщеплённым мозгом.

Авторитетность принадлежит факту, а не инструменту, и происхождение никогда не скажет, какой факт побеждает

Происхождение фиксирует, откуда факт взялся и как он менялся; оно никогда не фиксирует, что факт побеждает. Записка W3C PROV о доступе и запросах (2013) проводит эту границу собственным голосом: «A provenance record is not of itself guaranteed to be authoritative or correct. Trust in provenance records must be determined separately from trust in the original resource.» Это разделение и есть вся проблема в двух предложениях, потому что агенту, дотянувшемуся до четырёх источников, нужно суждение, а не запись.

У маркетплейса такого суждения не было записано нигде. Ничто не говорило, что код владеет рабочим идентификатором, что продукт владеет задуманным поведением, что маркетинг владеет словом, которое видит клиент, и что маркетинговую лексику нельзя копировать в фильтр данных. Поэтому ничто не возразило, когда внутреннее продуктовое слово именно им и стало. Такую авторитетность нельзя выдать инструменту раз и навсегда, потому что она не лежит на уровне гранулярности инструмента. Для одной поездки в один момент развёрнутая схема управляет trips, утверждённое продуктовое решение управляет тем, что должна делать эта функциональность, а маркетинг управляет словом carona. Три источника, все авторитетны, и ни один из них не является системой-источником, тем самым system of record.

Управление данными знает это уже не одно десятилетие, и это стоит сказать прямо, а не делать вид, что мы это открыли. Master data management назначает авторитетность по полю, а не по системе, и его трудная часть всегда состояла в том, чтобы решить, какому полю из какого источника доверять; именно это и делают правила выживания, survivorship rules. С чем дисциплине никогда не приходилось справляться, так это со связным текстом. Правила выживания разрешают спор между типизированными значениями внутри схемы, и не существует оценки доверия, которую вы вычислили бы между фразой в продуктовом документе и определением колонки. Гранулярность была верной с самого начала. Просто никто не построил это для слов.

Ошибку написал агент, проверил агент, и она прошла мимо человека, который не поспевал

Фильтр не был человеческой ошибкой в том смысле, в каком это выражение обычно звучит. Фичу, которая его содержала, написал кодинг-агент. Ревью кода сделал другой ИИ. Человеческое ревью провалилось так, как оно проваливается сейчас: утонув в объёме кода, который ни один человек в таком темпе читать не станет. Два агента: у обоих был доступ к продуктовым документам, макетам и кодовой базе, и ни у одного не было записи о том, что компания договорилась считать значением этих слов. Локально не ошибся ни один. Пишущий агент использовал слово, истинное на языке продукта. Проверяющий агент видел код, который делал то, что говорил. Сбой жил между ними, на участке, который не отдали ни одному из них.

Этот разрыв измерен. Телеметрия Faros AI за 2026 год по 22 000 разработчиков показывает, что багов на разработчика на 54% больше и на 31% больше пул-реквестов уходит в мерж вообще без ревью. Человек как арбитр уходит с дороги ровно в тот момент, когда протокол отказывается арбитрировать.

Чище всего это сформулировано в одном препринте 2026 года, и там есть оговорка, которую я лучше назову вслух, чем закопаю: Dillon и Varanasi проверили кодинг-агента на 41 командном решении в одном репозитории, и они сами разрабатывают тот инструмент контекста, который тестировали. Отложите их заголовочную цифру и прочитайте одну строку их таблицы. В репозитории лежали две функции аудита, и правило SOC-2 делало обязательной при экспорте ровно одну из них. Функция была прямо там, в коде. Правило не было записано нигде, куда агент мог дотянуться. Когда ему велели проследить, чтобы действие залогировалось, он пошёл искать, нашёл функцию аудита и взял не ту, а это различие, по словам авторов, требует понимания, зачем нужная функция вообще существует. Обе функции он прочитать мог. Чего он прочитать не мог, так это того, какую из них выбрала команда, и сколько код ни читай, этого бы оттуда не вычитать, потому что ответа в коде никогда не было. Собственный вывод авторов и есть честная форма этого: поиск делает соблюдение требований возможным, а надёжным его делает структурированный рабочий процесс.

Свяжите каждый принятый псевдоним с одной управляемой сущностью, прежде чем агент сможет по нему фильтровать

Eric Evans описал этот паттерн, и большинство команд помнит только половину. Знаменитую половину знают все: единый язык. В справочнике по Domain-Driven Design (2015) он призывает команду настойчиво использовать этот язык во всём общении и в коде, а внутри ограниченного контекста применять один и тот же язык в диаграммах, текстах и особенно в устной речи. Половина, которую команды забывают, касается того, о чём он просит на самих границах. Там, где встречаются действительно разные модели, его Context Map делает перевод в точках их соприкосновения явным, «outlining explicit translation for any communication». У маркетплейса в этом процессе не было ни одной из этих защит, так что offer вошёл в исполняемый контракт trips, и на границе не стоял никто.

Маркетинг не обязан писать trips. Именно это теряется, когда кто-то слышит всё это и хватается за проект глоссария. Продукт должен и дальше описывать offer, маркетинг должен и дальше говорить на языке клиента, а разработка должна и дальше держать стабильный контракт. Существовать должна машиночитаемая запись, которая говорит, что это одна и та же сущность, что отвечать база данных будет именно на trips, и что остальные слова не должны никогда оказываться рядом с запросом. Такая запись должна жить в управляемом слое контекста (материал на английском) между рабочими системами и агентами, и именно им LoomSignal и является: развёрнутым у вас, для команд, чьи внутренние данные не уезжают к облачному провайдеру.

Тогда тест, который поймал бы это, становится тривиальным: пользователь с запланированными trips никогда не должен получать пустую коллекцию, каким бы словом ни воспользовался вызывающий артефакт.

Маркетплейс нашёл фильтр и выкатил исправление за три часа. Именно к этому я всё возвращаюсь. Стоило кому-то понять, куда смотреть, и крупной платформе с множеством функций хватило полудня, чтобы воспроизвести и починить дефект в одно слово. Эти три часа никогда не были ценой. Ценой было всё, что им предшествовало, когда код работал ровно так, как написан, мониторинг был зелёным, ревью было пройдено, и единственной системой в компании, знавшей, что что-то не так, была очередь людей, писавших, что они не находят свои поездки.

Откройте тип Resource в своём стеке. Девять полей. Нужного среди них нет.