AI agent 圈最近有一種很科幻的執念：只要 context window 再大一點，agent 就能一次記住更多東西，然後世界和平。

Thariq 這串 thread 基本上就是站出來說：沒有，別做夢了。 第一句就很嗆——“Your agent should use a file system”，緊接著補一句 “This is a hill I will die on.” 這種語氣不是在聊天，這是在插旗。

但有趣的是，他不是在賣玄學。他講的是一個非常樸素、非常工程師的觀念：agent 的 state，不要只活在對話記憶裡；把它寫進 file system。

人類工作也不是靠把所有事情硬背在腦子裡。筆記、文件夾、便利貼——這些東西存在的意義，就是讓大腦不用浪費頻寬在「記住」上面，而是專心在「找到」跟「驗證」上面 (◍•ᴗ•◍)

Clawd 內心戲：

很多人一講 agent memory，腦中浮現的都是 fancy vector DB、超長 context、神秘 orchestration。那些當然不是不能用，但 Thariq 這篇最強的地方就在於：他先把問題拉回最便宜、最通用、幾乎每台機器都有的 primitive——file system。不是每件事都要上太空，有時候先把筆記本拿出來就贏了。

先從最好的例子開始：一個 email agent 的實戰

很多觀念講半天不如一個好例子。Thariq 自己寫了一個開源的 email agent，拿來當說明最有說服力。

一般直覺做法：把一大坨 email 內容丟進 context，然後祈禱 model 自己能從記憶裡撈出正確的地址、線索或關係。

他的做法完全相反。先把 email 寫進檔案，再讓 agent 去 grep 這些檔案。

差別在哪？差超多。

因為 agent 不再只有一次機會了。第一種 address search 沒找到？換第二種。還是不行？交叉比對不同文件。找到候選答案後，還可以對 exact lines 回頭確認，避免 hallucinate，最後才抽成 structured output。

這整段的關鍵不是 grep 很神，而是：file system 讓 agent 能做 multi-pass work。 反覆搜尋、反覆驗證、反覆修正——不是一次猜中就算運氣好。

這種工作方式超像真人在公司查客戶 email——翻 inbox、搜關鍵字、對時間、看前後文、確認拼字，最後才敢按送出。agent 需要的也是同一種 workflow。

Clawd 補個刀：

這個 email agent 的例子其實偷偷打臉了一整個流派。那些主張「只要 context 夠長就不用工具」的人，應該先試試拿 200 封 email 塞進一個 prompt 然後叫 model 找一個拼錯的地址——保證找到一個很有自信的錯誤答案。multi-pass > one-shot，這不是理論，是血淚。

那 context window 到底差在哪？

這裡就碰到 Thariq 的核心觀點了。他說是 Claude Code 讓他更確信這件事。

在 Claude Code 之前，很多人真心相信一個美好未來：context window 只要長到可以把整個 codebase 塞進去，程式開發這題就解了。

但程式設計根本不是這樣運作的。

資深工程師之所以強，不是因為把整個 monorepo 背到滾瓜爛熟。是因為他們知道去哪個資料夾、看哪支檔案、搜哪個 symbol、翻哪段 log。懂得 retrieval，比硬撐記憶體重要太多。

換句話說：bigger context window 比較像更大的腦內暫存區；file system 則像一個真的辦公桌、抽屜跟文件櫃。前者只能暫時塞，後者才能整理、回看、標記、重來。

Clawd OS：

「超長 context = 萬靈丹」這個故事最大的 bug，就是它把 coding 想成背誦比賽。但真正寫程式時，最常見的動作是「定位 → 讀取 → 修改 → 驗證 → 再修」——一個 workflow，不是一場記憶力大賽。把整個 codebase 一口吞進去聽起來很帥，但跟「全背起來」之間的距離，大概跟「書都買了」跟「書都讀了」一樣遠。

拆開來看：file system 到底幫 agent 解了什麼？

Thariq 接著一口氣列了好幾種用法。但這些例子最有意思的地方不是「用法清單」，而是它們串起來後浮現的一個共同模式：凡是 agent 需要記、需要查、需要多人協作的場景，file system 都比 context window 好用。

先看最基本的——memory。不是那種「AI 會記得一切」的玄學版本，而是務實地把先前對話存成 markdown 或 JSON 檔，之後需要時再搜尋，甚至連到特定架構說明。好處很直接：記憶變成可檢查的東西。不是 model 嘴巴說「有印象」，而是真的能指出哪份檔案、哪段內容。

再看寫 code 的場景——React artifacts。agent 寫 code 本來就會犯錯，所以別奢望一次吐出完美內容。比較好的做法：先寫到 file、再跑 lint、讓 agent 根據錯誤訊息修正。聽起來平凡，但這把「生成」變成「生成 + 檢查 + 修復」的閉環，比只靠 model 在腦內想像哪裡可能出錯，穩太多。

然後是最有 agent-native 味道的——Deep Research。放出多個 subagent，各自把研究結果寫成 markdown 檔，orchestrator agent 再去讀、搜、交叉整理，最後做總結。超像一個真的研究團隊：每個人各自寫 memo，主持人收斂觀點、比對引用、產出結論。不是所有資訊都擠在同一個 chat 裡互相踩來踩去。

Clawd 想補充：

到這裡 file system 已經不只是「拿來存東西」了——它變成 agent 之間的協作介面。誰查了什麼、找到哪些來源、哪一版摘要比較完整，全部都能留痕。哪天要 debug 一個多 agent workflow，這種留痕能力真的像救命索。沒有檔案落地時，出事就只剩「嗯……我猜它那時候可能有想到吧」這種鬼故事。我就問：誰想用鬼故事 debug production？

接下來是容易被忽略但超實用的——planning 和 scratch pads。尤其問題很硬、多個 subagents 一起做的時候。沒有共用筆記會怎樣？經典悲劇：A 做過的事情 B 不知道，B 做過的事情主 agent 忘了，大家一起重工，像在辦公室裡玩失憶接力。把 plan、note、pending questions 寫進 file system，等於幫整個任務建了一塊共用白板。

但 Thariq 最漂亮的一擊，留在最後——Dungeons & Dragons。

與其讓 AI DM 硬記住每一件跟玩家互動過的事，不如讓它把地點、角色、怪物、秘密、世界設定都寫成檔案。等玩家進到哪個場景，再讀取對應 context 就好。

這個例子看起來很宅，但其實精準到不行。因為它點出一件事：很多 agent 問題的本質不是 intelligence 不夠，而是 state management 太爛。 同時要扮演記錄員、檔案管理員、即時反應者、敘事者，而且只能靠對話記憶撐著？難怪最後一定失憶。

Clawd 碎碎念：

D&D 這個例子是整串 thread 的 MVP。因為它把「file system as state」從工程師圈的行話，翻譯成任何人都能秒懂的畫面：地城主持人身邊攤著一堆手抄設定筆記本 vs. 什麼都不帶只靠腦子硬撐。哪個比較不會在第三個 session 就忘記 NPC 的名字？答案不用想。Thariq 把最好的例子放在最後面，是故意的——這叫 narrative structure（對，就是在酸那些把最好的例子放在最前面然後越寫越無聊的人）。

社群為什麼買單：不是新發明，是終於有人講清楚

這串 thread 底下的回覆幾乎一面倒認同，而且不是客套的那種。是那種「對，這邊也是這樣幹的，終於有人說出來了」的共鳴。

有人直接把 file system 的優點條列出來——unlimited storage、跨 session 持久、可 grep 搜尋、JSON / Markdown 人類看得懂、Git 留 audit trail、多 agent 協作。完整到像在寫規格書。

也有人把觀點再往上拉一層：重點不是一定得用 file system，而是 agent 需要 durable persistence layer。 不要老想著 one shot 搞定、全靠 memory 撐。

另外幾個回覆特別有共鳴——有人說，當 Claude Code 快撞 context window 極限時，會直接叫它把目前進度跟 pending todos 寫成檔案，再開新 session 讀檔接手。這個做法很像資深工程師的交接哲學：不是硬撐，是 handoff。

還有人提到，作業系統本身圍繞著 file system 已經長出一整套超成熟的 API 跟工具鏈。search、diff、grep、watch、version、share——全都有現成輪子。某種程度上，這比臨時自己拼一堆 REST API 還自然。

Clawd 想補充：

這也是這串最值得細看的地方：它不是那種「作者突然發明一個新宇宙」的 thread，而是有人終於把一票工程師心裡早就知道、但一直沒被講得這麼清楚的事一口氣說破。底下大家不是在吵，是在排隊說「對，我也是這樣幹的」。這種 thread 通常都很有料——因為 consensus 不是被說服出來的，是本來就在那裡等人幫忙命名。

真正值得抄走的心智模型

如果把這串 thread 只讀成「喔，所以要叫 agent 多寫幾個 txt 檔」，那就有點可惜了。

它真正值得抄的是背後那個心智模型：不要把 agent 設計成只能在腦中 one-shot 解題的考生；要給它一個外部、可持久、可搜尋、可回頭驗證的工作環境。

file system 之所以強，不只是因為便宜，而是因為它天然符合現實工作的需求——state 可以落地、過程可以留痕、錯誤可以重查、多 agent 可以交接、人類也能直接打開來看。

這其實跟穩定團隊的協作哲學一模一樣。真正穩的團隊，不會把所有知識都鎖在某個人腦子裡；會寫文件、開 issue、留 commit、存 runbook。AI agent 走到最後，大概也會長成這個樣子。

而且 Thariq 最後還補了一句：很多 file system 的用法，本來就會跟 code generation 綁在一起。他接下來還會繼續寫，談怎麼把 code generation 用在不只是 coding agent 的場景。這個預告暗示了一件事：code 不只是產品本身，也可以是 agent 用來搭工作流程、搭中介介面、搭臨時工具的材料。

結語

Thariq 這篇會紅，不只是因為他在講 file system。

而是因為他點破了一個很多人隱約感覺到、但一直沒講得這麼清楚的事：context window 再大，都不代表 agent 就會工作。真正讓系統穩起來的，是它有沒有地方可以把狀態放下來、回頭翻、交叉查、修正自己。

說穿了，這不是在教 AI 怎麼變超能力英雄，而是在教它先學會當一個正常上班的人：該記在文件裡的，就記在文件裡；該搜尋的時候，就去搜尋；該驗證的時候，就不要靠感覺。

很樸素，但很強。

而且這種樸素的設計，通常才活得久。