ИИДля
← Назад
Разбор / CODE · 29.09.2026 · 08:51

ИИ для проверки шагов агента: журнал действий до кнопки «выполнить»

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

Антон ЛевинРедактор инструментов и кода
Редакционная иллюстрация к материалу «ИИ для проверки шагов агента: журнал действий до кнопки «выполнить»»
Авторская иллюстрация редакции «ИИ Для»
Суть задачи

Нарисуйте границу полномочий

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

Что подготовить

Проверяйте не только цель, но и конкретный вызов

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

Рабочий маршрут

Соберите тесты на отказ

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

Контроль качества

Разберите пример агента для отчёта

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

Пример

Что должно попасть в журнал

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

Границы метода

Проверяйте возможность отката

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

После запуска

FAQ

**Можно ли сразу подключить production?** Нет, сначала изолированный тест и чтение без записи. **Достаточно ли журнала?** Нет: нужны минимальные права, валидация аргументов и контроль владельца процесса. **Что делать при сбое?** Остановить очередь, сохранить безопасный журнал и вернуть задачу ручному исполнителю.

Внедрение

Связанные материалы

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

Перед использованием

Короткая проверка

  • Понятны цель и человек, который примет результат.
  • Исходники очищены, их версия и дата сохранены.
  • Факты, числа и ограничения сверены вручную.
  • Неудачный пример записан вместе с причиной.
  • Есть измеримый следующий шаг и путь назад.
Продолжить тему

Другие материалы этого направления