Как выбрать инструменты поиска для агентов: от обнаружения источников до проверенных ответов

Поисковый агент может выдать десять на вид релевантных ссылок и всё равно не ответить, поддерживается ли параметр сейчас. Ссылки могут вести на устаревшие версии, сниппеты могут опускать ограничения, а несколько статей могут ссылаться на одно и то же объявление. Часто следующим шагом нужно прочитать исходную страницу, а не искать чаще.

При выборе инструментов сначала определите, что должен дать текущий шаг: источники для чтения, содержимое конкретной страницы или доказательства в поддержку конкретного вывода. В статье инструменты поиска EveryInfra сгруппированы по этим трём типам результатов. Затем объясняется, когда следует прекратить поиск, зафиксировать, что осталось неизвестным, и проверить цитаты. Каталоги и исторические вызовы с временными метками описаны отдельно; в статье не проводится сравнительное тестирование всех инструментов, и она не претендует на описание сквозной исследовательской системы.

Сначала переформулируйте вопросы в проверяемые утверждения

«Разобраться в продукте» годится как направление исследования, но не как условие завершения работы инструмента. Разбейте эту цель на проверяемые вопросы: какой эндпоинт принимает этот параметр, к какой версии это относится, нужны ли дополнительные права и можно ли повторить запрос после сбоя. Для каждого вопроса укажите временную метку, продукт и контекст использования.

Например, редактор, проверяющий, можно ли интегрировать удалённый сервис с клиентом, должен отдельно выяснить, какой транспорт поддерживает сервис, какие методы аутентификации принимает клиент и был ли вызов успешно выполнен в этом клиенте. Первые два ответа даёт документация, а для третьего нужно подтверждение фактическим выполнением. Даже если в двух документах независимо упоминается поддержка MCP, без такого подтверждения нельзя считать интеграцию проверенной.

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

Чтобы разобраться в этом процессе, прочитайте оригинальную статью Льюиса и соавторов о RAG: в ней генеративные модели сочетаются с хранилищами данных для поиска, а параметрические знания не рассматриваются как единственный авторитетный источник. Описанные в этом материале поиск источников, чтение и поэлементная проверка относятся к проектированию прикладного уровня; экспериментальные результаты статьи не дают оснований гарантировать точность какого-либо веб-агента.

Начинайте с поиска источников, только если расположение страницы неизвестно

Если у вас есть вопросы, но нет URL, начните с поиска потенциально релевантных страниц через web. В публичном каталоге на 2026-9-4 параметр q указан как обязательный, а среди необязательных есть сайт, регион, время и номер страницы. Перед вызовом всегда проверяйте актуальный каталог и не угадывайте названия параметров по естественному языку.

Инструменты для поиска источников можно выбирать по входным данным и ожидаемым результатам:

• semantic подходит для описания понятий на естественном языке; suggest помогает подобрать формулировки запросов. Связанные термины — это подсказки для поиска, а не выводы.
• similar ищет похожие страницы, отталкиваясь от уже известных URL; deep даёт точки входа для более глубокого поиска. Слово «deep» в названии инструмента не означает, что страница отвечает текущим требованиям к доказательствам.
• news, scholar и forum смещают область поиска на новости, научные материалы или обсуждения. Они меняют охват источников, но не стандарты автоматической проверки фактов.
• places, shopping, media и lens работают соответственно с местами, товарами, ключевыми словами для медиа и URL изображений. Входные данные у них разные, поэтому объединить их в одну функцию, принимающую только q, нельзя.

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

Если URL уже есть, переходите от повторных поисков к чтению

read получает содержимое указанных страниц. Используйте map, чтобы изучить структуру страниц на сайте, а если нужно прочитать несколько страниц, рассмотрите crawl. Для структурированных задач по сайту сначала изучите назначение harvest и требования к его полям, а не используйте его как точку входа по умолчанию для чтения одной страницы.

Это различие влияет на последующую проверку. Получив список URL из map, не записывайте найденную страницу в прочитанные материалы; предложения из поисковых сниппетов тоже нельзя помечать как полностью проверенные. Если содержимое обрезано, включает только элементы навигации или вместо него возвращается страница входа, этап чтения остаётся незавершённым.

Не используйте переход к другому инструменту для обхода ограничений доступа. Столкнувшись с запросом на вход, явным отказом в доступе или неясными границами авторизации, остановитесь и сначала выясните, какие способы доступа разрешены. Для временных сбоев страницы можно сохранить условия повторной попытки, но если доступ к ресурсу не разрешён, нужно пересмотреть границы задачи, а не менять инструмент в попытке обойти запрет.

Проверьте обязательные параметры одной бесплатной командой

Следующая команда только читает публичные каталоги инструментов: она не выполняет поиск, не загружает целевое содержимое и не требует API-ключа. В терминале должны быть установлены curl и jq; включение pipefail не позволяет последующей обработке скрыть ошибки запроса.

set -o pipefail
curl -fsS --max-time 20 \
  'https://api.everyinfra.com/api/v1/search/tools' \
  | jq -e '
      [.tools[] |
       select(.tool == "web" or .tool == "read" or .tool == "crosscheck") |
       {tool, required_params, optional_params}]
      | if length == 3 then . else error("selected tool missing") end'

В этой проверке web и crosscheck требуют q, а read требует url. Необязательные параметры crosscheck: num, since, read_top, depth и mechanisms; у read необязательных параметров нет. Не передавайте вслепую одни и те же поля времени или количества во все инструменты. Публичный каталог поиска

В том же каталоге перечислено 17 инструментов. Это число обозначает длину списка, возвращённого запросом, но не означает, что все 17 позиций прошли бизнес-проверку, и не является долгосрочным обязательством, которое можно выносить в заголовки статей. Описания в каталоге показывают, как отправлять запросы, но не гарантируют полноту содержимого, количество результатов или статус оплаты.

Crosscheck помогает находить связи между доказательствами, но не определяет достоверность фактов

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

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

Не применяйте к этому процессу непроверенные фиксированные пороги. Например, не считайте, что вес цитаты для ИИ удваивается, если одно и то же число встречается на трёх доменах. Согласно официальной документации Google по AI Overviews и AI Mode, публичные рекомендации сосредоточены на базовых принципах SEO, внутренних ссылках, которые помогают находить страницы, и полезном контенте. Они не предписывают правил умножения веса для нескольких доменов и не описывают работу всех RAG-систем. Числа, опубликованные одной командой на корпоративных сайтах, в LinkedIn и на Medium, помогают читателям найти первоисточники, но в карточках доказательств их нужно сводить к одному исходному наблюдению, а не считать тремя отдельными голосами.

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

Заводите карточку доказательств для каждого вывода

Рекомендуем хранить в бизнес-системах следующие поля. Это предлагаемая схема записи, а не описание структуры ответа API:

• claim: минимально необходимое утверждение, а также продукты, версии и регионы, к которым оно относится.
• source_url и final_url: исходная точка входа и итоговая целевая страница, чтобы выявлять редиректы и дублирующиеся источники.
• observed_at: время чтения; хранится отдельно от указанных на странице published_at и updated_at.
• evidence_locator: указатели на конкретные разделы, абзацы или примеры, а не просто на главную страницу.
• support_status: рекомендуемая классификация со статусами «подтверждает», «противоречит», «не относится к делу», «не читается» и «ожидает проверки».
• limits: ограничения области применения, исключения, пробелы в доказательствах и условия повторной оценки из исходного текста.

Карточки доказательств нужны не ради лишней бумажной работы, а чтобы другой проверяющий мог оценить тот же вопрос по той же ссылке. Если сохранить только «сайт A говорит „да“», повторная проверка невозможна; если опустить условия из источника, вывод нельзя будет исправить дополнительными ссылками.

Для динамических цен, версий и списков возможностей установите сроки повторной оценки и перед публикацией заново проверяйте сами цитируемые фрагменты. Доступность страницы не гарантирует, что её содержимое не изменилось, а рабочая ссылка — что исходные утверждения по-прежнему верны. Изменяя выводы, сохраняйте исходные доказательства, а не заменяйте прежние даты наблюдения сегодняшней.

Для отслеживания связей между этапами обратитесь к рекомендациям W3C PROV о сущностях, действиях и связях происхождения данных: они помогут связать версии источников, журналы чтения и ответы. Это позволяет объяснить происхождение выводов, но не определяет автоматически независимость источников или правильность содержимого.

Различайте состояния «успешно», «пустой результат» и «не удалось прочитать»

В обезличенном рабочем примере от 2026-9-02 web вернул 3 результата, а один вызов crosscheck вернул записи по 4 механизмам. В том же раунде были примеры, где read не смог прочитать указанные документы, возникала ошибка HTTP 503, а запросы к scholar выполнялись успешно, но с пустыми результатами. Это конкретные исторические входные данные, а не гарантия поведения для всех вызовов.

Повторная проверка 2026-9-4 касалась только каталогов инструментов, процессы аутентификации заново не запускались. Поэтому в этой статье не утверждается ни «read сейчас не работает», ни «read восстановлен». При приёмке интеграции нужно самостоятельно проверить получение полного содержимого, сохранение состояния ошибки и поддержку цитирования; старые примеры не заменяют актуальные результаты.

Для агентов пустой набор должен сохранять условия запроса и временной диапазон и выдавать «в этом раунде результатов не найдено», а не «таких фактов не существует». Если страницу не удалось прочитать, сохраняйте найденные URL и состояние сбоя и не выдавайте сниппеты за полное содержимое. Если из-за тайм-аута результат запроса неизвестен, не делайте поспешных выводов о том, что задача не выполнена или аккаунт не изменился.

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

Проверка цитат и безопасности входит в единый процесс подготовки результата

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

Закончив ответ, проверьте цитаты построчно: подтверждают ли ссылки утверждения, рядом с которыми они стоят, сохранены ли ограничения, соответствуют ли даты времени наблюдения и не учтены ли первоисточники дважды? Одного лишь непустого списка источников недостаточно. Особенно при подмене «можно подключить» на «полностью реализовано» или «поддерживает поля» на «возвращает все поля» по цитатам редко можно понять, что исходный смысл был расширен.

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

Вредоносные инструкции в тексте веб-страниц создают риски непрямой инъекции промптов, описанные OWASP. В соответствии с принципами минимальных привилегий и проверки вызовов инструментов текст страницы не должен наделять инструменты чтения возможностью загружать файлы или изменять аккаунт; действия с высоким риском должны по-прежнему требовать отдельной авторизации.

Начните интеграцию с одного проверяемого вопроса

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

Публичные каталоги EveryInfra позволяют сначала проверить инструменты и входные данные; реальные вызовы в рабочих сценариях, обработку сбоев и качество результата нужно проверять на собственных примерах, которые входят в разрешённую область. Цель статьи достигнута не тогда, когда «вызван каждый инструмент», а когда читатель может указать, какие утверждения подтверждены первоисточниками, какие остаются неизвестными и какие доказательства нужны дальше. Открыть документацию API