影片筆記：爱马仕+Agent Reach， Hermes Agent 终极进化！

一句話總結

影片探討如何透過引入具備外部資訊獲取能力的 Agent（如 Agent Rich/Reach）來解決大型語言模型（Hermes）在內容創作與選題時「缺乏真實外部視角」的問題，強調從「內部瞎猜」轉向「外部查證」的工作流，並詳細分析了路由機制、Token 成本優化、隱私風險及商業數據工具的應用限制。

核心重點

1. 解決「瞎猜」問題：單純依賴模型內部知識容易導致「瞎猜包裝成答案」，必須引入具備外部資訊獲取能力的 Agent（如 Agent Rich）為模型「開門」，獲取真實證據。
2. 驗證優先於創作：在讓 AI 寫稿前，必須先通過外部入口（GitHub, YouTube, X 等）獲取真實證據，避免錯誤的選題方向（如項目停更、無討論）導致後續剪輯、標題、封面製作的全盤浪費。
3. 路由（Routing）機制：模型需具備選擇不同工具的能力，而非單一姿勢查詢。例如：查代碼去 GitHub，查討論去 X 或 Reddit，查頻道內容去 YouTube。
4. 技術與成本優化：直接將整頁 HTML 丟給模型會消耗大量 Token（約 86,000 Token）且包含雜訊。Agent Reach/Rich 的好處在於先清理資料，撈出可用內容再交給模型，減少亂猜與成本。
5. 風險與限制：外部工具接入涉及 Cookie、隱私與帳號穩定性風險（如掉登錄、風控攔截）。國內平台（B站、小紅書、抖音）同樣面臨權限與穩定性問題。
6. 工具應用建議：

• 格洛克（Glock）：專門負責 X 上的資訊搜尋，適合發現「風向」但不適合直接當「結論」。
• Clay.com：連接聯繫人、郵箱、公司線索等業務數據，建議普通人先不要上頭，需人工複查，避免合規與隱私風險。

詳細大綱

I. 問題診斷：Hermes 類 Agent 的盲點

• 表面聰明，實際脫節：模型回答語氣穩、結構完整，但可能未真正查看外部資料（GitHub, YouTube, X）。
• 瞎猜的風險：若未實際查證，寫得越順越危險，因為這將「瞎猜」包裝成了「答案」。
• 成本錯置：錯誤的選題方向（如項目停更、無討論）會導致後續剪輯、標題、封面製作的全盤浪費，這是最大的成本。

II. 解決方案：引入 Agent Rich 與外部入口

• Agent Rich 的角色：作為「鑰匙」，打開 Hermes 通往外部資訊的門。
• 主要接駁平台：
• 海外：YouTube, GitHub, RSS, Reddit, X, LinkedIn。
• 中文場景對應：B站, 小紅書, 抖音（但需注意當前工具主要接海外內容與代碼）。
• 工作順序：先讓 Hermes 學會查證（摸到證據），再談創作（開口說話）。

III. 技術細節與優化

• Token 成本與資料清理：
• 整頁 HTML 包含菜單、按鈕、腳本、廣告等雜訊，消耗約 86,000 Token。
• Agent Reach/Rich 的好處在於先清理資料，撈出可用內容，再交給模型，減少亂猜與成本。
• 路由（Routing）機制：
• 定義不同任務對應不同工具：
• 開源項目 -> GitHub
• 頻道新內容 -> YouTube
• 海外討論 -> X 或 Reddit
• 公司/團隊線索 -> LinkedIn
• 模型需懂得「選工具」，而非所有問題用同一姿勢查詢。
• 需讓模型理解工具功能、失敗後的備選方案及交叉檢查方法。

IV. 驗證與評估方法

• 小問題驗證法：
• 不問大問題，先問具體小問題（如：某頻道最新內容的第一句話）。
• 若能找到即為真，找不到或編造則一眼看穿。
• GitHub 項目評估維度：
• 最近是否更新？
• 安裝難度與依賴問題？
• Issue 中是否有未處理的問題？
• Readme 是否清晰（講人話還是謎語）？
• 適合普通人上手嗎？適合做內容選題嗎？

V. 風險與限制

• Cookie 與帳號狀態：
• Cookie 是瀏覽器保存登錄狀態的憑證（逐字稿原文）。
• 風險：帳號掉登錄、平台改規則、風控攔截。
• 隱私邊界：需自行判斷，不可將所有帳號狀態、權限、私人內容無腦塞入。
• 國內平台限制：B站、小紅書、抖音涉及登錄、評論、帳號狀態、私域內容時，同樣面臨權限與穩定性問題。

VI. 特定工具應用：格洛克（Glock）與 X

• 格洛克的角色：作為補位工具，專門負責 X 上的資訊搜尋。
• 使用邏輯：
• X 資訊快速且混亂，適合發現「風向」，不適合直接當「結論」。
• 一人觀點不等於事實，多人吵架不等於產品翻車。
• Hermes 需將格洛克找到的「線索」與其他來源（GitHub, YouTube, RSS）的「證據」結合。

VII. 商業數據工具：Clay.com

• 定位：連接聯繫人、郵箱、公司線索等業務數據。
• 建議：普通人先不要上頭。
• 涉及業務動作（外聯、銷售線索）。
• 風險：數據準確性、隱私、合規、打擾他人。
• 必須人工複查，不能將生成的聯繫人列表直接用於群發。

VIII. 總結與工作流建議

• Hermes 的三項變化：

1. 有機會出去找資料，不再關在聊天框裡猜。
2. 知道不同任務該走不同入口。
3. 能將多個來源串起來，少一點拿到線索就急著下結論。

• 有效用法：先找資料 -> 再判斷 -> 再整理 -> 回頭補證據。
• 核心原則：不能只會說，得會查；不能只會查，還得知道查來的東西哪些能信、哪些只是線索。
• 最終建議：先給 Hermes「開門」（接 Agent Rich），而非急於增加任務。

工具 / 模型 / 名詞整理

• Hermes：被討論的主要 Agent/模型名稱。
• Agent Rich：提供外部資訊入口的工具（逐字稿中亦出現 "Agent Ridge", "Agent Reach" 等變體）。
• 格洛克（Glock）：用於補位 X 上資訊搜尋的工具。
• Clay.com：用於處理聯繫人、郵箱、公司線索的商業數據工具。
• GitHub：開源項目平台。
• YouTube：視頻平台。
• X：社交媒體平台（原 Twitter）。
• Reddit：論壇平台。
• LinkedIn：職業社交網絡。
• RSS：資訊聚合格式。
• B站：中國視頻平台。
• 小紅書：中國社交電商平台。
• 抖音：中國短視頻平台。
• Cookie：瀏覽器保存登錄狀態的憑證。
• Token：模型處理文字的計量單位，整頁 HTML 可能消耗約 86,000 Token。
• Routing（路由）：模型根據任務選擇不同工具機制的概念。

操作流程整理

1. 診斷問題：確認 Hermes 類 Agent 是否存在「表面聰明但實際脫節」的問題，識別「瞎猜」風險。
2. 引入外部入口：部署 Agent Rich/Reach 作為鑰匙，連接外部平台（GitHub, YouTube, X, LinkedIn 等）。
3. 設定路由規則：

• 開源項目 -> 指向 GitHub。
• 頻道新內容 -> 指向 YouTube。
• 海外討論 -> 指向 X 或 Reddit。
• 公司/團隊線索 -> 指向 LinkedIn。

1. 資料清理與優化：利用工具清理 HTML 雜訊（菜單、按鈕、腳本、廣告），僅保留可用內容，降低 Token 消耗。
2. 執行查證（小問題驗證法）：

• 先問具體小問題（如：某頻道最新內容的第一句話）。
• 驗證是否能找到真實證據，若找不到或編造則視為失敗。

1. 綜合評估：

• 檢查 GitHub 項目更新、安裝難度、Issue、Readme 清晰度。
• 結合格洛克（Glock）在 X 上找到的「線索」與其他來源的「證據」。

1. 商業數據處理（可選）：若涉及業務，使用 Clay.com 連接聯繫人與郵箱，並進行人工複查以確保合規與隱私。
2. 最終創作：在確認資料真實性與方向正確後，再讓 Hermes 進行內容創作。

值得注意的限制或風險

1. 帳號與隱私風險：

• Cookie 是瀏覽器保存登錄狀態的憑證，存在帳號掉登錄、平台改規則、風控攔截的風險。
• 隱私邊界需自行判斷，不可將所有帳號狀態、權限、私人內容無腦塞入模型。

1. 國內平台限制：

• B站、小紅書、抖音涉及登錄、評論、帳號狀態、私域內容時，同樣面臨權限與穩定性問題。
• 當前工具主要接海外內容與代碼，中文場景對應需注意穩定性。

1. 數據準確性與合規：

• Clay.com 生成的聯繫人列表需人工複查，直接用於群發可能涉及數據準確性、隱私、合規及打擾他人的風險。

1. 資訊解讀誤區：

• X 資訊快速且混亂，適合發現「風向」，不適合直接當「結論」。
• 一人觀點不等於事實，多人吵架不等於產品翻車。

1. Token 成本：

• 整頁 HTML 包含大量雜訊，直接丟給模型會消耗約 86,000 Token，需透過工具清理資料以降低成本。

逐字稿辨識疑點

• Hermas：逐字稿中多次出現，應指代 Hermes。
• Agent Ridge：應指 Agent Rich。
• Agent Reach：應指 Agent Rich。
• 憑震：應指「憑證」。
• Cloud Code：逐字稿中提及「查過 Cloud Code」，疑為口誤或聽寫錯誤，上下文似指代雲端代碼或特定平台，但無明確上下文支持，僅作記錄。
• 克劳德扣：逐字稿中提及「你想看克劳德扣的最近有什么新进展」，疑為「Claude」或其他模型名稱的聽寫錯誤，但不得自行更正，僅作記錄。
• RS：在「GitHub, YouTube, RS, 或其他來源」中出現，疑為 RSS 的縮寫或聽寫錯誤。
• 为更多任务：在「先别急着给他为更多任务」中，語意不通，疑為「為更多任務」或「做更多任務」的口誤。

可延伸追問

1. 如何具體設定 Hermes 的路由（Routing）規則，以確保模型能準確區分不同類型的查詢並調用對應的外部工具？
2. 在處理國內平台（B站、小紅書、抖音）時，目前有哪些具體的技術方案可以克服登錄狀態與風控攔截的問題？
3. Agent Rich/Reach 在清理 HTML 雜訊時，具體的演算法或邏輯是什麼，如何保證不遺漏關鍵資訊？
4. 對於 Clay.com 生成的商業數據，有哪些具體的合規檢查清單或人工複查流程建議？
5. 如何量化「瞎猜」的風險？是否有指標可以監測模型是否真正查看了外部資料而非僅憑內部知識生成回答？