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

一句話總結

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

核心重點

主語差異決定產品定位：

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

四大維度比較：

• 記憶機制：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，並進行反思與技能沉淀）。

選擇建議：

• 若需完成具體程式碼工程，選 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 操作流程（執行層）

初始化：選擇目錄或建立空白專案（Workspace/Repo）。

接收需求：讀取 Repo，理解 Prompt。

規劃與執行：規劃任務 -> 改碼 -> 執行編輯/測試。

交付：提交變更（PR/MR）。

結束：任務完成即結束（任務制生命週期）。

Hermes 操作流程（編排層）

理解用戶：讀取 User.md, Memory.md, System.md。

匹配目標：理解用戶意圖與當前狀態。

調用工具：調用內置 Tools/MCP/Skills（如聊天、查航班、訂票、寫代碼、產品方案討論）。

委派任務：若涉及程式碼工程，可委派任務給 Codex。

執行與反思：執行任務 -> 反思結果。

沉淀與成長：沉淀 Skill 或更新記憶（User.md/Memory.md），實現長期陪伴。

值得注意的限制或風險

模擬的局限性：

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

渠道限制：

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

記憶機制的差異：

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

逐字稿辨識疑點

GPT-5.5：

• 講者提到「因為我自己用的是這個模型比較多」。目前公開市場常見版本為 GPT-4 系列或 GPT-4o，「GPT-5.5」可能為口誤、聽寫錯誤或特定內部/未公開版本名稱，需查證。

Hermes 的具體產品定義：

• 講者將 Hermes 描述為具有多平台接入、個人記憶、包工頭角色的 Agent。若 Hermes 指代特定現有產品（如某些開源項目或特定公司產品），其功能描述與主流認知可能有差異，需確認該 Hermes 具體指哪一個產品實體。

Codex 的 Memory 機制描述：

• 講者提到 Codex 早期沒有 Memory，後來引入，且主要為 Task Memory。這與部分開發者對 Codex 實際行為的感知可能存在差異，屬講者個人觀察視角。

可延伸追問

GPT-5.5 的具體指涉：講者所指的「GPT-5.5」究竟是哪個模型？是否為內部版本或口誤？

Hermes 的產品實體確認：影片中所指的 Hermes 具體是哪個產品？是否有官方文檔或開源項目對應？

Codex 模擬 Hermes 的社區方案細節：是否有具體的開源項目或文檔展示如何在 Codex 上實現 Hermes 的功能？

Hermes 的隱私保護機制：由於 Hermes 涉及大量個人生活記憶（User.md/Memory.md），其數據隱私保護機制為何？

Codex 與 Hermes 的協作案例：是否有實際案例展示 Hermes 如何有效委派任務給 Codex，並處理後續結果？