Пять месяцев доработок GoClaw: почему разработчик создал свою платформу ИИ-агентов

Автор статьи на Хабре хотел собрать из открытых компонентов полноценную среду для разработки с помощью ИИ-агентов. За основу он взял GoClaw, но постепенно обнаружил, что необходимые функции приходится встраивать через обходные решения. Когда к системе подключились примерно десять пользователей, добавились регулярные падения, задержки и трудности с управлением длительными задачами. По словам автора, дело не в том, что GoClaw плох сам по себе: просто его архитектура не соответствовала требованиям корпоративной работы.

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

А что делать, если один сотрудник не ответил, другой сообщил противоположное, а руководитель отправил требования на доработку? Агент не должен самостоятельно решать, что согласование можно пропустить. Процесс должен сохранять своё состояние, учитывать решения людей и продолжаться с нужного этапа даже после сбоя или перезапуска сервиса.

Поэтому обычной кнопки «Одобрить» недостаточно. В корпоративной системе участие человека — HITL (human-in-the-loop) — должно быть встроено в сам механизм выполнения задач. Например, если сотрудник запретил агенту удалять базу данных, тот не может через час повторить операцию под другим названием. А если план изменился, разрешение, выданное для предыдущей версии, нельзя автоматически считать действующим.

Именно вокруг этих требований автор построил Temporality — платформу с открытым исходным кодом, которую можно развернуть на собственных серверах. В ней четыре основных направления: выполнение длительных задач, наблюдение за действиями агентов, контроль их полномочий и накопление проверенного опыта. Для управления долгими процессами используется Temporal. Он помогает сохранять состояние работы, когда агент ждёт решения человека, сервис обновляется или выполнение прерывается.

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

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

Отсюда и другой подход к памяти агентов. Если ИИ однажды нашёл способ обойти ошибку, это ещё не значит, что решение сработает в другой версии программы. Temporality отделяет историю действий от знаний, которые можно использовать повторно. Такие знания проходят проверку, могут исправляться, заменяться или признаваться устаревшими. Удачный результат ещё не означает проверенный метод.

Тот же принцип действует для навыков агентов — повторяемых процедур выполнения задач. У каждой должны быть понятные входные условия, ожидаемый результат и критерии проверки. Если агент предлагает изменить навык, новую версию сначала испытывают на контрольных примерах. Для оценки с помощью языковой модели предусмотрено сравнение с предыдущими решениями людей. Если оценки расходятся слишком сильно, изменение не проходит проверку.

Важна и возможность восстановить весь ход работы. Агент может несколько раз ошибиться, потратить лишние ресурсы, вызвать неподходящий инструмент и всё же случайно выдать правильный ответ. Поэтому недостаточно видеть только итоговый статус «выполнено». Нужно знать, какие действия предпринимал агент, где возникали задержки, сколько было повторных попыток и какие решения принимали сотрудники. Такой подход автор называет Agent-SRE — наблюдением за надёжностью всего процесса, а не только конечного результата.

Отдельный вопрос — безопасность. Автор приводит показательный случай: вместо того чтобы попросить пароль от зашифрованного архива, агент самостоятельно написал программу для его взлома и начал перегружать ноутбук вычислениями. В Temporality для подобных операций предусмотрены изолированные Docker-контейнеры с ограниченными правами, временем работы и доступными ресурсами. Сеть по умолчанию отключена, а секреты основной системы не передаются контейнеру как обычные переменные окружения. Впрочем, автор признаёт, что такая изоляция не защищает от всех угроз, включая компрометацию самого Docker или ядра сервера.

Чтобы проверять производительность платформы, разработчик подготовил воспроизводимые нагрузочные испытания. Один из сценариев включает четыре обращения к модели, два запуска команд в изолированной среде и паузу на согласование с человеком. Однако вместо настоящей языковой модели используется её имитатор. Поэтому такие тесты показывают, как платформа справляется с параллельными задачами, но не учитывают реальные задержки, ограничения и стоимость обращений к ИИ. Они не доказывают, что настоящий агент способен выполнить работу за 6 мс.

Автор не утверждает, что Temporality уже решила все проблемы корпоративных ИИ-агентов. Некоторые механизмы ещё требуют развития, а открытый код и тесты не заменяют независимого аудита. Но главный вывод пяти месяцев работы он сформулировал вполне определённо: для бизнеса важнее не то, насколько убедительно отвечает агент, а то, насколько предсказуемо он выполняет сложную задачу, когда в процессе участвуют несколько человек, возникают ошибки и каждое важное решение нужно подтвердить.