Агентный поиск

Агентный поиск - это поиск, выполняемый агентом, который сам решает, искать ли вообще, какой запрос составить, достаточно ли хороши результаты и нужно ли повторить поиск, причём по нескольким источникам контекста, у каждого из которых есть свой нативный инструмент поиска. Это промежуточный и текущий этап трёхшаговой эволюции, описанной Леони Монигатти в agentic-search-context-engineering.

Исходной точкой был RAG с фиксированным пайплайном (см. rag-limitations): взять сообщение пользователя, выполнить один векторный поиск, прикрепить фрагменты к промпту, сгенерировать ответ. Это работает для узких Q&A-задач и ломается тремя предсказуемыми способами, и всё потому, что извлечение данных происходит строго один раз: поиск запускается, даже когда он не нужен; плохой запрос нельзя скорректировать вторым проходом; невозможен multi-hop, когда первые результаты лишь подсказывают, что искать дальше. Агентный RAG исправляет это, превращая извлечение в инструмент, который агент может вызвать, перезапустить или переписать. Контекстная инженерия обобщает этот подход: теперь агент обращается ко множеству источников - локальным файлам и черновикам, базам данных, вебу, долговременной памяти, - и у каждого из них есть нативный поисковый инструмент (поиск по файлам, загрузка skill'ов, инструменты запросов к БД, веб-поиск, инструменты работы с памятью).

Один инструмент охватывает большинство этих источников: shell tool (название в LangChain; Anthropic называет его bash tool, OpenClaw - exec tool). Поскольку очень многое доступно через CLI - grep и ls для файлов, консольные клиенты баз данных и curl для сервисов и веба, - один инструмент с семантикой "выполни эту команду" закрывает массу задач. Именно поэтому постоянно звучат предложения вроде "Bash + файловая система - всё, что вам нужно". Но у него есть реальное ограничение: семантический поиск. Получив концептуальный вопрос по текстовым файлам, агент начнёт "хитрить", цепочкой запуская grep по синонимам (regulat, затем compliance, constraints, GDPR, governance), пока что-нибудь не найдётся. Это срабатывает удивительно часто, но не масштабируется на открытый поиск по смыслу: на запрос "фильмы о супергероях-животных" ему пришлось бы перечислять всех животных. Чтобы закрыть этот пробел, существуют CLI для семантического grep: semtools от LlamaIndex, colgrep от LightOn, jina-grep-cli от Jina AI (grep-совместимые флаги плюс косинусный --threshold и --top-k).

Поэтому архитектурный вопрос заключается не в выборе между shell tool и всем остальным. Вопрос в том, какие поисковые инструменты нужны вашему стеку с учётом требований к задержкам и качеству: универсальный инструмент запросов справляется со сложными неоднозначными вопросами, но обходится дороже и требует более сильной модели, тогда как узкий семантический инструмент дешёв, но спотыкается на точных совпадениях по ключевым словам. Это часть более широкой проблемы context-engineering, а баланс между загрузкой мощных универсальных инструментов и дешёвых специализированных связан с темами mcp-vs-skills и hybrid-search.

Что касается конкретно работы с вебом, на странице terminal-search-clients сравниваются CLI-варианты, которые агент может вызывать через shell, по решающим параметрам: возвращаются ли результаты в JSON или интерактивном пейджере, чего стоит аутентификация и поддерживается ли проект.