Автономные агенты на Rust: декомпозиция авторской архитектуры MCP-сервера agents-mcp

Проект agents-mcp на GitHub - движок MCP-сервера для специализированных LLM-агентов, написанный на Rust под лицензией MIT. В репозитории лежит только движок: агентов пишет тот, кто разворачивает сервер. Для 1С-разработчика он интересен по двум причинам. Первая: сервер держит агентов как обычные папки с конфигурацией и промптом, поэтому нового агента можно добавить без пересборки бинарника. Вторая: сервер отдаёт клиенту вызовы моделей, доску задач, работу с файлами и загрузку навыков - набор, рассчитанный на агента, который выполняет шаги.

🧭 Что это за проект

Сервер реализует Model Context Protocol: клиент подключается к нему и видит набор инструментов с описаниями. За вызовом модели стоит маршрут: сервер выбирает провайдера и модель, собирает промпт из шаблона, следит за лимитами и сроками, сохраняет ход выполнения в хранилище задач.

Три типа агентов заданы в конфигурации:

• prompt-template - один запрос к модели без инструментов: преобразовать текст, разобрать фрагмент, дать заключение;
• agent-loop - цикл с инструментами: агент читает файлы, пишет артефакты, ведёт доску задач, укладываясь в ограничение по числу шагов;
• orchestrator - агент, который вызывает других агентов, то есть декомпозиция задачи верхнего уровня.

Провайдеры выбираются в конфигурации: прямой HTTP-вызов по протоколу OpenAI или Anthropic, плюс отдельные блоки для локальных CLI-клиентов claude_cli и codex_cli, плюс mock для тестов. Ключи не хранятся в файле конфигурации: в блоке провайдера указывается имя переменной окружения, а значения подставляются в виде ${ИМЯ} - с возможностью задать значение по умолчанию.

🧱 Агент как папка

Агент описывается каталогом agents/<имя>/. Обязательных файлов два.

• config.toml - описание агента: блок [model] с провайдером, именем модели, температурой и лимитом токенов; блок [response] с форматом ответа json или text; блок [input]; блок [limits] со сроком timeout_sec; блок [cache]; блок [execution] со списками allowed_tools и disallowed_tools, режимом прав, рабочим каталогом, числом шагов max_turns и дополнительными аргументами.
• prompt.md - шаблон на Tera с переменными из входных данных вызова.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

[model]
provider = "direct"
name = "${MODEL_NAME:-deepseek-v4-flash}"
temperature = 0.3
max_tokens = 4000

[response]
format = "json"

[limits]
timeout_sec = 300

[execution]
allowed_tools = ["fs_read_file", "fs_list_dir", "task_create"]
max_turns = 8

Дополнительно принимаются варианты промпта под именем prompt.<вариант>.md - вариант выбирается параметром вызова, - и схема ответа в файле schema.json, на которую ссылается блок [response]. Каталог агентов перечитывается на лету: в конфигурации сервера есть режим горячей перезагрузки с короткой задержкой, поэтому новый агент появляется без перезапуска процесса.

🔌 Транспорт и точки подключения

По умолчанию сервер поднимает потоковый HTTP на локальном интерфейсе: http://127.0.0.1:8025/mcp, номер порта задаётся в блоке [server]. Для клиентов, которые не умеют HTTP, предусмотрен режим stdio - ключ --transport stdio при запуске. Точка GET /health отдаёт состояние сервера: во время остановки в ответе появляется признак draining.

Подключение из клиента описывается стандартной записью в .mcp.json:

1
2
3
4
5
6
7
8

{
  "mcpServers": {
    "agents-mcp": {
      "type": "http",
      "url": "http://127.0.0.1:8025/mcp"
    }
  }
}

Сервер, поднятый только на 127.0.0.1, доступен процессам на той же машине. Для 1С-контура это значит, что обращаться к нему должна либо служба на том же узле, либо настроенный прокси: HTTP-служба 1С сама по себе не станет шлюзом.

🧰 Инструменты MCP

Инструменты сгруппированы по назначению, и в каждой группе видно, на кого рассчитан вызов.

Двумя ключевыми инструментами автор называет invoke_agent и agent_run: первый запускает агента и может вернуть управление сразу, второй доводит вызов до результата в пределах шагов агента. Разделение на запуск и ожидание нужно там, где задача живёт минутами: клиент получает идентификатор и забирает результат позже, не удерживая соединение. Отмена сделана на двух уровнях: agent_cancel для отдельного вызова и chain_cancel для задачи вместе с её фоновыми вызовами.

🧮 Хранилище задач и конфигурация сервера

По умолчанию состояние живёт во встроенной SQLite в режиме WAL, а схема применяется при каждом открытии базы. Для промышленного контура предусмотрен PostgreSQL: строка подключения задаётся в конфигурации или переменной окружения AGENTS_MCP_TASK_STORE_DSN, размер пула - отдельным параметром со значением по умолчанию 8. Миграции для PostgreSQL лежат в каталоге migrations_pg/ и применяются вручную - автоматического обновления схемы там нет, и это первое, что проверяется при переходе со SQLite.

Отдельно ведётся журнал сервиса: своя база SQLite с таблицей событий, сжатием и ограниченным сроком хранения. Файл конфигурации по умолчанию - configs/agents-mcp.toml, рядом лежит пример; путь можно передать ключом --config или переменной AGENTS_MCP_CONFIG.

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

🔒 Границы доступа и защита данных

Три уровня ограничений, которые видны в конфигурации.

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

Наборы инструментов. Инструменты задаются списками разрешённых и запрещённых на уровне агента, плюс режим прав на выполнение. Ограничение набора работает надёжнее запрета на слово в промпте: инструмент либо доступен агенту, либо нет.

Контроль чтения. Перед чтением файла может вызываться внешняя программа-охранник, если у агента подключён индекс кода. У охранника есть свой срок - около пяти секунд. Если он не ответил вовремя или завершился ошибкой, файл читается всё равно, а в журнал попадает предупреждение. Этот момент стоит помнить: охранник даёт сигнал, блокировки в нём нет.

Что уходит провайдеру модели, описано в документации проекта прямо: текст задачи, системный промпт, содержимое читаемых файлов, результаты всех инструментов и рабочие пути. Отсюда практические требования: для работы агента берётся копия базы вместо продуктивной; список инструментов сужается; для агентских вызовов заводится отдельный ключ провайдера. Копию удобно делать через git worktree: агент видит исходники, но не трогает рабочее дерево.

💻 Сборка и запуск

Сборка обычная для Rust - в режиме release. Для сборки под Linux с чужой машины используется кросс-компиляция через zigbuild для цели x86_64-unknown-linux-gnu.

1
2

cargo build --release
cargo zigbuild --release --target x86_64-unknown-linux-gnu

Что проверять заранее:

• на Linux нужна библиотека glibc версии не ниже 2,30; в проекте указана проверенная сборка на Ubuntu 22.04;
• на Windows с GNU-инструментарием в PATH должен быть dlltool, иначе кросс-сборка падает на упаковке библиотек;
• запуск идёт с указанием файла конфигурации: agents-mcp.exe --config configs/agents-mcp.toml;
• уровень журнала задаётся переменной RUST_LOG, а шумные внешние библиотеки по умолчанию приглушены.

📈 Цифры эксплуатации из публикации автора

Данные об эксплуатации принадлежат автору проекта. В его публикации на Infostart приведены цифры за период с 19.06 по 14.09.2026: 10 351 вызов и 78 агентов, успешных сценариев 96,2 %, провальных 3,8 %.

Распределение вызовов по задачам: 5 020 - проверки и отладка, 3 063 - генерация запросов и прикладного кода, 1 843 - интеграция внешних сервисов через 1С, 425 - остальное.

Распределение по провайдерам: Claude Code 6 294 вызова, DeepSeek через API 1 947, свои модели на локальной видеокарте 1 940, прочие 170. Обе разбивки дают в сумме те же 10 351 вызов.

Источник и точные формулировки: статья «agents-mcp и MCP-сервер для ИИ-агентов» на Infostart, автор Sorm, опубликована 17.09.2026 - infostart.ru/1c/articles/2789368. Код проекта: github.com/Regsorm/agents-mcp.

Эти числа описывают один контур и один период. Переносить их на свой проект нельзя: доля успешных вызовов зависит от моделей, формулировок промптов и качества выгрузки контекста.

🪤 Что ломается при развёртывании

• Сборка на Windows без dlltool. Ошибка появляется уже на упаковке, а сообщение говорит про библиотеку, поэтому причину ищут долго.
• Старые библиотеки на Linux. Собранный на новой системе бинарник не стартует на сервере со старым glibc; сборка под целевую версию решается кросс-компиляцией.
• Переход на PostgreSQL без миграций. Миграции применяются вручную: сервер поднимется, но работать с задачами не сможет.
• Одинаковое имя экземпляра. Два сервиса на одной базе с именем по умолчанию мешают друг другу: старт одного закрывает незавершённые вызовы другого.
• Ожидание от охранника чтения жёсткой блокировки. При сбое или превышении срока файл читается с предупреждением в журнале.
• Ключи в файле конфигурации. В проекте предусмотрены подстановки вида ${ИМЯ} и переменные окружения; держать ключ прямо в configs/agents-mcp.toml не нужно.
• Порт занят. Номер 8025 задан по умолчанию, и при нескольких сервисах на узле конфликт портов проявится уже при старте.
• Агент с широкими правами на продуктивной базе. Отдельный ключ провайдера и копия базы вместо рабочей закрывают основную часть риска.

🚧 Что проверено и что осталось за кадром

Проверено по публичным материалам: устройство агента, состав и типы инструментов, адрес и режимы транспорта, точки /health, параметры хранилища, набор провайдеров, правила подстановки секретов, команды сборки, параметры ограничений и цитаты из публикации автора о нагрузке.

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

🏁 Итог

agents-mcp устроен как движок с внешними описаниями: агент - папка с config.toml и prompt.md, инструменты - фиксированный набор из групп вызова, справки, доски задач и файлов, состояние - SQLite по умолчанию и PostgreSQL для промышленного контура, доступ - через разрешённые корни и наборы инструментов. Главное, что стоит перенести в свой проект, - три решения: разделение запуска и ожидания, доска задач как хранилище хода выполнения и явный список инструментов на агента.

Перед развёртыванием проверьте сборку под целевую систему, примените миграции, разведите имена экземпляров и вынесите ключи в переменные окружения. Расскажите в комментариях, какие ограничения для агентов вы ставите у себя - по инструментам или по каталогам.

📦 Файл к статье

Архив к статье (06.2-companion.zip) лежит в блоке «Файлы» (над текстом публикации). Что внутри:

• karta-proekta.md - карта сервера: где лежат агенты, что в блоках конфигурации, на какие группы делятся инструменты;
• primer-agenta.toml - образец описания агента с подстановкой модели из переменной окружения, без ключей;
• chek-list-zapuska.md - порядок первого запуска и проверок: сборка, конфигурация, порт, состояние, список агентов, миграции;
• voprosy-k-proektu.md - вопросы, на которые отвечает только запущенный стенд, с местом для замеров.

При подготовке статьи сервер не запускался: файлы собраны по публичной документации проекта, измерений в них нет.

 

Нинель Адольевна Щербакова (Ninel_S)

Архитектор • SRE & DevOps инженер • HighLoad 1С

Автор 28 технических публикаций на Infostart. Разработчик NOPik, SRE-Suite-for-1C и мультиагентных ассистентов для экосистемы 1С:Предприятие.

Каталог статей и открытых репозиториев Ninel_S