1. 首頁 > 生活百科 > >

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

人工智能ai美歐關系

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

文章圖片

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提醒 ， 這一周產出的內容大概率會很普通 ， 甚至很糟糕 ， 這本來就是正?，F象 。 第一周唯一的任務是把所有錯誤都具體地糾正出來 ， 不是簡單說“這個不行” ， 而是明確告訴它：“這條不行 ， 是因為X；下次請按Y來做 。 ”
第二周 ， 要開始檢查這些經驗到底有沒有真正留下來 。
Saboo建議 ， 可以讓同一個Agent跑兩次相似任務 ， 然后觀察它是否還會犯同樣的錯誤 。 如果同樣的問題再次出現 ， 就說明反饋閉環沒有成型 ， 也就是經驗沒有真正進入可持續存儲的文件 。 這一階段 ， 用戶應該開始建立自己的技能文件 ， 把那些反復重復的規則正式寫下來 。
第三周 ， 如果前兩周執行得比較扎實 ， Agent通常會逐漸進入第二階段 ， 也就是“內容需要編輯 ， 但不需要重寫” 。 這個階段可以開始記錄一個更實際的指標：每次審稿到底花了多久 。
Saboo認為 ， 這個數字應該是一周比一周下降的 。 如果沒有下降 ， 通常不是模型不行 ， 而是反饋仍然不夠具體 。
到了第四周 ， 才適合考慮引入第二個Agent ， 而且前提是第一個Agent已經能夠穩定產出有用結果 。
【30天養蝦秘籍公開！第4天差點團滅，最后跑出“AI軍團”，超全避坑干貨在此】Saboo建議 ， 這時兩個Agent之間的配合也不要設計得太復雜 ， 最簡單的方式就是基于文件協作：第一個Agent把產出寫進共享文件 ， 第二個Agent去讀取這個文件再繼續處理 。 集成方式越簡單 ， 系統越不容易失控 。

    推薦閱讀