Главная / Статьи

Создание локального агента для исследований в LM Studio с использованием четырех серверов MCP

Местный исследовательский агент в LM Studio с четырьмя серверами MCP: файловая система, GitHub, SearXNG и Camofox, упрощённая схема инструментов, команда для планирования и демонстрация функции анкеринга.

Издатель: REACTAPP.TOP14 мин чтения3208 слов

Источники: How to Turn LM Studio Into a Local Research Agent With MCP Servers

Полезен локальный модель, который может искать, читать файл или открывать pull request. Локальный модель, способный объединить все эти действия в одной логической цепи для ответа на один вопрос, представляет собой исследовательского помощника. Чтобы добиться такого уровня в LM Studio, требуются четыре сервера MCP, работающих параллельно, план по предотвращению того, чтобы совокупные схемы инструментов занимали слишком много места в окне контекста, а также механизм, побуждающий модель объемом 9 миллиардов параметров выполнять многоэтапную задачу целиком, вместо того чтобы использовать один инструмент и останавливаться.

Четыре сервера — это сервер файловой системы, сервер GitHub, самостоятельно развернутая инстанция SearXNG для поиска и браузер Camofox для просмотра страниц, находящихся в результатах поиска. Сервер файловой системы имеет название @modelcontextprotocol/server-filesystem и работает только в определенной директории. Доступ к GitHub осуществляется через OAuth по адресу api.githubcopilot.com/mcp/. SearXNG и Camofox запускаются в Docker и взаимодействуют друг с другом через интерфейсы mcp-searxng и camofox-mcp. Каждый из них функционирует независимо. Интересно то, что происходит, когда в одном чате объединяются все эти компоненты.

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

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

Этап 1: все четыре сервера в одном чате

LM Studio не ограничивает количество серверов MCP, которые могут использоваться в одном чате. Он загружает их все и передает модели схему каждого инструмента с каждого из них. В этом и заключается преимущество такой настройки, но, как покажет следующий этап, это также первая проблема, с которой сталкиваются пользователи.

Файловая система и записи в GitHub настроены так, как это делается в автономной среде, аналогично и записи SearXNG и Camofox. Основные контейнеры должны уже быть запущены, причем файлы docker-compose.yml и searxng/settings.yml в них должны находиться, поскольку они не повторяются здесь. Изменение заключается в том, что все четыре записи теперь находятся в одном файле mcp.json:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/jes/research-workspace"
      ]
    },
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "auth": {
        "CLIENT_ID": "<your Client ID>",
        "CLIENT_SECRET": "<your client secret>"
      }
    },
    "searxng": {
      "command": "npx",
      "args": ["-y", "mcp-searxng"],
      "env": {
        "SEARXNG_URL": "http://localhost:8080"
      }
    },
    "camofox": {
      "command": "npx",
      "args": ["-y", "camofox-mcp"],
      "env": {
        "CAMOFOX_URL": "http://localhost:8765",
        "CAMOFOX_API_KEY": "your-camofox-api-key",
        "CAMOFOX_AUTH_MODE": "api_key"
      }
    }
  }
}

Три момента заслуживают внимания.

  • Энтрия github запускает собственный шаг OAuth. LM Studio запрашивает её при первой попытке сервера загрузиться. Поскольку конечная точка GitHub не поддерживает динамическую регистрацию клиентов, в процессе используется приложение GitHub OAuth, которое необходимо зарегистрировать вручную заранее. Обойти это невозможно.
  • Разрешённая директория для сервера файловой системы выбирается произвольно. Специальная папка research-workspace работает лучше, чем домашняя директория, в основном потому, что она чётко показывает, к чему может обращаться модель.
  • CAMOFOX_URL и SEARXNG_URL должны указывать на контейнеры Docker. Если они не запущены, серверы всё равно загружаются в LM Studio, но любые запросы к ним терпят неудачу, из-за чего в первый раз возникает путаница, которая длится около двадцати минут.

Когда включены все четыре компонента, а маленькие зелёные точки рядом с названиями серверов в панели MCP становятся полными, чат содержит четыре инструмента для работы с файловыми системами, десятки инструментов GitHub, четыре инструмента SearXNG и примерно сорок пять инструментов Camofox. Это огромный объём информации, над которым должна работать одна модель объёмом 9 миллиардов параметров, и именно эту проблему решает следующий этап.

Этап 2: поддержание объёма контекста

Уже один только количественный состав инструментов GitHub представляет собой риск, как и инструменты Camofox. В совокупности с инструментами SearXNG и файловыми системами нагрузка становится значительной.

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

Самое простое решение — это вообще не включать все инструменты с каждого сервера. Для GitHub существует более удобный способ, чем ручное включение инструментов в панели MCP. Временный сервер принимает заголовок X-MCP-Readonly, который ограничивает всю связь использованием только инструментов с режимом чтения, прежде чем LM Studio сможет обработать остальную часть схемы. Благодаря этому запись github из предыдущего этапа становится следующей:

{
  "github": {
    "url": "https://api.githubcopilot.com/mcp/",
    "auth": {
        "CLIENT_ID": "<your Client ID>",
        "CLIENT_SECRET": "<your client secret>"
     },
    "headers": {
      "X-MCP-Readonly": "true"
    }
  }
}

При включенном заголовке сервер объявляет только инструменты для чтения: pull_request_read, issue_read, list_commits, get_file_contents, search_repositories и search_code. Любые инструменты, позволяющие удалять, сливать, загружать или создавать данные, просто отсутствуют. Это ограничение вводится со стороны GitHub, а не из-за скрытия кнопки в LM Studio, поэтому это настоящее ограничение. Это также означает, что схемы для отключенных инструментов записи никогда не токенизируются в контексте, что и является целью этого этапа.

Те, кто хочет более узкие возможности, могут использовать X-MCP-Tools, который принимает явный список разрешенных инструментов, разделенных запятыми, например search_code,search_repositories,get_file_contents,list_commits. Это подходит в тех случаях, когда инструменты для работы с задачами и пул-запросами явно не понадобятся.

Скриншот GitHub MCP в этом состоянии покажет только инструменты get, read, list, scan и search, поскольку флаг только для чтения установлен в значение true, при этом существует возможность отключить дополнительные инструменты, которые не нужны и увеличивают стоимость токена.

У Camofox нет эквивалентного флага с серверной стороны, поэтому его инструменты отключаются по одному в панели MCP. Для чата, предназначенного исключительно для исследований, к отключению подлежат delete_download, import_cookies и все инструменты, связанные с управлением профилями, включая save_profile и load_profile, поскольку сессия исследований не требует работы с сохраненными профилями браузера.

Принцип заключается в том, чтобы оставить только то, что необходимо для конкретного случая использования, и отключить остальное. Для большинства серверов это решение, связанное с ограничением ресурсов, а не с вопросами безопасности. Исключением является GitHub, поскольку его собственный сервер обеспечивает соблюдение этого правила.

Демо-версия на этапе 4 никогда не требует прав на запись в GitHub, поскольку единственная действие в GitHub заключается в чтении одного манифеста, что позволяет сохранять ограничение только на чтение. Если позже потребуется выполнить операцию записи, например, для создания задачи с описанием того, что обнаружил агент, следует использовать отдельный чат для этой цели. Сочетание подключений к GitHub с ограничением только на чтение и с возможностью записи в одной сессии — не лучший способ решения этой проблемы.

Само окно контекста также требует внимания. Минимальный лимит в 4096 токенов казался разумным, когда схема обработки данных поступала с одного сервера. Однако при наличии четырех серверов и сокращенном, но всё ещё значительном списке инструментов 4096 токенов оказывается слишком мало. Необходимо значительно увеличить этот лимит, возможно, до 32 килотокенов и более, в зависимости от возможностей модели и оборудования, а также от ожидаемой продолжительности взаимодействия. Нет единственно правильного значения — речь идет о компромиссе между объемом контекста и свободной памятью VRAM, поэтому следите за процентом заполнения контекста, отображаемым в LM Studio под полем ввода, и корректируйте параметры в соответствии с этими данными.

Этап 3: план, который может выполнить модель

Агент, написанный вручную, имеет одно преимущество, которого интерфейс чата LM Studio не предоставляет автоматически. В скрипте системное сообщение представляет собой строку на Python, находящуюся под полным контролем, и можно явно описать цикл: поиск, выбор источника, загрузка данных, а затем определение того, отвечают ли они на вопрос или требуется новый поиск.

Лучше четко указать, что на самом деле предлагает LM Studio, чем намекать на наличие скрытого варианта планирования. Его нет — отдельных настроек планирования не существует.

Есть только поле «System Prompt» в боковой панели чата под разделом «Model Parameters». Это сообщение можно сохранить вместе с настройками температуры и контекста в виде названного предустановленного значения, так что его не нужно переписывать при каждой сессии. Это тот же механизм, что и у агента, написанного вручную, только в виде текстового поля, а не строки в коде.

Системное сообщение в таком формате подходит для исследовательского чата:

You are a research assistant with tools for web search, page fetching,
file storage, and GitHub. When asked a factual question you cannot
answer with confidence from memory, follow this plan:

1. Search for the topic using searxng_web_search. Look at more than one
result before deciding a source is good.

2. Fetch the most promising source with camofox's navigate and
 snapshot or extract_structured tools, not just the search snippet.
When using camofox always open a new tab before trying to navigate
to a page.

3. If the question needs more than one source to answer confidently,
search again and fetch again before answering.

4. If asked to save findings, write them to a markdown file in the
 workspace using the filesystem tools, don't just describe them in chat.

5. State which sources you actually fetched, not just which ones you
found in search results.

Несколько замечаний о его поведении:

  • Это простой прозаический текст, без использования машин состояний для его контроля. Модель видит именно инструкции и, как правило, следует их структуре, хотя это и не гарантируется, так же как и в случае с системными промптами внутри скриптов.
  • Шаг 5 имеет большее значение, чем кажется. Без него модель склонна отвечать, опираясь только на фрагменты из поиска, пропуская шаг получения данных, что сводит на нет смысл включения Camofox в процесс обработки.
  • Сохранение результата в виде предустановки позволяет использовать его в последующих чатах без повторной вставки.

На скриншоте промпт находится под разделом «Параметры модели», а предустановка называется «Research Chat». При наличии промпта и отфильтрованного списка инструментов у модели появляются возможности и своего рода план их использования. Остается вопрос, действительно ли она ими пользуется.

Этап 4: демонстрация, подтверждающая использование инструментов

Хороший тест на понимание реальных ситуаций должен требовать использования реальных инструментов. Только на основе уверенного воспроизведения из памяти невозможно получить правильный ответ, поэтому модель либо находит реальный источник, либо делает предположение. Задание должно быть таким, которое невозможно запомнить, подлежать независимой проверке и быть достаточно общим, чтобы не касаться конкретного человека.

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

I want you to check one dependency in a GitHub repository for known
security advisories. Do this:

1. In the repository <owner>/<repo>, read <manifest-file> using
   get_file_contents.
2. From that file, find the exact pinned version of the dependency
   "<dependency-name>".
3. Search the web for known security advisories filed against that
   specific version of "<dependency-name>".
4. Fetch the actual advisory page(s) you find rather than relying on
   the search snippet alone.
5. Write a short summary to dependency-risk.md in the workspace: the
   dependency name, the pinned version, any advisories found (with
   severity and a link), and a one-line recommendation.

Места замены работают следующим образом:

  • <owner>/<repo> — это любой репозиторий с правами на чтение. Личный проект подходит так же хорошо, как и публичный, который является зависимостью.
  • <manifest-file> — это имя файла зависимостей, от которого зависит проект, например go.mod, pyproject.toml, requirements.txt или package.json.
  • <dependency-name> — это отдельная зависимость из этого манифеста, желательно та, которая действительно представляет интерес.

Если нет подходящего репозитория, такого как juice-shop/juice-shop — намеренно уязвимого приложения для обучения от OWASP, — его можно заменить. В его файле package.json уже содержатся достаточное количество ранее отмеченных зависимостей, поэтому на этапе поиска обычно находится что-то подходящее, а express-jwt и sanitize-html являются разумными вариантами для начала. Пример заполненной версии выглядит так:

I want you to check one dependency in a GitHub repository for known
security advisories. Do this:

1. In the repository juice-shop/juice-shop, read package.json using
get_file_contents.
2. From that file, find the exact pinned version of the dependency
"express-jwt".
3. Search the web for known security advisories filed against that
specific version of "express-jwt".
4. Fetch the actual advisory page(s) you find rather than relying
on the search snippet alone.
5. Write a short summary to dependency-risk.md in the workspace:
the dependency name, the pinned version,
any advisories found (with severity and a link),
and a one-line recommendation.

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

Полная обработка этого запроса использовала все четыре сервера MCP и потребовала в общей сложности 37803 токенов.

Этот запрос был выбран намеренно. Ответ зависит от репозитория и от того, что в нем закреплено, а базы данных CVE, которые используются в поиске, постоянно обновляются, поэтому заранее невозможно указать точный результат.

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

В демонстрации также показано, что достаточно заголовка только для чтения второго уровня. Весь процесс включает чтение данных с GitHub, поиск информации вне системы SearXNG, загрузку страниц с информацией через Camofox и запись результата в локальный файл; поэтому доступ к записи на GitHub не требуется, и заголовок может оставаться в прежнем виде. Одно запускание задачи позволяет протестировать все четыре сервера за один проход: GitHub читает манифест, SearXNG ищет соответствующие уведомления, Camofox загружает страницы с этими уведомлениями, а файловая система сохраняет итоговый отчет. Это быстрый способ проверить правильность настройки всей системы перед тем, как приступать к реальным исследованиям.

Где возникают проблемы

Лучше указать слабые места, чем притворяться, что вся цепочка работает надежно от начала до конца.

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

Иногда, сталкиваясь с десятками инструментов GitHub, которые она ранее никогда не использовала, модель выбирает подходящий, но неверный инструмент, например list_pull_requests вместо list_issues. Оптимизация на втором этапе является лучшей защитой — более короткий список похожих вариантов сокращает вероятность выбора неправильного инструмента.

Ничто из этого не превращает данный агент в детерминистическую систему. Там, где требуется детерминизм, подходящим инструментом является скрипт, а вручную написанный цикл ближе к этому решению. Преимущество использования LM Studio заключается в том, что модель адаптируется к любому поставленному вопросу, но цена этого — иногда она плохо адаптируется. Наблюдение за её работой над несколькими исследовательскими задачами — самый быстрый способ понять, в чём можно доверять ей, а где ей нужна помощь.

Готовая конфигурация

Четыре этапа обеспечивают работу одного чата в LM Studio с четырьмя серверами MCP. Список инструментов был сокращен, чтобы в контексте всё ещё оставалось место для обработки информации. Системное сообщение предоставляет 9B-модели структуру для работы там, где раньше была пустая страница, а демонстрация получения реальных данных показывает, что загружаются реальные страницы, а не ответы, воспроизводимые из памяти. В конкретных терминах:

  • Файловая система, GitHub, SearXNG и Camofox — всё это доступно в одном чате.
  • Отобранный набор инструментов плюс окно контекста достаточного размера для объединённой схемы вместо ограничений одного сервера.
  • Системное сообщение, сохранённое в качестве настройки по умолчанию, позволяет модели самостоятельно планировать цикл поиска, получения данных и их сохранения, используя те возможности интерфейса LM Studio, которые действительно доступны, а не несуществующие опции конфигурации.
  • Демонстрация повторяемого процесса обработки данных, при которой каждая часть может проверяться независимо, и которая охватывает все четыре сервера в одном запросе.

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

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

Связанные материалы

  • MCP и OAuth2: кто авторизовал действие агента? — Почему OAuth2 покрывает лишь часть процесса авторизации агентов в рамках MCP, и как взаимодействуют OIDC, диапазоны полномочий, правила работы с заместителями, GNAP и возможности агентов.
  • Семнадцать небольших инструментов MCP вместо одного гигантского агента: система для написания текстов с помощью ИИ — Как система для исследований и написания текстов разделяет процессы загрузки видео, поиска, составления черновиков, рецензирования и проверки кода на отдельные инструменты MCP с использованием соответствующих элементов данных и механизмов отслеживания.
  • Практические заметки: «MCP: протокол, превращающий ИИ из чат-бота в агента ИИ» — Подробное руководство по практическим заметкам: «MCP: протокол, превращающий ИИ из чат-бота в агента ИИ», включающее контракты, проверки и готовые фрагменты кода для команд, разрабатывающих системы MCP.
  • Безсостоянийный MCP в спецификации от 28.07.2026: какие изменения коснутся инфраструктуры агентов — Новая версия MCP устраняет поддержку сессий, добавляет заголовки маршрутизации, требует подтверждения наличия входных данных при каждом запросе и ужесточает правила OAuth. Как это влияет на шлюзы, масштабирование и безопасность.
  • Безопасные корпоративные AI-агенты на платформе MCP Toolbox: наборы инструментов на основе намерений, аутентификация и логирование — Принципы проектирования производственных агентов MCP для использования с GCS, PostgreSQL и BigQuery: наборы инструментов, ориентированные на намерения, привязка параметров URL, диапазоны OIDC и структурированная возможность отслеживания состояния.
  • Семантический поиск инструментов в платформе Bedrock AgentCore Gateway для крупных каталогов MCP — Сотни инструментов MCP перегружают контекст агента. Используйте семантический поиск AgentCore Gateway, чтобы передавать агенту Strands только наиболее релевантные результаты и сокращать количество токенов.
  • Создание агента для анализа акций с использованием ReAct и LangGraph — Агент на базе LangGraph и ReAct берет тикер, последовательно запрашивает информацию по фундаментальным показателям, новостям, техническому анализу и инструментам аналитиков, а затем пишет краткий отчет с паузами для участия человека.
  • Второй мозг для локального ИИ: локальная система RAG с использованием AnythingLLM, Ollama и Obsidian — На второй виртуальной машине Proxmox настраивается AnythingLLM и модель эмбеддингов, что позволяет локальной модели Mistral 7B искать информацию в ваших заметках в Obsidian с указанием реальных затрат ресурсов.
  • Связывание инструментов ИИ в ежедневные рабочие процессы без постоянных запросов — Как превратить отдельные инструменты ИИ в повторяемую цепочку операций: избегать ошибок, возникающих при множественных запросах, использовать простой оркестратор и разрабатывать, тестировать и проверять каждый этап.