web_search
像让 Grok 去网上找资料，再把结果讲成答案。
Tools 导读
用 Grok 做联网搜索：一个 API Key 同时搞定网页搜索和 X 帖子搜索
配置时先拿 XAI_API_KEY，它同时驱动 web_search 和 x_search 两个工具。x_search 只搜 X 帖子，要查转发、回复等指标必须用帖子 URL 或 ID，别用泛搜。
先讲这一页到底在解决什么
用 Grok 做联网搜索：一个 API Key 同时搞定网页搜索和 X 帖子搜索
配置时先拿 XAI_API_KEY，它同时驱动 web_search 和 x_search 两个工具。x_search 只搜 X 帖子，要查转发、回复等指标必须用帖子 URL 或 ID，别用泛搜。
第一站
🧩 先把它想成“一个钥匙，多扇门”
官方一开始就提醒你：Grok 这条线不只是网页搜索，它还可能顺手给 X 搜索和 xAI 模型提供后备支持。
x_search
像专门去 X 上找帖子。它和网页搜索不是一回事。
同一把 key
XAI_API_KEY 还能同时供给这几条线，像一把万能门卡。
先记一句
Grok 不只是网页搜索，它还是 xAI 生态里的一扇口子。
第二站
🚀 它为什么和 Gemini 看起来像一对双胞胎
因为它们都不是“只给链接”的搜索，而是“先找，再整理成答案”。只是背后的公司不同，地上的小路也不同。
🧠 xAI web-grounded responses
像让 Grok 先去找资料，再把资料整理成可读的答案。
📝 有引用
答案不是拍脑袋来的，后面会挂上来源。
🔁 还能顺带当后备钥匙
如果你把 key 放在 xAI 的配置里，它还能给 bundled xAI model provider 做 fallback。
📌 这页真正的主线
Grok 是“答案型搜索”，不是“链接型搜索”。
第三站
🛫 Onboarding 那一步，像“我先替你把两个门一起开好”
官方特别提了 openclaw onboard 和 openclaw configure --section web，因为选 Grok 时，可能会顺手问你要不要把 X 搜索也一起开了。
⚙️ 选 Grok 时的 follow-up
像你说“我想用这把钥匙”，系统顺手问你：“要不要连隔壁 X 那扇门也一起开？”
🧰 不是顶层单独入口
它不是一个独立的大类 web provider，而是 Grok 选择之后的一个后续动作。
📍 如果先跳过也没关系
以后也能再把 x_search 打开，不是第一次没选就永远错过。
🎈 一句话
选 Grok，常常等于顺便在问要不要把 X 搜索也装上。
第四站
🔑 API key 的动作不复杂，就是把 xAI 的门卡放进来
这页的 key 逻辑很直接：去 xAI 拿 key，然后放进 Gateway 环境，或者让 OpenClaw 的 web 配置帮你写进去。
XAI_API_KEY像一张门卡。没它，Grok 这位小喇叭就没法上岗。
openclaw configure --section web像把网页搜索设置打开，然后把 Grok 填进去。
provider: \"grok\"像告诉总搜索台：“网页搜索先找 xAI 这条路。”
🧠 还会复用到别的地方
如果你把 key 存在 xAI 的插件配置里，它还能被后面的 xAI 模型 provider 复用。
第五站
🧪 x 搜索和网页搜索，像两个不同的放大镜
官方特地提醒了一个小细节：如果你要的是帖子级别的信息，最好直接去用 x_search，别拿宽泛网页搜索硬找。
网页搜索
适合查网页、查文章、查一般资料。
X 搜索
适合查具体帖子，还能看 reposts、replies、bookmarks、views 这些细节。
精确 URL / status ID
如果你已经知道那条帖子在哪，直接拿门牌号去找最省事。
先记一句
找帖子就用 x_search，别把它塞进普通网页搜索里硬找。
第六站
🧷 参数很少，说明它主打的是“直接讲答案”
Grok Search 支持的参数也不多。它像 Gemini 一样，更偏答案型输出，而不是复杂筛选器型输出。
query你真正想问的问题。
count想让它带回来多少条结果。
🚫 不支持太多花活
像国家、语言、时效、域名过滤这类细筛选，它这里都不主打。
🎈 这一节的感觉
Grok 更像“把答案讲出来”，不是“给你一堆可拧的旋钮”。
最后总结
把这页压成一句最好记的话
Grok Search 是 xAI 的答案型网页搜索，和 X 搜索还能共用一把钥匙。它适合你想要“搜完就能讲”的场景。
如果你下一页只想继续看一页，我建议看 /tools/kimi-search。它也走答案型网页搜索，但背后的路子换成了 Moonshot。