Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Feature: add Baidu as a web_search provider for stronger zh-CN retrieval [1 pull requests, 5 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#56304•Fetched 2026-04-08 01:42:29
View on GitHub
Comments
5
Participants
2
Timeline
6
Reactions
0
Author
jimmyzhuujimmyzhuu
Participants
AliorpseAliorpsejimmyzhuujimmyzhuu
Timeline (top)
commented ×5cross-referenced ×1

Add Baidu as an optional web_search provider to improve zh-CN retrieval quality in OpenClaw.

To keep the change small, the proposed implementation would register baidu via the existing bundled qianfan plugin and expose only the minimum config needed for web search.

Root Cause

For zh-CN workflows, Baidu is a meaningful addition because it is not just another API surface. It adds access to a search backend that is especially strong on the mainland Chinese web ecosystem, including local portals, services, news, documentation, and Chinese-language sites where localized recall matters.

PR fix notes

PR #56316: web_search: add optional Baidu provider via qianfan

Description (problem / solution / changelog)

Summary

This PR adds a bundled baidu web_search provider via the existing qianfan plugin.

It supports two modes:

  • direct: structured search results
  • smart: AI-synthesized answer with citations

Refs #56304

Motivation

This is intended to improve zh-CN retrieval coverage by adding a Chinese-first search backend with strong mainland Chinese web coverage, while keeping the implementation small and maintainer-friendly.

Why Baidu:

  • Baidu remains the largest search backend in China
  • it covers a distinct Chinese-local content ecosystem
  • Qianfan already exposes both direct search and AI search generation APIs
  • those two API shapes map cleanly onto OpenClaw's existing web_search output patterns

Scope

Included in this PR:

  • add bundled baidu web-search provider ownership under qianfan
  • add minimal Qianfan-owned web search config:
    • plugins.entries.qianfan.config.webSearch.apiKey
    • plugins.entries.qianfan.config.webSearch.mode
    • plugins.entries.qianfan.config.webSearch.model
  • support QIANFAN_API_KEY as env fallback
  • normalize direct responses into structured results[]
  • normalize smart responses into content + citations
  • add targeted tests, contract tests, metadata sync, and docs

Not included:

  • fallback / provider rotation
  • provider ranking redesign
  • query rewriting
  • plugin architecture refactors
  • unrelated UI or infra changes

Implementation Notes

  • provider id: baidu
  • plugin owner: qianfan
  • default mode: direct
  • smart mode default model: ernie-4.5-turbo-32k
  • auto-detect order: 55
  • shared QIANFAN_API_KEY web-search auto-detect behavior is intentional and follows the existing shared-key pattern already used by Gemini for LLM + web search

Follow-up

After initial review, I pushed 6a145ae488 to keep the PR narrowly scoped while addressing the remaining docs / contract sync gaps:

  • synced the SecretRef docs baseline for plugins.entries.qianfan.config.webSearch.apiKey
  • added the missing Qianfan web-search credential to the canonical SecretRef surface page
  • removed the Baidu card self-link in docs/tools/web.md

Test Plan

Ran:

  • COREPACK_HOME=/tmp/corepack corepack pnpm exec vitest run --config vitest.unit.config.ts extensions/qianfan/src/baidu-web-search-provider.test.ts src/config/config.web-search-provider.test.ts src/plugins/web-search-providers.test.ts src/plugins/web-search-providers.runtime.test.ts src/commands/onboard-search.test.ts src/secrets/runtime.coverage.test.ts
  • COREPACK_HOME=/tmp/corepack corepack pnpm exec vitest run --config vitest.extensions.config.ts extensions/qianfan/src/baidu-web-search-provider.test.ts extensions/qianfan/web-search-provider.contract.test.ts extensions/qianfan/bundled-web-search.contract.test.ts extensions/qianfan/plugin-registration.contract.test.ts
  • PATH=/tmp/corepack-bin:$PATH COREPACK_HOME=/tmp/corepack corepack pnpm exec vitest run --config vitest.unit.config.ts src/secrets/target-registry.test.ts
  • PATH=/tmp/corepack-bin:$PATH COREPACK_HOME=/tmp/corepack corepack pnpm exec vitest run --config vitest.unit.config.ts src/secrets/runtime.coverage.test.ts
  • COREPACK_HOME=/tmp/corepack corepack pnpm check:bundled-plugin-metadata
  • PATH=/tmp/corepack-bin:$PATH COREPACK_HOME=/tmp/corepack corepack pnpm check
  • PATH=/tmp/corepack-bin:$PATH COREPACK_HOME=/tmp/corepack corepack pnpm check:docs

Manual / live validation performed locally against the Baidu Qianfan endpoint:

  • direct search request/response shape
  • smart search request/response shape

Current CI Status

On the latest PR head 6a145ae488, the Baidu-related regressions that had shown up in:

  • checks-node-test-3
  • checks-windows-node-test-5

are resolved.

The remaining failing checks are currently outside the touched Baidu / Qianfan / web-search surface:

  • src/plugins/contracts/tts.contract.test.ts
  • extensions/matrix/src/matrix/monitor/index.test.ts
  • src/process/exec.test.ts

Recent main CI runs have also been unstable, so these remaining failures may need reruns once the base-branch noise settles.

Known Verification Gap

Full pnpm build in this environment is currently blocked by a repo-level postbuild step while staging bundled runtime deps for slack (npm install failed in scripts/runtime-postbuild.mjs).

I was able to verify:

  • targeted unit coverage
  • extension/provider tests
  • contract tests
  • bundled metadata sync
  • SecretRef baseline sync
  • pnpm check
  • pnpm check:docs

AI-assisted Disclosure

This PR was implemented with AI assistance, then reviewed locally with the scope intentionally kept to a small provider addition under the existing Qianfan plugin.

Changed files

  • docs/reference/secretref-credential-surface.md (modified, +1/-0)
  • docs/reference/secretref-user-supplied-credentials-matrix.json (modified, +7/-0)
  • docs/tools/web.md (modified, +19/-14)
  • extensions/qianfan/bundled-web-search.contract.test.ts (added, +3/-0)
  • extensions/qianfan/index.ts (modified, +4/-0)
  • extensions/qianfan/openclaw.plugin.json (modified, +37/-1)
  • extensions/qianfan/plugin-registration.contract.test.ts (added, +7/-0)
  • extensions/qianfan/src/baidu-web-search-provider.test.ts (added, +223/-0)
  • extensions/qianfan/src/baidu-web-search-provider.ts (added, +429/-0)
  • extensions/qianfan/web-search-provider.contract.test.ts (added, +3/-0)
  • extensions/qianfan/web-search-provider.ts (added, +1/-0)
  • src/commands/onboard-search.test.ts (modified, +19/-0)
  • src/config/config.web-search-provider.test.ts (modified, +40/-3)
  • src/config/test-helpers.ts (modified, +3/-1)
  • src/plugins/bundled-plugin-metadata.generated.ts (modified, +43/-2)
  • src/plugins/web-search-providers.runtime.test.ts (modified, +2/-0)
  • src/plugins/web-search-providers.test.ts (modified, +3/-0)
  • src/secrets/runtime.coverage.test.ts (modified, +5/-1)
  • src/secrets/target-registry-data.ts (modified, +11/-0)
RAW_BUFFERClick to expand / collapse

Summary

Add Baidu as an optional web_search provider to improve zh-CN retrieval quality in OpenClaw.

To keep the change small, the proposed implementation would register baidu via the existing bundled qianfan plugin and expose only the minimum config needed for web search.

Motivation

OpenClaw already supports multiple web search providers, and recent issues show ongoing demand for broader provider coverage and provider extensibility in this area.

For zh-CN workflows, Baidu is a meaningful addition because it is not just another API surface. It adds access to a search backend that is especially strong on the mainland Chinese web ecosystem, including local portals, services, news, documentation, and Chinese-language sites where localized recall matters.

This also fits a concrete product gap: there has already been a reported Brave + Chinese locale issue in web_search (#42746), and there is recurring community interest in additional web search providers (#43337, #48160, #50967).

Why Baidu

1. Baidu is still the largest search backend in China

As of February 2026, StatCounter reports:

That makes Baidu the most representative search backend for many mainland Chinese queries, especially mobile-first and locally hosted content.

2. The Chinese-language internet is large enough to justify dedicated retrieval coverage

According to the Chinese government / CNNIC release published on February 5, 2026, China had 1.125 billion internet users by the end of 2025, with an internet penetration rate of 80.1%.
https://english.www.gov.cn/archive/statistics/202602/05/content_WS698442cac6d00ca5f9a08edc.html

Given that scale, it seems reasonable for OpenClaw to expose at least one search provider that is explicitly strong on the Chinese web ecosystem.

3. Baidu's official APIs map cleanly onto OpenClaw's existing web_search shapes

Baidu Qianfan already exposes both:

That maps naturally onto OpenClaw's current web_search patterns:

  • direct mode -> normalized results[]
  • smart mode -> content + citations

So this looks like a practical, low-friction provider addition rather than a speculative integration.

Proposed Scope

This issue proposes only a narrowly scoped provider addition:

  • add a bundled baidu web search provider
  • register it via the existing qianfan plugin
  • support a minimal config surface:
    • plugins.entries.qianfan.config.webSearch.apiKey
    • plugins.entries.qianfan.config.webSearch.mode
    • plugins.entries.qianfan.config.webSearch.model
  • support QIANFAN_API_KEY as an env fallback
  • expose two modes:
    • direct
    • smart
  • add targeted tests and docs

Non-goals

This proposal does not include:

  • fallback / rotation between providers
  • provider ranking redesign
  • query rewriting
  • web_search plugin architecture refactors
  • unrelated UI work
  • a broader Qianfan feature expansion outside this provider addition

Why this shape

Using the existing qianfan plugin should keep the diff smaller and easier to review:

  • no new standalone plugin package
  • no new auth surface beyond Qianfan
  • minimal config expansion
  • better consistency with existing bundled provider patterns

Open Question

Would maintainers be comfortable with the minimal qianfan-owned shape described above, or would a standalone baidu plugin be preferred even if it makes the change larger?

My preference is the smaller qianfan-owned version because it keeps the scope tight and the review surface focused.

extent analysis

Fix Plan

To add Baidu as an optional web_search provider, follow these steps:

  • Register baidu via the existing qianfan plugin
  • Add a minimal config surface:
    • plugins.entries.qianfan.config.webSearch.apiKey
    • plugins.entries.qianfan.config.webSearch.mode
    • plugins.entries.qianfan.config.webSearch.model
  • Support QIANFAN_API_KEY as an env fallback
  • Expose two modes:
    • direct
    • smart

Example code:

# qianfan_plugin.py
import os

class QianfanPlugin:
    def __init__(self, config):
        self.config = config
        self.api_key = self.config.get('webSearch', {}).get('apiKey')
        self.mode = self.config.get('webSearch', {}).get('mode')
        self.model = self.config.get('webSearch', {}).get('model')

    def search(self, query):
        if self.mode == 'direct':
            # Use Baidu direct search API
            url = f'https://api.baidu.com/qianfan/v1/search?query={query}&apiKey={self.api_key}'
        elif self.mode == 'smart':
            # Use Baidu AI search API
            url = f'https://api.baidu.com/qianfan/v1/search/smart?query={query}&apiKey={self.api_key}&model={self.model}'
        # Send request and return results

# config.py
QIANFAN_API_KEY = os.environ.get('QIANFAN_API_KEY')

# Add Baidu web search provider
plugins.entries.qianfan.config.webSearch = {
    'apiKey': QIANFAN_API_KEY,
    'mode': 'direct',  # or 'smart'
    'model': 'default'  # or other models
}

Verification

To verify that the fix worked:

  • Test the baidu web search provider with different modes and queries
  • Check the search results for accuracy and relevance
  • Ensure that the config surface is minimal and easy to use

Extra Tips

  • Make sure to handle errors and exceptions properly when using the Baidu API
  • Consider adding more test cases to cover different scenarios and edge cases
  • Keep the code organized and maintainable by following standard coding practices and conventions.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#integration issue#index setup#retrieval issue#search optimization

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix Feature: add Baidu as a web_search provider for stronger zh-CN retrieval [1 pull requests, 5 comments, 2 participants]