資料累積 與記憶設計的差異
原圖的核心論點：*「Memory is raw material. Retrieval is the operating layer.」*多數團隊持續累積資料，卻沒有設計「如何在正確時機把對的資料交給 Agent」的機制。
公司的運作知識通常分散在對話、Slack 串、會議錄音裡，而非集中於 wiki。當需要這些知識做決策時，傳統做法是召集相關人員開會；人員離職後，知識也隨之消失。採購部、品保部、跨部門例會的存在，本質上是用「人」來補「無法儲存決策脈絡」這個缺口。
人能從零碎片段重建脈絡，但 AI Agent 無法做到同等效果。將所有資料塞進向量資料庫，通常會產生混雜的檢索結果。模型本身的能力不是瓶頸，缺的是在特定時刻應當載入哪六塊資料的判斷機制。
擴大記憶體不等於提升答案品質。精準檢索才是運作層的核心。
Anthropic 將「脈絡（context）」列為 AI Agent 最稀缺的資源。前沿模型的能力已非瓶頸，真正導致 Agent 在生產環境失效的，是它不了解公司的運作規則，包括如何定義「有效客戶」、上一通電話承諾了什麼、法務標記過哪些禁區。這張地圖將上述問題拆解為六階段可執行的運作系統。
散落的公司情境
原圖左欄列出八種「原始訊號」來源。各來源獨立存在時，資訊易於流失，即原圖所述：「Disconnected context is lost context」。
Slack 訊息串
決策、進度更新、問答。最真實的即時對話，但最容易被洗掉。
客戶通話 / Demo
銷售對話、產品演示、客戶提出的反對意見與洞察。
CRM 紀錄
聯絡人、商機、活動歷程、業務筆記（如 HubSpot）。
SOP 文件
流程文件、操作手冊、檢查清單，記錄「正確做法」的官方版本。
銷售筆記
探詢、後續追蹤、客戶反對點、口頭承諾。
內容決策
主題、切角、論點、定位，以及各項選擇背後的理由。
主管修正
策略調整、語氣修正、明令不可碰的禁區（no-gos）。
每日日誌
今天發生什麼、什麼變了、下一步是什麼。
六階段運作流程
原圖中央主軸，定義了將原始訊號轉化為可執行知識的六個階段。階段順序固定，缺少任一前置階段，後續階段均無法正常運作。
1 · Capture · 捕捉
原始材料進入系統
記錄工作產出、通話、決策，並保留來源 metadata。**捕捉階段的職責是儲存，不包含理解或分析。**資料在此階段進入系統，後續階段負責處理。
記錄工作產出
轉錄通話
記下決策
保存修正紀錄
留存來源資訊
2 · Retrieval · 檢索
真正的運作層
在每次請求時，僅載入當下最相關的脈絡片段。Agent 不需要存取全部資料，需要的是當前任務最相關的六塊。此階段的品質決定是否能控制 context bloat，並減少重複解釋的需求。
給當下對的脈絡
任務專屬記憶
只拉重點
避免 context bloat
減少重複解釋
3 · Source Truth · 來源真實性
誰說了算
定義來源衝突時的優先順序，例如「即時 CRM」vs「舊版 SOP」、「通話逐字稿」vs「Slack 上的更正」。未定義來源層級時，Agent 會把任意片段當成事實，以高信心回答錯誤的答案。
即時 CRM vs 舊 SOP
逐字稿 vs Slack 更正
對外安全 vs 僅供內部
歷史脈絡 vs 當前真相
4 · Permissions · 權限
讓大腦可以安全使用
定義各角色與工作流的存取範圍，包括客戶資料邊界、HR/財務隔離、對外內容安全。未設存取控制的知識系統，會將機密資料暴露給無權限的工作流。
誰能看什麼
工作流層級存取
客戶脈絡邊界
HR / 財務隔離
對外內容安全
5 · Feedback Loops · 回饋迴路
每一次修正都強化系統
設計原則：每一個修正，都應轉化為一條規則。包括語氣規則、來源規則、CRM 風險規則、路由規則。累積規則後，重複性錯誤的出現頻率會下降。
修正→規則
語氣規則更新
來源規則更新
路由規則更新
重複錯誤消失
6 · Execution · 執行
帶著脈絡、證據與更少的來回把事做完
前五階段完備後，Agent 在每次啟動時已載入相關脈絡：報告自動生成、內容附帶來源佐證、通話洞察可直接轉為 playbook，操作者無需從頭提供背景資訊。
Agent 起手更聰明
報告自動生成
內容自帶佐證層
pipeline 浮現風險
不再從零開始
六條鐵則
六條鐵則是整張地圖的摘要，各對應一個容易忽略的設計決策。
1 · 捕捉是儲存，不是智慧
資料量多不等於系統具備理解能力。儲存只是第一步。
2 · 精準檢索優於擴大記憶體
在當下挑出六塊相關資料，比將全量資料塞入 context 更有效。
3 · 來源優先序防止誤引
定義衝突時哪個來源優先，Agent 才能裁決而非猜測。
4 · 存取控制是系統安全的前提
未設邊界的知識共享，會將機密資料暴露於不應存取的工作流。
5 · 每個修正都該轉化為規則
單次更正不會被系統記住；轉化為規則後才能持續生效。
6 · 系統應隨使用而累積知識
每次互動後系統的回答品質應有所改善，而非每次重新冷啟動。
自動化前的 六個審查問題
將工作流交給 Agent 前，先用這六個問題確認系統設計完整。無法回答其中任何一題，代表該工作流尚未具備自動化的前提條件。
Q1 · 這個工作流需要哪些來源？
列出 Agent 必須能讀到的訊號，缺一個都會降低品質。
Q2 · 來源衝突時，哪個贏？
事先定義優先順序，不要讓模型臨場猜。
Q3 · 哪些脈絡是「永遠必要」？
找出每次都得載入的核心規則（hot memory）。
Q4 · 哪些脈絡不應被引用？
明確定義禁區，比模糊的「盡量小心」在執行層面更為可靠。
Q5 · 哪些修正會重複出現？
重複性錯誤是最值得轉化為規則的候選項目。
Q6 · 一個修正如何轉化為規則？
回饋迴路的最後一步若未設計完整，修正無法累積為系統知識。
複利型運作智慧
六階段與六鐵則完整部署後，效益會逐步疊加，而非線性累加。原圖將此稱為 Compounding Operating Intelligence。
決策速度提升
依據脈絡行動，不依賴猜測。
交接效率改善
減少重複說明，提高接手準確度。
產出品質提升
內容具備相關性、準確性與來源佐證。
任務切換成本降低
脈絡持續存在，減少重新建立情境的時間。
重複性錯誤減少
修正轉化為規則後，系統持續生效。
機構記憶累積
知識隨使用而增長，形成競爭門檻。
壞模型 vs 好模型
| 模式 | 運作鏈條 |
|---|---|
| Broken | Prompt→ Output→ 回饋散落→ 決策遺失→ 重來（冷啟動） |
| Working | 通話/CRM/SOP/Slack→ 檢索對的脈絡→ Agent 熱啟動→ 產出（帶 artifacts）→ 審核修正→ 變成規則 |
One Source of Truth單一可信來源
Decisions Are Logged決策被記錄
Context Is Curated脈絡經過策展
Access Is Controlled存取受控管
Feedback Is Compounded回饋會複利
Memory Is An Edge記憶就是優勢
從零到 生產環境的實作路徑
以下是一條務實的部署路徑，適用於從無到有建立公司大腦系統。起點建議：先不使用向量資料庫，過早引入向量檢索是常見的過度工程。
從結構化檔案開始，而非向量庫
社群的一致建議：先用「結構化檔案 + 規則文件」（例如
CLAUDE.md/AGENTS.md等常駐記憶檔案），通常已能滿足八成需求。待知識量大到單一檔案無法承載時，再引入向量檢索。略過此步直接使用 Pinecone，是最常見的過度工程。記憶分三層：熱記憶、專責 Agent、冷記憶
三層架構適用於大型程式碼庫與企業知識庫：熱記憶（每次請求都載入的規則與慣例）、專責 Agent（按領域分工）、冷記憶（可按需檢索的規格文件）。將規則與細節文件分離，是系統可擴展的前提。
每筆記憶標記 scope
採用 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，而非升級模型。
管理 context bloat 與 context rot
過多脈絡會降低模型回應品質、增加延遲與成本，並導致相同輸入產生不同結果。LangChain 提出四種管理策略：Write（寫入 scratchpad 或外部記憶）、Select（只載入所需片段）、Compress（壓縮摘要）、Isolate（多 Agent 隔離）。Claude Code 的
/compact指令採用相同邏輯。從單一工作流開始，先建立回饋迴路
不建議一次自動化全公司的工作流。選擇一個高頻、低風險的工作流（例如客服分類、會議摘要），先將「修正 → 規則」的迴路跑通，再擴展至其他工作流。缺少回饋迴路的自動化，只會放大錯誤的影響範圍。
r/AI_Agents、r/LocalLLaMA、r/Rag 社群實作討論摘要
以下整理自 r/AI_Agents、r/LocalLLaMA、r/Rag 及 Hacker News，收錄反覆出現的實作建議、工程取捨與真實使用案例。
Rag · 踩坑
多數需求不需要向量庫
社群反覆出現的建議：80% 的需求可用「整理好的結構化檔案 + 規則文件」解決。過早引入 Pinecone/Qdrant 的實作者，後續多在排查檢索延遲與 chunking 切割問題。
// hack：先 grep，撐不住再 embedding
AI_Agents · 心法
檢索品質決定輸出品質，而非模型規模
常見的實作結論：升級模型無法改善差的檢索結果。投入 chunking 策略、hybrid search 與 reranking，效果優於更換更大的 LLM。
// 「大多數 RAG 問題都是檢索問題」
LocalLLaMA · 工程
使用 scratchpad 外部檔案管理長任務
長任務中，讓 Agent 將計畫與進度寫入外部檔案（scratchpad），按需讀回，而非全部塞入 context window。Anthropic 的多 Agent researcher 採用相同模式，在接近 token 上限前先將計畫存入記憶。
// write → select → compress → isolate
AI_Agents · 權限
權限外洩的危害高於幻覺
多人共用的公司大腦系統中，最常見的嚴重問題是權限外洩，例如一般查詢意外拉取到 HR、財務或其他客戶的資料。建議每條 read path 都進行 per-user scope 隔離，採預設拒絕策略。
// 預設拒絕，逐項開放
Rag · 維運
過期資料會導致 Agent 引用失效文件
舊文件未清除時，Agent 可能引用已作廢三個月的 SOP，且回答看起來正確。對策：為每筆記憶標記時間戳與來源優先序，確保即時 CRM 的優先序高於舊文件。
// timestamp + source priority = 必備
AI_Agents · use case
回饋迴路的起點：會議逐字稿自動化
社群分享較多的成功案例，是將通話或會議逐字稿自動轉為「決策 + 待辦 + 寫入 CRM」。此類工作流具備高頻率、低風險、時間節省可衡量等特點，適合作為建立回饋迴路的第一個試點。
// 從高頻的例行工作流開始
LocalLLaMA · 隱私
自架記憶層的需求增加
不希望將公司脈絡鎖定於特定 SaaS 的團隊，傾向選擇自架（Supabase + MCP）或 local-first 方案。主要考量是資料主權與長期可攜性，這與原圖末段的論點一致：Memory is a competitive edge。
// own your memory layer
AI_Agents · MCP
工具數量過多會降低 Agent 的選擇準確率
透過 MCP 掛載大量功能重疊的工具，會導致 Agent 選錯工具或產生不存在的參數。系統成熟度的指標不在於可接工具的數量，而在於能精確控制 Agent 在任務中可見的工具範圍。
// 工具也要做 curation
將六階段設計 寫入 System Prompt
以下範例將六階段邏輯直接嵌入「公司大腦檢索 Agent」的系統提示。可作為基礎範本修改使用，重點在於如何強制執行 來源真實性、權限管控與回饋迴路。
company-brain-agent.system.md
# 角色 ─────────────────────────────────
你是 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 turn）
User: 幫我準備等下跟 Globex 的續約電話，他們的價格我們答應過什麼？
Agent（理想輸出）:
你們在 2026/05/12 的通話中口頭承諾「續約維持原價，並送 3 個月進階支援」。
此後 CRM 未更新新價格，且無主管修正紀錄推翻此承諾。
依據：
· call_transcript · Globex 續約討論 · 2026/05/12（優先序 3）
· live_crm · Globex 帳戶 · 最後更新 2026/05/20（優先序 1，未變更價格）
信心：medium ── 我沒看到法務對「進階支援」條款的書面確認，建議開會前向法務確認。記憶是原料，檢索才是運作層
這張地圖的核心價值在於設計視角的轉換：從「我們存了多少資料」，改為「Agent 在此刻能否取得正確的六塊脈絡」。將捕捉、檢索、來源真實性、權限、回饋、執行六階段逐一完整建立，公司大腦就能從資料倉庫，發展為持續累積知識的競爭優勢。
建議起點：選擇一個高頻、低風險的工作流，以本文的 Prompt 範例跑通「修正 → 規則」迴路，再擴展至其他工作流。
概念與視覺改編：Tenten — https://tenten.co 內容整合自 AI Agent 記憶／context engineering 之公開研究、產品文件，以及 r/AI_Agents、r/LocalLLaMA、r/Rag 與 Hacker News 等社群討論。技術名詞保留英文原文。