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