Я заметила странную вещь: за последние пару лет мы привыкли, что «ИИ-агент» живет в отдельном чате. Ты заходишь в веб-интерфейс, описываешь задачу, получаешь ответ - и дальше руками тащишь результат туда, где работа реально происходит: в Slack, Notion, Jira, репозиторий, таск-трекер.
И вот тут мне зашел подход OpenWorker от Andrew Ng. Это не еще один чат-бот, а попытка сделать десктопного ИИ-сотрудника, который живет на вашей машине, подключается к вашим инструментам и возвращает проверяемый результат, а не бесконечную переписку.
Главное: агент должен работать там, где живет контекст
OpenWorker - это local-first приложение. Агент запускается на вашем компьютере и работает «внутри» вашей среды: файлы, терминал, рабочие приложения, коннекторы. Это выглядит как сдвиг от модели «помощник в отдельном окне» к модели «сотрудник, встроенный в процесс».
И мне важно не то, что он умеет «умно отвечать». Мне важно, что он заточен под то, чтобы:
- собрать данные из источников (репо, тикеты, календарь, почта),
- нормально оформить результат (таблица, заметка, сводка, черновик),
- встроить результат обратно в рабочий поток.
Пример, который сразу понятен команде: Slack и GitHub
Представьте обычную сцену в проектном канале Slack:
«Какие открытые issues по нашему репозиторию появились за последние 3 дня?»
В привычном мире дальше начинается многорукий Шива: открыть браузер, зайти в GitHub, накрутить фильтры, скопировать ссылки, собрать список, вернуть в тред.
В модели OpenWorker вы упоминаете @OpenWorker в Slack и формулируете задачу. Агент (который запущен на вашем десктопе) делает то, что сделал бы человек с доступом к инструментам: лезет в GitHub, собирает список, форматирует ответ и возвращает его в тред.
Главное: ценность здесь не «вау, он отвечает», а минус одно переключение контекста и минус один ручной перенос данных.
Архитектура, которая мне кажется практичной: десктоп + локальный сервер
По описанию проекта, OpenWorker - это нативное десктопное приложение с GUI, а «сердце» - локальный агентный сервер на Python (в репозитории упоминаются aisuite и коннекторная архитектура).
На практике это означает:
- агент может работать с локальными файлами и терминалом
- подключается к внешним системам через набор коннекторов (GitHub/Slack/Jira/Notion/Linear/HubSpot/Outlook/Gmail/Google Calendar и т.д.)
- LLM можно выбирать: облачные провайдеры или (что особенно важно) локальные модели, например через Ollama.
Мне как человеку, который строит production-интеграции, это звучит как нормальная инженерная логика: контекст не выносится в «еще один чат», а остается там, где он и так живет.
Почему «local-first агент» - не игрушка, а бизнес-аргумент
Вот три пункта, которые для меня в таких системах обычно решают, взлетит оно в компании или останется демкой:
- Приватность и безопасность (local-first)
Если история запусков, токены коннекторов, ключи LLM и промежуточные результаты хранятся локально, это резко упрощает жизнь там, где безопасность - не формальность. Особенно в средах, где «вынести контекст в облако» сложно юридически или организационно.
- Человек в цикле и гейты подтверждений
Мне нравится сама идея: любые действия с последствиями (запись файлов, отправка сообщений, выполнение команд) должны требовать подтверждения. Это делает поведение агента не «магией», а управляемым процессом.
- Свобода модели
Не застревать на одном провайдере - критично. Сегодня у вас одна модель «самая адекватная», завтра - другая. Возможность переключаться и/или уходить в локальные модели - это страховка от зависимости.
Применить у себя
Что я бы проверила руками (и вам советую)
Если хочется понять, «встроится» ли такой агент в ваш процесс, не надо оценивать стиль ответов. Надо оценивать сколько ручных действий он действительно снимает.
Три сценария для короткого теста:
- Ежедневная сводка почты в Notion
Подключить Gmail/Outlook и Notion. Попросить агента каждое утро делать сводку писем за вчера: главные темы, кто от кого ждет ответа, что требует действия. Посмотреть, насколько хорошо он выделяет главное и как структурирует.
- Slack + GitHub: «что горит» по репо
В проектном канале попросить: «Собери открытые issues/PR за неделю, сгруппируй по лейблам/компонентам и отметь, где нет владельца». Проверить, как он форматирует выдачу и насколько реально это экономит время.
- Локальная работа с файлами через Ollama
Поднять Ollama, подключить локальную модель, дать задачу: «Пройди по папке, найди все упоминания термина X, собери отчет и сохрани в отдельный файл». Важно: убедиться, что это реально делается локально и вы контролируете действия.
Мой критерий успеха
Я бы не мерила «насколько агент похож на человека». Для меня критерий проще:
- сколько раз вы перестали копировать данные из одного окна в другое
- насколько действия агента проверяемы (логи, шаги, подтверждения)
- можно ли встроить его в регулярные процессы, не превращая все в хаос.
Если после недели использования вы поймали себя на мысли «я перестала быть курьером между Slack и GitHub/Notion» - значит, подход работает.