三個機器人怎麼選？開源、訂閱、交易所內建

想讓 AI 生的 Pine Script（TradingView 的程式語言，用來寫交易策略和指標）自動跑，第一步是找能接 webhook（伺服器接收外部通知的機制）的機器人。市面上分三類：開源自己架、按月付錢用別人的、交易所內建的。價格差異從零到每月幾十美元不等，但關鍵不在功能多不多，而在哪一層需要你自己動手。而不管是哪一種方案，都離不開一個核心概念：API Key（應用程式金鑰，用來讓機器人代表你向交易所下單的憑證）。

這篇文章不評論你用的是哪個方案好不好——我們沒做過這種測試，這篇也不會做。我們只給你三件事：三種機器人各自在哪裡介入（Alert→Webhook→下單）、每種方案的風險在哪一層由你承擔、開源方案裡哪個訊號可以實測而不需要完全信任廠商的保證。

TradingView 的 alert() 到底傳了什麼？

Pine Script 有兩個產生 alert 事件的函式：alert() 和 alertcondition()。它們都不是直接傳送 webhook——它們只是在 TradingView 伺服器上建立一個觸發事件，然後由你在 Create Alert 對話框裡設定 Webhook URL，TradingView 才會把訊號送出去。

alert() 的完整簽名是 alert(message, freq)，只有兩個參數。message 是觸發時傳送的訊息文字，支援 {{ticker}}、{{close}} 等佔位符；freq 是可選的頻率控制，預設是 alert.freq_once_per_bar（每個實時 K 棒只觸發一次）。沒有 url 參數，也沒有 title 參數。

//@version=6
        indicator("My Alert", overlay=true)
        cross = ta.crossover(close, ta.sma(close, 14))
        if cross
            alert("Price " + str.tostring(close) +
                  " crossed MA. Symbol: {{ticker}}",
                  alert.freq_once_per_bar)
        plot(ta.sma(close, 14))

上一版把 alert() 寫成「只能傳 URL 和一個 title 參數」是錯的——那個 URL 根本不在 Pine Script 裡面，它在 Create Alert 對話框的 Webhook URL 欄位。title 也不存在，只有 alertcondition() 才有可選的 title（用在對話框的 Condition 下拉選單裡）。這是一個基礎文檔宣稱漏洞，會直接影響讀者寫的 alert 能不能正確觸發。

開源方案：誰該自己架、誰不該？

開源機器人通常以 GitHub 上的專案形式存在。它們的架構大同小異：收到 TradingView webhook → 解析 payload → 驗證 API Key → 下單到交易所。透明度高，因為你能看到每一行程式碼。

但透明不等於安全。你必須自己處理：資料庫連線、API Key 加密儲存、伺服器維運、webhook 被截斷時的重試邏輯、以及交易所 API 版本升級後的相容性問題。交易所偶爾會改名欄位或調整格式，開源專案通常要等作者更新才跟得上——如果你的策略不在熱門專案的支援清單裡，可能就要自己改程式。

訂閱制機器人：你買的是什麼？

按月或按年付費，換取「別人幫你架好所有東西」。通常會提供一個 dashboard，讓你看到 webhook 有沒有送達、下單成功失敗的紀錄。優點是零維護，缺點是你不知道平台背後到底做了什麼。

訂閱制機器人的 dashboard UI、webhook payload 解析邏輯、支援哪些帳戶模式，這些東西在 TradingView 官方文件都沒有提及——它們都是第三方的延伸應用。你買的是「有人幫你處理這些細節」的安心感。

• 你的 API Key 存在哪裡？平台自己的伺服器還是你手邊的加密金鑰管理器？
• 下單失敗時，平台有重試嗎？重試幾次？退避時間多長？
• 如果平台關了，你的策略還能跑嗎？資料能導出嗎？

交易所內建方案有什麼限制？

有些交易所（如 Binance、OKX）的 API Key 頁面提供基本的權限設定，但不提供 webhook 監控、下單紀錄查詢、或「為什麼這筆單被擋」的詳細原因。它是最簡單的方案——因為簡單到幾乎什麼都沒有。

如果你直接從交易所 API Key 頁面下單，你失去的不只是除錯資訊：你不知道這筆單到底有沒有送到交易所，失敗的原因是什麼，以及有沒有重試機制。對於需要自動交易的場景，這等於把風險全部留給自己承擔。

斷線時，掛單會撤、部位不會被動嗎？

Binance、OKX、Bybit、Bitget 的斷線自動撤單機制範圍都嚴格限定在撤銷「掛單」——沒有一份提到部位。這意味著如果你的交易所當機、你的 WebSocket 斷線，那些已經成交的部位不會被自動平倉。

我們查過 Bybit 的 Disconnect Cancel All (DCP) 文件，它明確說只針對 open orders。Binance 的 Kill-Switch 同理。Bitget 的 CountDown Cancel All 也是同樣的範圍。沒有任何一份官方文件直接寫明會自動平倉。

TradingView 有 SLA 嗎？

TradingView 從未針對自己故障期間漏掉的 alert 公布任何 SLA。官方條款（Section 6）沒有 uptime guarantee，Section 2 寫明了 TradingView 可以隨時停服務而不需要提前通知。TradingView 自己的 webhook 規格也明確指出：收到端超過 3 秒沒回應就取消、不重試；超過 15 次/3 分鐘就會自動停用 alert——這些是規格，不是 SLA。

任何自動化交易架構都保證不了 100% 送達——包括我們自己。

風險檢查清單：寫進正文之前先問自己

這篇文章不評論你用的是哪個方案好不好。但可以給你一個框架，讓你在選擇之前先問清楚幾個問題：

• 你的技術能力夠不夠維護開源方案的日常維運？
• 你願意為省麻煩付多少錢？不同方案的月費從零到幾十美元不等，差別不只是功能數量，還有 API Key 託管的安全模型。
• 如果這個平台明天關了，你的策略還能繼續跑嗎？
• 下單失敗時，你有多快能發現？是靠 dashboard 的通知、還是等錢不見了才發現？

關於 webhook 機器人，常見的疑問有哪些？

這些問題來自過去半年內社群和客戶最常問的提問。我們只回答查得到依據的部分——查不到的就不假裝知道。

如果你的情況不在下面列出來，也可以直接去 TVSBot 的 dashboard 裡找客服，或到 Telegram 社群提問。