Менеджер ИИ агентов ведёт реестр отдельных заданий: у каждого есть владелец, допустимые инструменты, состояние, условие остановки и проверяемый результат. Такой контур нужен команде, когда параллельно идут поиск сведений, подготовка черновиков и действия во внутренних системах. Выбор платформы описан в материале о платформе для ИИ агентов; здесь речь об эксплуатации конкретных запусков после выбора стека. Описанный маршрут служит проектным предложением для будущего пилота.
Реестр заданий
Единица контроля — отдельное задание с идентификатором, владельцем, состоянием, разрешёнными действиями и ссылкой на итог. Приёмку результата подтверждает специалист.
Реестр связывает запрос сотрудника с фактическим запуском. До обращения к модели сотрудник указывает цель, источник и ожидаемый артефакт. Например, запрос на сводку по обращениям предполагает чтение разрешённого среза и черновик отчёта. Отправка письма или изменение CRM образуют отдельное действие с отдельным допуском. Такое разделение позволяет увидеть, кто поручил работу, какой агент получил задачу и какие права действовали на момент вызова.
| Поле записи | Что фиксировать | Зачем команде |
|---|---|---|
| Задание | Идентификатор, цель, версия входа | Сопоставлять повторные запуски |
| Владелец | Инициатор и принимающий специалист | Направлять вопросы и исключения |
| Допуск | Источники, инструменты, вид действий | Ограничивать серверные вызовы |
| Итог | Артефакт, статус проверки, ссылка на журнал | Отделять выполнение от приёмки |
В проектной схеме идентификатор создаёт сервер заданий. Он же связывает обновления состояния, подтверждения человека и записи журнала. Для очереди полезно хранить версию входного запроса и контрольную ссылку на исходный документ; тогда исправление требований создаёт понятную новую редакцию. Если один агент подготавливает данные для другого, зависимость отражается ссылкой между заданиями, а доступ к исходным данным второго запуска проверяется заново.
Общий взгляд на роли и развитие команды есть в разборе управления ИИ агентами в компании. Операционный реестр решает более узкую задачу: показывает состояние каждого запуска и доказательство принятого решения, включая отклонённый результат.
Состояния и маршруты
Для будущего пилота удобно согласовать конечный набор состояний: «ожидает», «в работе», «ждёт подтверждения», «завершено», «остановлено», «ошибка» и «принято». Последнее состояние выставляет принимающий специалист после сверки артефакта. Между состояниями нужны разрешённые переходы. Исполнитель сообщает о завершении шага, сервис реестра проверяет допустимость перехода, а владелец принимает итог. Спорный результат возвращают на исправление с сохранением истории.
Официальное руководство LangGraph показывает построение процесса из узлов, переходов и общего состояния. Там же описан шаг с вмешательством человека через interrupt и сохранение состояния для возобновления такого шага. Эти функции помогают описать внутренний ход агентного сценария. Общий реестр команды, матрица прав и процедура остановки всех внешних действий остаются отдельными проектными решениями компании.
- Создайте запись и назначьте принимающего владельца до запуска. Укажите разрешённый вход, ожидаемый выход и условия отказа.
- Передавайте исполнителю идентификатор задания. Обновляйте состояние через серверный маршрут с проверкой предыдущего статуса.
- При необходимости записи во внешнюю систему переводите задание в ожидание подтверждения. Покажите человеку точное действие и объект изменения.
- После исполнения приложите артефакт, список обращений к инструментам и результат проверки. Владелец отмечает приёмку либо возвращает конкретные замечания.
Внутреннее состояние графа и состояние реестра связаны, но решают разные вопросы. Граф знает текущий шаг сценария; реестр показывает ответственному, можно ли доверять итоговому артефакту и требуется ли его участие. При сбое между записью результата и сменой статуса сервис сверяет идентификаторы операций; решение о повторе принимает владелец после проверки внешних последствий.
Допуск инструментов
Лимит инструментов задают на уровне задания, а сервер проверяет его при каждом вызове. Разрешение «читать базу знаний» означает конкретный набор документов и роль доступа, разрешение «создать запись» содержит объект, область данных и необходимость подтверждения. Текст промпта помогает агенту понимать правила работы, но полномочия выдаёт сервер приложения и подключённой системы. Даже корректный черновик команды должен получить отказ, если владелец запретил запись или источник закрыт для данного аккаунта.
В проектном контуре политика состоит из списка разрешённых инструментов, типа действия, источника данных и качественного бюджета вызовов. Бюджет нужен для остановки бесконечного поиска и повторяющихся запросов. Права на чтение и изменение разделяют; общий ключ с широкими полномочиями разрушает смысл допуска. Допуск хранится на сервере, журнал фиксирует версию политики.
Агент предлагает действие и объясняет основание. Сервер сверяет роль, область данных, действующий допуск и подтверждение человека. Внешняя система повторно проверяет полномочия своего аккаунта. Отказ сохраняется как событие задания.
Условный пример: агент собирает выжимку из разрешённых документов и предлагает обновить карточку заявки. Владелец видит текст изменения, исходные ссылки и целевой объект. Пока подтверждение отсутствует, сервер допускает только подготовку черновика. После согласования сервер ещё раз сверяет статус задания и права перед записью. Если карточка уже изменена другим сотрудником, запись переводят в исключение для ручной сверки. Такое правило защищает от повторного применения устаревшего черновика.
Передача нескольких заданий между агентами требует отдельного контроля: исходный агент передаёт ссылку на проверенный результат, принимающий получает собственный допуск и владельца. Предметная проверка выводов описана в разборе регулярной аналитики агентами.
Остановка и журнал
Кнопка «остановить» в реестре должна запускать конкретную процедуру: пометить задание, закрыть новые вызовы инструментов, передать сигнал исполнителю и зафиксировать подтверждение прекращения работы. Запрос на остановку и фактическая остановка различаются. Внешняя операция могла уже уйти в подключённую систему; поэтому после остановки инженер сверяет её итог и отражает обнаруженное действие в журнале.
Журнал содержит идентификатор задания, изменение состояния, вызванный инструмент, тип операции, результат проверки прав, подтверждение владельца и ссылку на артефакт. Секреты, полные чувствительные выгрузки и лишние персональные данные в него помещать нельзя. Для отладки сохраняют безопасные идентификаторы и причины отказов; доступ к самим источникам остаётся в исходных системах. Период хранения и круг читателей согласуют владельцы данных и политики компании.
- При запросе остановки сервер прекращает выдавать новые разрешения на вызовы и фиксирует инициатора.
- Исполнитель подтверждает завершение текущего шага либо возвращает сообщение об ошибке; незавершённые внешние действия получают статус для сверки.
- Ответственный проверяет следы записи в целевой системе и прикладывает решение о продолжении, исправлении или закрытии задания.
Для записей во внешних системах полезен ключ операции, по которому сервер различает повтор доставки и новую команду. Схема восстановления включает сверку результата перед повторным вызовом и отдельное разрешение на повтор. Агент может кратко объяснить расхождение по разрешённым записям, но решение о повторе принадлежит инженеру и владельцу процесса.
Для настройки реестра, стопа и допуска под ваш процесс можно обсудить внедрение ИИ агентов с командой.
Нужен реестр и остановка агентных заданий для вашей команды?
Пилот и приёмка
Будущий пилот лучше ограничить учебным потоком с искусственными данными и понятным принимающим специалистом. Например, агент получает разрешённые заметки, готовит черновик сводки и запрашивает подтверждение перед записью результата в тестовую карточку. Команда заранее описывает ожидаемый артефакт, допустимые источники и отказы. Такой сценарий позволяет сравнить журнал с тестовой системой.
Сначала проверьте обычное завершение: запись реестра связывает запрос, версию входа, черновик и отметку приёмки. Затем смоделируйте запрет на инструмент, отсутствие подтверждения, повторную доставку команды, ошибку внешнего сервиса и остановку при незавершённом действии. Для каждого случая заранее запишите ожидаемый статус и ответственное лицо. Приёмка требует совпадения журнала с фактом в тестовой системе, ясной причины отказа и понятного владельцу следующего действия.
Скрипт сверяет полноту записей, допустимость переходов и совпадение идентификаторов операций. Языковая модель помогает объяснить исключения и предложить причины для расследования. Человек сверяет гипотезы с журналом и исходной системой. Если пилот включает скан PDF, OCR создаёт сигнал о распознанном тексте, а качество чтения проверяет специалист. Черновик BPMN полезен для обсуждения маршрута; инженер отдельно проверяет возможность его исполнения в выбранной системе.
Критерий выхода из пилота — воспроизводимый путь от поручения до принятого результата, включая отказ и остановку. Смета зависит от числа интеграций, сложности разрешений, состояния данных и требований к аудиту. Стоимость обсуждают после описания процесса и проверки контуров доступа. Для старта составьте перечень реальных типов заданий, владельцев и систем записи, затем выберите учебный сценарий для проверки.
Зафиксируйте одно учебное задание, его владельца и разрешённые инструменты. Согласуйте статус после отказа и способ сверки внешнего действия; затем запускайте проверку в тестовом контуре.