Skip to content

feat(tools): add Bocha web search provider#874

Open
shikihane wants to merge 2 commits intosipeed:mainfrom
shikihane:feat/bocha-search
Open

feat(tools): add Bocha web search provider#874
shikihane wants to merge 2 commits intosipeed:mainfrom
shikihane:feat/bocha-search

Conversation

@shikihane
Copy link

Description

Add Bocha AI as a new web search provider, appended at the lowest priority in the search provider chain.

Changes:

  • Config: Add BochaConfig struct and Bocha field in WebToolsConfig
  • Web tools: Implement BochaSearchProvider using the Bocha AI web search API (api.bochaai.com/v1/web-search), supporting configurable API key, base URL, and max results
  • Agent loop: Wire Bocha config fields into WebSearchToolOptions

Provider priority remains: Perplexity > Brave > Tavily > DuckDuckGo > Bocha

Type of Change

  • New feature (non-breaking change which adds functionality)

AI Code Generation

  • Mostly AI-generated code with human review and testing

Technical Context

Bocha AI provides a Bing-compatible web search API with optional summary generation. The implementation follows the existing SearchProvider interface pattern. Response format: data.webPages.value[] with name, url, snippet, summary fields. Summaries are preferred over snippets when available, truncated at 500 chars.

Test Environment

  • Radxa Cubie A7A (arm64), Debian 11
  • Verified Bocha API with curl and live queries
  • Build and all tests pass

Checklist

  • My code follows the style guidelines of this project
  • I have performed a self-review of my code
  • New and existing tests pass locally with my changes
  • Any dependent changes have been already merged and published

🤖 Generated with Claude Code

Add BochaSearchProvider implementing the SearchProvider interface,
using the Bocha AI web search API (api.bochaai.com). Appended at the
end of the provider priority chain (lowest priority) with
configurable API key, base URL, and max results.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Copy link

@nikolasdehor nikolasdehor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clean implementation that follows the existing SearchProvider pattern well. Priority placement (lowest, below DuckDuckGo) makes sense. A few suggestions: (1) Unbounded response read: io.ReadAll(resp.Body) has no size limit. Consider io.LimitReader(resp.Body, 110241024) to prevent OOM from malformed responses (PR #883 addresses the same pattern in WebFetch). (2) HTTP client per-request: createHTTPClient is called on every Search() invocation, creating a new client and transport each time. Consider creating it once in the constructor for HTTP connection reuse. (3) Tests: Even a basic test with a mock HTTP server would be valuable. LGTM.

- Cap response body read at 1MB via io.LimitReader to prevent OOM
- Reuse HTTP client across searches instead of creating per request
- Add mock HTTP server tests for success and error paths

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants