С самого первого дня Cisco IQ создавалась на основе четкой задачи: предоставить унифицированную, детерминированную операционную аналитику на базе ИИ с помощью архитектуры, ориентированной на API.
Мы выполнили это обещание благодаря анонсам на Partner Summit 2026 на прошлой неделе. Мы официально открыли доступ к Cisco IQ, представив комплексный набор производственных REST API и наш сервер Model Context Protocol (MCP). Это гарантирует, что наша аналитика будет беспрепятственно работать с любой существующей системой или ИИ-агентом.
Самое приятное то, что эта база доступна и нашим партнерам. Теперь партнеры могут расширять свои собственные управляемые сервисы с помощью возможностей Cisco IQ, интегрируемых через интерфейсы API и MCP.
С момента общего доступа к Cisco IQ в апреле 2026 года ее внедрили более 16 000 клиентов, и по мере расширения этой экосистемы появился новый класс потребителей API в больших масштабах: автономный ИИ-агент.
Агенты потребляют API совсем не так, как человеческие разработчики программного обеспечения. Разработчики читают спецификации, планируют циклы интеграции и пишут детерминированный код. ИИ-агенты исследуют систему вероятностным методом: они угадывают, повторяют попытки и пытаются объединить разрозненные данные в рамках своего контекстного окна промпта. Поэтому мы задали фундаментальный инженерный вопрос: как должна выглядеть архитектура API, если она спроектирована так, чтобы одинаково хорошо обслуживать человеческих разработчиков и автономных ИИ-агентов на основе одного и того же контракта?
Наш ответ заключается в том, что доверие к агенту не должно быть отдельным решением. Агент не получает отдельную систему, специализированный свод правил или неконтролируемый черный ход. Он работает через ту же самую доменную модель и те же самые политики безопасности, которые уже управляют вашими инженерными командами, операционными панелями и корпоративными интеграциями.
Вот взгляд изнутри на то, как мы воплотили эту реальность в жизнь: от спецификации доменной модели до нашего сервера Model Context Protocol (MCP).
1. Одна каноническая модель — для каждого контракта
В традиционной разработке API, если вы хотите узнать, какие коммутаторы затронуты конкретным объявлением об окончании срока службы оборудования, разработчик обычно пишет специальную конечную точку (endpoint), чтобы объединить эти данные.
Наш подход начинается с того, как инфраструктурные сущности существуют и взаимодействуют друг с другом на уровне системы, а не со списка разрозненных функций. Cisco IQ охватывает множество операционных доменов, и реальная ценность заключается в связях между ними. Когда мы добавляем новую возможность, мы моделируем ее связь с тем, что уже существует — физическим оборудованием, работающими операционными системами, бюллетенями безопасности и контрактами на обслуживание, — а также то, какую новую ценность она приносит в возможности и домены, которые наши клиенты уже используют. Каждое добавление делает целое более полезным, чем сумма его частей.
На практике мы моделируем взаимосвязь, а не очередную конечную точку.
Каждая сущность, взаимосвязь, определение поля и бизнес-правило определяются один раз в единой канонической доменной модели. Эта модель и есть контракт. Все остальное компилируется непосредственно из нее:
- Описания OpenAPI 3.2 и справочная документация, которую читают разработчики.
- Схемы базового хранилища данных, реляционные таблицы и уровни индексации, которые содержат информацию.
- Каталог детальных прав доступа, который авторизует каждый операционный вызов.
- Контракты запросов и инструментов, которые ИИ-агенты используют для анализа данных через MCP.
- Инструменты разработчика, генерация SDK и метаданные представления, которые остаются постоянно синхронизированными.
Взаимосвязи в рамках жизненного цикла инфраструктуры явно объявляются в модели со строгим направлением и кардинальностью.
Поскольку каждая поверхность проистекает из этого общего источника, они не могут расходиться. Поле, которое разработчик проверяет в справочнике API, идентично полю, которое Cisco IQ хранит в базе данных, индексирует при планировании запросов и предоставляет ИИ-агенту. Определение OpenAPI служит абсолютной границей: если функция отсутствует в модели, ее не существует. И когда правило меняется, мы обновляем его один раз в канонической модели, и оно мгновенно распространяется везде: в публичном REST-вызове, в инструментах разработчика и в вызове инструмента MCP агента.
Единый источник истины для людей, программного обеспечения и ИИ-агентов.
2. Предсказуемо для разработчиков, проверяемо для агентов
Хорошо спроектированный API предсказуем. Изучите одну его часть, и вы будете знать остальные. Поскольку каждый API Cisco IQ ведет себя одинаково, разработчик или агент, изучивший одну его часть, может предсказать поведение остального, а все возникающие проблемы возвращаются в виде одного четкого ответа, а не предположения. Мы приняли конкретные архитектурные решения, чтобы гарантировать абсолютную согласованность работы наших API:
- Изучай один раз, запускай где угодно: Каждый URL-адрес ресурса следует единой структуре (https://{host}/api/{namespace}/v1/{resource}), поэтому никакой вызов никогда не нужно переучить, выполняя маршрутизацию через региональные конечные точки (например, us-west-2, eu-central-1) для соблюдения строгих требований по суверенитету и размещению данных.
- Стандартизированные запросы и чистые схемы: Коллекции верхнего уровня принимают единообразные параметры с использованием языка общих выражений (Common Expression Language, CEL), обеспечивая одинаковое поведение условий везде. Чтобы предотвратить сбои при генерации SDK, мы избегаем раздувания схем oneOf в наших определениях OpenAPI. Кроме того, мы применяем строгое правило псевдонимов с ведущим подчеркиванием (_) для определяемых клиентом вычислений в запросах, чтобы гарантировать, что они никогда не столкнутся с будущими дополнениями к схеме платформы.
- Устойчивая пагинация и ограниченные взаимосвязи: Традиционная пагинация на основе смещений дает сбой, когда потоки телеметрии оборудования меняются одновременно. Наши коллекции принудительно используют пагинацию по ключам с помощью непрозрачных курсоров (RFC 5988) для гарантии стабильного чтения. Мы также ограничиваем ответы для связей «многие к одному» (to-many) вместо ограничения данных, отображая огромные наборы данных (например, 10 000 уязвимостей безопасности) прямо в тексте с помощью ограниченных конвертов или в виде структурированных ссылок href для атомарного добавления и удаления.
- Безопасная запись и громкие сбои: Снисходительные API поощряют угадывание. Неизвестные поля или некорректные значения приводят к немедленным ошибкам с использованием деталей проблем RFC 9457, выдавая все ошибки валидации в одном структурированном массиве, чтобы разработчик или агент могли исправить их за одну итерацию. Для обновлений мы используем JSON Merge Patch для атомарных модификаций и ETag для оптимистичной блокировки (concurrency), гарантируя, что конфликтующие записи завершатся безопасным сбоем, а не перезапишут изменения другого процесса.
- Авторизация в терминологии модели: Разрешения названы непосредственно в честь действий: от полного типа (read:asset.Asset) до отдельного атрибута (update:asset.Asset.tags). Списки фильтруются строка за строка, гарантируя, что вызывающая сторона получает только те точные записи, на просмотр которых у нее есть разрешение.
- Работоспособность и эволюция без нарушения обратной совместимости: Каждая операция находится под неизменяемым путем версии, а ответы содержат заголовки W3C traceparent для распределенной трассировки. В наших CI/CD-пайплайнах выполняются автоматические проверки совместимости, которые выявляют критические изменения контрактов до их выпуска.
3. Почему просто обернуть API в оболочку недостаточно для агентов
Большинство серверов MCP сегодня предоставляют каждую отдельную операцию API в качестве отдельного инструмента. Чтобы ответить на вопрос вроде «У каких критических устройств заканчивается поддержка в этом квартале и по какому контракту они обслуживаются?», агент должен просматривать страницы с устройствами, записями о поддержке, контрактами, а затем самостоятельно объединять эти строки.
В наших базовых измерениях ответ на один типовой междоменный вопрос с использованием традиционной обертки API потребовал примерно 120 вызовов инструментов только для того, чтобы собрать 40 строк.
Такой подход переносит самую сложную часть проблемы — сопоставление данных из разных доменов — в наименее подходящее для этого место: контекстное окно модели ИИ. Контекст теряется на каждом шаге, задержка возрастает, а получаемые ответы склонны к галлюцинациям при соединении данных. Сопоставление должно происходить на уровне платформы, а не в промпте.
4. Универсальные операции: перенос сопоставления на уровень платформы
Мы решили эту проблему, спроектировав две универсальные операции платформы, которые изначально справляются со сложностью междоменных связей:
- Структурированный запрос (POST /api/system/v1/query): считывает любую сущность с фильтрацией, проекцией, упорядочиванием и вложенным расширением в рамках одного полезного блока JSON. Он расширяет связанные записи и выполняет агрегацию (groupby, apply, having, compute) по связанным доменам за один вызов в рамках авторизации вызывающей стороны.
- Пакетный обработчик (POST /api/system/v1/bulk): выполняет несколько изменений состояния в одном запросе. Клиенты отправляют плоский список операций по пространствам имен без необходимости вычислять графы ручных зависимостей.
- Автоматическое разрешение зависимостей: обработчик автоматически упорядочивает операции и разрешает циклические ссылки на сущности, откладывая отложенные ссылки и записывая их как автоматические последующие шаги.
- Синхронный частичный успех: атомарность является неотъемлемым свойством операции записи, а не HTTP-соединения. Пакетный обработчик поддерживает частичное выполнение в синхронных ответах, возвращая явные результаты, сопоставленные точно с исходными отправленными позициями. Это позволяет клиенту или агенту мгновенно повторно отправить только те операции, которые завершились ошибкой.
5. Четыре инструмента для эпохи агентов
Поскольку сопоставление выполняется на уровне платформы, нашему серверу MCP не нужно предоставлять агенту ИИ сотни хрупких отдельных операций. Он предоставляет ровно четыре инструмента, спроецированных непосредственно из канонической модели:
- discover: находит сущности, необходимые для ответа на вопрос, пути связей между ними и применимые действия.
- describe: возвращает точный контракт, поля, типы данных и предварительные условия для выполнения действия для сущности или операции.
- query: проверяет структурированный запрос на соответствие схеме и выполняет его через механизм запросов платформы.
- mutate: выполняет атомарное изменение после проверки предварительных условий и авторизации.
Когда Cisco IQ добавляет новую сущность, каждый агент обнаруживает ее автоматически с помощью тех же четырех инструментов. Стабильная, безопасная среда, которая органично растет вместе с моделью.
6. Идентификация агента
Агент, обращающийся к нашей платформе через MCP, использует стандартную аутентификацию API, наследуя точный профиль авторизации вызывающего субъекта. Cisco IQ изначально интегрируется с Cisco Unified Identity (CUI), связывая эту идентичность с нашим детализированным каталогом на основе ролей. Независимо от того, предоставляет ли политика доступ на чтение ко всему домену или ограничивает права на запись исключительно одной меткой актива, ИИ-ассистент действует строго в рамках авторизованных границ вызывающей стороны. Он не получает никаких дополнительных бизнес-привилегий просто потому, что подключается через MCP.
7. Проверка перед запуском: детерминированное поведение вероятностных моделей
На предприятии запрос, завершившийся ошибкой, — это неприятность. Запрос, возвращающий неправильный ответ, — это неприемлемый риск.
Чтобы обеспечить детерминизм, каждый написанный агентом запрос проверяется на соответствие доменной модели до того, как он попадет в механизм выполнения. Если агент ошибся в названии поля, значении или связи:
- Все ошибки валидации возвращаются одновременно в структурированном ответе RFC 9457.
- Сервер включает предварительно проверенный и исправленный полезный блок запроса, который агент может отправить повторно напрямую.
- Сервер никогда не переписывает молча и не выполняет запрос на основе предположений; агент сохраняет явный детерминированный контроль.
- Мутации сначала представляют требуемые состояния как операции чтения, позволяя операторам-людям изучать точные различия (diff) перед подтверждением выполнения.
Что это означает на практике? В ходе тестовых запусков по эталонному корпусу из 17 сложных корпоративных сценариев эта архитектура обеспечила решительное улучшение операций:
- Общее количество вызовов инструментов сократилось с 256 до 36.
- Количество запросов на интерактивное подтверждение уменьшилось со 181 до 1.
- Стандартные междоменные проверки на чтение выполнялись ровно за два вызова: discover, за которым следует query.
Меньше вызовов, меньше запросов на подтверждение и ответы, за которыми стоит платформа.
Инженерные возможности для клиентов и партнеров
Эти архитектурные решения открывают конкретные инженерные возможности для каждой операционной роли:
- Для клиентов: кто бы ни действовал от вашего имени — инженер, автоматизированный конвейер CI/CD или автономный ИИ-агент, — он работает в рамках тех же средств защиты безопасности, которым вы уже доверяете. Агент никогда не видит больше, чем разрешено видеть представляемому им субъекту, что исключает необходимость поддерживать параллельные модели разрешений. Развертывание ИИ-агента перед вашими данными не является новым решением о доверии.
- Для партнеров: интегрируйтесь один раз на основе единого контракта. Каждая представляемая нами функция следует одинаковым соглашениям о схемах, параметрам запросов и правилам доступа. Независимо от того, создаете ли вы собственные управляемые сервисы под своим брендом или подключаете специализированные внутренние агенты, вы осваиваете шаблон интеграции один раз, вместо того чтобы создавать одноразовые адаптеры для каждого этапа жизненного цикла.
Скоро: семантический поиск по смыслу и измерения живых агентов
Мы активно расширяем эту основу. Мы внедряем семантический поиск по смыслу наряду с поисковыми запросами по ключевым словам, гарантируя, что запросы на естественном языке находят целевые сущности так же надежно, как и запросы, написанные в строгих терминах схемы.
Мы также проводим тестирование живых автономных ИИ-агентов на нашем эталонном корпусе из 17 вопросов, готовясь опубликовать реальные данные о производительности агентов наряду с нашими существующими базовыми показателями по скриптам.
Основа для API, готовых к работе с агентами
В конечном итоге эти архитектурные решения служат одновременно и разработчикам-людям, и автономным ИИ-агентам. Предсказуемые URL-адреса, стандартизированные конверты ответов, структурированные форматы ошибок и единообразные параметры CEL упрощают интеграцию для разработчиков, делая при этом результаты работы агентов строго проверяемыми. Единая модель для каждого контракта гарантирует, что то, что мы предоставляем агенту, — это ровно то, что выполняет платформа.
Эта архитектура также готовит нас к тому, что будет дальше. Поскольку проверка запросов, структурная корреляция и исправление ошибок происходят на уровне платформы, а не в промпте, качество выполнения не зависит от размера параметров модели.
Такая архитектура позволяет небольшим, высокоэффективным и локально развертываемым моделям работать с той же точностью, что и передовые модели. Она гарантирует применение идентичных контрактов и средств защиты везде, где запущен Cisco IQ — от региональных облачных экземпляров до полностью изолированных суверенных виртуальных устройств.
API, созданные исключительно для разработчиков-людей, больше не достаточны. Они должны активно направлять ИИ-агентов к проверенным данным и физически предотвращать выполнение ими недопустимых операций.
Именно так создаются API для эпохи агентов.
Начало работы
- Узнайте больше: изучите документацию по API Cisco IQ и полную справочную документацию по API.
- Подключение агента: обратитесь к руководству по MCP-серверу Cisco IQ, чтобы подключить ваши ИИ-клиенты.
- Свяжитесь с нами: обратитесь к своей команде по работе с клиентами Cisco, чтобы обсудить возможности использования API и MCP Cisco IQ в вашей среде.
