Как создать своего локального ИИ-агента: с нуля или на готовой основе
Что на самом деле стоит за запросом «создать своего ИИ-агента»: из каких частей он собирается, когда придётся писать код, а когда достаточно готовой основы, и как сделать его локальным — без облака, подписки и VPN.
Запрос «создать своего ИИ-агента» скрывает два очень разных желания. Одни хотят написать агента как программу — со своим кодом, циклом рассуждения и набором функций. Другие хотят получить помощника под свои задачи, который работает у них на машине и делает то, что нужно именно им. Оба варианта законны, но путь к ним разный, и первое, что стоит сделать, — понять, какой из них твой. Разберём оба, а заодно — как в любом случае оставить агента локальным.
Из чего вообще состоит агент
Слово «агент» звучит как что-то цельное, но внутри это несколько отдельных частей, и собрать своего — значит собрать именно их:
- Модель. Собственно нейросеть, которая рассуждает. Локально это может быть Qwen, GigaChat, DeepSeek или любая другая модель в формате GGUF. От неё зависит, насколько умно агент понимает задачу.
- Цикл с инструментами. То, что превращает «модель, которая пишет текст» в «агента, который действует». Модель просит вызвать инструмент — код выполняет вызов — результат возвращается модели — она решает, что дальше. Этот цикл и есть сердце агента.
- Инструменты. Файлы, терминал, поиск в интернете, обращения к внешним сервисам. Без них агент только разговаривает.
- Память и правила. Чтобы агент помнил контекст и вёл себя по-твоему, а не начинал каждый чат с чистого листа.
Когда люди пишут «как создать агента с нуля», они обычно недооценивают именно второй пункт. Модель подключить несложно — тяжёлая часть в надёжном цикле вызова инструментов: разобрать, что именно попросила модель, выполнить, вернуть результат в понятном ей виде, обработать ошибку, не зациклиться. Это и есть та работа, которую придётся либо написать, либо взять готовой.
Путь первый: написать агента кодом
Если тебе нужен именно свой код — потому что ты строишь продукт, изучаешь внутреннее устройство или у тебя нестандартный сценарий, — собирать придётся из кубиков. Обычно это выглядит так: берёшь среду для запуска модели (llama.cpp, Ollama или LM Studio с локальным API), поверх неё пишешь цикл вызова инструментов сам или на фреймворке, описываешь функции, которые агент может дёргать, и добавляешь хранилище для памяти.
Честная оценка: рабочий прототип на фреймворке поднимается за вечер, но путь от «у меня отвечает» до «у меня не ломается на длинной цепочке инструментов» — это недели. Больше всего сил уходит не на модель, а на обработку сбоев: зависший вызов, неверный формат ответа, инструмент, который не выполнился. Если это твоя цель — отлично; если ты просто хотел помощника под задачи, код здесь лишний.
Отдельно про модель. На обычной домашней машине локальная модель скромнее топовой облачной — это факт, а не придирка. Для классификации, сводок, работы с файлами и несложного кода её хватает; на сложном многошаговом рассуждении она уступает большим облачным. Поэтому многие делают гибрид: рутина идёт на локальной модели, тяжёлая разовая задача — на облачной по API. Подробнее про выбор — в статье про локальную модель вместо облачного API.
Путь второй: собрать на готовой основе
Гораздо чаще за «создать своего агента» стоит не «написать харнесс», а «получить агента под мои задачи, который слушается меня и работает локально». В этом случае писать цикл вызова инструментов с нуля незачем — он уже написан, и своего агента ты собираешь поверх.
Именно так устроена Дока — десктопный агент для Windows и Mac. Цикл с инструментами, доступ к файлам и терминалу, поиск в интернете, подключение внешних сервисов уже внутри. «Своим» агент становится за счёт того, что ты добавляешь сверху:
- Модель под задачу. Встроенные Qwen и GigaChat, свой
.gguf-файл или облачная модель по API — переключаешься под конкретную работу. - Свои инструменты через MCP. База данных, трекер, мессенджер, любой сервис подключаются через MCP-сервер, и агент начинает работать с твоими реальными данными, а не в вакууме.
- Свои правила и процедуры. Через навыки в обычном Markdown ты описываешь свой порядок действий один раз, и агент применяет его сам.
- Проекты и память. Отдельный контекст под каждое направление — как это настроить, разобрано в статье про то, как настроить агента под себя.
Результат тот же, что и в первом пути, — агент, который делает твоё, — но без месяцев на обвязку. Ты занимаешься тем, что уникально в твоём сценарии (правила, инструменты, данные), а не переписываешь цикл вызова инструментов, который у всех одинаковый.
Что значит «локальный» здесь
И код с нуля, и сборка на основе могут быть локальными, но у локальности есть граница, про которую честно стоит сказать. Локально работают модель и сам агент — они на твоей машине, без интернета и без VPN. Данные, которые агент читает у тебя на диске, никуда не уезжают.
Но если ты подключаешь через MCP внешний сервис — облачную базу, чужой API, — то запрос к нему по-прежнему уходит в этот сервис. Локальный агент не делает облачный сервис локальным; он лишь сам живёт у тебя и решает, когда и куда обращаться. Это нормально — важно просто понимать, где проходит граница, особенно если работаешь с чувствительными данными.
С чего начать
Практический порядок такой. Сначала честно ответь, нужен ли тебе свой код. Если задача — «помощник под мои дела на моей машине», начни с готовой основы: скачай Доку, подключи одну модель, добавь один MCP-сервер под то, чем пользуешься чаще всего, и опиши один навык под повторяющуюся процедуру. Этого уже достаточно, чтобы получить агента, которого нет больше ни у кого, — потому что набор инструментов и правил твой.
Если же тебе нужен именно свой код — начни с минимального цикла на одной модели и одном инструменте, добейся, чтобы он не ломался, и только потом расширяй. И там, и там принцип один: агент собирается по частям, а не появляется целиком. Что такое локальный агент по сути и чем он отличается от браузерного чата — в отдельной статье про локального ИИ-агента.