凌晨一點我還在 B 站和小紅書之間來回切換。B 站推給我的是昨天剛看過類型的視頻小紅書又開始推薦同類穿搭筆記YouTube 那邊還在反復出現(xiàn)我已經看過多次的頻道內容Twitter 更是順著幾條舊興趣一路推下去。問題很清楚這些平臺推薦流的優(yōu)化目標不是我而是平臺自己的停留時長和互動率。我不是想說“平臺算法是壞的”而是想說平臺算法的目標函數(shù)和你需要的目標函數(shù)根本不是同一個。你想看的是“對自己真正有用的內容”平臺想讓你看的是“能讓你繼續(xù)刷下去的內容”。這兩個目標偶爾重合但更多時候不重合。所以當我看到 GitHub 上這個 1500 Star 的開源項目標題是把 B 站、小紅書、YouTube、Twitter 的推薦都換成你自己的第一反應不是“又一個爬蟲工具”而是“終于有人把內容篩選這件事的主動權交還給用戶了”。它做的事情看起來簡單但背后是一個完全不同的信息獲取思路你定義規(guī)則Agent 負責執(zhí)行平臺推薦只是其中一個數(shù)據(jù)來源而不是你的信息邊界。這篇文章我會從信息流重構的視角切入講清楚這個 Agent 項目真正解決的痛點、它的工作邏輯、怎么在 10 分鐘內跑通最小流程、哪些配置決定了運行效果以及從“跑通一次”到“長期使用”還差哪些工程能力。1. 這個 Agent 項目真正解決的不是“換算法”而是“信息源主權”1.1 平臺推薦流的兩個結構性缺陷先說第一個缺陷平臺推薦算法本質上是在優(yōu)化平臺指標不是優(yōu)化你的信息獲取質量。無論 B 站、小紅書還是 YouTube推薦系統(tǒng)的核心目標通常是停留時長、互動率、廣告展示次數(shù)。這些指標和“內容對你有沒有用”是兩回事。你明明只想看三條深度教程平臺會覺得你更喜歡輕松內容于是推給你 30 條輕松內容。你越往下刷離真實需求越遠。第二個缺陷是信息繭房是推薦系統(tǒng)的副產品不是 bug而是特性。平臺為了讓你停留會不斷強化你的既有偏好讓你反復看到相似內容。時間一長你的信息源會變得非常窄窄到你以為“世界就是這樣”其實只是平臺認為這樣能留住你。手動關注列表能不能解決能解決一部分但也不夠。關注列表是靜態(tài)的平臺仍然可以控制排序控制哪些內容優(yōu)先出現(xiàn)哪些內容沉底。即便你把所有優(yōu)質創(chuàng)作者都關注了你的信息入口仍然隔著一層平臺篩選。1.2 “換成你自己的推薦”到底指什么這個項目給出的方案不是去魔改平臺客戶端也不是去逆向平臺推薦接口而是在平臺和你之間加一個“內容代理層”。這個代理層做的事情分成四步從你指定的多平臺來源拉取內容包括關注列表、關鍵詞搜索、熱門榜等。用 Agent 對內容做清洗、去重、分類、質量判斷。根據(jù)你預先定義的興趣規(guī)則和評分權重對內容重新打分排序。把最終結果輸出成一份你自定義的推薦列表。換句話說平臺推薦流現(xiàn)在只是一個候選池真正的排序邏輯由你控制。你可以讓 Agent“優(yōu)先推薦最近一周內、和 AI 編程相關、時長不超過 20 分鐘的視頻”也可以讓它“把深度學習相關的長文排在最前面娛樂內容直接過濾掉”。這些規(guī)則過去只能靠手動搜索來實現(xiàn)現(xiàn)在變成了一個可配置、可復現(xiàn)的自動化流程。我理解的關鍵點在這里**這個項目沒有讓算法消失而是把“給你定算法”的權力從平臺手里拿回來了。**Agent 不是替代你判斷而是把你已經有的判斷轉化成一套可執(zhí)行的規(guī)則。2. 為什么過去這件事很難自動化2.1 多平臺采集的碎片化問題看到這里你可能會想這不就是寫幾個爬蟲腳本嗎確實如果只是抓取內容這件事很多年前就能做。但真正讓“替換推薦流”這件事變得困難的不是單平臺抓取而是多平臺的碎片化。每個平臺的接口、數(shù)據(jù)結構、限流策略、授權方式都不一樣。B 站有開放的 API小紅書對第三方訪問限制比較嚴YouTube 有標準的 API 體系Twitter 的接口則經歷了多次變更。要把這些平臺的數(shù)據(jù)統(tǒng)一到一個工作流里意味著你要為每個平臺寫適配層處理不同的字段、不同的分頁方式、不同的限流策略。這些工作非?，嵥槎移脚_接口一變腳本就廢。過去很多個人腳本就是這樣死的不是功能不行而是維護成本太高。你花了一個周末寫的抓取腳本兩周后平臺改版字段變了腳本就廢了。2.2 從采集到判斷再到輸出的閉環(huán)就算把多平臺內容都抓回來了也還只是第一步。真正有價值的部分在于“判斷”和“排序”。你需要的不是一個“內容倉庫”而是一份“推薦列表”。從內容倉庫到推薦列表中間要完成去重、分類、過濾、評分、解釋這五步操作。例如同一個視頻可能同時被多個平臺收錄你需要去重一個內容到底屬于娛樂還是學習需要分類標題里有沒有廣告味需要過濾內容和你興趣詞的匹配程度是多少需要評分為什么推薦這條需要給出理由。這些操作在過去很難自動化因為它們本質上需要“理解”內容而不只是“匹配關鍵詞”。舊方案往往只能做粗淺的規(guī)則過濾比如標題包含某個詞就通過不包含就淘汰。這種規(guī)則太脆弱稍微換一種表達方式效果就差很多。2.3 Agent 在這里承擔的角色Agent 能補上這中間最關鍵的一環(huán)用大模型的文本理解能力來做內容判斷。以一個典型場景為例你讓 Agent 篩選“AI 編程相關的優(yōu)質內容”。舊腳本的匹配方式是標題里是否有“AI”或“編程”這兩個詞。但 Agent 可以做更細的判斷它知道你關心的是用 AI 輔助寫代碼而不是 AI 生成的健身文案它可以在標題模糊的情況下通過描述、標簽、甚至正文摘要來判斷內容是否匹配。這就是為什么現(xiàn)在這類項目能跑通而以前跑不通。大模型理解能力的提升讓“按語義過濾內容”變成了可能。Agent 的作用不是一個“萬能腳本”而是把「拉取 → 理解 → 評分 → 排序 → 輸出」這個流程串起來的調度器。項目標題里的 10 分鐘、0 成本說的就是你已經具備了模型 API 和現(xiàn)成 Agent 框架之后只需要配置興趣規(guī)則就能啟動整套流程。3. 10 分鐘跑通最小流程3.1 前置條件與依賴準備先潑一盆冷水如果完全沒有 API Key、沒有平臺訪問憑證、沒有任何編程基礎10 分鐘可能不夠。但如果你已經具備基本條件10 分鐘跑通最小流程是很有可能的。需要準備的東西大致如下項目說明Git用于拉取項目倉庫代碼Python 3.10多數(shù) Agent 項目的運行環(huán)境具體看項目文檔要求大模型 API Key通常需要 OpenAI 兼容接口或 DeepSeek 等模型接口用于內容理解和評分平臺訪問憑證不同平臺要求不同一般需要申請 Token、Key 或完成 OAuth 授權穩(wěn)定網絡環(huán)境不同平臺的訪問穩(wěn)定性不同需要確保當前網絡能正常訪問目標平臺如果只是做小規(guī)模驗證可以選擇只接入一兩個平臺比如先接 B 站和 YouTube配置一條興趣規(guī)則跑通后再逐步擴展。3.2 最小配置示例首先拉取倉庫git clone 倉庫地址 cd 項目目錄 pip install -r requirements.txt具體倉庫地址以項目主頁為準這里只是一個通用步驟。接下來創(chuàng)建環(huán)境變量文件。大多數(shù)這類項目都會提供一個.env.example作為模板你需要把它復制一份然后填入自己的憑證cp .env.example .env打開.env文件后常見的配置項包括MODEL_API_KEY你的大模型APIKey MODEL_API_BASEhttps://api.deepseek.com/v1 BILIBILI_COOKIE你的B站Cookie YOUTUBE_API_KEY你的YouTubeAPIKey OUTPUT_FORMATmarkdown這部分不同項目差異很大但思路是一致的模型 API 用于內容判斷平臺憑證用于拉取數(shù)據(jù)輸出配置決定結果保存方式。3.3 運行與驗證配置完成后先用最小規(guī)模驗證流程是否通暢。我的建議是先不要直接跑全平臺批量任務先用一條真實內容做 dry-run 測試python main.py --dry-run --limit 10如果是常見寫法這個命令會把每個平臺的抓取條數(shù)限制在 10 條以內只輸出處理結果不生成最終報告。這一步主要是確認三件事平臺憑證是否有效能不能拉到內容。模型 API 是否連通能不能完成內容理解。整個流程有沒有斷點。如果 dry-run 通過再正式運行python main.py --output ./result.md然后打開輸出的result.md文件看看推薦結果是否符合你的預期。如果推薦的十條里有七條是相關度很高的內容說明流程基本打通。如果結果和預期偏差很大通常不是邏輯錯了而是興趣規(guī)則描述得不夠具體。注意不要一上來就把平臺數(shù)量和抓取條數(shù)拉滿。先用一條樣例確認輸入、輸出和日志都正常再去擴展范圍。這一步能幫你省掉大量排查時間。4. 需要理解的關鍵配置和參數(shù)4.1 數(shù)據(jù)源配置決定能看到什么數(shù)據(jù)源配置是整個項目的地基。它決定了 Agent 從哪些平臺、哪些賬號、哪些關鍵詞去拉取內容。常見的數(shù)據(jù)源配置項包括配置項作用建議平臺開關啟用或停用某個平臺初期先啟用 1-2 個平臺賬號/用戶 ID 列表指定關注某個創(chuàng)作者或賬號優(yōu)先填你真正高頻關注的賬號關鍵詞列表按關鍵詞搜索內容使用組合詞比單個詞效果更好時間窗口拉取最近 24 小時還是 7 天初期用 24 小時數(shù)據(jù)量小速度快最大條數(shù)每個平臺最多拉取多少條控制在 20-50 條避免請求量過大這里我最想提醒的是時間窗口。很多人第一次跑通后覺得內容太少就拼命擴大時間窗口。結果把 7 天的數(shù)據(jù)都拉下來又沒設置合理的評分閾值最終得到的推薦列表被打分很低的噪音內容淹沒。更合理的做法是先用一天的數(shù)據(jù)驗證規(guī)則把評分和過濾邏輯調好再擴大到一周。4.2 推薦策略配置決定什么內容排在前面這是整個項目的靈魂。Agent 的能力再強如果你不告訴它“你關心什么”它也只能隨機給內容打分。推薦策略配置通常包括興趣詞表你最關心的主題、實體詞、產品名、方向。不要只寫“編程”要寫“Python、深度學習、Agent 開發(fā)、RAG”這樣具體的詞。過濾規(guī)則哪些內容必須排除。例如“不包含廣告”“時長大于 5 分鐘”“不是影視解說”。評分權重興趣匹配和熱度的占比。如果你更看重時效性可以把“發(fā)布時間”的權重調高如果你更看重內容本身可以把“興趣匹配度”權重調高。推薦理由生成讓 Agent 在輸出中解釋每條推薦的原因。這個功能非常有用它不只是給你看還能幫你反過來驗證規(guī)則是否合理。我建議配置時多花一點時間打磨興趣詞表。這比調任何參數(shù)都重要。比如你寫“AI”Agent 會把“AI 網紅生成的海報”也歸進來但你寫“AI Agent 應用開發(fā)”過濾質量會明顯提升。這里有一個值得記住的技巧用興趣詞組合而不是興趣詞堆砌。4.3 輸出配置決定結果怎么保存和流轉輸出配置決定了整條工作流的最終產物。常見的輸出方式有Markdown 報告適合人直接閱讀每天生成一份推薦列表。JSON / JSONL適合程序進一步處理比如接入其他系統(tǒng)。SQLite 數(shù)據(jù)庫適合有長期數(shù)據(jù)積累需求的用戶可以查詢歷史推薦記錄。語音播報或消息推送部分項目支持把結果推送到 IM 工具適合通勤時聽。如果你只是個人使用我建議先用 Markdown然后根據(jù)使用頻率決定要不要升級到 SQLite 或消息推送。如果你要長期跑定時任務一定要給輸出文件加上日期標記避免每天覆蓋前一天的記錄。提醒一點很多項目默認會把輸出寫到當前目錄長期運行后目錄會越來越亂。建議在第一次配置時就規(guī)劃好輸出路徑把日志、中間結果、最終報告分目錄存放。5. 常見問題排查鏈路5.1 先看現(xiàn)象別急著改參數(shù)跑這類項目的時候最高頻的錯誤不是代碼邏輯問題而是環(huán)境配置和平臺接口問題。我建議遇到問題先按下述鏈條排查而不是看到一個報錯就改一個參數(shù)。沒有輸出先確認是否真的調用了main.py并傳了正確的參數(shù)再看日志里有沒有報錯最后看輸出目錄是否為空。有輸出但全部為空大概率是平臺側沒拉到數(shù)據(jù)。檢查 Token 或 Cookie 是否過期時間窗口是否太短關鍵詞是否太窄。API 報錯檢查模型 API Key 是否有效、額度是否用完、API 地址是否填錯。有些項目兼容 OpenAI 接口但地址寫錯會導致認證失敗。平臺返回 403/429403 通常是憑證無效或沒有訪問權限429 是請求太頻繁。遇到 429降低請求頻率增加 sleep 間隔或者減少抓取條數(shù)。速度異常慢一般有兩種原因一是單條內容都要調用模型 API數(shù)量一大就慢二是網絡環(huán)境不穩(wěn)定請求超時重試。可以先把數(shù)據(jù)量調小再把超時時間調低觀察是否提速。5.2 逐層排查的具體方法更細一點說我建議你按照「輸入 → 環(huán)境 → 權限 → 參數(shù) → 資源 → 日志 → 工具邊界」這個順序走一遍。輸入檢查配置的憑證、路徑、關鍵詞、平臺開關有沒有寫錯。常見問題是把.env.example復制成.env之后忘了改具體的 Key 值。環(huán)境檢查 Python 版本是否滿足要求依賴是否安裝完整。有的項目只支持 Python 3.10如果你還在用 3.8很多新版語法會直接報錯。權限檢查平臺 Token 是否有對應權限。比如一個只有只讀權限的 Token可能無法拉取某些私有內容或完整歷史記錄。參數(shù)檢查 limit、time_window、score_threshold 這類參數(shù)是否設置得太激進。比如打分閾值設成 90而實際內容最高分只有 85推薦列表自然為空。資源檢查磁盤空間、內存占用。如果數(shù)據(jù)量大且輸出到 SQLite長期運行會積累大量數(shù)據(jù)磁盤滿了會導致寫入失敗。日志打開 debug 模式看具體在哪一步失敗。這一步通常能快速定位問題。工具邊界有些問題是項目本身的功能邊界。比如某些平臺不再開放公開接口或者平臺調整了數(shù)據(jù)結構舊版本項目可能無法正常工作。這時候可以檢查項目有沒有新版本或相關 issue。5.3 兩個容易誤判的邊界第一個是“0 成本”。這個項目本身確實是開源、免費可用的但運行過程中會消耗大模型 API 的 token。如果每天跑一次大規(guī)模抓取日積月累下來還是會消耗一點 API 費用。好在大部分模型的免費額度或低成本檔位足夠個人日常使用。第二個是“10 分鐘”。10 分鐘是指你已經完成環(huán)境準備、有可用 API Key、網絡暢通的前提下從配置到跑通的最小時間。第一次接觸這類項目的用戶往往需要更多時間裝依賴、配置憑證、處理平臺的授權流程。6. 從“跑通”到“長期使用”的工程化建議6.1 先小樣本驗證再擴大范圍跑通一次離“長期使用”還差很遠。我更建議按照這個節(jié)奏來第一周只用 1 個平臺、1-2 個興趣詞、每天跑一次看看輸出質量。第二周加入第二個平臺調整評分權重比較不同平臺的推薦質量。第三周把興趣詞表擴充到 10 個以上設置過濾規(guī)則固定輸出目錄。第四周加入定時任務和失敗重試開始積累歷史數(shù)據(jù)。這個節(jié)奏看起來慢但對長期使用來說是安全的。很多人一上來就全平臺、全關鍵詞跑第二天就發(fā)現(xiàn) API 配額用完了或者某個平臺開始限制訪問反而放棄了整個項目。6.2 真正值得補的工程能力如果想讓這個流程穩(wěn)定運行以下幾點在長期使用中會非常關鍵定時調度用 cron 或系統(tǒng)計劃任務每天固定時間運行。推薦在凌晨低峰時段跑既不影響使用也減少平臺限流概率。失敗重試網絡抖動、API 限流、平臺臨時接口異常都可能導致任務失敗。設置 2-3 次重試每次間隔 30 秒以上能顯著提升成功率。日志記錄每次運行都保存日志包括成功數(shù)、失敗數(shù)、耗時、平臺響應碼。這樣即使某天輸出異常你也可以回溯到具體是哪一步出的問題。數(shù)據(jù)存儲不要只輸出 Markdown。建議同時把原始結果存成 JSONL方便后續(xù)分析、去重和重新排序。配置版本化把.env和興趣規(guī)則配置寫入 Git 倉庫方便回滾和對比不同配置的效果。6.3 適合誰、不適合誰任何方案都有邊界。這個項目也不例外。比較適合的人群有多個平臺信息源想把它們聚合到統(tǒng)一工作流里的內容消費者。對推薦內容有明確偏好且愿意花時間打磨興趣規(guī)則的深度用戶。正在研究 Agent 工作流、想通過真實項目理解 Agent 如何連接 API 和模型的開發(fā)者。不太適合的人群完全不想處理 API Key、平臺憑證、配置文件只想打開就能用的用戶。這類項目離成熟產品還有距離。希望完全替代實時推薦流連刷手機的一瞬間都在用這個工具的用戶。它的重點不是“刷”而是“定時獲取優(yōu)質內容”。對信息時效性要求極高每五分鐘就要更新一輪的用戶。受限于平臺接口和模型調用速度這類方案更適合日更或周更。7. 這類項目真正的長期價值不在“少刷幾分鐘”回到開頭的問題。這個項目真正值得關注的不是“把推薦流換成你自己的”這個功能本身而是它代表了一種新的信息獲取方式。過去十年我們獲取信息的方式很大程度上是平臺定義的。平臺推薦什么我們就看什么。平臺沒有推薦的內容哪怕質量再高也很難被我們看到。這個項目則提供了一個相反的思路平臺只是內容倉庫真正的推薦引擎可以由你自己控制。Agent 不代替你做判斷它只是把你對“什么是好內容”的理解變成一套可配置、可復現(xiàn)、可調整的流程。這個模式的長期價值在于**你花在定義規(guī)則上的時間會隨著時間積累產生復利。**你寫的每一個興趣詞、每一條過濾規(guī)則都會讓下一次推薦更精準。這和平臺算法的邏輯完全不同平臺算法的訓練數(shù)據(jù)是所有用戶的行為而你定義的是你自己的信息需求。當然我也想說清楚這不是一個可以一勞永逸的方案。平臺接口會變內容生態(tài)會變你自己的興趣也會變。你需要像維護自己的“內容花園”一樣定期調整規(guī)則、更新詞表、清理失效來源。但正是這種持續(xù)的調整讓你始終保持對信息流的掌控感。如果這個項目給你帶來的啟發(fā)只有一條我希望是**下一次打開推薦流刷到不感興趣的內容時你可以多問一句——這條內容為什么出現(xiàn)在我的首頁是誰在決定它應該出現(xiàn)**而這類開源項目的存在就是在告訴你這個問題你其實可以自己接管一部分。