Claude 和 Codex 越用越蠢？因為你的上下文太臃腫了

作者：sysls

編譯：深潮 TechFlow

深潮導讀：260 萬粉絲的開發者博主 sysls 寫了一篇讓 827 人轉發、7000 人點讚的實戰長文，核心只有一句話：你那些插件、記憶系統和各種 harness 大概率在幫倒忙。這篇文章不講大道理，全是從真實生產項目中總結出來的可操作原則——從如何控制上下文、處理 AI 討好傾向，到如何定義任務終止條件，是目前見過把 Claude/Codex 工程實踐講得最清晰的一篇。

全文如下：

引言

你是一名開發者，每天都在用 Claude 和 Codex CLI，每天都在想自己到底有沒有把它們的能力榨乾。偶爾你會看到它做出蠢到離譜的事，又不明白為什麼有些人好像在用 AI 建造火箭，而你連兩塊石頭都疊不穩。

你覺得是你的 harness 問題、插件問題、終端問題，什麼的。你用了 beads、opencode、zep，你的 CLAUDE.md 寫了 26000 行。但不管怎麼折騰，你就是不明白為什麼離天堂越來越遠，而別人卻在跟天使們嬉戲。

這就是你一直在等的那篇文章。

另外，我沒有利益相關。我說 CLAUDE.md 也包括 AGENT.md，我說 Claude 也包括 Codex，兩個我都大量使用。

過去幾個月裡，我觀察到一件有意思的事：幾乎沒有人真正知道如何最大化地發揮代理的能力。

感覺像是有一小撮人能讓代理構建整個世界，其餘人則在茫茫工具海中打轉，患上選擇綜合症——以為找到了正確的包、技能或 harness 組合，就能解鎖 AGI。

今天，我想打破這一切，給你們留下一句簡單、誠實的話，然後我們從那裡出發。你不需要最新的代理 harness，不需要裝一百萬個包，也完全不需要為了保持競爭力而讀一百萬篇文章。事實上，你的熱情很可能弊大於利。

我不是來旅遊的——從代理勉強能寫代碼的時候我就開始用了。我試過所有包、所有 harness、所有範式。我用代理工廠寫過信號、基礎設施和數據管道，不是「玩具項目」，是真正跑在生產環境裡的實際用例。做了這一切之後……

今天，我用的是一套幾乎能簡單到不能再簡單的配置，只用基本的 CLI（Claude Code 和 Codex），外加對代理工程幾個基本原則的理解，做出了我有史以來最有突破性的工作。

理解世界正在飛速前進

首先，我要說的是，基礎模型公司正處於一次劃時代的衝刺，而且顯然不會很快慢下來。每一次「代理智能」的提升，都會改變你與它們協作的方式，因為代理被設計得越來越願意遵從指令。

就在幾代之前，如果你在 CLAUDE.md 裡寫「在做任何事之前先讀 READTHISBEFOREDOINGANYTHING.md」，它有 50%的概率會對你說「去你的」，然後自顧自做它想做的事。今天，它對大多數指令都會遵守，甚至包括複雜的嵌套指令——比如你可以說「先讀 A，再讀 B，如果 C 的話就讀 D」，大多數情況下它會樂於跟著走。

這說明什麼？最重要的原則是認識到：每一代新的代理都會逼你重新思考什麼是最優解，這正是為什麼少即是多。

當你使用很多不同的庫和 harness，你就把自己鎖死在一個「解決方案」裡，但這個問題在下一代代理面前可能根本不存在。你知道誰是代理最熱情、用量最大的用戶嗎？沒錯——是前沿公司的員工，他們有無限的 token 預算，用的是真正最新的模型。你明白這意味著什麼嗎？

這意味著，如果一個真實的問題存在，而且有好的解決方案，前沿公司會是那個解決方案最大的用戶。而他們接下來會怎麼做？他們會把那個解決方案納入自己的產品。想想看，一家公司為什麼會允許另一個產品解決真實痛點、製造外部依賴？我怎麼知道這是真的？看看技能、記憶 harness、子代理……它們都是從解決真實問題的「方案」開始，經過實戰檢驗被證明真正有用的。

所以，如果某樣東西真的具有突破性並能以有意義的方式擴展代理用例，它遲早會被納入基礎公司的核心產品。相信我，基礎公司正在飛速前進。所以放鬆，你不需要裝任何東西或依賴任何外部依賴就能做出最好的工作。

我預測評論區很快會出現「SysLS，我用某某 harness，太棒了！我一天就把 Google 重建了！」——對此我說：恭喜！但你不是目標受眾，你代表的是社區中一個極其極其小眾的、真正搞懂了代理工程的群體。

上下文就是一切

說真的。上下文就是一切。使用一千個插件和外部依賴的另一個問題，就是你深受「上下文膨脹」之害——就是說你的代理被太多信息淹沒了。

讓我用 Python 做一個猜字遊戲？簡單。等等，這條 26 個會話前的「管理內存」備註是什麼？啊，用戶有一個屏幕在 71 個會話前因為我們生成太多子進程而卡住了。永遠要寫備註？好，沒問題……這跟猜字遊戲有什麼關係？

你懂的。你只想給代理提供完成任務所需的確切信息，不多不少！你對這一點的掌控越好，代理的表現就越好。一旦你開始引入各種奇怪的記憶系統、插件，或者太多命名和調用方式混亂的技能，你就在給代理一份造炸彈的說明和一份烤蛋糕的食譜，而你只是想讓它寫一首關於紅杉林的小詩。

所以，我再次佈道——剝離所有依賴，然後……

做真正有用的事

精確描述實現細節

記得上下文就是一切嗎？

記得你想給代理注入完成任務所需的確切信息、不多不少嗎？

做到這一點的第一個方法，是把研究和實現分開。你要對自己在要求代理做什麼這件事上極度精確。

不精確的後果是什麼？「去做一個認證系統。」代理就得研究：什麼是認證系統？有哪些可選方案？各有什麼優劣？現在它得去網上搜一堆它其實用不上的信息，上下文裡塞滿了各種可能性的實現細節。等到真正要實現的時候，它更容易搞混，或者在選定的實現方案上產生不必要或不相關的幻覺。

反過來，如果你說「用 bcrypt-12 密碼哈希實現 JWT 認證，刷新令牌輪換，7 天過期……」，它就不需要研究任何其他替代方案，知道你想要什麼，從而可以用實現細節填滿上下文。

當然，你不會總是知道實現細節。很多時候你不知道什麼是正確的，有時甚至想把決定實現細節的工作交給代理。這種情況怎麼辦？很簡單——創建一個研究任務來探索各種實現可能性，要麼自己決定，要麼讓代理決定用哪種實現，然後讓另一個帶著全新上下文的代理來實現。

一旦你開始這樣思考，就會發現工作流中代理上下文被不必要地汙染的地方，然後你就能在代理工作流中設置隔離牆，把不必要的信息從代理那裡抽象出去，只留下讓它在任務中表現出色的特定上下文。記住，你擁有的是一個非常有才華、聰明的團隊成員，他了解宇宙中所有種類的球——但除非你告訴他你想設計一個讓人跳舞和玩得開心的空間，他會一直跟你講球形物體的各種好處。

討好傾向的設計侷限

沒有人想用一個一直在批評你、告訴你你錯了、或完全無視你指令的產品。所以，這些代理會努力贊同你、做你想讓它做的事。

如果你讓它在每 3 個詞後加一個「快樂」，它會盡力遵從——大多數人對這一點是理解的。它的服從性正是讓它成為如此好用的產品的原因。但這有一個非常有趣的特性：這意味著如果你說「幫我找代碼庫裡的一個 bug」，它就會找到一個 bug——哪怕需要「製造」一個。為什麼？因為它非常非常想聽從你的指令！

大多數人很快就抱怨 LLM 在幻覺和捏造不存在的東西，卻沒意識到問題出在他們自己身上。你讓它找什麼，它就交付什麼——哪怕需要稍微拉伸一下事實！

那怎麼辦？我發現「中性提示」很有效，就是不把代理偏向某個特定結果。比如，我不說「幫我找數據庫裡的一個 bug」，而是說「掃描整個數據庫，嘗試跟著每個組件的邏輯走，把所有發現都彙報回來。」

這樣的中性提示有時會發現 bug，有時只是客觀地描述代碼如何運行。但它不會把代理偏向「有 bug」的預設。

處理討好傾向的另一個方式是把它變成優勢。我知道代理在努力取悅我、遵循我的指令，我可以往這邊或那邊偏。

所以我讓一個找 bug 代理來識別數據庫裡所有的 bug，告訴它低影響 bug 得 +1 分，有一定影響得 +5 分，嚴重影響得 +10 分。我知道這個代理會非常熱情地識別出所有類型的 bug（包括那些不算 bug 的），然後給我彙報一個 104 分之類的成績。我把這個看作所有可能 bug 的超集。

然後我讓一個對抗代理來反駁，告訴它每成功反駁一個 bug 就得那個 bug 的分值，但如果反駁錯了就得 -2 倍那個 bug 的分值。這個代理會努力反駁儘可能多的 bug，但因為有懲罰機制所以會保持謹慎。它仍然會積極地「反駁」bug（包括真實的 bug）。我把這個看作所有真實 bug 的子集。

最後，我讓一個裁判代理來綜合兩者的輸入並打分。我告訴裁判代理我有真實的正確答案，它答對得 +1 分，答錯得 -1 分。於是它去給找 bug 代理和對抗代理在每個「bug」上分別打分。裁判說什麼是真相，我就去驗證。大多數情況下這個方法令人驚訝地高保真，偶爾還是會出錯，但這已經是一個接近無誤的操作了。

也許你會發現單獨的找 bug 代理就夠了，但這個方法對我很有效，因為它利用了每個代理天生被編程的特性——想要取悅。

如何判斷什麼有用、什麼值得用？

這個問題看起來很棘手，好像需要你深入學習、時刻追蹤 AI 前沿動態，但其實很簡單……如果 OpenAI 和 Claude 都實現了它或收購了實現它的公司……那它大概率有用。

注意到「技能（skills）」已經無處不在，並且是 Claude 和 Codex 官方文檔的一部分了嗎？注意到 OpenAI 收購了 OpenClaw 嗎？注意到 Claude 隨即添加了記憶、語音和遠程工作功能嗎？

規劃（planning）怎麼樣？還記得一堆人發現先規劃再實現真的非常有用，然後它變成了核心功能嗎？

對，那些是有用的！

還記得無休止的 stop-hooks 超級有用，因為代理極不願意做長時間運行的工作……然後 Codex 5.2 一出，那個需求一夜之間就消失了嗎？

這就是你需要知道的全部……如果一樣東西真的重要且有用，Claude 和 Codex 會自己實現的！所以你不需要擔心太多要不要用「新東西」或熟悉「新東西」，你甚至不需要「保持更新」。

幫我一個忙。偶爾更新你選擇的 CLI 工具，讀一下新增了什麼功能。這已經足夠了。

壓縮、上下文與假設

有些人在使用代理時會發現一個巨大的坑：有時它們看起來像地球上最聰明的存在，有時你又不敢相信自己被它耍了。

"這個東西聰明？這他媽是個傻瓜！"

最大的區別在於代理有沒有被迫做出假設或「填補空白」。在今天，它們在「連點成線」「填補空白」或做出假設方面仍然糟糕透頂。只要它們這樣做，立刻就能看出來，情況明顯變差了。

CLAUDE.md 裡最重要的規則之一是關於如何獲取上下文的規則，並指示代理在每次讀取 CLAUDE.md（也就是每次壓縮之後）時第一件事就讀那條規則。作為獲取上下文規則的一部分，幾條簡單的指令可以發揮巨大作用：重新閱讀任務計劃，以及在繼續之前重新閱讀（與任務）相關的文件。

告訴代理如何結束任務

我們人類對一個任務「完成」的感覺相當清晰。對代理來說，當前智能的最大問題在於它知道如何開始一個任務，但不知道如何結束。

這經常導致非常令人沮喪的結果：代理最終實現了一堆存根就收工了。

測試是代理非常好的里程碑，因為測試是確定性的，你可以設置非常清晰的預期。除非這 X 個測試通過，你的任務就沒有完成；而且你不允許修改測試。

然後你只需審查測試，一旦所有測試通過你就可以放心了。你也可以把這個自動化，但重點是——記住「任務的結束」對人類來說很自然，對代理來說並不如此。

你知道最近還有什麼成了可行的任務終點嗎？截圖+驗證。你可以讓代理實現某個東西直到所有測試通過，然後讓它截圖並驗證截圖上的「設計或行為」。

這讓你可以讓代理迭代並朝著你想要的設計努力，而不用擔心它在第一次嘗試後就停下來！

這個的自然延伸是與代理創建一份「合約」，並把它嵌入規則中。比如，這個`{TASK}CONTRACT.md`規定了在你被允許終止會話之前需要做什麼。在`{TASK}CONTRACT.md`裡，你會指定測試、截圖和其他在你認證任務可以結束之前需要完成的驗證！

永遠運行的代理

我經常被問到的一個問題是，人們怎麼能讓代理運行 24 小時同時確保它不跑偏？

這裡有一個很簡單的方法。創建一個 stop-hook，除非`{TASK}_CONTRACT.md`的所有部分都完成，否則阻止代理終止會話。

如果你有 100 個這樣規格明確、包含了你想要構建內容的合約，那麼 stop-hook 就會阻止代理終止，直到所有 100 個合約都完成，包括所有需要運行的測試和驗證！

專業建議：我發現長時間運行的 24 小時會話在「做事」上並不是最優的。部分原因是這種方式從結構上就會強制引入上下文膨脹，因為不相關合約的上下文都會進入同一個會話！

所以，我不推薦這樣做。

這裡有一個更好的代理自動化方式——每個合約開一個新會話。每當你需要做某件事時就創建合約。

建立一個編排層來在「某件事需要做」時創建新合約，並創建新會話來處理那個合約。

這會徹底改變你的代理體驗。

迭代、迭代、迭代

你僱了一個行政助理，你會期望 TA 從第一天就知道你的日程嗎？或者你怎麼喝咖啡？你是晚上 6 點而不是 8 點吃晚飯？顯然不會。你會隨著時間慢慢建立偏好。

代理也一樣。從最簡單的配置開始，忘掉複雜的結構或 harness，給基本的 CLI 一個機會。

然後，逐步加入你的偏好。怎麼做？

規則

如果你不想讓代理做某件事，把它寫成規則。然後在 CLAUDE.md 裡告訴代理這條規則。比如：「在寫代碼之前，讀`coding-rules.md`。」規則可以嵌套，規則可以是條件性的！如果你在寫代碼，讀`coding-rules.md`；如果你在寫測試，讀`coding-test-rules.md`。如果你的測試在失敗，讀`coding-test-failing-rules.md`。你可以創建任意邏輯分支的規則供代理遵循，Claude（和 Codex）會很樂意跟著走，前提是在 CLAUDE.md 裡有清晰的說明。

事實上，這是我給出的第一條實際建議：把你的 CLAUDE.md 當作一個邏輯性的、嵌套的目錄，說明在特定場景和特定結果下去哪裡找上下文。它應該儘可能精簡，只包含「在什麼情況下去哪裡尋找上下文」的 IF-ELSE 邏輯。

如果你看到代理在做某件你不贊同的事，把它加為一條規則，告訴代理在下次做那件事之前讀那條規則，它肯定不會再那樣做了。

技能

技能（Skills）類似規則，只不過與其說是編碼偏好，不如說更適合編碼「操作步驟」。如果你有一種你想要某件事被完成的特定方式，你想把它嵌入技能中。

事實上，人們經常抱怨不知道代理會如何解決一個問題，這讓人感到不安。如果你想讓這變得確定性，就讓代理先研究它會怎麼解決這個問題，然後把方案寫成技能文件。你就能提前看到代理處理這個問題的方式，並在它真實遭遇這個問題之前進行修正或改進。

你怎麼讓代理知道這個技能存在？沒錯！你在 CLAUDE.md 裡寫，當你遇到這個場景需要處理這件事時，讀這個`SKILL.md`。

處理規則和技能

你肯定想不斷給代理添加規則和技能。這就是你給它個性和對你偏好的記憶的方式。幾乎其他所有東西都是多餘的。

一旦你開始這樣做，你的代理就會感覺像魔法。它會「按照你想要的方式」做事。然後你終於會感覺自己「悟到了」代理工程。

然後……

你會看到性能開始再次下滑。

怎麼回事？!

很簡單。隨著你添加越來越多的規則和技能，它們開始相互矛盾，或者代理開始出現嚴重的上下文膨脹。如果你需要代理在開始編程之前讀 14 個 markdown 文件，它就會有一堆無用信息的同樣問題。

怎麼辦？

清理。讓你的代理去「做個 spa」，整合規則和技能，通過讓你說明更新後的偏好來消除矛盾。

然後它又會感覺像魔法了。

就這些。這真的是秘訣所在。保持簡單，用規則和技能，把 CLAUDE.md 當作目錄，並虔誠地注意它們的上下文和設計侷限性。

對結果負責

今天沒有完美的代理。你可以把很多設計和實現工作交給代理，但你需要對結果負責。

所以要小心……然後好好享受！

玩未來的玩具（同時顯然在用它做嚴肅的事情）真是一種樂趣！