個人知識庫、LLM Wiki、第二大腦、還有什麼...？

往前翻我寫的文章，反覆地我提到像是： LLM Wiki 本質上是「一堆資料+AI」、一堆 Markdown 檔案 + 一個能操作檔案系統的 Claude

不是說我之前講錯了，只是從這個角度出發的解釋、設計其實「沒有控制可言」，我說明一下。

原先所有的設計其實已經有很強的「上下文管理」的思維

從按需檢索出發，我們要求 AI 在需要的時候將資訊讀取進上下文

例如第五篇我給出這樣的機制：

四種機制做到按需檢索

1. 拆分 => 一份筆記只講一件事（原子化）、命名要具體，這跟 Ingest（入庫）有關。
2. 結構 => 透過清楚定義好資料結構，「用看的」就能知道資料放在哪，不需要找，這對你跟對 AI 都方便。
3. 索引 => 弄一份「目錄」出來，像字典那樣，如果要查 Butthole，先去看看 B 開頭的從哪一頁開始。
4. 連結 => 相關的東西要互相牽線。像是 Butthole 跟痔瘡有關，兩件事要牽起來，掃到其中一個，自動想起另外一個。

就像這樣，配合各種步驟與驗證報告、規則與功能敘述之後

使用過程中還是反覆出現一些小問題，在稍後的時候我發現問題是：我假設寫清楚 = 會被照做

既然發現不是這樣，那麼就得想辦法解決才行。

什麼問題？

AI 幫我從建設歷程翻出五次撞牆紀錄，最嚴重的一次是：AI 無視規則事件。

之前我的 Query 會這樣寫：

---
## 1. 限縮範圍

建立候選頁面集合，來源分為三類：語意候選（A）、grep 候選（B）、反向連結候選（C）。三者聯集後去重，並保留各頁面的命中來源。

* **語意候選（A）**
  * 從 `wiki/index.md` 判斷與 Q 相關的主題，主題底下若只有路由頁連結，先讀路由頁取得頁面清單；再依頁面摘要挑出候選。
* **grep 候選（B）**
  * 不論 A 是否有結果，都以 Q 的關鍵字、同義詞與中英文變體搜尋 `wiki/`、`chaos/白板.md`、`chaos/想法.md`。
  * 所有命中頁面皆加入候選集合。
* **反向連結候選（C）**
  * 對 A、B 候選的頁面名稱搜尋 `wiki/` 中的 Wiki Link，將連向這些候選、但尚未進入集合的頁面加入候選。

我希望 AI 在搜尋知識庫內容時，先取出聯集、再從聯集中找我問題的答案。

當我把上面那串塞進 Context，要求 AI 「照做」時，我是把這串當作規則了，AI 則是只把它當成新來的上下文

只是新來的一坨字

而且 AI，或者說的更精確一點，LLM 在回答問題，任何問題時，它並不是照著步驟來的

它是反覆找，只要找到 LLM 「覺得可以回答」的程度就直接停下並且回答

而 Query 這個動作的本質就是問問題，這也讓這條規則特別容易被「無視」。

在發現根因後 Query 又經歷了幾次大改，但是問題仍在，因為彼時

我還沒有 Harness Engineering 的概念。

進入 Harness Engineering 範疇

實際上這問題一定會發生嗎？否。

我們只須稍微修正我們的預期，以及更好的「控制」AI 的行為

這就進入到 Harness Engineering 的範疇了。

Harness 馬具，套用在 Harness Engineering 上，於是人稱「駕馭工程」，其核心就是

駕馭 Agent 的工程

以往我們只用提示詞、上下文來控制 AI 的行為

就像是老闆塞了一桌子文件給你，然後期望你生出一個「令人滿意」的 PPT。

我們已經知道不管做了再多的設定，對 AI 來說就只是一桌子文件而已

對「員工」來說，要產出一個令人滿意的 PPT，除了一桌子文件以外，需要更多「引導」。

我們當然可以控制塞文件的速度與數量，但效果有限，只要你還是把 AI 當成「那個自己得出結論，產出 PPT 的好員工」，時間一久、Context 一長，AI 絕對會開始秀斗的。

那換個想法

Agent 只是匹馬。跑得很快的馬。

控制這匹馬，我們不只是要塞文件給它，還要學會控制。

工作逐漸從「提供上下文、寫規範」變成更廣的：設計環境、提供工具、建立 feedback loop 和 enforceable constraints。

做起來會像這樣：

Agent 犯錯
↓
修正問題
↓
找出為什麼環境允許它犯這個錯
↓
改 Harness
↓
下一個 Agent / 下一個 session 自然就比較不會犯

接下來幾篇文章會朝這個方向持續優化現有的知識庫規範、上下文等內容。