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