一句話： Agent Team 的知識不該散落在每個 Agent 的 Context 裡，需要一個集中的、可編譯的、可搜尋的知識庫。
那天晚上我讓 Em ingest 了 10 份對話紀錄，這些對話是我在建構整個 Agent Team 的過程中，跟不同 Agent 之間的互動記錄，包括我怎麼協調 Em 和 C7 平行處理、怎麼跟 Agent G 討論 GM 的設計、怎麼把一個 Agent 的產出手動轉交給另一個 Agent。ingest 完成之後，Em 的 wiki 新增了 3 個全新的 concept（bootstrap-agent-pattern、prompt-relay-pattern、cross-machine-registry-pattern），更新了 3 個 entity 頁面和 2 個既有的 concept，同時產出了一份 source summary，裡面包含 10 個對話的完整時間軸、5 種人類協調模式、10 個架構決策，以及「GM 需學會的 7 個 pattern」。
那是我開始覺得 Agent「記住了」我們做過的事，這個感覺不是因為 Context window 變大(那陣子 Opus 模型的 Context Windows 從 20 萬漲到 100 萬)，而是因為知識開始被結構化了，原本散落在不同 session 對話歷史裡的決策和 pattern，經過 Em 的 ingest，變成了可以被任何 Agent 在任何時間點查詢的 wiki 頁面，而且頁面之間有交叉引用，Em 不只是存了知識，他把知識之間的關聯也建立起來了，這讓 Context 有了新的維度。
為什麼需要一個知識 Agent
在前面幾篇裡我提過，Agent Team 的建構過程消耗了 1,080,005 個 output tokens，約等於 800 頁書的量，而這些產出裡有 97% 是 Markdown，而這些 Markdown 散落在不同的對話紀錄、不同的設計文件、不同 Agent 的工作目錄裡，如果沒有人系統性地整理它們，這些知識就只是存在某個地方的文字，不是可以被使用的知識，而這正是我們設計 Em 的原因，因為 Em 目前不做別的事，他只做：ingest（把原始素材轉化成結構化的 wiki 頁面）、query（從 wiki 裡找到相關知識回答問題）、lint（檢查 wiki 的一致性和完整性）這三件事(他的成長等等會說)，他擔任整個 Agent Team 的知識編譯器 [2][7]，raw data 進來，structured knowledge 出去。
之前 Context Engineering 那篇我提過 JIT loading 的原則 [1]：不是把所有東西都塞進 Context 等著用，而是在需要的時候才載入你當下需要的東西 [5]，而 Em 的 wiki 就是這個原則的具象化，Agent 不需要記住所有知識，他只需要知道「去問 Em」，Em 會從 wiki 裡找到相關的頁面、知識、索引提供給他。
raw → wiki → inbox：知識的三個階段
Em 的知識 Pipeline 有三個階段，每個階段處理不同性質的資料。
raw/：原始素材的存放位置，不做任何處理，可能是一段對話紀錄、一份外部文件、一個 GitHub repo 的內容、甚至是一個 DeepWiki 頁面的擷取，Em 不會修改 raw 裡的東西，他只是從裡面提取知識。
wiki/：Em 的核心產出，結構化的知識庫，裡面有四種頁面：concepts（概念，比如 Context Engineering、方法論三層框架）、entities（人事物，比如每個 Agent、外部工具、作者）、sources（來源摘要，記錄每次 ingest 的原始資料和產出）、analysis（跨概念的綜合分析，比如 GM 的方法論建議）。每個頁面都有固定的結構（標題、類型、日期、來源標記），頁面之間用交叉引用連結 [8]。
inbox/：來自其他 Agent 的待處理訊息，當 C7 完成了一個 skill 入庫，或者 Dm 建完了一個新 Agent，他們可以把通知放進 Em 的 inbox，告訴 Em「有新的東西值得 ingest 進 wiki」，這個機制目前還是手動的(大部分時候是我告訴 Em「去 ingest 這個」)，但設計上它之後會由 GM 協調自動化。
每次 /ingest 的流程是這樣的：
- 讀取 raw/ 裡的來源文件
- 在 wiki/sources/ 建立一個 source summary 頁面
- 辨識來源中提到的 entities 和 concepts
- 建立新頁面或更新既有頁面
- 更新 wiki/index.md（所有頁面的索引）
- 如果來源改變了大局理解，更新 wiki/overview.md
- 在 wiki/log.md 記錄這次 ingest
看起來很機械，但其中第 3 步和第 4 步是最需要判斷的，因為 Em 要決定：這段知識是一個全新的 concept，還是某個既有 concept 的補充？如果是補充，要更新哪個頁面的哪個段落？如果同時涉及多個 concept，交叉引用該怎麼建立？這些判斷決定了 wiki 的品質，而 wiki 的品質決定了其他 Agent 查詢時能不能拿到有用的結果。
三個 Ingest 的故事
光講流程太抽象，讓我用三個實際的 ingest 案例來展開。
案例一：ingest 外部 Plugin repo
第一個是 ingest 我自己的 Claude Code Plugin repo（emilwu-plugins），裡面有三個已經在 production 使用的 Plugin：investigate（跨 repo 平行調查）、claude-insights-command（session 分析報告）、claude-insights-skill（同上但用 Skill 形式）。
我給 Em 的指令不只是「ingest 這個 repo」，而是附了詳細的 ingest 重點，告訴他「這裡面有三個值得萃取的 pattern」：Parallel Investigation Pattern（Explore → Decide → Execute 三階段）、Session Analysis Pipeline（五階段 data pipeline + 兩層平行 subagent 處理）、Plugin Distribution Pattern（hooks + scripts + prompts 的打包結構）。
Em 讀了 16 個檔案之後，產出了 3 個新頁面（source、entity、一個新的 concept：multi-phase-llm-pipeline），更新了 4 個既有頁面（subagent-pattern 新增了兩個 real-world cases，plugin-packaging 補充了 distribution 細節）。
這裡有一個關鍵的設計決策是在 ingest 指令裡就給出萃取方向， 而不是讓 Em 自己判斷什麼值得萃取。因為 Em 的 Context 裡沒有「這個 Plugin 在 production 跑了多久」「哪個 pattern 被其他專案複用過」這些背景，如果不給方向，他可能會把注意力放在不重要的地方。這跟之前在校準那篇裡討論的「該說清楚的 vs 該放手的」是同一個判斷：目標和約束要說清楚，執行路徑放手。
案例二：ingest 10 份建構過程的對話紀錄
第二個案例就是開頭提到的那次，ingest 10 份我在建構 Agent Team 過程中跟不同 Agent 的對話紀錄，這次的 ingest 有一個前奏：我第一次下指令的時候，Em 開始照標準流程讀取檔案，但我中斷了他，重新給了一份更豐富的指令。
中斷的原因是我意識到標準流程不夠，因為這些對話紀錄不是「知識文件」，而是「工作過程的記錄」，Em 需要從工作過程中提取出 pattern，而不是把對話內容存起來，所以我在重新給的指令裡寫了：「這是我建立整個 Agent Team 的過程，提取過程中的知識，看我是怎麼協調這些 Agent 來做事，因為這是 Agent GM 應該要學會的東西，同時這些 Agent 溝通的過程也可以作為我們設計 inbox 跟 communication 機制的依據。」
這段指令的意義在於：ingest 的品質不只取決於 Em 的能力，也取決於人類給的方向， 如果你只丟一堆檔案給 Em 說「ingest」，他會用他自己的判斷來決定什麼重要，但他沒有你腦中的那些隱含脈絡，比如「這些對話裡的協調模式是 GM 將來要學會的」，當對話缺少這些東西的時候，最後的提取結果可能不會是你要的方向，不過你也要小心不要給出過多的細節，避免 Agent 在對話裡面試著拼湊出你要的東西，但這東西根本不存在對話中。
最後，Em 從 10 份對話裡提取出了：bootstrap-agent-pattern（Agent G 作為臨時建構者的模式）、prompt-relay-pattern（人類手動在 Agent 之間傳遞 prompt 的現狀，也就是 GM 要自動化的東西）、cross-machine-registry-pattern（跨機器的 Agent 註冊和同步），以及一份 source summary 裡整理的「Human 作為協調者的 5 種模式」，這些都提供了 Agent Team 繼續建立的基礎。
案例三：cross-concept synthesis
第三個案例是個混合的應用，因為它不只是讓 Em 做 ingest，而是讓他做了一次跨 concept 的綜合分析。
那是在設計 GM 的時候，Dm 的 Architect 需要一份 GM 的 Methodology 建議來做設計，但 GM 的 Methodology 不是從單一來源就能得到的，它需要交叉分析 wiki 裡多個不同的 concept：agent-team-architecture 告訴你 GM 在架構裡的位置，context-flow-decision-model 告訴你 GM 什麼時候該用 Skill、什麼時候用 Subagent、什麼時候用 Agent Teams，methodology-playbook-plan 告訴你 Methodology 本身應該長什麼樣，completion-reporting-protocol 告訴你 Agent 做完事之後怎麼回報，prompt-relay-pattern 告訴你目前人類手動做的事有哪些。
我讓 Em 讀取了 12 個概念頁面、5 個實體頁面、2 個來源摘要，然後產出了一份 GM 方法論的綜合分析，裡面包含 7 條方法論原則(每條都可以追溯到 wiki 裡某個具體概念)，GM 的場景模式建議(從 16 個 use case 歸納出來的 pattern)，以及 Context 設計建議(CLAUDE.md 該放什麼、哪些知識應該需要的時候才載入)。
這才是 Em 最有價值的能力：不只是存知識，而是把散落在不同頁面裡的知識連結起來，產出單一頁面無法提供的洞察， Dm 的 Architect 讀完 Em 的綜合分析之後，搭配 design inputs 裡的 16 個 scenario，直接設計出了 GM 的 plan，中間不需要再回來問 Em「那個 protocol 的規格是什麼」，因為 synthesis 裡已經把所有相關知識整合在一起了。
wiki 變大之後呢？
講到這裡，Em 的 wiki 聽起來很美好：知識被結構化了、有交叉引用、可以做 cross-concept synthesis、其他 Agent 可以隨時查詢，但當 wiki 從 20 幾頁長到 50 幾頁，再長到 120 多個檔案的時候，一個問題開始浮現。
每次 /query 的時候，Em 需要先讀 index.md 找到相關頁面，然後讀取那些頁面，綜合之後回答問題。但隨著 wiki 越來越大 [4]，index.md 本身就變得很長，而 Em 為了確保不遺漏，經常會讀取比實際需要更多的頁面，因為他沒辦法光看標題就確定某個頁面跟問題有沒有關。
這是一個 token 成本線性增長的問題 [3][10]， wiki 越大，每次 query 讀取的 token 越多，而大部分讀取的內容最後都不會被用到。這其實就是之前在 Context Engineering 那篇裡講的 Context Stuffing 的反面：你不是在啟動時把所有東西塞進 Context(那是 eager loading 的問題)，你是在查詢時被迫讀取太多東西(這是 search 的問題)。
更具體地說，問題出在 Em 的 query workflow 缺少一個 search 層，目前的流程是：讀 index → 讀頁面 → 綜合回答，但真正理想流程應該是：用語意搜尋找到最相關的頁面 → 只讀那幾頁 → 綜合回答，差別在於第一步是「遍歷」還是「搜尋」，遍歷的成本跟 wiki 大小成正比，搜尋的成本（理論上）是固定的。
後來我引入了 QMD（一個基於向量搜尋的語意查詢工具 [6]），讓 Em 的 query 可以先用語意搜尋縮小範圍，再讀取相關頁面，但 QMD 的整合故事比較複雜，涉及三個階段的設計，留到下一篇講記憶系統的時候再展開。
知識不只是存起來
回到 Em 身上，在建構過程中，有一個小場景帶給我一些感觸。
Em 經歷了前一篇提到的 CLAUDE.md refactor（99 行降到 47 行）之後，我讓 Em 自己更新他的 wiki entity page，記錄這次 refactor，那個 session 只有 4 分鐘，Em 更新了 wiki/entities/agent-em.md，在 Configuration section 加入了 wiki-schema skill 的說明，然後在 wiki/log.md 記錄了「抽出 Page Format / Workflows / Conventions 到 skill」的變更理由。
一個 Agent 在自己的知識庫裡記錄自己的架構變更， 這聽起來很 meta，但它說明了一件事：wiki 不只是「給其他 Agent 查詢用的資料庫」，它也是每個 Agent 自己的成長紀錄。下一次有人問「Em 什麼時候做了 refactor、為什麼做」，答案就在 Em 自己的 wiki 裡，不需要去翻對話歷史。
這帶出了一個另一個觀察，在傳統的軟體開發裡，知識管理通常是事後才做的事：先寫程式，然後（如果有時間的話）補文件，但在 Agent Team 裡，知識管理是核心工作流程的一部分，因為 **Agent 的能力直接取決於他能讀到什麼知識，他有什麼 Context，**所以如果 Em 的 wiki 裡沒有某個 concept，那其他 Agent 就不知道這個 concept 存在，就不會在設計決策中考慮它 [11]，所以說 Em 是整個 Agent Team 的大腦跟源頭其實不為過。
97% 是 Markdown，1,080,005 個 output tokens，800 頁書的量，而這些產出的價值不在於「寫了多少」，而在於「被結構化了多少」，散落的對話紀錄是 raw data，被 Em ingest 過的 wiki 頁面才是 knowledge，而 knowledge 的價值在於它可以被找到、被引用、被交叉連結、被其他 Agent 在做決策的時候拿來當依據。
知識管線的完整圖像
如果要畫一張圖來描述整個知識管線，大概是這樣的：
每一步都是 Context 的壓縮和結構化：raw data 裡有大量的雜訊和重複，Em 濾除雜訊之後再把它壓縮成 concept 頁面，concept 頁面之間建立了交叉引用讓知識形成網路，QMD 索引讓查詢不需要遍歷整個 wiki，最後其他 Agent 在需要的時候才載入需要的知識。
這就是 Context Engineering 的 JIT loading 原則在知識管理層面的實踐 [9]： 知識不該存在每個 Agent 的 Context 裡，知識該存在一個集中的、可編譯的、可搜尋的知識庫裡，Agent 在需要的時候去查，查完就可以釋放那段 Context，騰出空間給下一步的工作。
或許，Agent Team 裡最容易被低估的角色不是 GM（人人都覺得 leader 最重要），而是 Em（沒有人覺得圖書館員很重要，直到他們找不到需要的書）。
或許，這也解釋了為什麼 Em 是第一個被建出來的 Agent，因為在所有其他 Agent 開始做事之前，他們需要有個地方可以儲存、知道「我們已經知道了什麼」。
參考資料
[1] Anthropic — Effective Context Engineering for AI Agents（官方指南：selective loading 優於 context stuffing） https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
[2] The New Stack — 6 Agentic Knowledge Base Patterns Emerging in the Wild https://thenewstack.io/agentic-knowledge-base-patterns/
[3] arXiv — Solving Context Window Overflow in AI Agents https://arxiv.org/html/2511.22729v1
[4] AI Pace — Context Engineering: Mitigating Context Rot in AI Systems（「context rot」：context 越大，模型可靠性越低） https://medium.com/ai-pace/context-engineering-mitigating-context-rot-in-ai-systems-21eb2c43dd18
[5] Jentic — Just-In-Time-Tooling: Scalable, Capable and Reliable Agents（JIT 架構：按需載入而非預載） https://jentic.com/blog/just-in-time-tooling
[6] arXiv — Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG（反面觀點：業界更傾向 RAG + embedding 而非結構化 wiki） https://arxiv.org/abs/2501.09136
[7] InfoWorld — Anatomy of an AI Agent Knowledge Base https://www.infoworld.com/article/4091400/anatomy-of-an-ai-agent-knowledge-base.html
[8] arXiv — MAGMA: A Multi-Graph based Agentic Memory Architecture（反面觀點：graph 結構可能比 flat wiki 更有效） https://arxiv.org/pdf/2601.03236
[9] Context Studios — From Mode Collapse to Context Engineering（「focused 300-token context 優於 unfocused 113K-token context」） https://www.contextstudios.ai/blog/from-mode-collapse-to-context-engineering-how-we-build-reliable-ai-systems-2026
[10] Factory.ai — The Context Window Problem: Scaling Agents Beyond Token Limits https://factory.ai/news/context-window-problem
[11] Meta Engineering — How Meta Used AI to Map Tribal Knowledge in Large-Scale Data Pipelines https://engineering.fb.com/2026/04/06/developer-tools/how-meta-used-ai-to-map-tribal-knowledge-in-large-scale-data-pipelines/
支持這個系列
如果這系列文章對你有幫助，考慮請我喝杯咖啡
請我喝杯咖啡
