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

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

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

Я буду считать план недоверенным запросом полномочий, а не носителем credentials.

• Планировщик получает read-only метаданные возможностей и маскированные описания ресурсов, затем выдаёт типизированный DAG, где узлы запрашивают конкретные операции и границы аргументов.
• Доверенный compiler пересекает каждый запрос с правами аутентифицированного пользователя, policy задачи и результатами зависимостей, создавая manifest полномочий для каждого узла.
• Scheduler привязывает manifest к выданному непосредственно перед запуском credential исполнителя; исполнитель не может читать credentials соседних узлов, расширять права или менять manifest.
• Инструменты проверяют manifest, а перепланирование с изменением ресурсов или операций требует повторной компиляции; отсутствие полномочий блокирует узел или требует явного согласования.

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

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

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

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

Я выберу ReAct для коротких исследовательских задач, а plan-execute для долгой работы с зависимостями, бюджетами или точками согласования.

• ReAct адаптируется после каждого наблюдения и подходит для двух или трёх неопределённых поисков, но его неявный план трудно проверить и возобновить.
• Plan-execute показывает зависимости и прогресс, упрощая параллельность, согласования и восстановление ценой дополнительного вызова планировщика.
• Я сравню варианты по успеху одного запуска, повторным вызовам инструментов, p95 задержки и стоимости, а не только по качеству промпта.

Валидация, авторизация, переходы состояния и выполнение побочных эффектов должны быть детерминированными, даже если действие предложила LLM.

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

Я буду хранить один канонический append-only log и строить типизированные checkpoints workflow из зафиксированных событий.

• Commit узла атомарно записывает версию входа, результат, переход и outbox intent либо checkpoint, event и outbox попадают в одну транзакцию базы.
• Новый worker продолжает с последней зафиксированной последовательности и детерминированно восстанавливает проекции, а не доверяет двум независимо записанным хранилищам.
• Внешние эффекты остаются at-least-once: им нужны стабильные idempotency keys, ledger эффектов и reconciliation неоднозначных исходов, а не обещание exactly-once.
• Промпты модели, схемы инструментов и определения workflow получают ID версий, чтобы старые запуски продолжались или мигрировали по явным контрактам.

Я назначу каждому бизнес-эффекту стабильный idempotency key в его области авторизации и запишу статус до повторов.

• Ключ выводится из tenant, типа операции и видимого вызывающей стороне ID бизнес-операции, поэтому заново созданный run не заведёт тот же задуманный тикет повторно.
• Hash канонических аргументов хранится отдельно, а повторное использование ключа с другим payload отклоняется и не становится новой операцией.
• Ledger хранит состояния proposed, authorized, started, succeeded и uncertain вместе с ID внешнего ресурса.
• После timeout с неизвестным исходом агент ищет результат у провайдера по ключу или выполняет reconciliation вместо слепого повторного вызова.

Я представлю каждое бронирование как подтверждённый шаг с именованным компенсирующим действием и выполню компенсации в обратном порядке зависимостей.

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

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

• Для каждой возможности нужны схема входа и выхода, версия, класс побочного эффекта, обязательные scopes, владелец, таймаут и поведение идемпотентности.
• Состояние endpoint, регион, rate limit, класс данных и статус устаревания позволяют оркестратору выбрать рабочий маршрут.
• Агент получает отфильтрованное под задачу представление реестра, а не полный каталог инструментов организации.

Я оформлю initialization, проверку транспорта, reconnect policy и shutdown как явные состояния runtime.

• Клиент завершает MCP initialization, записывает выбранную версию протокола и identity сервера и строит registry только из объявленных сервером capabilities.
• MCP ping requests, transport deadlines и ограниченный reconnect backoff отличают разрыв соединения от медленного инструмента и не создают шторм переподключений.
• Переподключение не доказывает, что незавершённый вызов остановился или упал, поэтому workflow ждёт, проверяет состояние приложения или повторяет вызов только по idempotency contract инструмента.
• После потери сессии клиент снова выполняет initialization и обновляет списки capabilities до запуска новых вызовов.

Initialization выбирает версию протокола и обменивает разные объявления клиента и сервера, а не пересекает единый список функций.

• Клиент отправляет protocolVersion, clientInfo и client capabilities; сервер возвращает выбранный protocolVersion, serverInfo и server capabilities, после чего клиент отправляет initialized notification.
• Runtime показывает только объявленные сервером поверхности, например tools, resources или prompts, и включает поведение клиента лишь при наличии соответствующего объявления.
• Изменение списка tools требует server capability tools.listChanged, а подписки и изменения списка resources требуют соответственно resources.subscribe и resources.listChanged. Cancellation не является capability этапа initialization.
• Неизвестные необязательные поля сохраняют forward compatibility, а неподдерживаемая версия протокола явно прерывает initialization.

Я буду считать MCP-сервер OAuth protected resource и выполню discovery вместо передачи уже имеющегося bearer token.

• Клиент находит Protected Resource Metadata и указанные там authorization servers, затем через Authorization Server Metadata получает поддерживаемые authorization endpoints.
• Для authorization-code flow клиент использует PKCE и запрашивает token, привязанный к MCP resource через resource indicator и нужные scopes.
• Challenge с insufficient scope может запустить явный step-up consent, а refresh tokens остаются в хранилище клиента и не попадают модели или в аргументы инструментов.
• Token passthrough к другому MCP-серверу запрещён; внутренний token exchange является отдельным delegation design и должен выпускать новый audience-bound token.

Я свяжу долгий MCP request с одной долговечной операцией workflow и разделю состояния протокола и внешнего эффекта.

• Если caller передал progress token, MCP progress notifications обновляют монотонно выполненный объём и необязательный total, но не фиксируют результат инструмента.
• Отмена пользователем отправляет MCP cancelled notification для request и помечает cancellation requested; получатель уже мог выполнить часть работы, поэтому runtime не сообщает stopped без доказательства.
• Timeout workflow завершает локальное ожидание и запускает ограниченную очистку транспорта, но disconnect клиента не доказывает остановку обработки на сервере или внешнего эффекта.
• Без cancellation protocol request завершает финальный result или error; после cancellation workflow не ожидает result и сверяет неизвестные эффекты через прикладной status или idempotency interface.

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

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

Policy engine должен оценить аутентифицированного субъекта, намерение задачи, выбранную возможность, аргументы, текущее состояние и чувствительность данных.

• Детерминированное правило может разрешить чтение CRM, но потребовать согласование для экспорта более 100 записей или любого удаления аккаунта.
• Политика использует tenant и владельца из серверных источников, потому что поля от модели являются недоверенным вводом.
• Результат allow, deny или require approval с кодом причины записывается до продвижения ledger побочного эффекта.

Я предпочту DOM или accessibility tree для структурированных веб-интерфейсов, а зрение использую там, где нет семантических элементов или цель графическая.

• DOM API предоставляет элементы, атрибуты, текст и значения полей, а локаторы дерева доступности дают вычисленные роли и accessible names; оба подхода проще проверять, чем координаты пикселей.
• Зрение необходимо для canvas, удалённых рабочих столов и визуальных признаков layout, но требует проверки свежести скриншота и нормализации координат.
• Гибридный контроллер может найти цель визуально, сопоставить её DOM-элементу и проверить результат по обоим каналам.

Я представлю состояние браузера как версионированный snapshot, привязанный к текущей вкладке, документу и эпохе взаимодействия.

• Snapshot включает URL, ID вкладки и frame, ID навигации, digest DOM или accessibility tree, видимые диалоги и ссылки на нужные cookies или storage.
• Каждое предложенное действие ссылается на версию snapshot, по которой оно выбрано, а контроллер отклоняет его после навигации или существенного изменения DOM.
• Постусловия, например новый URL, текст подтверждения или выключенная кнопка отправки, наблюдаются до отметки действия успешным.

Я запущу каждую задачу в эфемерной песочнице без фоновых credentials хоста и по умолчанию запрещу сеть.

• Контейнер или microVM получает read-only mount исходников, записываемую временную область, непривилегированного пользователя, ограничения syscall, CPU, памяти, процессов и времени.
• Исходящий трафик разрешается только через аудируемый proxy к названным адресам, а секреты выдаются на одну команду и не пишутся в workspace.
• Выходящие артефакты ограничиваются по размеру и сканируются, а песочница уничтожается после задачи и не переиспользуется между tenant.

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

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