Integuru v0：把瀏覽器請求變成整合程式碼，但你要先接受它的前提
The first AI agent that builds permissionless integrations through reverse engineering platforms' internal APIs.
秒懂
- 它是什麼？
- Integuru v0 是一個用 LLM 逆向工程平台內部 API、自動產生整合程式碼的開源專案。它解決的是「沒有官方 API 時的自動化」問題，但前提是你願意交出 HAR 檔與 cookies，而且模型品質直接決定成敗。
- 適合誰用？
- Integuru v0 適合想快速建立非官方 API 整合的開發者或自動化工程師，尤其是目標平台沒有公開 API、你又願意手動操作瀏覽器錄製 HAR 檔的場景。不適合需要長期穩定、頻繁變動的整合，因為內部 API 隨時可能改版，而這套工具沒有處理 API 變遷的機制。
- 可以商用嗎？
- 可以，但條件嚴格。AGPL-3.0 是網路 copyleft 授權：如果別人透過網路使用你修改過的版本（例如作為託管服務），你必須以同一授權向他們提供原始碼。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 83 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的問題：沒有官方 API 的平台自動化
許多商業平台不提供公開 API，或只提供功能受限的付費版本。想自動化下載帳單、匯出報表、提交表單，傳統做法是寫網頁爬蟲，但爬蟲要處理 DOM 結構、JavaScript 渲染、驗證碼，既脆弱又費工。Integuru v0 換了一條路：它不碰網頁介面，直接分析瀏覽器發出的網路請求，找出背後真正在跑的內部 API，然後產生呼叫這些 API 的 Python 程式碼。這套工具是給具備一定技術背景的人用的，不是給一般使用者。你需要能操作瀏覽器、能讀懂 HAR 檔內容、能審查產生的程式碼。它本質上把「逆向工程」這件事從人工拆解請求，變成 LLM 輔助的自動化流程。
運作機制：從 HAR 檔建立依賴圖，再轉成函式
Integuru v0 的核心流程在 README 有清楚的五個步驟。首先，你用 create_har.py 錄下瀏覽器執行某個動作時的所有網路請求，存成 network_requests.har，同時把 cookies 存成 cookies.json。接著，你給 LLM 一個 prompt，描述你觸發的動作，例如「download utility bills」。代理會先找出哪一個請求真正下載了帳單，再檢查這個請求的 URL 中哪些參數是動態的，例如 accountId 和 userId。這些動態參數必須從其他請求的回應中取得，於是代理會找出提供這些參數的請求，把它們設為下載請求的前置依賴。這個過程會重複，直到某個請求只依賴 cookies 為止。最後，代理會從沒有後續依賴的請求開始，沿著依賴圖向上遍歷，把每個請求轉換成一個可執行的 Python 函式。整個過程的關鍵在於依賴圖的建立，這不是單純的 URL 比對，而是讓 LLM 判斷參數之間的來源關係。
實際安裝與執行：Poetry、Jupyter 與模型選擇
安裝流程要求你先設定 OPENAI_API_KEY 環境變數，然後用 poetry install 安裝依賴。接著要開啟 poetry shell，並執行 poetry run ipython kernel install --user --name=integuru 來註冊 Jupyter kernel，因為 README 提供 main.ipynb 作為另一種執行方式。實際使用分兩個階段。第一階段執行 poetry run python create_har.py，這會啟動一個瀏覽器，你必須手動登入平台、執行你想自動化的動作，例如下載帳單，完成後關閉瀏覽器，程式會產生 HAR 檔與 cookies 檔。第二階段執行 poetry run integuru --prompt "download utility bills" --model gpt-4o，代理會讀取預設的 ./network_requests.har 與 ./cookies.json，開始分析。命令列參數包括 --har-path、--cookie-path、--max_steps（預設 20）與 --input_variables，後者可以傳入像是年份這類變數，但 README 明確說 input variables 目前只支援圖形產生階段，程式碼產生階段還沒實作。模型選擇上，README 建議圖形產生用 gpt-4o，因為它支援 function calling；程式碼產生則會自動切換到 o1-preview，前提是你的 OpenAI 帳號有權限。
真正的限制：依賴圖建構的品質與範圍
Integuru v0 不是萬靈丹。它依賴 LLM 正確判斷請求之間的依賴關係，而這個判斷沒有驗證機制。如果 LLM 漏掉某個動態參數，或把不相干的請求當成依賴，產出的程式碼就會出錯。README 雖然提到 max_steps 參數，但沒有說明超過步驟上限會發生什麼事，是回報錯誤還是產生不完整的圖？再者，input variables 只支援圖形產生，代表你無法在產生的程式碼中動態指定參數，例如下載不同年份的帳單，這大大限制了它的實用性。另外，整個流程假設目標平台的內部 API 結構是穩定的，但實際上許多平台的內部 API 會頻繁變動，而這套工具沒有任何處理 API 版本變遷的機制。它適合一次性、短期的自動化任務，不適合需要長期維護的整合。
安全與隱私的取捨：HAR 檔與 cookies 的風險
使用 Integuru v0 等於把平台的完整請求記錄與你的登入狀態交給本機檔案，再讓雲端 LLM 分析。README 的 Privacy Policy 說資料儲存在本機的 network_requests.har 與 cookies.json，而 LLM 使用的是 OpenAI 的 GPT-4o 與 o1-preview，並聲明 LLM 不會用這些資料來訓練。但這裡有個沒有明說的問題：HAR 檔通常包含請求標頭、查詢參數、回應內容，這些可能含有個人資料或商業機密。你把這些內容送給 OpenAI 的 API，即使 OpenAI 不訓練模型，資料仍然會經過第三方伺服器。另外，README 提到當目標平台使用雙重驗證（2FA）時，你必須先完成 2FA，再把取得的 cookies 或 session token 交給工具。這代表你的 session 可能長時間有效，而這些 cookies 是以純文字存在本機，任何能讀取你檔案系統的程式都能取得。對於處理敏感資料的平台，這個風險你必須自己評估。
授權與維護成本：AGPL-3.0 與專案現況
這個儲存庫採用 AGPL-3.0 授權，這對商業使用有重大影響。AGPL 要求如果你修改程式碼並透過網路提供服務，你必須開放原始碼。如果你只是內部使用，不提供給外部使用者，影響較小；但如果你想把它整合進自己的 SaaS 產品，就可能需要開放整個服務的原始碼。這不是法律建議，但授權條款確實是採用前必須確認的項目。關於維護，這個儲存庫的 README 開頭就說這是「earliest version」，而最新版本在 integuru.com，且最後一次 push 是 2026 年 6 月，但沒有列出任何 release。這代表 v0 版本可能不會有太多後續更新，bug 修復與新功能都會集中在商業版本。如果你要長期使用，你必須自己維護這個 fork，或者考慮改用商業版本。另外，CI 流程只做了最基本的檢查：設定 Python 3.12、安裝依賴、執行 pytest，沒有整合測試或端對端測試，這也反映出這個專案仍處於早期階段。
替代方案：RPA 工具與 OpenAPI 生成器的本質差異
Integuru 的定位是「permissionless integrations」，也就是不依賴官方 API 的整合。最接近的替代方案是傳統 RPA 工具，例如 UiPath 或開源的 Robot Framework。RPA 工具模擬使用者的滑鼠與鍵盤操作，直接控制瀏覽器或桌面應用程式，它們不需要理解內部 API，但執行速度慢、容易受 UI 改版影響，而且通常需要付費授權。Integuru 則繞過 UI，直接呼叫內部 API，執行效率高，但前提是 LLM 能正確建構依賴圖。另一類替代是 OpenAPI 生成器，例如 OpenAPI Generator，它從官方 API 規格產生客戶端程式碼，穩定且可維護，但前提是平台必須提供 OpenAPI 規格，而這正是 Integuru 想解決的問題。所以選擇很明確：如果平台有官方 API，你不需要 Integuru；如果平台沒有，而且你不想寫爬蟲，Integuru 是少數能自動產生內部 API 呼叫程式碼的開源選項，但它犧牲了穩定性與安全性。
編輯結論
Integuru v0 適合想快速建立非官方 API 整合的開發者或自動化工程師，尤其是目標平台沒有公開 API、你又願意手動操作瀏覽器錄製 HAR 檔的場景。不適合需要長期穩定、頻繁變動的整合，因為內部 API 隨時可能改版，而這套工具沒有處理 API 變遷的機制。也不適合對資料隱私敏感的使用者，因為 HAR 檔包含完整請求內容，cookies 更是直接交給本機檔案與雲端 LLM。採用前你必須先確認三件事：你的 OpenAI 帳號是否能存取 o1-preview 或 o1-mini，因為 README 明說模型能力至少要到 o1-mini 等級；你能否接受 AGPL-3.0 的授權條款，這對商業內嵌使用是關鍵門檻；以及你是否有能力手動檢查產出的程式碼，因為逆向工程的結果沒有官方保證。若你只需要單一平台的簡單動作，例如下載帳單，這套工具值得一試；若你要的是可維護的整合層，請另尋其他方案。
社群筆記