|
Цель |
Спросите себя "Какого результата я хочу добиться?, а не "Какие инструменты мне нужны?", "Какие соединители мне вызывать?" или "Какую тему мне стоит создать?"
Четко опишите, почему агент должен существовать, чего он должен достигать и кто является целевой аудиторией. Сосредоточьтесь на результатах. Проектирование агента должно исходить из проблемы.
Определите следующее:- Проблема или разрыв в ценности
- Целевые пользователи
- Ожидаемый эффект
- Как будет выглядеть успех
Используйте формат "что нужно":
-
Как< пользователю>
-
Мне нужно<что-то сделать>
-
Чтобы<результат>
|
-
Как новому сотруднику, мне нужно разобраться в HR-политиках, чтобы уверенно пройти процесса адаптации.
-
Как руководителю службы ИТ-поддержки, мне нужно автоматически обрабатывать письма в службу поддержки, чтобы уменьшить объем ручного триажа.
|
- Начинать с функций, а не с результатов.
- Проектировать с учетом крайних случаев.
- Пропускать измеримые критерии успеха.
|
|
Триггеры |
Триггер агента — это конкретное событие, условие или входные данные, которые запускают работу агента. Человеческое действие или автоматическое событие могут инициировать триггер.
Подробнее: Поиск триггера, который подходит для вашего события. |
- Сообщение пользователя в чате.
- Новое письмо в общем почтовом ящике.
- Новая запись в системе.
- Запланированная или регулярная задача.
|
- Автономные агенты требуют явных триггеров. Без них агент не запускается.
- Триггер зависит от непредсказуемого поведения пользователя, например, когда пользователь вводит конкретное ключевое слово или фразу.
- Триггеру не хватает необходимого контекста, например, агент запускается, но у него недостаточно метаданных (идентификатор записи, идентификатор пользователя) для эффективной работы.
- Триггеры активируются чаще, чем требует сценарий, что приводит к ненужным выполнениям и расходу ресурсов.
- Проектирование триггеров не учитывает квоты или лимиты платформы, из-за чего агенты превышают лимиты использования или не справляются с нагрузкой.
|
|
Инструменты и интеграции |
Определите, какие действия агент должен уметь выполнять, а не только то, что он знает.
Инструменты позволяют агенту получать или обновлять данные, вызывать API, запускать рабочие процессы, отправлять сообщения и выполнять транзакционные операции. Перечислите системы, от которых зависит агент, и их ограничения (API, модели аутентификации, лимиты скорости и границы владения/SLA).
Учитывайте ожидаемые результаты, критерии успеха и качества, а также поведение при ошибках и отказах. Зависимости часто влияют на осуществимость — прорабатывайте их на раннем этапе.
Подробнее: Механизмы добавления инструментов в агенты. |
- Соединитель ServiceNow → получить данные о заявках
- Соединитель Microsoft Entra ID → получить местоположение пользователя
- API JIRA → обновить рабочие элементы
- Соединитель Outlook → ответить на письмо
|
- Отказ от ведения журнала действий или хранения выходных данных для аудита.
- Предположение, что API стабильны и всегда доступны.
- Предоставление чрезмерных разрешений инструментам.
- Не определено поведение при отказе при вызове инструментов (не проводится проверка результата работы инструмента, нет резервного варианта при сбоях инструментов, нет пути эскалации).
- Игнорирование лимитов или регулирования запросов.
- Отсутствие сопоставления зависимостей (кто владеет каждым API, каково соглашение об уровне обслуживания).
- Отсутствие проверки предварительных условий перед выполнением действий.
|
|
Каналы |
Канал — это конкретная платформа или интерфейс, на котором ваш агент развернут и взаимодействует с пользователями.
Канал также влияет на ожидания пользователей относительно задержки, очередности реплик и пользовательского опыта. |
- Microsoft Teams
- SharePoint
- Microsoft 365 Copilot
- Веб-чат или голосовые интерфейсы
|
- Выбор каналов на основе удобства или легкости внедрения, вместо учета реальных условий и мест работы пользователей.
- Ожидание того, что пользователи адаптируются к каналу агента, вместо того чтобы встречать их там, где они уже находятся.
- Приоритет технической реализации над пользовательским опытом приводит к низкой степени использования, даже если агент работает корректно.
- Проектирование "chat-first", когда реальный канал — это электронная почта или рабочие процессы (создание разговорного UX, когда поддержка фактически осуществляется через Outlook; забывая, что email — это коммуникация по очереди, а не разговорная)
- Игнорирование специфических ограничений каналов (Outlook требует исчерпывающие ответы, а не уточняющие вопросы; Teams поддерживает адаптивные карточки, email — не поддерживает)
|
|
Знания и данные |
Задокументируйте сведения, необходимые агенту для принятия решений, и источники, где в настоящее время находятся соответствующие знания или данные. Учитывайте качество и свежесть данных, структурированный или неструктурированный контент, а также границы доступа и разрешений.
Недостаточная готовность данных — одна из самых распространенных причин возникновения задержек на поздних этапах проекта, если этот вопрос не решен заранее. |
- Документы
- Базы данных
- Веб-сайты
- База знаний
- Внутренние или внешние системы
|
- Плохое или непоследовательное управление данными. Когда владельцы данных, периодичность обновления и процессы обновления не определены, данные быстро устаревают или становятся противоречивыми.
- Путаница между "документами" и "знаниями". Указание на большие хранилища документов как на источник истины без учета того, актуальны ли эти документы, хорошо ли структурированы и последовательно ли маркированы.
- Источники знаний противоречат друг другу. Наличие нескольких версий политики, процедуры или набора данных приводит к тому, что агент получает противоречивые инструкции.
- Права и контроль доступа не спроектированы явно. Конфиденциальный контент непреднамеренно раскрывается, или агент ссылается на знания, к которым конечные пользователи не имеют доступа.
- Расширение источников знаний без проверки границ безопасности приводит к тому, что агенты либо раскрывают слишком много информации, либо выходят из строя при ограничении доступа.
|
|
Потоки и оркестрация |
Определите структуру и последовательность выполнения работы в рамках агента: когда использовать детерминированные потоки или темы, когда полагаться на оркестрацию и когда требуется участие человека. Цель — предсказуемое поведение, безопасная автоматизация и четкая эскалация.
Когда использовать потоки или темы:- Многошаговый сбор данных
- Интерактивное устранение неполадок или принятие решений с помощью деревьев решений
- Процессы, основанные на соответствии или политиках
- Действия с высоким воздействием или необратимые действия
Темы — это основной механизм детерминированной логики.
Определите:- Что агент может делать автономно
- Что требует утверждения, проверки или переопределения или отмены человеком
- Когда агент должен эскалировать или отложить выполнение
- Как обратная связь от человека интегрируется для совершенствования агента
|
- Агент "спроси меня о чем угодно": минимальные детерминированные потоки; в основном опирается на оркестрацию и генеративное рассуждение.
- Автономный агент: использует потоки или темы для обеспечения последовательности, валидации и ограничительных механизмов для критически важных шагов.
- Рабочие процессы утверждения: агент подготавливает контекст и рекомендации; люди утверждают или отклоняют значимые действия.
|
- Чрезмерная структурированность потоков, сниженная гибкость и ощущение, что агент становится негибким или хрупким.
- Слабое структурирование потоков, снижение надежности и непредсказуемые результаты:
- Отсутствие явного использования тем для детерминированной логики приводит к случайному или непоследовательному поведению.
- Нечеткое разграничение обязанностей между человеком и агентом, приводящее к непонятным механизмам эскалации.
- Перегрузка людей необходимостью утверждать действия с низким уровнем риска, что создает узкие места и снижает мотивацию использовать агентов.
- Агенты действуют без четких границ запрета на действия, особенно в пограничных или высокорисковых ситуациях.
|
|
Инструкции и поведение |
Инструкции определяют следующее:- Роль и обязанности агента
- Как он рассуждает и отвечает
- Когда и каким образом агент должен использовать знания, инструменты или других агентов
- Последовательность действий, которой должен придерживаться агент
- Тон, ограничения и правила безопасности
Четкие инструкции объединяют знания, инструменты и потоки в целостную, предсказуемую систему.
Подробнее: Настройка высококачественных инструкций для генеративной оркестрации, и Написание эффективных инструкций для декларативных агентов. |
- Роль и область деятельности: "Ты агент поддержки по электронной почте в ИТ-отделе, отвечающий за чтение входящих сообщений в почтовом ящике, извлечение номеров заявок и ответ с подтвержденной информацией из ServiceNow."
- Последовательные действия: "Шаг 1. Проверь базу знаний на наличие существующей политики или известной проблемы. Шаг 2. Если информация не найдена или неполная, вызови инструмент ServiceNow, чтобы получить подробности заявки. Шаг 3. Если необходимые данные все равно отсутствуют, ответь по шаблону "я не знаю" и эскалируй".
- Правила использования инструмента: "Всегда проверяй извлеченные идентификаторы с помощью вызова инструмента перед тем, как использовать их в ответах."
- Обработка ошибок: "Если знания отсутствуют или вызвать инструмент не удалось, не пытайся угадывать". Дай ответ, четко указав ограничение и следующий шаг".
|
- Слишком размытые инструкции. Например, инструкция "Помогай пользователям с вопросами поддержки" не уточняет предметную область, границы или разрешенные действия.
- Отсутствие ясности в том, когда использовать знания, когда инструменты, а когда других агентов, что приводит к непоследовательному или неэффективному поведению.
- Инструкции не определяют последовательность действий, из-за чего агент непредсказуемо смешивает знания и выходные данные инструмента.
- Правила использования инструментов не определены явно, что может привести к их избыточному или недостаточному применению, а также к непредсказуемому смешиванию знаний и результатов инструментов.
- Противоречивые инструкции, такие как "всегда задавать уточняющие вопросы" и "отвечать только окончательными ответами".
- Отсутствие инструкций о том, какие действия запрещены, например изменение конфиденциальных данных, разглашение внутренних идентификаторов, предоставление юридических или кадровых консультаций без проверенных источников.
|
|
Архитектура и композиция агента |
Используйте нескольких агентов, когда:
- Предметные области объемные или их несколько
- В разных командах за агентов отвечают разные люди
- Доступ или разрешения различаются
- Требуется специализированное рассуждение
Делегирование повышает модульность, понятность и удобство долгосрочной поддержки.
Ознакомьтесь: Знакомство с шаблонами многоагентной оркестрации. |
- Главный агент делегирует поиск заявок ИТ-агенту.
- Агент по знаниям осуществляет контроль качества документов.
- Агент по маршрутизации решает, к какому экспертному агенту обратиться.
|
- Чрезмерное делегирование (слишком много агентов) — например, создание отдельного агента для каждой небольшой задачи — может привести к разрастанию архитектуры и усложнить поддержку, отладку, обеспечение безопасности или обновление агентов.
- Недостаток делегирования (один гигантский агент) — например, когда от одного агента ожидают ответы на вопросы по HR, поиск ИТ-заявок, решение проблем и создание заказов на покупку и инцидентов — может привести к монолитному, хрупкому агенту, которого невозможно поддерживать.
- Неопределенные границы делегирования. Например, главный агент не знает, когда передавать управление, дочерние агенты не знают, какие входные данные им ожидать, или обязанности пересекаются (два агента оба ищут ИТ-запросы).
|
|
Управление и риски |
Определите, как агент управляется, защищается и контролируется, чтобы он вел себя ответственно, безопасно и предсказуемо на протяжении всего жизненного цикла.
Это определение включает контроль доступа, разрешения на действия, ограничители безопасности, подотчетность и постоянный надзор для управления как операционными, так и связанными с ИИ рисками с первого дня.
Подробнее: Сбор требований управления и Применение принципов ответственного применения ИИ. |
- Модель аутентификации и доступа: агент использует учетную запись пользователя для получения только тех данных, которые разрешено просматривать этому пользователю, в то время как системные учетные записи ограничены четко определенными сервисными операциями.
- Права действий и ограничители: агент может обновлять рабочие заметки или составлять ответы, но не может выполнять необратимые действия (например, закрывать заявки или отправлять внешние сообщения) без одобрения.
- Защита данных и контента: конфиденциальная или регулируемая информация обнаруживается и блокируется от передачи или обработки с помощью платформенных средств защиты (например, предотвращение потери данных (DLP) или фильтры безопасности):
- Логирование, аудит и прослеживаемость: все действия агента, вызовы инструментов, отказы и эскалации фиксируются и доступны для аудита для соответствия требованиям и контроля.
- Операционная ответственность: у агента определены владелец, спонсор и операционный куратор, а разрешения и поведение пересматриваются на регулярной основе.
|
- Позднее внедрение механизмов управления и контроля рисков, приводящее к невозможности развертывания или задержкам ввода в эксплуатацию.
- Чрезмерные права доступа агентам "для удобства", увеличивая риск утечки данных или непреднамеренных действий.
- Недостаточные права доступа у агентов приводят к сбоям в процессе выполнения, когда необходимые системы или данные недоступны.
- Отсутствие интеграции вопросов ответственного ИИ в основные управленческие решения.
- Слабое операционное управление: отсутствие четкого владельца, плана мониторинга или определенного процесса реагирования на инциденты.
- Не осуществляется мониторинг поведения агента после развертывания, предполагая, что одних защитных механизмов достаточно.
|
|
Оценка и оптимизация |
Определите тесты, моделирующие реальные сценарии для измерения точности, релевантности и качества ответов ваших агентов. Укажите ожидаемый ответ и покажите, как ответ агента соотносится с вашим или эталонным ответом.
Планируйте, как измерять и улучшать производительность:
- Точность и актуальность
- Экономия времени или эффективность
- Внедрение и использование
- Сигналы удовлетворения и доверия
- Качество цитирования
- Соблюдение разрешений
- Обнаружение неверной информации
- Поведение при уточняющих вопросах
Определите, какую телеметрию собирать:
- Вызовы инструментов
- Действия агента
- Сбои и повторные попытки
- Отзыв пользователя
Рассматривайте оценку как часть проектирования, а не как нечто второстепенное. Подробнее: Проектирование и внедрение оценки агентов. |
- Проверьте, что поиск заявок возвращает актуальный статус, а не устаревший.
- Проверьте, что ссылки на источники указывают на текущий одобренный контент.
- Проверьте, что агент отказывается предоставлять детали по заявке другого пользователя.
- Проверьте, не выдумывает ли агент номер заявки или статью базы знаний.
- Измеряйте количество писем, обрабатываемых автономным агентом в день, и процент пользователей, выбирающих агента вместо ручных каналов.
|
- Слишком позднее проведение оценок (после развертывания).
- Отсутствие базового уровня или эталонного показателя.
- Оценки не связаны с реальными ситуациями.
- Отсутствие обнаружения регрессии.
- Отсутствие многоходовых взаимодействий.
- Отсутствие оценки качества использования инструментов.
- Проверяются только "счастливые пути".
- Пробелы в телеметрии.
|
