AI Engineer Europe 2026 · 工作坊 · 2026-05-05 · 68 分
讓 agent 失敗來補知識庫
Demand-Driven Context: A Methodology for Coherent Knowledge Bases Through Agent Failure
講者認為公司內部知識才是 agent 的瓶頸：不如拿真實工單去考 agent，讓它失敗並列出缺什麼，再由人補答案、寫進 GitHub。
概要
- 瓶頸在公司內部知識講者說 LLM 與 agent 越來越強，卡住的是只存在公司與人腦裡的 institutional knowledge，而且沒有廠商會替你的公司修知識庫。
- 接再多 MCP 也補不了講者自己做過一堆 MCP server，多數時候只有 10% 到 30% 的時間答對，其餘時間都在幫 agent 補資料。
- 改成 pull，不再 push像給新進員工派工作一樣，把問題丟給 agent，讓它失敗、提出缺口清單，人補完後它再整理成可重用的 context blocks。
- 用歷史工單批次掃缺口把過去的 Jira、事故、客服工單拿來驗證知識庫，產出缺口分類與 Kanban board，標出哪些最該先補。
- 知識存在 GitHub講者偏好 GitHub repo，因為自帶 PR 與 review，多個 agent 與專家貢獻時可以處理衝突，之後再發佈到別處。
- 適用範圍要縮小Q&A 裡講者說，範圍縮到最小的團隊才快又有用，也承認這個方法還很早期。
原話
▶ 02:16“nobody is actually seriously looking into the problem”
沒有人真的認真在看這個問題
▶ 09:39“I'm doing more work than actually doing less work.”
我做的事反而更多，而不是更少
▶ 11:44“But nobody is going to come to your company and fix your knowledge base.”
沒有人會跑到你公司來幫你修知識庫
▶ 25:10“we are moving agent from consumer to a knowledge manager”
我們讓 agent 從消費者變成知識管理者
▶ 37:25“I don't want to be the knowledge manager of it, so let it do it.”
我不想當知識管理者，讓 agent 去做
延伸
- 講者說三月已在 arXiv 發表 preprint，但這場沒有講細節。
- 回答聽眾時講者提到一篇做法相近的論文，說那篇處理的是 agent 從對話中更新記憶，而不是發掘與整理已文件化的領域知識。
- 講者說也試過在營運當下邊失敗邊補，但太耗時，所以改成在 retrieval 之前先修。
章節
點時碼直接跳到原片的那一段。
- 開場與自我介紹講者說明自己在 IKEA 擔任 staff software engineer，並預告這場分三段：處境、問題、動手示範。
- 用 Memento 比喻 agent講者拿電影 Memento 類比：模型推理與寫程式很強，缺的是公司內部的領域知識。
- 企業為什麼看不到成效講者提問：AI 這麼會寫程式，Jira epic 為什麼沒在動；引用 McKinsey 的數字，88% 的公司用 AI，只看到 6% 的價值。
- 工單的三種顏色講者用四張 Jira 工單分成綠、橙、紅：綠色是 LLM 本來就會的，橙色要教，紅色是只存在公司與人腦裡的 institutional knowledge。
- 業界解法與自己踩的坑業界的答案是 retrieval layer；講者自己做過一堆 MCP server，多數時候只有 10% 到 30% 的時間答對，其餘時間都在幫 agent 補資料。
- 知識庫是一整塊 monolith講者畫出企業知識的組成：過時、不可靠、重複，以及約 40% 的 tribal knowledge；沒拆開之前，接再多 MCP 都沒用。
- 提案：從 monolith 拆成 context blocks類比 monolith 拆 microservices、waterfall 轉 Agile；講者說三月已把這個方法發成 arXiv preprint。
- 改用 pull，不要 push用新進員工的類比，不先灌知識，直接派工作讓 agent 去問、去補；也拿 TDD 比喻，先給它一定會失敗的問題。
- 示範環境講者用 Claude Code 搭配 skills、rules、agents、hooks 實作，用平面檔案代表 Confluence、Slack、GitHub 等 monolith。
- 示範：單一事件的根因分析agent 先找知識庫、找不到就列出缺的清單；講者補上答案後，它把新知識寫回去，實體數從 56 個左右再增加。
- 14 個事件跑完整輪重複 14 個事件，信心分數一路拉到 4.4；講者的說法是 agent 從知識的消費者變成知識管理者。
- 自動化：用歷史工單掃知識庫手動跑太痛苦，改拿 Jira、事故、客服工單批次驗證，分三步：產生 probes、執行、分析缺口。
- 彙整成缺口看板每個事件列出缺的資訊，再彙整成 clean、stale、incomplete、missing、tribal 等分類，產生 Kanban board 讓團隊像處理工單一樣補文件。
- 知識存哪裡：GitHub 與 metamodel講者偏好用 GitHub repo，因為自帶 PR 與 review，之後還能發佈到 Confluence 或 Slack；另外建議搭配 metamodel 當 agent 的地圖。
- 實際看到的價值與限制最大的價值是把從沒寫下來的東西挖出來，並讓 agent 自己做知識管理；知識庫已經很完整的小團隊用處不大，手動做很痛苦，講者也坦言方法還很早期。
- 它在流程裡的位置這套方法夾在 monolith 與 retrieval layer 之間，做出像快取一樣的 context blocks；講者用 80/20 法則，其餘留成連結。
- 帶回家的三樣東西與動手試講者列出 GitHub repo 與 starter guide、現場的 context gap scanner，以及拿一張自己的工單丟給 agent 的簡單 prompt。
- Q&A：範圍要縮到一個團隊有聽眾問是否只在玩具規模試過；講者說企業或領域層級需要太多專家，縮到最小的團隊才快又有用。
- Q&A：程式碼與 Confluence 打架有聽眾說合併 codebase 與 Confluence 的結果不穩定，因為兩邊文件重複；講者說要定義誰是 source of truth，這部分自己仍在處理。
- Q&A：事前修，不在營運時修有聽眾提到自己的 skill 是靜態的；講者說選擇在 retrieval 之前把 context 修好，一個團隊花幾週就能補到六到八成。
- Q&A：長 context 與相關論文講者估計單一領域約 96k tokens，直接放進 context window 比做 RAG 好；也提到一篇與此相近的論文。
- Q&A：過時文件與權限講者的流程用最後更新日期標出疑似過時，但只通知、由人決定；權限直接靠 GitHub，若做成產品才需另外處理。
- Q&A：延伸到業務流程與重複文件同一套做法可延伸到業務流程的缺口；掃描時也會標出同一份資訊散在多個版本的重複。
- Q&A：成本講者估計 context gap scanner 掃一次，連 1 美元都燒不到，不需要每天跑。
- Q&A：細節與縮小範圍每張工單的結果會寫成約 100 或 150 行 markdown；範圍縮到團隊、幾週內就做得完，先看整體現況再修。
- Q&A：用會議逐字稿當知識庫有聽眾提議直接餵會議逐字稿；講者說看各組織的情況，若對話裡有資料就能用，並搭配壓縮。
名詞
- institutional knowledge
- 只存在公司內部與人腦裡的領域知識，是講者認為 agent 最缺的一塊
- tribal knowledge
- 大家知道怎麼做、但從沒寫下來的知識，講者估計約占企業知識的 40%
- context blocks
- 把整坨知識庫拆成 agent 用得上的小塊內容，是這個方法要產出的東西
- Demand-Driven Context
- 講者提出的方法：用 agent 做不出來的問題逼出缺的知識，再整理回知識庫
- context gap scanner
- 講者做的工具，拿過去的事件去驗證知識庫，找出缺漏、過時與重複
- probes
- 掃描時先產生的基本測試，用來檢查知識庫能不能回答某個事件
- metamodel
- 描述業務流程、系統、API 與術語如何互相關聯的結構，講者用來當 agent 的地圖
- MCP / RAG
- 業界目前補 institutional knowledge 的 retrieval layer 做法
- Claude Code
- 講者示範用的 agent，用 skills、rules、agents、hooks 實作這個方法
- IKEA
- 講者任職的公司，講者說平常在工作上用 Copilot 實作
