43 萬 Stars 教會我們的事：開源 Agent 生態的規模陷阱

WSHobson 三萬六千、Swarms 接近七千、Trafilatura 六千、vLLM Semantic Router 四千三、Herdr 接近四千——呢五個開源項目加埋四十三萬 GitHub stars。呢個數字攞出去見投資者，足以令人眼前一亮。但如果你真係用過呢堆工具做 production 嘢，你可能會有另一個體驗：stars 多同好用，好似係兩回事。

Star count 係一個 marketing metric，唔係 engineering metric。喺 AI 熱潮之下，一個靚嘅 demo video 加一個 well-written README，已經可以換嚟幾千甚至幾萬 stars。WSHobson 嘅 star 數係 Trafilatura 嘅六倍，但後者喺網頁擷取呢個狹窄領域入面每日被成千上萬嘅 pipeline 使用；前者作為 agent framework，真正喺 production 入面跑緊嘅 deployment 可能少過你想象。

Star 經濟學：免費嘅注意力泡沫

GitHub stars 本質上係一種社交信號：佢反映嘅係「幾多人覺得呢個 project 值得留意」，而唔係「幾多人真係用緊」。喺 Twitter/X 同 Hacker News 主導嘅開源分發生態入面，一個項目嘅 viral potential 往往取決於敘事能力多過技術實力。Agent framework 尤其係咁——因為「AI agent 可以自動化一切」呢個敘事本身就有極強嘅傳播力。

問題在於 star 嘅累積門檻極低：㩒一個掣，唔使成本，唔使承諾。呢個機制令 stars 變成咗一種注意力通脹——當人人都喺度派星星，星星嘅購買力就不斷貶值。十年前一個 10k stars 嘅項目係 serious business；今日一個寫得靚嘅 prototype 可以輕鬆拎到 50k stars。Star count 作為品質 proxy 嘅可信度已經崩潰。

更值得留意嘅係呢種通脹嘅自我強化循環：stars 多 → 上 GitHub Trending → 更多曝光 → 更多 stars。呢個 loop 鼓勵嘅係「容易 viral」嘅功能——靚 demo、prompt engineering tricks、hype-driven features——多過「難做但重要」嘅基本功：error handling、observability、backward compatibility、documentation。你望下 WSHobson 同 Swarms 嘅 release notes，新功能嘅頻率遠高過 bug fix，呢個 pattern 本身就說明咗問題。

Agent Framework 嘅軍備競賽

WSHobson、Swarms、Herdr——呢啲項目代表咗開源 agent 生態嘅典型困局。每個 framework 都試圖定義「agent 應該點樣寫」，但彼此之間嘅差異往往比你想像中細。佢哋都喺度解決同一組問題：task decomposition、tool calling、memory management，只係用唔同嘅 API 設計同抽象層次。

呢種 fragmentation 帶嚟一個現實代價：developer 嘅學習成本被攤分到多個唔相容嘅生態系統入面。你喺 WSHobson 學到嘅嘢，轉去 Swarms 要重新學過。對於香港嘅獨立開發者或者細團隊嚟講，呢個 switching cost 係真實嘅——你嘅時間同注意力本來就有限。

更深層嘅問題係 maintainer 被 star count 牽住走，不斷加新功能去滿足 contributor 嘅期望，而唔係打磨核心穩定性。結果係每個 release 都帶嚟 breaking changes，documentation 永遠跟唔上，production deployment 嘅 best practices 要靠社群自己摸索。呢個現象唔係單一項目嘅問題，而係整個開源 agent 生態系統性嘅激勵錯配。

狹窄場景先係真正價值所在

對比之下，Trafilatura 嘅六千 stars 顯得更加實在。呢個項目淨係做一件事——由 HTML 抽取乾淨文字——但佢做得好、做得可靠。唔需要複雜嘅 configuration，唔需要理解 agent 嘅推理流程，唔需要擔心 framework 升級會打爛你嘅 pipeline。Import 佢，解決問題，完。

vLLM Semantic Router 都係同一類：問題好 specific——根據 query 語義決定 routing——但喺佢嘅 domain 入面佢好有用。呢啲項目唔會拎到幾萬 stars，唔會上 TechCrunch，但實際使用率同 user satisfaction 可能仲高過嗰啲萬星 project。

呢個 paradox 值得每一個香港開發者諗一諗：你寧願整一個 10k stars 但得 100 個 active users 嘅 project，定係一個 1k stars 但有 10,000 個 active users 嘅工具？喺開源經濟入面，stars 係 ego boost，active users 先係真正嘅 product-market fit signal。

重新定義咩叫成功

作為獨立開發者或者細團隊，避開規模陷阱嘅方法係重新定義成功嘅指標。

第一，放棄 star chasing。Set 一個目標：100 個每日 active users 好過 10,000 stars。Active users 會開 issue、會提 PR、會話你知邊忽係垃圾。Stars 唔會。

第二，專注狹窄但真實嘅問題。一個好細嘅 niche——例如「幫香港中小企自動化 WhatsApp 客服回覆」——只要解決得夠好，嗰幾十個客戶帶嚟嘅 recurring revenue，遠比一個 viral GitHub project 帶嚟嘅短暫 attention 有價值。

第三，唔好俾 star count 影響 product decisions。最危險嘅係見到 competitor 多 stars 就 panic，然後加 features 去 compete on GitHub。Build for your users，唔係 build for GitHub Trending。

第四，認真考慮唔開源核心嘅可能性。越來越多成功嘅 indie OSS business——Cal.com、Appwrite——嘅策略係開源個 core 但保留 commercial features 同 hosting 做 closed source。咁你就可以享受開源嘅 community 同 distribution 好處，同時唔會被 star 經濟學綁架。

四十三萬 stars 嘅總和好靚，但如果你問呢五個 project 嘅 maintainer 佢哋嘅 revenue、daily active users、或者 churn rate，我懷疑答案會令好多人跌眼鏡。星星喺夜空好靚，但佢哋唔會幫你交租。喺香港呢個城市，我哋好早就學識咗呢個道理。