Claude 4.7 Memory 與 Agent Team 實戰：自建 Brain 系統的真正價值

Anthropic 在 2026 年 4 月發布的 Claude Opus 4.7 在 memory 和 Agent Team 兩塊都有顯著改進。但這些「改進」對已經自建知識架構的開發者來說，究竟是關鍵升級還是錦上添花？本文整理一天的深度討論，對比 Claude 原生機制和自建 Brain 系統，並落地一套可跨機器攜帶的 bug 追查框架。

Part 1：Memory 系統 — 4.7 改了什麼，對我有什麼用

Claude 4.7 的三個 memory 改進

Claude Opus 4.7 在 memory 方面的改進可以拆成三個層次：

1. 檔案式 memory 變「一等公民」：4.7 特別訓練用檔案系統當 memory（scratchpad、notes、structured store），能主動寫筆記且下次對話時知道去讀筆記。
2. Cross-session 穩定性提升：跨多 session、多小時的工作流程一致性更好，模型會依 brain 和 memory 的指引從上次停下的地方接續。
3. 1M context 無長 context 溢價：原生百萬 token context window，不另收費。以前 200K+ 要 /compact 的場景現在一口氣吃完。

Cross-session memory 的真相：沒有魔法，只有檔案

很多人以為 Claude 4.7 的 cross-session memory 是某種「核心系統」幫你串起過去對話。真相是：session 之間仍然完全隔離，模型本身沒有跨 session 的任何 state。所謂 cross-session，是 Claude Code 在新 session 開啟時自動注入：

• CLAUDE.md（你寫的指令）
• MEMORY.md 和 topic files（auto-memory 累積的筆記）
• 過往 session summary（Claude Code 自動寫的摘要檔）

這些全是檔案，不是隱藏的 cloud memory。4.7 改進的不是機制，而是對這套檔案機制的使用熟練度：知道什麼該寫、該去哪讀、讀到後如何套用。

自建 Brain 系統 vs Claude 原生 auto-memory

如果你已經有自建的 Brain 系統（跨專案的技術 domain 知識庫），對比 Claude 原生 auto-memory 會發現：本質是相同機制，差別在淬煉程度。

面向	Claude 原生 auto-memory	自建 Brain 系統
範圍	單專案（綁 cwd）	跨專案（按技術 domain 分類）
載入時機	Claude Code 自動注入	CLAUDE.md 宣告 Domain Brain: 主動載入
curation	模型自動（容易塞流水帳）	手動規則過濾（Why / How to apply 格式）
外部知識	僅記錄當前對話	支援 [source: external] 納入社群/文章的坑
配套	memory 單打獨鬥	Brain + Skill 配對（坑 vs 對的做法）

4.7 對自建 Brain 的實際收益

對已經有成熟 Brain 系統的開發者，Claude 4.7 的 memory 改進主要體現在兩個地方：

• Context 吞更多（70% 的價值）：1M context 可以同時載入所有相關 brain + CLAUDE.md + 當前 code，不再被切斷。多個 brain 同時載入 5000+ 行也不爆。
• 維護判斷力（30% 的價值）：叫 Claude 整理 memory 時，4.7 會主動去讀 brain 檢查重複、按規則格式寫，而不是無腦 append。4.6 可能直接塞、不去重。
• 自動 cross-session 對自建系統無感：已經有 Brain + CLAUDE.md 宣告機制的用戶根本不依賴 auto cross-session，品質比自動版高。

關鍵洞察：模型版本升級 ≠ 知識管理升級。Anthropic 再怎麼升級內建 memory，都在解決「模型如何維護筆記」。但「什麼知識該存、怎麼結構化、跨專案怎麼轉移」是架構設計問題，不是模型能力問題。

Part 2：Agent Team — Named sub-agent 真正解決什麼

4.7 的四個 Agent Team 改進

• Named sub-agents：spawn 時給名字，後續用 SendMessage({to: name}) 續接，不用重跑 context
• Permission 繼承修正：user-level permissions 現在會正確傳給 teammate，不再每個 teammate 都跳一堆授權 prompt
• 個別 teammate 可調 mode：spawn 後可以用 Shift+Tab 單獨切換某個 teammate 的 permission mode
• /team-onboarding：自動分析使用歷史產生 ONBOARDING.md，幫新隊友快速上手

前置條件：要啟用 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1，否則 SendMessage 工具根本不存在。

Named sub-agent 和 Team A/B/C 的差異

很多人以為 named sub-agent 是在取代自組 Team 的做法，其實兩者是不同層次的機制，互補而非競爭。

面向	Team A/B/C（宏觀）	Named sub-agent（微觀）
解決什麼	多工平行	單工延續
邊界	不同 task 之間	同 team 內部 agent 之間
Context 燒法	每個 team 獨立燒一份	同 agent 只燒一次，後續增量
適用場景	早上開 3 件不相干的事	追一條長 bug / 深入一個模組

最佳組合是兩者混用：宏觀 Team 隔離不同主題，微觀 named agent 讓每個 teammate 有連續記憶。等於開三家公司並行做不同案子，每家公司裡的同一個員工連續給你服務，不是每次都新人上場。

已知限制：teammate 之間不能互喊

目前 Claude Code 有個已知 bug（GitHub issue #48160）：subagent 本身不能 originate SendMessage。意思是 teammate A 想主動找 teammate B 協作做不到，所有通訊必須經過 team lead 路由，變成星形拓撲（hub-and-spoke）而非 mesh。

另外 delegate mode 有個連帶效應：lead 切到 delegate mode 後，它的權限限制會傳給 teammate，導致 teammate 也不能讀檔、跑命令，整個 team 卡住。解法是 spawn teammate 時明確放寬權限。

Part 3：實戰落地 — Bug 追查框架

為什麼開發和修正要用不同的 agent 拓撲

對話中得到一個清晰的洞察：「開發」和「修正」性質不同，應該用不同的 agent 拓撲。

Case	啟動策略
開發（新 feature）	Team A/B/C 並行，短 context agent，各管一塊
修正（bug / fix）	單一 named agent + PUA，多輪深挖
重構（無新功能）	單一 named agent，多檔追蹤 side effect

認真追 bug 的 agent 應該有的樣子

一個 bug 不是「修好就算了」。它有根本原因（root cause）、爆炸半徑（blast radius）、和教訓（lesson）。停在第一個看似合理的修補是 bug 改頭換面回來的最快路徑。認真的 bug-hunting agent 應該有三層結構：

1. 方法論（如何思考）：PUA 式修辭壓力 — 從不接受第一個假設、永遠挑戰自己的推理、窮盡所有替代方案。
2. 延續性（如何記住）：Named 長壽 agent 跨輪次攜帶 context，不要每輪重新 spawn 新 agent 失去歷史。
3. 事後教訓（如何教未來）：每個修好的 bug 都要更新 brain，否則知識死在這個專案。

三層缺一不可：沒方法論 → 停在第一個合理原因、出 bandaid；沒延續性 → 每輪重講 context、走回原路；沒事後教訓 → 同一個 bug 六個月後在別專案又出現。

頻道韌性：為什麼要假設「無法中斷」

有些 channel（Bot wrapper、API-based tools、async chat）無法真正中斷正在跑的 turn，用戶的輸入只能排進下一輪。框架設計時要把這當前提：

• 每個 hunter 步驟要快速 return 控制權，不要 chain 10 個 tool call
• 長任務用 run_in_background: true 讓 lead 儘快 ready
• 在自然 checkpoint 回報進度，讓用戶在下一輪調整方向
• 把用戶輸入當戰略路線修正，不是即時操舵

如果頻道可中斷（CLI）那是 bonus，不是前提。框架不該依賴可中斷性。

Skill fallback：沒有 PUA 也要能跑

如果你在多台機器工作，可能某台有 pua:pua-debugging skill、某台沒有。框架要具備graceful degradation：

• Skill 優先：有 PUA / systematic-debugging skill 時，讓 hunter 載入 — skill 是維護中的、品質更新快
• Brain 兜底：把 PUA 的核心精神內嵌到 brain 檔，確保沒 skill 的機器也能按內建規則運作

內嵌的規則例如：「假設你的第一個假設是錯的，立刻列出兩個會產生同樣症狀的替代方案」、「修好了 trigger 下一個問題：為什麼以前會壞？」、「症狀只能『大致』解釋 = 沒被解釋，真正的 root cause 能解釋所有觀察，包含奇怪的那些」。這套 inline rule 讓 brain 成為 skill 缺席時的 safety net。

結案 checklist

一個 bug 追查只有在全部滿足以下條件才算完：

• Bug 可重現（或明確記錄為何無法重現）
• 根本原因以白話講清楚
• 修復已驗證（重現原 failure → 套用 fix → 確認 failure 停止）
• 爆炸半徑評估（同一個 root cause 還可能壞掉什麼？）
• Brain 檔已更新（domain 對、[source: project] tag 已加）
• Commit message 以 fix: 開頭，而且 brain 更新發生在開始下一個 task 之前

為什麼這套設計 model-agnostic

整套 Brain + Skill + Agent Team 設計最大的優勢是 model-agnostic：未來換 Opus 5.0、換 Gemini 3、換 GPT-5，只要該模型支援讀檔案 + 自訂 instruction 機制，整套可以直接搬過去。

Auto cross-session memory 綁在 Claude Code 內建機制上，換 tool 就沒了。自建 Brain 是把架構設計前置到模型之外 — 模型只負責執行，架構你自己定。結果是：

• 4.7 再強，沒 Brain 也是亂塞
• 4.6 再弱，有 Brain 也能跑
• 未來換任何 LLM，這套設計直接移植

這其實很接近個人化 RAG 系統的雛形 — 只是沒用 vector DB，用人類可讀的 markdown + 手動路由。反而更可控、更可維護。

結論

Claude 4.7 的 memory 和 Agent Team 改進都是實實在在的能力提升，但對已經有自建知識架構的開發者來說，真正的護城河不在追著升級模型，而在建立 model-agnostic 的架構設計。

• Memory：用 Brain 做跨專案長期記憶、用 MEMORY.md 做專案短期筆記、用 Skill 存對的做法 — 三者分工明確。
• Agent Team：宏觀 Team A/B/C 並行處理不同主題 + 微觀 Named sub-agent 保持任務延續性 — 互補使用最強。
• Bug 追查：方法論（PUA）× 容器（Named agent）× 事後教訓（Brain 更新）三層結構，對頻道韌性和 skill 缺席都要有 fallback。

模型會一代代升級，但你累積的 Brain 不會過時 — 因為它記錄的不是模型能力，是你自己踩過的坑和學到的道理。