AI Engineer Europe 2026 · 工作坊 · 2026-05-03 · 101 分
讓 agent 懂組織的 context engine
Mergeable by default: Building the context engine to save time and tokens · Peter Werry，Unblocked
Peter Werry 先談 context engine 為何不等於 RAG 或多接幾個 MCP，再帶大家動手做 social graph builder，後半是長長的 Q&A。
概要
- 人成了 agent 的瓶頸Peter 說以前由人當 context engine，自己抓 ticket、餵資料。現在同時管好幾個 agent，要一直切換脈絡，很難把任務交給背景 agent，除非有東西懂程式碼與組織的來龍去脈。
- 存取不等於理解接上一堆 MCP 或自建 RAG，agent 還是看不出資料之間的關係與原因。Peter 舉的例子是一個動到 Anthropic thinking 設定的任務：沒有 context engine 時，agent 蓋掉了依賴舊做法的程式碼；有了之後，它看到原因並保留向下相容。
- 三個迷思與 satisfaction of searchPeter 認為 naive RAG、多接 MCP、更大的 context window 都不夠。agent 找到第一個像答案的東西就停手，真正關鍵的線索可能在 Slack 對話或事故報告裡。
- 三個踩過的坑先前只求能存取、不求理解；用簡單策略處理衝突，卻沒把解不開的衝突攤出來；把答案快取起來重複使用，也不能拿舊答案當新答案的脈絡。
- 數字對照Peter 說同一個大任務，沒有 context engine 要兩個半小時、21 million tokens，有的話 25 分鐘、10 million tokens，但也承認那張圖的數字是 Claude 產出的，要看的是整體感覺。
- 動手做 social graph builder後半段請大家加入 Slack 與 GitHub repo，一起改進這個從程式碼庫的 PR 與 review 關係推出團隊與專家的小工具。Peter 說這個 org 會留到週末，之後開源，貢獻者會掛名。
原話
▶ 07:52“Without context, I'm just gonna reemphasize this point, you'll probably end up in doom loops.”
沒有脈絡，我要再強調一次，你很可能陷入 doom loop
▶ 09:05“Access doesn't mean understanding.”
能存取不代表理解
▶ 24:57“everything changes constantly, right? Code changes. Docs change.”
Peter 解釋為何不該快取答案：程式碼和文件都一直在變
▶ 31:09“AI-generated code should just feel like it was written by someone that's been in your team for like 20 years.”
Peter 說 AI 產生的程式碼該像團隊裡待了二十年的人寫的
▶ 1:27:14“you can't really leave it up to the agent to do memory hydration because that's kind of like part of the seed context.”
記憶的載入不能交給 agent 自己來，因為那是起始脈絡的一部分
延伸
- Peter 說 social graph builder 的 AI 步驟只用來替團隊命名，不跑也行；一段 Q&A 另外提到 Slack 與 Teams 的版本要用不同的做法。
- Peter 提到 Unblocked 另有一套 code review 元件可接上 SCM，這場只簡短展示了一個 PR 範例。
- 地端部署只簡單說明有提供但不建議，沒有展開細節。
章節
點時碼直接跳到原片的那一段。
- 開場與議程Peter 說明這場分成一段演講加一段動手做，演講講三個迷思與幾個教訓，再一起做 social graph。
- 什麼是 context engineagent 一開始對程式碼與組織一無所知，會先到處翻；context engineering 是只給需要的脈絡，讓它照組織慣例做事。
- 人怎麼累積組織脈絡回到沒有 AI 的年代，新人靠摸程式碼、跟著前輩、經歷事故累積「為什麼這樣做」，這是 context engine 要補的東西。
- 從自動補全到背景 agentPeter 沿用 Basim Eldath 的採用曲線（自己也說姓氏可能唸錯），從 2022 年 8K token 的自動補全講到並行 agent、MCP 與雲端背景 agent。
- 人成了瓶頸與 doom loop同時管好幾個 agent 會一直切換脈絡；Peter 認為模型夠聰明了，缺的是脈絡，沒有脈絡就會掉進 doom loop。
- 存取不等於理解接上一堆 MCP 或自建 RAG 也看不出資料之間的關係；Peter 用一個改 Anthropic thinking 設定的任務對照有無 context engine。
- 三個迷思Peter 逐一反駁：naive RAG、多接 MCP、更大的 context window 都不等於 context engine。
- Satisfaction of search借用放射科的說法：找到第一個解釋就停手；agent 也會在 Notion 或 Confluence 停下，漏掉 Slack 與事故報告裡的關鍵。
- context engine 該懂什麼要懂你是誰、在哪個團隊、專家是誰、決策怎麼走到現在；要分真假、承認解不開的衝突，並沿用原本的存取權限。
- 六項需求與做法Peter 走過統一系統脈絡、衝突處理、針對任務與個人的檢索、資料治理，衝突處理先偏向新的、再偏向程式碼，最後認為要看專案接下來往哪走。
- 實驗數字與三個教訓同一個大任務，沒有 context engine 要兩個半小時、21 million tokens，有的話 25 分鐘、10 million tokens；接著講三個踩過的坑。
- 哪裡最值得接規劃與 review 效益最大，另外有 ticket 補全、事故分流、客服與工程支援頻道，也能掛進 CI。
- 實際例子展示 Unblocked 在 PR 上留的 review，以及兩份任務逐字紀錄經 Claude 比較後，團隊選了有 context engine 的方案。
- Q&A：產品形式與適用範圍聽眾問 context engine 到底是什麼形式、跟 LLM Wiki 的關係、是否只限工程；Peter 說明介面形式並表示目前聚焦工程。
- Q&A：權限、合成與衝突合成要在各自有權限的範圍內做，或用 group ID 標記；知識圖譜由程序建立再由 LLM 提煉，衝突在匯入與執行時各處理一次，人也可以回饋。
- 動手做：加入並認識 social graph請大家加入 Slack 與 GitHub repo，Peter 展示 social graph builder 的團隊圖、專家頁與互動圖。中間的邀請與排錯時間一併略過。
- Q&A：大家用哪些 agentPeter 秀出使用比例，Claude Code 最多，其次是 Cursor，也有不少人用 Claude Desktop。
- social graph 跟探索型 agent 的差別探索型 agent 每次都得寫程式重建圖；Peter 說明專家當成檢索的起點，還有「bottling the expert」的做法。
- 動手：用 agent 跑 repo建議把 repo 丟給 agent 跑，要設時間範圍或 PR 數量；也回答了自主 agent 與企業知識萃取的問題。
- 對比設計與圖譜演算法回應聽眾對比較公平性的疑問，並說明從只算 PR 數到 SCM 演算法、向量叢集與 LLM 提煉的演進。
- 排錯與第一批 PRfork 與寫入權限出狀況，邊補邀請邊等到第一批 PR 進來，Unblocked 也在 Slack 自動回答。
- 儀表板與對客戶展示價值有聽眾問怎麼對客戶展示；Peter 展示儀表板，並說這類產品很難不接上資料就展示價值。
- 回饋如何變成記憶使用者回饋會被提煉成任務記憶，專家的意見權重較高；記憶對 agent 呈現為檔案，底層是資料表並在執行時組裝。
- 衡量成效與回應速度Peter 說內部有 benchmark 但偏「氛圍」，也看情緒分數；自主化之後答案要準比回應快重要，Brandon 補充了兩個半小時任務的細節。
- 資料更新頻率資料有的即時、有的靠排程，圖譜增量更新，最佳實務約每週提煉一次。
- 隱私與地端部署隱私在組織層級談，敏感環境提供地端方案但不推薦，因為更新較慢、維運吃力。
名詞
- context engine
- 替 agent 供應需要、且只供應需要的組織脈絡，包括程式碼、對話、決策原因與專家是誰
- Unblocked
- Peter 所屬公司的產品，這場以它的做法為例，介面包括 MCP server、CLI、儀表板與 Slack
- doom loop
- Peter 的說法：跟 agent 反覆來回修正，最糟是放手跑完整個任務卻整個錯
- satisfaction of search
- 借自放射科：找到一個解釋就停止搜尋，agent 也會這樣漏掉更重要的線索
- social graph builder
- 這場 workshop 的範例專案，從 repo 的 PR 與 review 關係推出團隊、專家與程式碼區域的覆蓋度
- bottling the expert
- Peter 的說法，把某位專家做過的事、做過的決策提煉成脈絡，當作檢索的起點
- group ID
- 合成資訊跨越權限邊界時，附上標記，只有有權限的人才取得
- GraphRAG
- Peter 提到它逐層摘要，難免跨越權限邊界，所以要劃出各自獨立的區塊
- Brandon
- Peter 的同事，協助 Q&A 與 workshop 現場
