LineBridge 怎麼連 AI Agent？先分清本機 CLI、雲端 MCP 與 LINE 收發
把 LineBridge 裝在 Mac 上，再讓雲端 AI 呼叫 localhost，不會自動連到那台 Mac。先確認 AI 的命令實際在哪台主機執行：能操作同一台電腦終端機的 AI，可走本機 CLI；只有雲端執行環境的 AI，需要另外可達的 gateway 與遠端授權。 兩條路的憑證、暴露範圍和驗收方式不同。
LineBridge 作者文件將它定位為接收 LINE 訊息、提供指定聊天室讀取、封存搜尋與明確授權傳送的橋接器。本文依 2026-10-12 的儲存庫文件整理連線與驗收指南，沒有實際安裝或登入 LINE，也不把社群展示當成自己的實測。
先選本機或雲端，不要先開 tunnel
依 CONNECTIONS.md，目前支援的 LineBridge CLI 與 service 在 Windows／macOS 執行；Linux 主機可作為 HTTP／MCP client。若 AI 的工具能在你持續開機、連網的 Windows／Mac 上執行既有 CLI，就不需要為這條本機路徑另外註冊雲端 connector。
| AI 的執行位置 | 接入方式 | 要確認的邊界 |
|---|---|---|
| 與 LineBridge 同一台 Windows／Mac，可操作終端機 | 既有受保護的 CLI profile | 同一 OS 使用者、原資料目錄、有效 profile 與聊天室範圍 |
| 本機相容 MCP client | 本機 MCP 接入；Codex 另有作者提供的 stdio adapter 流程 | client 所用憑證與工具範圍；adapter 不會自動建立雲端 Dot connector |
| 只有遠端雲端執行環境 | 可達的 HTTPS gateway 與相容 HTTP／MCP client | 從該雲端環境驗證連線，另有遠端授權與私密憑證設定 |
這裡的「Dot」不能單靠產品名稱分流：同一個 AI 若有本機終端工具與雲端工具，要看這一次呼叫選了哪個執行端。先在任務紀錄列出 LineBridge 主機、CLI 主機與 MCP client 主機，再選連線方式，才能避免在錯的主機查 PATH、重裝套件或反覆重試 localhost。
作者文件也明確限制：local wizard 建立的 profile 不能直接經 tunnel 使用。 遠端連線要另行授權；不要只是把 URL 改成公開 HTTPS，就假設原本的本機 profile 已有遠端存取權。
保存的聊天室授權，不代表 LINE 已收到新訊息
第一次使用前，需由使用者完成 LINE 配對與聊天室範圍確認。讀取與傳送是獨立 grant；只有摘要需求時，不必順帶開傳送。憑證透過 client 私密設定或受保護環境提供，不把 token 貼進對話、命令參數或 log。
作者的範圍規則指出，聊天室 AI 開關同時涉及 monitoring 與 managed local profile。關閉聊天室也會擋住其他 client 對該聊天室的存取；若開啟會連帶授權 manual／remote client，需先檢查那些 client 的範圍。這不是每個 client 完全獨立的一顆 UI 開關。
新增聊天室後，分開檢查「scope 已保存」與「receiver 有近期成功接收」。同一張儀表板顯示已開啟，不代表 LINE poll 已成功；反過來，沒有新訊息也不一定是故障，已完成的空 poll 仍可構成接收健康證據。依已安裝版本回報的欄位判讀，不能把 pending 當成新的成功紀錄。
若你正在決定是否需要把整套工具接到 AI，可先看 接 MCP 前的能力盤點；這裡真正要解決的是指定聊天室的存取，不是一次開放所有工具。
用三層驗收找出故障位置
下面是依作者文件設計的驗收順序，並非本文已執行的整合結果。先準備一個使用者已同意、沒有敏感內容的測試聊天室，保存每層的時間、主機、版本與去敏錯誤碼。
1. Gateway 可達，client 取得預期工具
本機 CLI 在原安裝資料夾、以原 OS 使用者執行。macOS 的文件範例入口如下，Windows 對應 .\linebridge.cmd；實際使用安裝版本的 launcher 與 --help：
./linebridge --version./linebridge status./linebridge discover若 AI 使用遠端環境，要從那個環境檢查 DNS、HTTPS、未授權請求遭拒、預期 scope API 與 MCP tool discovery。自己電腦開得到 URL，不能替雲端 client 通過驗收。作者提供的 examples/probe-connection.mjs 處理這些連線檢查，但不接觸 LINE、也不傳送訊息；本文沒有執行它。
需要遠端連線時，只轉送 status 回報的 gateway port。作者預設 gateway 為 3211、管理介面為 3210，但應使用當前狀態的實際值；管理介面留在 loopback，不一併對外轉送。接入前先確認 client 支援文件所述的 stateless Streamable HTTP MCP 與 JSON responses，不能把「任何 MCP client」都當成已相容。
2. LINE 接收有近期成功，內容能讀回
由使用者在測試聊天室送入一段可辨識的無敏感文字，再確認該聊天室 receiver 的近期 durable success，以及具讀取權限的 client 能讀到這段文字。記錄時間與聊天室 ID，不需要公開整份聊天。
如果第一層通過、這層失敗，先查監控聊天室、profile、grant 到期／撤銷與接收串流錯誤。CLI 文件將服務可達與接收健康分開；不要只看到 HTTP 200 就宣告 LINE 正常，也不要用新的空資料目錄取代原封存來掩蓋問題。
3. 需要傳送時，再做一則明確授權的測試
讀取摘要通過後，若工作流確實需要傳送，再由使用者確認確切聊天室與訊息內容，確認 send grant，為該次請求保留穩定的 idempotency key。不能把讀取權限或聊天裡的一句指令當成傳送授權。
依 explicit sends 的契約，遇到 delivery_unknown，先查聊天室是否已有訊息；無法確認就保持結果不明，不自動重送，也不換新的 key 繞過去。API 接受或回傳 message ID 不等於收件者收到、已讀，或 Flex 已正確顯示。驗收紀錄要把「client 回應」「LINE 接受」「聊天室看見內容」各自記下。
官方 Messaging API 與 LineBridge 是不同選擇
LineBridge 作者明確說明 LINE 介面非官方，OpenChat 仍有實驗性質，上游變更會影響可用性。不能用它目前可讀個人聊天的定位，推論成 LINE 官方保證的功能。
若需求是讓 LINE 官方帳號 bot 回應使用者，應評估 LINE 官方 Messaging API 的 webhook、reply 與 push 路徑。若需求是讓 AI 存取自己選定的既有聊天室，再評估 LineBridge 的接收方式與非官方限制；兩者不是只換一個 URL 就能替代。
本文查核範圍為 LineBridge main revision ec7435b 的 README、CLI 與 connections 文件，未驗證安裝套件、QR 配對、遠端 tunnel、MCP 呼叫、接收或傳送。接入時以實際安裝版本的說明為準，先完成本機／雲端位置與三層驗收，再決定是否開啟排程或擴大聊天室範圍。
參考資料：