Почему промпт не заменяет GraphQL, а MCP — не шина данных
Начинать разговор об агентных архитектурах стоит с отрезвляющего тезиса: промпт не является заменой ни агрегирующим запросам, ни GraphQL, ни контекстному поиску. Это распространённое упрощение, которое на практике ведёт к архитектурной деградации.
Промпт — слой интерпретации. Он получает уже собранные и переданные в контекст данные и объясняет модели, что с ними делать. Сам он не умеет обращаться к базе, строить join'ы и резолвить эндпоинты. Путать его со средствами доступа к данным — значит добровольно отказываться от контрактов, строгой схемы и предсказуемости.
Однако возникает закономерный вопрос: если промпт только интерпретирует, то каким образом агент динамически выбирает инструменты и источники? Здесь появляется Model Context Protocol (MCP) — и вместе с ним новая волна заблуждений. MCP-сервер описывают как замену шины данных и GraphQL, что технически некорректно.
MCP — это универсальный адаптер. Он предоставляет агенту стандартизированный интерфейс к трём сущностям: Tools (действия), Resources (данные), Prompts (шаблоны). Но под капотом MCP-сервер вызывает те же REST, GraphQL или SQL, а не подменяет их. Он не занимается трансформацией сообщений, не гарантирует доставку, не обеспечивает транзакционную целостность и, главное, не принимает решений о маршрутизации. Решение о том, какой инструмент вызвать, принимает LLM — недетерминированно, на основе описания.
Именно здесь возникает то самое «поле чудес и русская рулетка», о которых говорилось ранее: агент угадывает инструмент, а результат этого угадывания может быть как точным, так и разрушительным. MCP здесь выполняет роль стандартизированного слоя доступа, но не роль шины данных. Считать «агент + MCP» эволюцией ESB — ошибка. ESB обеспечивает детерминированную маршрутизацию по правилам; MCP обеспечивает стохастический выбор, ограниченный лишь качеством промпта и описаний инструментов.
Практический вывод: антипаттерн «заменили GraphQL промптом» не просто неточен, он опасен. Правильная архитектура подразумевает чёткое разделение: GraphQL и REST — для детерминированной работы с данными, промпты и MCP-адаптеры — для недетерминированного принятия решений. Агент без проверенной API-подложки беспомощен, а его «гибкость» превращается в генератор ошибок.
Начинать разговор об агентных архитектурах стоит с отрезвляющего тезиса: промпт не является заменой ни агрегирующим запросам, ни GraphQL, ни контекстному поиску. Это распространённое упрощение, которое на практике ведёт к архитектурной деградации.
Промпт — слой интерпретации. Он получает уже собранные и переданные в контекст данные и объясняет модели, что с ними делать. Сам он не умеет обращаться к базе, строить join'ы и резолвить эндпоинты. Путать его со средствами доступа к данным — значит добровольно отказываться от контрактов, строгой схемы и предсказуемости.
Однако возникает закономерный вопрос: если промпт только интерпретирует, то каким образом агент динамически выбирает инструменты и источники? Здесь появляется Model Context Protocol (MCP) — и вместе с ним новая волна заблуждений. MCP-сервер описывают как замену шины данных и GraphQL, что технически некорректно.
MCP — это универсальный адаптер. Он предоставляет агенту стандартизированный интерфейс к трём сущностям: Tools (действия), Resources (данные), Prompts (шаблоны). Но под капотом MCP-сервер вызывает те же REST, GraphQL или SQL, а не подменяет их. Он не занимается трансформацией сообщений, не гарантирует доставку, не обеспечивает транзакционную целостность и, главное, не принимает решений о маршрутизации. Решение о том, какой инструмент вызвать, принимает LLM — недетерминированно, на основе описания.
Именно здесь возникает то самое «поле чудес и русская рулетка», о которых говорилось ранее: агент угадывает инструмент, а результат этого угадывания может быть как точным, так и разрушительным. MCP здесь выполняет роль стандартизированного слоя доступа, но не роль шины данных. Считать «агент + MCP» эволюцией ESB — ошибка. ESB обеспечивает детерминированную маршрутизацию по правилам; MCP обеспечивает стохастический выбор, ограниченный лишь качеством промпта и описаний инструментов.
Практический вывод: антипаттерн «заменили GraphQL промптом» не просто неточен, он опасен. Правильная архитектура подразумевает чёткое разделение: GraphQL и REST — для детерминированной работы с данными, промпты и MCP-адаптеры — для недетерминированного принятия решений. Агент без проверенной API-подложки беспомощен, а его «гибкость» превращается в генератор ошибок.