你们的Hermes都是怎么网上冲浪的？
-
我用本地searxng服务配置给hermes的web_search用，简单的信息搜索他回复很快，貌似是meta search的关系。
深度搜索或需要仔细读取网页内容的时候，hermes会调用我的本地firecrawl服务来读取网页内容。这时候其实分两层，一层是firecrawl爬取网页的速度，还有就是对网页内容进行归纳总结的速度（推理模型的速度），这个可以在config.yaml的服务任务（auxiliary）中设置web_extract部分控制，默认是主模型，但是如果主模型不够快（比如本地小模型），你可以指定其他模型，比如云模型api、或本地更快的模型来执行。 -
我一直都是自己写。思路更新在我的帖子里。实测7900XTX 就可以跑起来。但是属于入门级别。太复杂的操作不了。更新后 发现 其他 指纹厂商也都 陆续 跟风。接口持续丰富中。光是冲浪的话应该很简单的。（所以看我的思路就行了，浏览器可以看看其他厂商。）
重点是你的本地模型要测试好。一定要足够稳定。上下文测试是重点。新手不如直接用在线 api 搞。跑通生成 skill 再转移到 本地。
经验：在线转 本地 需要 在线api 继续修缮。本地 小 显存24G 都会折腾一段。预测 48G是甜点区。 -
我一直都是自己写。思路更新在我的帖子里。实测7900XTX 就可以跑起来。但是属于入门级别。太复杂的操作不了。更新后 发现 其他 指纹厂商也都 陆续 跟风。接口持续丰富中。光是冲浪的话应该很简单的。（所以看我的思路就行了，浏览器可以看看其他厂商。）
重点是你的本地模型要测试好。一定要足够稳定。上下文测试是重点。新手不如直接用在线 api 搞。跑通生成 skill 再转移到 本地。
经验：在线转 本地 需要 在线api 继续修缮。本地 小 显存24G 都会折腾一段。预测 48G是甜点区。@williamlouis 我个人的经验的话，还是得看具体的任务难度。我的hermes的默认profile用的qwen3.6 35b a3，负责做一些简单的任务以及控制cron定时任务，够用了。复杂任务就用27b 稠密或云服务的api 调用deepseek v4 flash，就和版主说的一样，跑通了做成skill给本地小模型用，能省就省点
-
爬取网页用什么工具最好啊？好的衡量标准就是快、稳定、能最大程度规避放机器人机制。
我本地部署的Firecrawl，用着还行，但是实在是太慢了，爬一个网页有时候要几分钟...
SearXNG只能搜索，爬具体网站还得靠别的工具。
我装了一个Scrapling的Skill，目前来说是最好用的，可是默认的web_extract工具并不支持它，如果不提醒Hermes，他还是经常使用默认的。
各位大佬爬网页这一块子是怎么搞的呢？
@Ray-Wang 分享我的hermes自己總結的內容
目前的架構。讓我總結給你看：
目前設定：
- web.search_backend = searxng（本機 SearXNG，localhost:8888）
- web.extract_backend = firecrawl（本機自架 Firecrawl，localhost:3002）
- web_extract 的 LLM 壓縮 = GPU1 的 9B 模型（port 8081）
你提到的 Skill 強制走 browser_navigate + browser_snapshot 方案 vs 現況比較：
搜尋
• 你的 Skill 方案（browser_*): 無，需另外處理
• 目前（Firecrawl + SearXNG）: SearXNG 聚合 5 個來源，免金鑰正文擷取
• 你的 Skill 方案（browser_*): Playwright 瀏覽器引擎，JS 渲染完整
• 目前（Firecrawl + SearXNG）: Firecrawl 抓全文 + 9B 壓縮摘要速度
• 你的 Skill 方案（browser_*): 快（直接瀏覽器渲染）
• 目前（Firecrawl + SearXNG）: Firecrawl 有中間層 + 壓縮模型，較慢防爬繞過
• 你的 Skill 方案（browser_*):
瀏覽器引擎原生繞過
• 目前（Firecrawl + SearXNG）: Firecrawl 也有繞過能力長文處理
• 你的 Skill 方案（browser_*): 需手動 document.body.innerText 再壓縮
• 目前（Firecrawl + SearXNG）: 自動 LLM 壓縮（5000字以上）維護成本
• 你的 Skill 方案（browser_*): 高（要寫 Skill 約束 + 等渲染）
• 目前（Firecrawl + SearXNG）: 低（設定檔指路徑即可）結論：目前的 Firecrawl + SearXNG 方案功能更完整（搜尋+擷取+壓縮一條龍），但 Firecrawl 確實比 Playwright 直調慢。
如果你想切回 Playwright 直調，理論上可以改 web.extract_backend 為其他支援的後端，但問題是 Hermes 內建的 extract 後端只有 firecrawl / tavily / exa / parallel，沒有 browser_* 作為 extract 後端的選項。要強制走 browser_navigate 那條路，你的 Skill 方案確實是目前唯一做法——但那樣就失去 Firecrawl 自動壓縮摘要的便利。
我的建議：維持現況。原因：
- 搜尋摘要 + Firecrawl 全文擷取 + LLM 壓縮，一條龍搞定，不用我手動處理
- 速度差在可接受範圍（壓縮模型在 GPU1 上約 3-5 秒）
- Skill 強制方案會增加維護成本，且失去自動壓縮功能
如果你覺得 Firecrawl 太慢想換 Playwright 直調，我可以幫你寫那個 Skill，但會犧牲自動壓縮摘要的功能。
-
@Ray-Wang 分享我的hermes自己總結的內容
目前的架構。讓我總結給你看：
目前設定：
- web.search_backend = searxng（本機 SearXNG，localhost:8888）
- web.extract_backend = firecrawl（本機自架 Firecrawl，localhost:3002）
- web_extract 的 LLM 壓縮 = GPU1 的 9B 模型（port 8081）
你提到的 Skill 強制走 browser_navigate + browser_snapshot 方案 vs 現況比較：
搜尋
• 你的 Skill 方案（browser_*): 無，需另外處理
• 目前（Firecrawl + SearXNG）: SearXNG 聚合 5 個來源，免金鑰正文擷取
• 你的 Skill 方案（browser_*): Playwright 瀏覽器引擎，JS 渲染完整
• 目前（Firecrawl + SearXNG）: Firecrawl 抓全文 + 9B 壓縮摘要速度
• 你的 Skill 方案（browser_*): 快（直接瀏覽器渲染）
• 目前（Firecrawl + SearXNG）: Firecrawl 有中間層 + 壓縮模型，較慢防爬繞過
• 你的 Skill 方案（browser_*): 瀏覽器引擎原生繞過
• 目前（Firecrawl + SearXNG）: Firecrawl 也有繞過能力長文處理
• 你的 Skill 方案（browser_*): 需手動 document.body.innerText 再壓縮
• 目前（Firecrawl + SearXNG）: 自動 LLM 壓縮（5000字以上）維護成本
• 你的 Skill 方案（browser_*): 高（要寫 Skill 約束 + 等渲染）
• 目前（Firecrawl + SearXNG）: 低（設定檔指路徑即可）結論：目前的 Firecrawl + SearXNG 方案功能更完整（搜尋+擷取+壓縮一條龍），但 Firecrawl 確實比 Playwright 直調慢。
如果你想切回 Playwright 直調，理論上可以改 web.extract_backend 為其他支援的後端，但問題是 Hermes 內建的 extract 後端只有 firecrawl / tavily / exa / parallel，沒有 browser_* 作為 extract 後端的選項。要強制走 browser_navigate 那條路，你的 Skill 方案確實是目前唯一做法——但那樣就失去 Firecrawl 自動壓縮摘要的便利。
我的建議：維持現況。原因：
- 搜尋摘要 + Firecrawl 全文擷取 + LLM 壓縮，一條龍搞定，不用我手動處理
- 速度差在可接受範圍（壓縮模型在 GPU1 上約 3-5 秒）
- Skill 強制方案會增加維護成本，且失去自動壓縮功能
如果你覺得 Firecrawl 太慢想換 Playwright 直調，我可以幫你寫那個 Skill，但會犧牲自動壓縮摘要的功能。
-
@Ray-Wang 分享我的hermes自己總結的內容
目前的架構。讓我總結給你看：
目前設定：
- web.search_backend = searxng（本機 SearXNG，localhost:8888）
- web.extract_backend = firecrawl（本機自架 Firecrawl，localhost:3002）
- web_extract 的 LLM 壓縮 = GPU1 的 9B 模型（port 8081）
你提到的 Skill 強制走 browser_navigate + browser_snapshot 方案 vs 現況比較：
搜尋
• 你的 Skill 方案（browser_*): 無，需另外處理
• 目前（Firecrawl + SearXNG）: SearXNG 聚合 5 個來源，免金鑰正文擷取
• 你的 Skill 方案（browser_*): Playwright 瀏覽器引擎，JS 渲染完整
• 目前（Firecrawl + SearXNG）: Firecrawl 抓全文 + 9B 壓縮摘要速度
• 你的 Skill 方案（browser_*): 快（直接瀏覽器渲染）
• 目前（Firecrawl + SearXNG）: Firecrawl 有中間層 + 壓縮模型，較慢防爬繞過
• 你的 Skill 方案（browser_*): 瀏覽器引擎原生繞過
• 目前（Firecrawl + SearXNG）: Firecrawl 也有繞過能力長文處理
• 你的 Skill 方案（browser_*): 需手動 document.body.innerText 再壓縮
• 目前（Firecrawl + SearXNG）: 自動 LLM 壓縮（5000字以上）維護成本
• 你的 Skill 方案（browser_*): 高（要寫 Skill 約束 + 等渲染）
• 目前（Firecrawl + SearXNG）: 低（設定檔指路徑即可）結論：目前的 Firecrawl + SearXNG 方案功能更完整（搜尋+擷取+壓縮一條龍），但 Firecrawl 確實比 Playwright 直調慢。
如果你想切回 Playwright 直調，理論上可以改 web.extract_backend 為其他支援的後端，但問題是 Hermes 內建的 extract 後端只有 firecrawl / tavily / exa / parallel，沒有 browser_* 作為 extract 後端的選項。要強制走 browser_navigate 那條路，你的 Skill 方案確實是目前唯一做法——但那樣就失去 Firecrawl 自動壓縮摘要的便利。
我的建議：維持現況。原因：
- 搜尋摘要 + Firecrawl 全文擷取 + LLM 壓縮，一條龍搞定，不用我手動處理
- 速度差在可接受範圍（壓縮模型在 GPU1 上約 3-5 秒）
- Skill 強制方案會增加維護成本，且失去自動壓縮功能
如果你覺得 Firecrawl 太慢想換 Playwright 直調，我可以幫你寫那個 Skill，但會犧牲自動壓縮摘要的功能。
@CHIA-AN-YANG 我想问 为什么需要压缩 而不是交给模型自行决定？ 如果压缩为什么不是用主模型 而用小模型？
-
@CHIA-AN-YANG 我想问 为什么需要压缩 而不是交给模型自行决定？ 如果压缩为什么不是用主模型 而用小模型？
@applejuice 因為有兩張7900XTX 另一張跑comfyui不是很常用,還有餘裕就弄個小模型跑壓縮 快很多!!
