在 Telegram 里下完一整笔 Energy 订单

卖 TRON Energy 的 Telegram 机器人，通常就是一个带按钮的下单表单。选数量、付款、收到一行文字，然后坐在聊天窗口里猜资源到没到。

@rentron_energy_bot 这个 TRON 能量 Telegram 机器人是反过来做的。它不是网站的轻量副本，而是换了一道门进入的同一个账户；订单每推进一个阶段，你眼前的界面由服务器重新绘制。订单处理期间界面下方有一个刷新按钮，但整套流程里没有任何东西在等你按它。

有一条限定要放在最前面，因为被引错的正是它。上面说的是机器人的行为。公开 API 既没有 webhook 也没有回调：在 Telegram 里界面自己更新，在代码里由你按自己的节奏反复去问。

下面讲清楚三件事：机器人能做什么、它和网站是什么关系、以及“实时”这个说法到哪里为止。价格不写，报价在下单当刻给出。

机器人在聊天里到底能做什么？

整个租赁流程，以及围着它的那个账户。

一笔订单分四步：数量与时长、发起转账的地址、报价、创建订单。可选项及其取值来自网站读取的同一处，所以订单这一块没有任何删减。

围绕它的，是平时得离开聊天才能办的事。余额界面显示可用金额和为订单预留的金额，固定充值地址既是可复制的一行，也是一张二维码。常用地址可以添加、重命名、删除，每一个都能点开，看到它当前持有的资源。

历史是分页的，订单和充值各自成表。打开中的订单按阶段显示进度。设置里是界面语言，与网站发布的六种一致。客服是独立的一屏，在那里开始的对话会被转交，而不是绕回菜单。

有一项值得单独提：按地址查看资源。它把最常见的顺序倒了过来——先下单，再发现那个地址本来就有 Energy，或者选错了地址。

分页历史顶替的是聊天里不断上滑的消息。想知道某笔充值什么时候到的、某笔订单下给了哪个地址，不必往上翻，两张表各自留在自己的页码里。

主界面上还有一个按钮，把 Rentron 作为 Mini App 打开，用在整页比一条消息更好读的时候。

机器人的余额是另一个余额吗？

不是。这是这一页最该记住的一句。

在网站登录和启动机器人，指向的是同一条联系人记录。从那里出发，两边读的是同一个账户：同样的可用金额、同样的预留金额、同样的固定充值地址。不存在“属于机器人的钱包”，两边之间也没有什么需要搬来搬去。

由此带来的好处不大，但确实省事。可以在电脑上充值、在手机上下单，反过来也一样。发到那个固定地址的 TRX，从哪一边看都算数；在聊天里下的单，扣的是在网站上充进去的余额。

因此充值地址不必按入口重新复制一遍。它属于账户，而不属于某一次把它显示出来的界面。

同样值得注意的是缺席的东西：没有第二套注册。两条路都依托一个已验证的 Telegram 账号，任何一边都不会再生出一对用户名和密码。

不离开 Telegram 怎么下单？

按顺序五步：

1. 打开租赁界面，从菜单进入，或者用一条直接落到那里的链接。
2. 选数量和时长。Energy 按 65000 一份的固定份额出售，单笔订单最多 1300000，也就是二十份。时长为 15 分钟、1 小时、4 小时和 24 小时。
3. 填写发起转账的地址。常用地址点一下就选中，新地址可以在这一步添加并命名。
4. 为这笔订单取一次报价。这一步不扣款。
5. 创建订单。金额在这一步按那份报价锁定。

第 4 步需要一句直白的话。报价不预留任何东西，也不把价格留到以后——它是此刻的一个数字，真正扣的金额在创建订单时才锁定。数量的问题更早就要解决：转出 USDT 前先算清所需 Energy 讲的是具体一次调用需要多少，而租赁本身写在首页。

固定份额不是为难人。数量永远是 65000 的整数倍，选的是份数而不是任意数字，所以不可能在输入框里差一个数量级。代价也有：单笔订单二十份封顶。

时长同样是选的，不是填的。十五分钟够用，前提是转账马上就发。更长的时段留给相反的情况——下单到签名之间还有事要办：核对金额、等待批准、跟收款方确认。

地址步骤里，常用地址列表的用处也在这里显现。如果长期发往同一个地址，只需添加一次，之后每笔订单都缩成一次点击，手输带来的错字也在这一步被排除。

需要手动点刷新吗？

不需要。按钮是有的——订单处理期间它就在界面下方——但界面是订阅的，不是画一次就完事的，状态不按它也会到。

有两个事件流在喂它。一个带的是某一笔订单的状态，只要那笔订单还开着。另一个带的是充值到账，它挂在账户上，而不是挂在某一笔订单上。信号一到，界面就在原地重绘。

这些信号由服务器发布。机器人内部没有任何东西按秒表去问“变了没有”，刷新因此留给宁可自己问一句、也不愿干等的人：它不是状态送达的通道，也没有哪个间隔需要熬。

一次订阅存活 30 天；切换到另一笔订单时，订单流会转到新的那笔，而不是在旧订阅上再叠一层。收益很窄，但看得见：改变的是你正在看的那条消息。

聊天本来就不适合承载会变的状态。读过的消息定住了，新消息往下走，聊十分钟之后订单还得重新找。订阅去掉的正是这一段：订单活在一屏里，而不是活在自己历史状态的串里。

落到实处也简单：下完单不必守着。想再问一次进度，界面下方的刷新按钮就在那里——但等待是被服务器的信号结束的，不是被你的操作结束的。

API 也会主动推送吗？

不会。把这一点弄反，代价不小。

公开 API 既没有 webhook 也没有回调。订单的状态靠请求订单本身读出来。文档给出的节奏是创建后 1、2、5 秒各一次，之后每 10 秒一次；同时跟着多笔订单时，加一点抖动。

拿到响应之后怎么办，由三个标志决定。energy_usable 是用来行动的：它在 available 状态下变为 true，大约比 delivered 早一分钟，含义是 Energy 已经在地址上、可以花了。等 delivered 只是在消耗已经付过钱的租期。

delivery_final 和 lifecycle_final 是用来停的，而且必须两个都为 true。只看一个标志、或者只看某个状态就停，会把循环切得太早。另外也没有沙箱，接入方的第一次调用直接落在真实余额上。配套的重试矩阵见轮询与安全重试。

差别在“等待怎么结束”上也看得出来。在机器人里，等待自己结束：信号来了，界面变了。在代码里，结束等待的是你的循环，判断停不停的也是它——依据是标志，而不是外部送来的事件。

深链接是用来做什么的？

一共两条，都是为了把一件事从别处交进聊天里。

以 rent_ 开头的启动参数直接打开租赁流程，跳过菜单。带订单 id 的启动参数打开那一笔订单：它的阶段、它的进度，以及每个订单界面都有的那份订阅。

用处一看就明白。客服对话里的一条链接，或者从网站的一次交接，把人直接带到正在讨论的那笔订单上，而不是丢进一个还得自己走一遍的菜单。

第二种用法是回到没结的订单。带 id 的链接直接落到它的界面上，不必回忆它停在历史的第几页。

哪个入口适合哪种活？

三个问题，通常第一个就定了。

是不是一个人用手机手动发一笔转账，并且更希望状态被摆到眼前而不是自己去找？那就是机器人，没必要再开浏览器。它在同类里处于什么位置，另有一页：七家租赁服务横评。

下单的是不是程序——一批代付、一条提现队列、任何没人盯着也在跑的东西？那就是 API：自己的轮询循环、自己的重试策略，以及每笔订单上必填的幂等键。上面讲的推送不会延伸到那边。

这个选择会把钱挪到别处吗？不会。一个账户、一份余额、一个充值地址；入口的差别在进门方式，不在里面装了什么。下单前看一眼地址当前的状态仍然值这一分钟：转 USDT 前，先核对 TRON Energy。

于是还有第三个答案：两个都用。账户只有一个，所以机器人里的订单历史是账户的历史，而不是这段聊天的历史，与订单从哪一边下的无关。

还有一条边界在每个入口都成立。Energy 分配给一个公开的 TRON 地址，这份分配不携带任何签名权限；USDT 转账仍然由你在自己的钱包里签。 这个问题另有专页：转 USDT 前先核对 Energy 的安全边界。

总结

@rentron_energy_bot 不是挂了个菜单的售卖窗口。整个租赁在聊天里走完：数量与时长、发起转账的地址、报价、创建订单。旁边是余额（充值地址可复制，附二维码）、可增删改名的常用地址、分页的订单与充值历史、按阶段的进度、六种界面语言和转交对话的客服入口。

它也不是第二个账户。网页登录和机器人指向同一条联系人记录，其后是同一个账户：一份可用金额、一份预留金额、一个固定充值地址。电脑上充值、手机上下单即可。

别处没有对应物的是界面的订阅关系：服务器发布两个流——打开着那笔订单的状态，以及记入账户的充值——订阅存活 30 天。刷新按钮仍在，只是备用：变的是已经摆在你面前的那条消息。

这句话只属于机器人。公开 API 既没有 webhook 也没有回调，接入方要轮询：1、2、5 秒各一次，之后每 10 秒并加抖动。按 energy_usable 行动而不是等 delivered，两个 final 标志同时为 true 才停，且没有沙箱可供预演。

选哪个入口，看下单的是谁。人在聊天里更省心，程序不是。