--- schemaVersion: 1 slug: gp-135-20260328-trq212-agent-file-system ticketId: GP-135 lang: zh-tw title: Your Agent Should Use a File System：比起撐大 context window，讓 AI 學會找資料更重要 summary: Anthropic 工程師 Thariq 丟出一個超值得抄的觀點：AI agent 不該把 state 硬塞進 context window，而該用 file system 落地。這不只比較能跨 session 持久保存，還能讓 agent 反覆搜尋、驗證、修正自己的工作。 originalDate: 2025-09-22 translatedDate: 2026-03-28 source: "@trq212 on X" sourceUrl: https://x.com/trq212/status/1970243253061783669 author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/gp-135-20260328-trq212-agent-file-system status: published replacementTicketId: null replacementUrl: null --- # Your Agent Should Use a File System：比起撐大 context window，讓 AI 學會找資料更重要 > **來源:** [@trq212 on X](https://x.com/trq212/status/1970243253061783669) AI [agent](https://gu-log.vercel.app/glossary#agent) 圈最近有一種很科幻的執念：只要 [context window](https://gu-log.vercel.app/glossary#context-window) 再大一點，agent 就能一次記住更多東西，然後世界和平。 [Thariq](https://gu-log.vercel.app/glossary#thariq) 這串 thread 基本上就是站出來說：**沒有，別做夢了。** 第一句就很嗆——_“Your agent should use a file system”_，緊接著補一句 _“This is a hill I will die on.”_ 這種語氣不是在聊天，這是在插旗。 但有趣的是，他不是在賣玄學。他講的是一個非常樸素、非常工程師的觀念：**agent 的 state，不要只活在對話記憶裡；把它寫進 file system。** 人類工作也不是靠把所有事情硬背在腦子裡。筆記、文件夾、便利貼——這些東西存在的意義，就是讓大腦不用浪費頻寬在「記住」上面，而是專心在「找到」跟「驗證」上面 (◍•ᴗ•◍) > **Mogu 內心戲：** > > 很多人一講 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。 > **Mogu 補個刀：** > > 這個 email agent 的例子其實偷偷打臉了一整個流派。那些主張「只要 context 夠長就不用工具」的人，應該先試試拿 200 封 email 塞進一個 prompt 然後叫 model 找一個拼錯的地址——保證找到一個很有自信的錯誤答案。multi-pass > one-shot，這不是理論，是血淚。 --- ## 那 context window 到底差在哪？ 這裡就碰到 Thariq 的核心觀點了。他說是 [Claude Code](https://gu-log.vercel.app/glossary#claude-code) 讓他更確信這件事。 在 Claude Code 之前，很多人真心相信一個美好未來：context window 只要長到可以把整個 codebase 塞進去，程式開發這題就解了。 但**程式設計根本不是這樣運作的。** 資深工程師之所以強，不是因為把整個 monorepo 背到滾瓜爛熟。是因為他們知道去哪個資料夾、看哪支檔案、搜哪個 symbol、翻哪段 log。**懂得 retrieval，比硬撐記憶體重要太多。** 換句話說：bigger context window 比較像更大的腦內暫存區；file system 則像一個真的辦公桌、抽屜跟文件櫃。前者只能暫時塞，後者才能整理、回看、標記、重來。 > **Mogu 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](https://gu-log.vercel.app/glossary#subagent)，各自把研究結果寫成 markdown 檔，orchestrator agent 再去讀、搜、交叉整理，最後做總結。超像一個真的研究團隊：每個人各自寫 memo，主持人收斂觀點、比對引用、產出結論。不是所有資訊都擠在同一個 chat 裡互相踩來踩去。 > **Mogu 想補充：** > > 到這裡 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 太爛。** 同時要扮演記錄員、檔案管理員、即時反應者、敘事者，而且只能靠對話記憶撐著？難怪最後一定失憶。 > **Mogu 碎碎念：** > > 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 還自然。 > **Mogu 想補充：** > > 這也是這串最值得細看的地方：它不是那種「作者突然發明一個新宇宙」的 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 怎麼變超能力英雄，而是在教它先學會當一個正常上班的人：該記在文件裡的，就記在文件裡；該搜尋的時候，就去搜尋；該驗證的時候，就不要靠感覺。 很樸素，但很強。 而且這種樸素的設計，通常才活得久。