EC 搜索抓取与
浏览器模拟 实测报告

项目里 Search Module 需要什么

从 agent_requirement.md 看，Search Module 是 Requirement Agent 的基础设施。 抓取结果不是「网页文本摘要」，而应该落到结构化字段。 这决定了工具选择 — 能稳定返回结构化字段的 driver，优先级高于「看起来能浏览页面」的工具。

站点可得性矩阵

P0 是「立刻做 PoC」候选；P1 是次优补充；API 优先类不写爬虫；放弃 / 删除类不进路线图。

建议补充进候选池的数据源

下面不是本轮本机实测结论，而是根据官方文档和项目需求补充的候选源。它们更适合走 API / 商务接口，不建议优先写网页爬虫。

工具选型决策树

用户需求进 Requirement Agent → Search Agent 查 site_registry → 按官方 API / 已有 driver / 探路层 分流。 探路找到稳定接口就沉淀成 Python driver；找不到就降级到 SaaS 兜底或放弃。

flowchart TD
  A["用户需求 / PN / 自然语言"] --> B["Requirement Agent"]
  B --> C["Search Agent / module_search"]
  C --> D{"站点是否已有官方 API?"}
  D -->|是| E["官方 SDK / 商务 API"]
  D -->|否| F{"site_registry 是否已有 driver?"}
  F -->|curl_cffi| G["curl_cffi driver
0.5–15 s · 批量主力"]
  F -->|patchright| H["patchright driver
4–10 s · 强反爬补齐"]
  F -->|无| I["浏览器探路层"]
  I --> J["Edge DevTools / Playwright MCP
抓 Network · 登录态 · 现场诊断"]
  I --> K["Stagehand / Crawl4AI / Scrapling
探索页面结构并生成候选 parser"]
  J --> L{"能固化成稳定接口?"}
  K --> L
  L -->|能| M["沉淀为新 Python driver
加入 site_registry"]
  L -->|不能| N{"商业价值足够高?"}
  N -->|高| O["Browserless / Bright Data
SaaS 兜底评测"]
  N -->|低| P["放弃 / 发 API 申请 / 人工询价"]
  E --> Q["统一 SearchOffer schema"]
  G --> Q
  H --> Q
  M --> Q
  O --> Q

  classDef start fill:#1A2238,stroke:#1A2238,color:#F4F1EA;
  classDef decision fill:#F4F1EA,stroke:#2E5C8A,color:#1A2238;
  classDef prod fill:#4A7C3E,stroke:#4A7C3E,color:#F4F1EA;
  classDef explore fill:#7A8FA8,stroke:#7A8FA8,color:#F4F1EA;
  classDef saas fill:#B85C2E,stroke:#B85C2E,color:#F4F1EA;
  classDef fail fill:#A33A2D,stroke:#A33A2D,color:#F4F1EA;
  classDef out fill:#1E3F66,stroke:#1E3F66,color:#F4F1EA;
  class A,B,C start;
  class D,F,L,N decision;
  class E,G,H,M prod;
  class I,J,K explore;
  class O saas;
  class P fail;
  class Q out;
      

建议的工程落地

三步走：site_registry → SearchOffer schema → 一周可交付的 PoC。 不追求 perfect，先把 6-7 个 driver + 1 个 patchright driver 接进去，回归跑起来。

第一步 · 建 site_registry

so_szlcsc:
  host: so.szlcsc.com
  method: curl_cffi
  parser: next_data_json
  evidence_level: retested
  fields:
    - mpn
    - brand
    - package
    - category
    - param_map
    - stock_total
    - stock_gd
    - stock_smt
    - rohs
  missing:
    - price_tiers

hqchip:
  host: www.hqchip.com
  method: curl_cffi
  parser: html
  evidence_level: retested
  fields: [mpn, stock, price_text]

lcsc_overseas:
  host: www.lcsc.com
  method: patchright
  evidence_level: existing_raw_result
  note: use only when official LCSC API is unavailable

mouser_cn:
  host: www.mouser.cn
  method: official_api_only
  evidence_level: retested_blocked

第二步 · 统一 SearchOffer schema

class SearchOffer:
    query: str
    normalized_mpn: str | None
    manufacturer: str | None
    distributor: str
    source_url: str
    source_type: str  # official_api / curl_cffi / patchright / mcp_probe
    sku: str | None
    package: str | None
    category: str | None
    param_map: dict
    stock: int | None
    stock_detail: dict
    price_tiers: list[dict]
    currency: str | None
    moq: int | None
    lead_time_days: int | None
    rohs: bool | None
    datasheet_url: str | None
    fetched_at: str
    confidence: float
    evidence_digest: str

第三步 · 一周内可交付的 PoC

如果要做更完整评测 · 三个小实验

只建议在 curl_cffi + patchright PoC 之后做。否则会把时间花在平台调研上，反而拖慢 Search Module 的第一版落地。

回归测试标准

每个 driver 每天跑 3 个固定 PN，看字段覆盖率与稳定性变化：

每次记录

• HTTP 状态、字节数、命中字段数
• 解析出的 offer 数量
• stock / price 是否为空
• 与上次结果的字段差异
• 失败截图或 HTML 摘要