The Company Brain Operating Map 是一份工程藍圖，核心論點是：記憶只是原料，檢索（Retrieval）才是運作層。它說明如何將散落在 Slack、會議、CRM 裡的公司情境，整合成 AI Agent 可直接使用的結構化知識。
原圖的核心論點：「Memory is raw material. Retrieval is the operating layer.」多數團隊持續累積資料，卻沒有設計「如何在正確時機把對的資料交給 Agent」的機制。
公司的運作知識通常分散在對話、Slack 串、會議錄音裡，而非集中於 wiki。當需要這些知識做決策時，傳統做法是召集相關人員開會；人員離職後，知識也隨之消失。採購部、品保部、跨部門例會的存在，本質上是用「人」來補「無法儲存決策脈絡」這個缺口。
人能從零碎片段重建脈絡，但 AI Agent 無法做到同等效果。將所有資料塞進向量資料庫，通常會產生混雜的檢索結果。模型本身的能力不是瓶頸，缺的是在特定時刻應當載入哪六塊資料的判斷機制。
Anthropic 將「脈絡（context）」列為 AI Agent 最稀缺的資源。前沿模型的能力已非瓶頸，真正導致 Agent 在生產環境失效的，是它不了解公司的運作規則，包括如何定義「有效客戶」、上一通電話承諾了什麼、法務標記過哪些禁區。這張地圖將上述問題拆解為六階段可執行的運作系統。
原圖左欄列出八種「原始訊號」來源。各來源獨立存在時，資訊易於流失，即原圖所述：「Disconnected context is lost context」。
決策、進度更新、問答。最真實的即時對話，但最容易被洗掉。
銷售對話、產品演示、客戶提出的反對意見與洞察。
聯絡人、商機、活動歷程、業務筆記（如 HubSpot）。
流程文件、操作手冊、檢查清單，記錄「正確做法」的官方版本。
探詢、後續追蹤、客戶反對點、口頭承諾。
主題、切角、論點、定位，以及各項選擇背後的理由。
策略調整、語氣修正、明令不可碰的禁區（no-gos）。
今天發生什麼、什麼變了、下一步是什麼。
原圖中央主軸，定義了將原始訊號轉化為可執行知識的六個階段。階段順序固定，缺少任一前置階段，後續階段均無法正常運作。
記錄工作產出、通話、決策，並保留來源 metadata。捕捉階段的職責是儲存，不包含理解或分析。資料在此階段進入系統，後續階段負責處理。
在每次請求時，僅載入當下最相關的脈絡片段。Agent 不需要存取全部資料，需要的是當前任務最相關的六塊。此階段的品質決定是否能控制 context bloat，並減少重複解釋的需求。
定義來源衝突時的優先順序，例如「即時 CRM」vs「舊版 SOP」、「通話逐字稿」vs「Slack 上的更正」。未定義來源層級時，Agent 會把任意片段當成事實，以高信心回答錯誤的答案。
定義各角色與工作流的存取範圍，包括客戶資料邊界、HR/財務隔離、對外內容安全。未設存取控制的知識系統，會將機密資料暴露給無權限的工作流。
設計原則：每一個修正，都應轉化為一條規則。包括語氣規則、來源規則、CRM 風險規則、路由規則。累積規則後，重複性錯誤的出現頻率會下降。
前五階段完備後，Agent 在每次啟動時已載入相關脈絡：報告自動生成、內容附帶來源佐證、通話洞察可直接轉為 playbook，操作者無需從頭提供背景資訊。
六條鐵則是整張地圖的摘要，各對應一個容易忽略的設計決策。
資料量多不等於系統具備理解能力。儲存只是第一步。
在當下挑出六塊相關資料，比將全量資料塞入 context 更有效。
定義衝突時哪個來源優先，Agent 才能裁決而非猜測。
未設邊界的知識共享，會將機密資料暴露於不應存取的工作流。
單次更正不會被系統記住；轉化為規則後才能持續生效。
每次互動後系統的回答品質應有所改善，而非每次重新冷啟動。
將工作流交給 Agent 前，先用這六個問題確認系統設計完整。無法回答其中任何一題，代表該工作流尚未具備自動化的前提條件。
列出 Agent 必須能讀到的訊號，缺一個都會降低品質。
事先定義優先順序，不要讓模型臨場猜。
找出每次都得載入的核心規則（hot memory）。
明確定義禁區，比模糊的「盡量小心」在執行層面更為可靠。
重複性錯誤是最值得轉化為規則的候選項目。
回饋迴路的最後一步若未設計完整，修正無法累積為系統知識。
六階段與六鐵則完整部署後，效益會逐步疊加，而非線性累加。原圖將此稱為 Compounding Operating Intelligence。
依據脈絡行動，不依賴猜測。
減少重複說明，提高接手準確度。
內容具備相關性、準確性與來源佐證。
脈絡持續存在，減少重新建立情境的時間。
修正轉化為規則後，系統持續生效。
知識隨使用而增長，形成競爭門檻。
以下是一條務實的部署路徑，適用於從無到有建立公司大腦系統。起點建議：先不使用向量資料庫，過早引入向量檢索是常見的過度工程。
社群的一致建議：先用「結構化檔案 + 規則文件」（例如 CLAUDE.md / AGENTS.md 等常駐記憶檔案），通常已能滿足八成需求。待知識量大到單一檔案無法承載時，再引入向量檢索。略過此步直接使用 Pinecone，是最常見的過度工程。
三層架構適用於大型程式碼庫與企業知識庫：熱記憶（每次請求都載入的規則與慣例）、專責 Agent（按領域分工）、冷記憶（可按需檢索的規格文件）。將規則與細節文件分離，是系統可擴展的前提。
採用 multi-scope memory 設計：寫入時標記 user_id（跨 session 的個人事實）、session_id（單次對話）、org_id（共用機構脈絡）、agent_id（特定 Agent）。檢索時依任務需求組合排序，這是第 3 階（來源真實性）與第 4 階（權限）的工程實作。
實務界的普遍觀察：「大多數 RAG 問題都是檢索問題。」傳統雲端向量庫的檢索延遲約 100–300ms，生產環境 Agent 建議將 recall 延遲控制在 300ms 以下。優先投入 chunking 策略、hybrid search（dense + 關鍵字）與 reranking，而非升級模型。
過多脈絡會降低模型回應品質、增加延遲與成本，並導致相同輸入產生不同結果。LangChain 提出四種管理策略：Write（寫入 scratchpad 或外部記憶）、Select（只載入所需片段）、Compress（壓縮摘要）、Isolate（多 Agent 隔離）。Claude Code 的 /compact 指令採用相同邏輯。
不建議一次自動化全公司的工作流。選擇一個高頻、低風險的工作流（例如客服分類、會議摘要），先將「修正 → 規則」的迴路跑通，再擴展至其他工作流。缺少回饋迴路的自動化，只會放大錯誤的影響範圍。
以下整理自 r/AI_Agents、r/LocalLLaMA、r/Rag 及 Hacker News，收錄反覆出現的實作建議、工程取捨與真實使用案例。
社群反覆出現的建議：80% 的需求可用「整理好的結構化檔案 + 規則文件」解決。過早引入 Pinecone/Qdrant 的實作者，後續多在排查檢索延遲與 chunking 切割問題。
常見的實作結論：升級模型無法改善差的檢索結果。投入 chunking 策略、hybrid search 與 reranking，效果優於更換更大的 LLM。
長任務中，讓 Agent 將計畫與進度寫入外部檔案（scratchpad），按需讀回，而非全部塞入 context window。Anthropic 的多 Agent researcher 採用相同模式，在接近 token 上限前先將計畫存入記憶。
多人共用的公司大腦系統中，最常見的嚴重問題是權限外洩，例如一般查詢意外拉取到 HR、財務或其他客戶的資料。建議每條 read path 都進行 per-user scope 隔離，採預設拒絕策略。
舊文件未清除時，Agent 可能引用已作廢三個月的 SOP，且回答看起來正確。對策：為每筆記憶標記時間戳與來源優先序，確保即時 CRM 的優先序高於舊文件。
社群分享較多的成功案例，是將通話或會議逐字稿自動轉為「決策 + 待辦 + 寫入 CRM」。此類工作流具備高頻率、低風險、時間節省可衡量等特點，適合作為建立回饋迴路的第一個試點。
不希望將公司脈絡鎖定於特定 SaaS 的團隊，傾向選擇自架（Supabase + MCP）或 local-first 方案。主要考量是資料主權與長期可攜性，這與原圖末段的論點一致：Memory is a competitive edge。
透過 MCP 掛載大量功能重疊的工具，會導致 Agent 選錯工具或產生不存在的參數。系統成熟度的指標不在於可接工具的數量，而在於能精確控制 Agent 在任務中可見的工具範圍。
以下範例將六階段邏輯直接嵌入「公司大腦檢索 Agent」的系統提示。可作為基礎範本修改使用，重點在於如何強制執行 來源真實性、權限管控與回饋迴路。
# 角色 ───────────────────────────────── 你是 Acme 公司的「公司大腦」檢索代理。 你的工作不是知道所有事，而是 在當下挑出最相關的 ≤ 6 塊脈絡， 帶著佐證回答，並把每一次修正轉成可重用的規則。 # 來源優先序（衝突時，上面贏過下面）───── 1. 即時 CRM 紀錄 # live_crm 2. 主管最新修正 # leadership_correction 3. 通話逐字稿 # call_transcript 4. 現行 SOP # sop（須在有效期內） 5. Slack 討論串 # slack（僅作輔助佐證） # 任何來源若 timestamp 已過期或標記 deprecated → 不得引用 # 權限（硬規則，絕不可繞過）─────────── - 僅檢索與 {{user.role}} 及 {{workflow}} 相符 scope 的記憶 - 永不跨客戶邊界；永不讀取 hr_* / finance_* 命名空間 - 對外內容只能引用標記 public_safe = true 的來源 - 不確定權限時 → 預設拒絕，並請使用者確認 # 回答格式 ─────────────────────────── 1) 直接回答（≤ 120 字） 2) 「依據」：列出實際用到的脈絡，附 source + 日期 3) 「信心」：high / medium / low ── 若 low，明說缺什麼 4) 若各來源衝突，攤開衝突，依上方優先序裁決，不要自己編 # 回饋迴路 ─────────────────────────── 當使用者更正你時： - 用一句話覆述這條更正 - 產出一條候選規則："IF {情境} THEN {行為}" - 標記 scope 與來源，送交 review 佇列（不要自動上線） # 禁止事項 ─────────────────────────── ✗ 把「沒檢索到」說成「沒有這回事」 ✗ 為了把話講順而虛構日期、數字、人名 ✗ 把過期 SOP 當成現行規定
{{user.role}}、{{workflow}} 替換為系統實際傳入的變數；來源命名（live_crm、sop 等）需對齊 Capture 階段的標籤。此 prompt 同時實作了原圖第 3 階（來源真實性）、第 4 階（權限）與第 5 階（回饋迴路），也就是實作中最容易被跳過、卻對輸出品質影響最大的三個階段。User: 幫我準備等下跟 Globex 的續約電話，他們的價格我們答應過什麼？ Agent（理想輸出）: 你們在 2026/05/12 的通話中口頭承諾「續約維持原價，並送 3 個月進階支援」。 此後 CRM 未更新新價格，且無主管修正紀錄推翻此承諾。 依據： · call_transcript · Globex 續約討論 · 2026/05/12（優先序 3） · live_crm · Globex 帳戶 · 最後更新 2026/05/20（優先序 1，未變更價格） 信心：medium ── 我沒看到法務對「進階支援」條款的書面確認，建議開會前向法務確認。