Динамические приложения могут адаптировать рабочие процессы в реальном времени по мере изменения задач, сокращая необходимость навигации и повторного ввода данных для пользователя, а также предоставляя агентам структурированные пути.
Большинство рабочих процессов в приложениях проектируются заранее. Мы решаем, какой экран идет первым, какие поля появляются в форме и что происходит после того, как пользователь нажимает кнопку отправки. Путь может разветвляться в зависимости от роли или состояния учетной записи, но приложение все равно следует поведению, запрограммированному нами заранее.
ИИ дает нам возможность адаптировать рабочий процесс прямо во время выполнения задачи. Например, модель может интерпретировать намерения пользователя, поиск может предоставить актуальный контекст, а агент может проверить состояние приложения перед тем, как решить, какое действие запросить. После этого интерфейс может отобразить информацию или элементы управления, соответствующие текущей задаче.
В этом и заключается идея динамического приложения. Часть рабочего процесса может изменяться в зависимости от контекста пользователя, состояния приложения и активности агента, в то время как само приложение сохраняет контроль над разрешениями, валидацией и бизнес-правилами.
От фиксированных рабочих процессов к динамическим
Рассмотрим приложение для учета расходов. Стандартный сценарий может требовать от пользователя загрузить чек, ввести название продавца, выбрать категорию, указать центр затрат и отправить расходы на рассмотрение. Некоторые шаги существуют потому, что приложению требуется информация, которую оно не может получить самостоятельно.
В рабочем процессе на базе ИИ модель может извлечь данные о продавце и общую сумму из чека. Код приложения может загрузить центр затрат сотрудника, а система поиска — найти политику, применимую к данным расходам. Если единственным недостающим значением является код проекта, интерфейс может запросить именно его, вместо того чтобы отображать всю форму целиком.
Нам по-прежнему потребуется та же самая проверенная запись о расходах перед отправкой, но приложение может адаптировать путь ее достижения на основе уже имеющейся информации. Это разделение означает, что мы можем хранить состояния рабочего процесса и бизнес-правила в коде, позволяя уровню ИИ помогать в выборе наиболее полезного следующего шага.
Контекст делает интерфейс адаптивным
Чтобы приложение эффективно адаптировалось, ему нужно понимать нечто большее, чем просто немедленный запрос. Ему также необходим контекст выполняемой задачи.
Большая часть этого контекста уже существует в системах, которые мы создаем сегодня. Фронтенд знает, какая запись открыта, какое представление активно и что выбрал пользователь. Бэкенд знает разрешения пользователя, состояние учетной записи и связанные записи. Поиск может добавлять документацию или правила, а управляемая приложением память может предоставлять предпочтения, которые остаются полезными в течение сеансов.
Возьмем в качестве примера инженера техподдержки, открывающего тикет по выставлению счетов. Приложение уже знает клиента, оспариваемый счет и разрешения инженера. Агент может изучить недавние платежи и запросить политику возврата средств. Вместо того чтобы открывать несколько вкладок и вручную собирать ту же информацию, инженер может начать работу с несоответствием в счете и соответствующей политикой перед глазами.
Важно помнить, что нам все равно следует ограничивать контекст, передаваемый модели. Отправка всей записи клиента увеличивает затраты на токены и может раскрыть поля, которые не нужны для текущей задачи. Бэкенд должен формировать наиболее компактный полезный контекст для запроса, точно так же, как он фильтрует данные для любой другой функции приложения.
Тот же принцип применим и к инструментам. Агенту по выставлению счетов могут понадобиться get_payment_history и get_refund_policy, но ему не нужен доступ ко всей системе поддержки. Контекст и возможности всегда должны соответствовать задаче.
Адаптация интерфейса без генерации всего UI целиком
При создании динамических приложений обычно хочется избегать динамической генерации всего пользовательского интерфейса, так как это делает поведение системы менее предсказуемым, а также более сложным для тестирования и поддержки. Вместо этого мы можем опираться на компоненты, которые мы уже контролируем, а затем использовать контекст для определения того, какой именно компонент должен появиться для текущей задачи и состояния рабочего процесса.
Предположим, что в приложении поддержки есть три контекстные панели:
Если агент обнаруживает дублирующийся платеж, бэкенд может вернуть панель invoice_comparison. Затем фронтенд сопоставляет этот тип панели с соответствующим компонентом. Если позже для рабочего процесса потребуется утверждение, бэкенд может вернуть refund_approval, и та же область обновится, отобразив интерфейс согласования. Фронтенд по-прежнему отвечает за макет, доступность, состояния загрузки и элементы управления для каждого компонента.
Этот паттерн также предоставляет нам полезную форму персонализации. Два человека могут открыть одну и ту же запись и нуждаться в разной информации, поскольку у них разные обязанности. Инженеру поддержки может потребоваться история переписки и элементы управления возвратом средств, в то время как специалисту по биллингу — история платежей и детали политики.
Когда агент изменяет рабочий процесс
До сих пор мы рассматривали, как интерфейс динамического приложения может адаптироваться на основе контекста. Та же идея применима и к рабочим процессам, в которых агент активно выполняет работу от имени пользователя. Агент может получить цель, выбрать инструменты и пройти несколько шагов, причем каждый шаг потенциально изменяет состояние приложения, пока пользователь остается на том же экране.
Представьте себе агента, помогающего в описанном выше примере с биллингом. Он читает историю платежей, извлекает политику возврата средств и подтверждает, что с клиента списали средства дважды.
Если сумма укладывается в его делегированный лимит, агент может подготовить возврат. Если сумма требует одобрения, рабочий процесс должен приостановиться и отобразить это решение в интерфейсе.
Стенограмма чата может описывать то, что делает агент, но у приложения уже есть более подходящее место для большей части этой информации. Представление счета может пометить дублирующиеся платежи, блок одобрения может появиться рядом с суммой возврата, а история активности может записать, что проверил агент и какое действие он запросил.
Это дает нам несколько состояний интерфейса, для которых необходимо проектировать дизайн:
- Выполнение (Working): Показать, какую запись или шаг обрабатывает агент.
- Ожидание одобрения (Awaiting approval): Показать предлагаемое действие и лежащие в его основе доказательства.
- Завершено (Completed): Обновить затронутую запись и сохранить сводку изменений.
- Эскалировано (Escalated): Четко показать, что агент остановился, и отобразить то, что требует внимания человека.
Эти состояния связывают агента с рабочим процессом, а не помещают его работу в отдельную панель ассистента.
Сохраняйте полномочия в приложении
Динамические рабочие процессы все равно нуждаются в фиксированных границах. Интерфейс может адаптироваться, и агент может выбирать свой путь, но код приложения должен обеспечивать соблюдение разрешений, политики и допустимых переходов состояний.
Давайте рассмотрим запрос на возврат средств. Модель может подготовить сумму и причину, но бэкенд может направить этот запрос в соответствии с бизнес-политикой:
С учетом вышесказанного интерфейс может отображать разное состояние для каждого результата. Небольшой возврат может быть выполнен сразу, более крупный — приостановлен для одобрения, а запрос, выходящий за рамки политики, может быть передан ответственному сотруднику-человеку.
Модель не решает, какими полномочиями она обладает, поскольку пределы выполнения должны быть предсказуемыми и принудительными. Права на инструменты, валидация схем и проверка политик обеспечивают соблюдение этой границы вне модели.
Единый динамический рабочий процесс от начала до конца
Мы можем объединить все элементы с помощью примера с возвратом средств, который мы обсуждали в этой статье. Для начала предположим, что инженер техподдержки открывает платежный тикет и задает вопрос:
Можем ли мы вернуть средства за эту транзакцию?
Можем ли мы вернуть средства за эту транзакцию?
Динамическое приложение может обработать этот запрос следующим образом:
- Бэкенд получает вопрос вместе с данными о текущем клиенте, платежном тикете и правах пользователя.
- Агент загружает соответствующий счет, историю платежей, детали разговора и существующие запросы на возврат средств.
- Он извлекает применимую политику возврата средств и проверяет такие условия, как дублирующие списания, предыдущие возвраты, статус платежа и лимиты на возврат.
- В окне тикета выделяется спорный платеж, отображаются подтверждающие материалы и применяемые условия политики.
- Рабочий процесс выводит сопутствующую информацию, такую как предыдущие возвраты, нерешенные споры или несоответствие между счетом и платежными записями.
- Инженер техподдержки задает уточняющий вопрос, корректирует предлагаемую сумму или выбирает запрос на возврат для получения более подробной информации.
- Бэкенд проверяет доступ к выбранным записям и получает последние данные о состоянии платежа и тикета перед подготовкой или выполнением запроса.
- Если требуется одобрение, интерфейс представляет на рассмотрение предлагаемый возврат, сумму, подтверждающие материалы и обоснование политики.
- Возврат по-прежнему подлежит проверке на авторизацию, валидацию и соответствие политике приложения, в то время как в журнале действий регистрируются заданные вопросы, просмотренные материалы и выполненные действия.
Интерфейс адаптировался во время беседы, но платежный тикет оставался тем же элементом интерфейса продукта. Агент собирал контекст с помощью структурированных инструментов и представлял пояснения вместе с записями, которые просматривал инженер техподдержки. Пользователь получил представление, адаптированное под конкретную задачу, без необходимости переключаться между несколькими экранами поддержки.
Это золотая середина для динамических приложений. Мы можем сделать рабочие процессы адаптивными к намерениям и контексту, не делая само приложение непредсказуемым.
Итоги
Динамические приложения могут адаптировать части рабочего процесса по мере изменения задачи. Приложение может использовать текущее состояние пользовательского интерфейса, данные учетной записи, извлеченные знания и активность агента, чтобы определить, какая информация и какие элементы управления должны отображаться пользователю.
Для пользователей это может сократить количество переходов и повторного ввода данных. Для агентов это создает структурированные пути к тем же возможностям, которые управляют интерфейсом. Обе категории пользователей работают в рамках одних и тех же правил бэкенда в отношении прав доступа, валидации и выполнения.
Поскольку приложения обслуживают как людей, так и агентов, этот баланс имеет важное значение. Рабочий процесс может адаптироваться в режиме реального времени, в то время как приложение продолжает нести ответственность за то, что каждый участник может видеть, изменять и одобрять.
Дополнительную информацию о создании приложений и агентов на базе ИИ с помощью Progress можно найти в следующих ресурсах:
- Progress Agent Engineering Solutions
- Progress Agentic RAG
