Примечание автора: отталкиваясь от принципа «обращаться к человеку только при удалении данных, расходовании денег и смене направления», разберём три критерия для определения границ самостоятельности Agent, устройство канала согласования и распределение задач по проверке с CI.
Когда Agent из собеседника превращается в исполнителя, самое сложное — не запустить его, а понять, когда он должен остановиться. Если проверять каждый шаг, автоматизация превращается в бесконечные ручные подтверждения. Если проверять слишком редко, одно ошибочное удаление или неконтролируемая трата могут свести на нет месяцы повышения эффективности. В этой статье мы разберём вопрос когда Agent должен остановиться и спросить человека и предложим универсальный подход к определению границ самостоятельности.
Это не абстрактное рассуждение в духе «ИИ опасен, будьте осторожны». Мы начнём с реальной системы, о которой её создатель рассказал публично: автор Казике почти год разрабатывал систему автоматизации с Agent. Она обращается к нему за решением через карточки в Feishu только в трёх случаях: при удалении данных, расходовании денег и смене направления. Мы превратим этот принцип в набор критериев и дополним его рекомендациями по устройству канала согласования.
Главное: прочитав статью, вы сможете определить, какие действия можно доверить Agent, а какие требуют подтверждения человека, и узнаете, как устроить канал согласования, который не будет мешать автоматизации и при этом поможет сдерживать риски.
Когда агенту стоит остановиться и спросить человека: 3 типа решений
Система Кадзика предлагает сдержанный ответ: человек подключается только в трёх случаях. В таблице ниже показано, какие это решения и какие риски за ними стоят.
| Решение | Типичные действия | Суть риска | Зачем нужен человек |
|---|---|---|---|
| Удаление данных | Очистка записей в базе данных, удаление файлов, перезапись исторических версий | Необратимость | После выполнения откат может быть очень дорогим или вовсе невозможным |
| Расходование денег | Вызов платных сервисов, закупка ресурсов, массовое расходование квоты на вызовы моделей | Отток средств | Возникают реальные расходы, которые могут многократно вырасти из-за цикла |
| Смена направления | Корректировка тематики контента, изменение стратегии продукта, переписывание установленных правил | Влияние на цели | Агенту не хватает полного бизнес-контекста и понимания ценностных приоритетов |
Где проходит граница человеческих решений в четырёхуровневой архитектуре
Согласно опубликованному краткому описанию, главная идея системы Кадзика — сделать так, чтобы задачи начинались не с человека: работа агента запускается событием, а не вручную. Система состоит из четырёх уровней, и принятие решений человеком находится на последнем. Это «тормоз» всей цепочки, а не «педаль газа».
| Уровень | Задачи | Реализация по открытым данным |
|---|---|---|
| Платформа автоматизации | Централизованное управление запуском по событиям и распределением задач между агентами | Правила централизованно настраиваются в rules.json |
| Уровень выполнения агентов | Непосредственный запуск задач агентов | Работает локально на Mac Mini |
| Платформа CI | Пять этапов: ревью, проверка, слияние, публикация и верификация | Собственная разработка |
| Уровень принятия решений в Feishu | Запрос решения человека в ключевых ситуациях | Карточки Feishu |
В этом разделении виден важный принцип: большинство вопросов «правильно ли сделано?» передаются на автоматическую проверку платформе CI, а человеку достаются только вопросы «стоит ли это делать?». В первом случае есть объективные критерии проверки, во втором приходится учитывать компромиссы и ответственность. Здесь и проходит главная граница участия человека в принятии решений.
Стоит уточнить, что исходный материал — лишь краткое описание. В нём не раскрываются конкретные поля карточек Feishu, частота обращений к человеку и время ответа, а также точное определение «смены направления». Дальнейшие рекомендации по устройству карточек и критериям принятия решений — это развитие описанного принципа, а не пересказ исходной системы.
Как понять, когда агенту стоит остановиться и спросить человека: метод трёх критериев
«Удаление данных, трата денег, смена направления» — хорошая отправная точка, но в реальных системах операций гораздо больше. Если свести их к трём универсальным критериям, можно быстро оценить любое новое действие: обратимость, влияние на затраты и направление работы.
Критерий первый: обратимость показывает, можно ли отменить последствия
Вопрос обратимости звучит так: «Можно ли всё вернуть назад, если что-то пошло не так?» Написать черновик, создать ветку или запустить скрипт в тестовой среде — обратимые действия: в случае ошибки результат можно отбросить и начать заново. А вот удаление данных в рабочей среде, отправка письма внешним адресатам или официальная публикация — необратимые или частично обратимые действия. Отменить их последствия гораздо сложнее, чем выполнить их.
При оценке полезно задать конкретный вопрос: если агент сразу после выполнения обнаружит ошибку, сколько времени и человеческих усилий понадобится на восстановление? Если ответ выходит за пределы допустимого для вас, действие следует отправить на согласование.
Критерий второй: влияние на расходы определяет, нужен ли бюджетный лимит
Влияние на расходы — это не только «сколько мы потратим сейчас», но и «не вырастет ли эта сумма многократно». Главный финансовый риск агента часто связан с циклами: ошибка в логике повторных попыток или слишком широкое условие срабатывания могут привести к тому, что вызовы модели будут повторяться часами. Даже дешёвая операция может обойтись слишком дорого, если её неконтролируемо повторять.
Поэтому на практике стоит установить бюджетные лимиты: агент действует самостоятельно, пока расходы на отдельную операцию и суммарные расходы остаются в пределах лимитов. Если лимит превышен, он останавливается и обращается к человеку. Если агенту нужно вызывать несколько больших языковых моделей, их можно подключить через единую платформу вроде APIYI apiyi.com. Статистика использования будет собрана в одном месте, и вам будет проще следить за суммарными расходами и сравнивать их с лимитами, не переключаясь между кабинетами разных поставщиков.
Критерий третий: влияние на направление определяет, кто отвечает за цели
Влияние на направление — самый размытый из трёх критериев. Речь о том, может ли операция изменить то, «куда мы идём»: например, пересмотреть стратегию выбора тем, изменить настройки правил или приоритеты продукта. Агент хорошо находит оптимальный путь к заданной цели, но плохо справляется с решением о том, нужно ли менять саму цель. Для этого нужно понимать бизнес-контекст, учитывать особенности бренда и брать на себя ответственность.
Практический способ провести границу: если операция меняет собственные правила или цели агента (например, переписывает условия срабатывания в rules.json) либо её результат станет основой для множества последующих задач, считайте её «изменением направления».
| Критерий | Признаки низкого риска | Признаки высокого риска | Рекомендуемый подход |
|---|---|---|---|
| Обратимость | Черновик, ветка, тестовая среда, откат одним нажатием | Удаление, перезапись, публичная публикация, отправка сообщений | При высоком риске обязательно согласование |
| Влияние на расходы | Низкая стоимость операции, суммарные расходы в пределах бюджета | Превышение лимита, возможный многократный рост из-за цикла | В пределах лимита — самостоятельно, за пределами — согласование |
| Влияние на направление | Работа в рамках заданных целей | Изменение правил, целей или долгосрочной стратегии | Всегда передавать решение человеку |
| Общая оценка | Все три риска низкие | Хотя бы один риск высокий | При высоком риске по любому критерию остановиться и обратиться к человеку |
Цена чрезмерных и недостаточных согласований
Установить границы — значит найти баланс между двумя крайностями. И слишком частые, и слишком редкие согласования могут привести к провалу проекта автоматизации с помощью агента, хотя и по разным причинам.
| Ситуация | Как это выглядит | Непосредственное последствие | Долгосрочное влияние |
|---|---|---|---|
| Слишком много согласований | Подтверждение требуется на каждом шаге, карточки накапливаются | Автоматизация превращается в «ручное нажатие кнопок» | Усталость от согласований: люди нажимают «Согласовать», не читая |
| Слишком мало согласований | Даже ключевые операции выполняются самостоятельно | Случайное удаление, перерасход, отклонение от цели | Один инцидент подрывает доверие к системе |
| Разумные границы | Агент останавливается только в трёх типах рискованных ситуаций | Человек решает только те вопросы, где действительно нужно его суждение | Доверие постепенно растёт, агенту можно передавать больше полномочий |
Самый незаметный вред от чрезмерных согласований — «усталость от согласований». Когда человек ежедневно получает десятки карточек для подтверждения, он быстро привыкает нажимать «Согласовать», не читая их. Контроль остаётся только на словах. Это даже опаснее, чем полное отсутствие согласований: все ошибочно считают, что кто-то проверяет действия системы. Именно поэтому система Казика обращается к человеку только в трёх случаях — чтобы каждое такое обращение заслуживало внимательного рассмотрения.
Границы решений Agent: пять шагов к настройке согласования
Ниже — план создания канала согласования с нуля. Он не привязан к конкретному фреймворку: вы можете использовать любой инструмент для обработки событий и любую платформу для обмена сообщениями.
Шаг 1. Составьте список всех действий Agent
Перечислите все инструменты и действия, доступные Agent: например, чтение и запись файлов, удаление записей, вызов внешних API, отправку сообщений и изменение конфигурации. Для каждого действия проставьте метки по трём параметрам, чтобы получился «список рисков действий». Этот список станет основой для всех дальнейших правил и поможет команде договориться о границах.
Шаг второй: централизуйте управление правилами
По примеру Казика, который использует rules.json для управления триггерами и планированием задач, вынесите правила о том, какие действия требуют одобрения, в единый конфигурационный файл. Не стоит разбрасывать их по промптам отдельных агентов. У централизованной конфигурации два преимущества:
- Прозрачность: каждый может увидеть, какие операции сейчас требуют подтверждения человека;
- Гибкость: если границы нужно ужесточить или ослабить, достаточно изменить правила в одном месте.
Обратите внимание: изменение самой конфигурации относится к «смене направления», поэтому делать это должен только человек.
Шаг третий: поручите CI автоматические проверки
Прежде чем обращаться к человеку, позвольте автоматике проверить всё, что она может. CI-платформа Казика включает пять этапов: ревью, проверку, слияние, выпуск и верификацию. Это значит, что к моменту принятия решения человеком такие проблемы, как ошибки форматирования и проваленные тесты, уже отсеяны. Человек не должен выполнять проверки за машину, а машина — принимать решения за человека.
Шаг 4: Спроектируйте карточку решения
Ниже — наши рекомендации по дизайну карточки, а не описание исходной системы. Главный принцип: человек должен принять решение за несколько десятков секунд.
- Одной фразой объясните, что нужно сделать: например, «Удалить черновики, созданные до марта»;
- Укажите выявленные риски: необратимость, превышение бюджета или смену направления;
- Покажите масштаб и стоимость: сколько записей затронуто и сколько предположительно будет потрачено;
- Приведите доводы и подтверждения Agent: почему он предлагает это действие и что показала проверка CI;
- Добавьте понятные кнопки: «Одобрить», «Отклонить» и при необходимости — «Изменить и выполнить».
Шаг 5: Определите тайм-аут и поведение по умолчанию
Человек не может быть на связи постоянно. Заранее определите, сколько времени карточка может оставаться без ответа и что делать по истечении этого срока: не выполнять действие или выполнить его в ограниченном режиме. Для удаления данных, денежных расходов и подобных операций значение по умолчанию должно быть «не выполнять». Лучше оставить задачу в ожидании, чем считать молчание согласием.
🚀 Быстрый старт: на этапе прототипирования рекомендуем сначала использовать единую точку доступа к моделям, чтобы проверить всю цепочку: «Выполнение Agent → проверка CI → утверждение по карточке». Через APIYI apiyi.com можно вызывать различные популярные модели и переключаться между ними, не меняя логику утверждения. Это позволит сравнить, как часто разные модели запрашивают утверждение и насколько убедительно обосновывают свои действия.
Распределение ролей: проверка CI и решения человека
Многие команды задаются вопросом: если CI умеет всё проверять, зачем нужен человек? Дело в том, что они отвечают на разные вопросы. Вот где проходит граница между ними:
| Этап | На какой вопрос отвечает | Основание для решения | Кто отвечает |
|---|---|---|---|
| Ревью / проверка | Соответствует ли результат стандартам | Правила, тесты, формат | Платформа CI |
| Слияние / выпуск | Можно ли переходить к следующему этапу | Все ли проверки пройдены | Платформа CI |
| Подтверждение | Действительно ли изменения вступили в силу | Проверка после выполнения | Платформа CI |
| Удаление данных / расходы / смена направления | Стоит ли это делать | Бизнес-оценка и ответственность | Человек |
| Источник вызова модели | Какую модель использовать и сколько тратить | Лимиты бюджета | Правила конфигурации + контроль человека; для сбора статистики использования можно воспользоваться APIYI apiyi.com |
Часто задаваемые вопросы FAQ
Q1: Что такое граница принятия решений человеком для агента?
Это правило, которое определяет, какие действия агент может выполнять самостоятельно, а какие требуют подтверждения человека. Пока действия остаются в пределах границы, агент работает без остановки. Достигнув границы, он приостанавливается и передаёт решение человеку. Обычно границу определяют по трём критериям: обратимости действий, влиянию на расходы и изменению направления работы.
Q2: Чем согласование человеком отличается от автоматических проверок CI?
CI отвечает на вопрос «Правильно ли это?» с помощью правил и тестов — такую проверку лучше доверить машине. Человек отвечает на вопрос «Стоит ли это делать?», опираясь на понимание бизнес-задач и принимая ответственность за решение. Первое стоит максимально автоматизировать, а второе — оставить только для действительно важных случаев. Вместе они помогают работать быстро и надёжно.
Q3: Как определить такую расплывчатую категорию, как «изменение направления»?
В исходных материалах не сказано, как именно автор определяет эту категорию. Мы предлагаем относить к ней любые действия, которые меняют правила или цели самого агента, а также действия, результаты которых станут основой для множества последующих задач. Если граница неясна, лучше сначала требовать согласования, а затем постепенно расширять самостоятельность агента с учётом практики.
Q4: В каких случаях особенно важно предусмотреть решения человека?
Прежде всего:
— **Очистка данных**: регулярное удаление устаревших записей или файлов;
— **Автоматическая публикация контента**: финальное подтверждение перед публикацией;
— **Массовые вызовы моделей**: платные вызовы, число которых может резко вырасти из-за циклов;
— **Изменение стратегий**: корректировка тематики, правил планирования задач и тому подобного.
Q5: Как контролировать расходы агента на вызовы больших языковых моделей?
Рекомендуется установить два бюджетных порога: для одного вызова и для суммарных расходов. В пределах порогов агент работает самостоятельно, а при их превышении запрашивает согласование. Если сосредоточить вызовы моделей на платформе с единым интерфейсом, такой как APIYI apiyi.com, отслеживать расход относительно порогов и анализировать его будет проще.
Q6: Как быстро проверить, разумно ли установлены границы согласования?
Для начала проведите пробный запуск на небольшом количестве реальных задач. Записывайте ежедневное число запросов на согласование, долю отказов и среднее время ответа. Если запросов много, а доля отказов очень низкая, границы слишком строгие. Если проблемы обнаруживаются только после выполнения действий, границы слишком широкие. На начальном этапе можно запустить один и тот же набор задач с несколькими моделями через APIYI apiyi.com и посмотреть, как часто каждая из них запрашивает согласование.
Q7: Какие ограничения есть у этого подхода?
Согласование зависит от доступности человека и скорости его ответа, поэтому ночью или в праздники задачи могут накапливаться. Если в карточке недостаточно информации, человек тоже может принять неверное решение. Кроме того, исходный материал, на котором основана статья, представляет собой краткое изложение: подробности о случаях ошибочного выполнения действий без согласования и конкретных механизмах защиты пока не опубликованы. При внедрении необходимо дополнить подход механизмами тайм-аутов, журналирования и отката с учётом особенностей своей системы.
Когда агенту стоит остановиться и спросить человека: главное
- Главный принцип: обращаться к человеку только в трёх случаях — при удалении данных, расходовании денег и смене направления. Тогда каждый запрос на согласование будет значимым.
- Три критерия: быстро оценивать любое новое действие по обратимости, влиянию на расходы и направлению работы.
- Чёткое разделение ролей: CI отвечает на вопрос «правильно ли сделано», человек — «стоит ли это делать». Одно не заменяет другое.
- Осторожно, усталость от согласований: если запросов слишком много, человек начинает автоматически нажимать «согласовать». Это опаснее, чем отсутствие согласований.
- Консервативный вариант по умолчанию: если время ожидания истекло, а ответа нет, рискованное действие не выполняется.
- Единая точка доступа: APIYI apiyi.com позволяет централизованно вызывать разные модели, управлять порогами расходов и сравнивать модели.
Итоги
Вопрос о том, когда агенту стоит остановиться и спросить человека, сводится к чёткой границе между эффективностью и риском:
- Начните с трёх типов решений: удаление данных, расходование денег и смена направления охватывают большинство рискованных сценариев;
- Расширьте подход с помощью трёх критериев: обратимость, влияние на расходы и направление работы помогут оценивать любые новые действия;
- Снизьте нагрузку с помощью автоматических проверок: пусть CI отсеивает простые ошибки, а человек занимается только тем, что требует его решения.
Эта граница не устанавливается раз и навсегда: по мере роста доверия её можно постепенно расширять. Начните тестирование со строгих ограничений и на основе данных решайте, где можно дать агенту больше самостоятельности. На этапе построения и настройки процесса удобно использовать APIYI apiyi.com для единого доступа к разным моделям и быстрой проверки того, как они работают в вашей цепочке согласований.
📚 Источники
- 数字生命卡兹克 делится архитектурой системы автоматизации на базе Agent, над которой работал год: источник описанных в статье принципов и архитектуры
- Ссылка:
aihot.news/items/dzwfvd9xp6v4qaj6olxezpier - Описание: представлены четыре уровня архитектуры — платформа автоматизации, исполнение задач агентами, платформа CI и принятие решений в Feishu, — а также принцип «обращаться к человеку только при удалении данных, расходовании денег или смене направления». Это краткое изложение; подробности нужно сверить с оригиналом.
Автор: техническая команда APIYI
Обсуждение: свяжитесь с нами через главную страницу APIYI apiyi.com, чтобы обменяться опытом внедрения автоматизации с помощью агентов и совместной работы людей и ИИ. Дополнительные материалы доступны в документации на docs.apiyi.com.
