Что случилось: пять месяцев на GoClaw и десять пользователей, которые всё сломали
Руководитель центра разработки Directum пять месяцев собирал управляемую среду для корпоративной разработки с AI-агентами из открытых компонентов. Основой стала GoClaw, и её автор долго допиливал под свои процессы. На небольшой группе всё держалось. После подключения примерно десяти пользователей вылезли тормоза, падения и проблемы с управлением длительными задачами. Полноценного human-in-the-loop не хватало: согласования и возвраты на доработку приходилось сооружать обходными путями.
Историю автор выложил публично, с деталями по этапам: пять месяцев приручал GoClaw, в итоге написал свою систему. Ответ на вопрос «почему ушёл» звучит так: дело не в качестве конкретной open-source-сборки. Нужные гарантии лежали вне агентного цикла, и собирать их из чужих запчастей выходило дороже, чем построить систему под себя. В итоге он начал писать self-hosted Temporality, чтобы получить гарантии на уровне системы, а не долепливать очередные палки очередным добром.
Границы кейса обозначены самим автором. Нагрузочные цифры получены на детерминированном мок-провайдере, поэтому реальные задержки и стоимость LLM они не отражают. Все проблемы агентной разработки, по его собственному признанию, тоже не решены. Дальше разбираем, какие требования к среде вытащил этот опыт и что из него переносится в другую команду.
Почему агентного фреймворка недостаточно для корпоративной разработки
Большая часть агентных фреймворков хорошо отвечает на один вопрос: как дать модели инструменты, организовать цикл вызовов, подключить MCP, запустить подагента и получить результат. Это рабочая база, и GoClaw её закрывала. Вопрос в том, что происходит после получения результата.
Чем корпоративная задача отличается от демо-сценария агента
В корпоративной разработке задача обычно начинается не с вызова инструмента и заканчивается не ответом модели. Формулировка из кейса: агенту нужно сходить к Васе и Пете, собрать информацию и уточнить противоречия, сформировать артефакт с требованиями и источниками, а затем согласовать его с начальником отдела.
Разложим на состояния. Сбор информации зависит от двух людей, которые могут ответить в разное время и противоречить друг другу. Артефакт имеет версии. Согласование может вернуть документ на доработку, и тогда часть шагов повторяется с новым контекстом. Финальный текст модели здесь промежуточный результат, а не завершение работы. Обычный агентный цикл «вызов инструмента - ответ» такую конструкцию не держит: он не хранит, кто и когда что согласовал, и не умеет ждать человека сутками.
Почему локальные харнесы плохо масштабируются на команду
Автор кейса высказывается жёстко: за локальные харнесы надо отрубать руки в любой компании крупнее 3,5 человек. Аргумент простой: харнес на ноутбуке сотрудника - гарантированный способ потерять весь накопленный опыт и инструментарий вместе с его уходом. Это позиция практика, а не универсальный закон. Для команды из двух человек с одинаковыми задачами локальная сборка может оказаться дешевле любой серверной.
Второй риск той же природы: права. Рано или поздно агент что-то набедокурит на машине с правами локального администратора. Когда такой агент один и вы за ним смотрите, это инцидент на вечер. Когда их десять и они работают параллельно, это уже вопрос доступа и разграничения прав.
Отсюда список требований, который кейс предъявляет к корпоративному харнесу:
- мультитенантность: несколько пользователей и команд на одной системе, без общей свалки контекстов;
- состояния и история HITL-решений: кто согласовал, что вернул на доработку и почему;
- сквозной бюджет ресурсов на задачу: токены, вызовы инструментов, время, стоимость;
- версионируемые навыки с критериями проверки;
- оценочный гейт перед выкатом изменений;
- наблюдаемость: видно, что агент делал и в каком порядке.
Формальным стандартом этот список не служит. Это набор того, чего не хватило в конкретной сборке на десять человек по описанию автора.
Что именно сломалось в GoClaw: деградация, падения и отсутствие HITL
Симптомы из кейса звучат буднично: тормоза, падения, проблемы с управлением длительными задачами, нехватка полноценного HITL. Конкретных стектрейсов и номеров версий автор в разборе не приводит, и придумывать их не нужно. Важнее другое: набор симптомов типовой для перехода от демо к многопользовательской работе.
Десять активных пользователей означают конкурентные запуски, общий пул ресурсов и задачи, которые нельзя просто перезапустить с нуля. Каждый запуск занимает модель, инструменты и место в очереди. Когда один агент уходит в цикл на сорок шагов, остальные девять ждут. Дальше появляются таймауты, повторные запуски, дублирующиеся действия. Наращивать число агентов в такой ситуации бесполезно: рой из десятков агентов не становится умнее, а только добавляет точек отказа. Типичные сбои многоагентных схем разбирали отдельно в материале про рой AI-агентов.
Готовых взрослых мультитенантных харнесов раз-два и обчелся, и они требуют сложного конструирования из отдельных запчастей. Это контекст, в котором доработка GoClaw перестала быть дешёвой. Каждый новый пользователь добавлял не строчку конфига, а новый класс проблем.
Длительные задачи и многошаговые процессы: где ломается агентный цикл
Длительная задача требует трёх вещей, которых нет в простом цикле вызовов: сохранённого состояния, точек восстановления и явного управления шагами. Если процесс падает на двадцатом шаге из сорока, перезапуск с нуля тратит токены и время, а побочные эффекты предыдущих шагов приходится разбирать вручную.
Как это выглядит, когда механику закладывают в архитектуру, видно по заявлениям платформы RunForge: изолированный браузер на каждый запуск, одобрение человеком до действий агента, чекпоинты с автоматическим возобновлением с последнего шага после сбоя. Это пример того, что подобные вещи проектируют как часть системы. RunForge здесь иллюстрация подхода, а не рекомендация: в кейсе Directum её не использовали, да и требования у команд разные.
Почему HITL нельзя приделать сбоку
HITL - это не кнопка «одобрить» в чате. Это состояния и история решений: кто согласовал, когда, с какими комментариями, что именно вернули на доработку и на каком основании. В сборке на GoClaw такие вещи сооружались обходными путями, а обходные пути быстро становятся главной логикой системы.
Практическая деталь: согласование расходует внимание человека. Десять агентов, каждый из которых просит подтверждение на каждом шаге, выматывают за час, после чего человек начинает одобрять не глядя. Это и есть бюджет внимания, который надо считать наравне с токенами. Как хранят состояние проекта между сессиями, моделями и агентами, разбирали на примере Later Bender: задачи, заметки, runbook'и и временные среды поверх MCP.
Temporality: какие гарантии автор вынес на уровень архитектуры
Формулировка автора: получить гарантии на уровне системы, не долепливая очередные палки очередным добром. Из этого следует набор обещаний, которые в Temporality заявлены как часть архитектуры, а не надстройка над агентным циклом: длительное исполнение на Temporal, наблюдаемость, контроль полномочий, накопление проверенного опыта. В публичном описании кейса эти механизмы названы, деталей реализации в нём немного.
Почему длительное исполнение на Temporal, а не на самописном цикле
Temporal - движок для долгоживущих workflow. Он хранит состояние выполнения, повторяет шаги по заданной политике ретраев и позволяет ждать внешнего события, включая решение человека. Для агента это ровно те свойства, которых не хватает самописному циклу: шаг не теряется при падении процесса, ожидание согласования не держит поток в памяти, история шагов остаётся в движке.
Цена решения очевидна: Temporal надо разворачивать и сопровождать, а workflows писать по его правилам, с ограничениями на детерминизм. Своя система означает свою поддержку. Temporality в кейсе не готовый продукт для рынка, а внутренний инструмент, который ещё предстоит развивать.
Наблюдаемость, полномочия и накопление опыта как часть архитектуры
Три обещания стоит разложить по смыслу. Наблюдаемость: видно, какие шаги агент выполнил, в каком порядке и с какими аргументами. Контроль полномочий: заранее определено, что агенту разрешено, а что нет, и это проверяется на границе исполнения, а не в тексте промпта. Накопление проверенного опыта: удачные приёмы и разборы ошибок остаются в системе, а не в голове у сотрудника.
Третий пункт прямо связан с критикой локальных харнесов. Если опыт живёт на ноутбуке, он уходит вместе с ноутбуком. Если в общей системе с версиями и историей, им пользуется вся команда. Self-hosted здесь принципиален: данные, процессы и журналы остаются внутри контура компании.
Наблюдаемость AI-агентов и Agent-SRE: как оценивать траекторию, а не финальный текст
Для агентных систем эталон - это траектория: какие функции вызваны, в каком порядке и с какими аргументами. Финальный ответ тоже проверяют, но он не единственный критерий. Пример из разбора golden dataset: агент по заявкам в CRM должен сначала найти контрагента, потом проверить договор, и только затем предложить скидку. Красивый финальный текст при неверной последовательности шагов считается провалом, о чём подробно пишут в материале про сборку golden dataset.
Agent-SRE в этом контексте означает простую дисциплину: смотреть на траекторию выполнения как на основной объект наблюдения. Какие инструменты вызывались, где агент зациклился, сколько раз повторял один и тот же шаг, на каком месте остановился. Ответ без этих данных ничего не говорит о надёжности системы.
Golden dataset: что фиксировать в эталоне
Эталонный набор фиксирует договорённости команды: что считается правильным ответом, какие источники допустимы, как оформлять ссылки на пункт регламента. По оценке автора разбора, это снимает половину приёмки, детали он приводит в разборе метода. Для агента с инструментами в набор добавляют ожидаемую траекторию вызовов. Размер набора и метрики каждая команда выбирает сама: универсальных цифр здесь нет.
Важная оговорка: эталон - договорённость, а не истина. Когда меняется регламент или появляется новый источник, набор правится вместе с ним, иначе гейт начнёт защищать устаревшее поведение.
Оценочный гейт для изменений: как не сломать агента правкой промпта
Логика гейта простая. Любое изменение (промпт, модель, индекс базы знаний, набор инструментов) прогоняется на эталонном наборе. Сравниваются ответ и траектория. Решение о выкате принимают по результату прогона, а не по ощущению, что новая формулировка звучит лучше.
С этим связаны версионируемые навыки. У навыка есть версия и критерии проверки, по которым понятно, сработал он или нет. Текст промпта в репозитории без версии и без критериев проверить нельзя. Как пересматривать показатели, когда система усложняется, видно на примере оркестратора задач на Claude Code: часть исходных метрик пришлось менять по ходу работы.
Версионируемые навыки и «бюджет внимания»: как управлять ресурсами агентной системы
Ресурсов в агентной системе два типа, и считать их надо вместе.
Сквозной бюджет ресурсов означает учёт на всю задачу, а не на отдельный шаг: токены, вызовы инструментов, время, стоимость. Агент, который на каждом шаге укладывается в лимит, может сжечь бюджет в десять раз на всей цепочке. Без сквозного счётчика такая задача выясняется по факту счёта от провайдера.
Бюджет внимания устроен похоже. Человек выдерживает ограниченное число согласований и возвратов, после чего начинает одобрять не читая. Если процесс требует подтверждения на каждом шаге, система формально работает, а фактический контроль исчезает. Планировать число точек HITL нужно так же осознанно, как лимит токенов.
Версионируемые навыки замыкают схему. У каждого навыка есть версия, критерии проверки и понятная зона ответственности. Когда навык меняется, гейт из предыдущего раздела показывает, стало лучше или хуже. История HITL-решений при этом остаётся записями в системе, а не перепиской в мессенджере.
Конкретных числовых лимитов кейс не даёт, и брать их с потолка не нужно. Разумный старт: измерить текущее потребление на своих задачах и поставить лимит чуть выше медианы, а дальше смотреть, где агент упирается в потолок чаще всего.
Безопасность: что Docker-песочница защищает, а что нет
В кейсе агенты работают в Docker-песочнице с отключённой по умолчанию сетью и урезанными привилегиями. Это разумный базовый уровень. Песочница ограничивает то, что агент может сделать с файлами и сетью, и снимает часть рисков от случайных команд.
Дальше начинаются границы. Такая песочница не защищает от компрометации Docker-демона и ядра хоста. Ошибка в конфигурации демона, уязвимость ядра или неверно выданный доступ к сокету Docker обнуляют изоляцию контейнера. Агент, которому разрешено управлять контейнерами, получает дорогу к хосту.
Этот риск смыкается с сюжетом про локальные харнесы и права администратора. Песочница нужна, но её недостаточно: границы доверия проектируют отдельно. Полезно заранее ответить на вопросы о runtime-контроле: кто проверяет действие агента в момент исполнения, что будет, если он обойдёт ограничения на уровне инструмента. На похожем сюжете разбирали, как агент с правами только на чтение всё равно изменил запись в CRM через downstream-узел, в материале про runtime-контроль на n8n и DeepSeek.
Ограничения кейса: что нельзя переносить на свой прод
Первое и главное: нагрузочные цифры получены на детерминированном мок-провайдере. Такой провайдер отвечает мгновенно и одинаково, поэтому реальные задержки LLM, их разброс и стоимость в этих числах не видны. Любые выводы о производительности на живых моделях придётся проверять заново.
Второе: автор прямо говорит, что не решил все проблемы агентной разработки. Temporality - не готовый продукт, а собственная система, которую надо поддерживать, обновлять и объяснять новым сотрудникам.
Третье: масштаб. Десять пользователей и один руководитель в роли архитектора не тянут на корпоративную нагрузку в тысячи сессий. Опыт показателен качественно, количественные выводы из него лучше не делать.
Отсюда рамка решения. Если у вас три-пять пользователей и короткие задачи, доработка open-source может оказаться дешевле своей системы. Если в процессах несколько людей, согласования, возвраты на доработку, требования к наблюдаемости и мультитенантности, стоимость доработки чужого кода растёт быстро: каждый новый пользователь вскрывает новый класс проблем. Сравнение своей разработки с готовыми решениями по latency, cost и reliability разбирали в материале про самописного AI-агента на Python, там же есть чек-лист выбора.
Что забрать в свою команду: практический чек-лист
- Выпишите свои многошаговые процессы с людьми внутри. Для каждого шага отметьте, где нужен человек и что считается результатом.
- Определите, где хранятся состояния и история HITL-решений. Если это чат и таблица, система у вас уже есть, только без гарантий.
- Введите сквозной бюджет ресурсов на задачу и бюджет внимания на человека. Считайте токены, вызовы инструментов, время и стоимость вместе, а не по шагам.
- Соберите golden dataset с траекториями вызовов, а не только с эталонными ответами.
- Поставьте оценочный гейт перед выкатом изменений промпта, модели или индекса знаний.
- Заведите версии навыков с критериями проверки. Навык без версии проверить нечем.
- Проверьте права агента и границы Docker-песочницы. Отдельно ответьте, что будет при компрометации демона или ядра хоста.
- Решите, доработка open-source или своя система. Решение принимайте по числу пользователей, сложности процессов и требованиям к наблюдаемости.
Ценность кейса Directum в честности про ограничения. Автор показывает не готовый рецепт, а путь: сначала пять месяцев доработки чужого кода, потом собственная система с Temporal в основе, с явно названными рисками и нерешёнными задачами. Такой разбор полезнее истории успеха, потому что позволяет примерить чужие грабли к своему масштабу до того, как на них наступить.