Наблюдаемость агента AI при неисправности инструмента: Пятислойный тест

Агент AI может не использовать инструмент даже тогда, когда его модель реагирует, его процесс живой, и призыв инструмента появляется в следе. Таким образом, практическим дефолтом для наблюдаемости агента AIZ является тестирование инструментального вызова в пяти упорядоченных слоях: транспорт, протокол, авторизация, исполнение и результат. Остановитесь на первом неудачном слое. Это правило превращает неоднозначное предупреждение о недоступности инструмента в ограниченный ремонт, и это предотвращает то, что зеленый ответный конверт может быть ошибочно принят за выполненную работу. Данное руководство применяет правило к инструментам типа MCP по HTTP и JSON RPC, но диагностическая форма также работает для пользовательских инструментов REST и локальных адаптеров команд. Цель состоит не в том, чтобы собрать каждый запрос или полезную нагрузку. Он должен сохранить самые маленькие доказательства, необходимые для ответа: где остановился звонок, какой авторитет требуется и достиг ли обещанный результат его назначения? Начните с первого неудачного слоя Один счетчик tool call failed разрушает неисправности, требующие несовместимых ответов. Ошибка DNS может оправдать повторную попытку ограничения подключения. Вычеркнутый срок может оправдать одно обновление. Отсутствие возможностей требует человека или администратора; повторное использование того же же знака это трата. Действительный инструмент без изменения файла, билета, сообщения или базы данных требует исследования результатов, а не ремонта транспорта. Используйте следующее преимущество: Складка Минимальные доказательства Примеры неудач Разумный следующий шаг Транспорт результат соединения, статус HTTP, истекшее время Неудача DNS, отказ в подключении, HTTP 503 проверка доступности; повторная проверка только в рамках фиксированного бюджета Протокол идентификатор запроса, метод, код ошибки JSON RPC отсутствует метод 32601 , недействительные параметры 32602 обновить открытие или исправить договор о запросе Разрешение Статус HTTP, дезинфицированная ошибка автора, требуемый объем 401 invalid token , 403 insufficient scope один раз обновлять или обращаться к отсутствующему органу Исполнение Статус результатов инструмента, отсрочка, вердикт схемы выхода MCP isError: true , отсрочка, неправильный структурированный выход проверять реализацию или ввод инструмента Результат проверяющий пункт назначения и свежесть Ответ говорит "создано", но артефакт отсутствует. проверять место назначения; не объявлять завершенное Порядок имеет значение. Если разрешение DNS не удалось, авторизация и результат unobserved , не удалось. Выпуск пяти неудач за один ранний перерыв увеличивает количество инцидентов и направляет респондентов к доказательствам, которые никогда не существовали. Сохраняйте провал протокола отдельно от провала инструмента При обращении к инструменту MCP используется tools/call , в то время как определение инструмента имеет inputSchema и может иметь outputSchema . Нынешний Спецификация MCP Tools также показывает результат инструмента с isError: false . Это отдельные контрольные пункты: клиент может добраться до сервера, обмениваться действительным ответом JSON RPC и все же получать отказ на уровне инструмента. JSON RPC делает внешнее различение ясным. Его Спецификация 2.0 резервирует 32601 для Метод не найден и 32602 для Недействительные параметры; ответ на ошибку содержит error , в то время как успешный ответ содержит result . JSON RPC result только доказывает, что протокол обмена завершен. Это не доказывает, что инструмент принял операцию, что его структурированный выход соответствует рекламируемой схеме или что существует внешний побочный эффект. Запишите границу без хранения чувствительных аргументов: Это событие намеренно исключает токен носителя, аргументы инструмента, тело ответа, текст билета и абсолютные пути. Hash идентификаторы или идентификаторы карты, когда требуются перекрестные соединения. Идентификатор следа полезен только в том случае, если медицинская запись все еще может объяснить первый провальный слой и результат приговора, когда сырой след недоступен. Не пытайтесь перепробовать проблему с авторитетом, как если бы это была потеря пакета. Разрешение заслуживает своего слоя, потому что 401 и 403 предполагают разные действия. Спецификация разрешения на MCP требует от клиентов обращения с 401 Unauthorized и описывает открытие защищенных ресурсов через WWW Authenticate . Он также рекомендует руководство по охвату, чтобы клиент мог узнать о полномочиях, необходимых для текущего запроса. РФК 6750 определяет invalid token как законченный, отмененный, неправильно сформированный или иным образом недействительный токен носителя и ассоциирует его с HTTP 401. Он определяет insufficient scope для токена, который не имеет необходимых привилегий и связывает его с HTTP 403. Это дает оператору безопасное правило принятия решений: 1. Для invalid token попробуйте один раз настроить маршрут обновления. Если обновленный аккредитив не работает, остановить и выйти на поверхность владельца аккредитива. 2. Для insufficient scope , не используйте петлю. Укажите требуемый объем, если он предоставляется сервером, и запросите явный авторитет. 3. Никогда не используйте токен, токен обновления, заголовок разрешений или сырое вызов в общецелевой телеметрии. Это различие также предотвращает разрушительную модель автоматизации: расширение разрешений каждый раз, когда призыв к инструменту не работает. Инцидент соединения не должен превращаться в эскалацию привилегий, и отказ в охвате не должен быть "установлен" путем тихого переключения на более мощный аккредитив. Воспроизвести разрыв между ложным успехом Сопроводительное устройство содержит восемь синтетических вызовов: две ошибки транспорта, одна ошибка метода JSON RPC, две ошибки авторизации, одна ошибка выполнения инструмента, один ложный успех и одна проверенная доставка. Запустить классификатор из каталога артефактов: Решающий результат: Три звонка вернули конверт результатов, но только один дал результат, подтвержденный пунктом назначения. В одном конверте была ошибка в исполнении; в другом заявлялось, что он был успешным, в то время как обещанный артефакт отсутствовал. Результаты подсчета протокола сообщали бы о 37,5% успешности. Подсчет проверенных результатов составляет 12,5%. Разница заключается не в оценке детектора или в оценке LLM: это происходит из за изменения критерия завершения. Установка преднамеренно детерминистическая. Реальные системы добавляют неоднозначность: API билет может совершить запись и время отключения до возвращения своего идентификатора; поиск места назначения может быть устаревшим; ключ с незаменимостью может позволить безопасный запрос согласования. Отметьте эти чемоданы uncertain . Не пытайтесь перепробовать побочный звонок, пока не узнаете, совершена ли первая попытка. Превратить доказательства в правила работы Инструмент один событие здоровья на попытку эксплуатации инструмента, связанное с владельцем. Сохранить первый провальный слой, дезинфицированный код, свежесть доказательств, владельца и проверку результатов. Затем используйте четыре элемента управления: Предупреждение о групповых инцидентах, а не о каждой попытке. Пять звонков, которые не выполняют один и тот же срок действия, являются одним инцидентом с властями. Пополнить повторные попытки по слою. Неисправности транспорта могут получить ограниченный резерв; неисправности протокола и объема обычно требуют контракта или изменения человеком. Разница между ожиданием и застрявшим. Призыв, ожидающий утвержденного потока OAuth, не продвигается, но это не цикл исполнения. Устранение инцидента только после прохождения неисправности слоя and , когда наблюдается предполагаемый результат. Успешное повторное командование это активность, а не восстановление. Следовательно, полезный ряд панели управления небольшой: затронутый агент, первый слой неудачи, эффект, время доказательства, доверие, количество повторных попыток, требуемый авторитет и результат проверки. Необработанные следы могут оставаться неисправностью. Это здоровье оперативного агента, а не требование заменить время выполнения или маршрутизировать каждый запрос модели через новый шлюз. Есть также жесткое ограничение. Не каждый результат имеет детерминистический верификатор. Файл можно проверить по маршруту и перевариванию; билет по стабильной идентификации; развертывание по конечному пункту здоровья и пересмотр. Исследование хорошее может потребовать рубрики или человеческого обзора. Ознакомьте метод и уверенность рядом с приговором вместо того, чтобы превратить отсутствующие доказательства в здоровые. Sidewisp сейчас находится на этапе закрытого предварительного доступа. Его адаптеры мониторинга производства и выполнение восстановления обычно не отправляются. Планируемое направление это слой здоровья наряду с существующими сроками выполнения, который разделяет доступность, прогресс, доступ к инструментам и проверенные результаты при сохранении контроля над людьми. Если эта операционная модель совпадает с вашими агентами, Присоединяйтесь к частному просмотру. Источники Модель Контекстного протокола: Инструменты, версия спецификации 2025 11 25 Модель Контекстного протокола: Разрешение, спецификация версии 2025 11 25 Спецификация JSON RPC 2.0 RFC 6750, OAuth 2.0 Использование токенов носителя