Когда я начал копать, оказалось, что рынок уже формируется. И это хорошая новость. Не потому что «всё занято». А потому что боль реальна и умные люди её видят.
Вот кто решает похожие задачи. Три ветки.
Первая ветка — 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агенты #разработка
Вот кто решает похожие задачи. Три ветки.
Первая ветка — 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, а не через «накидаем код и посмотрим».
Полный текст — в следующем сообщении 👇
Частый вопрос от заказчиков: «Зачем ещё один каркас, если есть готовые агентные фреймворки?» Ответ короткий: мне нужен был рантайм, которому можно доверить реальные действия на машине. С журналом, одобрениями, изоляцией и честной остановкой.
Рассказываю, из чего вырос проект и как он строился: через канон спецификаций и 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
• что будет, если процесс упал посреди записи файла;
• кто разрешил боту выполнить shell-команду;
• где токен, который бот только что «увидел»;
• почему агент сообщил «готово», а файла нет.
Как строился проект. В репозитории есть папка prompt-factory-CANON/OUTPUT: спеки, архитектура, дорожная карта и промпты разработки. Сначала пишется контракт поведения, потом тест на него в tests/, потом код в src/harness/. Значительную часть кода пишут агенты, поэтому рядом лежат AGENTS.md и .cursorrules — правила для людей и агентов одновременно.
Почему DeepSeek. Мне нужна была одна модель, под которую можно честно отладить весь контур: формат вызовов инструментов, reasoning, кэш префикса. Поддержка «любой модели» на старте размазала бы усилия.
Ключевая трудность (инженерная): спецификация, которая не врёт. Когда код пишут агенты, расхождение между каноном и реальностью растёт тихо. Лечится только тем, что каждый контракт закреплён тестом, а не абзацем в документе. Без этого канон превращается в красивую, но устаревшую вики.
Дальше — первая несущая идея: группа как единица изоляции.
#HarnessOS #Элис #PromptFactory #AIразработка
👉 Канал про HarnessOS и Элис: https://t.me/harness_ai_ru
Telegram
Harness для ИИ
Как строить управляемую AI-разработку: harness вокруг LLM, оркестрация, память, проверки. История разработки HarnessOS от Алексея Пасечника.
Когда 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агенты #разработка
Когда 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 у обвязки вокруг модели понятная структура. Есть спецификация, есть проверки, есть приёмка: код, который пишет ИИ-агент, либо проходит дисциплину 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
Логичнее было бы сначала довести одно до конца. Но мой исследовательский интерес всегда был выше запросов рынка. И в этот раз он победил.
В 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
Telegram
Harness для ИИ
Как строить управляемую AI-разработку: harness вокруг LLM, оркестрация, память, проверки. История разработки HarnessOS от Алексея Пасечника.
Группа — единица изоляции
Единица изоляции в Элис — не пользователь, а группа. Отдельные бот-контуры со своим каталогом на диске. Группы не делят ни браузер, ни файлы, ни память, ни бюджет. И правило: в группе одновременно идёт только один активный разговор, остальное — в очередь.
Почему так и что это ломает — в посте.
Полный текст — в следующем сообщении 👇
Единица изоляции в Элис — не пользователь, а группа. Отдельные бот-контуры со своим каталогом на диске. Группы не делят ни браузер, ни файлы, ни память, ни бюджет. И правило: в группе одновременно идёт только один активный разговор, остальное — в очередь.
Почему так и что это ломает — в посте.
Полный текст — в следующем сообщении 👇
Каталог группы — 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
• 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
Telegram
Harness для ИИ
Как строить управляемую AI-разработку: harness вокруг LLM, оркестрация, память, проверки. История разработки HarnessOS от Алексея Пасечника.
Начинать всегда тяжело. Особенно когда строишь новую категорию продукта, а не «ещё один AI-инструмент».
Вот три факапа, которые я собрал в первые дни.
Факап 1. Я думал, что «достаточно умной модели»
Первая версия была наивной: «Возьмём DeepSeek, дадим ему доступ к файлам, и он всё сделает». Реальность: агент писал код, который выглядел правильно. Компилировался. Проходил линтер. А потом ломался на первом нетривиальном сценарии.
Урок: модель — не главное. Главное — обвязка.
Факап 2. Я думал, что «контекст — это просто»
Первая версия совала в промпт весь проект. Или большой кусок. Результат: модель путалась. Ссылалась на файлы, которых не видела. Галлюцинировала.
Урок: контекст — это не «больше», а «точнее». Не «весь проект», а то, что нужно для этой задачи.
Факап 3. Я думал, что «память — это история чата»
Первая версия хранила всё в чате. Закрыл сессию — контекст пропал. Начал новую — начинай с нуля.
Урок: память — это не история, а структура. Что делал. Какие решения принял. Почему. Это не чат. Это база знаний о проекте.
Эти три факапа стоили мне нескольких дней работы. Но они дали главное: понимание, что делать.
Не искать более умную модель. А строить нормальную обвязку.
В следующем посте — что оказалось труднее всего.
#HarnessOS #AIразработка #КакЯСтроилHarnessOS #AIагенты #разработка
Вот три факапа, которые я собрал в первые дни.
Факап 1. Я думал, что «достаточно умной модели»
Первая версия была наивной: «Возьмём DeepSeek, дадим ему доступ к файлам, и он всё сделает». Реальность: агент писал код, который выглядел правильно. Компилировался. Проходил линтер. А потом ломался на первом нетривиальном сценарии.
Урок: модель — не главное. Главное — обвязка.
Факап 2. Я думал, что «контекст — это просто»
Первая версия совала в промпт весь проект. Или большой кусок. Результат: модель путалась. Ссылалась на файлы, которых не видела. Галлюцинировала.
Урок: контекст — это не «больше», а «точнее». Не «весь проект», а то, что нужно для этой задачи.
Факап 3. Я думал, что «память — это история чата»
Первая версия хранила всё в чате. Закрыл сессию — контекст пропал. Начал новую — начинай с нуля.
Урок: память — это не история, а структура. Что делал. Какие решения принял. Почему. Это не чат. Это база знаний о проекте.
Эти три факапа стоили мне нескольких дней работы. Но они дали главное: понимание, что делать.
Не искать более умную модель. А строить нормальную обвязку.
В следующем посте — что оказалось труднее всего.
#HarnessOS #AIразработка #КакЯСтроилHarnessOS #AIагенты #разработка
Журнал событий: сначала сохрани — потом сообщи
Сердце Элис — журнал событий, единственная правда системы. Каждый факт — отдельный файл на диске: сообщение оператора, вызов инструмента, наблюдение, одобрение, конец разговора.
Правило: событие сначала записано и сброшено на накопитель (fsync), и только потом его получают подписчики — UI, дашборд, проекции.
Полный текст — в следующем сообщении 👇
Сердце Элис — журнал событий, единственная правда системы. Каждый факт — отдельный файл на диске: сообщение оператора, вызов инструмента, наблюдение, одобрение, конец разговора.
Правило: событие сначала записано и сброшено на накопитель (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
Что строится поверх журнала:
• 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
Telegram
Harness для ИИ
Как строить управляемую AI-разработку: harness вокруг LLM, оркестрация, память, проверки. История разработки HarnessOS от Алексея Пасечника.
Из всего, что я делал, самым сложным оказалась не оркестрация агентов. И не инфраструктура. И даже не память.
Самым сложным оказалась приёмка результата.
Вот в чём проблема. Агент говорит «готово». Ты смотришь — вроде работает. Тесты зелёные. Линтер чист. Компилируется.
А потом выясняется: не то. Не то, что ты хотел. Или работает не так. Или сломало что-то, чего ты не заметил.
«Тесты прошли» ≠ «задача решена».
Это Verification Tax в чистом виде. Ты экономишь час на написании — и тратишь полтора, а то и два на то, чтобы понять, что именно сделано и правильно ли это.
И здесь я упёрся в фундаментальную проблему.
Нельзя проверить корректность только техническими средствами. Тесты проверяют то, что написано в тестах. А не то, что ты хотел.
Решение пришло не сразу.
Ключевая идея: приёмка должна быть трёхуровневой.
• Первый уровень — машина. Автоматические проверки. Тесты. Линтер. Типы. Сборка.
• Второй уровень — запись. Не «мы проверили», а файл, в котором написано, что проверялось, какой получен результат и какие критерии покрыты.
• Третий уровень — человек. Явное «да». Не «агент решил, что готово», а человек посмотрел и согласился.
Только все три вместе дают нормальную приёмку.
Это не серебряная пуля. Это способ сделать Verification Tax управляемым.
В следующем посте — три самые сложные задачи, которые пришлось решать по дороге.
#HarnessOS #AIразработка #КакЯСтроилHarnessOS #AIагенты #разработка
Самым сложным оказалась приёмка результата.
Вот в чём проблема. Агент говорит «готово». Ты смотришь — вроде работает. Тесты зелёные. Линтер чист. Компилируется.
А потом выясняется: не то. Не то, что ты хотел. Или работает не так. Или сломало что-то, чего ты не заметил.
«Тесты прошли» ≠ «задача решена».
Это Verification Tax в чистом виде. Ты экономишь час на написании — и тратишь полтора, а то и два на то, чтобы понять, что именно сделано и правильно ли это.
И здесь я упёрся в фундаментальную проблему.
Нельзя проверить корректность только техническими средствами. Тесты проверяют то, что написано в тестах. А не то, что ты хотел.
Решение пришло не сразу.
Ключевая идея: приёмка должна быть трёхуровневой.
• Первый уровень — машина. Автоматические проверки. Тесты. Линтер. Типы. Сборка.
• Второй уровень — запись. Не «мы проверили», а файл, в котором написано, что проверялось, какой получен результат и какие критерии покрыты.
• Третий уровень — человек. Явное «да». Не «агент решил, что готово», а человек посмотрел и согласился.
Только все три вместе дают нормальную приёмку.
Это не серебряная пуля. Это способ сделать Verification Tax управляемым.
В следующем посте — три самые сложные задачи, которые пришлось решать по дороге.
#HarnessOS #AIразработка #КакЯСтроилHarnessOS #AIагенты #разработка
Outbox: коробка недоделанных побочных эффектов
Агент решил отправить задачу другой группе или записать файл, и тут процесс упал. Сделалось действие или нет? В Элис на это отвечает outbox — «коробка недоделанных побочных эффектов».
Как это устроено и почему идемпотентность здесь важнее скорости.
Полный текст — в следующем сообщении 👇
Агент решил отправить задачу другой группе или записать файл, и тут процесс упал. Сделалось действие или нет? В Элис на это отвечает outbox — «коробка недоделанных побочных эффектов».
Как это устроено и почему идемпотентность здесь важнее скорости.
Полный текст — в следующем сообщении 👇
Идея. Действие, которое меняет мир, сначала кладёт в state.db запись «надо сделать». Потом выполняется. Потом запись закрывается. После рестарта система первым делом разбирает pending: доделывает или честно закрывает.
Что даёт:
• не теряются действия, которые агент «обещал» сделать;
• действия не выполняются дважды вслепую;
• видно, на каком шаге оборвалось.
Связь с журналом. Outbox живёт в state.db, а state.db — проекция журнала. Поэтому намерение и результат видны и в аудите, и при replay.
Связь со стартом задачи. Восстановление outbox — обязательный шаг запуска, до того как группа возьмёт новую работу. Нельзя начинать новое, не разобравшись с хвостами старого.
Ключевая трудность (инженерная): не все действия идемпотентны. Записать файл тем же содержимым можно ещё раз. Передать задачу на другой хост или отправить что-то наружу — нет: повтор создаёт дубль. У каждого типа эффекта должна быть своя стратегия: повторить, сверить с внешней стороной по ключу или закрыть как невыполненное и сказать об этом. Универсального «retry» тут нет, и честнее закрыть pending с причиной, чем молча задвоить.
Дальше — как стартует задача: от команды до первого вызова модели.
#HarnessOS #Элис #outbox #надёжность
👉 Канал про HarnessOS и Элис: https://t.me/harness_ai_ru
Что даёт:
• не теряются действия, которые агент «обещал» сделать;
• действия не выполняются дважды вслепую;
• видно, на каком шаге оборвалось.
Связь с журналом. Outbox живёт в state.db, а state.db — проекция журнала. Поэтому намерение и результат видны и в аудите, и при replay.
Связь со стартом задачи. Восстановление outbox — обязательный шаг запуска, до того как группа возьмёт новую работу. Нельзя начинать новое, не разобравшись с хвостами старого.
Ключевая трудность (инженерная): не все действия идемпотентны. Записать файл тем же содержимым можно ещё раз. Передать задачу на другой хост или отправить что-то наружу — нет: повтор создаёт дубль. У каждого типа эффекта должна быть своя стратегия: повторить, сверить с внешней стороной по ключу или закрыть как невыполненное и сказать об этом. Универсального «retry» тут нет, и честнее закрыть pending с причиной, чем молча задвоить.
Дальше — как стартует задача: от команды до первого вызова модели.
#HarnessOS #Элис #outbox #надёжность
👉 Канал про HarnessOS и Элис: https://t.me/harness_ai_ru
Telegram
Harness для ИИ
Как строить управляемую AI-разработку: harness вокруг LLM, оркестрация, память, проверки. История разработки HarnessOS от Алексея Пасечника.
Каждый из сложных аспектов harness’а я решал отдельно. Не пытался сделать всё сразу.
Вот три задачи, которые оказались самыми сложными. И как я их решал — без деталей реализации.
Задача 1. Как не терять работу при сбоях
Представь: агент делает задачу из 10 шагов. Сделал 6. Упал сервер.
Наивное решение — начать заново. Минус: теряется время, сжигаются токены.
Что я сделал: каждое действие агента записывается. Не в оперативную память, а в постоянное хранилище. Когда агент запускается снова, он читает эту запись и понимает, где остановился.
Это называется resume. Работа не теряется. Продолжаем с того же места.
Задача 2. Как откатывать плохие шаги
Представь: агент сделал шаг, и что-то сломалось. Он понял, что сделал неправильно.
Наивное решение — чинить руками. Минус: долго, рискованно, можно сломать ещё больше.
Что я сделал: после каждого шага агента сохраняется снимок состояния. Если шаг плохой, берём предыдущий снимок. Всё, что было после, отменяется.
Это называется rollback. Не надо чинить руками. Откатил — и работаешь с чистой точки.
Задача 3. Как не создавать дубли
Представь: агент отправил команду «создать заказ». Но ответ не пришёл — сеть моргнула. Агент не знает, создался заказ или нет.
Наивное решение — повторить. Минус: создастся второй заказ.
Что я сделал: к каждой команде прикрепляется уникальный ключ. Система помнит ключи. Если приходит команда с тем же ключом, она не выполняется повторно.
Это называется идемпотентностью (idempotency). Повторная попытка не ломает систему.
Все три задачи — про надёжность. Про то, что может пойти не так. И про то, чтобы система не рассыпалась от первой же проблемы.
В последнем посте серии — что я понял за это время.
#HarnessOS #AIразработка #КакЯСтроилHarnessOS #AIагенты #разработка
Вот три задачи, которые оказались самыми сложными. И как я их решал — без деталей реализации.
Задача 1. Как не терять работу при сбоях
Представь: агент делает задачу из 10 шагов. Сделал 6. Упал сервер.
Наивное решение — начать заново. Минус: теряется время, сжигаются токены.
Что я сделал: каждое действие агента записывается. Не в оперативную память, а в постоянное хранилище. Когда агент запускается снова, он читает эту запись и понимает, где остановился.
Это называется resume. Работа не теряется. Продолжаем с того же места.
Задача 2. Как откатывать плохие шаги
Представь: агент сделал шаг, и что-то сломалось. Он понял, что сделал неправильно.
Наивное решение — чинить руками. Минус: долго, рискованно, можно сломать ещё больше.
Что я сделал: после каждого шага агента сохраняется снимок состояния. Если шаг плохой, берём предыдущий снимок. Всё, что было после, отменяется.
Это называется rollback. Не надо чинить руками. Откатил — и работаешь с чистой точки.
Задача 3. Как не создавать дубли
Представь: агент отправил команду «создать заказ». Но ответ не пришёл — сеть моргнула. Агент не знает, создался заказ или нет.
Наивное решение — повторить. Минус: создастся второй заказ.
Что я сделал: к каждой команде прикрепляется уникальный ключ. Система помнит ключи. Если приходит команда с тем же ключом, она не выполняется повторно.
Это называется идемпотентностью (idempotency). Повторная попытка не ломает систему.
Все три задачи — про надёжность. Про то, что может пойти не так. И про то, чтобы система не рассыпалась от первой же проблемы.
В последнем посте серии — что я понял за это время.
#HarnessOS #AIразработка #КакЯСтроилHarnessOS #AIагенты #разработка
Как стартует задача: от команды до первого токена
Что происходит между «оператор нажал Enter» и «модель начала думать»? В Элис это девять шагов, и у каждого своя причина существовать.
Разбираю путь: вход → транспорт → замок → outbox → журнал → классификатор → промпт → цикл → честный конец.
Полный текст — в следующем сообщении 👇
Что происходит между «оператор нажал Enter» и «модель начала думать»? В Элис это девять шагов, и у каждого своя причина существовать.
Разбираю путь: вход → транспорт → замок → outbox → журнал → классификатор → промпт → цикл → честный конец.
Полный текст — в следующем сообщении 👇