Прежде чем рассказывать про HarnessOS, надо рассказать про то, что было до него.

Несколько лет я работал над сложными проектами. И всё время упирался в одну проблему: AI генерирует код быстрее, чем я успеваю его проверять.

Это называют Verification Tax — налог на проверку.

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

Тогда я начал строить Prompt Factory. Не фреймворк. Не библиотеку. Методологию и инструмент дисциплины.

Идея простая: сначала договориться, потом делать.

Вместо «сделай мне фичу» — сначала зафиксировать, что именно строится, зачем, какие границы и как это проверить. Только после этого — код.

Prompt Factory делает три вещи:

• Декомпозирует. Большая задача режется на тонкие куски. Каждый можно проверить отдельно.
• Описывает. Каждый кусок получает спецификацию: что должно быть, чего быть не должно, как проверить.
• Генерирует. Из спецификации появляется задание для агента. С чёткими критериями приёмки.

Я назвал это дисциплиной. Потому что суть не в инструменте. Суть в том, что система не даёт сделать иначе.

Prompt Factory прошёл проверку на реальных проектах — xChangePro и WebCraftly. Не на демо. Это важно.

Но у него был один недостаток. Он не умел работать с существующими проектами. Только с новыми, с нуля.

Это и стало отправной точкой для HarnessOS.

В следующем посте — что уже есть на рынке и кто решает похожие задачи.

#HarnessOS #AIразработка #КакЯСтроилHarnessOS #AIагенты #разработка

Элис: каркас для групп ботов — от своей машины к облаку

Запускаю новую серию — про Элис (HarnessBot). Это мой второй большой проект после HarnessOS: каркас для групп ботов на DeepSeek. Сегодня он работает локально или на выделенной машине, в планах — облачный сервис. Это не замена IDE. Оператор даёт задачу, бот думает и вызывает инструменты, а всё важное пишется на диск, чтобы после сбоя можно было продолжить.

За 20 постов разберу, как он устроен, зачем каждый кусок и где было по-настоящему трудно. Пишу для тех, кто сам строит агентов.

Полный текст — в следующем сообщении 👇

Сначала о том, что такое Элис. Это рантайм, в котором живут группы ботов. У каждой группы своя рабочая папка, свой журнал событий, своя база проекций, свой браузер и свои секреты. Оператор работает через CLI или веб-панель Mission Control.


Что система делает:
• ведёт полный журнал всего, что произошло: файлы событий, а не «память в голове процесса»;
• гоняет цикл «модель → инструменты → снова модель»;
• спрашивает человека перед опасным действием: запись файлов, shell, навигация, генерация медиа;
• переигрывает историю без повторных побочных эффектов;
• передаёт задачу другой группе, в том числе на другой хост;
• считает токены, деньги и время и останавливается честно, а не «замолкает».

Куда движется. Сейчас Элис запускается локально или на отдельной машине. Следующий шаг — облачный сервис. Архитектура под это заложена с самого начала: удалённый HTTP-транспорт, федерация хостов, изоляция каждой группы, брокер секретов, B2B-лицензия. Чем Элис не является: это не замена IDE, не Kubernetes-mesh и не обучение своих моделей. Ставка — на надёжность самого harness.

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

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

#HarnessOS #Элис #AIагенты #LLM #DeepSeek

👉 Канал про HarnessOS и Элис: https://t.me/harness_ai_ru

Аналоги: что уже есть на рынке

Как я строил HarnessOS · 5/10

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

Полный текст — в следующем сообщении 👇

Когда я начал копать, оказалось, что рынок уже формируется. И это хорошая новость. Не потому что «всё занято». А потому что боль реальна и умные люди её видят.

Вот кто решает похожие задачи. Три ветки.

Первая ветка — Spec-Driven Development

Инструменты, которые заставляют работать по спецификациям. Сначала договориться — потом делать.

OpenSpec. GitHub Spec Kit. Kiro от AWS. У каждого свой подход. Но суть одна: спецификация — источник правды, код — производное.

Что они делают: дают дисциплину спецификаций.

Чего у них нет: они не runtime. Они дают структуру. Исполнять её ты должен сам.

Вторая ветка — Agent Harness

Инструменты, которые исполняют задачи. Runtime для агентов.

DeepSeek Harness. OpenHarness. OpenHands. Мощные. Расширяемые.

Что они делают: дают двигатель.

Чего у них нет: они не заставляют работать по спецификации. Это мощные двигатели, но без процессной дисциплины.

Третья ветка — Memory-слой

Компоненты для памяти агентов.

mem0. Zep и его Graphiti. Каждый решает свою часть.

Что они делают: дают память.

Чего у них нет: они не управляют процессом. Память — это компонент, а не control plane.

И вот ключевое наблюдение.

Уже появились плагины и надстройки, которые пытаются склеить первые две ветки: спецификации и runtime. Например, specpowers и dsh-spec-loop для DeepSeek Harness, а также community-надстройки над OpenSpec для работы с несколькими агентами.

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

Но это плагины. Надстройки над чужим runtime. И это принципиально.

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

#HarnessOS #AIразработка #КакЯСтроилHarnessOS #AIагенты #разработка

Почему я начал Элис после HarnessOS

Частый вопрос от заказчиков: «Зачем ещё один каркас, если есть готовые агентные фреймворки?» Ответ короткий: мне нужен был рантайм, которому можно доверить реальные действия на машине. С журналом, одобрениями, изоляцией и честной остановкой.

Рассказываю, из чего вырос проект и как он строился: через канон спецификаций и Prompt Factory, а не через «накидаем код и посмотрим».

Полный текст — в следующем сообщении 👇

Большинство агентных библиотек оптимизированы под демо: цикл с моделью, пара инструментов, красивый вывод. В реальной работе быстро вылезают неудобные вопросы:
• что будет, если процесс упал посреди записи файла;
• кто разрешил боту выполнить shell-команду;
• где токен, который бот только что «увидел»;
• почему агент сообщил «готово», а файла нет.
Как строился проект. В репозитории есть папка prompt-factory-CANON/OUTPUT: спеки, архитектура, дорожная карта и промпты разработки. Сначала пишется контракт поведения, потом тест на него в tests/, потом код в src/harness/. Значительную часть кода пишут агенты, поэтому рядом лежат AGENTS.md и .cursorrules — правила для людей и агентов одновременно.
Почему DeepSeek. Мне нужна была одна модель, под которую можно честно отладить весь контур: формат вызовов инструментов, reasoning, кэш префикса. Поддержка «любой модели» на старте размазала бы усилия.
Ключевая трудность (инженерная): спецификация, которая не врёт. Когда код пишут агенты, расхождение между каноном и реальностью растёт тихо. Лечится только тем, что каждый контракт закреплён тестом, а не абзацем в документе. Без этого канон превращается в красивую, но устаревшую вики.
Дальше — первая несущая идея: группа как единица изоляции.
#HarnessOS #Элис #PromptFactory #AIразработка
👉 Канал про HarnessOS и Элис: https://t.me/harness_ai_ru

Почему я решил, что я на правильной стороне рынка

Как я строил HarnessOS · 6/10

DeepSeek, GitHub, AWS и сообщество. Почему я считаю, что выбрал правильную нишу.

Полный текст — в следующем сообщении 👇

Когда DeepSeek выпускает Harness — это сигнал. Крупный игрок видит ту же боль, что и я. Значит, проблема реальна.

Когда GitHub выпускает Spec Kit, а AWS — Kiro, это второй сигнал. Гиганты не вкладываются в то, что никому не нужно.

Третий сигнал приходит уже не от крупных игроков, а от сообщества: появляются плагины вроде specpowers. Люди хотят соединить SDD и harness. Но делают это своими руками, потому что готового решения не находят.

Я не изобретаю проблему. Я отвечаю на реальный спрос.

Разница в том, что именно я строю. DeepSeek Harness — двигатель. OpenSpec — слой дисциплины. Плагины — склейка.

HarnessOS — control plane. Не «двигатель плюс слой». А система, которая держит процесс целиком: план, роли, проверки, память, лимиты, эскалация.

И вот что ещё важно. Все три ветки фрагментированы: каждая закрывает свой кусок.

• DeepSeek Harness — открытый (MIT) и запускается локально, но это runtime: дисциплину спецификаций к нему приходится добавлять плагинами.
• OpenSpec — слой дисциплины, но не runtime.
• Плагины — работают, но зависят от чужого runtime, который пока в стадии developer preview.

Self-hosted control plane, который соединяет всё это вместе, я не нашёл.

Это и есть моя ниша. Не «сделать лучше». А собрать то, чего я не нашёл на рынке.

Два сигнала от крупных игроков и один от сообщества — это не «всё занято». Это «проблема подтверждена».

В следующем посте — с каких факапов я начинал.

#HarnessOS #AIразработка #КакЯСтроилHarnessOS #AIагенты #разработка

Я не закончил HarnessOS. И начал Элис AI

HarnessOS ещё в работе, а я уже взялся за Элис AI. Почему исследовательский интерес оказался сильнее запросов рынка и как обуздать модель — в следующем сообщении 👇

Честно: HarnessOS ещё в работе. И при этом я взялся за новый проект — Элис AI.

Логичнее было бы сначала довести одно до конца. Но мой исследовательский интерес всегда был выше запросов рынка. И в этот раз он победил.

В HarnessOS у обвязки вокруг модели понятная структура. Есть спецификация, есть проверки, есть приёмка: код, который пишет ИИ-агент, либо проходит дисциплину Prompt Factory, либо нет. Всё предсказуемо.

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

Эта разница не давала мне спать спокойно. Я понял: это направление нужно изучать срочно, а не «когда-нибудь потом».

Главный вопрос — как обуздать модель?

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

Я всегда был бойцом. И в этот бой я не мог не вступить.

HarnessOS я не бросаю: опыт Элис вернётся в него новыми проверками. А как идёт эта гонка — буду рассказывать здесь.

А вы бросаете начатое ради задачи, которая не отпускает? Или сначала доводите до конца?

#HarnessOS #Элис #AIагенты #LLM

👉 Канал про HarnessOS и Элис: https://t.me/harness_ai_ru
📝 Мой блог: https://blog.arhellist.ru/blog/ya-ne-zakonchil-harnessos-i-nachal-elis-ai

Группа — единица изоляции

Единица изоляции в Элис — не пользователь, а группа. Отдельные бот-контуры со своим каталогом на диске. Группы не делят ни браузер, ни файлы, ни память, ни бюджет. И правило: в группе одновременно идёт только один активный разговор, остальное — в очередь.

Почему так и что это ломает — в посте.

Полный текст — в следующем сообщении 👇

Каталог группы — data/groups/<имя>/. Внутри:
• workspace — песочница, «тюрьма путей»;
• events — журнал, каждый факт — отдельный файл;
• state.db — очередь, гранты, outbox, todos; это не источник правды, она пересобирается из журнала;
• chrome-profile — свой профиль браузера;
• memory.db — память группы;
• audit.log — цепочка решений человека;
• skills/ и agents/ — навыки и субагенты;
• roles.yaml — какая модель на какую роль: зрение, OCR, генерация;
• allowed_domains — куда браузеру можно.

Замок «один активный разговор». Новая задача, пока идёт текущая, встаёт в очередь или получает честный отказ «занято». Параллель — только если явно включён такой режим. Так в каждый момент один «мозг» владеет файлами и браузером группы.

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

Ключевая трудность (инженерная): замок, который переживает падение. Процесс умер, держа замок, — группа «зависла». Снимать замок по таймауту агрессивно — два разговора пишут в одну папку. Нужно отличать «владелец долго думает» от «владельца больше нет» и не потерять очередь. Помогает то, что state.db — производная от журнала: очередь и outbox можно восстановить, а не угадывать.

Дальше — журнал событий и правило «сначала сохрани, потом сообщи».

#HarnessOS #Элис #AIагенты #архитектура

👉 Канал про HarnessOS и Элис: https://t.me/harness_ai_ru

Первые факапы

Как я строил HarnessOS · 7/10

Три факапа первых дней: умная модель, контекст и память. И что они мне дали.

Полный текст — в следующем сообщении 👇

Начинать всегда тяжело. Особенно когда строишь новую категорию продукта, а не «ещё один AI-инструмент».

Вот три факапа, которые я собрал в первые дни.

Факап 1. Я думал, что «достаточно умной модели»

Первая версия была наивной: «Возьмём DeepSeek, дадим ему доступ к файлам, и он всё сделает». Реальность: агент писал код, который выглядел правильно. Компилировался. Проходил линтер. А потом ломался на первом нетривиальном сценарии.

Урок: модель — не главное. Главное — обвязка.

Факап 2. Я думал, что «контекст — это просто»

Первая версия совала в промпт весь проект. Или большой кусок. Результат: модель путалась. Ссылалась на файлы, которых не видела. Галлюцинировала.

Урок: контекст — это не «больше», а «точнее». Не «весь проект», а то, что нужно для этой задачи.

Факап 3. Я думал, что «память — это история чата»

Первая версия хранила всё в чате. Закрыл сессию — контекст пропал. Начал новую — начинай с нуля.

Урок: память — это не история, а структура. Что делал. Какие решения принял. Почему. Это не чат. Это база знаний о проекте.

Эти три факапа стоили мне нескольких дней работы. Но они дали главное: понимание, что делать.

Не искать более умную модель. А строить нормальную обвязку.

В следующем посте — что оказалось труднее всего.

#HarnessOS #AIразработка #КакЯСтроилHarnessOS #AIагенты #разработка

Журнал событий: сначала сохрани — потом сообщи

Сердце Элис — журнал событий, единственная правда системы. Каждый факт — отдельный файл на диске: сообщение оператора, вызов инструмента, наблюдение, одобрение, конец разговора.

Правило: событие сначала записано и сброшено на накопитель (fsync), и только потом его получают подписчики — UI, дашборд, проекции.

Полный текст — в следующем сообщении 👇

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

Что строится поверх журнала:
• state.db — проекция: очередь, гранты, outbox, todos; пересобирается из журнала;
• лента разговора и дашборд в Mission Control — тоже проекции;
• снимки — ускорители, хранятся последние несколько;
• архив закрытых разговоров — через CLI;
• replay — переигровка без живой модели.

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

Ключевая трудность (инженерная): порядок fsync и подписчиков. Сообщить UI о событии до того, как оно на накопителе, и упасть — оператор видел то, чего «не было». Делать fsync на каждое событие — платишь отзывчивостью. Приходится жёстко держать порядок: запись → fsync → рассылка, и следить, чтобы ни один код не «срезал угол» и не слал событие подписчикам напрямую. Вторая боль — проекции: state.db должна догонять журнал, а не наоборот, иначе правд становится две.

Дальше — outbox, «коробка недоделанных побочных эффектов».

#HarnessOS #Элис #eventsourcing #AIагенты

👉 Канал про HarnessOS и Элис: https://t.me/harness_ai_ru

Что оказалось труднее всего

Как я строил HarnessOS · 8/10

Самым сложным оказалась не оркестрация и не инфраструктура, а приёмка результата. «Тесты прошли» ≠ «задача решена».

Полный текст — в следующем сообщении 👇

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

Самым сложным оказалась приёмка результата.

Вот в чём проблема. Агент говорит «готово». Ты смотришь — вроде работает. Тесты зелёные. Линтер чист. Компилируется.

А потом выясняется: не то. Не то, что ты хотел. Или работает не так. Или сломало что-то, чего ты не заметил.

«Тесты прошли» ≠ «задача решена».

Это Verification Tax в чистом виде. Ты экономишь час на написании — и тратишь полтора, а то и два на то, чтобы понять, что именно сделано и правильно ли это.

И здесь я упёрся в фундаментальную проблему.

Нельзя проверить корректность только техническими средствами. Тесты проверяют то, что написано в тестах. А не то, что ты хотел.

Решение пришло не сразу.

Ключевая идея: приёмка должна быть трёхуровневой.

• Первый уровень — машина. Автоматические проверки. Тесты. Линтер. Типы. Сборка.
• Второй уровень — запись. Не «мы проверили», а файл, в котором написано, что проверялось, какой получен результат и какие критерии покрыты.
• Третий уровень — человек. Явное «да». Не «агент решил, что готово», а человек посмотрел и согласился.

Только все три вместе дают нормальную приёмку.

Это не серебряная пуля. Это способ сделать Verification Tax управляемым.

В следующем посте — три самые сложные задачи, которые пришлось решать по дороге.

#HarnessOS #AIразработка #КакЯСтроилHarnessOS #AIагенты #разработка

Outbox: коробка недоделанных побочных эффектов

Агент решил отправить задачу другой группе или записать файл, и тут процесс упал. Сделалось действие или нет? В Элис на это отвечает outbox — «коробка недоделанных побочных эффектов».

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

Полный текст — в следующем сообщении 👇

Идея. Действие, которое меняет мир, сначала кладёт в state.db запись «надо сделать». Потом выполняется. Потом запись закрывается. После рестарта система первым делом разбирает pending: доделывает или честно закрывает.

Что даёт:
• не теряются действия, которые агент «обещал» сделать;
• действия не выполняются дважды вслепую;
• видно, на каком шаге оборвалось.

Связь с журналом. Outbox живёт в state.db, а state.db — проекция журнала. Поэтому намерение и результат видны и в аудите, и при replay.

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

Ключевая трудность (инженерная): не все действия идемпотентны. Записать файл тем же содержимым можно ещё раз. Передать задачу на другой хост или отправить что-то наружу — нет: повтор создаёт дубль. У каждого типа эффекта должна быть своя стратегия: повторить, сверить с внешней стороной по ключу или закрыть как невыполненное и сказать об этом. Универсального «retry» тут нет, и честнее закрыть pending с причиной, чем молча задвоить.

Дальше — как стартует задача: от команды до первого вызова модели.

#HarnessOS #Элис #outbox #надёжность

👉 Канал про HarnessOS и Элис: https://t.me/harness_ai_ru