30天養蝦秘籍公開！第4天差點團滅，最后跑出“AI軍團”，超全避坑干貨在此

智東西
作者｜江宇
編輯｜漠影

一套“24小時運轉”的龍蝦團隊，在上線第4天，差點被主人親手“團滅”。

智東西3月10日報道，海外知名AI科技博主、前谷歌產品經理Shubham Saboo近日在社交平臺公開復盤了自己連續運行30天的AI Agent系統。

在他的設想中，這支“龍蝦團隊”應該像一個自動運轉的小型內容工作室：有人負責研究行業信息，有人負責寫內容，還有人負責發布和運營賬號，整個流程全天候自動運行。但現實很快給了他一記悶棍。

最初幾天，這套系統幾乎可以用“災難”來形容：負責寫內容的Agent寫出來的推文又長又空，讀起來像模板拼接；負責搜集信息的Agent一天抓回47條所謂的“行業線索”，其中40條都是沒用的假消息。

Saboo后來回憶，那幾天他幾乎一直在給Agent“擦屁股”。他花在修改Agent輸出上的時間，甚至比自己手動把這些事情做完還多。上線第4天，他差點直接把整套系統關掉。

但事情在幾周后開始出現轉折。同樣的模型、同樣的提示詞，第4周時，這些Agent生成的內容已經可以直接拿來用，大多數草稿只需要改兩三個詞就能發布。原本需要他反復返工的任務，開始自動跑通。

在這份復盤里，他回答了一個問題：為什么那么多人“養蝦”時，第一周就速速放棄，而有些人卻能把龍蝦變成同事，效率倍增。

一、第1周幾乎是“負收益”：改Agent比自己干活還累

Saboo最早上線的Agent是運營Agent——“Kelly”，負責運營他的X賬號。第一天只是搭建環境，第二天開始生成推文，但結果并不理想。

Kelly寫出來的內容既冗長又套路化，經常使用列表和箭頭符號，開頭是“我很高興宣布……”，結尾再配上一串標簽，整體風格不是作者平時的表達方式。

Saboo回憶，在第一周里，他幾乎每天都在修改這些內容，花在修正Agent輸出上的時間，比自己直接寫一條推文還多。原本期待AI帶來效率提升，現實卻是不斷修補錯誤輸出，同時還要維護系統本身。

后來復盤這段經歷時，他把這個過程稱為 “糾錯式Prompt工程（Corrective Prompt Engineering）”。與其一開始就設計完美提示詞，不如先在SOUL.md（Agent行為設定文件） 中寫一個粗略設定，然后通過持續反饋不斷修正，就像管理新員工一樣。第一版通常很普通，第十版開始能用，第三十版才會真正穩定。

Saboo坦言，在第一周結束前，他一度差點把整個系統關掉。

二、把具體反饋寫進文件，而不是停留在聊天里

Saboo發現，Agent真正變好的關鍵在于具體規則的積累。在“運營Agent”Kelly第一次生成推文后，他把一組明確規則寫入Agent的記憶文件。

這個記憶文件后來逐漸形成兩個部分：一個叫“BAD”，記錄所有被否定的寫作模式，比如使用bullet points（項目符號列表）、箭頭格式或領英帖子的語氣；另一個叫“GOOD”，里面放的是作者過去表現最好的推文，讓Agent在每次寫作時進行模仿。

隨著這些規則不斷累積，Kelly的表現逐漸改善。第10天時emoji基本消失，第15天開始模仿作者的句式結構，到第20天時，大部分草稿只需要改一兩個詞就能發布。

Saboo認為，很多人使用Agent時會忽略一個關鍵環節：反饋必須寫入文件，而不是停留在聊天記錄里。如果反饋只存在對話記錄中，下一次任務Agent就會再次犯同樣的錯誤。只有當這些經驗被寫入可持續加載的文件，系統才會真正進化。

三、一次錯誤，讓研究Agent學會判斷“信號”和“噪音”

Saboo的第二個Agent是研究Agent——“Dwight”，負責每天掃描AI行業信息，為內容團隊尋找選題線索。第一次掃描時，Dwight推送了47條信息，其中40條都屬于噪音：包括各種小更新、未經驗證的傳聞，以及幾乎沒有價值的項目。

于是Saboo給了它一個非常嚴格的規則：如果讀者Alex今天無法據此做任何事情，就不要推送。Alex是Saboo設定的目標讀者畫像：一位AI產品開發者。

這個規則很快改變了Agent的行為。第10天時，Dwight每天只推送18條信息，而且大多有價值；到第25天時，數量減少到7條，但每一條都值得閱讀。

此外，一次錯誤也讓系統進一步優化。Dwight曾把一個工具當成“新發布項目”推薦給Saboo，后來才發現，這個工具早已存在，只是當天有人在X上提到它。Dwight誤把“被討論”當成“剛發布”。

Saboo隨后調整流程，要求Agent在推薦項目之前必須驗證發布時間，例如檢查GitHub倉庫創建日期、Hacker News發布時間以及實際發布記錄。如果項目已經存在一周以上且沒有明顯更新，就直接跳過。

他還徹底移除了GitHub趨勢榜作為信息源，因為那里噪音太多，很多項目只是被重新討論而已。取而代之的是goodailist.com（專門篩選新AI項目的網站）。

四、Agent團隊也會“發胖”：上下文太多反而拖慢系統

隨著系統不斷積累經驗，一個新的問題出現了：上下文膨脹。

Kelly的上下文一度達到161000個token，Dwight也超過156000個token。大量歷史記錄占據了模型的上下文空間，導致響應變慢，輸出質量也開始下降。

Saboo最終對兩個Agent進行了“壓縮”：Kelly的上下文從161K減少到40K，Dwight從156K減少到43K。做法很簡單，只保留當前真正有用的規則和記憶，其余內容全部歸檔。

他后來把這件事變成固定流程，每兩周檢查一次Agent記憶文件。Saboo形容，這個過程就像軟件項目里的代碼重構，如果長期不清理，系統就會越來越臃腫。

同一時期，他還解決了另一個系統問題。

第三周時，定時任務調度器出現Bug：任務在隊列中推進，但實際上并沒有執行。Saboo幾個小時后才發現問題，因為系統表面狀態看起來一切正常。

于是他新增了一個“首席運營Agent”——Monica。Monica負責定期檢查系統“heartbeat（任務心跳信號）”。如果某個任務超過26小時沒有運行，她會自動觸發重新執行。

五、每個Agent團隊都會經歷的三個階段

根據自己的實踐經驗，Saboo認為大多數Agent團隊都會經歷三個階段。

第一階段是混亂期，通常發生在上線后的前一周。Agent輸出內容普遍比較普通，修改成本甚至高于人工完成任務，很多人會在這一階段放棄。

第二階段是穩定期，大約在第8到第21天之間。隨著反饋不斷積累，明顯錯誤逐漸消失，輸出開始接近可用狀態，只需要少量編輯。

第三階段是復利期。當系統積累了足夠多的規則和上下文后，Agent會逐漸理解用戶的表達習慣和判斷標準，新任務也能繼承過去的經驗，整體效率明顯提升。

在他看來，能夠堅持度過“混亂期”的人，最終得到的是一套會不斷學習的自動化系統；而那些中途放棄的人，則每一次都要從零開始。

六、真正提升效率的是：兩類文件和一個閉環

Saboo在復盤這30天時特別強調，真正會隨著時間不斷變好的，其實只有三樣東西，其他部分基本都沒有本質變化。

第一類是記憶文件。記憶文件存放的是Agent從反饋里學到的“偏好”，每一條反饋一旦寫進記憶文件，就意味著這類錯誤以后不必再糾正一次。

第二類是技能文件。和記憶文件不同，技能文件記錄的是從失敗中提煉出來的“操作規則”。Saboo認為，技能文件更像是任務說明書，它告訴Agent這項工作到底該怎么做，而不僅僅是用戶個人偏好是什么。也正因為更具指令性，技能文件往往比記憶文件積累得更快，效果也更直接。

第三類真正持續起作用的東西，是反饋閉環。Saboo認為，這是最容易被忽略的一環。很多人搭完Agent之后就讓它自己運行，過幾天發現效果沒提升，便覺得系統沒有用。但問題往往不在模型，而在于反饋沒有真正進入系統。

比如“運營Agent”Kelly寫完一條推文，如果Saboo只是當場說一句“太長了，把第一段刪掉”，但這句反饋沒有被寫進文件，那么下一次Kelly還是會犯同樣的錯誤。只有當這條反饋被記錄進記憶文件或技能文件，并在下一次任務開始時重新加載，Agent才會真正“記住”這件事。

Saboo自己后來形成了一套固定動作：先給反饋，再由Agent更新記憶文件或技能文件，下一輪任務開始時把這條經驗重新加載進去。整個流程并不復雜，但前提是執行上必須足夠嚴格。

在他看來，模型在第1天和第30天其實沒有變化，不會越用越“聰明”。真正發生變化的，是圍繞模型構建的系統——包括規則文件、記憶記錄以及持續反饋形成的工作流程。

七、他踩過的坑，也正是多數人會放棄的地方

回頭看這30天，Saboo也總結了幾個自己最典型的失誤。

第一個問題是Agent上得太快、太多了。

他在兩周之內一口氣搭了6個Agent，結果很快發現：單個Agent本身都還沒有進入穩定狀態，多個Agent之間的銜接自然更容易混亂。更合理的方式應該是先把一個Agent做到穩定可用狀態，再去加第二個。

第二個問題是文件結構一開始就設計錯了。

最初兩周里，他把所有內容都塞進同一個文件：偏好、規則、經驗、教訓混在一起。結果就是，Agent加載到的上下文經常互相打架。比如第一周形成的是一種表達偏好，第二周又寫入了一條更明確的規則，二者之間可能彼此沖突，最終反而讓Agent理解混亂。

Saboo后來才把記憶文件和技能文件徹底拆開，并給自己定了一條更明確的要求：當上下文達到15萬token以上時，就必須強力壓縮，不能再拖。

第三個問題是反饋給得太模糊。

Saboo認為，“把這個改好一點”這種話幾乎不會留下任何有效積累，因為它無法寫成一條規則，也無法指導下一次任務。真正有用的反饋，必須具體到足以直接寫進文件。可靠的反饋不僅能解釋為什么有問題，也能直接告訴Agent下次應該怎么改。換句話說，只有能被規則化的反饋，才有復利價值。

八、如果從零開始，前30天應該怎么跑

在文章最后，Saboo也給出了一套更適合新手照著執行的30天方案。

第一周，最重要的不是追求復雜系統，而是只挑一個自己每天最重復、最機械的任務。

圍繞這個任務搭建一個Agent，寫好SOUL.md，設置一條簡單的定時任務，讓它先跑起來。Saboo提醒，這一周產出的內容大概率會很普通，甚至很糟糕，這本來就是正常現象。第一周唯一的任務是把所有錯誤都具體地糾正出來，不是簡單說“這個不行”，而是明確告訴它：“這條不行，是因為X；下次請按Y來做。”

第二周，要開始檢查這些經驗到底有沒有真正留下來。

Saboo建議，可以讓同一個Agent跑兩次相似任務，然后觀察它是否還會犯同樣的錯誤。如果同樣的問題再次出現，就說明反饋閉環沒有成型，也就是經驗沒有真正進入可持續存儲的文件。這一階段，用戶應該開始建立自己的技能文件，把那些反復重復的規則正式寫下來。

第三周，如果前兩周執行得比較扎實，Agent通常會逐漸進入第二階段，也就是“內容需要編輯，但不需要重寫”。這個階段可以開始記錄一個更實際的指標：每次審稿到底花了多久。

Saboo認為，這個數字應該是一周比一周下降的。如果沒有下降，通常不是模型不行，而是反饋仍然不夠具體。

到了第四周，才適合考慮引入第二個Agent，而且前提是第一個Agent已經能夠穩定產出有用結果。

Saboo建議，這時兩個Agent之間的配合也不要設計得太復雜，最簡單的方式就是基于文件協作：第一個Agent把產出寫進共享文件，第二個Agent去讀取這個文件再繼續處理。集成方式越簡單，系統越不容易失控。