Agentic search для context engineering

Статья Леони Монигатти (отредактированная версия её воркшопа на AI Engineer Europe 2026) выдвигает один тезис и затем раскрывает его в коде: context engineering - выбор того, что из всех возможных источников попадёт в контекстное окно агента, - примерно на 80% состоит из agentic search. То, что кажется единым шагом "отбора контекста", на самом деле представляет собой набор поисковых инструментов, которые агент решает вызвать. Вопрос архитектуры в том, какие именно инструменты нужны в вашем стеке с учётом требований к задержке и качеству, а не в дилемме "shell tool против всего остального". Об авторе см. leonie-monigatti-blog, о концепции - agentic-search.

Три эпохи

Поиск в стеке ИИ прошёл три этапа за три года. RAG с фиксированным пайплайном (2024) берёт сообщение пользователя, выполняет один векторный поиск, прикрепляет найденные фрагменты к промпту и генерирует ответ. Это работает для узких сценариев "вопрос-ответ", но ломается тремя предсказуемыми способами из-за единственного обращения к поиску: поиск запускается, когда он не нужен, и лишний мусор сбивает модель с толку; невозможно перезапустить неудачный запрос; не поддерживается multi-hop, когда первые результаты лишь подсказывают, что искать дальше. Agentic RAG заменяет фиксированный пайплайн поисковым инструментом, который агент может вызывать по своему усмотрению, оценивать результаты, перезапускать или переформулировать запрос. Context engineering обобщает этот подход на множество источников одновременно - локальные файлы и scratchpad'ы, базы данных, веб, долговременную память, - где для каждого есть свой специализированный инструмент поиска (поиск по файлам, загрузка навыков, инструменты запросов к БД, веб-поиск, инструменты работы с памятью). См. rag-limitations, context-engineering.

Shell tool

Все эти источники пересекает shell tool (название в LangChain; bash tool у Anthropic, exec tool в OpenClaw): один универсальный инструмент "запустить команду", дающий доступ к файлам (grep, ls), базам данных (утилиты CLI, вызовы HTTPS API через curl) и вебу (curl). Из-за такой широты возможностей тезис "Bash + файловая система - всё, что вам нужно" всплывает регулярно. В другой статье для Elastic Монигатти доказывает, что это не серебряная пуля: суть не в выборе между shell и всем остальным, а в грамотной сборке стека.

Три демо

В демо используется LangChain поверх расписания конференции, разбитого по одному документу на доклад.

Демо 1 - единственный инструмент семантического поиска поверх Elasticsearch (gpt-5.4-nano, jina-embeddings-v5). Концептуальные запросы работают ("какие доклады посвящены регуляторным ограничениям?" находит нужный доклад). Запросы по точным ключевым словам ломаются: "какие доклады посвящены GEPA?" возвращает нерелевантные результаты, поскольку эмбеддинг путает "GEPA" с "Gemma". На этом большинство демонстраций agentic search и заканчивается.

Демо 2 - замена на универсальный инструмент execute_esql_query, позволяющий агенту писать полноценные запросы на ES|QL, и переход на gpt-5.4-mini, так как генерация запросов сложнее простой передачи темы. Сначала агент ошибается, подставляя SQL-шаблоны % (WHERE text LIKE '%GEPA%') вместо *, принятого в ES|QL, и получает ноль строк. Решением становится Agent Skill: минимальный навык elasticsearch-esql, загружаемый через инструмент load_skill в LangChain и SkillMiddleware, вместе с системным промптом, предписывающим загрузить навык перед запросом и перегенерировать его при ошибке. После этого агент пишет корректный ES|QL (LIKE "*GEPA*") и находит нужный доклад. Будучи универсальным, инструмент справляется и с аналитическими вопросами - например, "сколько докладов пройдёт 8 апреля?" через STATS COUNT() (результат: 27), что ценно, так как LLM плохо умеют считать. Плата за это: больше возможностей для неоднозначных запросов, но загрузка навыков увеличивает задержку и расходы на токены, а также требует более сильной модели. Сравните с mcp-vs-skills.

Демо 3 - shell tool поверх отдельных .txt-файлов для каждого доклада ("Bash + файловая система - всё, что вам нужно"), где агент использует ls/grep/cat. Grep идеально справляется с точными совпадениями. На семантическом запросе агент "хитрит": запускает grep по корню regulat, затем перебирает синонимы (compliance, constraints, GDPR, governance), пока что-то не сработает. Это работает удивительно хорошо, но не масштабируется: на запрос "фильмы про супергероев-животных" агенту пришлось бы перечислять всех животных. Отсюда появление CLI для семантического grep'а: semtools от LlamaIndex, colgrep от LightOn, jina-grep-cli от Jina AI (совместимые с grep флаги -r/-R/-l плюс косинусный порог --threshold со значением по умолчанию 0.5 и --top-k по умолчанию 10). Получив в промпте правило выбора между grep и jina-grep, агент гораздо эффективнее находит совпадения по косинусному расстоянию для запроса об ограничениях.

Выводы

Универсальные инструменты справляются со сложными запросами, но обходятся дороже и требуют более сильных моделей; специализированные инструменты дёшевы, но хрупки на запросах, под которые они не заточены. Описания инструментов берут на себя реальную работу - агент выбирает инструменты на их основе. Изолируйте shell tool в песочнице (по умолчанию у него нет встроенных ограничений). И заранее определите, как трактовать пустой ответ: как признак того, что ничего не найдено, или как сигнал для повторной попытки с другими параметрами. См. также hybrid-search.

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

• agentic-search - концепция: поиск по нескольким источникам под управлением агента и ограничения shell tool
• context-engineering - общий контекст темы; тезис Монигатти про ~80% вынесен туда
• rag-limitations - ограничения фиксированных пайплайнов, подтолкнувшие этот переход
• mcp-vs-skills - паттерн "универсальный инструмент плюс навык" из Демо 2
• hybrid-search - объединение поиска по ключевым словам и семантического поиска, пробел в Демо 1 и 3
• leonie-monigatti-blog - автор материала