# 第 10 章：建構一個真實世界的知識 Harness

> **一句話總結：** 一位開發者用 4 個 agent 團隊、漸進式揭露路由和自動化內容管線, 建出完整的 AI 知識系統。
>
> **為什麼重要：** 這證明一個人配上對的架構, 就能做到過去要一個團隊才能做的事。本指南裡的概念不是理論。

本章呈現一個匿名的 solo 開發者案例研究——下文稱為「建構者」——他在數月迭代開發中, 建構了一個完整的知識 harness。這裡描述的系統是真實的, 每天都在生產使用。它示範了前面章節討論的概念——context engineering、漸進式揭露、技能系統、agent 編排——如何在實務中整合起來。

## 起點

建構者從一個簡單的問題開始: 知識太多, 沒有結構。一個個人知識 vault 累積超過 300 篇筆記, 涵蓋在做的專案、技術參考、會議記錄和散落的想法。標準做法——「需要時去搜」——隨著 vault 變大就崩潰了。筆記被遺忘, 洞察被重新發現而非被檢索, 工作 session 之間 context 流失。

最初的解法很樸素: 用 LLM 助手存取 vault。但對 300+ 筆記的原始存取意味著把上下文視窗灌滿。真正的工程挑戰不是「LLM 能不能讀我的筆記」, 而是「我怎麼在對的時間給 LLM 對的筆記」。

## 知識層: Vault 作為隱式知識圖

系統的基礎是一個 Obsidian vault, 組織為刻意的資料夾層級:

- **Inbox** 用於捕捉（所有新筆記落在這裡）
- **Active** 用於日常使用的筆記（保持 5-10 項）
- **Projects** 用於有截止期限的限期工作
- **Areas** 用於無截止期限的持續職責
- **Notes** 用於原子知識（每個筆記一個想法, 標題作為斷言）
- **Daily** 用於日記和回顧報告
- **Archive** 用於完成或過時的材料

每個筆記都用 wikilink 連接到相關筆記, 不需要正式圖資料庫就能形成隱式知識圖。連結慣例簡單但嚴格: 如果筆記 A 提到筆記 B 詳細闡述的概念, A 必須連結到 B。久了之後, 這產生一個可導覽的知識網, 任何入口點都通往相關 context。

Vault 透過回顧循環來維護: 每日回顧處理 inbox 並分類新筆記; 每週回顧分析知識累積趨勢, 重新浮現有價值的舊筆記; 每月回顧檢查矛盾、合併重疊筆記、封存完成的專案。這個維護不是可選的。沒有它, 知識層會在數週內退化, 筆記變得陳舊、重複或孤立。

## Context engineering: 系統 prompt 作為索引

建構者的 context engineering 把系統 prompt 當作**深層資源的索引**, 而不是單一的指令集。一個中央設定檔（類比 AI 的 README）包含:

- **環境細節**: OS、shell、要避免的已知怪癖
- **語言偏好**: 建構者的工作語言和格式約定
- **路由表**: 一份按優先序排列的技能類別清單, 列出觸發關鍵字與指向路由檔的指標

這個設定檔總是被載入。它很精簡——少於 2,000 token——因為它只裝指標, 不裝載荷。當 LLM 收到使用者請求, 它對照路由表匹配, 只載入相關的路由檔, 路由檔再指向所需的具體技能。

另有獨立的記憶系統處理跨 session 持續。它儲存:

- 在做專案的位置與結構
- 從使用者回饋學到的偏好
- 各專案特有的技術 pattern 與約定
- 複雜主題的詳細子檔參照

記憶檔有機增長。當建構者更正助手的行為, 那項更正被記錄為偏好。當一個專案的結構被建立, 它被文件化一次, 之後就被引用。這消除了讓無狀態 LLM 互動飽受困擾的「讓我重新解釋一次我的專案」問題。

## Harness engineering: Agent 團隊

系統採用四個 agent 團隊, 每個有明確角色:

1. **Data Collector**: 從外部來源收集資訊（網頁搜尋、API 呼叫、文件解析）。擁有廣泛權限但不能發布。
2. **Pipeline Orchestrator**: 協調工作流程, 決定呼叫哪些 agent, 管理順序。撰寫「sprint 合約」——為每個任務規定預期輸出標準的文件。
3. **Content Writer**: 產出輸出（報告、社群媒體貼文、技術文件）。在內容守衛之下運作, 強制品牌語調和格式標準。
4. **QA Evaluator**: 在內容能發布前對照 sprint 合約審查所有輸出。檢查事實準確度、格式合規、品牌對齊。

Sprint 合約機制值得展開。當 orchestrator 啟動一項內容任務, 它不會簡單說「寫一篇關於 X 的貼文」。它會產出一份合約, 規定: 目標平台、字數範圍、必要元素（例如必須包含一項統計、必須以 CTA 結尾）、禁用元素（例如不要級用極端形容詞、不要未經驗證的主張）、評估標準。Content writer 對照這份合約產出。QA evaluator 對照它打分。如果輸出不通過評估, 它帶著具體回饋被退回 writer——回饋引用合約條文。這不是單次重試——迴路持續到合約被滿足或人類介入。

內容守衛在三個層級運作:

- **Prompt-level guards**: 嵌入系統 prompt 的指令, 定義 agent 必須做和不能做什麼
- **Auto-correction**: 後置處理, 抓出並修復常見問題（例如移除不要的格式 pattern、強制一致術語）
- **Regex strip**: 最後一關, 移除特定不該出現在輸出裡的 pattern（例如某些會破壞下游系統的字元、模型外漏的 metadata token）

Agent 間通訊是觸發式的。Agent 不互相輪詢。Data collector 完成收集後, 把輸出寫到指定位置並觸發 orchestrator。Writer 產出內容後, 觸發 evaluator。這種事件驅動架構讓系統反應迅速而不做不必要的計算。

## 技能系統的演化

技能系統經歷了四個清晰的演化階段, 每個都由生產中發現的實際限制驅動。

**階段 1: 平面技能檔。** 每項技能是一個含指令的獨立 markdown 檔。LLM 在 session 開始時載入所有技能檔。在 5-10 項技能時還行, 但當庫變大就難以為繼。上下文視窗被技能定義灌滿, 留給實際工作的空間所剩無幾。

**階段 2: 豐富的 YAML frontmatter。** 技能獲得結構化 metadata: 觸發條件、所需 context、依賴、版本號。這讓系統可以按相關性過濾技能, 但過濾邏輯本身消耗 token 又增加 latency。

**階段 3: 技能間的 wikilink。** 技能開始互相連結, 形成技能圖。一個「deploy」技能會連接到「run tests」作為前置條件。這使系統能載入技能鏈而非單個技能, 但導覽這張圖仍需要載入圖索引。

**階段 4: 路由檔配漸進式揭露。** 最終架構使用一份在系統 prompt 中的精簡索引（路由表）, 指向七個分類專屬的路由檔。每個路由檔列出該類別的技能與觸發條件。LLM 只載入匹配類別的路由檔, 然後只載入所需的具體技能。任何時刻, 系統載入的是: 系統 prompt 索引（約 2K token）+ 一個路由檔（約 500 token）+ 一個技能檔（約 1-2K token）。無論系統中有多少技能, 總開銷都在 4K token 以下。

建構者用 85 個測試查詢測試這套路由架構, 涵蓋所有類別, 達到 85/85 正確路由——100% 準確度。邊角情境（可能匹配多個類別的模糊查詢）由路由表中的明確消歧規則處理。

## 成果

這個架構可衡量的成果:

- **65% token 縮減**, 來自相對於平面檔做法的漸進式揭露。同樣的任務過去消耗 8-12K token 的技能 context, 現在不到 4K。
- **自動化內容管線** 在多個平台每日產出有一致品質的內容, 由一個人管理。
- **知識維護** 透過自動化 vault linting, 偵測矛盾、孤立筆記和過時資訊——這些過去需要手動回顧 session 處理。
- **跨 session 持續** 消除「冷啟動」問題。記憶系統讓助手每次都從上次離開的地方接起。

## 學到的教訓

**先簡單, 再疊加複雜度。** 建構者第一天沒有設計四 agent 加 sprint 合約系統。它從單個 agent 配一個指令文字檔開始。每一層複雜度都是為回應特定故障模式而加的: agent 產生幻覺（加 QA evaluator）、輸出不一致（加內容守衛）、上下文視窗溢出（加漸進式揭露）。過早的架構會產生為想像問題最佳化、而非真問題最佳化的系統。

**漸進式揭露值得花的設置成本。** 建構與維護路由表、七個路由檔以及個別技能檔需要持續工夫。但 65% 的 token 縮減讓它在每次互動中都付清自己。更重要的是, 系統可擴展: 加新技能意味著在一個路由檔加一行, 不是重構整個 prompt。

**Less is more。** 壓縮、精確的技能定義勝過冗長的。一個寫「在 vault 中搜尋匹配查詢的筆記, 返回檔案路徑與相關摘要, 建議關聯」的技能檔, 比同樣指令的 500 字闡釋更好。LLM 不需要被牽著走; 它需要清晰意圖。

**Harness 就是產品。** 建構者的競爭優勢不是任何單一技能或 agent。是 harness——路由邏輯、sprint 合約、內容守衛、回顧循環、記憶系統。各別組件都很直接。整合才是價值所在。這呼應一個關於知識工程的更廣真理: 模型在商品化, 但編排它們的系統不是。

## 邊欄: Claude Code 作為參考實作

建構者系統演化的大部分時間, Anthropic 自家內部工具是黑盒。從業者可以從 Claude Code 的行為推論它如何工作, 但 Anthropic 之外沒人看過原始碼。這在 **2026 年 3 月 31 日** 改變了, 當 Anthropic 不慎在 npm 套件 `@anthropic-ai/claude-code` v2.1.88 內運送了一份 59.8MB 的 source map——大約 513,000 行未混淆的 TypeScript, 跨 1,906 個檔（詳情見第 4 章）。這次外洩給社群提供了對前沿實驗室生產 harness 的第一次實證觀察, 而它的幾個 pattern 與建構者獨立到達的非常吻合:

- **Self-Healing Memory, 不是一個大檔。** Claude Code 外洩出來的架構組織成三層「Self-Healing Memory」系統, 層之間有明確的修復邏輯。建構者的 vault + 記憶檔 + sprint 合約迴路是同一概念的較粗版本: 短期工作狀態（當前 session）、中期壓縮狀態（記憶檔）、長期持久知識（vault）。兩個系統中,「記憶」都不是一個地點; 它是一組層加上層之間的轉換。
- **MEMORY.md 是索引, 不是儲存庫。** Claude Code 內部的 `MEMORY.md` 是輕量級的指標式索引, 指向更詳細的筆記——不是單一的 transcript。建構者的設定檔扮演完全相同角色: 它裝路由表與指標, 不裝載荷, 這正是基線 context 保持在 2K token 以下的原因。
- **`KAIROS` 與自主 daemon 模式。** Claude Code 原始碼中提到一個 `KAIROS` feature flag 超過 150 次。它把守一個自主 daemon 模式——一個無人看管的長時間執行迴路, 遠超大多數使用者熟悉的互動 REPL。建構者的觸發式、事件驅動 agent 間通訊是同一概念的手工版本: agent 在事件上喚醒、做工、傳遞, 不需要人類每步介入。

這個邊欄的重點不是建構者的系統秘密就是 Claude Code。這兩個系統在工程投入上差了幾個數量級, 建構者的版本是用數百份 markdown 檔做了 Anthropic 用 50 萬行 TypeScript 做的事。重點是**兩個系統獨立收斂到同一個形狀**——含索引的分層記憶、路由優於載荷、事件驅動編排——這暗示這些 pattern 不是風格選擇。它們是生產 harness 在與真實工作負載接觸並存活下來後會變成的樣子。

## 對從業者的啟示

這個案例研究說明, 一個 solo 開發者在數月迭代下, 可以建出兩年前需要一個工程師團隊才能建的知識 harness。關鍵啟動條件是: 足以遵循複雜多步指令的 LLM、用於工具整合的開放協定（MCP）、提供這些系統設計 pattern 的新興 context engineering 學科。

建構者的系統不是要被複製的範本。它是一個概念證明, 顯示本指南中的原則——漸進式揭露、context engineering、技能圖、agent 編排——在生產中產生可衡量的成果。你的 harness 看起來會不一樣。架構應該一樣。

---

*下一章: [第 11 章 —— LLM 知識工程的關鍵時刻](../../../chapters/11-timeline.md)（英文）*
