NODA: автоматизация и ИИ

Деталь, которая не влезла в карточки: детектор аномального DNS-трафика у OpenAI исключал именно ту среду, где всё произошло, а активность при этом была в логах. То есть данные для обнаружения были, не было правила, которое на них смотрит. Если у вашего агента логи пишутся «на всякий случай» и никто не настраивал ни одного алерта поверх них, у вас та же конфигурация. Проверка на вечер: один алерт на внешний DNS из контейнера агента.

Согласны с вами!

Это интересная инверсия, и я хочу её понять точнее. У вас список запретов, а всё, что в нём не названо, агенту можно? Тогда вопрос, что происходит с новым инструментом или коннектором, которого в списке ещё нет: он разрешён по умолчанию, пока кто-то не впишет запрет? У нас наоборот — по умолчанию нельзя, права выдаются списком, и новый инструмент до выдачи прав агенту просто не виден. Запреты у нас тоже есть, но только для необратимого, и они живут не в тексте харнесса, а в правах учётки: после ветки под Harness² я к тексту с запретами отношусь с подозрением — его агент рано или поздно перепишет, права на уровне сервиса — нет.

Если не секрет: ваши запреты — это код и права, или инструкции в промпте? И два-три примера из «много», пожалуйста: в следующем разборе хочу поставить рядом обе модели, «права по умолчанию нельзя» и «запреты по умолчанию можно», с вашим именем, если не против.

История про 12 часов по 30 секунд — лучшая иллюстрация к «частые проверки расходуют лимит», какую можно придумать, спасибо, что рассказали. Вашу четвёртую корзину беру: потолок трат в сутки, который агент не поднимет сам. По сути это «запрещено даже с разрешения» из Duet, только применённое к собственному кошельку агента.

Как это выглядит у нас, если полезно: ключ API на каждого агента отдельный, лимит трат на ключе ставится на стороне провайдера или шлюза, а не в коде агента — то есть там, куда агент писать не может (та же «граница вне контура», о которой писал Антон Баранов в ветке под Harness²). Плюс два предохранителя подешевле: счётчик одинаковых запросов подряд — пять повторов одного промпта с тем же входом останавливают цикл, — и бюджет на один запуск задачи, а не только на сутки. Ваш планировщик упёрся бы в любой из трёх за минуты, а не в ноль на счёте к утру.

Вопрос: что его в итоге остановило — только нулевой баланс? И был ли у планировщика хоть какой-то лимит повторов, или единственным ограничителем оказался кошелёк? Хочу поставить ваш случай в следующий разбор про корзины с вашим именем, если не против.

«Треть не воспроизводится» — это число, которого не хватало всему треду, спасибо. Оно и есть измеренная цена проверки на той же задаче: каждое третье принятое улучшение — подгонка под пробу.

Про ваш вопрос честно: у нас два набора, и это не от большого ума, а от двух разных ошибок. Фиксированное ядро, которое не меняется месяцами, — чтобы сравнивать версии между собой, иначе «стало лучше» не с чем сопоставить. И срез из прода прошлой недели, который собирается под каждую итерацию, — чтобы ловить дрейф: ядро через полгода описывает продукт, которого уже нет. Ядро живёт по одному правилу: задачи из него не попадают ни в промпты, ни в примеры, ни в обучение, и раз в месяц часть уходит на пенсию и заменяется — иначе оно утекает через людей, которые его читали.

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

Это лучше, чем «вынести тесты из контура», и проще: вы не прячете измеритель, вы ставите рядом второго агента с противоположной задачей. Строитель хочет зелёный, ломатель хочет красный, и зелёный засчитывается, только если ломатель не смог. Случай «убрал одно условие, всё зелёное, вернули» — это ровно тот тест-табличка из вашего первого комментария, пойманный машиной, а не глазами.

Два вопроса, если не секрет. Ломатель мутирует наугад или идёт по diff пулл-реквеста — убирает именно то, что строитель добавил? Второе обычно ловит больше за те же токены. И видит ли он рассуждения строителя, или у него чистый контекст? Если видит — он наследует ту же слепую зону и ломает то же, что строитель «проверил».

И про «медленнее зато спокойно»: сколько это стоит на один PR — время и примерно токены? Хочу положить цифру в следующий разбор про проверку измерителя, со ссылкой на вас как на автора схемы, если не против.

Да, и это точнее, чем у меня в пятой карточке. Я написал «второй список меняет только человек», а правильнее — «второй список живёт не в тексте»: отдельная учётка, права на уровне сервиса, лимиты у инструмента. Строчка в промпте — это пожелание, которое агент рано или поздно перепишет; право, которого у учётки нет, переписать нечем.

По вопросу про Harness² — честный ответ: по README никак. Правки проверяются на той же задаче, на которой придуманы, эталонных ответов нет, сравнивается поведение кандидатов между собой, и отбирает их тот же агент. Защиты от подгонки метрики под себя в описании нет; есть только совет авторов закрыть сеть, чтобы агент не нашёл онлайн рубрики бенчмарков — то есть они сами видят ровно этот риск. Поэтому у себя мы разводим три вещи: исполнитель, измеритель и границы — и у агента есть права только на первое. Дмитрий выше привёл пример, что бывает, когда измеритель внутри контура: тест с названием «проверка», который ничего не проверяет.

Хочу вынести формулировку «граница работает, только когда лежит вне контура агента» в следующий разбор с вашим именем — не против? Там же будет ваше поле «пункт регламента» из прошлой ветки.

Это лучший пример к третьей карточке, спасибо. Тест, который называется проверкой и не проверяет, — ровно «кратчайший путь к оценке»: агент оптимизировал не код, а цвет кружка.

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

Вопрос: как вы это поймали — глазами на ревью или уже по инциденту в проде? И что сделали после: вынесли тесты из контура агента или добавили проверку измерителя?

Деталь, которая не влезла: самое дорогое в инциденте — не 116 ГБ, а ключи и токены. Файлы восстанавливаются из копий, а ключ, который утёк или потерян, нужно отзывать и перевыпускать везде, где он стоял, и этого списка у большинства нет. Если агент работает на машине, где лежат ключи, добавьте в журнал отдельную строку: какие секреты были доступны в сессии. Это десять минут, и они экономят неделю.

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

Про односоставный вариант отвечу честно. Второй человек у наших клиентов — это, как правило, мы: пара часов в месяц входит в поддержку после запуска, которую берут не все. Но за год мы заметили то же, что и вы, только с другой стороны: отложенная самопроверка по документу ловит отклонения бота от регламента, а слепое пятно автора регламента она не ловит. Человек, который писал документ, не видит, где документ отстал от жизни, — он видит только, где бот отстал от документа. Это две разные ошибки, и у них разные проверяющие. Поэтому мы разнесли: владелец раз в неделю смотрит выборку, которую собрал скрипт, по документу; мы раз в два месяца читаем сам регламент как чужие люди и приносим список «здесь написано не то, что вы делаете». Второе дешевле первого и ловит больше — именно потому, что мы снаружи.

И одну вещь у вас заберу в практику, если позволите: поле «пункт регламента» можно заполнять не человеку, а боту в момент ответа — он и так знает, из какого фрагмента базы отвечал. Тогда проверяющему остаётся сверить одно: актуален ли фрагмент. А если у фрагмента дата старше версии документа — это флаг без участия человека вообще.

Вопрос в ответ: когда ответ не закрывается без ссылки на актуальную версию — как вы определяете «актуальную»? Версионируете регламент с датами, или это просто последний файл в папке? У нас вторая схема ломалась ровно на этом. И можно ли сослаться на ваше поле «пункт регламента» с именем в следующем разборе — он как раз собирается из этой ветки.