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

## 一句話總結

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

## 核心重點

1.  **解決「瞎猜」問題**：單純依賴模型內部知識容易導致「瞎猜包裝成答案」，必須引入具備外部資訊獲取能力的 Agent（如 Agent Rich）來為模型「開門」，獲取真實證據。
2.  **驗證優先於創作**：在讓 AI 寫稿前，必須先通過外部入口（GitHub, YouTube, X 等）獲取真實證據，避免方向錯誤導致後續內容成本浪費。順序應為：摸到證據 -> 開口說話。
3.  **路由（Routing）機制**：模型需具備選擇不同工具的能力，而非單一姿勢查詢。例如：查代碼去 GitHub，查討論去 X，查頻道內容去 YouTube。
4.  **技術與成本優化**：直接將整頁 HTML 丟給模型會消耗大量 Token（約 86,000 Token）且包含雜訊。Agent Reach/Rich 的好處在於先清理資料，撈出可用內容，再交給模型，減少亂猜與成本。
5.  **風險與限制**：外部工具接入涉及 Cookie、隱私與帳號穩定性等風險。需自行判斷隱私邊界，不能將所有帳號狀態、權限、私人內容無腦塞入。
6.  **工具分工建議**：
    *   **研究類**：先學習 Agent Rich、格洛克（Glock），用於獲取公開資訊與線索。
    *   **商業數據類**：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, RS）的「證據」結合。

### 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。

## 操作流程整理

1.  **診斷問題**：確認 Hermes 類 Agent 是否存在「表面聰明但脫節」的問題，評估選題方向是否正確（如項目是否停更、有無討論）。
2.  **引入外部工具**：
    *   根據任務類型選擇入口（路由機制）：
        *   查代碼/開源項目 -> GitHub
        *   查頻道內容 -> YouTube
        *   查討論/風向 -> X (透過格洛克) 或 Reddit
        *   查公司/團隊 -> LinkedIn
    *   使用 Agent Rich/Reach 作為鑰匙打開外部門戶。
3.  **資料清理與獲取**：
    *   利用工具清理 HTML 雜訊（菜單、按鈕、腳本、廣告）。
    *   撈出可用內容，減少 Token 消耗與模型亂猜。
4.  **驗證與評估**：
    *   使用「小問題驗證法」：先問具體小問題（如頻道最新內容第一句話），確認證據真實性。
    *   評估 GitHub 項目：檢查更新頻率、安裝難度、Issue 情況、Readme 清晰度。
5.  **綜合判斷與創作**：
    *   將格洛克找到的「線索」與其他來源（GitHub, YouTube, RS）的「證據」結合。
    *   先找資料 -> 再判斷 -> 再整理 -> 回頭補證據。
    *   人工複查商業數據（如 Clay.com 生成的列表），確認隱私與合規後再進行業務動作。

## 值得注意的限制或風險

1.  **帳號與隱私風險**：
    *   Cookie 是瀏覽器保存登錄狀態的憑證，存在帳號掉登錄、平台改規則、風控攔截的風險。
    *   隱私邊界需自行判斷，不能將所有帳號狀態、權限、私人內容無腦塞入模型。
2.  **國內平台限制**：
    *   B站、小紅書、抖音涉及登錄、評論、帳號狀態、私域內容時，同樣面臨權限與穩定性問題。
3.  **資訊性質誤判**：
    *   X 資訊快速且混亂，適合發現風向，不適合直接當結論。
    *   個人觀點不等於事實，多人吵架不等於產品翻車。
4.  **商業數據風險**：
    *   Clay.com 等工具涉及數據準確性、隱私、合規、打擾他人問題。
    *   必須人工複查，不能將生成的聯繫人列表直接用於群發。
5.  **Token 成本**：
    *   直接處理整頁 HTML 會消耗大量 Token（約 86,000 Token），需透過工具清理資料以降低成本。

## 逐字稿辨識疑點

*   **Hermas**：逐字稿中多次出現，應指代 Hermes，但依規則標為疑點。
*   **Agent Ridge**：逐字稿中出現，疑為 Agent Rich 的聽寫錯誤。
*   **Agent Reach**：逐字稿中出現，疑為 Agent Rich 的聽寫錯誤。
*   **憑震**：逐字稿中描述 Cookie 時使用「憑震」，疑為「憑證」的聽寫錯誤。
*   **Cloud Code**：逐字稿中提及「查過 Cloud Code」，疑為特定產品或聽寫錯誤（可能指 Cloud Code IDE 或泛指雲端代碼，但語境似指 X 上的討論）。
*   **克劳德扣**：逐字稿中提及「看克劳德扣的最近有什麼新進展」，疑為「Claude」或特定產品名稱的聽寫錯誤。
*   **RS**：逐字稿中提及「GitHub, YouTube, RS」，疑為 RSS 的縮寫或聽寫錯誤。
*   **為更多任務**：逐字稿中「先別急著給他為更多任務」，語意不通，疑為「為更多任務」或「為更多任務」的聽寫錯誤。
*   **我先接下來**：逐字稿結尾重複兩次「我先接下來」，語意不明，疑為口誤或聽寫錯誤。

## 可延伸追問

1.  如何具體設定 Hermes 的路由（Routing）邏輯，以確保它能正確區分「線索」與「證據」？
2.  在處理國內平台（B站、小紅書、抖音）時，目前有哪些可行的技術方案可以繞過登錄與風控限制？
3.  對於普通人而言，如何平衡使用 Agent Rich/Reach 帶來的效率提升與隱私洩露風險？
4.  在評估 GitHub 項目時，除了 Readme 和 Issue，還有哪些自動化指標可以用來判斷項目的活躍度與可靠性？
5.  Clay.com 生成的聯繫人數據，具體需要人工複查哪些維度才能確保合規與準確性？