hCaptcha Challenger：用 ONNX 模型與多模態 LLM 拆解 hCaptcha 的五種題型
🥂 Gracefully face hCaptcha challenge with multimodal large language model.
秒懂
- 它是什麼？
- 這個專案把 hCaptcha 的驗證流程拆成可插拔的模型管線，從 ResNet 分類、YOLOv8 偵測到 Spatial Chain-of-Thought，並以 GPL-3.0 釋出。本文檢視它實際解決的問題、模型載入與 Agent 工作流的機制，以及在什麼情況下它會是錯的工具。
- 適合誰用？
- 這個專案適合已經在用 Playwright 跑自動化、且能自行承擔模型推論與 LLM API 成本的團隊；如果你的場景只需要處理單一固定題型，或無法接受 GPL-3.0 的傳染性條款，它會是錯的工具。導入前先確認三件事：你的 hCaptcha 題型是否落在 README 表格所列的五類之內、模型的 ONNX 權重是從 GitHub Releases 的 model tag 取得還是需要自行訓練、以及 Agentic Workflow 所依賴的多模態 LLM 供應商與計費方式。
- 可以商用嗎？
- 可以，但有條件。GPL-3.0 是 copyleft 授權：如果你散布包含它的軟體，就必須以同一授權公開該軟體的原始碼。只在內部執行、不對外散布，則不會觸發這項義務。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 32 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要解的不是「破解驗證碼」，而是「讓 AI 對上 AI」
README 的 Introduction 寫得很直白：不依賴任何 Tampermonkey 腳本、不使用任何第三方打碼服務，只是實作一些介面，讓 AI vs AI 成為可能。這句話界定了專案的邊界。它不仲介外部人力或商業打碼 API，所有辨識都在你自己的環境裡跑模型。
目標使用者因此相當明確：已經用 Playwright 之類的工具驅動瀏覽器、需要在流程中通過 hCaptcha 的開發者。專案主題標籤裡同時出現 agent、ai-agents、playwright、yolo、clip，說明它被定位成自動化代理的一環，而不是獨立的桌面工具。
這裡有一個現實層面的取捨。繞過驗證碼這件事本身牽涉服務條款與法律風險，專案以 GPL-3.0 釋出並公開模型與資料集，等於把責任完全推給使用者。文件裡沒有任何合規聲明，也沒有使用情境的限制說明。要採用的人得自己判斷。
五種題型、五條模型管線
README 的 What's features 表格是理解這個專案最關鍵的一張表。它把 hCaptcha 的挑戰類型逐一對應到可插拔資源：image_label_binary 走 ResNet ONNX 分類；image_label_area_select 的 point 模式走 YOLOv8 ONNX 偵測；同一題型的 bounding box 模式走 YOLOv8 ONNX 分割；image_label_multiple_choice 走 ViT ONNX zero-shot；image_drag_drop 走 Spatial Chain-of-Thought。
表格右側還有一欄 Agent Capability，只有 image_label_binary、area_select 的 point 模式、以及 image_drag_drop 三項被標記為支援。bounding box 分割與 multiple_choice 兩項是空的。這個細節比表格本身更值得注意：它意味著後兩類題型目前沒有走 Agent 路徑，而是純模型推論。如果你的目標網站大量出現這兩類題目，這個專案的成熟度對你而言和前三類不是同一回事。
進階任務另外列了三項：Rank.Strategy 對應 nested-model-zoo、self-supervised challenge 對應 CLIP-ViT、Agentic Workflow 對應 AIOps Multimodal Large language model。可以看出架構分成兩層，一層是針對具體題型的視覺模型，另一層是決定策略與調度模型的工作流。
模型從哪裡來：Releases 的 model tag 與 CI 收集流程
Workflow 表格透露了模型的來源鏈。ci: sentinel 與 ci: collector 是兩個 GitHub Actions 工作流，分別對應 sentinel.yaml 與 collector.yaml。資料集標註走 Roboflow 與 hcaptcha-model-factory，訓練則提供兩份 Colab：roboflow_resnet.ipynb 與 roboflow_yolov8.ipynb。最後 model: upload, upgrade 對應到 repo 的 src 目錄與 modelhub。
README 的徽章區有一個指向 GitHub Releases 的 model tag 下載計數，這暗示模型權重是透過 Releases 的 model 標籤發布，而不是隨 PyPI 套件一起打包。這是實務上很容易踩到的點：pip 安裝完之後，模型檔案不會自動就位。文件沒有在提供的內容裡明說首次執行時是否會自動下載，這一點需要在實際環境中確認。
公開資料集放在 Roboflow Universe 與 hcaptcha-whistleblower 兩個位置。對想自行微調的人來說，這是有意義的：訓練腳本與資料集都是公開的，題型變了可以自己重訓，不必等上游更新。代價是這條路徑需要標註能力與 GPU 時間。
Agentic Workflow 依賴外部 LLM，成本結構與純 ONNX 不同
表格裡最晚出現的一項是 Agentic Workflow，對應 PR #980，時間戳記為 250331，而 v0.19.0 在 2026 年 1 月發布。也就是說這條路徑相對年輕。
它的設計取向和前面的 ONNX 模型不同。ResNet、YOLOv8、ViT 這些模型一旦下載完成，推論在本機進行，沒有每次呼叫的邊際成本。Agentic Workflow 走的是多模態大型語言模型，README 的 Reference 列出 Google Gemini 的文件連結，以及 Anthropic/MCP 與 Google/A2A 兩個協定。這代表通過驗證的過程會涉及外部 API 呼叫。
差別不只是錢。外部 API 意味著延遲、可用性與速率限制都受制於第三方，而且驗證碼圖片會被送到該供應商。對於處理敏感目標的團隊，這是一個必須先想清楚的架構決策，而不是實作細節。
Spatial Chain-of-Thought 用在 image_drag_drop 上，同樣是這一類需要推理而非單純分類的題型。拖曳題的難點在於判斷物件與目標位置的空間關係，這正是視覺語言模型相對擅長的區塊，也是純 CNN 難以處理的部分。這個選擇在技術上是合理的。
安裝與啟動：從 PyPI 到 Playwright 的實際步驟
套件名稱是 hcaptcha-challenger，發布在 PyPI，主語言為 Python。README 以徽章形式標示 PyPI 版本與下載量，但沒有在提供的內容中給出安裝指令。依套件名稱推斷，安裝方式應為 pip install hcaptcha-challenger，這一點請以官方文件 docs/README.md 或 docs/README_zh.md 為準，我無法從現有材料確認。
可以確認的是相依元件。專案主題包含 playwright，Reference 第一項就是 microsoft/playwright-python，所以瀏覽器自動化層依賴 Playwright，需要先執行 playwright install 安裝瀏覽器二進位檔。模型權重則來自 GitHub Releases 的 model tag 與 repo 內的 src 目錄，屬於獨立於 pip 的取得步驟。
文件提供四種語言版本：英文、簡體中文、俄文、越南文。繁體中文讀者可以直接讀簡體中文版，術語差異不大。
專案還提到 undetected-playwright，用來藏匿 Playwright 的指紋。這暗示單靠這個套件不一定足夠，瀏覽器指紋本身也是偵測面。這是自動化鏈上另一個需要單獨處理的環節。
真正的限制：模型會過期，題型會漂移
這個專案最根本的脆弱點在於它對抗的是一個持續變動的目標。hCaptcha 的題型與圖片風格會調整，模型訓練時見過的分布和線上遇到的不會完全一致。README 用 sentinel 與 collector 兩個 CI 工作流來持續收集與監測，正是對這個問題的回應。但監測不等於免疫。
表格中 Agent Capability 有兩格是空的，這是可以量化的限制。bounding box 分割與 multiple_choice 沒有 Agent 支援，意味著這兩類題型沒有策略層的調度，只能靠單一模型硬解。準確率如何，文件沒有給出任何數字，我不會替它編一個。
另一個容易被忽略的成本是維護。模型需要跟著上游題型更新，Releases 的節奏可以參考：v0.18.12 到 v0.18.13 相隔四天，v0.18.13 到 v0.19.0 相隔約兩個半月。這不是一個發版頻繁到可以忽略的專案，也不是停滯的專案。採用它等於接受一條需要跟進的升級線。
還有一個更基本的問題：這類工具的存在本身會推動防守方升級。這不是專案的缺陷，而是這條賽道的結構性特徵，評估時應該把它算進長期成本。
替代路線：商業打碼 API 與自建模型的差別
最直接的替代方案是第三方打碼服務。README 明確說不使用這類服務，這正好點出兩條路線的分野。商業 API 把辨識外包出去，你付出的是每次呼叫的費用，換來的是對方持續維護模型、承擔題型漂移的成本，而且不需要在本機跑 GPU 推論。hcaptcha-challenger 走相反方向：前期投入在環境建置與模型管理，之後每次辨識的邊際成本接近零，但題型變了要自己想辦法。
另一條路是自己從零訓練。這個專案其實已經把這條路的材料攤開：Roboflow 上的公開資料集、兩份 Colab 訓練筆記本、以及 hcaptcha-model-factory 這個獨立 repo。差別在於它是把資料、訓練腳本與推論框架綁成一套，你不用自己設計 ResNet 與 YOLOv8 的接法，也不用自己處理題型分派。
選擇的判斷點很清楚。如果你的請求量小、題型雜、不想養模型，商業 API 的總成本更低。如果你有穩定的請求量、能接受 GPL-3.0、並且願意把模型更新納入維運，這套自建管線的長期成本結構更可控。中間沒有模糊地帶。
授權與升級：GPL-3.0 的實際約束
專案採用 GPL-3.0。這是一個傳染性授權，如果你把它的程式碼整合進自己的產品並散布，通常需要以相同授權釋出對應部分。單純在內部使用、或把它當成獨立執行的服務來呼叫，情況不同。具體界線請諮詢律師，我只能指出這是採用前必須釐清的一項。
升級成本方面，從版本節奏看，v0.18.x 系列在 2025 年 10 月連續發了兩個版本，v0.19.0 在 2026 年 1 月。這種節奏意味著修補與功能更新是持續的，但沒有到需要每週跟進的程度。真正需要留意的是模型權重的版本與程式碼版本是否對齊，因為模型透過 Releases 的 model tag 獨立發布，兩者的更新時機不一定同步。
專案仍在活躍維護，最後推送時間為 2026 年 8 月，未封存。What's next 段落列出 Dislock、undetected-playwright、epic-awesome-gamer 三個相關專案，可以看出作者把它當成一個生態的其中一塊，而不是單點工具。這對長期維護是正面訊號，但也意味著這個套件的方向會受整個生態的優先順序影響。
編輯結論
這個專案適合已經在用 Playwright 跑自動化、且能自行承擔模型推論與 LLM API 成本的團隊；如果你的場景只需要處理單一固定題型，或無法接受 GPL-3.0 的傳染性條款，它會是錯的工具。導入前先確認三件事：你的 hCaptcha 題型是否落在 README 表格所列的五類之內、模型的 ONNX 權重是從 GitHub Releases 的 model tag 取得還是需要自行訓練、以及 Agentic Workflow 所依賴的多模態 LLM 供應商與計費方式。這三項沒確認完，其餘的評估都是空談。
社群筆記