# 影片筆記：你在纠结选 Codex 还是 Hermes？这个问题本身就问错了

## 一句話總結

Codex 與 Hermes 並非互斥的競爭關係，而是解決不同層面問題的工具：Codex 以「專案/程式碼庫」為主語，專注於工程導向的執行層任務；Hermes 以「人」為主語，專注於個人導向的編排層長期陪伴與成長。選擇的關鍵在於需求是具體的程式碼交付，還是生活與工作的智能助手。

## 核心重點

1.  **主語差異決定產品定位**：
    *   **Codex**：主語是 Workspace/Repo（專案/程式碼庫）。它必須選擇目錄或建立空白專案作為根據地，以專案為中心。
    *   **Hermes**：主語是「人」（User）。雖然有 Workspace，但存在感較低，以人為焦點，Slogan 為「與你一起成長的 Agent」。

2.  **四大維度比較**：
    *   **記憶機制**：Codex 為 Task Memory（任務記憶，關注專案規範與工程偏好）；Hermes 為 Human Memory（人類記憶，關注個人生活、習慣與狀態）。
    *   **生命週期**：Codex 為任務制（做完即走，如 Issue -> Feature -> PR -> 結束）；Hermes 為長期陪伴（持續學習，更新 User.md/Memory.md，越用越了解用戶）。
    *   **渠道入口**：Codex 限於 IDE、CLI 或專屬 App 等開發環境；Hermes 支援多平台（Telegram, Discord, 微信, 企微等），強調跨渠道的上下文延續。
    *   **抽象層級**：Codex 位於執行層（專注寫碼、測試、提交）；Hermes 位於編排層（包工頭角色，可委派任務給 Codex，並進行反思與技能沉淀）。

3.  **選擇建議**：
    *   若需完成具體程式碼工程，選 Codex。
    *   若需生活與工作管理的智能助手（Jarvis 類），選 Hermes。
    *   兩者架構設計初衷不同，硬行模擬對方會違背產品設計初衷。

## 詳細大綱

### 一、 前言：釐清問題前提
*   回應觀眾提問：Codex 與 Hermes 該如何選擇？
*   核心觀點：先問「是不是」，再問「為什麼」。
*   兩者雖都是 Agent，但並非同級選項，也不互相取代。
*   講者立場：它們解決不同層面的問題，不衝突，無需 All in 單一產品。

### 二、 根本區別：主語（Subject）的不同
*   **Codex 的主語**：
    *   關注點在 Workspace 或 Repo。
    *   必須選擇目錄或建立空白專案作為根據地。
    *   以專案為中心。
*   **Hermes 的主語**：
    *   關注點在「你」（User）。
    *   雖然有 Workspace，但存在感較低。
    *   以人為焦點，Slogan 為「Agent that grows with you」（與你一起成長的 Agent）。
    *   Repo 只是 Hermes 操作的一部分，而非全部。

### 三、 四個維度的微觀區別

#### 1. 記憶能力（Memory）的關注點
*   **Codex (Task Memory)**：
    *   以任務為主，意圖通常是編寫程式碼。
    *   記憶內容與專案強相關：框架、跑法、代碼規範、錯誤處理、Git commit 規範、技術約束（如 go-zero, RPC proto）。
    *   屬於工程偏好，與「人」本身的關係不大。
*   **Hermes (Human Memory)**：
    *   以人為主要關注點。
    *   記憶內容包含：研究興趣、生活煩惱、主副業、維護的產品、生活習慣（起床、用餐、健身時間）、興趣愛好（唱歌、健身）。
    *   範圍更廣，回到人本身。

#### 2. 生命週期（Lifecycle）
*   **Codex**：
    *   任務制生命週期。
    *   流程：接收需求單 (Issue) -> 開發 Feature/Fix -> 提 PR/MR -> 結束。
    *   專注於完成單一任務，做完即結束。
*   **Hermes**：
    *   長期陪伴。
    *   自動沉淀 Skill 或經驗，更新 User.md 或 Memory.md。
    *   越用越了解用戶，實現「Grows with you」。
    *   講者註記：Codex 也有 Memory 機制，但與 Hermes 的「成長」概念不同。

#### 3. 渠道入口（Channel Entry）
*   **Codex**：
    *   官方希望用戶在專屬環境使用。
    *   入口：IDE 插件、CLI、專屬 App、手機版 Codex App。
    *   不鼓勵在微信、Facebook 等非開發環境使用。
*   **Hermes**：
    *   官方支持多平台消息渠道。
    *   入口：Telegram, Discord, Facebook, 微信, 釘釘, 企微等。
    *   跨渠道溝通，所有渠道的消息上下文都能沉淀並回顧。
    *   官方立場：希望連接用戶，因為用戶才是主角。

#### 4. 抽象層級（Abstraction Level）
*   **Codex**：
    *   執行層（Execution Layer）。
    *   以 Repo 為單元，專注代碼工程。
    *   流程：讀取 Repo -> 理解 Prompt -> 規劃 -> 改碼 -> 執行編輯/測試 -> 提交變更。
    *   核心：完成工程任務交付閉環。
*   **Hermes**：
    *   編排層（Orchestration Layer）。
    *   角色：包工頭（Supervisor）。
    *   功能：理解人 -> 匹配目標 -> 調用工具（聊天、查航班、訂票、寫代碼、產品方案討論）。
    *   流程：理解用戶 (User.md, Memory.md, System.md) -> 調用內置 Tools/MCP/Skills -> 委派任務（如委派給 Codex）-> 執行 -> 反思 -> 沉淀 Skill 或更新記憶。
    *   核心：個人代理閉環，自學習。

### 四、 關於模擬與產品初衷
*   **Codex 模擬 Hermes**：
    *   理論上可行（加基礎設施、接 MCP/SDK、定時任務、寫編排邏輯）。
    *   社區有人嘗試，但與產品初衷對抗。
    *   官方不太可能支持第三方渠道（如飛書、微信）直接調用 Codex，多為社區方案。
*   **Hermes 模擬 Codex**：
    *   同樣無法完善，因為架構設計服務於不同目的。
*   **本質差異**：
    *   差異不在底層模型（如 GPT-5.5），而在 Agent 層（記憶、上下文、工具鏈）。

### 五、 選擇建議
*   **選擇 Codex**：
    *   目標：把代碼工程或具體任務做好。
    *   適用：需要具體的工程交付閉環。
*   **選擇 Hermes**：
    *   目標：需要像 Jarvis 這樣的智能助手。
    *   適用：生活助手（健康提醒、健身總結、心理健康）、項目管理、推薦內容（書、音樂、電影）。
    *   講者主觀偏好：看好 Hermes 未來的發展，因為它更懂人且想象力更大。
*   **總結**：
    *   它們不是競品，而是不同賽道的 Agent。
    *   每個大廠小廠都有自己的 Agent，兩者同時存在且有各自合適的場景。

## 工具 / 模型 / 名詞整理

*   **AI 模型/產品**：
    *   Codex
    *   Hermes
    *   Claude Code
    *   OpenCode
    *   Gemini
    *   DeepSeek
    *   GPT-5.5（講者提及自己較多使用的模型）
    *   豆包
    *   混元（騰訊）
*   **開發工具/環境**：
    *   IDE（集成開發環境）
    *   CLI（命令列介面）
    *   App（應用程式）
    *   MCP（Model Context Protocol）
    *   SDK（開發工具包）
    *   Repo（程式碼倉庫）
    *   Workspace（工作區）
    *   Git
    *   go-zero
    *   RPC（遠端過程呼叫）
    *   proto（協議緩衝區）
    *   CSS（層疊樣式表）
*   **開發流程/術語**：
    *   Issue（需求單/問題單）
    *   Feature（功能）
    *   Fix（修復）
    *   PR (Pull Request)
    *   MR (Merge Request)
    *   User.md
    *   Memory.md
    *   System.md
    *   Skill（技能）
*   **其他**：
    *   Jarvis（智能助手範例）
    *   知識星球（講者社群）
    *   微信
    *   飛書
    *   Telegram
    *   Discord
    *   Facebook
    *   釘釘
    *   企微（企業微信）

## 操作流程整理

### Codex 操作流程（執行層）
1.  **初始化**：選擇目錄或建立空白專案（Workspace/Repo）。
2.  **接收需求**：讀取 Repo，理解 Prompt。
3.  **規劃與執行**：規劃任務 -> 改碼 -> 執行編輯/測試。
4.  **交付**：提交變更（PR/MR）。
5.  **結束**：任務完成即結束（任務制生命週期）。

### Hermes 操作流程（編排層）
1.  **理解用戶**：讀取 User.md, Memory.md, System.md。
2.  **匹配目標**：理解用戶意圖與當前狀態。
3.  **調用工具**：調用內置 Tools/MCP/Skills（如聊天、查航班、訂票、寫代碼、產品方案討論）。
4.  **委派任務**：若涉及程式碼工程，可委派任務給 Codex。
5.  **執行與反思**：執行任務 -> 反思結果。
6.  **沉淀與成長**：沉淀 Skill 或更新記憶（User.md/Memory.md），實現長期陪伴。

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

1.  **模擬的局限性**：
    *   Codex 模擬 Hermes 或 Hermes 模擬 Codex 在理論上可行（透過加基礎設施、接 MCP/SDK、定時任務、寫編排邏輯），但會與產品初衷對抗。
    *   官方不太可能支持第三方渠道（如飛書、微信）直接調用 Codex，多為社區方案。
    *   硬行模擬對方會違背產品設計初衷，無法完善。

2.  **渠道限制**：
    *   Codex 官方不鼓勵在微信、Facebook 等非開發環境使用，限制於 IDE、CLI 或專屬 App。
    *   Hermes 支援多平台，但需確認各平台功能的完整性。

3.  **記憶機制的差異**：
    *   Codex 的 Memory 主要為 Task Memory，與專案強相關，與「人」本身的關係不大。
    *   Hermes 的 Human Memory 範圍廣，包含生活習慣、興趣等，但需確認其長期記憶的準確性與隱私處理。

## 逐字稿辨識疑點

1.  **GPT-5.5**：
    *   講者提到「因為我自己用的是這個模型比較多」。目前公開市場常見版本為 GPT-4 系列或 GPT-4o，「GPT-5.5」可能為口誤、聽寫錯誤或特定內部/未公開版本名稱，需查證。
2.  **Hermes 的具體產品定義**：
    *   講者將 Hermes 描述為具有多平台接入、個人記憶、包工頭角色的 Agent。若 Hermes 指代特定現有產品（如某些開源項目或特定公司產品），其功能描述與主流認知可能有差異，需確認該 Hermes 具體指哪一個產品實體。
3.  **Codex 的 Memory 機制描述**：
    *   講者提到 Codex 早期沒有 Memory，後來引入，且主要為 Task Memory。這與部分開發者對 Codex 實際行為的感知可能存在差異，屬講者個人觀察視角。

## 可延伸追問

1.  **GPT-5.5 的具體指涉**：講者所指的「GPT-5.5」究竟是哪個模型？是否為內部版本或口誤？
2.  **Hermes 的產品實體確認**：影片中所指的 Hermes 具體是哪個產品？是否有官方文檔或開源項目對應？
3.  **Codex 模擬 Hermes 的社區方案細節**：是否有具體的開源項目或文檔展示如何在 Codex 上實現 Hermes 的功能？
4.  **Hermes 的隱私保護機制**：由於 Hermes 涉及大量個人生活記憶（User.md/Memory.md），其數據隱私保護機制為何？
5.  **Codex 與 Hermes 的協作案例**：是否有實際案例展示 Hermes 如何有效委派任務給 Codex，並處理後續結果？