Multi-provider search (Brave, Perplexity) by nikmd1306 · Pull Request #177 · vamplabAI/sgr-agent-core

nikmd1306 · 2026-02-17T17:45:31Z

Adds Brave and Perplexity as standalone search providers alongside existing Tavily

BaseSearchService — abstract base with factory method and provider routing by engine config
BraveSearchService / PerplexitySearchService — concrete implementations with httpx.AsyncClient
_BaseSearchTool — shared base for all search tools (fields, __call__ logic, __init_subclass__ auto-registration)
BraveSearchTool / TavilySearchTool / PerplexitySearchTool — standalone tools that force their engine
WebSearchTool uses engine from config (default: tavily)
Per-tool config in config.yaml (API keys, base URLs per provider)
Tests: 14 service tests + 9 new tool tests (factory, conversion, async calls, engine forcing)

Closes #176

…ce, Brave and Perplexity Add BaseSearchService base class with factory pattern routing by engine config. Add BraveSearchService (httpx, native offset) and PerplexitySearchService (httpx, over-fetch+slice). Extend SearchConfig with engine, brave_*, perplexity_* fields. Refactor TavilySearchService to inherit BaseSearchService.

… with shared BaseSearchTool base Add _BaseSearchTool base class with shared fields and __call__ logic Refactor WebSearchTool to inherit from _BaseSearchTool Add TavilySearchTool, BraveSearchTool, PerplexitySearchTool standalone tools Fix description ClassVar inheritance in __init_subclass__ Add Tavily key guard to ExtractPageContentTool Update exports and config examples with multi-provider settings

…ti-provider support Add test_search_services.py with factory, conversion and missing API key tests Update test_tools.py: patch BaseSearchService instead of TavilySearchService, add init/execution tests for BraveSearchTool, PerplexitySearchTool, TavilySearchTool

…Service and adjust tool exports for consistency

…offset handling

EvilFreelancer · 2026-02-18T20:06:22Z

sgr_agent_core/base_tool.py

    def __init_subclass__(cls, **kwargs) -> None:
        super().__init_subclass__(**kwargs)
-        if cls.__name__ not in ("BaseTool", "MCPBaseTool"):
+        if cls.__name__ not in ("BaseTool", "MCPBaseTool", "_BaseSearchTool"):


Думаю _BaseSearchTool тут лишне, потому что _BaseSearchTool и так наследует BaseTool.

_BaseSearchTool тут нужен - без него он зарегается в ToolRegistry как полноценный тул с именем _basesearchtool а это абстрактный базовый класс, его нельзя вызвать

сам подход с хардкодом имён конечно так себе, в идеале заменить на маркер типа _abstract = True, но это уже отдельная задача

sgr_agent_core/agent_definition.py

config.yaml.example

sgr_agent_core/tools/extract_page_content_tool.py

EvilFreelancer

В целом очень хорошо, плюс пару предложений по допилке фичей.

sgr_agent_core/services/base_search.py

…ider logic into tools with unified registry and tests

…rch-providers # Conflicts: # sgr_agent_core/base_tool.py

sgr_agent_core/tools/base_search_tool.py

virrius · 2026-02-19T13:01:50Z

sgr_agent_core/tools/base_search_tool.py

+        provider_cls = _search_registry.get(search_config.engine)
+        if provider_cls is None:
+            raise ValueError(f"Unsupported search engine: {search_config.engine}")


Не понятен этот момент:

Мы делаем выбор провайдера в base search tool, хотя их конкретная логика есть в дочерних тулах.

Какая именно тула предполагается к использованию пользователями фреймворка?

Если _BaseЫуфксрTool - внутренняя абстракция, то зачем тут эта логика?

выбор провайдера в базе потому что все 4 тула шарят один и тот же флоу в call: config merging, выбор провайдера, вызов _search(), форматирование, обновление context. если вынести эту логику в WebSearchTool то придется либо дублировать весь call, либо городить промежуточный метод-прокси типа _do_search в каждом туле

по вопросам:

пользователи используют WebSearchTool, это основной инструмент, движок выбирается через SearchConfig.engine. standalone тулы (tavily, brave, perplexity) это альтернатива когда нужно чтобы LLM сам выбирал конкретный движок

_BaseSearchTool внутренняя абстракция (поэтому _ префикс, исключен из ToolRegistry), но выбор провайдера это часть общего флоу который все тулы наследуют. по сути template method, база задает скелет, конкретные тулы реализуют _search()

sgr_agent_core/tools/extract_page_content_tool.py

sgr_agent_core/agent_definition.py

sgr_agent_core/tools/base_search_tool.py

sgr_agent_core/tools/brave_search_tool.py

sgr_agent_core/tools/extract_page_content_tool.py

sgr_agent_core/tools/perplexity_search_tool.py

sgr_agent_core/tools/tavily_search_tool.py

MiXaiLL76 · 2026-02-19T14:28:17Z

sgr_agent_core/tools/web_search_tool.py

-
-
-class WebSearchTool(BaseTool):
+class WebSearchTool(_BaseSearchTool):


Как я понимаю, эт теперь legacy. Надо подписать что это именно оно. Возможно повесить депрекейтед тег.
В том числе в docstring.

не, WebSearchTool не legacy. это основной тул для пользователей, все примеры в examples/ и agents.yaml.example используют именно web_search_tool. standalone тулы (tavily, brave, perplexity) нигде в примерах не фигурируют

смысл WebSearchTool в том что он не форсит конкретный движок, а берет engine из конфига. пользователь может переключить провайдера одной строкой в config.yaml без изменения агента. standalone тулы это альтернатива для кейса когда нужно чтобы LLM сам выбирал между движками

что он пустой это не баг, а результат рефакторинга, вся общая логика в _BaseSearchTool. но согласен что это неочевидно, добавлю пояснение в докстринг

sgr_agent_core/agent_definition.py

MiXaiLL76 · 2026-02-19T14:30:56Z

config.yaml.example

  web_search_tool:
+    engine: "tavily"  # Search engine: "tavily" (default), "brave", or "perplexity"
    tavily_api_key: "your-tavily-api-key-here"  # Tavily API key (get at tavily.com)
    tavily_api_base_url: "https://api.tavily.com"  # Tavily API URL
    max_results: 12
    max_searches: 6
  extract_page_content_tool:
-    tavily_api_key: "your-tavily-api-key-here"  # Same Tavily API key
+    tavily_api_key: "your-tavily-api-key-here"  # Same Tavily API key (Tavily-only feature)
    tavily_api_base_url: "https://api.tavily.com"
    content_limit: 2000
+  # Standalone search tools (for multi-engine setups where LLM picks the engine)
+  brave_search_tool:
+    brave_api_key: "your-brave-api-key-here"  # Brave Search API key
+    brave_api_base_url: "https://api.search.brave.com/res/v1/web/search"
+  perplexity_search_tool:
+    perplexity_api_key: "your-perplexity-api-key-here"  # Perplexity API key
+    perplexity_api_base_url: "https://api.perplexity.ai/search"
+  tavily_search_tool:
+    tavily_api_key: "your-tavily-api-key-here"
+    tavily_api_base_url: "https://api.tavily.com"


Описать бы более детальное разделение тулов. Зачем столько много в примере.
Мы уверены, что прям так надо показывать пользователю?

тут паттерн проекта такой что целые опциональные секции (prompts, proxy, доп mcp серверы) комментируются, а тулы с конфигами всегда раскомментированы. пользователь просто не добавляет ненужный тул в agent tools список. standalone тулы следуют этому же паттерну, плюс комментарий-разделитель уже есть на строке 72

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

как по твоему лучше оформить - закоментировать блоки или оставить с более подробным описанием?

…y for search tools to centralize and standardize search provider registration and lookup

…avily_search_tool to improve separation of concerns and update tests accordingly

…r and add section comments for clarity

…tion and usage options

virrius · 2026-03-13T12:21:11Z

Чтобы подбить клинья:

Лучше оставить одну тулу с разными движками. 4 тула мне кажется немного сложновато
Логика движков может быть в виде функций в этом же файле рядышком или в сервисах
Конфиг тулы так же предлагаю добавить в файл тула(чтобы давать более правильный референс для добавления юзером тулы, где всё относящееся в одном месте, не изменяя глобал конфиг)
Из конфига можно убрать разные url под движки и оставить три параметра: engine, api_key, api_base_url
Думаю регистри здесь лишнее (хотя и не точно. можно и с ним в целом то). Как варик, тула тупым образом достаёт нужный обработчик движка (банальный маппинг {str: Callable} из первого пункта)
конфиг упростится до описания одной тулы с выбором движка

Идеи:

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

nikmd1306 added 5 commits February 17, 2026 17:27

refactor(exports): reorder and update exports to include TavilySearch…

2844f2f

…Service and adjust tool exports for consistency

docs(tavily_search): add class docstring explaining usage, auth, and …

1c53809

…offset handling

nikmd1306 requested review from EvilFreelancer and virrius February 17, 2026 17:45

nikmd1306 self-assigned this Feb 17, 2026

EvilFreelancer reviewed Feb 18, 2026

View reviewed changes

sgr_agent_core/agent_definition.py Show resolved Hide resolved

EvilFreelancer reviewed Feb 18, 2026

View reviewed changes

config.yaml.example Show resolved Hide resolved

EvilFreelancer reviewed Feb 18, 2026

View reviewed changes

sgr_agent_core/tools/extract_page_content_tool.py Show resolved Hide resolved

EvilFreelancer requested changes Feb 18, 2026

View reviewed changes

EvilFreelancer reviewed Feb 18, 2026

View reviewed changes

sgr_agent_core/services/base_search.py Outdated Show resolved Hide resolved

refactor(search): remove deprecated BaseSearchService and inline prov…

c83dec6

…ider logic into tools with unified registry and tests

EvilFreelancer previously approved these changes Feb 19, 2026

View reviewed changes

Merge remote-tracking branch 'origin/main' into 176-different-web-sea…

7146546

…rch-providers # Conflicts: # sgr_agent_core/base_tool.py

nikmd1306 dismissed EvilFreelancer’s stale review via 7146546 February 19, 2026 12:08

EvilFreelancer previously approved these changes Feb 19, 2026

View reviewed changes

virrius reviewed Feb 19, 2026

View reviewed changes

MiXaiLL76 reviewed Feb 19, 2026

View reviewed changes

nikmd1306 added 4 commits February 20, 2026 15:37

refactor(search): replace _search_registry with SearchProviderRegistr…

6c89cdb

…y for search tools to centralize and standardize search provider registration and lookup

refactor(extract_page_content_tool): move Tavily extract logic from t…

3dc9da1

…avily_search_tool to improve separation of concerns and update tests accordingly

refactor(agent_definition): reorganize SearchConfig fields by provide…

968239c

…r and add section comments for clarity

docs(web_search_tool): expand class docstring to clarify engine selec…

c262eaf

…tion and usage options

nikmd1306 dismissed EvilFreelancer’s stale review via c262eaf February 20, 2026 15:38



		class WebSearchTool(BaseTool):
		class WebSearchTool(_BaseSearchTool):

Conversation

nikmd1306 commented Feb 17, 2026

Uh oh!

EvilFreelancer Feb 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nikmd1306 Feb 19, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

EvilFreelancer left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

virrius Feb 19, 2026

Choose a reason for hiding this comment

Uh oh!

nikmd1306 Feb 20, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

MiXaiLL76 Feb 19, 2026

Choose a reason for hiding this comment

Uh oh!

nikmd1306 Feb 20, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

MiXaiLL76 Feb 19, 2026

Choose a reason for hiding this comment

Uh oh!

nikmd1306 Feb 20, 2026

Choose a reason for hiding this comment

Uh oh!

virrius commented Mar 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

EvilFreelancer Feb 18, 2026 •

edited

Loading

virrius commented Mar 13, 2026 •

edited

Loading