（系列：《AI 維運實戰：我用 Hermes 把 Agent 變成企業同事的 30 天》）
（主題：將 AI 模型整合進實際系統與產品的工程實踐）

上一篇把 Profile 切開後，新問題立刻出現：每位 Agent 都有自己的工作空間，但公司知識到底放哪裡？

如果答案是「放進模型記憶」，很快就會失控。財務口徑、工程 SOP、客戶交接與外部研究，生命週期完全不同。全部塞進 memory，不只浪費上下文，也無法追來源、做版本管理或交給人員審閱。

我最後把 Company Brain 設計成四層查詢架構，而不是一個超大的資料夾。

────────────────────────────────

四層知識，各自解不同問題

查詢順序是 L1 到 L4。近、短、穩定的資訊先取；需要原文證據時回到 Obsidian；關鍵字不明確或資料分散時，再用 QMD 擴大召回。

這不是把資料複製四份。每層只負責自己的工作。

────────────────────────────────

唯一原始資料層，為什麼選 Markdown

我的決策是：Obsidian Vault 裡的 Markdown，才是 Company Brain 可編輯的原始資料。

理由很務實：

1. 人可以直接閱讀與修訂。
2. Git、備份與檔案工具都能處理。
3. frontmatter 可保存 type、status、confidence、owner 與權限範圍。
4. wikilink 能把來源、概念、實體、決策與行動串起來。
5. 不會被某個向量資料庫或單一產品綁死。

QMD 可以重建，embedding 也可以重算；但公司制度、決策理由與來源紀錄不能靠索引反推回來。可重建的是衍生物，不可重建的才是原始資料。

────────────────────────────────

第一次盤點，暴露的不是缺資料

2026 年 8 月的一次全量盤點，當時掃到 307 篇 Markdown。候選分類中，行銷 132 篇、AI Agent 與自動化 64 篇，另有 11 篇待人工確認。

真正的問題不是「資料太少」，而是資料很多，卻不一定能形成公司行動。收藏一篇文章，不等於公司已經學會；搜尋得到，也不等於能直接採用。

因此我沒有先大搬家。來源頁保留原位置，再用 frontmatter、wikilink 與分類標準建立關聯。自動分類沒有把握的內容進待人工確認，不直接升格，也不刪除。

這是我踩過的重要認知錯誤：知識庫不是檔案倉庫，搜尋成功也不是知識治理成功。

────────────────────────────────

分類要能一路走到執行

Company Brain 先按公司治理、職能部門、人員與職位、技術與 AI、決策與執行等區域整理。內容型態則分成 Source、Concept、Entity、Synthesis、Decision、Action。

理想流程是：

原始來源 → 可複用概念 → 具體實體 → 跨來源判斷 → 決策或行動

例如，一篇社群貼文只能先當 Source，並標示可靠度。它不能因為寫得有道理，就直接變成公司 SOP。只有經過查重、交叉驗證、連到既有知識，並由適當 owner 採納後，才可能形成 Decision 或 Action。

每筆重要知識至少要能回答：誰需要知道、誰負責、影響什麼決策、下一步是什麼，以及如何驗證完成。

────────────────────────────────

公司大腦不是「全員可看全部」

集中知識不代表取消權限。公司公開知識可以共用；內部流程依職能開放；個資、薪酬與績效必須標示 confidential；財務與客戶資料則依角色授權。

Agent 能搜尋某個來源，也不代表它有權修改、分享或對外發布。能力與授權要分開，否則 Company Brain 只會把原本分散的風險集中起來。

────────────────────────────────

今天的結論

Company Brain 的價值，不是讓 Agent 記住更多，而是讓人與 Agent 都能找到同一份、可追溯、可治理的公司知識。

L1 記憶保存穩定規則，L2 Wiki 解釋系統，L3 Obsidian 保存原始 Markdown，L4 QMD 負責搜尋。最關鍵的決策，是只保留一套可編輯真相來源，其餘都視為可重建的查詢層。

下一篇 D10：我會拆開 QMD 的 SQLite、BM25 與 embedding 索引，說明為什麼它是 Obsidian 的衍生搜尋層，而不是第二套知識庫。