Agent Team 實戰（六）：知識——Em 的 Wiki 和「不是所有東西都要塞進 Context」

一句話： 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 的建構過程消耗了約等於 800 頁書的量的 output tokens，而這些產出幾乎都是文件、而且散落在不同的對話紀錄、不同的設計文件、不同 Agent 的工作目錄裡，如果沒有人系統性地整理它們，這些知識就只是存在某個地方的文字，除非你記得、而且叫 agent 去讀，不然這些文字就不是可以被使用的知識，為了解決這個問題而設計的 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 裡找到相關的頁面、知識、索引提供給他。(之後進化成可以自己查)

當然，這邊也有兩條不同的路，對許多人來說，他們只需要 Ingest 之後改善現有流程，意即讓知識驅動 Agent Team 進化，所以這些整理後的結果應該是一個 Agent 的改善，藉此達成一個 Agent 前進的閉環就夠了，並不需要所謂的知識，這觀點的前半段我是同意的，但我想做的並不只是這樣，因為 Agent 的習性(解決眼前問題、喜歡加東西多於減東西、自我驗證繆誤等)，多一個制高點的知識用以稽核、審視、復用、進化、甚至將來的回測/回驗/整合來說，這個獨立於實作之外的知識的是必要的，所以我選的是另外一條路，先做知識，再來讓知識推動改善跟進化，因為跟我之前提到的三層方法論、Playbook、Plan 一樣，如果我們專注於打造/更新 Playbook、Plan，忘了更新方法論，一但遇到場景更新而且對應不上，我們只能從頭來過，但如果留下方法論，就能夠在那個狀況下給我們更多的彈性跟退路，這也是我希望 Agent Em 肩負的另一個重要任務。

raw → wiki → inbox：知識的三個階段

Em 的知識 Pipeline 有三個階段，每個階段處理不同性質的資料。

raw/：原始素材的存放位置，Em 不做對 Raw data 做任何處理，這個 Data 可能是一段對話紀錄、一份外部文件、一個 GitHub repo 的內容、甚至是一個 DeepWiki 頁面的擷取，Em 不動這些資料，只從裡面”提取”知識。

wiki/：Em 的核心產出，基本上就是一個結構化的知識庫，但裡頭有四種頁面：concepts（概念，比如 Context Engineering、方法論三層框架）、entities（人事物，比如每個 Agent、外部工具、作者）、sources（來源摘要，記錄每次 ingest 的原始資料和產出）、analysis（跨概念的綜合分析，比如 GM 的方法論建議），每個頁面都有固定的結構框架（標題、類型、日期、來源標記），讓 Agent 容易讀取理解，並且頁面之間有交叉引用連結 [8]，讓你可以在需要時找到對應的關聯資料。

inbox/：來自其他 Agent 的待處理訊息，當 C7 完成了一個新的 Skill 入庫，或者 Dm 建完了一個新 Agent，他們可以都可以把通知放進 Em 的 inbox，告訴 Em「有新的東西值得 ingest 進 wiki」，這個機制目前還是手動的(大部分時候是我告訴 Em「去 ingest 這個」)，但我希望從設計上讓它之後由 GM 協調自動化。

看起來很機械，但其中第 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 的打包結構），讓他的 ingest 有一個初始框架。

Em 讀了 16 個檔案之後，產出了 3 個新頁面（source、entity、一個新的 concept：multi-phase-llm-pipeline），更新了 4 個既有頁面（subagent-pattern 新增了兩個 real-world cases，plugin-packaging 補充了 distribution 細節）。

這裡有一個比較關鍵的決策是在 ingest prompt 裡就給出萃取的方向， 而不是讓 Em 自己判斷什麼值得萃取，因為我判斷 Em 的 Context 裡沒有「這個 Plugin 在 production 跑了多久」「哪個 pattern 被其他專案複用過」這些背景，如果不給方向，他可能會把注意力放在不重要的地方，這跟之前在校準那篇裡討論的「該說清楚的 vs 該放手的」是類似的判斷：目標和約束要說清楚，執行路徑要放手。

案例二：ingest 10 份來自於 Agent Team 建立時的對話紀錄

第二個案例就是開頭提到的那次，ingest 10 份我在建立 Agent Team 過程中跟不同 Agent 的對話紀錄，這次的 ingest 有一點點不同：我下了指令叫 Em 開始照標準流程讀取檔案，然後我馬上中斷，重新給了一份更詳細的 Prompt。

為什麼？因為是我意識到標準流程可能不夠，因為這些對話紀錄不是「知識文件」，而是「工作過程的記錄」，Em 需要從工作過程中提取出 pattern，而不是把對話內容的亮點 Ingest 出來，這兩種做法在產出上並不太一樣，如果你有讓 AI 自己總結你的對話紀錄做改善就會發現，給指令跟不給指令有很大的差異，所以，我在第二次的 Prompt 裡寫到：「這是我建立整個 Agent Team 的過程，提取過程中的知識，主要你要看我是怎麼協調這些 Agent 來做事，因為這是 Agent GM 應該要學會的東西，同時這些溝通過程也很重要，他是作為我們設計 inbox 跟 communication 機制的依據。」

這段 Prompt 的意義在於：ingest 的品質不只取決於 Em 的辨識能力，也取決於人類給的方向指引， 如果你只是丟一堆檔案給 Em 說「ingest」，他會用他自己的判斷來決定什麼重要，對於一個 Githu Repo、一篇文章、一個新聞，這樣或許可行，但對於已經有脈絡的對話紀錄，Agent 沒有你腦中的那些脈絡，比如「這些對話裡的協調模式是 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 該放什麼、哪些知識應該需要的時候才載入)，有了這些東西，才開始讓 Dm 做 GM 的設計。

這才是 Em 最有價值的能力：不只是存知識，而是把散落在不同頁面裡的知識連結起來，產出單一頁面無法提供的洞察，這跟每次對話就叫 Agent Ingest Session Context 或者 每個禮拜 Review 所有 Finding 來做是截然不同的，因為他是有架構、有意識、有向性的去連結知識跟框架，跟前面單純做大堆頭的摘要、精煉、濃縮，在邏輯型跟架構性上就不一樣，最終， Dm 的 Architect 讀完 Em 的綜合分析，搭配 design inputs 裡的 16 個 scenario 設定，設計出了 GM 的 development plan，中間也不需要再回來問 Em「那個 protocol 的規格是什麼」，因為 synthesis 裡已經把所有相關知識整合在一起了，就像前面說的，如果你只是在每次 Review 工作 Session 或者 Weekly Report 時就即時產出一個對 Agent 的改善，你是無法得到這樣的洞察跟理解，同時用來架構更完整更大的東西。

wiki 變大之後呢？

走到這裡，感覺上 Agent 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，那是一個只有 4 分鐘的小小 session ，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 裡，不用去翻對話紀錄或 Release Note。

這同時也帶出了另一個觀察，在傳統的軟體開發裡，知識管理通常是開發完成事後才做的事：先寫程式，然後（如果有時間的話）補文件(事前寫 SPEC 文件，事後寫操作文件)，但在 Agent Team 裡，知識管理是核心工作流程的一部分，因為 **Agent 的能力直接取決於他的 Context，**Context 越完善，Agent 的產出越精準，所以如果 Em 的 wiki 裡沒有某個 concept，那其他 Agent 就不知道這個 concept 存在，就不會在設計決策中考慮它 [11]，而實際的產出就有可能有遺漏，所以說，要說 Em 是整個 Agent Team 的大腦跟開發的源頭也不為過。

800 頁書的量的 Token 產出不在於「寫了多少」，而在於「被結構化了多少」，散落的對話紀錄是 raw data，被 Em ingest 過的 wiki 頁面才是 knowledge，而 knowledge 的價值在於它可以被找到、被引用、被交叉連結、被其他 Agent 在做決策的時候拿來當依據。

知識管線的完整圖像

如果要畫一張圖來描述這條知識 Pipeline，大概是這樣的：

這裡頭的每一步都是 Context 的壓縮和結構化：從充滿大量雜訊和重複的 raw data，到經過 Em 濾除雜訊之後再壓縮的 concept，然後透過在 concept 頁面之間建立了交叉引用，讓知識形成網路，最後讓 QMD 索引讓查詢不需要遍歷整個 wiki，這一棒接一棒的努力，最後產出了一個讓其他 Agent 可以在需要的時候載入需要的知識的系統。

這就是 Context Engineering 的 JIT loading 原則在知識管理層面的實踐 [9]： 知識不應該存在每個 Agent 的 Context 裡，那太浪費 Agent 的 Context 跟 Token，知識應該存在一個集中的、可編譯的、可搜尋的知識庫裡，讓 Agent 在需要時可以查，然後查完就釋放那段 Context，騰出空間給下一步的工作，這樣才是一個有效率的系統。

所以，Agent Team 裡最容易被低估的角色其實是 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/