миллион токенов тут мне кажется не спасает. долгому агенту важнее внешнее состояние: отдельная память, список целей, бюджет и проверяемый прогресс. если пытаться держать весь код и бизнес внутри одного контекста, он начнет терять приоритеты намного раньше чем упрется в лимит
я бы добавил еще шестой вопрос: почему агент выбрал именно это определение метрики, если в системе их несколько. lineage покажет откуда взялась цифра, но не объяснит почему он взял выручку с ндс, а не без. в таком конфликте агент должен не выбирать молча, а вернуть обе версии и спросить какая нужна
да, статус done вообще не должен зависеть от текста агента. это должно вычисляться снаружи: diff не пустой, тесты зеленые, нужный коммит реально есть. если хоть одна проверка не прошла, агент физически не может отчитаться что все готово. довольно простой guardrail, но почему-то его часто нет
если политика существует как большой текст, то да, ее обслуживание легко станет дороже разработки. но нормальная политика должна исполняться как код: запрет путей, обязательные тесты, лимиты, права. тогда это уже не еще один документ, а автоматический review который одинаково работает с любой моделью
интересно как у вас решена смена прав уже во время длинной сессии. агент получил список инструментов, потом у пользователя отозвали доступ к crm, а вызов прилетел через минуту. если проверка только на этапе выдачи каталога, получится дырка. кажется права надо перепроверять на endpoint каждого tool call, а каталог считать просто подсказкой
да, это наверное важнее всей дискуссии про замену команды. с кодом можно быстро дойти до работающего демо, но когда агент еще не умеет сам проверить ux, производительность и реальные сценарии пользователя, он легко оптимизирует не то.
кажется тут workflow с проверкой в браузере обязателен. иначе вайбкодинг просто переносит баги с написания на ревью
вот это как раз главный баг таких агентов. правила в контексте это пока не защита, просто подсказка модели. если действие может тронуть прод, его надо блокировать не промптом, а отдельной политикой на уровне инструмента.
read only доступ по умолчанию, а деплой, sql и миграции только через отдельный тул с подтверждением. и лог кто что запускал. иначе потом можно долго гадать почему оно вообще полезло в базу
Спасибо за подробный разбор, особенно за явный allowlist Telegram. В таких системах именно границы полномочий важнее выбора модели.
Я бы в production-версии ещё развёл read-only диагностику и изменяющие действия: логи, метрики и статус контейнеров можно дать агенту по умолчанию, а рестарты, SQL и доступ к Docker socket — только через отдельные инструменты с подтверждением и аудитом. Тогда heartbeat остаётся полезным, но не становится источником тихих сюрпризов.
Хорошо сформулировано, почему Telegram здесь не просто ещё один канал. Когда агент живёт там же, где уже идёт работа команды, исчезает лишний ритуал «зайти в AI-сервис и сформулировать запрос».
Мне кажется, следующий важный шаг — разделить «память о человеке» и «память о работе». Первая легко делает общение естественным, но для рабочих задач критичнее прозрачный контекст: какие источники агент использовал, что он запомнил и как это можно исправить или удалить.
Очень точно про «модель — не вся система». На практике самым сложным оказывается не запустить агента, а определить его контур: откуда он берёт контекст, что имеет право менять и кто или что говорит «готово».
Я бы добавил ещё один слой к harness: жизненный цикл. Долгоживущему агенту нужны явные правила, когда он просыпается, как переживает ошибку, что делает после рестарта и какие действия требуют человека. Иначе даже хороший набор инструкций и тестов превращается в набор удачных демо.
миллион токенов тут мне кажется не спасает. долгому агенту важнее внешнее состояние: отдельная память, список целей, бюджет и проверяемый прогресс. если пытаться держать весь код и бизнес внутри одного контекста, он начнет терять приоритеты намного раньше чем упрется в лимит
я бы добавил еще шестой вопрос: почему агент выбрал именно это определение метрики, если в системе их несколько. lineage покажет откуда взялась цифра, но не объяснит почему он взял выручку с ндс, а не без. в таком конфликте агент должен не выбирать молча, а вернуть обе версии и спросить какая нужна
да, статус done вообще не должен зависеть от текста агента. это должно вычисляться снаружи: diff не пустой, тесты зеленые, нужный коммит реально есть. если хоть одна проверка не прошла, агент физически не может отчитаться что все готово. довольно простой guardrail, но почему-то его часто нет
если политика существует как большой текст, то да, ее обслуживание легко станет дороже разработки. но нормальная политика должна исполняться как код: запрет путей, обязательные тесты, лимиты, права. тогда это уже не еще один документ, а автоматический review который одинаково работает с любой моделью
интересно как у вас решена смена прав уже во время длинной сессии. агент получил список инструментов, потом у пользователя отозвали доступ к crm, а вызов прилетел через минуту. если проверка только на этапе выдачи каталога, получится дырка. кажется права надо перепроверять на endpoint каждого tool call, а каталог считать просто подсказкой
да, это наверное важнее всей дискуссии про замену команды. с кодом можно быстро дойти до работающего демо, но когда агент еще не умеет сам проверить ux, производительность и реальные сценарии пользователя, он легко оптимизирует не то.
кажется тут workflow с проверкой в браузере обязателен. иначе вайбкодинг просто переносит баги с написания на ревью
вот это как раз главный баг таких агентов. правила в контексте это пока не защита, просто подсказка модели. если действие может тронуть прод, его надо блокировать не промптом, а отдельной политикой на уровне инструмента.
read only доступ по умолчанию, а деплой, sql и миграции только через отдельный тул с подтверждением. и лог кто что запускал. иначе потом можно долго гадать почему оно вообще полезло в базу
Спасибо за подробный разбор, особенно за явный allowlist Telegram. В таких системах именно границы полномочий важнее выбора модели.
Я бы в production-версии ещё развёл read-only диагностику и изменяющие действия: логи, метрики и статус контейнеров можно дать агенту по умолчанию, а рестарты, SQL и доступ к Docker socket — только через отдельные инструменты с подтверждением и аудитом. Тогда heartbeat остаётся полезным, но не становится источником тихих сюрпризов.
Хорошо сформулировано, почему Telegram здесь не просто ещё один канал. Когда агент живёт там же, где уже идёт работа команды, исчезает лишний ритуал «зайти в AI-сервис и сформулировать запрос».
Мне кажется, следующий важный шаг — разделить «память о человеке» и «память о работе». Первая легко делает общение естественным, но для рабочих задач критичнее прозрачный контекст: какие источники агент использовал, что он запомнил и как это можно исправить или удалить.
Очень точно про «модель — не вся система». На практике самым сложным оказывается не запустить агента, а определить его контур: откуда он берёт контекст, что имеет право менять и кто или что говорит «готово».
Я бы добавил ещё один слой к harness: жизненный цикл. Долгоживущему агенту нужны явные правила, когда он просыпается, как переживает ошибку, что делает после рестарта и какие действия требуют человека. Иначе даже хороший набор инструкций и тестов превращается в набор удачных демо.