AI Агент наблюдаемость для MCP Изменения инструмента: доказать конвергентность обнаружения

Агент AI, использующий инструменты MCP, не является здоровым только потому, что его процесс жив, его серверное соединение открыто или он получил уведомление о изменении списка инструментов. Практическая проверка более строгая: после соответствующего изменения клиент завершил новый переход tools/list , последовал странице до конца и заменил свой реестр точными определениями инструмента, которые он обнаружил? Обращайтесь к этому как к тесту конвергенции. Зарегистрируйте согласованную версию протокола MCP и возможности tools.listChanged , последний срок notifications/tools/list changed , время начала и завершения обнаружения, каждый курсор и канонические дигесты обнаруженных и установленных реестров. Возврат converged , stale , incomplete или unverifiable . Не превращайте отсутствующие доказательства в зеленый результат. Определить конвергенцию на границе протокола Спецификация жизненного цикла MCP требует инициализации до нормальной работы. Клиент и сервер ведут переговоры о версии протокола и возможностях, и обе стороны должны уважать эти переговоры. Успешное инициирование доказывает, что одна сессия началась по согласованному контракту. Это не доказывает, что последующее изменение инструмента достигло клиента. Спецификация инструментов MCP поставляет следующие части: сервер, поддерживающий инструменты, заявляет о возможности tools ; listChanged сообщает, будет ли он выдавать уведомления об изменении списка инструментов; клиенты открывают определения через tools/list ; открытие может быть переделено на страницы через nextCursor ; определение инструмента включает в себя больше, чем его название, в частности inputSchema и факультативный outputSchema , анотации и метаданные исполнения. Это создает три отдельных события, которые не должны разрушаться: 1. Смена сигнала: клиент получает notifications/tools/list changed . 2. Открытие: он начинает новый переход tools/list и достигает ответа, чья nextCursor отсутствует или не имеет значения. 3. Registry install: определения, используемые клиентом, соответствуют завершенному снимку обнаружения. Уведомление это намек на обновление, а не квитанция за завершенное обновление. Первая страница это деятельность, а не полный реестр. Сопоставляемые имена не являются сопоставляющимися контрактами, когда требуется изменение аргумента, схемы выхода или свойства исполнения. Сделайте доказательства небольшими, но решающими Чтобы иметь полезный медицинский учет, не нужно получать запросы, аргументы с инструментами, справки или результаты инструмента. Он нуждается в достаточном количестве безопасных метаданных, чтобы ответить на вопрос, согласны ли клиент и сервер: Поле Что он устанавливает Что он не устанавливает protocolVersion Переговорный вариант МПК на сессии Что более позднее выпуск сервера оставался совместимым tools.listChanged Были ли проведены переговоры о уведомлениях об изменении Что уведомление было доставлено или обработано notificationAt Наступило время для освежения . Это открытие началось discoveryStartedAt и discoveryCompletedAt Ограниченное освежение зафиксировано после сигнала . Что каждая страница была получена цепь курсоров Описание окончилось без пробелов . Что клиент установил результат обнаруженный реестр Идентичность комплекта определений Что призыв к инструментам будет успешным реестр клиентского реестра Идентификация того, что клиент в настоящее время раскрывает агенту Что агент будет правильно выбирать Создайте дигест из стабильной проекции: name , title , description , inputSchema , outputSchema , annotations и execution . Сортировать инструменты по именам и канонизировать заложенный JSON перед хэшированием. Декоративные иконы могут быть исключены, если они не влияют на выбор или выполнение, но само проекция должна быть версией. РФК 8785 объясняет, почему повторяемое хэширование требует неизменной сериализации JSON и рекурсивного сортирования свойств. Компактный рекурсивный сортер, используемый в этом эксперименте, адекватен для обычных значений JSON фиксации; он не представлен как полная реализация JCS. Продукционный код должен использовать пересмотренную библиотеку канонизации, особенно когда нумерационные рамки или подписи имеют значение. Не хранить сырые секреты в записье. Схемы инструментов должны описывать формы аргументов, а не ценности аккредитации. Если описание содержит данные арендаторов или внутренние пути, то выредактируйте его перед сбором и запишите, какая версия проекции произвела дигест. Воспроизводить аудит реестра в шести случаях В сохраненном устройстве используются шесть синтетических наблюдений: полный двухстраничный базовый план; удаление инструмента, после чего происходит полное обновление; уведомление о изменении, после которого не было обнаружено новых данных; первая страница с оставшимся nextCursor ; имя одного и того же инструмента с измененной схемой ввода; сервер, который не рекламировал listChanged , без ограничения сведений о обновлении. Основной порядок принятия решений имеет значение: Запустить устройство с помощью Node.js: Точная повторная игра вернулась: Противоприведенные примеры более полезны, чем два зеленых случая. notification without refresh имеет идентичные обнаруженные и клиенты переваривают, но его открытие завершено до сигнала изменения. Переваривание совпадает с старым снимком. unfinished pagination также имеет соответствующие дигесты для одной наблюдаемой страницы, но nextCursor остается. Допустимое совпадение первой страницы является неполным доказательством. В случае с одним и тем же именем read ticket изменяется с требования только ticketId к требованию как projectId , так и ticketId . Инвентарь только по имени не изменит реестр. Каноническое определение переваривается с c42521a2412558ca на c3837b93f14b688f , поэтому старое определение клиента классифицируется как устаревшее. Превратить приговор в оперативное решение Используйте converged в узкой форме. Это означает, что наблюдаемый клиентский реестр соответствует одному полностью пересеченному открытию, завершенному после соответствующего изменения сигнала. Это не доказывает доступность транспорта для следующего вызова, действительные разрешения, правильное поведение инструмента, успешный внешний эффект или предполагаемый результат задачи. Управлять остальными состояниями без агрессивной автоматизации: Приговор Доказательства Следующий шаг безопасный. stale Обновление старше сигнала, или реестр отличается Перестаньте выбирать значение, которое влияет на вас; запросите одно ограниченое обновление; проверьте, прежде чем перепробовать последовательную работу incomplete Открытие началось , но прохождения курсора или завершения доказательства отсутствуют . Возобновить с ожидаемого курсора, если клиент поддерживает его, в противном случае возобновить открытие один раз unverifiable Никаких ограничений на обнаружение доказательств не существует Отчет о недоступности сигнала; переподключение или планирование контролируемого обновления в соответствии с политикой runtime converged Полное открытие после изменения и точное совпадение переваривания Продолжайте, сохраняя отдельные проверки вызова, эффекта и результата Если сервер не рекламирует listChanged , ожидается молчание и не может установить свежесть. Определить ограниченную альтернативу: обновление при восстановлении соединения, до высокоэффективной работы или в измеренном интервале, соответствующем пределам затрат и тарифов сервера. Зарегистрируйте эту политику, так что "нет уведомления" не будет ошибочно пониматься как "нет изменений". Также отделять здоровье реестра от здоровья задач. Инструмент может присутствовать и правильно описываться, пока срок действия его аккредитации истекает. Он может вернуть isError: false , пока обещанный билет, файл или развертывание отсутствуют. После любой утвержденной восстановления проверьте внешний эффект или результат задачи вместо объявления успеха, потому что обнаружение или команда завершены. Сохранить границы продукта и полномочий Эта проверка относится к наблюдаемости агента AI, поскольку доступность инструмента и дрейф разрешений могут блокировать полезный прогресс, пока агент остается активным. Это сигнал здоровья, а не разрешение на перезагрузку времени, перемены учетных данных, использование инструментов или повторное расходование. Следующее вмешательство должно оставаться ограниченным, видимым и подлежащим одобрению человека. Целевое направление Sidewisp это слой здоровья вокруг существующих сроков действия агента: показать доказательства, свежесть, серьезность, неопределенность и наиболее безопасное следующее действие. Запись конвергенции MCP в данной статье представляет собой операционную модель и эксперимент, а не утверждение о том, что Sidewisp в настоящее время собирает ее. Sidewisp сейчас находится на этапе закрытого предварительного доступа. Общественный сайт и система статей на экране. Производственный агент собрание здоровья, адаптеры MCP runtime, автоматическое восстановление, управление cron и анализ стоимости токенов, как правило, не отправляются. Присоединяйтесь к частному просмотру, если вы хотите помочь сформировать контракты на доказательства, такие как переговоры о протоколе, конвергенция реестра, доступность инструментов и проверенные результаты, сохраняя человеческий авторитет ясным.