接上你的工具
把 X（推特）介接 AI 代理人
X 是這一族連接器中唯一一個每個動作都有價格的。自 2026 年 2 月起，平台對其呼叫收費：專案消耗的是預先購買的點數，而發布比讀取更貴。這是介接之前就該知道的前提，因為點數不足的專案會以一則從不點明真正原因的「存取遭禁止」訊息拒絕發布。本頁說明代理人能發布什麼，以及三個讓人浪費時間的陷阱。
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. 常見問題
使用這個連接器需要付費給 X 嗎？
是的，間接需要：自 2026 年 2 月起，X 對其程式介面的呼叫收費。專案消耗的是預先向 X 購買的點數，這與你的 nullbot 訂閱無關。
我的貼文被拒絕，顯示存取遭禁止。該檢查什麼？
依序：先看 X 專案的點數餘額，再看授權中是否包含「Read and write」。這兩個原因會給出同一則訊息，而前者更常見。
可以把多張圖片和一支影片一起發布嗎？
不行。X 最多接受四張圖片，或一支影片，或一張 GIF——絕不允許混合。這是平台的規則，會在送出時被拒絕。
我的 X 連線為何這麼快就斷了？
X 的存取權杖兩小時後即失效。自動續期仰賴 offline.access 這項權限；少了它，連線當天就會中斷，必須手動重新建立。
延伸閱讀
接著閱讀：介接 Buffer、用於社群平台的 AI 代理人，或 所有可用的連接器。