AnySearch для AI-агентов: структурированный поиск, снижение расхода токенов и улучшенный контекст в реальном времени

Введение

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

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

Продукт занял первое место на Product Hunt как в день, так и в неделю 6 июля 2026 года. В описании релиза подчеркивается, что он предоставляет информацию в реальном времени, отфильтрованную, дедуплицированную и структурированную, через API, MCP-сервер или устанавливаемые навыки агентов.

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

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

Почему обычные результаты поиска дороги для агентов

Люди могут просматривать страницу результатов, игнорировать рекламу, распознавать дублирующиеся статьи и определять, на какие ссылки стоит обратить внимание.

Агенты же часто получают каждый результат как входные данные, что влечет за собой множественные затраты:

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

Проблема не только в точности поиска, но и в форме и плотности возвращаемой информации.

Поэтому практичная поисковая система для агентов должна ответить на три вопроса, прежде чем передавать информацию модели:

1. Какой тип источника наиболее подходит для этого запроса?
2. Какие результаты предоставляют уникальные и надежные доказательства?
3. Как доставить результаты без веб-шума?

AnySearch спроектирован именно вокруг этих шагов.

Релиз на Product Hunt и публичные результаты бенчмарков

AnySearch занял первое место на Product Hunt как в день, так и в неделю 6 июля 2026 года. Product Hunt описывает его как

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

В исходной статье также представлена система оценки из 300 вопросов, построенная на трех бенчмарках:

• FRAMES
• FreshQA
• WebWalkerQA

В статье отмечается, что AnySearch, Brave Search и Parallel использовали одну и ту же языковую модель, поэтому поисковый уровень (а не выбор модели) является основной переменной.

Заявленная точность

Поисковая система	Общая точность	FreshQA	WebWalkerQA
AnySearch	76.4%	80.0%	65.2%
Brave Search	64.0%	74.0%	46.8%
Parallel	72.2%	78.0%	61.0%

FreshQA оценивает вопросы, зависящие от текущей или меняющейся информации. WebWalkerQA фокусируется на просмотре нескольких страниц и поиске доказательств. Их комбинация весьма актуальна для агентов, которым нужны не просто поверхностные списки ссылок.

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

Заявленная задержка

Диаграмма задержки показывает, что значения AnySearch ниже как по среднему сравнению, так и по подмножеству WebWalkerQA.

Поисковая система	Средняя задержка	Задержка WebWalkerQA
AnySearch	48.0	76.5
Brave Search	68.9	133.0
Parallel	77.4	145.6

Исходное изображение не указывает единицы измерения, поэтому таблица намеренно сохраняет значения из отчета, не преобразуя их в секунды или миллисекунды.

Подключение AnySearch к агенту

AnySearch в настоящее время поддерживает три основных способа интеграции:

• API
• MCP
• Навык агента (Agent Skill)

Официальный GitHub-проект предоставляет навык и MCP-сервер под лицензией Apache-2.0. Оба поддерживают общий веб-поиск, вертикальный поиск, параллельный пакетный поиск и извлечение содержимого целых страниц по URL.

Это изображение связано с разделом документа, где описывается AnySearch, и наглядно демонстрирует функции и возможности AnySearch, помогая читателю лучше понять поддерживаемые типы поиска и другую информацию.](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/80912d0a-73aa-4f80-bbab-eb6f0779cd63-e96fb0d4-000e-4288-ae1b-bf3c078c578f.png)

Установка навыка AnySearch

Официальный репозиторий рекомендует загружать фиксированную версию (pinned release), а не неопубликованные изменения из основной ветки.

Ветка.

# Загрузить указанную версию AnySearch Skill.
# Замените v2.1.0 на более новую стабильную версию, когда она появится.
curl -L -o anysearch-skill.zip \
  https://github.com/anysearch-ai/anysearch-skill/archive/refs/tags/v2.1.0.zip

# Распаковать архив.
unzip anysearch-skill.zip

Переместите распакованный каталог в соответствующее место для вашего агента:

# Claude Code
mv anysearch-skill-2.1.0 ~/.claude/skills/anysearch

# OpenCode
mv anysearch-skill-2.1.0 ~/.config/opencode/skills/anysearch

# Проект Cursor или Windsurf
mv anysearch-skill-2.1.0 <project>/.skills/anysearch

# Общая папка агента
mv anysearch-skill-2.1.0 ~/.agents/skills/anysearch

Точный каталог зависит от платформы агента и её текущих правил обнаружения навыков.

API-ключи и анонимный доступ

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

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

Тест 1: Поиск промышленного Go-кода

Первый тест в исходной статье требовал от агента найти реальную, ориентированную на производство реализацию API-ограничителя скорости на Go, а не учебное руководство.

Запрос был:

Я создаю проект, мне нужна реализация API-ограничителя скорости на Go. Мне не нужны учебники. Найдите промышленный код из реального проекта с открытым исходным кодом.

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

Запуск с помощью AnySearch вернул более структурированные, ориентированные на код результаты с более понятными цепочками вызовов и материалами из реальных кодовых баз.

Это различие критически важно, поскольку производственный код — это не только алгоритмы. Полезный результат поиска должен помочь агенту проверить:

• Структуру пакета
• Инициализацию
• Конфигурацию
• Зависимости от хранилища или распределённого состояния
• Интеграцию с промежуточным ПО
• Обработку ошибок
• Тестирование
• Лицензию
• Активность проекта
• Связь кода с остальной частью репозитория

Поиск кода, который извлекает красивую функцию, но игнорирует её контекстные допущения, может ввести в заблуждение агента-реализатора.

Лучший запрос на поиск промышленного кода

Независимо от поставщика поиска, более точный запрос может улучшить результаты:

Найти поддерживаемые Go-проекты с открытым исходным кодом, которые реализуют API-ограничение скорости в промышленном коде.

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

Поисковая система должна предоставлять доказательства. Агент-кодер должен всё равно проверить репозиторий, лицензию, тесты, предположения о безопасности и текущее состояние обслуживания перед адаптацией кода.

Тест 2: Due diligence компании

Второй тест

сравнил AnySearch и Exa в задаче исследования одной и той же компании.

Оба отчёта показали хорошие результаты по базовой публичной информации о компании. Различия в основном касались раздела рисков.

Сообщается, что AnySearch нашёл локально опубликованные записи о соблюдении нормативных требований и объявления на платформах, которые отсутствовали в отчёте, сгенерированном Exa. Источник объяснил это различие доступом к китайским вертикальным источникам данных, а не самой языковой моделью.

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

Агент due diligence должен явно искать по нескольким категориям:

1. Регистрация компании и бенефициарная собственность
2. Финансирование и изменения в составе акционеров
3. Судебные иски и записи о правоприменении
4. Нормативные объявления
5. Жалобы на продукцию и штрафы платформ
6. Патенты и товарные знаки
7. Инциденты кибербезопасности и утечки данных
8. Изменения в руководстве
9. Финансовые и операционные сигналы тревоги
10. Последние новости с внутреннего рынка компании

Важно: Due diligence с помощью поиска не заменяет профессиональную юридическую, финансовую или комплаенс-проверку. Записи могут быть неполными, названия — запутанными, а автоматические сводки — неверно интерпретировать доказательства.

Тест 3: Отчёт о глобальном энергетическом рынке в реальном времени

Третий тест потребовал от AnySearch создать отчёт о глобальном энергетическом рынке, охватывающий:

• Изменение запасов природного газа в США
• Цены на электроэнергию на день вперёд по европейским странам
• Углеродоёмкость электросети Австралии

Источник сообщает, что выводы включали детали региональных запасов, сравнение цен на электроэнергию в Европе и данные о выбросах. В отчёте были приведены недавние данные, включая публикацию Управления энергетической информации США от 9 июля и цены на электроэнергию на день вперёд в Европе от 12 июля.

Этот рисунок связан с содержанием третьего теста в документации, представляя данные о ценах на электроэнергию на день вперёд для нескольких европейских стран и являясь частью отчёта о мировом энергетическом рынке, созданного AnySearch.](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/3f5432f8-0641-4e6e-b8aa-62b6a50e7d18-f18fcac7-52c7-4efa-a066-9c9722c9cea9.jpeg)

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

Надёжная реализация должна обеспечивать следующее:

1. Разбиение запроса на подзапросы.
2. Маршрутизацию каждого подзапроса к соответствующему источнику данных.
3. Фиксацию дат публикации и наблюдения.
4. Сохранение единиц измерения и географических определений.
5. Разграничение прогнозных и фактических значений.
6. Возврат URL-адресов или идентификаторов источников.
7. Нормализацию при окончательном выводе без сокрытия противоречий в данных.

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

Как AnySearch маршрутизирует запросы

Основная концепция дизайна заключается в том, что AnySearch перестраивает поисковый конвейер вокруг поведения агентов.

Процесс, показанный в исходном коде, включает пять этапов:

1. Приём запроса
2. Понимание намерений
3. Оркестрация маршрутизации
4. Параллельный поиск
5. Агрегация результатов и передача агенту

1. Понимание намерений

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

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

Это принципиально отличается от подхода, при котором все запросы обрабатываются через один общий индекс.

2. Определение области и маршрутизация источников

AnySearch заявляет, что, помимо общего поиска, поддерживает более 20 вертикальных категорий, охватывающих следующие области:

• Код
• Финансы
• Академические исследования
• Безопасность
• Правовая информация
• Корпоративные и коммерческие данные
• Общий веб-контент

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

3. Параллельный поиск

Вопрос, охватывающий несколько областей, может инициировать несколько независимых поисков. MCP-сервер поддерживает пакетное выполнение от 1 до 5 объектов запроса, причём сбой в одной ветви не блокирует выполнение других.

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

Доказательства.

4. Ранжирование до модели

В исходном тексте предлагаются три идеи ранжирования:

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

Предполагаемая цель — выполнять больше фильтрации до того, как контент попадёт в языковую модель.

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

5. Структурированная доставка

После ранжирования AnySearch извлекает основной контент, удаляет «шум» страницы и преобразует результаты в формат Markdown.

Официальный MCP-сервер также предоставляет операцию извлечения URL, которая возвращает содержимое страницы в формате Markdown с чётким ограничением в 50 000 символов.

Структурированный вывод может уменьшить объём работы, необходимой модели, особенно когда результаты содержат:

• Чёткие заголовки
• Метаданные источника
• Даты
• Отдельные блоки доказательств
• Таблицы
• Код с путями к файлам
• Стандартизированные единицы измерения
• URL-адреса для верификации

Почему дедупликация сокращает потери токенов

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

Это приводит к трем проблемам:

1. Повторяющийся материал занимает место в контексте.
2. Модель может ошибочно принять повторения за независимые подтверждения.
3. Менее популярные, но более авторитетные источники могут быть вытеснены.

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

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

Экономия токенов — это результат конвейера, а не фиксированный процент

В оригинале более низкое потребление токенов описывается как преимущество AnySearch, но не приводится универсальный процент сокращения токенов.

Это логично, поскольку объем экономии зависит от:

• количества исходных результатов
• длины страниц
• степени дублирования
• качества извлечения
• токенизатора модели
• максимального размера контекста
• того, будет ли агент выполнять повторный поиск
• требуемой глубины цитирования
• объема сохраняемых структурированных метаданных

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

Полезные метрики включают:

Метрика	Что измеряет
Входные токены поиска	Контекст, потребляемый извлеченным материалом
Общие токены агента	Поиск, рассуждение, последующие действия,

│ финальная генерация │
│ Количество вызовов поиска за раунд │ Приводит ли слабый поиск к повторным поискам │
│ Количество разных источников │ Разнообразие доказательств после дедупликации │
│ Точность цитирования │ Поддерживает ли цитируемый источник соответствующее утверждение │
│ Полнота ответа │ Покрывает ли ответ все требуемые аспекты │
│ Сквозная задержка │ Время, необходимое для завершения задачи │
│ Успешность выполнения задачи │ Достиг ли агент поставленной цели │

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

Инженерные особенности, ориентированные на агентов

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

Источники ресурсов выделяют следующие особенности:

• Обработка тайм-аутов
• Автоматический откат
• Маршрутизация по нескольким источникам
• API-доступ
• Поддержка MCP
• Поддержка навыков
• Структурированный вывод Markdown

Публичная документация MCP также поддерживает:

• Общий веб-поиск
• Вертикальный поиск
• Параллельный пакетный поиск
• Извлечение полных страниц
• Анонимный доступ
• Опциональная аутентификация по API-ключу

Производственные команды все равно должны добавлять собственные средства контроля:

• Бюджет времени ожидания для каждого источника
• Механизм повторных попыток с экспоненциальной задержкой
• Отслеживание запросов и затрат
• Белые и черные списки источников
• Сканирование на предмет внедрения промптов
• Фильтрация персональных данных и секретов
• Ограничение размера результатов
• Стратегии кэширования
• Журналы аудита
• Ручная проверка для решений с высоким уровнем риска

Результаты поиска — это недоверенный внешний ввод. Даже очищенный текст в формате Markdown может содержать вредоносные инструкции, ложные утверждения или скомпрометированный контент.

Поиск становится инфраструктурой для агентов

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

Это меняет приоритеты проектирования.

Поиск для людей	Поиск для агентов
Оптимизирован для быстрого просмотра	Оптимизирован для машинного потребления
Ссылки и аннотации	Структурированные доказательства
Пользователь сам выполняет дедупликацию	Система должна уменьшать дублирование
Пользователь обращает внимание на даты	Даты должны быть явно указаны
Пользователь решает, кому доверять	Необходимы сигналы источника и качества
Просмотр может быть исследовательским	Повторные поиски потребляют время и токены
Визуальный макет важен	Важны стабильная структура и Markdown

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

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

Как оценить AnySearch в своем рабочем процессе

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

Вместо этого следует создать оценочный набор на основе реальных сценариев.

Задач, которые выполняет ваш агент.

Шаг 1: Определите репрезентативные запросы

Охватите простые и сложные случаи:

• Текущие новости
• Код из репозитория
• Записи местного бизнеса
• Научные статьи
• Регуляторная информация
• Данные из нескольких стран
• Вопросы с конфликтующими источниками
• Запросы, требующие нескольких подтем

Шаг 2: Сохраните модель неизменной

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

Шаг 3: Захватите исходные доказательства

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

Шаг 4: Оценивайте больше, чем просто точность

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

Шаг 5: Вручную проверяйте результаты с высоким уровнем риска

Финансовые, юридические, задачи в области безопасности, медицины и комплаенса требуют экспертной проверки. Поисковый API может улучшить сбор доказательств, но не может взять на себя профессиональную ответственность.

Шаг 6: Тестирование поведения при сбоях

Отключите один из источников, замедлите один из маршрутов, верните контент с неверным форматом, добавьте дублирующиеся результаты. Надёжность в production-среде зависит от того, как система ведёт себя при несовершенном поиске.

Часто задаваемые вопросы

Что такое AnySearch?

AnySearch — это сервис инфраструктуры для поиска в реальном времени, разработанный для AI-агентов и разработчиков. Он предоставляет функции веб-поиска, вертикального поиска, пакетного поиска и полнотекстового извлечения со структурированным выводом.

AnySearch — это потребительский поисковик?

У него есть веб-сайт, где пользователи могут попробовать поиск, но его основное предназначение — это инфраструктура для агентов. Основные способы интеграции включают API, MCP и устанавливаемый Skill.

Работает ли AnySearch без API-ключа?

В официальной документации Skill и MCP указано, что для анонимного доступа действуют ограничения по скорости и квотам. API-ключ необязателен, но рекомендуется для более регулярного использования.

Какие вертикальные области поддерживает AnySearch?

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

Как AnySearch снижает использование токенов?

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

Был ли показатель 76,4% независимо проверен?

Этот показатель был представлен AnySearch и воспроизведён в оригинальной статье. В процессе проверки не был найден полный публичный оценочный пакет, поэтому результат следует рассматривать как сравнительные данные, предоставленные поставщиком.

Может ли AnySearch заменить профессиональную комплексную проверку?

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

Является ли AnySearch open-source?

Репозитории кода для AnySearch Skill и MCP-сервера опубликованы под лицензией Apache-2.0. Хостируемый API-бэкенд является отдельным сервисом и не входит в лицензионное покрытие этих репозиториев.

Связанные инструменты

• AnySearch: Инфраструктура поиска в реальном времени для AI-агентов.
• AnySearch Skill: Устанавливаемый навык агента, поддерживающий веб-поиск, вертикальный поиск, пакетный поиск и поиск по содержимому URL.
• AnySearch MCP Server: Интеграционное решение MCP, предоставляющее инструменты AnySearch совместимым агентам.
• Exa: API для поиска, сбора контента, парсинга и исследований, созданный для AI-приложений.
• Tavily: API для поиска и извлечения данных в реальном времени для рабочих процессов агентов и RAG.
• Brave Search API: Независимый API для веб-поиска, предназначенный для приложений и AI-систем.
• Model Context Protocol: Открытый протокол для подключения AI-приложений к внешним инструментам и данным.

Связанные ссылки

• AnySearch на Product Hunt: Описание продукта, информация о запуске, отзывы сообщества и награды.
• Рейтинг Product Hunt за неделю 6 июля 2026 года: Рейтинг, показывающий AnySearch на первом месте по запускам за эту неделю.
• Руководство по установке AnySearch Skill: Официальные инструкции по настройке, ключам API, каталогу и времени выполнения.
• Документация AnySearch MCP: Официальное описание функций MCP, параметров, аутентификации и определений инструментов.
• Репозиторий FreshQA: Код и данные для оценки вопросов, требующих актуальных знаний о мире.
• Статья FreshLLMs: Исследовательская работа, представляющая FreshQA и оценку с улучшенным поиском.
• Статья WebWalkerQA: Бенчмарк для обхода веб-страниц и поиска доказательств по кросс-сайтовым структурам.

Заключение

AnySearch рассматривает поиск как входной слой для агентов, а не как список страниц для просмотра человеком. Он маршрутизирует запросы по общим и вертикальным источникам, выполняет поиск по нескольким путям, сортирует и дедуплицирует доказательства, удаляет шум со страниц и возвращает структурированный контент через API, MCP или интеграцию со Skill.

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

Его рейтинг на Product Hunt и предоставленные поставщиком результаты бенчмарков делают AnySearch достойным тестирования, но командам следует воспроизвести сравнительные результаты с использованием своих собственных запросов, моделей, учёта токенов и критериев качества, прежде чем заменять существующий поисковый стек.

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