Я создал агента по возврату средств, который мог получать документы о политике, проверять историю счетов и рассчитывать право на участие.
Однако он не мог задать человеку ни единого вопроса без того, чтобы я не разрушил всю архитектуру.
Именно в этот момент я понял, что большинство серверов MCP глухие, а большинство агентов разговаривают сами с собой.
Сервер, который мог только слушать Я потратил месяц на создание системы поддержки клиентов с несколькими серверами MCP.
Один обернул нашу базу данных политик.
Один из открытых API-интерфейсов управления учетными записями.
Один подключен к системе продажи билетов.
Каждый из них представлял собой чистый, хорошо типизированный и совместимый с MCP сервер.
Каждый из них был полностью однонаправленным.
Проблема была не в вызове инструмента.
Инструменты сработали.
Агент по возврату может получить полис, запросить счет, рассчитать кредит.
Чего он не мог сделать, так это попасть в крайний случай — скажем, вернуть деньги за пределами стандартного окна — и попросить одобрения у человека в середине операции.
Сервер MCP не имел возможности связаться с клиентом.
Клиент мог только спросить; сервер мог только ответить.
Я продолжал искать обходной путь.
Могу ли я закодировать вопрос в результатах инструмента?
Могу ли я использовать отдельный API?
Могу ли я провести опрос?
Каждая альтернатива была обходным путем, а не ответом.
Протокол MCP, который я использовал, был разработан как улица с односторонним движением: агенты вызывают инструменты, инструменты отвечают, агенты рассуждают.
Ничто не течет в другую сторону.
Это потолок, которого достигает большинство команд, но который не называют.
Ваш агент может использовать инструменты, но ваши инструменты не могут взаимодействовать с вашим агентом.
Обратные примитивы.
Никто мне не объяснил.
В спецификации MCP было название того, чего мне не хватало: обратные примитивы.
Запросы, инициируемые сервером, которые позволяют серверу MCP связаться с клиентом в середине операции.
Их изначально три: Sampling, Roots и Elicitation.
Их не было в учебниках, которые я читал.
Их не было в большинстве примеров серверов.
В спецификации они были описаны как «функции клиента» — возможности, которые клиент предлагает серверу, а не возможности, которые сервер предоставляет агенту.
Выборка позволяет серверу запросить завершение LLM через клиента.
Серверу не нужны собственные ключи API, он не выбирает свою модель, не управляет своими расходами.
Он отправляет клиенту запрос выборки/созданияMessage, и клиент — с одобрения пользователя — запускает завершение и возвращает результат.
Это часть, которая превращает сервер инструментов в нечто, способное рассуждать в середине задачи.
Вместо того, чтобы возвращать необработанные данные и надеяться, что агент их правильно интерпретирует, сервер может попросить LLM клиента оценить, обобщить или принять решение.
Выявление позволяет серверу запрашивать у пользователя вводимые данные во время взаимодействия.
Структурированная форма, URL-адрес для внеполосных потоков, схема, отображаемая клиентом.
Это часть, которая решает проблему одобрения возврата.
Сервер попадает в крайний случай, отправляет запрос на получение/создание, клиент передает форму человеку, а сервер получает ответ и продолжает работу.
Roots позволяет клиенту указать, в каких каталогах должен работать сервер — граница области действия, ограничение наименьших привилегий. (Я еще вернусь к этому, потому что отношение спецификации к нему изменилось во многом.) В тот момент, когда я понял эти примитивы, изменилась архитектура.
Мой сервер MCP больше не был конечной точкой пассивного инструмента.
Это был участник разговора.
Он мог бы попросить разъяснений.
Он может позаимствовать рассуждения клиента.
Он мог сделать паузу в середине операции и дождаться человека.
Как на самом деле выглядит двунаправленное движение Как только вы его увидите, поток становится простым.
Клиент отправляет запрос инструментов/вызова на сервер MCP.
Сервер начинает обработку и понимает, что ему что-то нужно — ввод пользователя, решение LLM, решение об объеме.
Вместо сбоя или возврата неполных данных сервер отправляет запрос сервер-клиент обратно через то же соединение.
Клиент обрабатывает запрос — открывает форму, выполняет выборку, проверяет корневую границу — и отвечает.
Сервер получает ответ и продолжает обработку исходного вызова инструмента.
Клиент получает конечный результат.
AWS Bedrock AgentCor