我讓我的 Hermes Agent 速度提升了 10 倍，且無需更換模型

上週我讀到一篇關於 AI 設計出能對抗我們尚未遇到的冠狀病毒疫苗的文章（ScienceDaily）。劍橋大學進行了首次人體試驗，有 39 名志願者接種了該抗原。

想到一個演算法分析了一個病毒的整個基因家族，並設計出針對仍在動物間傳播、伺機感染人類的病毒成員的保護措施，這實在令人難以置信。但當我要求它從一堆文件中找出我最新的簡報時，它卻花費將近兩分鐘的時間在我的個人知識庫中打開錯誤的檔案，最後才顯示出三個月前的舊簡報。

而且我知道劍橋大學使用的是客製訓練的 AI，但我想讓你知道的是，AI 能做到的事與設定讓它能做的事之間的差距，正是決定你工作流程與生產力成敗的關鍵。

直到最近，我都沒有刻意為此建立輔助框架。這些框架是隨著一個資料夾又一個資料夾，意外地堆積在 Agent 周圍，直到它在我自己塑造的混亂中迷失了方向。

所以我花了一天時間記錄每一次失敗的時間，結果發現了一個模式。在這一期的內容中，我會告訴你為什麼你的 Agent 總是在簡單的事情上跌跤，而世界卻稱它為天才，以及解決這個問題並讓它回到你身邊的修復方法。

本文重點：

• 我的資料夾結構讓 Agent 失敗，因為我的資料夾是根據我自己的思考方式組織，而不是根據 Agent 的導航方式
• 在每個主要資料夾的根目錄放一個索引檔案，將緩慢的搜尋變成三十秒就能讀完
• 圍繞在 Agent 周圍的無形輔助框架，比 Agent 自身的能力更重要，以下將說明如何建立它
• 一個五分鐘內就能執行的診斷測試，看看你的資料夾結構是否是真正的問題所在

你的 Agent 看不見的結構

我像大多數人一樣整理我的個人知識庫。文章、研究、素材、策略文件，每個都有自己的資料夾。這樣的結構感覺很清晰，因為我是根據內容類型來思考的。資料夾對應我的分類，我從來不需要考慮去哪裡找。草稿就是文章，筆記就是研究，歸檔系統自動運行。

但 Agent 不是按分類來思考的。當我要求 Hermes 規劃一個產品發布時，這個任務需要從散落在不同資料夾的策略筆記、品牌指南和過往發布資訊中提取。

這些背景資訊在我的內容類型結構中位於不同的地方。我的 Agent 每次都必須到處搜尋，卻不知道哪個草稿是當前的、哪個是歸檔的，也不知道哪個研究筆記是這個月的，還是六個月前的。

以內容類型來組織對人類來說非常完美。你一生都在將事物歸類，你的大腦會自動進行交叉對照。期望 AI 以同樣的方式運作是很自然的，但實際上，Agent 必須手動進行交叉對照，這就是結構失效的地方。

圍繞在 Agent 周圍的結構，比 Agent 自身的能力做了更多的工作。

一旦我看到這個模式，原因就很明顯了：我為一個記得東西放在哪裡的人類大腦建立了個人知識庫，然後把它交給了必須每次都從頭搜尋的 Agent，而這暴露了資料夾混亂背後的真正問題。

搜尋者需要一張地圖，因為沒有它，Agent 就像在黑暗中行走，把每個檔案都當成可能答案。

能力浪費在什麼地方

Hermes 在找到正確檔案之前，會一直打開一堆檔案，或者當前的檔案在其他地方時，它卻去抓取歸檔版本。更糟的是，它會問要用哪個檔案，而答案本該從上下文中就顯而易見。這發生在我使用的每個模型上，包括 Opus、GPT 5.5、Qwen 和 GLM。

這個模式一再重複，我眼睜睜看著同樣緩慢的搜尋在一項又一項任務中上演。

儘管我的 Agent 有能力找到東西，但資料夾結構已經成為它開始實際工作前的主要瓶頸。

我在記錄失敗時間的那天達到了臨界點。我追蹤了 Hermes 在找到正確檔案之前打開了多少檔案，以及花了多久時間。在我改變任何東西之前，五個常見任務看起來是這樣的。

在我改變任何東西之前：

• 查找當前的文章簡報：打開 7 個檔案，花了 2 分鐘才找到正確檔案；
• 查找品牌顏色定義：打開 5 個檔案，花了 1 分 12 秒；
• 查閱用於規劃的文章佇列：打開 4 個檔案，花了 48 秒；
• 查找關於同一主題的先前文章：打開 6 個檔案，花了 1 分 36 秒；
• 提取發布推廣策略：打開 3 個檔案，花了 34 秒。

這是粗略的實驗，所以請將確切數字視為方向性參考。

每個任務都跨越了多個資料夾。大多數任務在找到使用中的版本之前，都先打開了歸檔版本。我的 Agent 將能力浪費在導航上，而不是執行它的工作。一個發布計劃需要三個檔案，而它們分別位於三個不同的資料夾，我眼睜睜看著它錯誤嘗試了三次才找到正確的檔案。

一個會寫文章、寫程式和做規劃的 Agent，不應該花費大部分時間在尋找東西上。

能正常運作的最小框架

每個關注領域一個資料夾，用數字排序，並在根目錄放一個能映射所有內容的 INDEX.md。這就是全部的修正方法，細節則包含在三個互相配合的規則中。

每個主要資料夾根目錄的 INDEX.md 就是一張地圖。它列出了每個子資料夾和標準檔案，以及我的 Agent 應該從哪裡開始。我的 Agent 會先讀取這個檔案，然後在接觸任何其他東西之前就知道裡面有什麼。把它想像成一個軟性的准許關卡，Agent 在知道它要處理什麼之前，不允許開始工作。

重組後，我的品牌資料夾結構看起來像這樣。

105.Brand/
2├── INDEX.md
3├── 01.Brand System/
4├── 02.Editorial Strategy/
5├── 03.Promotion/
6├── 04.Public Deliverables/
7├── 05.Operating Plan/
8└── 06.Archived/

這個結構是按關注領域而不是按內容類型來組織。每個關注領域都有自己的資料夾，所以品牌工作留在品牌工作內，策略工作留在策略工作內。我的 Agent 不會越界去尋找不屬於那裡的東西。

資料夾上的數字讓閱讀順序明確，而不是依賴字母排序。01. Brand System 會在 02. Editorial Strategy 之前被讀取。我的 Agent 不需要猜測。資料夾內部的數字對檔案也起到同樣作用，所以我的 Agent 知道 01. Articles 是起點，然後才是 02. Previous Articles。

我引導資料夾名稱時會加上數字，因為這對我自己來說也比較容易記住。

這就是我完整的 $30 Hermes 設定如何能夠輕鬆地在數十個資料夾中移動，而我的 Agent 卻從不迷路的原因。

歸檔的東西放在 06.Archived 裡，舊的簡報和退役計劃就在那裡待著。我的 Agent 知道除非我特別要求歷史背景，否則不要到那裡去找。這種分離保持了活躍資料夾的整潔和搜尋的速度。

一旦我的 Agent 被告知預設不要越過這個邊界，活躍資料夾內的每個任務都執行得更快了。

我的 INDEX.md 看起來像這樣。

1# Brand Index
2
3此資料夾包含當前的品牌系統。
4
5## 資料夾地圖
6
7| 資料夾 | 用途 | 更新日期 |
8|---|---|---:|
9| `01.Brand System/` | 視覺識別、主題範圍、語調 | 2026-06-11 |
10| `02.Editorial Strategy/` | 文章方向、標題規則、佇列 | 2026-06-11 |
11| `03.Promotion/` | 發布、分發、工具策略 | 2026-06-11 |
12
13## 標準檔案
14
15| 檔案 | 用途 |
16|---|---|
17| `01.Brand System/01. Brand System.md` | 視覺識別、顏色、排版 |
18| `02.Editorial Strategy/01. Articles.md` | 文章佇列、標題規則 |
19
20## 從哪裡開始
21
22-   從 `01.Brand System/04. Direction.md` 開始，了解使命
23-   使用 `02.Editorial Strategy/01. Articles.md` 進行文章選擇

INDEX.md 經歷了三個版本。我的第一個版本列出了品牌資料夾內的每一個檔案，長達四十行。它在技術上很完整，但我的 Agent 每次都得解析它，長度本身就成了額外的開銷。我的第二個版本太短了，大約十五行，我的 Agent 仍然會問我沒有回答到的問題。這第三個版本只列出了子資料夾和標準檔案，並加上一個簡短的「從哪裡開始」部分，告訴我的 Agent 它的起點。

當我要求我的 Agent 提取發布的推廣策略時，它會讀取 05.Brand/INDEX.md，打開 03.Promotion/01. Promotion Strategy.md，然後開始工作。重組後的時間記錄如下。

重組後：

• 查找當前的文章簡報：打開 1 個檔案，花了 10 秒
• 查找品牌顏色定義：打開 3 個檔案，花了 22 秒
• 查閱用於規劃的文章佇列：打開 1 個檔案，花了 10 秒
• 查找關於同一主題的先前文章：打開 2 個檔案，花了 18 秒
• 提取發布推廣策略：打開 1 個檔案，花了 12 秒

最慢的任務從 2 分鐘降到 26 秒，最快的運行時間則大約在 10 秒左右。我的 Agent 打開 INDEX.md，跟著它需要的起點走，然後開始工作，不會亂跑。我的 Agent 端的能力沒有任何改變。資料夾結構在任務開始之前就不再浪費大部分能力了。

資料夾結構就像我建立的一個籠子，它限制了我的 Agent 移動的方式，但沒有限制我的 Agent 能做的事。在籠子內，我的 Agent 自由運行。沒有它，Hermes 就容易亂跑，而我就得浪費時間把它指向正確的檔案。

轉移到 Hermes 讓我能同時跨檔案、跨供應商和跨記憶體建立這種系統，而 INDEX.md 模式是其中最小的一塊，卻在日常工作中帶來了最大的改變。

每個籠子都有一把鎖

我的第一個錯誤是為每個子資料夾都加上 INDEX.md。地圖太多意味著我的 Agent 花時間在閱讀索引上，而不是做正事。我只在主要資料夾（如 Brand 和 Editorial Strategy）的根目錄保留 INDEX.md，因為那裡有足夠多的子資料夾需要地圖。在一個只有四五個檔案的小子資料夾裡，Hermes 可以直接導航，完全不需要地圖。

請記住，當你新增資料夾時，編號會變得繁瑣。我得決定一個新資料夾在序列中的位置，有時我會把它附加在最後面，而不是重新排列所有編號。這沒關係。數字不必完美，只要有方向性就好。完美排序的資料夾不是目標，把這件事當成目標會把一個實用的修正變成一個表面功夫。

更大的錯誤是在你的 Agent 顯示出任何困惑之前就先建立結構。大多數人過度設計他們的 Agent 設定，因為他們認為它需要適當的基礎設施。

我目前的規則遵循與選擇 MCP、CLI 或你自己的工具相同的原則。使用能完成任務的最小介面。只有當你的 Agent 迷路時才加入結構，而且只加入足夠解決該特定問題的結構。

我遇到的另一個失敗是在結構內嵌套結構。我在子資料夾內又加了子資料夾，試圖讓一切完美分類，這把一個兩層的階層結構變成了五層。我的 Agent 接著必須讀取多個 INDEX 檔案並解析多個編號序列才能到達一個檔案。我將這些多餘的層級合併回扁平的子資料夾，導航速度就再次加快了。

深度是快速檔案查找的敵人，而大多數重組增加深度時，都以為那是精確性。

在重組前先衡量

在觸碰任何一個資料夾之前，對你的 Agent 最常處理的三個真實任務進行這個測試。計時每個任務，並記下它在找到正確檔案之前打開了多少檔案。追蹤它選錯檔案或停下來問你要用哪個檔案的頻率。

任何需要你的 Agent 超過三十秒，或打開三個以上錯誤檔案的任務，都指出該任務背後的資料夾有問題。

選擇最常發生的一次失敗。打開那個資料夾，寫一個 INDEX.md，列出每個子資料夾和重要檔案，以及你的 Agent 應該從哪裡開始。儲存它。再次執行同樣的任務。

如果你的 Agent 在三十秒內找到正確的檔案，那麼修復就成功了，你現在也知道了這個模式。將其應用於下一個有問題的資料夾。如果仍然失敗，那麼問題可能出在編號或每個資料夾一個關注領域上，這是接下來要修復的兩件事。

從那個浪費最多時間的資料夾開始，修復它，準備好了再移到下一個。

欄杆仍然彎曲的地方

歸檔的內容有時仍然會被參考，當我需要一個舊的簡報作為背景時。我的 Agent 必須知道要去 06.Archived 而不是活躍資料夾找，我會在 INDEX.md 中提到這一點，讓它知道歷史資料在哪裡。如果沒有這個註記，我的 Agent 會假設歸檔內容不存在。

此外，Obsidian Sync 有時會在跨裝置同步不完整時產生問題。如果我在筆記型電腦上更新了一個檔案，但舊版本仍然留在我的 VPS 上，Hermes 會載入 VPS 上的副本，並將其視為當前的真實來源。這與其說是資料夾結構的問題，不如說是同步問題，但它會發生在資料夾系統內，因為 Agent 只看到它面前的那些檔案。

當你有太多資料夾，導致序列變得毫無意義時，編號就會失效。當一個層級上的編號項目超過十到十二個時，數字就開始變得任意了。我試著將主要類別保持在這個門檻以下，並將更深的結構嵌套在內部，而不是擴充頂層。

重新命名是另一個摩擦來源。當我重組時，有時會重新命名資料夾以更好地符合其用途，而任何對舊名稱的 INDEX.md 參考都會在更新前失效。我現在試著一次設定好資料夾名稱就不再更動，因為一個稍微不那麼完美的名稱比一個斷裂的參考來得代價更低。

這個結構最適合內容密集型的工作流程和規劃密集型的工作流程。純程式碼或數據密集型的設定可能需要完全不同的組織原則，而 INDEX.md 模式無法解決所有的導航問題。

我在這篇文章中寫的所有內容都追溯到一個直覺：掌控那個重要的層級。我建立我的技術棧，這樣就沒有任何公司能控制我的工具。我建立我的個人知識庫，這樣就沒有混亂能控制我的 Agent。同樣的原則，從供應商到資料夾，再到未來的一切。

當圍繞著能力的輔助框架出現問題時，能力本身是廉價的。建立輔助框架，能力自然會發揮作用。一個索引檔案和資料夾名稱前的幾個數字，就是一個迷路的 Agent 和一個有效工作的 Agent 之間的差別。

如果這篇文章對你有幫助，歡迎關注 @wandermist 以獲取更多類似內容！