AU2026 會後心得分享：你的知識庫就是 Agent 的「專案記憶體」

前面兩篇文章，我們把兩件事講完了：

第一篇，為什麼台灣建築營造產業需要一個開源知識庫——因為這個產業最寶貴的資產是經驗，而經驗正以每天幾個人的速度消失。那套知識庫開源在 GitHub 上（HJPLUS_Taiwan_Architect_KB），每一則條目同時是給人看的 Wiki、也是給 AI 讀的「技能」。

第二篇，知識庫是燃料，地端模型是引擎——怎麼讓引擎在你自己的硬體上轉起來，從 Ollama 到 vLLM，從 RAG 到量化，到怎麼算這筆帳划不划算。

但兩篇文章發出後，被問得最多的問題其實是同一個：

「好，燃料有了、引擎有了……然後呢？它到底跑在哪個地方？」

答案在 AU 2026 上。

Autodesk University（AU）是 Autodesk 一年一度的年度大會，全球建築、工程、營造（AEC）產業的專業人士、開發者和決策者都會聚集在一起。今年在拉斯維加斯舉辦，時間是 9/15–17。除了產品發布和技術課程，AU 也是觀察 Autodesk 戰略方向的最直接窗口——每年的主題，往往就是接下來一年產業的走向。

AU 2026 的主題只有一個字：Agent

Autodesk University 2026 剛結束沒幾天。翻完所有官方發布內容，你會發現今年的主題高度一致：Autodesk 把 AI 從「聊天框」變成「Agent」——會讀專案資料、會呼叫工具、會在人類監督下執行跨產品工作流。官方甚至推出了 Assistant Builder，讓公司把自己的 Agent 接進 Autodesk Assistant。

但對我們這種「自己建了知識庫、自己跑了地端模型」的人來說，AU 2026 最值得看的不是產品發布，而是三堂課。這三堂課加起來，回答了一個我之前沒有答案的問題：

我們建的那套知識庫，在 Agent 的架構裡，學名叫做「專案記憶體」。

四階段閉環：RUN → CHECK → STORE → APPLY

先講 AS2183 這堂課（講者 Nabil Sadeg，Nacorm CTO）。他講的是一個很具體的問題：

同一個工作流連續三週執行，每週輸入不同，但錯誤相同。每次手動修正完就遺失——修正只存在於修正後的檔案裡，下一次跑，agent 又犯同樣的錯。

他列出四種常見失敗：無回饋捕捉、無驗證、修正只存在於人類頭腦中、agent 每次收到相同的 context 從不學習專案慣例。

解法是一個閉環，四個階段：

RUN（執行）→ CHECK（驗證）→ STORE（儲存）→ APPLY（套用）→ 回到 RUN

• RUN：agent 透過一連串 tool calls 執行任務，每個 call 和結果都被記錄成 run log。
• CHECK：輸出跟 ground truth 比較。三個檢查器由便宜到昂貴：自動化規則 → 第二個 AI 模型（必須是不同模型，同一個模型有同樣的盲點）→ 人類。
• STORE：檢查結果寫入專案記憶體——修正（人類寫）、經驗教訓（agent 寫、人類確認）、專案慣例、每次 run 的分數。
• APPLY：儲存的知識改變下一次 run 的行為，分三個層級。Level 1 只是讓 agent 在每次 run 前讀取記憶體的規則——不需要改任何程式碼，成本幾乎為零。

他給了一個讓我印象很深的案例：60 個 issue 的分類任務。

記憶體狀態準確率空38%加入 5 句修正後83%冷啟動（新 session，只有記憶體）78%

那 5 句修正全是建築事實，不是 AI 知識——「這個專案的 sprinkler 工程歸消防承包商」、「這個專案的層級命名是 L00 到 L08」。Agent 自己推斷不出這些，因為每個專案的慣例都不同。

38% 到 78% 的提升，來自把知識存在伺服器裡，而不是存在聊天記錄裡。

讀到這裡如果你覺得眼熟——對，這就是我們第一篇知識庫文章開頭講的那件事。只是現在，AU 2026 上有人用一組數據把它證實了。

「專案記憶體」= 你的開源知識庫，只是學名不一樣

對照一下：

AS2183 的專案記憶體我們的知識庫條目修正（correction）踩過的坑、實務修正經驗教訓（lesson）法規讀完後的詮釋與提煉專案慣例（convention）特定專案的命名、流程慣例分數（score）（我們還沒做——這是下一步）

結構上是一樣的東西：都是把散落在人腦、聊天記錄、修正後檔案裡的知識外部化，讓任何一個 agent、任何一個新人，冷啟動就能讀到。

差別只有一件事：位置。

AS2183 強調，記憶體存在哪裡很重要——存在應用內，一個應用學到的其他工具看不到；存在一個所有工具都能讀的 MCP server 裡，記憶體才真正「屬於專案」。而我們的知識庫目前在 GitHub 上——任何人可以 clone、可以發 Pull Request，但 agent 要讀到它，還得先走一道 RAG。

這就接到下一堂課。

工具邊界，由你定義

BLD2228 這堂課（講者 Marcello Sgambelluri，AG&E）做的事情很直接：自建一個 AI 助理，透過 MCP 同時接 Revit、Robot、AutoCAD、3ds Max、Excel、Rhino。

但他現場先做了一件更有價值的事——實測官方的 Revit AI Assistant：

• 問「model 裡有幾面牆」：答對，20 面。
• 問「現在 active 的 model 名稱」：答「沒有工具可以取得」。
• 問「把牆幾何抽出並在 AutoCAD 重建」：不行，只能教你手動 export。
• 在 Revit 2025 上：功能完全不存在。

他的結論值得所有 AEC 公司記住：官方助理的能力邊界是廠商定義的；自建助理的能力邊界是你自己定義的。

他講了一句話，我直接引用：「政策文件管不住人，但工具清單管得住——沒建的工具，AI 就調不到。」

這跟我們知識庫的設計哲學是同一件事：我們不需要把整份法規複製貼上，我們需要的是經過提煉的、有明確使用情境的條目。Agent 的能力邊界，跟人的能力邊界一樣，取決於你餵給它的知識品質。

而 BES4067（講者 Michael Gustafson、Andrew Sundal）補上了最後一塊：目前 AEC 產業的 Agent 普遍在自主程度的第 2–3 階（工具呼叫、推理），第 4–5 階還在實驗。他們列了幾個真實案例——HGA 用 MCP 接公司資料倉儲、員工用自然語言問「過去類似案子的費用」；Thornton Tomasetti 基於內部資料庫做結構方案預測。

注意一個共同點：這些案例裡，Agent 真正厲害的部分都不是模型，是後頭那套「內部資料庫」。

所以，我們的下一步是什麼

把三堂課和兩篇文章疊在一起，路線其實很清楚：

1. 知識庫條目 = 專案記憶體的內容。結構已經對了，不需要重做。
2. 把知識庫包成 MCP server。現在它是 GitHub 上一堆 Markdown；包成 MCP server 之後，任何 host（Claude、Cursor、Copilot）都能直接讀，agent 在每次 run 前讀取規則——就是 AS2183 說的 Level 1，「今天就能做，成本幾乎為零」。
3. 建立測試集。AS2183 講得很明白：沒有測量就沒有改進。50–100 題已知正確答案的固定測試集，每次 run 後評分，畫出分數曲線。這也正好補上知識庫目前缺的那一塊——「分數」。
4. 工具邊界自己定。哪些是 read-only、哪些要人類批准、哪些刻意不建——這是我們的政策，不是廠商的。

收尾：知識主權，現在有技術語言了

第一篇知識庫文章裡我寫過一段話：工具的演進會把知識封裝在黑盒子裡，如果新人只會用工具、卻不知道為什麼要這麼做，他們就失去了理解、查閱、甚至挑戰這些知識的能力。

AU 2026 給了這段話一個技術版本：

Agent 的自由越多，人類要控制的越多。

AS2183 的閉環裡，寫入記憶體的每一步都有人類批准、版本化、可回滾；BES4067 反覆強調 human in the loop 不可少——工程師是建成環境的最後責任人，合約上跑不掉。

那套「控制」，具體落實下來，就是一套人類寫得懂、可以審計、可以回滾的知識庫。

我們從兩年前開始做的事，現在終於有標準的技術語言可以描述了。它不叫 Wiki，不叫 SOP，不叫「公司內部文件」。

它叫專案記憶體。

而它剛好是開源的。