三种机器人怎么选？开源、订阅还是交易所内置

想让 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 能不能正确触发。

开源机器人：谁该自己搭、谁不该？

它们的架构大同小异：收到 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 社群提问。