OpenWorker: локальный ИИ-агент на своём API-ключе

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

Почему две привычные схемы не работают

Разберём, из чего вообще приходится выбирать.

Подтверждение каждого действия. Безопасно и невыносимо. Агент делает десятки шагов, на каждом останавливается, человек нажимает «да» не глядя уже к пятому. Через день эту настройку выключают — и получают вторую схему.

Полный доступ. Удобно и опасно. Границы нет вообще: агент получает те же права, что у вас, включая всё, что вы не имели в виду.

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

Разумный вопрос лежит посередине: не «можно ли выполнить вот это», а «можно ли агенту вообще делать такие вещи». На него человек ответить в состоянии, и ответить один раз.

Что даёт разбиение по риску

Четыре уровня выстроены по возрастанию последствий, и это ключевое свойство.

Чтение локальных файлов. Самое безобидное. Худшее, что может случиться, — агент прочтёт лишнее. Неприятно, если рядом лежат секреты, но необратимого ничего.

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

Выполнение кода. Качественный скачок. Всё, что можно сделать в системе, становится доступно, и ограничения предыдущих уровней теряют смысл.

Обращение к внешним сервисам. Отдельная ось: данные могут покинуть машину. Это единственный уровень, где ущерб не ограничен вашим компьютером.

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

Что ещё внутри

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

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

Разделение полезное: библиотека годится как основа для собственной обвязки, а само приложение — как рабочий пример того, что на ней можно собрать. Для команды, которая раздумывает, писать своего агента или брать готового, это удобная точка входа.

Лицензия MIT — одна из самых свободных: не ограничивает коммерческое использование, не требует раскрывать производные и не ставит условий по масштабу бизнеса. Мы разбирали разницу между такими лицензиями и собственными лицензиями вендоров на примере музыкальной модели, где условия оказались куда жёстче.

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

Почему разрешения важнее интеллекта модели

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

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

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

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

Модель под капотом вы всё равно поменяете — это строчка в конфигурации. Архитектуру разрешений поменять не получится.

Как это применить независимо от инструмента

Практическая часть, потому что четыре уровня — это идея, а не привязка к конкретному агенту.

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

1. Выпишите все инструменты, доступные агенту. Список обычно длиннее, чем помнится.
2. Отнесите каждый к уровню. Чтение, запись, выполнение, внешний вызов. Спорные случаи относите к более высокому уровню.
3. Определите, какие уровни нужны задаче. Большинству сценариев хватает первых двух.
4. Сделайте повышение уровня явным действием. Не флагом в конфигурации, о котором забудут, а решением, которое принимается осознанно и, желательно, на время.

Четвёртый пункт — тот, где обычно всё разваливается. Разрешение, выданное однажды «на время отладки», живёт годами, и никто уже не помнит, зачем оно было нужно. Помогает простое: срок жизни у повышенного уровня, после которого он сам возвращается к базовому.

Про модель под таким агентом

Отдельно, потому что это прямо касается выбора.

OpenWorker не привязан к вендору: он берёт ваш ключ и работает с тем каталогом, который вы укажете. Та же конструкция, что у кодинг-агента fx от Vercel, и это уже становится нормой — харнесс и модель выбираются независимо.

Практические следствия для расхода:

Начинайте с дешёвой модели. Агент делает много шагов, и ставка умножается на их количество. В каталоге есть позиции от 3 ₽ за миллион токенов и три с нулевой ставкой.

Считайте историю, а не запросы. В агентском цикле она растёт квадратично — как это считать.

Проверьте статус маршрута. Модель может быть в каталоге, но с закрытым протоколом; читается это из живой выдачи.

Чего мы не утверждаем

Инструмент вышел в конце июля, а не сегодня. Мы пишем о нём с опозданием и говорим об этом прямо.

Мы его не запускали. Все характеристики — из публикаций и репозитория, перечисленных в источниках.

Четыре уровня — не гарантия безопасности. Это разумная организация разрешений на уровне приложения. Она не заменяет изоляцию на уровне операционной системы, если агент выполняет код — почему обычного контейнера мало.

Не сравниваем с другими агентами. Разбираем конкретное решение, а не выносим вердикт о том, чей инструмент лучше.

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

Что держать в голове

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

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

Как мы отделяем проверенное от предполагаемого — на странице о проекте. Ключ для любого совместимого агента заводится за минуту: keydealer.ru/login.