凌晨一點，螢幕上又跳出「要修改這個檔案嗎？」。今天不知道第幾次按下 Enter 的同時，心裡冒出一個念頭：到底是我在自動化，還是我被自動化了？
我去翻了一輪那些自稱把 AI 編碼代理用得很順的人的分享，結果發現差別根本不在模型選得好不好，而是他們一開始就把整個場子鋪得完全不一樣。
清空上下文的方法、把工作交接出去的方法，還有一道防止闖禍的圍籬。就這三件事。抓住這三點，今天晚上你至少能讓一個視窗自己跑。
對話一變長，AI 為什麼就突然變笨了？
先給你三行結論。
- 代理人會迷路不是因為效能不好，而是對話視窗已經塞爆了。
- 解法不是摘要，而是留下一份交接文件，在新視窗從 0% 重新開始。
- 打算讓它整晚跑的話，比起放寬權限，先把它關進沙箱才是第一步。
要搞懂原因，得先看對話視窗是怎麼運作的。我們以為自己只送出了一個問題，但實際上到目前為止的整段對話，每一次都會被一起送過去。
第 10 個問題，會把第 1 到第 9 個整包黏上去一起送。就像一邊往背包裡塞石頭、一邊爬山。
看數字更有感。2026 年 7 月我打開官方文件查了一下，Claude Sonnet 4.5 和 Haiku 4.5 的上下文視窗寫的是 20 萬 tokens。模型一直在更新，你正在用的那顆一定要自己再確認一次。
而且快到上限時，它會自動壓縮（auto-compact）對話。看了幾篇相關分析，大家說大約在整體的 83% 左右就會觸發。20 萬乘以 0.83，差不多是 16 萬 6 千 tokens。本來想說應該還能撐很久，結果實際發動的點比想像中早太多。
真正的問題在於，壓縮的本質就是「摘要」。而摘要一定會丟掉東西。
但如果被丟掉的，剛好是你昨天花兩小時才敲定的例外處理規則呢？
社群心得裡最常看到的抱怨就是這句：「壓縮完之後，剛剛才修好的地方又犯一模一樣的錯。」難怪大家都建議別等到上限，在 50～60% 左右就先整理一次。
別給它摘要，給它一份「交接文件」
這裡要把思路整個翻過來。不要硬把對話接下去，而是讓它像下班的同事一樣寫一份交接文件。
想想真實職場就懂了。你不會把前任六個月份的通訊軟體紀錄整包丟給接手的人吧？頂多給一張 A4 的交接單而已。
所以每次要收工的時候，就固定丟同一句話進去：「把目前為止決定的事項、還沒完成的工作、不能動的檔案，整理成 HANDOFF.md。」然後把視窗完全清空，在新視窗裡第一件事就是叫它讀那份檔案。
三種做法擺在一起，差別一眼就看得出來。
| 做法 | 上下文 | 記憶保留 | 什麼時候用 |
|---|---|---|---|
| 就這樣一直聊下去 | 持續累積 | 表面上有保留 | 30 分鐘內的短任務 |
| 壓縮（/compact） | 變少 | 部分遺失 | 要繼續同一個任務時 |
| 清空（/clear）＋ 交接檔 | 重置為 0% | 文件寫多少就留多少，100% | 要進到下一個階段時 |
重點只有一個：把記憶放在檔案裡，而不是放在對話視窗裡。對話會蒸發，檔案不會。
再搭配一份寫著專案規則的文件（像 CLAUDE.md 那種），會更輕鬆。每次開新視窗都不用再從頭解釋一遍。
別叫一個視窗做完全部，把團隊拆開就不一樣了
把所有事情都塞給同一個視窗，其實是最沒效率的做法。一下抓資料、一下想策略、一下又改回測程式碼。這跟叫同一個人同時扛業務、開發加會計沒兩樣。
所以要把角色拆開。一個只碰行情資料、一個只動策略邏輯、一個只負責驗證結果。各自只要顧好自己那塊就好。
工具內建幫你做這件事的，就是子代理（subagent）。翻文件會看到，子代理各自擁有獨立的上下文視窗、獨立的系統提示，以及受限的工具清單。也就是說，你把很吃資源的搜尋任務整包丟過去，主視窗還是乾乾淨淨的。
建立起來也沒什麼難度。寫一句「你是專門翻日誌找原因的角色」這種文字放著就結束了。
再往前一步，你甚至可以同時開好幾個 session，每個給一個角色。一個視窗就等於一個人。
不過如果只是個人專案，真的不用一開始就開八個。先從兩個開始：一個負責規劃跟下指令，一個負責實際改程式碼。光是這樣拆，說「整個感覺完全不同」的心得就多到看不完。
要讓代理人彼此對話，你需要一個「傳話人」
這時候會撞牆。視窗 A 跟視窗 B 是完全獨立的兩個行程，A 沒有辦法直接把自己講的話丟給 B。
用辦公室來比喻，就是兩個人各自關在隔音間裡。做事都很行，但彼此聽不到對方在說什麼。
所以中間要另外開一個傳話人。一般叫它 bus（訊息匯流排），做的事情就只有這三件：
- 持續盯著各個 session 留下的「這個幫我轉給那邊」的請求
- 把訊息記錄下來（誰傳給誰都會留下日誌）
- 把內容塞進接收方的視窗，然後連 Enter 都幫你按下去
「連 Enter 都幫你按」聽起來有點好笑對吧？但這就是自動化的最後 1 公分。我們之所以半夜還坐在電腦前不能睡，說到底也就是為了那一下 Enter。
實作起來也很樸素。在共用資料夾裡堆訊息檔案讓彼此互相讀、或是架一個小小的工作佇列、或是用終端機多工器（像 tmux）把按鍵送到另一個視窗。公開的開源工具也有好幾套，不必從零開始寫。
這個結構還有一個附加好處：對面不一定要是同一款模型。只要訊息格式對得上，把別家公司的代理人請來坐旁邊也照樣能跑。
要整晚跑，先把圍籬立好再說
走到這一步，大家都會掉進同一個誘惑：每次都要問實在很煩，乾脆把確認流程整個關掉。
心情我懂。但那等於是拆掉煞車在夜路上飆車。一行下錯的 rm，早上起來整個專案資料夾可能就不見了。
所以順序要反過來。不是先放寬權限，而是先把它關起來，讓它在裡面盡情發揮。
查了資料才發現，權限設定跟沙箱根本是兩個不同層級的東西。權限是在決定「可以用哪些工具」，沙箱則是在 OS 層級直接封死檔案系統與網路存取本身。做法就像丟進 Docker 容器裡跑，只把你現在在做的那一個資料夾掛進去。
睡前確認這四件事，再關燈。
- 工作資料夾有沒有用 git 管理（要能還原才行）
- 有沒有不小心把容器外的資料夾一起掛進去
- 裡面有沒有放真正的 API 金鑰或帳戶憑證
- 有沒有留下誰做了什麼的日誌
尤其是第三點。如果你做的是程式交易這種跟錢直接掛勾的東西，真實帳戶的金鑰絕對不要交到自動運作的代理人手上。先在模擬交易環境跑到夠久，下單那個按鈕就留給人來按。
最後那 1%，為什麼一定要留給人？
把「完全自動化」設成目標，結果反而會更糟。沒有人看過就一路堆積上去的程式碼，到某個時間點會變成一坨根本不敢碰的東西。
所以只交出去到 99%，留兩個地方給人：commit 之前，還有真正下單之前。
今天要做的只有一件事就夠了。在你現在開著的那個又臭又長的對話視窗裡，打下這句話：「把目前為止決定的事項和剩下的工作，整理到 HANDOFF.md。」然後清空視窗，重新開始。
一開始一定會覺得可惜。但當你看到新視窗突然變得聰明起來，你就會懂了：你一直抱著不放的那些，根本不是記憶，而是包袱。
