Демо собирается за неделю. Оно показывает хороший результат, проект согласуют, а дальше пилот полгода не может дойти до эксплуатации. К этому моменту команде обычно предлагают взять модель поумнее, и это ничего не меняет.
Фраза «мы сделали агента» чаще всего означает, что кто-то взял модель и написал к ней промпт. Агентом систему делает всё остальное: то, как она решает, что делать дальше, к чему ей позволено обращаться и что потом можно восстановить. Эту обвязку называют agentic harness, или просто harness.
Разделять модель и harness стоит по практической причине. Модель вы поменяете, когда следующая подешевеет или станет умнее. В аккуратно сделанной системе переход стоит перепрогона оценок. В неаккуратной он превращается в отдельный проект: вместе с моделью меняется поведение инструментов и разъезжаются промпты. Harness живёт дольше. Он описывает, как устроена ваша работа и что агенту в ней разрешено. Этот код вы пишете сами, и он остаётся вашим независимо от того, чью модель вы используете в следующем квартале.
Из чего состоит harness
Шесть частей. Рядом с каждой — как она выглядит, когда сломана.
- Цикл определяет, что происходит после каждого шага: продолжать, переспросить, остановиться, позвать человека. Сломан — агент крутится на месте до упора в лимит или уверенно доводит до конца сценарий, который надо было прервать на втором шаге.
- Инструменты задают, что агент физически может вызвать. Дальше начинаются обычные интеграции с CRM, базой, почтой и внутренним API, и ломается чаще всего именно там. Сломаны — агент получил ошибку вместо документа и продолжает рассуждать так, будто документ у него есть.
- Контекст решает, что агент видит сейчас и что помнит между запусками. Сломан — он делает второй раз то, что уже сделал, или теряет условие, названное ему в самом начале.
- Границы задают, чего агент не может в принципе и чего не может без человека: роли, лимиты, подтверждение на дорогих операциях. Сломаны — агент делает то, на что ему никто сознательно прав не давал, и узнают об этом по последствиям.
- Оценка говорит, стало ли лучше после смены модели или правки промпта. Сломана — «стало лучше» остаётся ощущением, которое нельзя ни подтвердить, ни оспорить.
- Журнал показывает, что именно агент сделал и почему: вход, вызванный инструмент, подтверждение и его автор, результат, версия модели и промпта. Сломан — на «что он делал во вторник» ответа нет.
Эти же шесть частей мы разбирали в докладе. Запись в конце страницы.
Почему демо доезжает, а продакшен нет
В демо ничего из этого не нужно. Сценарий один, данные подготовлены заранее, ошибиться негде, а если агент выдаст глупость, все посмеются и покажут следующий слайд.
Согласование договора мы автоматизируем в своём продукте АА.Докс. На демо агент разбирает один договор, находит расхождение с шаблоном и предлагает правку.
В эксплуатации тот же процесс выглядит иначе. Приходит скан вместо текста и приложение к договору в формате, которого не было в примерах. Система документооборота отдаёт ошибку вместо файла. Юрист правит пункт руками, и агент об этом не узнаёт. Тогда и выясняется, что цикл не умеет останавливаться, контекст не переживает перезапуск, а восстановить последовательность действий невозможно, потому что её никто не записывал.
Вопрос, на котором заканчиваются пилоты
Спрашивают не «справится ли модель», а «кто отвечает, если агент ошибся». Пока ответа нет, служба безопасности справедливо не пускает систему в контур.
Ответ собирается из ролей, лимитов, обязательного подтверждения на дорогих операциях и журнала каждого действия — то есть из двух частей списка выше: границ и журнала. Мы работали внутри контура крупного банка и промышленного холдинга: регламенты, проверки безопасности, интеграции с внутренним ландшафтом. Это обычные требования к любой системе с доступом к рабочим данным. В случае с агентом спрашивают строже только потому, что решение он принимает сам.
Что проверить в своём пилоте
Шесть частей выше — про симптомы. Шесть вопросов ниже — про причину: часть, за которую в компании никто не отвечает, никто и не починит.
- Цикл: кто решал, в какой момент агент останавливается и зовёт человека?
- Инструменты: кто держит полный список систем, к которым агент подключён, и сверялся ли этот список с тем, что реально в коде?
- Контекст: сколько живёт то, что агент помнит между запусками, и кто решает, когда это стереть?
- Границы: какие операции требуют подтверждения человека — и кто он по должности?
- Оценка: на каком наборе случаев видно, что после смены модели не стало хуже, и кто его поддерживает?
- Журнал: что в записи убедит внутренний аудит и кто это проверял?
Вопросы без ответа — это и есть та часть работы, которую пилот не сделал.
Как мы к этому пришли
Собирая агентов под разные процессы, мы каждый раз писали эту обвязку заново: роли, лимиты, согласования, журнал, коннекторы к чужим системам. В какой-то момент вынесли её в отдельный продукт — так появилась AgentArea: слой контроля с открытым кодом, который разворачивается в вашем контуре. В нём 500+ готовых интеграций, и писать их заново уже не придётся. Код открыт намеренно: github.com/agentarea/agentarea можно показать своей службе безопасности до разговора с нами. На нём работают два наших продукта, поэтому внедрение у клиента начинается не с пустого репозитория.
Если ваш пилот застрял, напишите, какой это процесс и в какой из шести частей у вас дыра. С этого и начнём.