Что можно доверить AI-агенту? Границы автономности

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

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

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

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

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

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

Евгений рассказывает о переносе своей игры с iOS на Android. Он не задавал подробную реализацию: дал исходный проект и предложил сравнивать экраны и механику через эмуляторы обеих платформ. По его словам, агент закончил работу примерно за пять часов без вмешательства. Здесь уже существующая игра стала проверяемым образцом. Александр подчёркивает границу примера: эксперимент не требовал немедленной публикации в магазине и ответственности перед пользователями. Удачный личный проект не доказывает готовность такого же процесса для рабочей системы.

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

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

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

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

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

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

Евгений предлагает искать повторяющиеся ошибки по журналам сессий и превращать наблюдения в изменения процесса. Во Flo Health он описывает эксперимент с анализом множества сессий, чтобы находить общие затруднения и предлагать улучшения. В финале разговор переходит к менеджменту. Навыки постановки задач и управления вниманием становятся нужны инженерам; при этом Евгений сохраняет роль руководителя в согласовании команд и развитии людей. Алексей ожидает более плоских структур. Единого прогноза участники не дают: масштаб и устройство организации остаются существенными условиями.