Вопросы на собеседовании: Agentic AI Engineer

Чат-бот в основном отвечает в диалоге, а агент может выбирать действия и применять инструменты для выполнения задачи.

• Чат-бот поддержки может объяснить правила возврата, а агент еще и найти заказ и оформить разрешенный возврат.
• Агент хранит состояние задачи между несколькими шагами и выбирает следующий шаг по результатам инструментов.
• Доступ к инструментам создает реальные риски ошибок и безопасности, поэтому агенту нужны права, лимиты и условия остановки.

Для запуска нужны явные статусы, например queued, running, waiting, succeeded, failed и canceled, с одним определенным смыслом для каждого.

• Queued означает, что запуск принят, но не начат, а running означает, что работа еще может создавать действия и события.
• Waiting является нетерминальным статусом и должен указывать, что возобновит запуск: ответ пользователя, подтверждение или запланированный повтор.
• Только среда выполнения должна применять проверенные переходы статусов, а терминальный статус должен хранить причину и время завершения.

Граница автономности определяет, какие решения и действия агент может выполнять без подтверждения человека.

• Агент для путешествий может искать варианты и составлять маршрут, но запрашивать подтверждение перед оплатой или покупкой невозвратного билета.
• Граница должна задавать разрешенные инструменты, области данных, денежные лимиты и действия, которые всегда передаются человеку.
• Ограничения нужно обеспечивать кодом приложения и правами доступа, а не только промптом, который модель может проигнорировать.

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

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

ReAct чередует обдумывание следующего шага, действие и полученное наблюдение, чтобы агент корректировал работу по фактам.

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

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

• Паузы, возобновления и повторы шагов сохраняют тот же ID запуска, а новая независимая задача получает новый ID.
• Каждый дочерний шаг или делегированная задача получает собственный ID со ссылкой на родительский запуск, чтобы их состояние и результаты не попали в другой запуск.
• Эти ID задают принадлежность и происхождение, но не полномочия, поэтому каждое действие все равно требует отдельной проверки прав действующего субъекта и области доступа.

Конечный автомат явно задает допустимые этапы и переходы агента вместо передачи всего процесса свободной генерации.

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

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

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

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

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

Pydantic преобразует недоверенный вывод модели в типизированные данные Python или отклоняет его со структурированными ошибками валидации.

• Модель Pydantic может требовать customer_id в формате UUID и quantity как целое число больше нуля.
• Валидаторы полей могут нормализовать допустимый ввод, а запрет лишних полей ловит выдуманные аргументы.
• ValidationError нужно превратить в краткий сигнал для исправления либо завершить вызов с ошибкой; нельзя обходить валидацию и передавать сырые данные.

Предусловия являются фактами, которые должны выполняться непосредственно перед отправкой действия, а постусловия являются фактами или подтверждениями ожидаемого эффекта после него.

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

До запуска среда должна проверить зависимости и побочные эффекты, чтобы решить, можно ли выполнять вызовы параллельно или их нужно упорядочить.

• Независимые вызовы только для чтения можно выполнять параллельно, если у каждого есть собственные ID вызова, тайм-аут и место для результата.
• Вызовы, которые изменяют общее состояние или зависят от другого результата, нужно выполнять последовательно в явно заданном порядке.
• Каждый результат или ошибка должен возвращаться с соответствующим ID вызова, а сбой одного вызова не означает, что остальные завершились с ошибкой или успехом.

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

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

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

• Ошибка валидации может привести к одному исправленному вызову по полученным данным о полях.
• Ошибка прав должна остановить процесс или передать его человеку, потому что смена аргументов не должна обходить авторизацию.
• Временный тайм-аут можно повторить по правилам, а неизвестную серверную ошибку нужно записать с trace ID и безопасно показать пользователю.

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

• Повторять нужно только временные ошибки, например 503 или тайм-аут, но не неверные учетные данные или отклоненный платеж.
• Подойдет небольшой лимит, например три попытки, с экспоненциальной задержкой и случайным разбросом.
• Число попыток нужно хранить в состоянии задачи, а после достижения лимита остановиться или передать задачу человеку.

Ключ идемпотентности связывает повторные запросы с одной логической операцией и предотвращает дублирование побочных эффектов после повторов.

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

Инструменты только для чтения наблюдают данные, а инструменты с побочными эффектами меняют внешнее состояние и требуют более строгого контроля.

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

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

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

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

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

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

• Нужно записать действия, которые не отправлялись, получили надежное подтверждение успеха или ошибки либо остаются в статусе pending или unknown.
• Запуск можно пометить succeeded, только когда все обязательные эффекты подтверждены; failed или canceled все еще могут требовать сверки неопределенных эффектов.
• Финальный отчет должен разделять подтвержденные результаты, пропущенную работу и нерешенные эффекты с ID операций и ответственными.