從 CLAUDE.md 到「做夢」：上下文工程如何把模型智力變成可用系統

模型變聰明不夠：要把智力變成可用系統，靠上下文工程。從 CLAUDE.md、Skills 漸進揭露、檔案系統式自主記憶，到生產級版本／並行／權限，再到頻外 Dreaming 鞏固跨 session 學習。

江中喬

15 7月 2026 • 10 min read

模型一直在變聰明。但把原始智力部署進「你的程式碼庫、你的組織、你的偏好」時，單靠智慧很難自動產生倍增效果——它需要情境。而這些情境，往往與模型本身有多聰明無關：你們怎麼 code review、什麼能合併、使用者喜歡什麼寫作風格、上次同一個任務踩過什麼坑。

Anthropic Applied AI 的 Lamis 在一場關於上下文工程的演講裡，把過去一年的路徑講得很清楚：從簡單有效的 Markdown，走到代理自主管理記憶，再走到生產級護欄，最後用名為 Dreaming（做夢） 的頻外程序，把「這次做完」收成「下次整體更強」。本文整理那條路徑，並對齊工程上可落地的判斷——也作為「Agent 記憶不是一個向量庫」的續篇：上篇談分層，本篇談自主記憶如何長出來、又如何不在生產裡炸開。

為什麼上下文工程值得投資

開箱的模型不可能精確知道如何在你的環境裡「照你的意思」做事。上下文工程的報酬結構是：

模型升級時，你策展過的情境仍在；智力與情境相乘，而不是每次從零教。

沒有這層時，典型症狀是：

代理不熟 codebase，每次重新摸索
不懂個人或組織偏好
下次執行不會更好——沒有從錯誤學習的閉環

持續學習若只發生在「再訓一個大模型」，成本高、節奏慢；若能發生在記憶與脈絡管線，迭代可以跟產品開發同頻。

一年演進：簡單且有效

Anthropic 常用的紀律是：做簡單且有效的事。 過去一年大致四站：

1. CLAUDE.md——開頭注入的航向

工作階段開始時，把 Markdown 指令注入上下文前端：熟悉 repo 的方式、組織慣例、使用者偏好。效果「好得不可思議」。

限制也立刻出現：檔案越來越長 → 上下文膨脹；誰維護、如何隨時間演化，變成新問題。
但原則留下了：人類可讀、代理可寫、雙方都能改的 Markdown，是極強的控制面。

2. 頻內記憶工具——讓代理自己管

下一步是：讓代理自主決定何時讀、寫、更新記憶，且多半在同一工作階段內完成。少預設立場去規定工具必須長什麼樣。

學到：在正確範圍內，自主性非常有效。代理開始為「未來的自己」留下筆記。

3. Skills——漸進式揭露

Skills 解決的是「什麼都想塞進 context」。聰明處在 progressive disclosure：

先只載入檔案頂部的前置資訊（名稱、描述、少數元資料）
需要時再載入正文細節

比喻：房間裡有書架。對話時先掃書名；對方說法文，再抽法文字典——不必預載七年法文課。
Skills 特別適合你已有頭尾想法的程序化工作流。瓶頸是：技能目錄仍常由「人＋代理」共同決定「什麼值得做成 skill」，主觀性高。

4. 把記憶建成檔案系統——當前實務主線

把上述學習收斂成一個模型：記憶系統 ≈ 檔案系統。

裡面可以塞滿 Markdown
代理本就擅長 Bash、Grep 等一般檔案工具——讓它們搜尋，而不是只准用某個專用「記憶 API」
索引＋智慧搜尋，本身就是另一種漸進揭露

關鍵操作要點：

Markdown 很適合被讀
庫可以長大，但要能快速索引與檢索
寫入時給代理自主權

單人、單工作區時，這套常帶來明顯的「持續學習感」：第二次做同一類任務，更快、更準。

上生產時，美好想法會撞牆

多代理、長時間、複雜 codebase 一上，問題成批出現：

風險	後果
多代理同時寫同一記憶	覆蓋、競態、不可重現
代理把錯誤寫進「組織級」上下文	錯誤被所有人讀到、災難擴散
人與代理共編記憶	難審計、難回滾
過時、寫錯、惡意注入	記憶成為攻擊面與腐蝕源

因此需要一組工程護欄——不是否定自主，而是讓自主可規模化。

生產級四原則

版本控制

每次更新可回溯。最好還能回答：這次改動依哪次 session／哪段逐字稿？誰（哪個代理、哪個人）做的？效果變差時，才能回滾，而不是「記憶壞了從頭再來」。

並行（樂觀鎖）

寫入流程可以是：取記憶內容的 hash → 起草修改 → 提交前再取 hash → 不符則重拉、重寫、再試。這是多代理共享記憶庫的基本 SE 紀律，不是重新發明浪漫。

權限分層

層級	建議
組織級原則／目標／關鍵 codebase 規範	多為唯讀；改動走審核
部門／專案共享	受控寫入
代理個人草稿本／工作記憶	可寫、可丟

你不會希望單一代理「自行決定」覆寫全公司脈絡。

可攜

策展過的記憶是資產。用簡潔 API 暴露，讓多產品、多 runtime 能讀寫同一套脈絡——否則記憶鎖死在單一工具裡，投資折舊極快。

把「代理有創意地管理記憶」與上述護欄合在一起，才是生產可用的形狀。效益往往不只準確率：更少重試、更少 token、人也能把注意力放回產品，而不是反覆重教同一件事。

頻內記憶的天花板

頻內（in-band）記憶：代理在執行任務的同一 session 裡讀寫（例如 Claude Code 工作階段內的記憶行為）。

它有兩個結構性限制：

資源競爭
你同時要求它完成任務，又要求它為未來整理記憶。多少算力給「現在」、多少給「明天的自己」，是很難的即時最佳化；還會拉高延遲。
視野受限
單 session 看不到跨 session 的重複失敗；多代理時也看不到別的代理踩過的坑。使用者覺得「怎麼每次都犯同樣錯」——對代理而言，每次都是新窗。

另外，記憶會過時，需要檢查機制確認寫入是否仍正確。

學校比喻：全班交作業，需要有人批改、有人俯瞰規律；若每個學生邊考試邊改全校教材，既分心又短視。

Dreaming：記憶的二階、頻外處理

Dreaming（做夢） 是針對記憶的批次、非同步、有專屬資源的二階程序——不跟當前用戶任務搶同一條注意力。

它做什麼

現有記憶庫
+ 一段時間的對話／逐字稿
  （含工具呼叫、skills、中繼資料，不只聊天文字）
→ 協調者部署子代理分析逐字稿
→ 找出跨任務／跨代理的模式
→ 提出對記憶庫的修改建議
  （最好附：範例逐字稿、普遍程度、為何該改）
→ 人（或政策）接受／拒絕
→ 次日代理「感覺更聰明」

它能發現什麼

知識缺口：某類題全錯 → 記憶／「課程」裡根本沒教
工具設定錯：全員同一類 tool 失敗 → 更新用法與前提
組織風格：不喜歡的寫作習慣 → 組織級指令
系統層規律：只有俯瞰多份逐字稿才看得到的失敗模式

成本疑慮

「為什麼要額外燒 token？」——若記憶庫有效，代理更常一次做對，總成本與延遲常不升反降。Dreaming 是用離線算力買線上效率。

與頻內記憶並行

	頻內記憶	Dreaming
時機	任務進行中	批次、背景
視野	單次 session	跨 session、可跨代理
資源	與任務競爭	專屬預算
見效	下一 session 就可能變好	庫級升級，影響面更大

實作上可引導負責寫記憶與做夢的代理：什麼算組織相關、什麼該忽略——把做夢對齊你們的領域，而不是通用空轉。

企業場景還要注意：觸發 Dreaming 時選定納入哪些逐字稿，權限與記憶庫一致；不要預設「抓時段內全部使用者資料」，否則背景程序會變成權限旁路。

實務路徑：你現在處在哪一階

階段	建議動作
個人／小專案	CLAUDE.md + Skills；必要時 repo 內 Markdown 記憶目錄
開始痛「每次重教」	讓代理可寫記憶；用搜尋／索引，勿只靠超長注入
多代理或長跑	上版本、hash 並行、權限分層、審計
要跨 session 真正變聰明	設計 Dreaming 類批次鞏固（自建或託管 Memory／Dreaming API）

不必一開始就自研完整「代理資料庫」。Q&A 裡的提醒很實用：先看清哪些必須確定性（版本、鎖、權限）——這些寫進框架；哪些留給代理自主（寫什麼、怎麼組織筆記）。有效的部分產品化，而不是為了自主而重新發明輪子。

這套也不限 coding：簡報語氣、寫作偏好、決策風格，同樣能進記憶與做夢閉環。

和記憶分層怎麼接

分層（上篇）	本篇機制
Session／Events	逐字稿來源；Dreaming 的原料
State	任務中結構化便利貼；不宜當唯一長期記憶
Profile	穩定事實；權限上常偏「受控寫入」
Memory Bank	檔案庫／可搜尋記憶；要版本與權限
（新增視角）頻內 vs 頻外	任務中書寫 vs Dreaming 鞏固

向量庫可以是檢索引擎之一，但策展、權限、版本、做夢才是讓記憶變成系統能力的骨架。

結語

上下文工程的一年，不是在堆更炫的名詞，而是反覆確認一件事：簡單可讀的脈絡載體 + 代理自主 + 漸進載入，遠比一開始就上複雜中間件有效；而一旦多代理、長時間、組織級共用，就必須把軟體工程裡已驗證的版本、並行與權限，接回自主記憶——最後用頻外的 Dreaming，補上單次 session 看不見的學習。

做簡單且有效的事。
讓代理在護欄內自己記。
需要閉環時，讓系統也會做夢。

模型會繼續變聰明。
會不會在你的世界裡變好用，取決於你是否把情境建成可演化、可稽核、可倍增的基礎設施。

延伸閱讀

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。