AI Agent 輸出垃圾？ 問題在你捨不得燒 Token
作者：Systematic Long Short
編譯：深潮 TechFlow
這篇文章的核心論點只有一句話：AI Agent 輸出品質和你投入的 Token 數量成正比。
作者不是在泛泛談理論，而是給出了兩個可以今天就開始用的具體方法，並清楚地劃定了 Token 堆不出來的邊界——“新穎性問題”。
對正在用 Agent 寫程式碼或跑工作流程的讀者，資訊密度和可操作性都很高。
引言
好吧，你得承認這個標題確實挺吸引眼球——但說真的，這不是玩笑。
2023 年，當我們還在用 LLM 跑生產代碼的時候，周圍的人都驚掉了下巴，因為當時普遍的認知還是 LLM 只能產出沒法用的垃圾。 但我們知道一件別人沒意識到的事：Agent 的輸出質量，是你投入 Token 數量的函數。 就這麼簡單。
你自己跑幾個實驗看得出來。 讓 Agent 完成一個複雜的、有些冷門的程式設計任務——比如說，從頭實作一個帶有約束條件的凸優化演算法。 先用最低思考檔執行；再切到最高思考檔，讓它 review 自己的程式碼，看看能發現多少 bug。 中檔、高檔都試。 你會直觀地看到：bug 數量隨著投入的 Token 量單調遞減。
這不難理解，對吧？
Token 越多 = 錯誤越少。 你可以把這個邏輯再推進一步，這基本上就是程式碼 review 產品背後那個（簡化過的）核心想法。 換一個全新的上下文，投入大量 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 用全新上下文 review N 次，每次發現問題就修復。
如果你發現這個簡單技巧改善了你的 Agent 工程效果，那你至少明白了，你的問題只是 Token 數量的問題——那就來加入燒 Token 俱樂部吧。
簡單做法二：VERIFY（驗證）
讓 Agent 儘早、頻繁地驗證自己的工作。 寫入測試來證明所選路徑確實能跑通。 這對高度複雜、深度嵌套的項目特別有用——一個函數可能被下游許多其他函數呼叫。 能在上游抓住錯誤，能為你節省大量後續的運算時間（Token）。 所以如果可以的話，在整個建置過程中到處設定「驗證檢查點」。
寫完一段東西，主 Agent 說搞定了？ 讓第二個 Agent 來驗證一次。 不相關的思考流能涵蓋系統性偏差的來源。
基本上就這些了。 關於這個主題我還能寫很多，但我覺得只要意識到這兩件事並好好落地執行，就能幫你解決 95%的問題。 我堅信把簡單的事情做到極致，再按需疊加複雜度。
我提到了「新穎性」是靠 Token 無法解決的問題，我想再強調一遍，因為你遲早會碰到這個坑，然後來跟我哭訴說堆 Token 沒有用。
當你想解決的問題不在訓練集裡時，你才是那個真正需要提供解法的人。 因此，領域專業知識依然極為重要。
