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 當作目錄，並虔誠地註意它們的上下文和設計限制。

對結果負責

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

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

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