TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
PanSou 開源搜尋 API，把雲端硬碟分享連結整併成一頁結果
PanSou 是可自架的開源聚合搜尋 API，同時對 Telegram 頻道與數十個外掛來源發查詢，把雲端硬碟分享連結分組回傳。我實測官方示範站，同一個關鍵字三次查詢分別回 321 筆、逾時與 29 筆，現行版本也已移除一年前介紹文還寫著的 MCP 服務，自架前該留意的五件事列在文中。
用 AI 摘要這篇文章：
同一個關鍵字，我在 PanSou 官方示範站上連查三次，得到三種答案：第一次 5.2 秒回來 321 筆結果，隔一分鐘重查同一個字，請求卡了超過一分鐘沒有回應，再隔一陣子冷測，4.8 秒只回 29 筆。這是 2026 年 8 月 27 日我實際打 API 記錄下來的數字。它點出 PanSou 的本質：這是一套你自架的聚合查詢服務，結果端看你接上哪些來源、以及當下哪些來源回應得及時，它並不是一個整理好、結果穩定的搜尋引擎索引。
PanSou 是用 Go 寫的開源搜尋 API 服務（MIT 授權，原始碼與示範站都公開），Docker 一行指令就能架起來。它同時對你指定的 Telegram 頻道和數十個外掛來源發出查詢，把找到的雲端硬碟分享連結辨識類型、分組排序後包成 JSON 回給你，官方還附了一個簡約的前端頁面。對想幫自己或小團隊做一條固定來源查詢管線的人，這個形態很有吸引力；不過在按下 docker run 之前，有幾件事值得先看清。
我打了五次 API：外掛來源撐起大部分結果
我對示範站的 /api/search 端點用 POST 送了兩個關鍵字、共五次查詢，其中一次指定只用 Telegram 頻道當來源做對照。全部數字如下：
| 關鍵字 | 來源設定 | 結果數 | 回應時間 | 類型分布 |
|---|---|---|---|---|
| blender | 全部來源 | 321 筆 | 5.2 秒 | 磁力連結 294、夸克 20、阿里 4、百度 2、UC 1 |
| blender（重查） | 全部來源 | 無回應 | 逾 60 秒逾時 | 未能取得 |
| blender（冷測） | 全部來源 | 29 筆 | 4.8 秒 | 夸克 20、阿里 4、磁力連結 3、百度 1、UC 1 |
| linux | 僅 Telegram 頻道 | 58 筆 | 1.6 秒 | 夸克 38、阿里 17、天翼 2、百度 1 |
| linux | 全部來源 | 971 筆 | 7.0 秒 | 磁力連結 877、夸克 70、阿里 19、其餘零星 |
三個觀察值得展開。先看來源結構：321 筆結果裡，回應欄位標著來自外掛的有 295 筆，來自 Telegram 頻道的只有 26 筆，示範站跑的是整合版映像檔，出廠預設啟用 28 個外掛、內建數十個頻道，即使如此外掛仍撐起了絕大多數結果。對照組也很有意思：同樣查 linux，只開 Telegram 頻道是 58 筆、1.6 秒，全開是 971 筆、7.0 秒，來源開越多等越久，而且 971 筆裡有 877 筆是磁力連結。剩下的疑問就是開場那三次查詢的落差，結果數會隨時間與來源狀態大幅波動。
最反常的兩件事：結果會縮水，MCP 服務已經不存在
波動本身有個合理機制可解釋（下一段會講），真正讓我意外的是一個時間差：網路上流通的 PanSou 介紹，有些還寫著它提供 MCP 服務、可以嵌入 Claude Desktop 之類支援模型上下文協定的應用。我把原始碼倉庫的完整檔案樹拉出來數了一遍，現行版本的檔案樹有 316 個項目，找不到任何一個 MCP 相關路徑；往提交歷史追，MCP 伺服器的 13 筆提交全部落在 2025 年 8 月 24 日到 30 日之間，之後就沒有了。也就是說，這個功能確實存在過，後來被整批移掉，現行版本的人工智慧整合形式，換成了一份給 Codex、Claude 這類 AI 客戶端參考的外掛開發說明文件，性質是協助你寫新的搜尋外掛，而不是把搜尋能力掛進對話工具。照著一年前的教學去找 MCP 設定檔，只會撲空。
這類時間差不只是歷史八卦。它在提醒讀者：PanSou 是個迭代中的個人專案，文件、外掛名單和功能面板都還在動，第三方介紹（包括搜尋引擎排前面的那些）未必反映現況，部署前以倉庫當下的 README 和 docs 為準最保險。
從波動反推設計：先回應拿得到的，背景再慢慢補
為什麼同一個查詢會回三種答案？設計文件把這套外掛系統的策略寫得很白話：盡快回應，持續處理。服務收到查詢後，只等外掛一段很短的快速回應窗（環境變數預設 4 秒），時間一到就先把拿得到的結果包回去，慢的外掛交給背景工作繼續查、查到的結果寫進外掛快取（預設保留 1 小時），下次有人查同一個字就直接用。我實測到的 321 筆對 29 筆，對上這個設計就有了合理解釋：第一次查詢碰上背景任務剛補完的快取，冷測那次則是快取過期、多數外掛又沒趕上 4 秒窗。另外查詢結果還有一層分片式的記憶體加磁碟快取（預設 60 分鐘、上限 100MB），重複查詢的延遲會明顯壓低，這部分是文件寫明的設計。
排序也有公式可循，而且值得每個使用者看一眼：一筆結果的總分，等於外掛等級分加時間分再加關鍵詞分。外掛被作者分成四級，等級一是 1000 分、等級二 500 分、等級三 0 分、等級四直接倒扣 200 分，這一項就佔了約一半權重，換句話說，同一批結果裡，高等級外掛回的舊連結，排名仍會壓過低等級外掛回的新連結。時間分看新鮮度，一天內最高 500 分，超過一年只剩 20 分。關鍵詞分則洩露了這套工具的使用者樣貌：標題帶「合集」加 420 分、「系列」350 分、「全」280 分，公式明擺著為影集合集型的資源調校。如果你要找的是單一檔案或冷門文件，這個排名邏輯和你的直覺不會在同一條線上，好在 API 參數能指定來源、類型與關鍵詞過濾，把排序的最終裁量權還給你。
講完機制，回頭看部署形態會更有感。官方映像檔有兩種：前後端整合版一個容器同時給你 API 和搜尋頁面（80 埠，裝好就有畫面）；純 API 版只有後端（8888 埠），給想自己接前端或腳本的人。來源設定全部靠環境變數：CHANNELS 決定要掃哪些 Telegram 頻道，純後端引擎不另外設定就只有官方預設的單一頻道，整合版映像檔則預先內建數十個，README 的範例設定列了 50 多個頻道名稱，本身就能當一份現成的頻道清單；ENABLED_PLUGINS 決定開哪些外掛。換句話說，索引範圍完全由你定義，這是它和商業搜尋服務最根本的差別，也是結果會因人而異的原因。前端本身是另一個獨立倉庫，星數 300 多，兩邊同步在更新。
和 AList 的差別：搜別人分享的，不是掛自己的
很多人會把 PanSou 和 AList 擺在一起比較，兩者其實站在不同層。AList 做的是把你自己的雲端硬碟帳號掛載成統一入口，檔案在你的帳號裡，它只負責介面與轉發；PanSou 恰好相反，它完全不碰你的檔案，搜的是別人公開分享出來的連結，來源是 Telegram 頻道和第三方資源站。一個是儲存層的聚合，一個是發現層的聚合，真正務實的用法是兩者接力：用 PanSou 找到分享連結，再轉存進自己的空間，例如 PikPak 這類支援離線下載與轉存的服務就是常見的下一站。如果你只是要把 Telegram 頻道裡的媒體收下來，也有更專門的 Telegram 媒體下載工具可搭著用。
支援的連線類型共 14 種：百度、阿里、夸克、光鴨、天翼、UC、中國移動、115、PikPak、迅雷、123 這十一個雲端空間品牌，加上磁力連結、ed2k（eDonkey）連結，以及無法歸類的其他。要注意其中多數是中國大陸的服務，從台灣取用時，帳號註冊與下載速度都有實際門檻，相對通用的是 PikPak 與兩種點對點連結協定。另外 API 還有一個文件裡寫得低調、其實很務實的端點：連結有效性檢查，把分享連結丟給它，會回報有效、失效、需要提取碼、不支援或不確定，畢竟分享連結會死，這個功能會幫你先過濾一遍再點。
自架前先過這五關
綜合倉庫文件與使用者的 issue 回報，自架前該知道的事可以收攏成五條：
- 外掛預設不一定開。純後端 API 版的環境變數 ENABLED_PLUGINS 必須明確指定才會啟用任何外掛，倉庫的外掛目錄有 91 個；前後端整合版則反過來，映像檔預設就啟用 28 個外掛。用純後端版什麼都不設，你只會查到 Telegram 預設頻道的結果。
- 認證預設關閉。AUTH_ENABLED 出廠值是 false，不開它，服務就是一個無密碼的公開查詢 API。要放到有對外 IP 的機器上，先開 JWT 認證、設好帳號密碼，官方文件有現成指令。
- 網路位置決定能不能用。PanSou 要連 Telegram 的公開頻道頁面抓訊息，t.me 在部分網路環境會被 DNS 解析擋掉，issue 裡就有使用者回報因此整批來源失效，README 為此提供了 SOCKS5 代理的正式設定。你的伺服器在哪，直接決定這套工具剩多少功能。
- 外掛會失控，資源會膨脹。有使用者回報單一外掛一天狂發 30,689 次請求、只有 36 次成功，日誌 13 萬行幾乎全是它，記憶體吃到超過 4GB。自架意味著你接管了這些第三方程式的行為，來源要挑、日誌要看。
- 內容合法性自己把關。外掛名單裡有海盜灣、nyaa 這類資源站，排序公式又偏好合集，這個生態的重心在哪裡很誠實地寫在程式裡。作者自己在倉庫簡介也寫明僅供學習研究、不要用於營利。找到連結不等於取得授權，下載與散布的著作權責任，不會因為工具開源而轉移。
示範站、搜尋引擎與商用授權：三個疑問
示範站可以直接拿來用嗎？
可以查，介面也算順手，但那是站方架的實例：來源怎麼設、速率怎麼限（文件提供的 nginx 範例是每分鐘 60 次請求）、查詢紀錄落在誰手裡，都不受你控制。偶爾查一下無妨，認真要當工具用，自架才握得住變數。
它和直接用 Google 加 site: 搜尋差在哪？
差在形態與加工。搜尋引擎給你網頁，PanSou 給你結構化的 JSON：連結已按雲端空間類型分組、附提取碼與時間戳記，還能批次檢查連結是否活著。要接進自己的腳本、機器人或儀表板，API 形態省掉的是解析網頁的成本，這正是它對開發者最有價值的部分。
授權可以商用嗎？
授權條款本身是 MIT，條款允許商業使用；但作者在倉庫簡介明確表達了僅供學習研究、不要用於營利的期望。條款給你的權利和作者的心願是兩件事，真要商業化，先想清楚來源內容的法律風險，那才是比授權條款更硬的約束。
誰該自架，誰繞道
我的判斷：適合 PanSou 的人，是想要一條固定來源、固定格式的聚合查詢管線，並且願意花一個下午挑外掛、開認證、看著日誌調校的自架玩家。它成熟到能當積木，還不夠格當產品。驗收標準也很具體：當你把頻道與外掛清單固定下來、快取熱起來之後，同一個關鍵字的結果數與回應時間應該趨於穩定，如果還是每次都大起大落，先回去檢查哪個外掛在拖垮整批查詢。反過來說，如果你只是偶爾找一份公開檔案，一般搜尋引擎加站內搜尋語法就夠；想管理自己雲端帳號裡的檔案，去找 AList；要找的是自己硬碟裡的東西，本地檔案搜尋工具像是 Mango Finder 更對口。專案本身仍活躍，實測前一週主分支還有修復提交，值得每隔一陣子回倉庫看看外掛名單又長出什麼。
