🛠 Инструменты Продолжим разбирать архитектуру агентов. Какая бы умная и крутая модель ни была, хоть AGI, без рук она ничего не сделает. Почта, Jira и база данных сами к ней не подключатся. Встроенные и свои тулы В AI-продуктах есть поиск, браузер, работа с файлами, калькулятор, запуск Python-кода и т. п. Всё это устроено как перечень функций с описаниями: модель может выбрать нужную функцию при ответе на запрос. Если вы работаете через API, в этот перечень можно добавлять свои тулы. Модель не исполняет их сама, а возвращает вызов функции с аргументами. Само действие выполняет ваше приложение. Тул, в отличие от скилла, — не инструкция по работе, а функция или действие, доступное модели. А чтобы передавать списки тулов между разными AI-приложениями, придумали протокол MCP. Как работает MCP MCP — стандартный протокол. Вместо отдельной интеграции для каждого клиента компания поднимает MCP-сервер. Клиент получает список и схемы тулов через tools/list, модель выбирает нужный, а через tools/call вызов уходит серверу. Тот уже обращается к Jira, базе или другому API. Ещё внутри AI-продуктов есть готовые коннекторы — интеграции с конкретными приложениями. По-сути это MCP-обёртки для популярных сервисов. Пользователь просто подключает их через интерфейс и входит в нужный аккаунт. У MCP есть ограничение: чтобы модель выбрала инструмент, клиент показывает ей список доступных тулов. Обычно их схемы попадают в контекст ещё до выбора действия. Пять тулов почти незаметны. Но сотни схем занимают токены, увеличивают стоимость и задержку, а модели становится сложнее выбрать нужную. Помогают с этим бороться allowed_tools, профили и tool search: нужные схемы загружаются по запросу. Но тогда мы можем упереться уже в качество поиска. CLI и локальные файлы CLI пока самый универсальный способ. Агент работает с папкой проекта: ищет через rg, обрабатывает CSV, меняет файлы и запускает тесты. Кастомные команды модель не угадает. ls или git она знает из обучения, а внутренний CLI изучает по README, скиллу или --help. Shell даёт агенту не каталог функций, а возможность исследовать среду. MCP аккуратнее, он удобнее для повторяемых операций и аудита, а CLI — для работы с локальными файлами и более широких возможностей агента. Но и рисков здесь, конечно, больше. Чтобы агент через CLI не получал бесконтрольный доступ ко всему компьютеру, используют sandbox. Например, локальный Codex запускает команды через системный sandbox, там указано, какие папки можно читать, куда писать и доступна ли сеть. Claude Cowork ещё строже: исполнение кода происходит внутри виртуальной машины, которая поднимается на ноуте. MCP Hub Пока MCP-серверов и коннекторов немного, всё это может жить отдельно у каждого сотрудника. Но в компании быстро появляются разные версии MCP, API-токены на ноутбуках и т.п. Чтобы это контролировать, есть концепция MCP Hub. Обычно он состоит из registry, где хранится каталог доступных MCP-серверов; gateway, который пропускает и анализирует вызовы — например, проверяет их на наличие персональных данных; и профилей, которые показывают нужные инструменты разным ролям сотрудников. Цепочка выглядит так: Агент → MCP Hub → MCP-сервер → Jira, GitHub, BI, базы Хаб управляет авторизацией, секретами и логами. Его проще администрировать, а пользователям приходится делать меньше ручных настроек. Из реализаций — Docker MCP Gateway и MCPHub. Computer Use Последний и самый «костыльный» способ дать агенту руки — разрешить ему кликать мышкой за вас прямо на компьютере. Выглядит как довольно смешной способ подружить агента с системами, где нет нормального API или просто долго и лень всё настраивать. Я иногда пользуюсь этой функцией, но выглядит это, конечно, одновременно забавно и стрёмно: агент кликает мышкой и что-то делает на вашем компьютере. Пока это один из самых рискованных и неэффективных методов: много токенов уходит на скриншоты и анализ действий. Зато можно попросить агента собрать дашборд прямо в Tableau, потому что у Tableau нет нормального API =))) @revealthedata #ai #agents #mcp