Поиск стал одной из важнейших внешних возможностей для AI-агентов. Мощные модели отлично справляются с рассуждениями, но не могут восстанови...
Поиск стал одной из важнейших внешних возможностей, доступных AI-агентам. Мощные модели способны к хорошим рассуждениям, но не могут восстановить факты, которые никогда не были найдены, отличить текущую информацию от устаревших сообщений на основе доказательств или надежно восстановить отсутствующие записи о компаниях.
AnySearch рассматривает эту проблему как инфраструктуру для агентов, а не как поисковую страницу для пользователей. Вместо того чтобы просто возвращать ссылки, заголовки и краткие выдержки, он направляет запросы к соответствующим веб-источникам или вертикальным источникам, удаляет дубликаты и низкокачественный контент, извлекает полезную информацию и предоставляет структурированные ответы, которые можно напрямую использовать в контексте рассуждений модели.
Продукт занял первое место на Product Hunt как в день, так и в неделю 6 июля 2026 года. В описании релиза подчеркивается, что он предоставляет информацию в реальном времени, отфильтрованную, дедуплицированную и структурированную, через API, MCP-сервер или устанавливаемые навыки агентов.
В этой статье объясняется, чем этот ориентированный на агентов поисковый рабочий процесс отличается от традиционных поисковых API, подробно разбираются примеры, представленные в исходном отчете, и предоставляются практические руководства по установке и оценке.
Примечание по бенчмаркингу: Данные о точности и задержке ниже взяты из сравнительных результатов AnySearch, воспроизведенных в исходной статье. Публичные материалы, рассмотренные в этой версии, не включают полный код оценки, исходные выходные данные, промпты для оценки или статистический анализ. Пожалуйста, рассматривайте эти данные как результаты, представленные поставщиком, а не как независимо воспроизведенный бенчмаркинг.
Люди могут просматривать страницу результатов, игнорировать рекламу, распознавать дублирующиеся статьи и определять, на какие ссылки стоит обратить внимание.
Агенты же часто получают каждый результат как входные данные, что влечет за собой множественные затраты:
Проблема не только в точности поиска, но и в форме и плотности возвращаемой информации.
Поэтому практичная поисковая система для агентов должна ответить на три вопроса, прежде чем передавать информацию модели:
AnySearch спроектирован именно вокруг этих шагов.
AnySearch занял первое место на Product Hunt как в день, так и в неделю 6 июля 2026 года. Product Hunt описывает его как
структурированный поиск в реальном времени, которому доверяют агенты и разработчики, получающий отфильтрованную и дедуплицированную информацию из параллельно опрашиваемых источников.
В исходной статье также представлена система оценки из 300 вопросов, построенная на трех бенчмарках:
В статье отмечается, что 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 в настоящее время поддерживает три основных способа интеграции:
Официальный 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)
Официальный репозиторий рекомендует загружать фиксированную версию (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 /.skills/anysearch
# Общая папка агента
mv anysearch-skill-2.1.0 ~/.agents/skills/anysearch
Точный каталог зависит от платформы агента и её текущих правил обнаружения навыков.
В официальной документации навыка и MCP указано, что анонимный доступ имеет низкие лимиты. API-ключ необязателен, но рекомендуется для более стабильного или высокого объёма использования.
Не помещайте API-ключ в публичный репозиторий. Храните его в переменных окружения, менеджере секретов или игнорируемом локальном конфигурационном файле.
Первый тест в исходной статье требовал от агента найти реальную, ориентированную на производство реализацию API-ограничителя скорости на Go, а не учебное руководство.
Запрос был:
Я создаю проект, мне нужна реализация API-ограничителя скорости на Go. Мне не нужны учебники. Найдите промышленный код из реального проекта с открытым исходным кодом.
Без специального рабочего процесса поиска, как сообщается, агент возвращал типичные ссылки и изолированные фрагменты кода. Такой результат, хотя и мог объяснить концепцию, был малополезен разработчику, которому нужен полный контекст реализации.
Запуск с помощью AnySearch вернул более структурированные, ориентированные на код результаты с более понятными цепочками вызовов и материалами из реальных кодовых баз.
Это различие критически важно, поскольку производственный код — это не только алгоритмы. Полезный результат поиска должен помочь агенту проверить:
Поиск кода, который извлекает красивую функцию, но игнорирует её контекстные допущения, может ввести в заблуждение агента-реализатора.
Независимо от поставщика поиска, более точный запрос может улучшить результаты:
Найти поддерживаемые Go-проекты с открытым исходным кодом, которые реализуют API-ограничение скорости в промышленном коде.
Требования:
- Вернуть репозиторий и точные пути к файлам.
- Предпочитать код, используемый в реальных серверах или шлюзах.
- Включить контекст инициализации и потока запросов.
- Указать алгоритм, бэкенд-хранилище, тесты и лицензию.
- Исключить учебные репозитории и скопированные фрагменты.
- Упомянуть даты недавних релевантных коммитов.
Поисковая система должна предоставлять доказательства. Агент-кодер должен всё равно проверить репозиторий, лицензию, тесты, предположения о безопасности и текущее состояние обслуживания перед адаптацией кода.
Второй тест
сравнил AnySearch и Exa в задаче исследования одной и той же компании.
Оба отчёта показали хорошие результаты по базовой публичной информации о компании. Различия в основном касались раздела рисков.
Сообщается, что AnySearch нашёл локально опубликованные записи о соблюдении нормативных требований и объявления на платформах, которые отсутствовали в отчёте, сгенерированном Exa. Источник объяснил это различие доступом к китайским вертикальным источникам данных, а не самой языковой моделью.
Этот пример подчёркивает общее ограничение в исследовании компаний: глобальный веб-индекс может хорошо охватывать официальные сайты организаций, международные новости и англоязычные базы данных, но может упускать местные нормативные, судебные, жалобные или платформенные записи.
Агент due diligence должен явно искать по нескольким категориям:
Важно: Due diligence с помощью поиска не заменяет профессиональную юридическую, финансовую или комплаенс-проверку. Записи могут быть неполными, названия — запутанными, а автоматические сводки — неверно интерпретировать доказательства.
Третий тест потребовал от 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)
Это типичный пример многопрофильного запроса, требующий от системы распознать, что в одном запросе содержится несколько независимых путей к данным, а не один обычный веб-поиск.
Надёжная реализация должна обеспечивать следующее:
Текущие данные всегда должны содержать временную метку. Если в отчёте не указано время публикации базовых измерений и их период охвата, то слово "последний" теряет всякий смысл.
Основная концепция дизайна заключается в том, что AnySearch перестраивает поисковый конвейер вокруг поведения агентов.
Процесс, показанный в исходном коде, включает пять этапов:
Система сначала определяет, какой тип доказательств требуется для запроса.
Запросы о корпоративной информации могут потребовать регистрационных записей, патентов, юридических баз данных и платформ жалоб. Вопросы, связанные с кодом, следует направлять в репозитории кода и документацию. Запросы об энергетическом рынке могут потребовать официальных данных о запасах и электроэнергии.
Опишите идею одной фразой, и We0 AI создаст сайт-витрину, страницы и CMS, а после запуска поможет привлечь клиентов и трафик.
Одна полная генерация проекта для бесплатной регистрации
Лучше всего попробовать один полный поток генерации и быстро увидеть первый черновик проекта.
Это принципиально отличается от подхода, при котором все запросы обрабатываются через один общий индекс.
AnySearch заявляет, что, помимо общего поиска, поддерживает более 20 вертикальных категорий, охватывающих следующие области:
Публичный интерфейс MCP включает метод каталога областей. Агент должен запрашивать допустимые области и схемы параметров, а не создавать неподдерживаемые фильтры самостоятельно.
Вопрос, охватывающий несколько областей, может инициировать несколько независимых поисков. MCP-сервер поддерживает пакетное выполнение от 1 до 5 объектов запроса, причём сбой в одной ветви не блокирует выполнение других.
Параллельный поиск сокращает общее время ожидания, но только при условии, что уровень агрегации может предотвратить ситуацию, когда быстро появляющиеся низкокачественные результаты вытесняют более медленные, но авторитетные результаты.
Доказательства.
В исходном тексте предлагаются три идеи ранжирования:
Предполагаемая цель — выполнять больше фильтрации до того, как контент попадёт в языковую модель.
Это отличается от конвейеров, которые возвращают большой набор результатов и позволяют модели самой выполнять дедупликацию. Предварительная фильтрация может сэкономить токены, но вводит дополнительную ответственность: система ранжирования не должна молча удалять записи из редких источников или ключевые противоречивые данные.
После ранжирования AnySearch извлекает основной контент, удаляет «шум» страницы и преобразует результаты в формат Markdown.
Официальный MCP-сервер также предоставляет операцию извлечения URL, которая возвращает содержимое страницы в формате Markdown с чётким ограничением в 50 000 символов.
Структурированный вывод может уменьшить объём работы, необходимой модели, особенно когда результаты содержат:
Почему дедупликация сокращает потери токенов
Предположим, агент получил десять результатов по одному и тому же событию. Если семь из них — это пересказ одного и того же исходного отчета, то контекст содержит повторяющиеся утверждения, а не семь независимых подтверждений.
Это приводит к трем проблемам:
Дедупликация на основе источника направлена на сохранение уникальных доказательств, а не просто на сохранение страниц с самым высоким рейтингом.
Практичный ответ агента при поиске должен делать информацию об источниках видимой. Разработчикам нужно знать, представляют ли пять результатов пять оригинальных источников, совместную публикацию одного и того же источника или смесь первичных и вторичных доказательств.
В оригинале более низкое потребление токенов описывается как преимущество AnySearch, но не приводится универсальный процент сокращения токенов.
Это логично, поскольку объем экономии зависит от:
Справедливая оценка должна измерять всю задачу, а не только первый поисковый ответ.
Полезные метрики включают:
| Метрика | Что измеряет |
|---|---|
| Входные токены поиска | Контекст, потребляемый извлеченным материалом |
| Общие токены агента | Поиск, рассуждение, последующие действия, |
│ финальная генерация │
│ Количество вызовов поиска за раунд │ Приводит ли слабый поиск к повторным поискам │
│ Количество разных источников │ Разнообразие доказательств после дедупликации │
│ Точность цитирования │ Поддерживает ли цитируемый источник соответствующее утверждение │
│ Полнота ответа │ Покрывает ли ответ все требуемые аспекты │
│ Сквозная задержка │ Время, необходимое для завершения задачи │
│ Успешность выполнения задачи │ Достиг ли агент поставленной цели │
Краткий ответ, в котором опущены ключевые доказательства, не является стратегией оптимизации. Сокращение количества токенов имеет ценность только при сохранении качества и прослеживаемости ответа.
Компоненты поиска, используемые в реальных производственных средах, должны обрабатывать проблемы, которые редко возникают в демонстрациях продуктов.
Источники ресурсов выделяют следующие особенности:
Публичная документация MCP также поддерживает:
Производственные команды все равно должны добавлять собственные средства контроля:
Результаты поиска — это недоверенный внешний ввод. Даже очищенный текст в формате Markdown может содержать вредоносные инструкции, ложные утверждения или скомпрометированный контент.
Традиционный поиск помогает пользователям находить страницы. Поиск для агентов имеет другую цель: предоставлять машиночитаемые доказательства для рассуждений и выполнения действий.
Это меняет приоритеты проектирования.
| Поиск для людей | Поиск для агентов |
|---|---|
| Оптимизирован для быстрого просмотра | Оптимизирован для машинного потребления |
| Ссылки и аннотации | Структурированные доказательства |
| Пользователь сам выполняет дедупликацию | Система должна уменьшать дублирование |
| Пользователь обращает внимание на даты | Даты должны быть явно указаны |
| Пользователь решает, кому доверять | Необходимы сигналы источника и качества |
| Просмотр может быть исследовательским | Повторные поиски потребляют время и токены |
| Визуальный макет важен | Важны стабильная структура и Markdown |
Модель определяет способность агента использовать доказательства для рассуждений. Уровень поиска определяет, какие доказательства изначально доступны.
По мере улучшения моделей важность качества поиска только возрастает. Мощные модели могут генерировать очень убедительные ответы даже на основе слабого контекста. Это делает выбор источников, их актуальность и прослеживаемость частью системы безопасности и надежности агента.
Разработчикам не следует выбирать провайдера поиска, основываясь только на одном публичном бенчмарке или впечатляющем демо-примере.
Вместо этого следует создать оценочный набор на основе реальных сценариев.
Задач, которые выполняет ваш агент.
Охватите простые и сложные случаи:
Используйте одну и ту же модель, промпт, инструментальную стратегию и формат вывода для каждого провайдера.
Сохраните возвращенные источники до того, как модель выполнит обобщение. В противном случае вы не сможете определить, связана ли ошибка с процессом поиска или рассуждения.
Измеряйте задержку, общее количество токенов, количество повторных вызовов поиска, охват, подтверждение цитирования, актуальность и частоту отказов.
Финансовые, юридические, задачи в области безопасности, медицины и комплаенса требуют экспертной проверки. Поисковый API может улучшить сбор доказательств, но не может взять на себя профессиональную ответственность.
Отключите один из источников, замедлите один из маршрутов, верните контент с неверным форматом, добавьте дублирующиеся результаты. Надёжность в production-среде зависит от того, как система ведёт себя при несовершенном поиске.
AnySearch — это сервис инфраструктуры для поиска в реальном времени, разработанный для AI-агентов и разработчиков. Он предоставляет функции веб-поиска, вертикального поиска, пакетного поиска и полнотекстового извлечения со структурированным выводом.
У него есть веб-сайт, где пользователи могут попробовать поиск, но его основное предназначение — это инфраструктура для агентов. Основные способы интеграции включают API, MCP и устанавливаемый Skill.
В официальной документации Skill и MCP указано, что для анонимного доступа действуют ограничения по скорости и квотам. API-ключ необязателен, но рекомендуется для более регулярного использования.
В публичной документации упоминаются финансы, академические исследования, безопасность, юридическая информация, код и другие категории. Перед использованием специфических для домена параметров агент должен запросить каталог поддерживаемых областей.
Он пытается маршрутизировать запросы до поиска, уменьшает количество дублирующихся источников, отдаёт приоритет результатам с высокой информационной плотностью, удаляет шум со страниц и возвращает структурированный Markdown. Фактическая экономия токенов зависит от содержания запроса и более широкого рабочего процесса агента.
Этот показатель был представлен AnySearch и воспроизведён в оригинальной статье. В процессе проверки не был найден полный публичный оценочный пакет, поэтому результат следует рассматривать как сравнительные данные, предоставленные поставщиком.
Нет. Он может помочь собрать корпоративную, юридическую, финансовую информацию и информацию о публичных рисках, но специалисты должны проверять личность, авторитетность источников, полноту, юрисдикцию и интерпретацию.
Репозитории кода для AnySearch Skill и MCP-сервера опубликованы под лицензией Apache-2.0. Хостируемый API-бэкенд является отдельным сервисом и не входит в лицензионное покрытие этих репозиториев.
AnySearch рассматривает поиск как входной слой для агентов, а не как список страниц для просмотра человеком. Он маршрутизирует запросы по общим и вертикальным источникам, выполняет поиск по нескольким путям, сортирует и дедуплицирует доказательства, удаляет шум со страниц и возвращает структурированный контент через API, MCP или интеграцию со Skill.
Примеры из исходного кода демонстрируют, почему такой дизайн критически важен для обнаружения рабочего кода, комплексной проверки местных компаний и данных по нескольким рынкам. В каждом случае агенту требуются полные, своевременные и отслеживаемые доказательства, а не просто релевантные ссылки.
Его рейтинг на Product Hunt и предоставленные поставщиком результаты бенчмарков делают AnySearch достойным тестирования, но командам следует воспроизвести сравнительные результаты с использованием своих собственных запросов, моделей, учёта токенов и критериев качества, прежде чем заменять существующий поисковый стек.
В рабочем процессе агента модель решает, как обрабатывать доказательства; а слой поиска определяет, дойдут ли правильные доказательства до модели.
Начните с одной фразы и получите полноценный сайт за считанные минуты.
