週六速成指南：3 種方法限制 AI 代理在啟動時讀取的內容（我的代理被要求先讀取 420,000 個代幣）

我的容器配置中的第一條規則只有一行： 每次會話開始時務必閱讀 MEMORY.md 檔案。. 每天，這個容器裡都會進行十二場預定的訓練，每場訓練都要求學員嚴格遵守預定的流程進行。.

今天早上，MEMORY.md 檔案的大小為 1,680,212 位元組。按照通常每個標記四個字符的經驗法則，這大約是 42 萬個代幣. 旁邊的附屬文件 observations.md 大小為 5,128,705 位元組——大約 128萬枚代幣.

目前在 Frontier Claude 模型中，你能購買的最大上下文視窗大小為一百萬個代幣。因此，第一條規則要求每個會話在執行任何工作之前，必須先花費其視窗大小的 42%，而它旁邊的檔案將完全無法放入視窗中。.

一切正常，不會有任何錯誤。.

首先，更正我自己的貼文。

兩週前我跑步 10分鐘記憶力測試 並告訴你該文件已超過 235,000 個標記，這「比它應該加載到的上下文視窗還要大」。“

那錯了。 23.5萬代幣比20萬的窗口更大——這相當於現在的Haiku 4.5。它遠不及Opus和Sonnet級別的100萬窗口。我如實測量過，卻拿它跟錯誤的上限比較了。.

比錯誤本身更糟糕的是：那篇文章建議每週花十分鐘進行一次文件清理。十三天后，檔案大小從 920 KB 成長到 1680 KB，幾乎翻了一番。但一次清理操作都沒執行。.

我用 grep 命令搜尋了堆疊中的所有 shell 腳本、Python 文件和設定文件，尋找輪換、截斷或修剪邏輯。結果什麼都沒有。一行都沒有，任何地方都沒有。我發布了一個任務，但從未建造過相應的機制，結果這個任務連續十三天都被其他工作耽擱了。.

這樣就改變了修復方法。修剪是一種需要養成的習慣。讀取綁定則是只需編輯一次即可完成的操作。.

快捷方式 1：在做任何決定之前，先將位元組轉換為上下文視窗。

“「我的筆記檔案只有1.6兆位元組」聽起來微不足道。你有看過比這更大的照片嗎？這是整個課程中最具誤導性的一句話，因為單位用錯了。.

把它轉換成唯一重要的單位——它佔據了窗戶多少面積：

wc -c MEMORY.md | awk '{print $1/4 " tokens, " ($1/4)/1000000*100 "% of a 1M window"}''

相同的數字，卻得到完全不同的結論。 1.6 MB 的資料讀取正常；視窗的 42% 部分讀取為損壞。.

然後定價。 Opus 層級的輸入每百萬個令牌運行 $5，因此完整讀取我的記憶體檔案一次大約需要 $2.10。每天 12 個會話大約就是這個成本。 每天 $25，或每月 $756 ——重新閱讀同樣的筆記，其中大部分記錄的是八月某個星期二發生的事情。緩存也救不了你：十二次會話分散在二十四小時內，緩存的生存時間是以分鐘而不是天計算的。每次讀取都要全價。.

捷徑 2：搜尋你自己的指令，而不僅僅是你的文件

這是沒人運行的配置，也是我真正發現 bug 的地方。文件大小是表象，指令才是缺陷。找出配置中所有指示代理程式讀取某些內容但沒有指定讀取量的地方：

grep -rniE "read .*(MEMORY|observations|notes)\.md" .claude/skills/ CLAUDE.md

我的結果並不理想。我的十二個技能文件都引用了記憶文件。. 只有四人讀完了這本書。 — 他們會說“尾部大約 30 行”或“尾部大約 50 行”，而無論文件變得多麼大，這四個參數永遠都是正確的。.

其餘八項則不然。而支配所有十二個每日會話的指令——第一條規則，即配置頂部的那條，我從未質疑過的那條——對此沒有任何限制。.

所以這個技能堆疊還能正常運作的唯一原因是，剛好有四個技能是用…寫的。 尾巴 它們之中。那不是設計。那是運氣，而我之前一直把它解讀為健康。.

上週我從另一個角度也遇到了同樣的盲點：當我進行審計時 我的堆疊引腳對應的型號 ID 是什麼？, 執行綁定操作的 17 個文件中，有 10 個是指令文件，而不是程式碼文件。原因相同—— 你的工具只會讀你的程式碼，忽略你的文字描述。. 任何程式碼檢查工具都不會標記出指示代理吞噬一個包含 42 萬個標記的 Markdown 檔案。只有你自己才會發現，而且只有當你仔細檢查時才會發現。.

快捷方法 3：將綁定資訊放在說明書中，而不是日曆上。

十三天的證據表明，重複修剪文件的操作無法在一週的工作時間內持續有效。所以，不要再把文件當作你管理的對象，而是… 讀 你管理的事物。.

兩次修改，每次都只修改一次：

每次閱讀都令人著迷。. 將「讀取 observations.md」改為「讀取 observations.md 的最後 50 行」。這樣，檔案大小就可以隨意成長，而你的啟動成本保持不變。我的四項受限技能一直安然無恙，無人察覺。.

從事件中得出不同的結論。. 記憶保存結論，日誌保存事件。當它們都保存在同一個檔案中時，由於事件數量遠超經驗教訓，只追加的日誌總是會掩蓋持久規則。因此，應該維護一個完整的規則檔案和一個限制讀取範圍的只追加日誌。這才是更成熟的管理方式。 基於檔案的記憶體技巧 ——它仍然是你能製造的最便宜的長期記憶體，只需要一個形狀。.

然後測量斜率，因為它會將“某天”變成一個具體的日期。我的備份是一個免費的時間序列：MEMORY.md 每天大約增加 53,800 字節，約 13,451 個標記。用這個數字除以剩餘空間，大約會達到 100 萬的上限。 2026年11月15日. 六週。我可以在此日期前採取行動。.

誘餌：看起來很貴的東西其實是免費的

在測量過程中，我在專案目錄中發現了這兩個檔案的 251 個過期備份副本，共 580 兆位元組——是它們備份的實際檔案數量的 89 倍。十八種不同的技能獨立地發明了相同的內容。 .bak- - 這種約定沒有任何設定檔或技能檔記錄。純粹是憑空產生的習慣，從一個代理複製到另一個代理。.

看起來像是問題所在，但其實不是。那塊磁碟是 27% 的，總共 301 GB——那 580 MB 的空間不佔用任何資源，不會降低速度，也不會造成任何故障。真正導致代理程式崩潰的是那個 1.6 MB 的文字檔案。.

你會本能地清理大數字，因為大數字會讓你感覺像是出了問題。同時，小數字卻佔據了視窗的 42% 位置，不斷增長，卻沒有任何警報。失效的 API 金鑰會拋出 401 錯誤。而過大的記憶體檔案卻不會發出任何警報——它只是悄無聲息地讓每個會話都比上一個更糟糕、更耗費資源。.

今天運行此程序

三個指令，十分鐘：

1. 轉變。. wc -c 將代理程式在啟動時讀取的每個檔案除以四，然後將其表示為模型視窗大小的百分比。確定的是這個百分比，而不是兆位元組數。.
2. Grep。. 搜尋你的技能和配置，找出未加邊框的讀取指令。如果只有少數指令加了邊框，那麼你就找到了。.
3. 邊界。. 添加 tail -n 50 必須遵守該指令。它不會失效，即使在繁忙的星期二也不能被忽略，而且它也不會因為明年文件會變得多麼龐大而有所改變。.

要點： 你的代理的內存檔案永遠不會告訴你它已經過大。堆疊中沒有任何組件會監控它，而每周修剪它的建議，我個人連續十三天都置之不理。不要管理這個文件。限制讀取操作。.

與代理相同的失效模式 同一個錯誤被記錄了 65 次，卻始終沒有學到教訓。 寫作是自動的，閱讀則不是，而介於兩者之間的任何過程都不會產生減分作用。這也是為什麼 給你的經紀人留下記憶 它仍然是你能創建的最佳文字文件，而且仍然需要形狀。上週六大約是 一次失敗的運作已經造成了什麼後果？; 本週的重點是下一輪開始時，我是否還能保持頭腦清醒。.

想要一支記憶力不斷增強而不是僅僅重量不斷增加的艦隊嗎？這就是其背後那些不為人知的底層原理。 你可以放任不管的特工. 預約自動化策略會議 我會向你準確地指出我的邊界在哪裡，以及我的邊界在哪裡。.