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

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

• 10 миллионов задач в месяц дают в среднем 3,9 задачи в секунду, поэтому мощность я проверял бы на измеренном часовом пике с двукратным запасом, а не по среднему.
• Workflow engine хранит попытки, дедлайны, бюджеты, аренды и типизированные события; чтения можно повторять, а побочные эффекты требуют ключей идемпотентности.
• Задача считается принятой только после проверки identity и начальной политики, резервирования квоты и дедлайна и кворумного подтверждения долговечного события; предложенная, отклоненная и принятая нагрузка показываются отдельно.
• Каждая долговечно принятая задача остается в знаменателе завершения, поэтому последующий отказ политики, деградация или исчерпание ресурсов считаются незавершением; отмены пользователя следуют одному заранее объявленному и отдельно показываемому правилу.

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

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

Я бы предоставил агенту целевые бизнес-возможности вместо разрешения компоновать сырые API всех 20 систем.

• Tool gateway унифицирует identity, схемы, таймауты, идемпотентность и квитанции, сохраняя раздельными поиск и изменяющие операции.
• Агент автоматически выполняет обратимые чтения и черновики; возвраты, отмены и изменения прав проходят детерминированные предусловия и одобрение по риску.
• Знаменатель возможностей изменения включает каждое намерение изменить аккаунт, дошедшее до детерминированной границы решения, включая воздержания и отказы; онлайн-квитанции дают предварительные метки, а отложенная проверка провайдером или человеком делает их окончательными.
• Продвижение требует, чтобы односторонняя верхняя 95% доверительная граница ошибочных изменений была ниже 0,1% в целом и по существенным срезам риска после созревания меток; ожидающие и пересмотренные production-метки явно показываются рядом с SLO 10 минут.

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

• Manifest фиксирует commit SHA, build image, кеши зависимостей, сетевую политику, учетные данные и разрешенные пути; ключи кеша включают tenant и репозиторий.
• Индекс обновляется по коммитам, но код и символы фильтруются до сборки контекста модели по разрешенному набору репозиториев.
• Агент выполняет ограниченные циклы правки и теста, публикует патч и квитанции команд, но не может merge или push без отдельного права репозитория.
• Тест мощности на 650 разноязычных задачах измеряет очередь, запуск sandbox, тесты, приемку патча и утечки относительно SLO 20 минут.

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

• На первой неделе сотрудники выполняют read-only задачи в браузере; затем когорты получают формы и обратимые записи, а платежи и настройки безопасности остаются закрытыми.
• Удаленный policy service ограничивает домены, UI-действия, загрузки, буфер обмена и credentials, а запись сессии хранит скриншоты и квитанции действий.
• При нуле тяжелых событий для односторонней верхней 95% границы ниже 1 на 100 000 нужно примерно 300 000 репрезентативных независимых сессий; срезы и зависимость увеличивают требуемую эффективную выборку, поэтому детерминированные тесты запрещенных действий остаются отдельными гейтами.
• Серверный kill switch отзывает manifest возможностей и останавливает активные сессии за 15 минут, что проверяется на каждом этапе rollout.

Я бы отделил discovery и governance MCP от data plane, который вызывает каждый tool server.

• Подписанный каталог хранит identity сервера, схемы, владельца, scopes, классы данных, уровень риска и версии совместимости; агент видит только разрешенный набор.
• Gateway применяет аутентификацию, политику, квоты, дедлайны и trace propagation, не скрывая семантику ошибок MCP.
• Собственный подписанный каталог использует кешированные снимки и отдельный канал срочных запретов; привилегированная маршрутизация запрещается, если нельзя подтвердить подпись, корректность часов, работоспособность канала запретов или допустимый максимальный возраст пакета.
• 650 tools дают 30% сверх текущих 500 для прогнозного роста и перекрытия версий; бюджет 40 мс оставляет измеренный сетевой запас.

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

• Registry хранит JSON Schema входа и выхода, класс побочного эффекта, auth scopes, таймаут, владельца, дату deprecation и digest реализации.
• Contract-тесты повторяют характерные вызовы на старой и новой версиях; удаление поля или смена семантики требует major-версии и миграции потребителей.
• Агент закрепляет snapshot registry на задачу, чтобы 24-часовой workflow не получил другую схему посередине выполнения.
• Откат переводит подписанный alias на прошлую проверенную версию, а ежедневный деплой разрешается только после drill восстановления за 10 минут.

Runtime получает внутренний capability handle на один вызов; provider OAuth tokens остаются на сервере с TTL и audience провайдера.

• Runtime агента получает непрозрачный grant handle, но не refresh token; broker проверяет пользователя, tenant, consent, scopes, audience и намерение вызова.
• Incremental consent запрашивает узкий scope по необходимости, а рискованное действие привязывает свежее подтверждение к хешу нормализованного вызова.
• Gateway проверяет resource, tenant, audience и replay; провайдер обязан поддерживать exchange или revocation за пять минут, иначе delegated actions закрываются.
• Тесты cross-audience, replay, просроченного consent и confused deputy служат релизными гейтами для всех 12 интеграций.

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

• Входы включают principal, tenant, версию агента, инструмент, нормализованные аргументы, класс данных, уровень риска и прошлые одобрения.
• Критические пакеты политик имеют TTL 60 секунд и отдельный канал срочных запретов; только низкорисковые чтения могут использовать заранее объявленный более долгий TTL последней заведомо исправной версии.
• При отсутствии identity, устаревшей критической политике или неизвестном действии система запрещает вызов; низкорисковые чтения могут ограниченно использовать последнюю заведомо исправную версию.
• После истечения срока актуальности критические решения считаются недоступными; доступность нужно отдельно считать для свежих критических политик и классов, которым разрешена последняя исправная версия.

Я бы обменивал подтвержденную workload identity и одобренное намерение на короткоживущие credentials на границе инструмента.

• Строгие разрешительные схемы отклоняют значения с секретами до сериализации промпта, события или trace; модель и телеметрия получают только непрозрачные grant handles, ID и reason codes.
• Региональные stateless brokers проверяют tenant, инструмент, scope, политику, аренду задачи и состояние отзыва, затем вводят ограниченные аудиторией и одной задачей credentials прямо в защищенный канал адаптера.
• Размещённые рядом снимки политик и региональные подписывающие сервисы на базе HSM обеспечивают p95 ниже 100 мс в указанных исправных регионах от аутентифицированного запроса до получения адаптером.
• Если broker, подписывающий сервис, свежесть политики или проверка отзыва недоступны, выдача и погашение запрещаются; canary scanners остаются дополнительной защитой, а не гарантией отсутствия открытых секретов.

Я бы использовал одноразовые microVM с отдельными профилями для исполнения кода и работы браузера.

• Каждый запуск получает свежую границу ядра, read-only base image, лимиты CPU и памяти, временный диск, отсутствие host sockets и default-deny egress proxy.
• Browser-сессии изолируют профиль, downloads, clipboard, extensions и доступ к локальной сети; code-сессии монтируют только объявленные входы и каталог результата.
• Images и browser builds закреплены по digest, сканируются и меняются, а события syscall, DNS, файлов и процессов поступают в containment alerts.
• Запуск быстрее двух секунд проверяется на warm pools, но escape-тесты и tenant-crossing probes важнее цели latency.

Сохраняйте недетерминированные результаты как workflow events.

• Completed node хранит normalized input, manifest, model output, provider metadata и validation; replay потребляет его без нового вызова модели.
• Только отсутствие terminal event создает новую attempt, а неоднозначные effects сначала требуют provider idempotency или reconciliation.
• Детерминированные migrators могут менять форму старого state, но не записанное решение.

Я бы использовал append-only event log как источник истины, а периодические типизированные snapshots только для ускорения replay.

• События содержат task, sequence, версию схемы, command ID, actor, timestamps и hashes; optimistic sequence checks предотвращают split-brain writers.
• Событие считается принятым после локальной кворумной записи, а задержка межрегиональной репликации жестко ограничена 30 секундами; прием останавливается, если границу нельзя удержать, что задает RPO не более 30 секунд.
• Snapshots создаются по измеренному порогу стоимости replay, сначала каждые 200 событий, а крупные artifacts используют content-addressed ссылки; ни частота snapshots, ни копирование artifacts не задают RPO.
• Recovery drills восстанавливают выборку длинных задач на свежей инфраструктуре и отдельно измеряют потерю подтвержденных событий и время replay, которое должно оставаться ниже пяти минут.

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

• Ledger хранит хеш нормализованного намерения, tenant, principal, версию tool, approval, ключ идемпотентности, попытку, статус и receipt провайдера.
• Состояния различают prepared, dispatched, confirmed, rejected и unknown; неизвестный исход блокирует повтор, пока точная сверка с провайдером не разрешит его.
• Outbox закрывает атомарность между базой данных и очередью, но не между базой и сторонней системой; денежное, коммуникационное или data-изменение допустимо только при нативной идемпотентности провайдера или точной сверке чтением после записи по стабильному бизнес-ключу.
• Частота дублей измеряется по семантическому эффекту среди всех покрытых изменений, а не по HTTP-попыткам; провайдеры без обоих механизмов не могут выполнять ни один покрытый эффект.

Считайте override ограниченным и истекающим policy artifact.

• Свяжите reviewer, case, intent hash, отклоненное правило, rationale, лимит effect, expiry и второе approval; dispatch заново проверяет state.
• Аудируйте исходное решение и outcome; новые arguments требуют reapproval.
• Training хранит его как исключение до независимого adjudication изменения правила владельцами policy.

Я бы потребовал от каждого изменяющего tool объявить прямой эффект, поведение идемпотентности, класс обратимости и проверенную компенсацию.

• Полностью обратимые вызовы дают версионируемую undo-команду; условно обратимые указывают срок и предусловия; необратимые требуют approval до отправки.
• Saga записывает завершенные эффекты и выполняет компенсации в обратном порядке зависимостей, каждая со своим idempotency key и receipt.
• Сбой компенсации ставит workflow на паузу и вызывает owning team, а не просит модель импровизировать новое изменение.
• Гейт восстановления 30 минут применяется только к цепочкам tools, чье худшее время компенсации прошло fault-injection tests.

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

• Для каждого предложения записываются исходный код, создавшие его агент и задача, происхождение входных данных, воспроизводимая сборка, схемы, запрошенные права, классы данных, сетевые назначения, класс побочных эффектов, владелец и срок действия; изолированная сборка создает digest артефакта.
• Автоматические тесты и независимый reviewer одобряют точный digest и manifest возможностей; registry и broker учетных данных принимают подписи только от субъектов, недоступных предложившему инструмент агенту.
• Подписанный артефакт работает в sandbox с запретом по умолчанию, а каждый вызов проходит через policy gateway с учетными данными в границах задачи; по истечении срока временный alias удаляется, а активные задачи остаются привязаны к проверяемой версии.
• p95 активации измеряется от окончательного одобрения до появления в каталоге, без времени review; срочный запрет отзывает маршрутизацию и новые учетные данные за пять минут, а откат возвращает предыдущий подписанный артефакт, сохраняя квитанции предложения, проверки и исполнения.

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

• Верхний уровень хранит цели, acceptance tests, бюджеты и зависимости; leaf plans содержат примерно 5-10 шагов, чтобы сбой не обесценивал 100 решений.
• Каждый завершенный leaf записывает structured findings, provenance и открытые вопросы в durable state вместо добавления сырой истории.
• Детерминированный packer упорядочивает доказательства по объявленному приоритету, удаляет дубли и считает system text, user input, summaries, найденные доказательства, выбранные tool schemas и резерв output tokens в жестком лимите 32 000 токенов для каждого вызова.
• Ветви critical path работают параллельно только в общих лимитах tools, tokens и двух часов; если вызов нельзя упаковать без удаления обязательных доказательств или резерва ответа, validation завершается ошибкой вместо неявного обрезания.

Я бы использовал supervisor над ограниченными capability специалистами, а не полностью связанную беседу 30 агентов.

• Router выбирает лишь несколько ролей, обоснованных типом кейса; у каждой свои tools, data scope, output schema и budget.
• Специалисты обмениваются подписанными artifacts через workflow state, не свободными peer messages, что ограничивает рост промпта и подделку полномочий.
• Action service выводит approver и executor из разных principals с непересекающимися grants, отклоняет одного principal или владельца credentials в обеих позициях и не позволяет supervisor переназначать credentials или создавать право approval.
• Replay tests измеряют точность routing, число handoffs, latency, conflicts и попытки обойти разделение обязанностей до добавления роли.

Я бы сделал blackboard типизированным tenant-partitioned состоянием workflow, а не общим документом на естественном языке.

• Записи объявляют owner, schema, task scope, provenance, version, expiry и read-write capability; авторизация идет до query или subscription.
• Compare-and-swap версии не дают агентам тихо перезаписывать друг друга, а append-only findings сохраняют конкурирующие гипотезы.
• Порядок гарантируется внутри раздела tenant-task; SLO в одну секунду действует для исправных указанных регионов, а при разделении сети записи завершаются ошибкой или ставятся в очередь, и чтения явно показывают устаревание.
• Tenant-isolation tests, stale-write conflicts и poisoning fixtures служат гейтами каждой схемы до автоматического потребления агентами.