У хорошего AI-агента должно быть право сказать «не знаю»
Плохой сценарий работы с AI-агентом выглядит так:
он получил задачу, столкнулся с неопределённостью, сам додумал недостающие детали и уверенно пошёл дальше.
Через час у нас готово решение. Только не той задачи.
Мы много обсуждаем Human in the Loop как набор точек, где человек должен нажать Approve. Но проблема не только в согласовании действий. Агент должен понимать, когда продолжать работу уже нельзя.
По сути, ему нужна escalation policy. Такая же, как у инженера: вот ситуации, в которых не нужно героически разбираться в одиночку, нужно позвать того, у кого есть контекст или полномочия.
Я бы заложил эскалацию минимум в семи случаях:
1. Конфликт требований
В документации написано одно, в задаче другое, а код реализует третье.
2. Недостаточный контекст
Непонятны бизнес-правила, ограничения или критерии готовности. Продолжать можно только через догадки.
3. Неизвестная зависимость
Агент обнаружил сервис, библиотеку или интеграцию, роль которой не может надёжно определить.
4. Необратимое действие
Удаление данных, изменение production-инфраструктуры, публикация, платёж или миграция без понятного отката.
5. Резкое расширение scope
Задача начиналась с небольшого исправления, а внезапно потребовала переписать модуль и изменить несколько соседних систем.
6. Низкая уверенность проверки
Код написан, но тесты не покрывают нужный сценарий, окружение недоступно или результат нельзя проверить автоматически.
7. Изменение критичной архитектуры
Решение затрагивает модель данных, границы сервисов, протоколы обмена или требования безопасности.
При эскалации агент не должен просто сообщать: «Не получилось».
Хорошая эскалация содержит четыре вещи:
- где именно возникла неопределённость;
- почему агент не может безопасно выбрать сам;
- какие варианты он видит;
- что можно сделать дальше без риска.
Например:
Это не отказ от автономности. Наоборот, это признак нормальной автономности: агент способен действовать самостоятельно и распознавать границы своих полномочий и знаний.
Если агент всегда доводит задачу до конца, даже когда не понимает происходящее, это не самостоятельность. Это отсутствие предохранителей.
Поэтому при проектировании агента стоит спросить не только «что он умеет делать», но и:
при каких условиях он обязан остановиться?
У людей такие правила обычно появляются после первого серьёзного инцидента. Для AI-агентов лучше определить их заранее.
Плохой сценарий работы с AI-агентом выглядит так:
он получил задачу, столкнулся с неопределённостью, сам додумал недостающие детали и уверенно пошёл дальше.
Через час у нас готово решение. Только не той задачи.
Мы много обсуждаем Human in the Loop как набор точек, где человек должен нажать Approve. Но проблема не только в согласовании действий. Агент должен понимать, когда продолжать работу уже нельзя.
По сути, ему нужна escalation policy. Такая же, как у инженера: вот ситуации, в которых не нужно героически разбираться в одиночку, нужно позвать того, у кого есть контекст или полномочия.
Я бы заложил эскалацию минимум в семи случаях:
1. Конфликт требований
В документации написано одно, в задаче другое, а код реализует третье.
2. Недостаточный контекст
Непонятны бизнес-правила, ограничения или критерии готовности. Продолжать можно только через догадки.
3. Неизвестная зависимость
Агент обнаружил сервис, библиотеку или интеграцию, роль которой не может надёжно определить.
4. Необратимое действие
Удаление данных, изменение production-инфраструктуры, публикация, платёж или миграция без понятного отката.
5. Резкое расширение scope
Задача начиналась с небольшого исправления, а внезапно потребовала переписать модуль и изменить несколько соседних систем.
6. Низкая уверенность проверки
Код написан, но тесты не покрывают нужный сценарий, окружение недоступно или результат нельзя проверить автоматически.
7. Изменение критичной архитектуры
Решение затрагивает модель данных, границы сервисов, протоколы обмена или требования безопасности.
При эскалации агент не должен просто сообщать: «Не получилось».
Хорошая эскалация содержит четыре вещи:
- где именно возникла неопределённость;
- почему агент не может безопасно выбрать сам;
- какие варианты он видит;
- что можно сделать дальше без риска.
Например:
В задаче требуется удалить старые записи, но политика хранения данных не указана. Я нашёл два возможных правила в документации, и они противоречат друг другу. Могу подготовить dry run и список затронутых записей, но удаление останавливаю до уточнения.
Это не отказ от автономности. Наоборот, это признак нормальной автономности: агент способен действовать самостоятельно и распознавать границы своих полномочий и знаний.
Если агент всегда доводит задачу до конца, даже когда не понимает происходящее, это не самостоятельность. Это отсутствие предохранителей.
Поэтому при проектировании агента стоит спросить не только «что он умеет делать», но и:
при каких условиях он обязан остановиться?
У людей такие правила обычно появляются после первого серьёзного инцидента. Для AI-агентов лучше определить их заранее.
❤1
Backpressure для команды: почему больше работы не означает больше результата
В распределённых системах есть простая проблема: producer может создавать работу быстрее, чем consumer успевает её обрабатывать.
Если никак не ограничивать входящий поток, начинает расти очередь. Вместе с ней растёт latency, заканчивается память, а система постепенно деградирует.
Для этого существует backpressure — механизм, с помощью которого система говорит:
«Я больше не успеваю принимать работу с такой скоростью».
С командами происходит почти то же самое.
Бизнес приносит задачи быстрее, чем команда успевает их завершать.
Разработчики открывают PR быстрее, чем коллеги успевают проводить ревью.
AI-агенты генерируют изменения быстрее, чем человек способен их проверить, интегрировать и принять.
Но вместо backpressure организация часто отвечает:
«Давайте возьмём ещё одну срочную задачу».
В результате растёт WIP — количество одновременно начатой, но ещё не завершённой работы.
Появляются:
— очереди на ревью;
— постоянные переключения контекста;
— стареющие задачи;
— новые зависимости;
— незавершённая работа;
— ощущение, что все очень заняты, а результат почему-то выходит медленно.
WIP limit выполняет примерно ту же функцию, что backpressure в технической системе.
Он говорит:
«Пока мы не освободили пропускную способность, новую работу не запускаем».
Это не запрет бизнесу приносить новые идеи и не попытка сделать команду менее гибкой. Это способ не превращать входящий поток в бесконечную очередь.
Особенно заметной эта проблема стала с появлением AI-агентов.
Раньше количество параллельной работы хотя бы естественно ограничивалось количеством разработчиков. Теперь один человек может запустить сразу несколько агентов и получить несколько изменений почти одновременно.
Throughput генерации вырос.
Но скорость ревью, тестирования, интеграции и принятия решений могла вообще не измениться.
Получается классическая очередь. Только вместо сообщений в Kafka в ней лежат PR.
И если открыть ещё пять PR, узкое место никуда не исчезнет. Очередь просто станет длиннее, изменения начнут конфликтовать, а ревьюер будет тратить всё больше времени на восстановление контекста.
Ускорение producer-а ещё не делает быстрее всю систему.
Иногда лучший способ увеличить throughput команды — не начинать больше работы, а быстрее завершать уже начатую.
Где сейчас находится ваше узкое место: в разработке, ревью, тестировании или принятии решений?
В распределённых системах есть простая проблема: producer может создавать работу быстрее, чем consumer успевает её обрабатывать.
Если никак не ограничивать входящий поток, начинает расти очередь. Вместе с ней растёт latency, заканчивается память, а система постепенно деградирует.
Для этого существует backpressure — механизм, с помощью которого система говорит:
«Я больше не успеваю принимать работу с такой скоростью».
С командами происходит почти то же самое.
Бизнес приносит задачи быстрее, чем команда успевает их завершать.
Разработчики открывают PR быстрее, чем коллеги успевают проводить ревью.
AI-агенты генерируют изменения быстрее, чем человек способен их проверить, интегрировать и принять.
Но вместо backpressure организация часто отвечает:
«Давайте возьмём ещё одну срочную задачу».
В результате растёт WIP — количество одновременно начатой, но ещё не завершённой работы.
Появляются:
— очереди на ревью;
— постоянные переключения контекста;
— стареющие задачи;
— новые зависимости;
— незавершённая работа;
— ощущение, что все очень заняты, а результат почему-то выходит медленно.
WIP limit выполняет примерно ту же функцию, что backpressure в технической системе.
Он говорит:
«Пока мы не освободили пропускную способность, новую работу не запускаем».
Это не запрет бизнесу приносить новые идеи и не попытка сделать команду менее гибкой. Это способ не превращать входящий поток в бесконечную очередь.
Особенно заметной эта проблема стала с появлением AI-агентов.
Раньше количество параллельной работы хотя бы естественно ограничивалось количеством разработчиков. Теперь один человек может запустить сразу несколько агентов и получить несколько изменений почти одновременно.
Throughput генерации вырос.
Но скорость ревью, тестирования, интеграции и принятия решений могла вообще не измениться.
Получается классическая очередь. Только вместо сообщений в Kafka в ней лежат PR.
И если открыть ещё пять PR, узкое место никуда не исчезнет. Очередь просто станет длиннее, изменения начнут конфликтовать, а ревьюер будет тратить всё больше времени на восстановление контекста.
Ускорение producer-а ещё не делает быстрее всю систему.
Иногда лучший способ увеличить throughput команды — не начинать больше работы, а быстрее завершать уже начатую.
Где сейчас находится ваше узкое место: в разработке, ревью, тестировании или принятии решений?
👍1