作者：Systematic Long Short
編譯：深潮 TechFlow
深潮導讀：這篇文章的核心論點只有一句話：AI Agent 的輸出品質與你投入的 Token 數量成正比。
作者並非空談理論，而是提供了兩個今天即可開始使用的具體方法，並明確界定了 Token 無法堆疊的邊界——「新穎性問題」。
對於正在使用 Agent 寫代碼或運行工作流的讀者，資訊密度和可操作性都很高。
引言
好吧，你得承認這個標題確實挺吸引眼球——但說真的，這不是玩笑。
2023 年，當我們還在用 LLM 執行生產代碼時，周圍的人都驚呆了，因為當時普遍的認知是 LLM 只能產出無法使用的垃圾。但我們知道一件別人沒意識到的事：Agent 的輸出品質，是你投入 Token 數量的函數。就這麼簡單。
你自己跑幾個實驗就能看出來。讓 Agent 完成一個複雜的、有些冷門的編程任務——例如，從頭實現一個帶約束條件的凸優化算法。先用最低思考檔執行；再切到最高思考檔，讓它審查自己的代碼，看看能發現多少 bug。中檔、高檔都試一遍。你會直觀地看到：bug 數量隨著投入的 Token 量單調遞減。
這不難理解，對吧？
越多 Token = 越少錯誤。你可以將這個邏輯再推進一步，這基本上就是代碼審查產品背後（簡化過的）核心思路。換一個全新的情境，投入海量 Token（例如讓它逐行解析代碼，判斷每一行是否有 bug）——這樣幾乎可以抓出絕大多數，甚至全部的 bug。這個過程可以重複十次、一百次，每次都從「不同的角度」審視代碼庫，你最終能將所有 bug 都挖出來。
「多燒 Token 就能提升 Agent 質量」這個觀點，還有一個實證支撐：那些聲稱能用 Agent 全程寫代碼直接推上生產的團隊，要麼是基礎模型供應商本身，要麼是資金極其充裕的公司。
所以，如果你還在為 Agent 跑不出生產級代碼而煩惱——說得直接點，問題出在你身上。或者說，出在你錢包上。
如何判斷我燒毀的 Token 是否足夠
我寫過一篇完整文章說明，問題絕對不在你搭建的框架（harness）、「保持簡單」一樣能做出優秀的成果，我至今仍堅持這個觀點。你讀了那篇文章並照著做了，但對 Agent 的輸出仍感到極度失望。你給我發了 DM，看到我已讀卻未回覆。
這篇，就是回覆。
你的 Agent 表現差、解決不了問題，大多數情況下，就是因為你燒的 Token 不夠。
解決一個問題需要投入多少 Token，完全取決於這個問題的規模、複雜度和新穎性。
「2+2 等於幾？」不需要多少 Token。
「幫我寫一個 bot，能掃描 Polymarket 和 Kalshi 之間的所有市場，找出語義相似、應在同一事件前後結算的市場，設定無套利邊界，一旦出現套利機會就以低延遲方式自動交易」——這需要燒掉一大堆 Token。
我們在實踐中發現了一件有意思的事。
如果你投入足夠多的 Token 去處理由規模和複雜度引發的問題，Agent 無論如何都能解決。換句話說，如果你想構建一個極度複雜、有很多組件和程式碼行的東西，只要你往這些問題裡砸足夠多的 Token，它們最終都能被徹底解決。
這裡有一個小但重要的例外。
你的問題不能太新穎。就目前階段而言，任何數量的 Token 都無法解決「新穎性」問題。足夠多的 Token 能把複雜性帶來的錯誤降到零，但無法讓 Agent 平空發明它不知道的東西。
這個結論其實讓我們鬆了口氣。
我們花了極大精力，燒了——很多很多非常多——Token，想試試能不能在幾乎不給引導的情況下讓 Agent 還原出機構投資流程。這部分原因是想搞清楚，我們（作為量化研究員）離被 AI 完全取代還有多少年。結果發現，Agent 根本做不到接近一個像樣的機構投資流程。我們認為這部分原因是它們從未見過這種東西——也就是說，機構投資流程在訓練數據裡根本不存在。
所以，如果你的問題是新穎的，別指望靠堆 Token 來解決。你需要自己引導探索過程。但一旦你確定了實現方案，你就可以放心堆 Token 來執行——無論程式碼庫多大、組件多複雜，都不是問題。
這裡有一個簡單的啟發式原則：Token 預算應當與程式碼行數成正比地增長。
多燒的 Token 究竟在做什麼
在實踐中，額外的 Token 通常通過以下幾種方式提升 Agent 的工程質量：
讓它在同一次嘗試中花更多時間推理，有機會自行發現錯誤的邏輯。推理越深入 = 規劃越好 = 一次命中的機率越高。
允許它進行多次獨立嘗試，走不同的解題路徑。有些路徑比其他路徑更好。允許它多次嘗試，它就能選出最優的。
同樣地，更多的獨立規劃嘗試讓它能夠放棄弱勢方向，保留最有希望的。
更多 Token 讓它能以全新的上下文來 critique 自己之前的工作，給它一個改進的機會，而不是被困在某條「推理慣性」裡。
當然，還有我最喜歡的一點：更多的 Token 意味著它可以用測試和工具來驗證。實際運行代碼看它是否跑通，是確認答案正確的最可靠方式。
這套邏輯能走通，是因為 Agent 的工程失敗並非隨機的。幾乎總是因為過早選錯了路徑、沒有在早期檢查這條路徑是否真的走得通，或者在發現錯誤後沒有足夠的預算來恢復和回退。
故事就是這樣。Token 字面意義上就是你買來的決策質量。把它想像成研究工作：如果你讓一個人即時回答一個難題，答案的質量會隨著時間壓力增加而下降。
研究，歸根結底，是產生「知道答案」這個基礎的東西。人類花費生物意義上的時間來產出更好的答案，Agent 則花費更多計算時間來產出更好的答案。
如何提升你的 Agent
你可能仍半信半疑，但已有許多論文支持這一觀點；坦白說，「推理」調節旋鈕的存在本身，就是你需要的全部證據。
我特別喜歡的一篇論文，研究者使用一小批精心策劃的推理樣本進行訓練，並採用一種方法強制模型在想停下來時繼續思考——具體做法是在它想停的地方追加「Wait」（等等）。僅此一項，就讓某個基準測試從 50% 提升至 57%。
我想說得直白一點：如果你一直抱怨 Agent 寫的代碼差強人意，單次最高思考檔對你來說很可能還是不夠。
我給你兩個非常簡單的解決方案。
簡單做法一：WAIT （等等）
你今天就能開始做的最簡單的事：搭建一個自動循環——完成後，讓 Agent 使用全新上下文審核 N 次，每次發現問題就修復。
如果你發現這個簡單技巧改善了你的 Agent 工程效果，那你至少明白了，你的問題只是 Token 數量的問題——那就來加入燒 Token 俱樂部吧。
簡單做法二：VERIFY（驗證）
讓 Agent 盡早且頻繁地驗證自己的工作。撰寫測試來證明所選路徑確實能運行。這對於高度複雜、深度嵌套的項目特別有用——一個函數可能被下游眾多其他函數調用。若能在上游抓住錯誤，將為你節省大量後續的計算時間（Token）。因此，若可能的話，請在整個構建過程中到處設置「驗證檢查點」。
寫完一段內容後，主 Agent 說搞定了？讓第二個 Agent 來驗證一次。不相關的思考流能覆蓋系統性偏差的來源。
基本就這些了。關於這個話題我還能寫很多，但我認為只要意識到這兩件事並好好落實執行，就能幫你解決 95% 的問題。我堅信把簡單的事情做到極致，再按需疊加複雜度。
我提到過「新穎性」是 Token 無法解決的問題，我想再強調一次，因為你遲早會碰到這個坑，然後來跟我抱怨說堆積 Token 沒用。
當你面對的問題不在訓練集內時，你才是那個真正需要提供解決方案的人。因此，領域專業知識依然極其重要。
