Начну с главного.
Когда люди говорят «я использую AI для разработки», они обычно имеют в виду одно из двух.
Первое: «Я пишу промпт в чат, копирую код, вставляю в редактор». Это не harness. Это использование LLM как очень умного автокомплита.
Второе: «У меня есть агент, который сам читает файлы, пишет код, запускает тесты». Вот это уже ближе. Но и это ещё не harness.
Harness — это всё, что находится вокруг модели. Модель — это процессор. Harness — это операционная система.
Аналогия, которая мне нравится больше всего: если модель — это двигатель, то harness — это машина целиком. Рама, колёса, руль, тормоза, бензобак. Сам по себе двигатель крутится, но никуда не едет.
Что делает harness:
• Решает, что модель увидит. Не «весь проект», а конкретный кусок, релевантный задаче.
• Решает, что модель может делать. Не «всё», а конкретный набор инструментов с ограничениями.
• Решает, как проверить результат. Не «модель сказала „готово“», а «вот объективные проверки».
• Решает, когда остановиться. Не «пробуем до бесконечности», а «после N попыток зовём человека».
• Помнит, что было. Не «контекст чата», а структурированная память о проекте.
Без harness модель — это талантливый, но безответственный сотрудник. Он быстро пишет код, который выглядит правильно. А потом этот код ломается на первом нетривиальном сценарии.
С harness это управляемый процесс. Медленнее на одном шаге. Быстрее на дистанции.
Именно поэтому я начал строить HarnessOS. Не потому что «хочу свой AI-инструмент». А потому что понял: проблема не в модели. Проблема в том, что вокруг неё нет нормальной обвязки.
В следующем посте — из каких слоёв обычно состоит harness.
#HarnessOS #AIразработка #КакЯСтроилHarnessOS #AIагенты #разработка
Когда люди говорят «я использую AI для разработки», они обычно имеют в виду одно из двух.
Первое: «Я пишу промпт в чат, копирую код, вставляю в редактор». Это не harness. Это использование LLM как очень умного автокомплита.
Второе: «У меня есть агент, который сам читает файлы, пишет код, запускает тесты». Вот это уже ближе. Но и это ещё не harness.
Harness — это всё, что находится вокруг модели. Модель — это процессор. Harness — это операционная система.
Аналогия, которая мне нравится больше всего: если модель — это двигатель, то harness — это машина целиком. Рама, колёса, руль, тормоза, бензобак. Сам по себе двигатель крутится, но никуда не едет.
Что делает harness:
• Решает, что модель увидит. Не «весь проект», а конкретный кусок, релевантный задаче.
• Решает, что модель может делать. Не «всё», а конкретный набор инструментов с ограничениями.
• Решает, как проверить результат. Не «модель сказала „готово“», а «вот объективные проверки».
• Решает, когда остановиться. Не «пробуем до бесконечности», а «после N попыток зовём человека».
• Помнит, что было. Не «контекст чата», а структурированная память о проекте.
Без harness модель — это талантливый, но безответственный сотрудник. Он быстро пишет код, который выглядит правильно. А потом этот код ломается на первом нетривиальном сценарии.
С harness это управляемый процесс. Медленнее на одном шаге. Быстрее на дистанции.
Именно поэтому я начал строить HarnessOS. Не потому что «хочу свой AI-инструмент». А потому что понял: проблема не в модели. Проблема в том, что вокруг неё нет нормальной обвязки.
В следующем посте — из каких слоёв обычно состоит harness.
#HarnessOS #AIразработка #КакЯСтроилHarnessOS #AIагенты #разработка
Есть хорошая новость: harness’ы устроены похоже. Даже если их делают разные люди для разных задач.
Я разобрал несколько открытых harness’ов — от простых до продакшн-уровня. И увидел четыре слоя, которые есть почти везде.
Слой 1. Оркестрация
Это то, что решает, что делать дальше. Какой агент, с каким контекстом, какие инструменты, что проверить. По сути, оркестрация — это цикл событий (event loop). Не «модель думает», а «модель предложила → система проверила → система решила, что дальше».
Слой 2. Изоляция
Где агент работает. Если агент пишет код прямо в твой проект, он может сломать то, что работало. Изоляция — это песочница: каждый агент в своём окружении. Если что-то сломалось, изменения откатываются, не задевая остальное.
Слой 3. Память
Что агент помнит. Не «история чата», а структурированная база знаний. Что делал вчера. Какие решения принял и почему. Какие грабли уже собрал.
Слой 4. Верификация
Как проверить результат. Не «агент сказал „готово“», а «тесты прошли, линтер чист, план выполнен». Верификация — это детерминированный фильтр. Не мнение модели, а факт.
Есть и пятый слой. Он встречается не всегда, но отличает зрелые harness’ы от самоделок: governance. Это правила. Лимиты. Эскалация. Что делать, если агент не может решить задачу. Когда звать человека.
Когда я это увидел, стало проще. Не надо изобретать. Надо сделать каждый слой нормально.
В следующем посте — почему я не взял готовый инструмент, а начал строить свой.
#HarnessOS #AIразработка #КакЯСтроилHarnessOS #AIагенты #разработка
Я разобрал несколько открытых harness’ов — от простых до продакшн-уровня. И увидел четыре слоя, которые есть почти везде.
Слой 1. Оркестрация
Это то, что решает, что делать дальше. Какой агент, с каким контекстом, какие инструменты, что проверить. По сути, оркестрация — это цикл событий (event loop). Не «модель думает», а «модель предложила → система проверила → система решила, что дальше».
Слой 2. Изоляция
Где агент работает. Если агент пишет код прямо в твой проект, он может сломать то, что работало. Изоляция — это песочница: каждый агент в своём окружении. Если что-то сломалось, изменения откатываются, не задевая остальное.
Слой 3. Память
Что агент помнит. Не «история чата», а структурированная база знаний. Что делал вчера. Какие решения принял и почему. Какие грабли уже собрал.
Слой 4. Верификация
Как проверить результат. Не «агент сказал „готово“», а «тесты прошли, линтер чист, план выполнен». Верификация — это детерминированный фильтр. Не мнение модели, а факт.
Есть и пятый слой. Он встречается не всегда, но отличает зрелые harness’ы от самоделок: governance. Это правила. Лимиты. Эскалация. Что делать, если агент не может решить задачу. Когда звать человека.
Когда я это увидел, стало проще. Не надо изобретать. Надо сделать каждый слой нормально.
В следующем посте — почему я не взял готовый инструмент, а начал строить свой.
#HarnessOS #AIразработка #КакЯСтроилHarnessOS #AIагенты #разработка
Справедливый вопрос: «Зачем строить своё, если есть Cursor, Windsurf, Claude Code?»
Я пробовал. Все три. Они классные. Но есть три вещи, которые меня не устроили.
Первое: контекст кода уходит наружу.
Это не «они плохие». Это архитектурное свойство. Claude Code запускается у тебя на машине, но промпты, прочитанные файлы и результаты команд уходят к модели в облаке. Cursor отправляет контекст кода через свои серверы к провайдерам моделей; режим приватности запрещает хранить его и учиться на нём, но не отменяет саму отправку. У Windsurf в облачной версии похожая схема, а self-hosted — отдельный корпоративный вариант. Итог один: фрагменты твоего кода покидают периметр, и дальше ты полагаешься на договор и политики вендора.
Для многих команд это неприемлемо. Финтех. Медицина. Госсектор. Все, у кого есть требования к периметру.
Второе: нет контроля в том виде, который мне нужен.
Агент сказал «готово» — значит готово. Хочешь проверить, что реально сделано, — иди разбирайся сам. Обязательных gates, явного approve и evidence как части процесса из коробки нет. Это приходится собирать самому.
Третье: нет памяти и порядка.
Правила и заметки можно положить в файлы. Но структурированной памяти о проекте нет: что делали вчера, какие решения приняли и почему. Закрыл чат — и многое приходится объяснять заново.
Я не говорю, что Cursor плохой. Он отличный для другого сценария. Быстро дописать функцию. Разобраться в незнакомом коде. Написать тесты.
Но для управляемой AI-разработки нужен другой инструмент. С self-hosted архитектурой. С явными gates. С памятью.
Именно поэтому я начал строить HarnessOS.
Не «сделать Cursor лучше». А сделать то, для чего Cursor не создавался.
В следующем посте — с чего всё началось: Prompt Factory.
#HarnessOS #AIразработка #КакЯСтроилHarnessOS #AIагенты #разработка
Я пробовал. Все три. Они классные. Но есть три вещи, которые меня не устроили.
Первое: контекст кода уходит наружу.
Это не «они плохие». Это архитектурное свойство. Claude Code запускается у тебя на машине, но промпты, прочитанные файлы и результаты команд уходят к модели в облаке. Cursor отправляет контекст кода через свои серверы к провайдерам моделей; режим приватности запрещает хранить его и учиться на нём, но не отменяет саму отправку. У Windsurf в облачной версии похожая схема, а self-hosted — отдельный корпоративный вариант. Итог один: фрагменты твоего кода покидают периметр, и дальше ты полагаешься на договор и политики вендора.
Для многих команд это неприемлемо. Финтех. Медицина. Госсектор. Все, у кого есть требования к периметру.
Второе: нет контроля в том виде, который мне нужен.
Агент сказал «готово» — значит готово. Хочешь проверить, что реально сделано, — иди разбирайся сам. Обязательных gates, явного approve и evidence как части процесса из коробки нет. Это приходится собирать самому.
Третье: нет памяти и порядка.
Правила и заметки можно положить в файлы. Но структурированной памяти о проекте нет: что делали вчера, какие решения приняли и почему. Закрыл чат — и многое приходится объяснять заново.
Я не говорю, что Cursor плохой. Он отличный для другого сценария. Быстро дописать функцию. Разобраться в незнакомом коде. Написать тесты.
Но для управляемой AI-разработки нужен другой инструмент. С self-hosted архитектурой. С явными gates. С памятью.
Именно поэтому я начал строить HarnessOS.
Не «сделать Cursor лучше». А сделать то, для чего Cursor не создавался.
В следующем посте — с чего всё началось: Prompt Factory.
#HarnessOS #AIразработка #КакЯСтроилHarnessOS #AIагенты #разработка
AI-агенты в 2026: что умеют, где работают и зачем бизнесу
Проект "Элис" — так и хочется начать эту статью, как в культовом многосерийном бестселлере :) Но сегодня речь пойдёт не о клонах, а об AI-обвязке и LLM-моделях.
Агент сегодня есть в любом AI-чате. Но Элис — не «просто агент», а каркас для многошаговых агентов: тех, что ведут задачу через длинную цепочку — план, десятки вызовов инструментов, проверки, одобрения человека, продолжение после сбоя и честный финиш. Разберу, чем они отличаются, что уже умеют, кто делает такие продукты и зачем они бизнесу.
Полный текст — в следующем сообщении 👇
Проект "Элис" — так и хочется начать эту статью, как в культовом многосерийном бестселлере :) Но сегодня речь пойдёт не о клонах, а об AI-обвязке и LLM-моделях.
Агент сегодня есть в любом AI-чате. Но Элис — не «просто агент», а каркас для многошаговых агентов: тех, что ведут задачу через длинную цепочку — план, десятки вызовов инструментов, проверки, одобрения человека, продолжение после сбоя и честный финиш. Разберу, чем они отличаются, что уже умеют, кто делает такие продукты и зачем они бизнесу.
Полный текст — в следующем сообщении 👇
Три уровня — и где тут Элис:
• чат-бот — отвечает на вопрос текстом и ничего не делает в мире;
• обычный агент в AI-чате — внутри одного ответа делает один-два вызова инструментов: поискать в сети, запустить код, прочитать файл. Сделал — ответил, задача закрыта;
• многошаговый агент — берёт задачу на часы и десятки шагов: планирует, вызывает инструменты, проверяет результат, останавливается спросить человека перед опасным действием, держит бюджет, ведёт журнал и после перезапуска продолжает с того места, где упал.
Разница между вторым и третьим уровнем — не в модели, а в обвязке. Длинная цепочка ломается в десятках мест: оборвался процесс, человек не ответил на запрос одобрения, агент зациклился, сказал «готово», а действия не было. Элис строится именно для третьего уровня.
Что умеет многошаговый агент:
• публикует рассылки постов в соцсетях по расписанию и генерирует изображения к постам;
• работает в браузере как человек: открывает сайты, заполняет формы, нажимает кнопки;
• выполняет задачи по расписанию — каждый день, каждую неделю, в нужный час;
• помнит правила и договорённости: что можно, что нельзя, что только после одобрения;
• работает с почтой, репозиториями и другими сервисами через интеграции;
• делит большую задачу между параллельными субагентами;
• пишет и правит код;
• собирает документы и отчёты;
• распознаёт скриншоты;
• когда нужен вход по СМС или одобрение, передаёт управление человеку, а не просит пароль в чате.
Где это применяется:
• контент — серии постов, кросспостинг, адаптация под площадки;
• поддержка — первая линия, разбор обращений, черновики ответов;
• продажи — обработка заявок, обновление CRM, напоминания;
• исследования — сбор и сравнение источников, выжимки;
• отчётность — регулярные сводки из нескольких систем;
• разработка и DevOps — правки кода, pull request, разбор упавших CI;
• бэк-офис — документы, таблицы, переписка по шаблону.
Кто уже на рынке:
• OpenAI — Operator вырос в ChatGPT agent, сейчас многошаговые задачи — в ChatGPT Work с облачным браузером;
• Anthropic — Claude Code и инструмент computer use для управления интерфейсом;
• Cognition Devin — автономный инженер: от задачи до pull request в своей виртуальной машине;
• Manus — универсальный агент со своим компьютером и браузером: исследования, презентации, сайты;
• OpenClaw — open-source ассистент, работает на твоей машине и отвечает в мессенджерах;
• n8n, Make, Zapier, Lindy — конструкторы автоматизаций и агентов;
• Сбер — ГигаЧат Бизнес для корпоративных агентов и ГигаАгент; Яндекс — AI Studio с конструктором агентов.
Почему Элис. Большинство продуктов выше — либо готовый сервис, где правила задаёт вендор, либо конструктор, где надёжность длинных цепочек — твоя забота. Элис — harness для многошаговых агентов на DeepSeek, и надёжность многошаговости держится на её ядре:
• журнал событий — единственная правда: что сделано, видно и после сбоя;
• outbox — побочные действия не теряются и не задваиваются при рестарте;
• replay — переигровка разговора без повторных эффектов, для отладки и проверки;
• одобрение человека — опасные шаги только с «да», честный таймаут, если ответа нет;
• бюджет и анти-runaway — лимиты токенов, денег, времени и шагов, стоп при зацикливании;
• честная остановка — каждый разговор заканчивается успехом или названной причиной провала.
Плюс изоляция каждой группы и секреты только ссылками. Сегодня Элис работает локально или на выделенной машине, в планах — облачный сервис.
Дальше — серия из 20 постов: как Элис устроена изнутри и где было трудно. Если хотите такого агента под свои задачи — пишите.
#HarnessOS #Элис #AIагенты #автоматизация #LLM
👉 Канал про HarnessOS и Элис: https://t.me/harness_ai_ru
📝 Мой блог: https://blog.arhellist.ru/blog/ai-agenty-v-2026-chto-umeyut-gde-rabotayut-i-zachem-biznesu
• чат-бот — отвечает на вопрос текстом и ничего не делает в мире;
• обычный агент в AI-чате — внутри одного ответа делает один-два вызова инструментов: поискать в сети, запустить код, прочитать файл. Сделал — ответил, задача закрыта;
• многошаговый агент — берёт задачу на часы и десятки шагов: планирует, вызывает инструменты, проверяет результат, останавливается спросить человека перед опасным действием, держит бюджет, ведёт журнал и после перезапуска продолжает с того места, где упал.
Разница между вторым и третьим уровнем — не в модели, а в обвязке. Длинная цепочка ломается в десятках мест: оборвался процесс, человек не ответил на запрос одобрения, агент зациклился, сказал «готово», а действия не было. Элис строится именно для третьего уровня.
Что умеет многошаговый агент:
• публикует рассылки постов в соцсетях по расписанию и генерирует изображения к постам;
• работает в браузере как человек: открывает сайты, заполняет формы, нажимает кнопки;
• выполняет задачи по расписанию — каждый день, каждую неделю, в нужный час;
• помнит правила и договорённости: что можно, что нельзя, что только после одобрения;
• работает с почтой, репозиториями и другими сервисами через интеграции;
• делит большую задачу между параллельными субагентами;
• пишет и правит код;
• собирает документы и отчёты;
• распознаёт скриншоты;
• когда нужен вход по СМС или одобрение, передаёт управление человеку, а не просит пароль в чате.
Где это применяется:
• контент — серии постов, кросспостинг, адаптация под площадки;
• поддержка — первая линия, разбор обращений, черновики ответов;
• продажи — обработка заявок, обновление CRM, напоминания;
• исследования — сбор и сравнение источников, выжимки;
• отчётность — регулярные сводки из нескольких систем;
• разработка и DevOps — правки кода, pull request, разбор упавших CI;
• бэк-офис — документы, таблицы, переписка по шаблону.
Кто уже на рынке:
• OpenAI — Operator вырос в ChatGPT agent, сейчас многошаговые задачи — в ChatGPT Work с облачным браузером;
• Anthropic — Claude Code и инструмент computer use для управления интерфейсом;
• Cognition Devin — автономный инженер: от задачи до pull request в своей виртуальной машине;
• Manus — универсальный агент со своим компьютером и браузером: исследования, презентации, сайты;
• OpenClaw — open-source ассистент, работает на твоей машине и отвечает в мессенджерах;
• n8n, Make, Zapier, Lindy — конструкторы автоматизаций и агентов;
• Сбер — ГигаЧат Бизнес для корпоративных агентов и ГигаАгент; Яндекс — AI Studio с конструктором агентов.
Почему Элис. Большинство продуктов выше — либо готовый сервис, где правила задаёт вендор, либо конструктор, где надёжность длинных цепочек — твоя забота. Элис — harness для многошаговых агентов на DeepSeek, и надёжность многошаговости держится на её ядре:
• журнал событий — единственная правда: что сделано, видно и после сбоя;
• outbox — побочные действия не теряются и не задваиваются при рестарте;
• replay — переигровка разговора без повторных эффектов, для отладки и проверки;
• одобрение человека — опасные шаги только с «да», честный таймаут, если ответа нет;
• бюджет и анти-runaway — лимиты токенов, денег, времени и шагов, стоп при зацикливании;
• честная остановка — каждый разговор заканчивается успехом или названной причиной провала.
Плюс изоляция каждой группы и секреты только ссылками. Сегодня Элис работает локально или на выделенной машине, в планах — облачный сервис.
Дальше — серия из 20 постов: как Элис устроена изнутри и где было трудно. Если хотите такого агента под свои задачи — пишите.
#HarnessOS #Элис #AIагенты #автоматизация #LLM
👉 Канал про HarnessOS и Элис: https://t.me/harness_ai_ru
📝 Мой блог: https://blog.arhellist.ru/blog/ai-agenty-v-2026-chto-umeyut-gde-rabotayut-i-zachem-biznesu
Telegram
Harness для ИИ
Как строить управляемую AI-разработку: harness вокруг LLM, оркестрация, память, проверки. История разработки HarnessOS от Алексея Пасечника.
Прежде чем рассказывать про HarnessOS, надо рассказать про то, что было до него.
Несколько лет я работал над сложными проектами. И всё время упирался в одну проблему: AI генерирует код быстрее, чем я успеваю его проверять.
Это называют Verification Tax — налог на проверку.
Ты экономишь час на написании — и тратишь полтора на то, чтобы понять, что именно агент сделал, не сломал ли он что-то и почему тесты вроде зелёные, а поведение — нет.
Тогда я начал строить Prompt Factory. Не фреймворк. Не библиотеку. Методологию и инструмент дисциплины.
Идея простая: сначала договориться, потом делать.
Вместо «сделай мне фичу» — сначала зафиксировать, что именно строится, зачем, какие границы и как это проверить. Только после этого — код.
Prompt Factory делает три вещи:
• Декомпозирует. Большая задача режется на тонкие куски. Каждый можно проверить отдельно.
• Описывает. Каждый кусок получает спецификацию: что должно быть, чего быть не должно, как проверить.
• Генерирует. Из спецификации появляется задание для агента. С чёткими критериями приёмки.
Я назвал это дисциплиной. Потому что суть не в инструменте. Суть в том, что система не даёт сделать иначе.
Prompt Factory прошёл проверку на реальных проектах — xChangePro и WebCraftly. Не на демо. Это важно.
Но у него был один недостаток. Он не умел работать с существующими проектами. Только с новыми, с нуля.
Это и стало отправной точкой для HarnessOS.
В следующем посте — что уже есть на рынке и кто решает похожие задачи.
#HarnessOS #AIразработка #КакЯСтроилHarnessOS #AIагенты #разработка
Несколько лет я работал над сложными проектами. И всё время упирался в одну проблему: AI генерирует код быстрее, чем я успеваю его проверять.
Это называют Verification Tax — налог на проверку.
Ты экономишь час на написании — и тратишь полтора на то, чтобы понять, что именно агент сделал, не сломал ли он что-то и почему тесты вроде зелёные, а поведение — нет.
Тогда я начал строить Prompt Factory. Не фреймворк. Не библиотеку. Методологию и инструмент дисциплины.
Идея простая: сначала договориться, потом делать.
Вместо «сделай мне фичу» — сначала зафиксировать, что именно строится, зачем, какие границы и как это проверить. Только после этого — код.
Prompt Factory делает три вещи:
• Декомпозирует. Большая задача режется на тонкие куски. Каждый можно проверить отдельно.
• Описывает. Каждый кусок получает спецификацию: что должно быть, чего быть не должно, как проверить.
• Генерирует. Из спецификации появляется задание для агента. С чёткими критериями приёмки.
Я назвал это дисциплиной. Потому что суть не в инструменте. Суть в том, что система не даёт сделать иначе.
Prompt Factory прошёл проверку на реальных проектах — xChangePro и WebCraftly. Не на демо. Это важно.
Но у него был один недостаток. Он не умел работать с существующими проектами. Только с новыми, с нуля.
Это и стало отправной точкой для HarnessOS.
В следующем посте — что уже есть на рынке и кто решает похожие задачи.
#HarnessOS #AIразработка #КакЯСтроилHarnessOS #AIагенты #разработка
Элис: каркас для групп ботов — от своей машины к облаку
Запускаю новую серию — про Элис (HarnessBot). Это мой второй большой проект после HarnessOS: каркас для групп ботов на DeepSeek. Сегодня он работает локально или на выделенной машине, в планах — облачный сервис. Это не замена IDE. Оператор даёт задачу, бот думает и вызывает инструменты, а всё важное пишется на диск, чтобы после сбоя можно было продолжить.
За 20 постов разберу, как он устроен, зачем каждый кусок и где было по-настоящему трудно. Пишу для тех, кто сам строит агентов.
Полный текст — в следующем сообщении 👇
Запускаю новую серию — про Элис (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
Что система делает:
• ведёт полный журнал всего, что произошло: файлы событий, а не «память в голове процесса»;
• гоняет цикл «модель → инструменты → снова модель»;
• спрашивает человека перед опасным действием: запись файлов, shell, навигация, генерация медиа;
• переигрывает историю без повторных побочных эффектов;
• передаёт задачу другой группе, в том числе на другой хост;
• считает токены, деньги и время и останавливается честно, а не «замолкает».
Куда движется. Сейчас Элис запускается локально или на отдельной машине. Следующий шаг — облачный сервис. Архитектура под это заложена с самого начала: удалённый HTTP-транспорт, федерация хостов, изоляция каждой группы, брокер секретов, B2B-лицензия. Чем Элис не является: это не замена IDE, не Kubernetes-mesh и не обучение своих моделей. Ставка — на надёжность самого harness.
Ключевая трудность (инженерная): удержать границы. Когда пишешь каркас для агентов, каждую неделю хочется добавить «ещё одну полезную штуку»: интеграции, удобства, «быстрые» обходы. Каждая такая штука размывает гарантии ядра — а в будущем облаке они понадобятся как никогда. Поэтому у проекта есть явный список не-целей и «конституция» AGENTS.md, по которой пишут код и люди, и агенты.
В следующих постах: изоляция групп, журнал событий, outbox, цикл агента, кэш промпта, политика инструментов, секреты, браузер, шлюз между группами, бюджет, replay, Mission Control и честный финал про то, что пока не получилось.
#HarnessOS #Элис #AIагенты #LLM #DeepSeek
👉 Канал про HarnessOS и Элис: https://t.me/harness_ai_ru
Telegram
Harness для ИИ
Как строить управляемую AI-разработку: harness вокруг LLM, оркестрация, память, проверки. История разработки HarnessOS от Алексея Пасечника.
Когда я начал копать, оказалось, что рынок уже формируется. И это хорошая новость. Не потому что «всё занято». А потому что боль реальна и умные люди её видят.
Вот кто решает похожие задачи. Три ветки.
Первая ветка — 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 от Алексея Пасечника.
Группа — единица изоляции
Единица изоляции в Элис — не пользователь, а группа. Отдельные бот-контуры со своим каталогом на диске. Группы не делят ни браузер, ни файлы, ни память, ни бюджет. И правило: в группе одновременно идёт только один активный разговор, остальное — в очередь.
Почему так и что это ломает — в посте.
Полный текст — в следующем сообщении 👇
Единица изоляции в Элис — не пользователь, а группа. Отдельные бот-контуры со своим каталогом на диске. Группы не делят ни браузер, ни файлы, ни память, ни бюджет. И правило: в группе одновременно идёт только один активный разговор, остальное — в очередь.
Почему так и что это ломает — в посте.
Полный текст — в следующем сообщении 👇