# 策展 · X (Twitter) 🔥🔥🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Vectorize (@Vectorizeio) · 平台：X (Twitter) · 日期：2026-05-26

> 原始來源：https://x.com/Vectorizeio/status/2058896248011165888

## 中文摘要

# 打造一個能記住你程式庫的 Hermes 程式開發助手

每一次的 AI 程式開發工作階段（session）都是從零開始。

你打開一個新的聊天視窗，貼上 context、你的技術堆疊（stack）、你的開發慣例、上週做的架構決策，還有三月份花了兩天才修好的那個臭蟲（bug）。然後下一個工作階段，你又得重來一次。再下一個也是。問題不在於 AI 程式開發工具寫程式的能力不好，而在於它們對你的程式庫（codebase）毫無記憶。

搭載 Hindsight 的 Hermes Agent 是個例外。每一個工作階段都會增加它對你專案的了解。到了第 20 個工作階段，Hermes 已經知道你的模組邊界、命名慣例、已知的脆弱區域，以及那個反覆出現的驗證（auth）問題的根本原因。你不再需要解釋，因為它已經「知道」了。

這篇文章將介紹 Hermes 實際上從程式開發工作階段中提取了什麼、如何在兩分鐘內完成設定，以及三個能讓持久化程式庫記憶發揮最大效益的工作流程。

## Hermes 對你的程式庫記住了什麼

Hermes 並不儲存對話紀錄。Hindsight 提取並保留的是「事實」——從你的對話中提取出來的、原子的、可檢索的知識片段。

在一個典型的程式開發工作階段後，像這樣的資訊會自動進入記憶：

- 「專案使用 ESM 模組而非 CommonJS，匯入（import）時請務必使用 .js 副檔名」

- 「驗證中間件（middleware）在重新整理權杖（refresh token）過期時會靜默失敗，這是截至 3 月 14 日已知的問題」

- 「經過 2 月份的效能測試後，已移除 SQLAlchemy 並改用原始的 asyncpg」

- 「團隊慣例：所有非同步處理器（async handlers）都必須用 handle_errors() 裝飾器包覆」

這些都不需要你明確地告訴 Hermes 要記住它們。Hindsight 的寫入管線會從你工作階段的自然流動中提取這些資訊，無論是你提出的問題、描述的臭蟲，還是你在過程中解釋的決策。

什麼不會變成記憶：原始檔案內容、逐行程式碼、冗長的終端機輸出。提取步驟本身就是一個過濾器。對話中的贅字、重複的 context 設定、程序上的雜訊，這些都不會被保留。留下來的是一個不斷成長的程式庫事實索引，Hermes 會將其帶入未來的每一個工作階段。

生命週期在每次對話的前後都會執行：

在每次對話前：Hindsight 會從你的歷史紀錄中預先擷取最相關的記憶，並將其注入到系統提示詞（system prompt）中。Hermes 在看到你的訊息之前，就已經先看到了這些 context。

在每次回應後：你的對話會被非同步保留。Hindsight 會在背景提取事實。你在這一次對話中討論的內容，在下一次對話時就能被搜尋到。

## 兩分鐘設定

Hermes v0.14.0 (v2026.5.16) 內建了 Hindsight 整合。設定只需一個精靈指令：

```
hermes memory setup # 選擇 "hindsight"
```

確認記憶功能已啟用：

```
hermes memory status
```

設定檔位於 $HERMES_HOME/hindsight/config.json。預設值適用於大多數工作流程：

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779765215219-iaHJKqyTDW0AADyZkjpg.jpg)

memory_mode 控制記憶在 Hermes 中的呈現方式：

- hybrid（預設）：記憶會在每次對話前自動注入，且模型可以使用 hindsight_recall、hindsight_retain 和 hindsight_reflect 工具。

- context：僅自動回想，沒有明確的工具，不需要額外思考。

- tools：模型必須明確呼叫 hindsight_recall；不會自動注入任何內容。

對於程式開發工作，hybrid 是最合適的預設值。你可以在每次對話中獲得自動回想功能，同時也能要求 Hermes 明確呈現它對特定元件的了解。

關於部署：如果你需要在不同機器間工作，或與團隊共享記憶，請使用 cloud 模式。如果你希望所有內容都在本地執行且沒有外部依賴，local 模式會在背景執行一個嵌入式的 PostgreSQL 守護行程（daemon）。第一次啟動時，資料庫初始化大約需要一分鐘；後續啟動速度很快。啟動紀錄位於 ~/.hermes/logs/hindsight-embed.log。

> 從舊版的 hindsight-hermes plugin 遷移過來？請先解除安裝（uv pip uninstall hindsight-hermes --python $HOME/.hermes/hermes-agent/venv/bin/python），然後執行設定精靈。原生提供者會取代 plugin 的所有功能。詳細資訊請參閱《Hindsight is now a native memory provider in Hermes Agent》。

## 三個程式庫記憶至關重要的工作流程

在現有工作上開啟新的工作階段

沒有記憶功能時，在現有專案上繼續工作意味著在開始實際工作前必須先設定 context：貼上 README、解釋技術堆疊、重新釐清上次做到了哪裡、提醒 Hermes 它本該知道的慣例。在複雜的專案中，這種額外開銷會吃掉每個工作階段 10 到 15 分鐘的時間。有了記憶功能，Hermes 在每個工作階段開始時，就已經將累積的事實注入到 context 中。它知道技術堆疊、知道慣例、也知道你上週在除錯什麼。

工作階段的第一條訊息，直接就是實際的工作內容。

注入的內容由 budget 設定控制。在 mid（預設值）下，Hindsight 會擷取 10 到 15 個最相關的記憶，足以涵蓋專案的核心事實，而不會淹沒 context 視窗。在 high 下，檢索會更深入：更多的 context、更多的 token。對於大多數程式開發工作流程，mid 是很好的平衡點。如果你要重新投入一項跨越多個模組的複雜調查，high 值得多付出一點代價。

除錯反覆出現的問題

程式庫記憶發揮最大效益的地方在於跨工作階段的模式識別。有些臭蟲不是一次性的，它們是更深層架構問題的症狀，會在幾個月內以不同形式浮現。

沒有記憶功能時，你會獨立地除錯每一個實例。你可能會追蹤同一個根本原因三次，卻沒能將它們串聯起來。

有了記憶功能，Hermes 會回想起之前的實例。描述一個新的失敗模式，它就會呈現相關的 context：它兩個月前識別出的根本原因、在下次重構前暫時有效的權宜之計、以及在這些失敗中不斷出現的元件。

這裡能發揮價值的資訊類型：

- 「速率限制器（rate limiter）會繞過帶有 X-Internal: true 標頭請求的驗證檢查，這是兩次權限提升未遂事件的來源」

- 「當 Redis 連線重置時，非同步任務佇列會靜默丟棄任務，需要明確的 ACK 處理，不能使用 fire-and-forget」

- 「GraphQL 解析器（resolver）的 N+1 模式在每次新增 schema 後都會重現，需要在程式碼審查（code review）中標記並強制執行 DataLoader」

這些不是你會想到在除錯工作階段開始時貼上的事實。它們是將「盲目除錯」與「在完整 context 下除錯」區分開來的組織知識。

prefetch_method: reflect 值得為此工作流程啟用。reflect 不會透過語意搜尋來檢索單一事實，而是要求 LLM 在注入前，將所有相關記憶合成一個連貫的摘要。雖然速度較慢，但對於「協助我理解這類臭蟲」的查詢來說，合成後的 context 比單一事實列表更有用。

上手他人的程式碼

如果你加入一個同事已經在使用 Hermes 和 Hindsight 並擁有共享 bank 的專案，這個記憶 bank 已經包含了他們工作階段的 context。

查詢 Hermes 對特定模組的了解：

```
你對 payments 模組了解多少？


驗證服務（auth service）中出現過哪些怪癖或已知問題？


我們當初從 SQLAlchemy 遷移出來的原因是什麼？
```

Hermes 會呈現從先前工作階段累積的事實：架構 context、已知的邊緣案例（edge cases）、過去的決策及其背後的邏輯，而不需要任何人將其寫在 README、Wiki 頁面或沒人找得到的 Slack 串中。

這不是文件，這是永遠不會進入文件的組織知識。

## 良好的程式庫記憶長什麼樣

在一個專案經歷 30 個以上的工作階段後，一個建構良好的記憶 bank 通常涵蓋：

專案慣例：模組結構與匯入模式、錯誤處理要求、從程式碼中無法明顯看出的命名慣例、與預設值不同的 linting 規則。

已知的脆弱區域：在特定負載或輸入條件下會崩潰的元件、曾導致生產環境事故的整合點、測試套件未涵蓋的邊緣案例。

架構歷史：被替換的依賴項及其原因、考慮過但被否決的模式、透過測試而非文件發現的效能特性。

團隊偏好：程式碼審查優先級、部署時的陷阱、運作方式與官方文件不同的地方。

大部分內容會從正常的工作階段中自動累積。例外情況是：重大的架構決策和團隊偏好，這些透過明確說明會更有幫助。當你做出重大決定時，告訴 Hermes 其背後的邏輯：

```
我們將從 SQLAlchemy 切換到 asyncpg，因為在我們的負載配置下，連線池（connection pooling）導致了超過約 200 個並發請求時出現間歇性超時。解決方案不是調整參數，而是移除 ORM 抽象層。請記住這一點。
```

在 hybrid 模式下，模型也可以呼叫 hindsight_retain 來明確標記需要保留的內容。但背景提取步驟通常能捕捉到大部分重要的資訊。

前後對比：工作階段中的記憶回想是什麼樣子

沒有記憶功能時，工作階段的開場可能是：

> 「我正在開發一個使用 asyncpg 進行資料庫存取的 Python 服務。我們在 2 月份因為負載下的連線池問題移除了 SQLAlchemy。所有非同步處理器都應該用 handle_errors() 包覆。請協助我除錯這個間歇性的 500 錯誤...」

有了記憶功能，Hermes 已經注入了這些事實。你只需要開場說：

> 「請協助我除錯 payment handler 中這個間歇性的 500 錯誤。」

技術堆疊、慣例、架構 context，都已經在那裡了。

## 團隊程式庫：共享記憶 Bank

預設情況下，bank_id 為 hermes。同一個專案的每位開發者都可以透過設定相同的 bank_id 來共享一個記憶 bank：

```json
{
 "bank_id": "payments-service",
 "mode": "cloud"
}
```

當多位開發者在同一個程式庫上使用 Hermes 並共享 bank 時，記憶會從他們所有的工作階段中匯集。一位開發者累積的知識——例如某個棘手模組未記錄的行為、辛苦得來的除錯見解、部署時的陷阱——會自動提供給團隊的其他成員。

幾點考量：

- 適合匯集的內容：程式庫事實、架構決策、已知問題、慣例。這些描述的是程式庫而非個人，可以安全共享。

- 保持獨立的內容：個人工作流程偏好、不相關的個人 context。請為這些內容使用獨立的 bank。

- Bank 命名：每個專案一個 bank，而非每個開發者一個 bank。一個名為 hermes 的共享 bank 若被三個人隨意使用，只會變成雜訊；一個名為 payments-service 的共享 bank 若由整個支付團隊共同使用，就會變成組織記憶。

## 進階：植入結構化的心智模型

從工作階段進行有機提取是 Hindsight 建立程式庫知識的主要方式。但你也可以明確地預先載入 context，這在剛開始接觸現有程式庫，或是在第一個工作階段執行前就需要將關鍵慣例放入 bank 時非常有用。

Hindsight 透過 SDK 和 API 在 Hermes 之外公開了兩個操作，用來餵養 Hermes 所使用的同一個記憶 bank：

匯入現有文件。上傳架構筆記、ADR 或慣例檔案。Hindsight 會對內容執行事實提取，並將結果作為記憶儲存在 bank 中。一旦匯入，這些事實就會在下一個工作階段提供給 Hermes，無需等待有機提取慢慢累積。

建立心智模型。根據來源查詢定義一個精選摘要，例如「這個專案的程式開發慣例是什麼？」。Hindsight 會執行 reflect 操作，從所有已匯入和工作階段提取的知識中合成答案，並儲存結果。將 refresh_after_consolidation 設為 true，模型就會在有新事實進入時自動重新推導。在 reflect 呼叫期間，系統會優先檢查心智模型，然後才是個別觀察和原始事實，因此預先計算好的答案會直接回傳，無需即時重新推導。

匯入的專案文件與工作階段提取的事實相結合，讓 Hermes 能從兩個角度獲得完整的圖像：被刻意記錄下來的，以及透過使用發現的。

這也是讓自主程式開發 Agent 變得可行的地方。一個擁有豐富、即時的心智模型、慣例、架構、已知脆弱區域的 Agent，擁有足夠的結構化 context 來做出決策並推動變更，而無需人類在每個任務開始時進行簡報。持久化的工作階段記憶，就是你達到該基準的方式。

請參閱 Hindsight 心智模型文件以獲取完整的 API 參考。

## 使用的時間越長，你需要解釋的就越少

搭載 Hindsight 的 Hermes 是唯一一個 context 會跨工作階段累積的程式開發工作流程。每一個工作階段都會增加它對你程式庫的了解。其他工具會重置，但這個不會。

價值會隨著使用而累積。第一個工作階段，Hermes 對你的專案一無所知。第五個工作階段，它了解技術堆疊和慣例。第 30 個工作階段，它了解專案的歷史、脆弱區域，以及形塑其現狀的決策。到了那個時候，你就不再需要解釋這些事情了，不是因為你跳過了 context，而是因為你再也不需要提供它了。一旦那個心智模型足夠豐富，你就不僅僅是在跟一個程式開發助手對話。你是在與一個像你一樣了解程式庫的 Agent 並肩工作。

使用 hermes memory setup 進行設定，或從 Hindsight 整合文件開始。

延伸閱讀：

- 《What Is Agent Memory?》，AI Agent 如何保留 context 的基礎概念

- 《Hindsight Is Now a Native Memory Provider in Hermes Agent》，設定指南、記憶模式與設定參考

- 《Adding Persistent Memory to Codex with Hindsight》，應用於 OpenAI Codex 的相同模式

- 《Best AI Agent Memory Systems in 2026》，所有主要 Agent 記憶框架的比較

## 標籤

Agent, 記憶系統, 新產品, Hermes