Я Никита Краснов, автор COSMOS. Я пришёл из ИТ в бизнес одежды, а затем через задачи этого бизнеса вернулся к разработке уже системы для работы с AI-агентами.
Эта история началась с очень приземлённого требования: меньше тратить на обслуживание повторяющихся операций. Маркетплейсы заставили нас постоянно оптимизировать работу. Нужно было продавать одежду, разбираться с возвратами, сопоставлять отчёты, вести учёт и понимать, что происходит между этими этапами. Каждая ручная передача данных добавляла работу.
В итоге мы оцифровали практически всё, что есть в нашем одежном бизнесе. Примерно год назад я начал собирать собственный harness для агентов. Постепенно из него вырос COSMOS – то, что я называю «ОС компании»: общая рабочая среда для задач, контекста, инструментов и агентов.
Хочу рассказать, почему бизнес одежды привёл меня именно к такой архитектуре.
Маркетплейсы быстро учат считать лишнюю работу
У одежды есть вполне физическая жизнь: размеры, цвета, склад, заказ, возврат. У той же одежды есть цифровая жизнь – карточки, статусы, отчёты и записи в учёте. Между ними постоянно приходится устанавливать соответствие.
Возьмём условный пример. Маркетплейс сообщил о возврате. Это ещё не отвечает на все вопросы: появился ли товар на складе, к какому событию относится запись в отчёте, что уже отражено в учёте? Несколько источников могут описывать разные этапы одной операции.
Когда человек разбирает это вручную, он одновременно работает переводчиком между системами и хранит историю процесса в голове. На следующем этапе другому человеку приходится восстанавливать эту историю.
Именно такие переходы меня интересовали. Можно ускорить одну операцию, но затем потратить всё выигранное время на выяснение, куда передать результат и что с ним делать дальше.
Поэтому оцифровка для меня постепенно стала означать больше, чем наличие файлов и таблиц. Мне было нужно, чтобы у работы появились понятное состояние, основания для решения и следующий ответственный шаг.
1С: начать с рутины, за которую приходится платить
Одной из практических задач стала автоматизация работы с 1С. Моя цель была прямой: убрать необходимость постоянно тратить деньги на воспроизведение рутинных бухгалтерских операций.
Повторяющаяся работа особенно раздражает инженера. Получить данные, сопоставить записи, подготовить операцию, проверить результат – если действия можно описать и проверить, хочется один раз организовать процесс, а затем разбирать исключения.
Это не означает, что я заменил всю бухгалтерию агентом. Ответственность за учётные решения остаётся у человека. Я говорю о причине, по которой взялся за автоматизацию, и о конкретных операциях, которые можно ограничить и проверить.
Здесь особенно ясно стало видно различие между «агент предложил решение» и «в учёте установлен нужный результат». Даже аккуратный ответ модели не сообщает, что произошло в 1С. Это нужно прочитать из самой системы.
Например, при разработке интеграции агент может исследовать контракт обмена, предложить изменение обработчика и помочь проверить его на тестовых данных. Применение к рабочей базе – отдельное действие с отдельными полномочиями.
Если после действия связь оборвалась, результат может быть неизвестен. Для учёта это существенное состояние: сначала нужно сверить, что произошло, и только потом решать, допустимо ли повторение.
Предлагаемый процесс проверки интеграционного изменения. Здесь нет производственных данных; учётное состояние устанавливается в 1С.
Так бизнес-задача превратилась в архитектурное требование: у действия должны быть границы и проверяемый результат.
Зачем мне понадобился harness
Когда начинаешь поручать агентам работу, быстро обнаруживаешь, сколько задач находится вокруг самой модели.
Откуда взять актуальный контекст? Что разрешено делать в этом проекте? Как сохранить решение? Кто проверит результат? С чего продолжить, если сессия прервалась?
Примерно год назад я начал строить слой, который отвечает за эту организацию работы. Harness – это среда вокруг модели: она выдаёт контекст и инструменты, поддерживает процесс выполнения и помогает установить результат.
Моя отправная точка была связана с уже существующим бизнесом. У нас есть системы, в которых живут данные, и действия, последствия которых придётся разбирать. Поэтому хотелось поручать агенту ограниченный участок работы, сохраняя связь с этими системами.
Чат удобен для разговора. Для продолжительной работы мне понадобились задачи, сохранённые решения, ссылки на источники и состояние, которое переживает отдельную сессию.
Как harness вырос в «ОС компании»
Постепенно вопрос изменился. Сначала я организовывал работу отдельного агента. Затем понадобилось связать проекты, инструменты, людей и несколько агентных ролей.
Словами «ОС компании» я обозначаю именно этот общий слой организации работы. Бизнес-системы сохраняют свои обязанности: учёт находится в 1С, у документов и проектов есть свои владельцы. COSMOS связывает работу вокруг них.
В проекте должны быть понятны его область и доступные инструменты. У задачи – текущий этап и основания для продолжения. У сохранённого решения – источник и условия, при которых оно действует.
Это важно и для памяти. Агенту не требуется буквально помнить всё. При возобновлении работы ему нужны относящиеся к задаче записи: что уже проверили, что осталось открытым и почему приняли решение. Устаревшие сведения нужно различать с актуальными, а недостающие – искать или запрашивать.
Представим подготовку отчёта. Часть данных подтверждена, часть ждёт сверки. Если передать следующему исполнителю только файл, ограничение может потеряться. Полезнее передать сам результат вместе с состоянием задачи и основанием, по которому его пока нельзя считать окончательным.
Для меня переход от harness к «ОС» произошёл именно здесь: понадобилось организовывать продолжение работы между людьми, системами и агентами.
Из чего я это собираю
В основе COSMOS – Python и PostgreSQL. Для подключения инструментов используется MCP. Веб-интерфейс строится на Angular и TypeScript, настольная оболочка – на Rust и Tauri.
Сам список технологий мало объясняет. Важнее распределение ответственности:
-
модель помогает исследовать задачу и предлагает шаги;
-
управляющий слой связывает их с проектом и доступными полномочиями;
-
сохранённое состояние и память помогают продолжать работу;
-
инструменты выполняют конкретные операции;
-
проверки дают основание принять результат.
Для значимых действий я использую контракт Action Envelope: объявить намерение, проверить политику, подготовить предварительный просмотр, получить необходимое согласование, выполнить действие и проверить результат.
MCP задаёт интерфейс вызова инструмента. Право изменить рабочие данные должно определяться отдельно. И ссылка на источник, и успешный локальный тест имеют ограниченную силу: нужно проверить, что они поддерживают именно то утверждение, которое мы собираемся принять.
Концептуальная схема: разрешение действия и подтверждение результата требуют отдельных оснований. Это не график измерений.
Боты и цифровые сотрудники
Бот компании может быть привычной точкой входа в этот процесс. Получить поручение, показать состояние задачи, найти относящиеся к ней документы, вернуть подготовленный результат. В COSMOS есть Telegram-интерфейс с настроенными участниками и инструментами.
При этом доступ через чат должен учитывать, кто обращается и какие действия разрешены. Удобство интерфейса не отменяет границы доступа.
«Цифровые сотрудники» для меня – агентные роли с определённой областью работы и критериями результата. Например, в разработческом сценарии один исполнитель исследует проблему и предлагает патч, другой проверяет его против требований, человек принимает решение о применении.
Это пример организации работы, а не обещание полностью автономной разработки. Проверяющий полезен, когда у него есть подходящие тесты или другие основания. Два похожих ответа модели ещё не подтверждают правильность изменения.
Вместо расширения полномочий на весь бизнес мне интереснее постепенно понимать, какие ограниченные задачи агент выполняет достаточно хорошо, чтобы доверять ему следующий участок процесса.
На какие проекты я смотрел
На следующих этапах развития я вдохновлялся и другими открытыми проектами: Hermes Agent, OpenClaw, DeerFlow.
Полезно видеть, как разные команды организуют навыки, память, подзадачи и доступ к агенту из привычных интерфейсов. Это помогает сравнивать подходы и пересматривать собственные решения.
У этих проектов своя хронология. Я не связываю все три с началом моего harness примерно год назад: они давали идеи по мере развития COSMOS. Моя исходная задача оставалась прежней – организовать работу в собственном бизнесе и уменьшить ручное обслуживание процессов.
Что я хочу проверять дальше
Следующий интересный шаг для меня -пилоты на одной понятной задаче. Например, разработка изменения интеграции и его проверка на фиксированных тестовых данных. С известным обычным способом работы, критериями приёмки и человеком, который отвечает за итог.
Экономию я хочу оценивать по стоимости принятого, проверенного результата. Сюда входят модель, инструменты, неудачные попытки, повторная работа и время проверки человеком. Цена токена – это лишь одна часть этого счёта.
Так мой путь из ИТ в fashion привёл к созданию среды для AI-агентов. Одежный бизнес поставил требования, которые трудно обойти красивой демонстрацией: данные должны сходиться, работу нужно продолжать, а последствия действий – проверять.
Если у вас похожая задача между бизнес-системами и ручной работой, расскажите, где именно теряется время. Мне интересно разобрать один конкретный процесс в учёте, интеграциях или разработке, и понять, какую часть можно поручить агентам с проверяемым результатом.
Автор: Agurchik
