把 X（推特）接入 AI 智能体

1. 智能体发布什么

一个普通的 X 账号就够了：不需要企业账号。素材以字节形式从你的电脑发出，因此没有任何域名需要向 X 验证。

这个连接器覆盖文字、图片和视频的发布，以及内容统计数据的读取。有一条需要记住的组合规则：一条内容最多承载四张图片，或一段视频，或一张 GIF。X 拒绝混合，而这个拒绝会在发送的那一刻出现。

与 TikTok 一样，X 也不通过编程接口安排任何预约：延后的发布由 nullbot 的编辑日历承担，或者经由 Buffer 这类聚合工具。

2. 按次调用的费用，以及那种不说明自身缘由的拒绝

这正是这个连接器区别于其他所有连接器之处。自 2026 年 2 月起，X 对每一次调用收费。项目消耗的是预先购买的额度，而且资费并不统一：发布比读取更贵。

难的不是原理，而是症状。额度不足的项目不会返回「额度用尽」，而是返回访问被禁止，与授权不足或账号被停用完全相同的提示。于是人们去排查权限，而问题其实出在账目上。

三个实际的后果：

• X 项目的额度余额需要像盯一份订阅那样盯着，这与 nullbot 无关。
• 在 X 上遇到无从解释的访问拒绝时，第一件要检查的事是余额，而不是授权。
• 在 X 上采取高频发布的策略，会带来在别处没有的直接成本。这值得权衡，而不是被动承受。

3.「Read and write」——无声失败的那项授权

授予应用的权限必须包含「Read and write」。被声明为只读的应用同样能顺利获得授权：同意页面通过，连接建立，一切看上去都正常。然后每一次发布都会被拒绝。

这是这个连接器的第二个陷阱，而且很费时间，因为在接入的那一刻没有任何东西提示这个错误。如果你在 X 的开发者门户里声明自己的应用——当 nullbot 尚未在你这套实例上携带它自己的应用时就是这种情况——你需要创建一个 Web App 类型的应用，机密客户端，把 nullbot 的回调地址一字不差地声明进去，然后在粘贴标识与密钥之前启用「Read and write」。

4. 两小时就消亡的令牌

X 的访问令牌只能存活两小时。这非常短，而且没有 offline.access 权限，连接当天就会中断：那就得手动反复重建，没有尽头。

这项权限属于默认请求的权限之一，正是为了让接入在无人干预的情况下长久保持。它属于决定一个连接器是能用于正式运行还是只能用于演示的那类细节——也正因如此，一条「昨天还好好的」而今天失灵的 X 连接，首先应当从续期这一侧去查。

5. 时间久了会有什么变化

X 奖励每日在场，也不太原谅缺席。它同时是入场成本最低的网络——一条文字消息就够了——也是心理负担最重的网络，因为你每天都得出现。

• 第 1 周。账号恢复了规律的存在，内容是写出来的，而不是从另一个网络照搬过来的。
• 第 3 个月。统计数据让人能够区分被阅读的与被忽略的，形式也向有效的方向收紧。按次调用的费用同样变得可测量，因而可以权衡。
• 第 2 年。账号有了可辨识的声音，也有了可以作为活动佐证的历史——这是任何一次性的活动都给不了的。

不承诺任何粉丝数量。所能保证的是，每天都有可发布的内容，包括那些没有人有空去想这件事的星期。

6. 常见问题

延伸阅读

接着阅读：接入 Buffer、用于社交网络的 AI 智能体，或 全部可用的连接器。