OpenWorker: AI-агенты Эндрю Ына с открытым кодом

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

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

Вот краткая версия:

• Что он делает: превращает цель в многошаговый рабочий процесс
• Как он работает: настольное приложение Tauri 2 + интерфейс на React 18 + локальный сервер FastAPI/Uvicorn
• Доступ к моделям: облачные провайдеры и локальные модели через aisuite, плюс Ollama для локального использования
• Модель безопасности: read, write_local, exec и external
• Проверка человеком: каждый шаг exec и external ожидает одобрения
• Подключённые инструменты: файлы, календари, Slack и другие командные системы
• Вариант эндпоинта модели: APIMart через единый OpenAI-совместимый API
• Наиболее подходящая работа: отчёты, исследования, контент-пакеты, задачи поддержки и медиа-конвейеры
• Требования для продакшена: трассировка, оценки, версионирование промптов, отслеживание расходов и процесс проверки исходящих сообщений

Несколько фактов выделяются. OpenWorker использует 4 типа действий, блокирует 100% действий exec и external, пока человек их не одобрит, и может переключаться между такими моделями, как GPT-5, Claude Sonnet 4.6 и Gemini 3 Pro Preview, не меняя логику рабочего процесса.

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

Эндрю Ын: состояние AI-агентов | LangChain Interrupt

Как работает OpenWorker: архитектура, модели и разрешения

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

Настольное приложение и локальный сервер агента

OpenWorker работает как настольное приложение Tauri 2 с интерфейсом на React 18 в паре с локальным сервером на Python 3.10+ с использованием FastAPI и Uvicorn. Проще говоря, приложение, которое вы видите на своём рабочем столе, работает бок о бок с локальным сервером, запущенным на вашей машине.

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

Маршрутизация моделей между облачными и локальными LLM

OpenWorker использует aisuite для маршрутизации запросов между провайдерами облачных моделей и локальными средами выполнения, такими как Ollama. Это даёт командам возможность решать, куда должна идти каждая задача, вместо того чтобы отправлять всё по одному пути.

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

Планирование задач, типизированные действия и ворота одобрения

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

Четыре типа разрешений напрямую соответствуют уровню риска:

Ворота одобрения блокируют каждое действие exec и external, пока человек его не одобрит. Именно эта модель контроля делает следующий слой интеграций практичным.

Инструменты, интеграции и доступ к моделям через APIMart

Работа с файлами, календарями, Slack и командными системами

OpenWorker подключается к локальным файлам, календарям, Slack и другим командным системам через встроенные инструменты, размещённые интеграции и коннекторы.^[4] Это делает его полезным для автоматизации связанной работы, а не только разовых задач.

Вот как это выглядит на практике. Операционная команда просит OpenWorker подготовить еженедельный отчёт о производительности и поделиться им с командой. Агент читает локальные аналитические выгрузки, собирает отшлифованный документ в общей папке, набрасывает сводку в Slack с ключевыми метриками, а затем останавливается, чтобы запросить одобрение перед отправкой чего-либо за пределы команды.^[4] OpenWorker выполняет координацию. Люди по-прежнему решают, что уходит наружу.

Команды контента и маркетинга могут использовать ту же схему для контент-пакетов. OpenWorker может извлечь исходные исследования из локальных файлов, набросать бриф или блоговый документ и отметить сроки проверки в командном календаре — всё это без обращения к внешним системам, пока кто-то не даст согласие.^[4]

Использование APIMart как единого эндпоинта модели

Когда инструменты подключены, следующий шаг — доступ к моделям. OpenWorker может использовать APIMart как свой единый эндпоинт модели через один OpenAI-совместимый базовый URL.^[2][3]

Настройка довольно проста:

• Создайте API-ключ APIMart
• Отправляйте стандартные OpenAI-совместимые JSON-полезные нагрузки для запросов чата, завершений и медиа

С точки зрения OpenWorker, APIMart выглядит как один стабильный провайдер. Но за этим единым эндпоинтом команды могут переключаться между такими моделями, как GPT-5, Claude Sonnet 4.6 или Gemini 3 Pro Preview, вообще не меняя рабочий процесс агента. Это означает один слой маршрутизации и меньше обслуживания среди используемых командой моделей.

Мультимодальные рабочие процессы для команд контента и медиа

Та же схема маршрутизации также поддерживает мультимодальную работу за пределами текста. С APIMart OpenWorker может пройти путь от исследования к сценарию и генерации видео через один эндпоинт.^[1]

Для команды, производящей еженедельный видеоконтент, OpenWorker может координировать весь конвейер — исследование, написание сценариев, генерацию ассетов и подготовку к проверке, — пока APIMart в фоне занимается выбором модели. Рабочий процесс остаётся тем же. Меняется только модель.

Надёжная работа OpenWorker в продакшене

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

Трассировка, оценки и версионирование промптов

Надёжность в продакшене начинается с видимости каждого шага каждого запуска.

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

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

Контроль рисков и человеческий надзор за чувствительными действиями

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

Для чувствительных действий используйте паттерн исходящих (outbox): агент записывает намеченные действия для проверки перед выполнением.^[5] Это правильный подход для общих систем, где проверка человеком должна происходить до выполнения, а не после того, как ущерб уже нанесён.

Это напрямую связано с типами разрешений exec и external, настроенными ранее — паттерн исходящих управляет финальной передачей для этих более рискованных действий. В более сложных мультиагентных схемах структура папок, построенная вокруг директорий inbox/, outbox/ и workspace/, сохраняет границы данных чистыми, а передачи предсказуемыми.^[5] Каждый агент знает, откуда читать и куда писать, что упрощает аудит конвейера.

Управление затратами и моделями с маршрутизацией APIMart

Как только рабочие процессы запущены, контроль затрат становится операционным требованием.

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

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

Практические сценарии использования и заключение

Исследования, контент-операции и медиа-процессы

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

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

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

Поддержка, операции и автоматизация внутренних операций

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

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

Заключение: что команды могут построить сегодня

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

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

Часто задаваемые вопросы

Кому OpenWorker подходит лучше всего?

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

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

Может ли OpenWorker хранить чувствительные данные локально?

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

С моделями локального развёртывания и файловыми протоколами связи команды могут сохранять строгие границы данных и держать операции внутренними.

Какие задачи командам стоит автоматизировать первыми?

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

Хорошие первые сценарии включают сортировку обращений в поддержку и обработку счетов. Почему именно они сначала? Они могут быстро сократить ручной труд и снизить стоимость обслуживания без масштабной перестройки процессов.

Оттуда команды могут перейти к обработке документов, извлечению данных и генерации контента.