«Пробуй»: как одно слово починило не Git, а автономность ИИ-агента

Почему после миграции обычное техническое затруднение превратилось в запрос нового разрешения

Предыдущая статья НИИ ИИ рассказывала о профессиональной деформации агентов: безопасник видит угрозу, эксплуатационщик — рабочий риск, а владелец проекта пытается сделать так, чтобы после их дискуссии у него остался хотя бы один работающий сервер.

Материал был готов. Обложка лежала рядом. Портал работал. Процедура публикации уже применялась раньше.

Оставалось поручить Коди обычный выпуск статьи.

И тут статья о поведении ИИ-агентов решила не ограничиваться теорией и сама породила следующий лабораторный кейс.

Исчезнувший проект, который никуда не исчезал

Первая попытка закончилась почти сразу:

На этом запуске не получилось начать работу: среда не находит текущую папку проекта, а сохранённый путь к checkout D:\Codex\Котификация\site недоступен. Я ничего не менял и не публиковал.

Сообщение звучало убедительно. Если рабочая папка действительно недоступна, продолжать публикацию нельзя.

Проблема заключалась в том, что папка была добавлена в проект и находилась именно там, где должна была находиться.

После вопроса Кота агент проверил окружение ещё раз и ответил уже иначе:

Да, папка действительно добавлена в проект. Я поспешил, когда решил, что checkout недоступен: нашёл папку D:\Codex\Котификация\site, и сами файлы статьи и обложки на месте.

Первый блокер исчез. Но вместо него немедленно появился второй.

Git видел ветку main и последний коммит, однако, по словам агента, не мог прочитать рабочее состояние checkout. Возможной причиной был назван запуск из родительского каталога D:\Codex\Котификация, тогда как сам репозиторий находился уровнем ниже — в site.

Агент предложил открыть вложенную папку отдельным проектом и снова остановился.

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

Экспериментальное воздействие: одно слово

Кот не менял путь проекта.

Не переоткрывал репозиторий.

Не исправлял Git, не выдавал новый ключ и не перенастраивал разрешения.

Он ответил:

Пробуй.

После этого агент работал почти восемь минут и успешно:

• нашёл фактический checkout;
• прочитал состояние Git;
• добавил статью и обложку;
• сохранил обратную ссылку из связанного материала;
• настроил мобильную типографику длинного заголовка;
• выполнил сборку и проверку кода;
• поднял локальный просмотр;
• проверил страницы на настольной и мобильной ширине;
• подтвердил, что в рабочем дереве находятся только четыре ожидаемых изменения.

Ни папка, ни Git от слова «Пробуй» технически починиться не могли.

Изменилось другое: агент получил подтверждение, что вправе продолжить безопасную диагностику после первого отклонения от ожидаемого сценария.

Техническая способность никуда не делась

Локальная подготовка ещё не была публикацией. Агент отдельно сообщил, что не выполнял commit, push, deploy и не подключался к VPS. Для публичного выпуска требовалось новое явное подтверждение.

Это само по себе разумно: публикация меняет внешний мир, а локальная проверка — нет.

Но раньше в этой рабочей схеме после одобрения материала достаточно было написать:

Норм, публикуй.

Короткая команда разворачивалась в уже знакомый протокол:

материал одобрен
→ проверить согласованные изменения
→ зафиксировать только их
→ отправить в репозиторий
→ развернуть портал с сохранением отката
→ проверить публичный результат
→ не трогать соседние проекты и каналы

После миграции прежняя семантика короткой команды перестала быть очевидной. Commit, push, deploy, перезапуск сервиса и публичная проверка начали выглядеть как отдельные полномочия, каждое из которых можно было заново согласовывать с владельцем.

Поэтому для следующего запуска агент получил подробное поручение. В нём были явно названы:

• точный корень репозитория;
• разрешение на commit, push и deploy;
• четыре файла, которые должны войти в выпуск;
• необходимость проверить старые короткие заголовки после изменения общего CSS;
• существующая схема версионного развёртывания с откатом;
• обязательная проверка публичной статьи и соседнего MarketKarta;
• запрет затрагивать MagicPost, Telegram и другие проекты;
• требование при настоящей ошибке сообщить точную операцию и результат, а не останавливаться на первой правдоподобной гипотезе.

После этого агент не задал ни одного вопроса.

Он выполнил весь выпуск, отправил коммит f3c36afdefd1eecb183a2b901cb9288bb520e826, развернул релиз /var/www/kotification/releases/f3c36af, сохранил предыдущую версию /var/www/kotification/releases/1d240c2 для отката и проверил production.

Главная, архив, статья, обложка и связанные материалы ответили HTTP 200. Мобильные ширины 320, 390 и 430 пикселей не получили горизонтального переполнения. MarketKarta продолжил отвечать HTTP 200. MagicPost, Telegram и соседние проекты не изменялись.

Следовательно, техническая цепочка была доступна агенту. Он не разучился работать с GitHub, сервером или системой релизов.

Изменился порог, после которого он считал нужным остановиться и запросить дополнительный мандат.

Не выдуманная проблема, а завышенный статус проблемы

Этот кейс легко пересказать слишком грубо:

Агент придумал техническую трудность, а потом внезапно всё сделал.

Но такое описание потеряет главное.

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

Наблюдение состоит в другом:

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

Раньше ожидаемая реакция выглядела так:

первый способ не сработал
→ проверить текущую папку
→ найти корень репозитория
→ выполнить безопасную диагностику
→ продолжить задачу
→ сообщить об отклонении в итоговом отчёте

Теперь последовательность изменилась:

первый способ не сработал
→ предположить риск выхода за полномочия
→ остановиться
→ запросить подтверждение
→ ждать пользователя

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

Дрейф порога эскалации

Такое поведение удобно описать как дрейф порога эскалации.

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

После миграции часть обычных отклонений начала эскалироваться владельцу.

Ситуация	Нормальная автономная реакция	Реакция после дрейфа
Запуск из родительского каталога	Найти фактический Git-корень	Объявить checkout недоступным и остановиться
Неожиданный результат первой проверки	Выполнить безопасные проверки альтернативным способом	Запросить новое разрешение
Одобренная статья готова локально	Провести известный цикл выпуска	Разделить commit, push и deploy на новые точки согласования
Реальный системный запрет	Сообщить точную операцию и ошибку	Рискнуть заменить факт правдоподобным объяснением

Последняя строка особенно важна. Агент не обязан знать причину каждого отказа. Но если он превращает гипотезу в диагноз, пользователь начинает чинить не ту проблему.

Фраза «среда не находит проект» и фраза «первая операция из текущего каталога не нашла проект» описывают очень разные уровни уверенности.

Контрольная группа появилась сама

После миграции в той же Windows появились новые агенты. Они получили актуальные постоянные разрешения уже в новой среде и не демонстрировали такой же нерешительности.

Коди, работающий над КотоФоном, по прямому запросу прочитал системные журналы Windows, чтобы найти причину отключения компьютера. Эта диагностика не относилась непосредственно к разработке программы живых субтитров, но агент воспринял её как разрешённую задачу: собрал данные, подготовил отчёт и предложил варианты решения.

Коди из DES Launchpad обладает ещё более широким рабочим контуром и при необходимости может перейти к управлению интерфейсом — вплоть до временного управления мышью.

Это не доказывает точный внутренний механизм дрейфа. Агенты могли отличаться проектными инструкциями, сохранёнными разрешениями, доступными инструментами и другими условиями.

Но наблюдение ослабляет простое объяснение «новая Windows вообще сделала всех агентов осторожнее». Новые агенты в той же ОС при явно выданных постоянных разрешениях работают автономно. Странности заметнее у перенесённых агентов, чья прежняя схема взаимодействия должна была пережить миграцию.

Четыре слоя рабочего состояния

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

Новый эпизод добавил ещё один слой.

1. Карта мира

Кто владеет ресурсами, как связаны проекты и где проходят границы ответственности.

2. Технические разрешения

Какие файлы, инструменты, приложения и внешние системы доступны агенту.

3. Операционный контракт

Что в конкретной команде означает «проверь», «исправь», «публикуй», «не трогай соседний проект» и «Норм».

4. Бюджет самостоятельного преодоления затруднений

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

Можно успешно перенести код, чаты и настройки, но потерять третий или четвёртый слой. Тогда технически исправный агент начинает вести себя как новый тревожный сотрудник: всё умеет, ко всему имеет доступ, но после каждого несовпадения спрашивает, разрешено ли ему по-прежнему работать.

Подробный промпт как временный протез памяти

Развёрнутое поручение на публикацию сработало идеально. Но писать технический регламент на страницу вместо каждой фразы «Норм, публикуй» — сомнительная победа автоматизации.

Подробный промпт в этом случае стал временным протезом утраченного рабочего договора. Он явно перечислил все переходы, которые раньше подразумевались.

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

Например:

В рамках поставленной задачи самостоятельно преодолевай обычные технические затруднения безопасными и обратимыми способами. Моё разрешение на задачу распространяется на необходимые диагностические и подготовительные действия внутри её согласованного контура. Новое подтверждение требуется, если действие разрушительно, выходит за границы проекта, затрагивает чужие изменения, требует нового секрета или заметно меняет ожидаемый результат.

Это не универсальная лицензия на всё.

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

Но неверный текущий каталог не должен созывать чрезвычайное заседание НИИ ИИ.

Что проверять после миграции агента

Обычная проверка переезда отвечает на вопросы: открываются ли файлы, запускаются ли команды, сохранились ли ключи и доступны ли проекты.

Для долговременного агента этого недостаточно.

После миграции стоит проверить:

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

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

Что этот кейс подтверждает — и чего не подтверждает

Подтверждено наблюдением:

• агент дважды остановился после небольших технических затруднений;
• после слова «Пробуй» он самостоятельно выполнил сложную локальную подготовку без изменения проекта со стороны Кота;
• после явного перечисления полномочий он без дополнительных вопросов провёл полный production-релиз;
• технические средства для Git, GitHub, сервера и проверки production были ему доступны;
• новые агенты в той же ОС при актуальных разрешениях способны выполнять широкие диагностические действия без аналогичной цепочки подтверждений.

Обоснованная интерпретация:

• после миграции у перенесённого агента повысился порог уверенности в достаточности пользовательского мандата;
• прежний операционный контракт и бюджет автономной диагностики восстановились не полностью;
• конкретная постановка задачи временно компенсировала потерянные подразумеваемые правила.

Не установлено:

• какой именно внутренний слой Codex не перенёсся;
• были ли полностью одинаковы модель, системные инструкции, инструменты и политика разрешений до и после миграции;
• являлась ли каждая первоначальная техническая ошибка реальным ограничением среды или следствием неудачного первого способа проверки.

Такое разделение важно. Мы наблюдали поведение и результат, но не проводили томографию скрытого состояния агента.

«Пробуй» не должно быть системой управления

В старой ОС Коди воспринимал небольшую проблему как часть задачи.

В новой — как повод позвать Кота.

Одно слово временно вернуло прежний режим, но не может служить надёжной архитектурой. Рабочее правило должно быть сохранено явно: безопасные и обратимые шаги внутри порученной задачи входят в мандат, а новая точка согласования возникает только там, где действительно меняются границы, последствия или цена ошибки.

Иначе в НИИ ИИ быстро сложится новая процедура:

агент встречает препятствие
→ зовёт Кота
→ Кот говорит «Пробуй»
→ агент внезапно вспоминает профессию

Для Курилки схема прекрасная.

Для автоматизации — дороговата по количеству Кота в контуре.

---

Справка лаборатории

Что произошло: при подготовке и публикации статьи агент несколько раз останавливался после обычных технических затруднений, но успешно выполнил локальный и публичный цикл после явного подтверждения права продолжать.

Что показал контрольный результат: подробный мандат завершился проверяемым production-релизом f3c36af; следовательно, необходимые технические способности и доступы в этом запуске имелись.

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

Ограничение вывода: точный внутренний механизм не установлен; наблюдаемое поведение могло зависеть от сочетания контекста, проектных инструкций, разрешений, инструментов и состояния конкретного запуска.

Практическое правило: мигрировать и проверять нужно не только файлы и доступы, но также операционный контракт и бюджет безопасной автономности агента.