API для AI-агентов: от MCP до собственных эндпоинтов

Когда LLM научились вызывать функции

В эпоху GPT-3 взаимодействие с LLM означало передачу промпта и получение текста в ответ. Знания модели были большими, но статичными, зафиксированными на уровне того, что содержалось в обучающих данных. Вы могли попросить ее объяснить квантовые вычисления или написать черновик письма, и она выдавала правдоподобный текст. Но она не могла проверить сегодняшнюю погоду, выполнить запрос к базе данных или совершить действие в реальном мире.

Функция, которая это изменила, получает удивительно мало признания. Она дала модели выбор между генерацией текста и вызовом функции. Вместо того чтобы всегда производить следующий токен, модель теперь могла вывести структурированный JSON-объект с именем функции и ее аргументами. Среда выполнения выполняла эту функцию, передавала результат обратно модели, и модель продолжала работу. В статье ReAct (Yao et al., 2022) это было формализовано как цикл Thought-Action-Observation. Модель рассуждает о том, что делать, выполняет действие (вызывает инструмент), наблюдает результат и повторяет процесс. Каждый серьезный AI-агент в 2026 году работает на той или иной версии этого паттерна.

Цикл

Claude Code, OpenClaw, Codex, Devin и десятки других агентных систем работают одинаково. Вызвать инструмент, наблюдать результат, решить, что делать дальше, повторить. Simon Willison сформулировал это точно: “LLM-агент запускает инструменты в цикле, чтобы достичь цели.”

Claude Code, например, использует однопоточный главный цикл без многоагентного роя или сложного графа оркестрации: while(tool_call) -> execute -> feed results -> repeat.

Исследование Anthropic об автономности агентов показывает, что длительность ходов в Claude Code почти удвоилась за три месяца, с 25 до более чем 45 минут. Пользователи все чаще доверяют циклу работать самостоятельно. Данные показывают, что опытные пользователи прерывают работу чаще (переходя от одобрения каждого действия к стратегическому мониторингу), а сам агент просит уточнений более чем в два раза чаще, чем пользователи его прерывают.

Этот циклический паттерн встречается везде: в агентах для программирования, ботах поддержки клиентов и контроллерах робототехники.

Что считается инструментом?

LLM дают нам значительную свободу в выборе уровня абстракции, на котором должен работать инструмент. На одном конце находятся очень конкретные API-эндпоинты: “создать контакт HubSpot с этими 12 полями”. На другом, инструменты вроде “выполнить эту bash-команду” или “выполнить этот Python-код”, то есть фактически “делай что угодно”.

Devin работает с тремя инструментами: shell, редактор кода, браузер. Основной инструмент Claude Code тоже shell. OpenClaw использует динамическую систему плагинов навыков. Тренд в агентных инструментах для программирования движется к меньшему числу более общих инструментов, а не к большому числу специализированных.

Simon Willison отметил, что MCP “сначала быстро распространился, но затем стал казаться менее центральным” для агентов программирования, потому что bash является универсальным инструментом. Файлы и скрипты, это примитив с меньшими накладными расходами, чем полноценные реализации MCP-серверов. Если агент может писать и выполнять код, он может сделать почти все без отдельного определения инструмента.

Но инструменты общего назначения подходят для агентов общего назначения. Для доменно-специфичных AI-агентов (поддержка клиентов, продажи, внутренние операции) нужны доменно-специфичные инструменты. Ваш агент поддержки не должен писать Python, чтобы проверить статус заказа. Он должен вызывать хорошо определенный API-эндпоинт с понятными параметрами и предсказуемыми ответами. Проектирование набора инструментов становится продуктовым решением.

Что теперь означает API-эндпоинт

Для AI-агентов API-эндпоинт работает как декларация возможности. Публикуя его, вы говорите, что вы (или ваш AI-агент) теперь можете делать то, что раньше было невозможно.

Это работает в обе стороны. Поставщик ПО публикует API, чтобы другие могли интегрироваться с его продуктом. Но AI-агент также может самостоятельно находить эндпоинты, изучая документацию, читая спецификации OpenAPI или буквально гугля, как выполнить задачу.

MCP-сервер представляет собой курируемый пакет API-эндпоинтов с заранее заданным представлением о том, как их следует использовать. Создатель MCP уже принял решения о том, какие эндпоинты раскрывать, как их называть, какие параметры показывать и, неявно, какие рабочие процессы поддерживать. Эта курация является одновременно сильной стороной (удобство, стандартизация) и слабой стороной (жесткость, предвзято заданные рамки). Сервер Notion, конкретный пример: он публикует 28 инструментов, а агенту справочного центра нужны четыре из них, разделенные между двумя подключениями.

MCP обменивают контроль на простоту использования. В 2026 году ИИ пишет большую часть кода интеграций. Если агент может прочитать API-документацию и сам написать интеграцию, аргумент “простоты использования” в пользу MCP становится слабее. Слой MCP может быть наиболее важен в переходный период, пока инструменты не догнали возможности модели. Руководство Anthropic по паттернам проектирования использования инструментов является практическим справочником по структурированию схем инструментов независимо от того, используете вы MCP или отдельные эндпоинты.

Связанное развитие: llms.txt является предлагаемым стандартом, в котором сайты публикуют файл /llms.txt, чтобы направлять AI-модели к наиболее ценным ресурсам. Его приняли Anthropic, Cloudflare, Docker и Stripe. MCP стандартизирует вызов инструментов, llms.txt стандартизирует обнаружение документации. Оба подхода пытаются сделать веб более понятным для машин, но с разных сторон.

Что такое API-эндпоинт в контексте AI-агентов?

API-эндпоинт, это конкретный URL, который принимает структурированный ввод и возвращает структурированный вывод. Для AI-агентов каждый эндпоинт представляет отдельную возможность, то, что агент может сделать в реальном мире. Описание эндпоинта, определения параметров и ответы об ошибках служат инструкцией для агента. Чем лучше задокументирован эндпоинт, тем надежнее агент может его использовать.

В отличие от разработчиков-людей, которые могут читать руководства и отлаживать итеративно, агент полагается на схему и описание эндпоинта, чтобы выполнить один правильный вызов. Поэтому API-документация, спроектированная для потребления ИИ, важнее, чем когда-либо. Только 24% разработчиков сейчас проектируют API с учетом AI-агентов, несмотря на то что 89% используют ИИ в своем рабочем процессе.

Что такое MCP (Model Context Protocol)?

MCP, это открытый протокол, представленный Anthropic, который стандартизирует подключение AI-агентов к внешним инструментам и источникам данных. Думайте о нем как об USB-C для ИИ. Один коннектор, который может реализовать любой поставщик инструментов и использовать любой AI-агент. MCP-сервер раскрывает набор инструментов (по сути API-эндпоинтов) со стандартизированными схемами, а MCP-клиент (агент) может обнаруживать и вызывать их без пользовательского кода интеграции. Более глубокое техническое объяснение см. в нашей статье MCP Explained. Практический разбор MCP в продакшене см. в нашем анализе реальных сложностей при создании решений на Shopify’s MCP.

Спектр контроля в Quickchat AI

Quickchat AI дает вам три способа снабдить AI Agent внешними инструментами. Они расположены на спектре от наиболее автоматизированного до наиболее контролируемого. Каждый подход предполагает свой компромисс между скоростью настройки и точностью поведения.

Remote MCP: подключить и использовать

Remote MCP, это самый быстрый способ подключить AI Agent к внешней функциональности. Вы указываете URL MCP-сервера, Quickchat AI подключается к нему, обнаруживает все доступные инструменты и позволяет выбрать, какие из них должен использовать ваш агент.

Как настроить:

1. Перейдите в AI Actions в панели управления Quickchat AI
2. Нажмите “Add Remote MCP”
3. Вставьте URL вашего MCP-сервера (например, https://mcp.example.com/sse)
4. При необходимости добавьте токен аутентификации или пользовательские заголовки (эти два варианта взаимоисключающие)
5. Нажмите “Connect.” Quickchat AI обнаружит все доступные инструменты и покажет их имена
6. Включайте или выключайте отдельные инструменты, чтобы контролировать, какие из них может использовать ваш агент
7. Установите флаг “default tool is active”, чтобы управлять тем, будут ли новые обнаруженные инструменты автоматически включены или отключены

Что происходит внутри:

Когда вы нажимаете Connect, Quickchat AI автоматически определяет транспортный протокол по URL. Если URL содержит sse, используется транспорт SSE, в противном случае по умолчанию используется streamable_http. Когда вы указываете auth token, он отправляется как Bearer-токен в заголовке Authorization.

Фильтрация инструментов работает через трехуровневую систему. Каждый инструмент с MCP-сервера проверяется по двум наборам: явно включенные инструменты всегда добавляются, явно отключенные инструменты всегда исключаются, а любой инструмент, отсутствующий в обоих наборах, подчиняется выбранной вами настройке “default tool is active”. Это означает, что когда MCP-сервер добавляет новые инструменты, вы контролируете, будут ли они автоматически доступны вашему агенту или потребуют явной активации.

Во время выполнения, когда начинается разговор, загружаются все активные подключения Remote MCP для агента. Инструменты извлекаются и фильтруются в соответствии с конфигурацией каждого подключения, а уникальность имен инструментов проверяется по всем источникам (с предупреждением, если найдены дубликаты).

Компромисс: вы сразу получаете доступ ко всему, что раскрывает MCP, но у вас ограниченный контроль над описаниями инструментов, определениями параметров и тем, как агент решает их использовать. Как мы выяснили при создании AI Agent на Shopify’s MCP, переход от демо к продакшену требует тщательной настройки, которую пакетный подход MCP может осложнять.

См. также: подключите своего агента к удаленному MCP-серверу, How to Launch Your Quickchat AI MCP, соображения безопасности MCP, документация Quickchat AI: MCP channel.

AI Actions (HTTP Request): один эндпоинт, полный контроль

AI Action в Quickchat AI, это один HTTP API-эндпоинт, который вы настраиваете индивидуально для своего AI Agent. Там, где MCP импортирует пакет инструментов сразу, каждая AI Action дает вам полный контроль над одной конкретной возможностью. Полный разобранный пример с четырьмя действиями, которые создают и обогащают контакты, логируют сделки и открывают тикеты в CRM, см. в руководстве по HubSpot AI Actions.

Настройка AI Action:

1. Name (максимум 64 символа): это станет именем инструмента, которое видит LLM. Оно нормализуется в допустимый идентификатор (например, “Check Order Status” становится Check_Order_Status)
2. Description (максимум 1,000 символов): это самое важное поле. Описание сообщает LLM, когда использовать этот инструмент. Хорошие описания указывают, при каких обстоятельствах в разговоре его вызывать, какую информацию сначала собрать у пользователя и как сообщать результаты обратно
3. HTTP method: GET, POST, PATCH, DELETE или PUT
4. URL (максимум 10,000 символов): может содержать плейсхолдеры {{parameter_name}} для динамических значений
5. Headers: пары ключ-значение для аутентификации и типа содержимого
6. Body items / Body JSON: тело запроса с подстановкой параметров
7. Query parameters: значения строки запроса URL
8. Parameters (максимум 10): у каждого есть имя, описание (максимум 500 символов), тип (str, int, float, bool или custom), флаг обязательности и необязательное значение по умолчанию

Плейсхолдеры {{parameter_name}}, это ключевой механизм. Когда LLM вызывает инструмент, она предоставляет значения для каждого параметра на основе контекста разговора. Затем Quickchat AI подставляет эти значения в шаблоны URL, заголовков, тела и строки запроса перед выполнением HTTP-запроса. Также есть четыре встроенные переменные, которые можно подставлять таким образом: scenario_id, conversation_id, conversation_channel и conversation_url.

AI Action, настроенная для проверки статуса заказа, с шаблоном URL, содержащим плейсхолдер параметра, заголовками и определениями параметров.

Внутри: Quickchat AI динамически строит типизированную схему из ваших определений параметров для каждой AI Action. Пять поддерживаемых типов (str, int, float, bool, custom) сопоставляются с их нативными эквивалентами, и эта схема используется для проверки входных данных LLM перед выполнением HTTP-запроса.

Пример AI Action для проверки статуса заказа:

{
  "name": "check_order_status",
  "description": "Когда пользователь спрашивает о статусе своего заказа и предоставил номер заказа, вызовите этот эндпоинт, чтобы получить текущий статус. Сообщите пользователю статус, ожидаемую дату доставки и номер отслеживания (если доступен).",
  "method": "GET",
  "url": "https://api.example.com/orders/{{order_id}}",
  "headers": [
    { "name": "Authorization", "value": "Bearer YOUR_API_KEY" },
    { "name": "Content-Type", "value": "application/json" }
  ],
  "parameters": [
    {
      "name": "order_id",
      "description": "ID заказа, предоставленный пользователем (например, ORD-12345)",
      "type": "str",
      "is_required": true
    }
  ]
}

Тестирование: в панели управления есть кнопка “Test”, которая позволяет указать примерные значения параметров и увидеть фактический HTTP-запрос (включая сгенерированную команду curl) и ответ до развертывания.

Советы по написанию эффективных описаний AI Action:

• Конкретно указывайте, когда агент должен ее вызывать: “Когда пользователь спрашивает о статусе своего заказа и предоставляет номер заказа, вызовите этот эндпоинт”
• Упоминайте, какую информацию нужно сначала собрать: “Перед вызовом убедитесь, что у вас есть email-адрес пользователя и ID заказа”
• Описывайте, как обрабатывать ответ: “Если статус ‘shipped’, сообщите пользователю номер отслеживания из ответа”
• Для многошаговых рабочих процессов описывайте последовательность в основном системном промпте агента, а не в описаниях отдельных действий. Чтобы перенести значение между действиями и ограничить запись этим значением, используйте Save to memory плюс условие запуска

Разобранный пример: пошаговую AI Action, которая записывает лиды, вопросы без ответа и запросы на демо прямо в таблицу, см. в статье как подключить AI-агента к Google Sheets.

Generate from Text: позвольте ИИ разобраться

Третий вариант предназначен для пользователей, которые знают, что должен делать их агент, но не знают, какой API-эндпоинт (или даже какой сервис) использовать.

Как это работает:

1. Вы вводите описание на естественном языке того, что хотите получить, например: “Я хочу, чтобы мой AI Agent мог запускать Tesla пользователя, когда он попросит”
2. Quickchat AI отправляет это в LLM с включенным инструментом web_search
3. Модель исследует веб, чтобы найти правильный API, читает официальную документацию и генерирует полную спецификацию AI Action, включая URL, метод, заголовки, параметры и требования к аутентификации
4. Результат возвращается с полной конфигурацией действия, ссылками на использованную документацию и пояснительным сообщением с отмеченными предположениями и пробелами
5. Вы проверяете, добавляете свои учетные данные и активируете

Ввод описания желаемой возможности на естественном языке.

Сгенерированная конфигурация AI Action со ссылками на использованную API-документацию.

Автоматическая генерация AI Action построена вокруг трех приоритетов:

• Приоритет 1: понять намерение. Определить точную возможность, которая нужна разработчику, и конкретный API-эндпоинт, который ее предоставляет
• Приоритет 2: опираться на документацию. Использовать веб-поиск, чтобы найти официальную документацию поставщика, а не догадки
• Приоритет 3: проектировать семантику с учетом разговора. Сгенерированные имя и описание должны описывать, когда в разговоре используется этот инструмент, а не только то, что API делает технически

Промпт использует две конвенции плейсхолдеров. {{param}} обозначает параметры времени выполнения, которые LLM заполняет из контекста разговора. [[secret_name]] (двойные квадратные скобки) обозначает константы разработчика, такие как API-ключи и ID аккаунтов, которые нужно настроить вручную перед активацией. Имя каждого параметра должно появляться как плейсхолдер {{that_exact_name}} где-либо в определении запроса, и не допускаются осиротевшие плейсхолдеры.

Система использует политику fail-closed. Если модель не может подтвердить критически важную информацию из документации (HTTP-метод, URL, схему аутентификации или обязательную структуру payload), действие не создается. Вместо этого система возвращает краткое объяснение того, чего не хватает, а не делает предположение.

Именно здесь философская идея о том, что AI-агенты обнаруживают API, связывается с конкретной функцией продукта. Функция Generate from Text буквально является AI-агентом (LLM с веб-поиском), который строит определение инструмента для другого AI-агента (агента Quickchat AI, который будет использовать его в разговорах).

Разобранный пример: полное руководство, которое превращает два введенных предложения в два живых и протестированных действия (запрос погоды без ключа и запрос NASA с ключом, включая отказ fail-closed), см. в статье как подключить вашего AI-агента к любому API на простом английском.

Во время выполнения все эти типы инструментов собираются вместе. Quickchat AI собирает инструменты HTTP request AI Action, инструменты Shopify MCP, инструменты базы знаний, инструменты Remote MCP, инструменты Discord и другие пользовательские инструменты в коллекцию, которая передается LLM. Модель не видит различий между ними. Инструмент Remote MCP и вручную настроенная AI Action выглядят одинаково, когда оказываются в списке инструментов.

Открытые API как новое SEO

Если AI-агенты будут автономно обнаруживать и использовать API, то хорошо задокументированный и простой в использовании API становится активом дистрибуции. Gartner прогнозирует, что к 2026 году более 30% роста спроса на API будет приходиться на AI-агентов.

Компании с открытыми API и минимальными барьерами учетных данных могут обнаружить, что их API становятся лучшим каналом привлечения. Вместо показов в поиске Google “показами” становятся AI-агенты, которые выбирают ваш сервис вместо сервиса конкурента.

Та же логика применяется на уровень выше. AI-агент, который отвечает на основе вашей документации, может сам быть раскрыт как MCP-сервер, который ChatGPT, Claude и Cursor вызывают как инструмент, что делает ваши знания, а не только ваш API, доступными для обнаружения агентным вебом.

Качество вашей API-документации определяет, сможет ли AI-агент успешно интегрироваться с вами с первой попытки. Описания параметров, сообщения об ошибках и примеры ответов выполняют ту же функцию, что метаописания и структурированные данные в традиционном SEO. Непонятный ответ об ошибке или незадокументированное обязательное поле означает, что агент потерпит неудачу, и на другой стороне не будет человека, который это отладит.

Компании, чьи API не задокументированы или закрыты за тяжелыми требованиями к учетным данным, могут оказаться невидимыми для агентного веба, так же как компании без сайтов стали невидимыми для Google в 2000-х.

Computer Use и API

Существуют значительные инвестиции в обучение AI-моделей “computer use” (нажатие кнопок, заполнение форм, навигация по UI). Anthropic, OpenAI (Operator) и open-source проекты вроде Browser Use предлагают свои версии этого подхода.

Но использование браузера, это обходной путь при отсутствии API. Вызов POST /orders занимает миллисекунды и возвращает структурированные данные. Браузерный агент, проходящий checkout flow, тратит минуты и может сломаться, если кнопка сдвинется на три пикселя влево. API быстрее, более детерминированы и дешевле в выполнении.

Контраргумент реален: API существуют не для всего. Legacy-системы, корпоративное ПО без API-поверхности, физические устройства, управляемые через GUI. Computer use закрывает реальный пробел в таких случаях.

Более правильный долгосрочный ответ на “у нас нет API для этого”, вероятно, состоит в том, чтобы построить API, а не учить ИИ пользоваться GUI. По мере того как все больше ПО пишется AI-агентами для AI-агентов, стоимость создания и поддержки API снижается. Экономический расчет, при котором парсить UI было дешевле, чем строить API, меняется.

Есть и аспект безопасности. “Летальная триада” Simon Willison описывает опасное сочетание доступа к приватным данным + воздействия недоверенного содержимого + внешней коммуникации. Это относится к обоим подходам, но инструменты на основе API легче аудировать и ограничивать. Вы можете логировать каждый API-вызов, валидировать каждый параметр и ограничивать частоту запросов к каждому эндпоинту. Делать эквивалент для браузерного агента, который может нажать что угодно, намного сложнее.

Инструменты для физического мира

Все, что обсуждалось до сих пор, относится к программному обеспечению. Тот же паттерн проявляется в физическом мире.

RT-2 и Gemini Robotics от Google DeepMind используют ту же архитектуру, только инструменты отправляют команды исполнительным механизмам вместо API. Фреймворк SPCA (Sense-Plan-Code-Act) формализует это для робототехники: просканировать окружение, спланировать подход, сгенерировать исполняемый код, выполнить его, наблюдать результаты.

Не существует API для “передвинуть растение на моем столе вправо”. Но робот с камерой мог бы на лету определить move_object(object_id="plant_01", direction="right", distance_cm=15) как инструмент и затем вызвать его. Определение инструмента служит интерфейсом между слоем рассуждения и слоем физического исполнения, выполняя ту же роль, что API-эндпоинты в программном обеспечении.

Архитектура LLM + инструменты + цикл является универсальной. Сегодня ее проще всего реализовать в ПО, но робототехника догоняет.

API, написанные ИИ для ИИ

Примерно за два года (с 2024 по 2026) мы перешли от ситуации, где большую часть кода писали люди, к ситуации, где большую часть кода пишет ИИ. Это хороший момент, чтобы переосмыслить, что такое API-эндпоинт. Все чаще эндпоинт, это декларация возможности, предназначенная для обнаружения и выполнения машинами, а не технический интерфейс, о котором разработчики-люди читают документацию и затем вручную интегрируют.

MCP являются полезным слоем стандартизации, но они также являются слоем курации, который вносит предвзятость. Создатель MCP решает, какие инструменты раскрывать и как их представлять. Для продакшен AI-агентов такая подача может не соответствовать тому, что вам действительно нужно. (Мы подробно писали об этом при анализе проблем с Shopify’s MCP.)

Спектр, который мы рассмотрели в Quickchat AI Agents, отражает более общий тезис. Правильный уровень контроля зависит от вашего сценария. Remote MCP хорошо подходит для быстрого прототипирования. Отдельные AI Actions дают вам детальный контроль для продакшен-агентов, работающих с клиентами. Generate from Text позволяет ИИ исследовать API и построить для вас определение инструмента, когда вы еще изучаете варианты.

И на каждом уровне базовый паттерн один и тот же. LLM, набор инструментов, цикл. Независимо от того, являются ли инструменты bash-командами, API-эндпоинтами, MCP-серверами или исполнительными механизмами роботов, все упирается в инструменты.