Karpathy 風格知識堆疊：為什麼我將 Hermes、MiniMax M3 與 Obsidian 作為核心

大多數人把筆記、模型和 Agent 視為三個獨立的世界

這個技術棧將它們融合成一個回饋迴圈：

Obsidian 作為你的記憶，Hermes 作為你的 Agent，MiniMax M3 作為推理核心

為什麼「知識棧」比「筆記 App」更勝一籌

傳統的 PKM 系統通常會在三種情況下失效：

• 筆記寫完一次就不再更新
• AI 對話雖然聰明，但總是失憶——每次對話都從零開始
• 重要工作的上下文總是超出你的 RAM（無論是你的大腦還是模型的）

我們真正想要的是：

• 一個本地、可連結的知識圖譜，涵蓋我們所知的一切
• 一個存在於該圖譜內部而非之上的 Agent
• 一個能處理大量真實上下文的前沿模型，而不只是 2-3 個段落

Hermes + MiniMax M3 + Obsidian 正是為你提供這些：

• Obsidian - 具有反向連結、圖譜視圖和專為個人知識庫設計的插件生態系的本地 Markdown 圖譜
• Hermes Agent - 一個自我改進的開源 Agent，具有內建的學習迴圈、工具和能在你自身基礎設施上運行的長期任務
• MiniMax M3 - 我每天在 Hermes 內部實際運行的模型。它具有長上下文、多模態和 Agent 特性，我選擇它是因為我想要一個能讀取我的整個知識庫、日誌和一堆新的原始文章的模型，所有這些都在一個上下文視窗內——而無需我拼湊一個 RAG 管道來實現。經過幾個月的實際使用，它一直是我的預設模型。更多原因將在下面說明

結果感覺不像是在「使用 LLM」，更像是在慢慢訓練一個第二個大腦

為什麼我選擇 M3（以及我注意到的幾點）

我不是因為某個基準測試選擇 M3 的

我選擇它是因為 2025 年我嘗試過的其他所有模型，在我的工作流程中都有相同的失敗模式：

它能夠很好地總結單一筆記，但當我要求它讀取十篇筆記、將它們與我的 MOC 交叉比對，並寫回一篇新筆記時，它就會迷失方向

症狀總是相似的：

• 摘要局部連貫，但整體理解錯誤
• 它引用了一個實際上不在檔案中的專案
• 它使用了來自不同分類法的標籤
• 它憑空編造了一個指向不存在頁面的 WikiLink

模型很聰明，但工作流程超出了模型的處理能力

M3 是我嘗試的第一個，其中整個圖譜都能放入上下文，並在整個任務過程中保持穩定

在實際使用中，有三點特別突出：

1. 它確實能使用我的分類法，我有一個包含約 41 個標籤的固定架構（#coin/\, [#project](https://x.com/search?q=%23project&src=hashtag_click)/\, #concept/*, #solana 內部, #meta）。當我要求 M3 整理一篇新筆記時，它第一次嘗試就能選中正確的主要標籤，成功率約為 90%。

使用 200K 上下文的模型時，我的成功率大約是 60%。差別在於 M3 可以一次看到整個標籤的樣貌並進行推理，而不是根據少數範例來猜測。

1. 它不會在長時間的 Agent 迴圈中失去連貫性，一次完整的知識庫檢查需要 30 多次工具呼叫：讀取 MOC、追蹤 WikiLink、統計標籤、掃描重複項、寫報告。

大多數模型在呼叫大約 8-9 次後開始偏離。

M3 能從頭到尾保持連貫。這是我停止每隔 20 分鐘就切換到一個新對話視窗的最大原因。

1. 它將前向引用視為一種功能，當我要求它整理一篇筆記時，如果某個概念尚未建立，M3 仍會寫下前向引用。

Obsidian 會將其呈現為灰色連結。我會在每週檢查中處理這些灰色連結。

這比一個要麼憑空編造筆記、要麼完全跳過連結的模型要好得多。

經過幾個月的使用，有三個誠實的提醒：

• 首次呼叫延遲較高。 Hermes 需要預載入上下文。不要因為 M3 最初幾秒的反應就對它下定論——給它 10 秒鐘。
• 它會很有自信地寫出指向不存在頁面的 [[wikilink]]。 這就是上述的「前向引用」行為。只有當你跳過每週檢查時，這才會成為問題。
• 多模態功能是真實的，但對於圖表密集的 PDF，我仍然會先使用專門的視覺工具。 M3 可以很好地讀取圖像和簡短截圖中的文字。但對於包含圖表的完整頁面，它不是合適的工具。

以上就是我的全部論點。

這個模型恰好擅長知識庫工作流程所需的事情：一次性讀取整個圖譜，並在不損失結構的情況下寫回其中。

第一層 – Obsidian 作為事實來源

Obsidian 是這個技術棧中不起眼但至關重要的基礎層

• 你的知識以純文字 Markdown 檔案形式儲存在磁碟上，而不是鎖定在他人的雲端服務中
• 反向連結、圖譜檢視和每日筆記有助於將想法整合成簇，而不是在聊天記錄中消失
• 插件將 Obsidian 轉變為一個可程式化的文件、任務和資料集圖譜，Agent 可以系統性地遍歷

原則很簡單：

如果有值得保留的內容，它應該首先存在於 Obsidian 中 如果 Agent 做了有用的事情，它最終應該變成一篇筆記

一個實用的結構：

1/obsidian-vault
2  /inbox
3  /people
4  /projects
5  /research
6    ai-agents.md
7    minimax-m3-benchmarks.md
8  /ai
9    hermes-playbook.md
10    agents-ideas.md

Hermes 會讀取、重構和建立這些筆記——但知識庫仍然是事實的來源

第二層 – Hermes 作為自我改進的操作者

這是技術棧從「一個帶有 LLM 的筆記系統」轉變為基礎架構的地方

Hermes Agent 是由 @NousResearch 建立的一個自我改進的 AI Agent

它能持續維護關於你和你的工作的模型，從經驗中創造技能，在使用過程中改進它們，並搜尋自己過去的對話來回憶相關上下文，而不是在每次對話中重置

你可以透過兩種主要方式運行 Hermes：

• 作為 Linux、macOS 或 WSL2 上的 CLI 工具
• 透過 Hermes Desktop - 一個適用於 macOS、Windows 和 Linux 的原生應用程式，它將相同的 Agent 核心包裝在 GUI 中

安裝路徑

macOS / Linux / WSL2 (CLI)

這一行命令會安裝 Hermes Agent、設定環境，並暴露全局的 hermes 命令

1curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

安裝後：

1source ~/.bashrc 2>/dev/null || true
2source ~/.zshrc 2>/dev/null || true
3hermes

Windows PowerShell (CLI)

1irm https://hermes-agent.nousresearch.com/install.ps1 | iex

Windows 安裝程式會處理 Python 3.11、Node.js 22、ripgrep、ffmpeg 和可攜式 Git Bash，然後將 hermes 加入你的 PATH

Hermes Desktop (GUI)

如果你不想在終端機中工作，請下載 Hermes Desktop 從官方桌面頁面下載，並為 macOS、Windows 或 Linux 運行原生安裝程式。

• 當你想要一個原生 GUI 而不是純 CLI 設定、更簡單的上手流程，以及無需手動 shell 引導即可使用的相同 Hermes 核心時，請使用 Desktop
• 當你想要可重現性、腳本化、遠端伺服器/VPS 部署，以及對工具、環境變數和長時間運行工作流程的精細控制時，請使用 CLI

大多數人會同時使用兩者：Desktop 用於日常互動，CLI 用於設定、自動化和遠端工作

架構 – 技術棧實際上是如何組合在一起的

清晰的思維模型：

1Obsidian Vault
2   ↓
3Hermes Agent
4   ↓
5MiniMax M3
6   ↓
7Updated notes, summaries, skills, scheduled jobs

每一層都有其明確的工作：

• Obsidian 將筆記儲存為 Markdown 檔案，這使得它們易於索引、搜尋、差異比對和版本控制
• Hermes 是編排層——它讀取檔案、運行工具、記住先前的工作、排程任務，並決定何時持久化有用的內容。它還可以連接到訊息平台和閘道
• MiniMax M3 是這個技術棧中的推理引擎。它可以讀取大量的筆記集合、改寫雜亂的筆記、比較整個知識庫中的文件，並處理長時間運行的 Agent 任務，而不會在 20 次工具呼叫後忘記上下文頂部的內容
• 在我的工作流程中，最後一點是關鍵：一次完整的知識庫檢查、一次跨 MOC 重構，或一個 30 次呼叫的「將這篇文章整理成一篇 5 個部分的筆記並更新 3 個 MOC」任務，都能從頭到尾保持連貫
• 「MSA 架構」的說法更像是行銷宣傳。實際體驗是：我可以執行一個任務 20 分鐘，而模型仍然記得我在第 1 分鐘要求它做什麼

Hermes 並非取代 Obsidian。它位於你的知識庫和模型之間，將知識庫轉化為可操作的東西

一個實際的循環：

• 你在 Obsidian 中記錄原始想法
• Hermes 讀取整個知識庫或特定資料夾
• Hermes 將相關的筆記集發送給 MiniMax M3
• M3 重構、添加標籤、建立連結、總結或擴展這些材料
• Hermes 將結果以乾淨的 Markdown 格式寫回知識庫

這個循環——而不是一次性對話——才是真正的產品

實際設定 – 將 Hermes 連接到你的知識庫

將你的 Obsidian 知識庫放在一個正常的檔案系統路徑中，並將該路徑暴露給 Hermes。

macOS / Linux

1export OBSIDIAN_VAULT="$HOME/Documents/Obsidian/MainVault"
2ls "$OBSIDIAN_VAULT"

Windows PowerShell

1$env:OBSIDIAN_VAULT="$HOME\Documents\Obsidian\MainVault"
2Get-ChildItem $env:OBSIDIAN_VAULT

現在運行 Hermes 設定精靈：

1hermes setup

或者，透過 Nous Portal 使用最短路徑（自動提供者、工具閘道等）：

1hermes setup --portal

官方文件建議使用 hermes setup 作為主要的上手命令，並使用 --portal 作為帳戶和提供者相關配置的快捷方式

然後驗證安裝：

1hermes doctor

hermes doctor 會檢查依賴項、PATH、提供者配置，並在你開始配置模型和工具之前標記常見問題

模型層 – 將 Hermes 連接到 MiniMax M3

Hermes 將「使用哪個模型」視為一級配置，而不是一個硬編碼的假設。

你可以使用 Hermes 本身來選擇和更新模型，而不是手動編輯配置文件。

主要命令：

1hermes model

這將打開一個模型選擇流程，Hermes 會列出支援的提供者和模型，並讓你選擇能夠暴露 MiniMax M3 的後端

實際設定路徑：

1. 安裝 Hermes（CLI 或 Desktop）
2. 運行 hermes setup 或 hermes setup --portal
3. 運行 hermes model
4. 選擇能讓你存取 MiniMax M3 的提供者路徑
5. 將其儲存為你的預設長上下文模型

如果你已經知道你的環境變數和提供者格式，你也可以使用以下命令設定特定值：

1hermes config set

文件稱 hermes config set 是無需手動編輯文件即可寫入單個配置值的支援方法。

在我的日常設定中，對於任何我原本需要拆分為多次模型呼叫的事情，M3 都是預設模型。具體來說：

• 讀取包含大量筆記的資料夾，答案取決於整個圖譜，而不是任何單一檔案
• 合併重複或重疊的筆記——這是一個圖譜問題，而不是文字問題
• 以我自己的語氣撰寫結構化摘要和概述（5 部分模板、41 標籤分類法）
• 長時間的研究鏈，上下文不斷增長——「整理，然後更新 3 個 MOC，然後寫 3 個推文思路」這類開放式任務
• 程式碼密集型、多步驟的 Agent 任務，模型需要記住自己超過 20 次呼叫的工具使用歷史

我在 Hermes 中保留一個小型快速模型，用於微小的實用操作（重新命名檔案、尋找字串、格式化 YAML）。

對於以上所有情況——使用 M3。大致劃分是：便宜模型用於機械性任務，M3 用於推理任務。幾週後，這種路由方式就會變得習以為常。

經驗法則：

使用快速、便宜的模型執行微小的實用操作。使用 MiniMax M3 處理任何依賴於大上下文、結構或長時間推理的事情。這才是技術棧變得明顯優於標準聊天的地方

工作模式 – 能夠真正擴展的資料夾

如果你想讓這個系統對真實用戶有效，知識庫的結構至關重要。

一個實用的佈局：

1MainVault/
2  Inbox/
3  Projects/
4  People/
5  Reading/
6  Daily/
7  Reviews/
8  AI/
9    Hermes/
10    MiniMax/

為什麼這樣有效：

• Inbox/ 用於捕獲原始想法和粗略的傾倒
• Daily/ 用於低摩擦的日常記錄
• Reading/ 存放來源筆記、重點摘錄和引言
• Projects/ 儲存持久化的輸出和進行中的工作
• Reviews/ 儲存每週和每月的綜合摘要

當每個資料夾都有明確的職責時，Hermes 表現最佳。如果你的知識庫混亂不堪，Hermes 仍然會有幫助，但它將花費更多時間來解讀混亂，而不是改進它

一個簡單的操作規則：

• 人類可以自由地在 Inbox/、Daily/ 和 Reading/ 中寫作
• 允許 Hermes 將摘要寫入 Projects/、Reviews/ 和像 AI/ 這樣的專題資料夾
• 長期筆記存放在穩定、可預測的資料夾中

這為 Agent 提供了權限邊界，即使你從未在 YAML 中將其正式化。

真正值得自動化的工作

最強大的 Hermes 用例不是「回答一個問題」- 而是重複發生的轉換工作，

具體例子：

• 將昨天的每日筆記轉換為結構化摘要
• 將 10 篇粗略的閱讀筆記合併為一篇常青筆記
• 從一個專案資料夾中提取開放性問題
• 從分散的筆記中構建一份週回顧
• 比較當前筆記和舊筆記，並標註觀點的變化

這就是 MiniMax M3 大放異彩的地方。

一個標準的短上下文模型可以很好地總結單一筆記。

M3 可以總結一個包含 50 篇筆記的資料夾，將它們與我知識庫中的 10 個 MOC 交叉比對，並提出一篇 1000 字的概述，該概述實際上使用了我的個人語氣和標籤——因為它看到了整個圖譜。

我最常運行的工作： 將一篇新文章放入 raw/，要求 M3 將其整理為一篇 5 個部分的筆記（# Profile → # 我研究中的 Context → # Links into vault → # Tags → # Related），然後觀察它：

• 從我的 41 個標籤分類法中正確選中一個標籤，
• 寫入 8-12 個指向現有筆記的 WikiLink，
• 告訴我哪個 MOC 需要更新。

使用 200K 模型時，這 4 個步驟中我可能只能得到大約 3 個正確 使用 M3，我可以在一次處理中全部得到 4 個，即使知識庫中有大約 500 個檔案

複合效應：我每次以這種風格整理的筆記都會成為 M3 回答下一個問題時的上下文的一部分。

在連續 6 個月每週整理之後，模型就「知道」了我的語氣、我的標籤系統，以及我為哪類工作更新哪些 MOC——而我無需重新訓練任何東西。

一個來自終端的典型流程：

1hermes

然後，在 Hermes 內部，你可以要求執行如下任務：

• 「讀取 Reading/AI Agents/ 中的所有內容，並建立一篇名為 agent-architecture-overview.md 的綜合筆記」
• 「掃描 Daily/ 過去 7 天的內容，並將一份週回顧寫入 Reviews/2026-W24.md」
• 「找出 Inbox/ 和 Projects/ 中的重複想法，並提出合併建議」

具體的措辭可以靈活變通，但核心思想是：每個任務都映射到真實的資料夾，並產生真實的 Markdown 輸出

排程和無人值守工作

Hermes 不僅僅為對話而構建，它還為閘道、排程器和後台執行而構建

這一點很重要，因為最好的 PKM 工作流程通常是異步的，而不是臨時的。

有用的排程任務：

• 每天早上 08:00 - 總結昨天的筆記，並將每日摘要寫入 Reviews/
• 每週五 - 從 Daily/ 和 Projects/ 中生成一份週回顧
• 每天一次 - 掃描孤兒筆記和結構性問題
• 每晚 - 將新的閱讀重點摘錄轉化為原子筆記並建立連結

這種架構轉變是巨大的：

• 對話的答案會消失
• 定期的筆記維護會產生複合效應

隨著時間的推移，這種複合效應正是將「只是些筆記」轉變為真正的第二個大腦的關鍵

完整的實際路徑，從頭到尾

1. 安裝 Hermes

macOS / Linux / WSL2：

1curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

Windows：

1irm https://hermes-agent.nousresearch.com/install.ps1 | iex

桌面版：

• 從官方桌面頁面下載 Hermes Desktop，並為 macOS、Windows 或 Linux 運行原生安裝程式。

2. 配置 Agent

1hermes setup
2# or
3hermes setup --portal

3. 驗證健康狀態

1hermes doctor

4. 選擇你的模型

1hermes model

選擇能夠暴露 MiniMax M3 的提供者路徑，並將其儲存為長上下文工作的預設模型。

5. 啟動 Hermes 並讓它成為現實

1hermes

在這一點上，有用的第一步不是「寫程式碼」。而是：

• 將 Hermes 指向你的知識庫
• 給它一個特定的資料夾
• 要求它產出一個乾淨的 Markdown 製品
• 在 Obsidian 中打開它並檢查結果
• 反覆迭代，直到這個工作流程變得無聊且可靠

一旦一個循環感覺穩固了，再添加另一個 -> 然後再添加另一個。

這就是你將 Hermes + MiniMax M3 + Obsidian 從一個酷炫的想法轉變為實際基礎架構的方法

如果你覺得這篇文章有幫助：

• 將這篇文章加入書籤。相關連結會變動，每週都會有新的倉庫出現——你會需要它作為參考
• 按讚並轉發上面的推文串，幫助其他開發者跳出聊天機器人的陷阱
• 想每週深入探討 AI 架構、量化交易和 Agent 經濟。請追蹤我：@polydao
• 加入 TG 頻道：Buzzoni Notes - 我在這裡分享我的原始提示、自定義技能，以及對 X 來說還太早期的 Alpha 資訊

不要只是閱讀它。去建構它。從今天開始改變你的工作流程