Web 搜索路由 — 按任务类型选最专工具
不要用固定工具组合糊弄所有查询。按任务类型选最专工具。内置 WebSearch 在本机(IP 限制)不可用,别拿它当兜底——它返回兜底提示,不出结果。
工具分工
| 任务类型 | 首选工具 |
|---|---|
| GitHub repo 发现(轻量,3-7 个候选) | gh search repos(--sort stars 取前 N) |
| GitHub issue / discussion / PR 读取 | gh issue view / gh api repos/.../discussions(glue-engineer 无此能力) |
| GitHub repo 发现 + 评分 + 能力匹配 + 胶水代码(重量) | glue-engineer(用户显式调用,不自动加载) |
| 库/包注册表检索(版本/许可证/下载量) | glue-engineer(polyglot scout/cross-search,用户显式调用) |
| 新鲜度/新闻/发布/价格/状态(非 GitHub web 查询) | keenable search_web_pages(见下方说明) |
| 单页定向提问(已知 URL 抽字段) | keenable fetch_page_content(prompt) |
| 单页内容抓取 + 引用落库 | wigolo fetch |
| 站点爬取/文档索引 | wigolo crawl |
| 结构化抽取(表格/字段/JSON-LD) | wigolo extract |
| 多步综合研究 | wigolo research / agent |
| 页面变化监控 | wigolo watch / diff |
| 相关内容发现 | wigolo find_similar |
| 本地缓存复用/重查旧题 | wigolo cache |
keenable 的角色(诚实定位)
keenable 不是 agent 默认会主动选的工具。实测 10 路并行(2026-09-09),agent 在新鲜度/新闻类查询上默认只跑 wigolo 单源,不会自动跑 keenable——即便 skill 写"必跑"也管不住。所以别把 keenable 当强制铁律,它做不到。
keenable 的真实价值:内置 WebSearch 在本机不可用,keenable 是唯一可用的新鲜度+召回源(2026-09-07 实测:同一查询 wigolo 5 条结果 4 条偏离,keenable 5 条直击当周新闻)。查最新动态/新闻/发布/价格这类新鲜度导向查询,主动调一次 mcp__keenable__search_web_pages 补召回+新鲜度,值得;但不是每个 web 查询都强求。
判断要不要 keenable 看查询形状:明显新鲜度导向(最新版本/刚发布/今天价格)→ 跑 keenable 补;静态调研(有没有这类工具、对比方案)→ wigolo 为主,keenable 可选补。
引用落库(唯一硬约束)
凡是要写进有引用的回答的 URL → 第一步必须是 wigolo fetch 落库,引用一律从 wigolo cache 取(带 citation_id + source_span)。keenable 发现的 URL 尤其要 fetch——keenable 输出是瞬时的(无缓存、无 citation_id、无 source_span),直接引用即丢失可审计性。gh CLI 抓的 issue/discussion 引用时带 issue 编号 + 仓库 URL 即可,gh 已是结构化源。
不要用"一次性调研过重"当借口跳过 wigolo fetch。同样 N 次 fetch,走 wigolo 拿到缓存+引用,走 keenable 只拿到瞬时文本——跳过 wigolo 不是省成本,是纯损失。
交叉验证
内置 WebSearch 不可用,交叉验证靠 keenable + wigolo 双取(两源都跑一遍,结果对照),或 多来源 wigolo fetch 同一事实(抓多个一手页对照)。别指望 WebSearch 兜底。
例外——单点事实查询
答案能在一条 snippet 内闭合、不交叉比对、不写进有引用的回答(如"今天 xx 价格多少""xx 发售了吗""xx 现在是什么版本号")。这类 keenable 单飞即可。判断标准看查询形状(单点事实 vs 多源综合),不看"会不会引用"——查询时无法预知最终是否引用。
默认链(凡要写进回答、要引用、要对比多源的 web 查询)
- 发现(按查询形状选):
- wigolo 路(默认): 先cache(查本地,命中免费)→ 未命中跑search(多关键词变体,结果带引用且落缓存)。
- keenable 路(新鲜度导向时补):search_web_pages补召回+新鲜度+厚 snippet,收集 URL + 发布日期。keenable 的 URL 稍后必须 wigolofetch落库才能引用。
wigolo 强在可引用+缓存复用,keenable 强在新鲜度+召回;新鲜度查询两路都跑,静态调研 wigolo 为主。 - 对每个值得用的 URL →
mcp__wigolo__fetch落本地缓存(keenable 发现的 URL 尤其要 fetch,它瞬时无引用)。 - 所有引用/复用走 wigolo cache(带
citation_id+source_span)。绝不引用 keenable 的瞬时 snippet。
已有明确 URL 或重查旧题:跳过发现,直接 wigolo cache(命中免费)→ fetch(未命中补抓)。
为什么这么分
- 实测(2026-09-09,10 路并行压测,经 4 轮措辞迭代): GitHub 查询走
gh的 agent(归档工具、封号报告)产出最扎实,无需通用搜索;新鲜度查询不跑 keenable 的 agent 只剩 wigolo 单源,漏新鲜度——但 skill 写"keenable 必跑"也没能管住(4 轮措辞均失败),agent 是否跑 keenable 是概率性的,非措辞可控。内置 WebSearch 在本机全程返回兜底提示,不可用。 - 2026-09-07 实测: 同一查询 "Anthropic Claude latest model release 2026",wigolo 5 条结果 4 条偏离,keenable 5 条全是当周新闻直击要点。keenable 胜在召回+新鲜度,wigolo 胜在可审计性(评分、citation、缓存)。互补,不冗余。
- 取舍: 放弃"keenable 必跑"铁律(管不住,强行写只产生不实承诺),保留"引用落库"为唯一硬约束(这条实测稳定执行)。keenable 降为新鲜度导向查询的首选建议,agent 主动用更好,不用也不算 skill 失职。
