24H 客服不求人！2026 WordPress 串接 OpenAI Assistants API 實戰：從 Threads 狀態管理到 File Search 的企業級架構

嗨，我是 Eric，浪花科技的資深工程師。如果你跟我一樣，在 2023 年就被那些只會回覆「我聽不懂您的問題」的關鍵字機器人搞到崩潰，那麼歡迎來到 2026 年。現在，如果你的企業官網還在用那種「智障型」客服，真的說不過去了。

這幾年 AI 發展快到讓我頭禿（還好工程師本來就沒剩多少頭髮），OpenAI 的 Assistants API 也已經從當初的 Beta 版進化到現在的穩定版本。對於我們這些 WordPress 開發者來說，最大的福音就是：我們終於不用自己手刻 RAG（檢索增強生成）和對話歷史紀錄（Chat History）了！

今天這篇文章，不講虛的，直接帶大家用 PHP 實戰串接 OpenAI Assistants API，把你的 WordPress 網站變成一個擁有 24 小時企業級智能客服的「活體」網站。

為什麼 2026 年你該選 Assistants API 而不是 Chat Completion？

以前我們用 GPT-3.5 或 GPT-4 的 /v1/chat/completions 接口時，最痛苦的是什麼？是狀態管理（State Management）。你必須把使用者的每一句對話都存進資料庫，然後每次請求都要把整串對話歷史（Context）重新丟給 API。這不僅浪費 Token，還會讓資料庫肥得像剛過完年的我。

OpenAI Assistants API 解決了三大痛點：

• Threads（對話串）： API 自動幫你存對話紀錄，你只需要傳送 Thread ID 和新訊息，省錢又省事。
• File Search（原 Retrieval）： 直接把公司的 PDF、產品型錄丟上去，它自動做向量檢索，不用自己架 Pinecone 或 Milvus。
• Function Calling（函數呼叫）： 讓 AI 能夠「按按鈕」，比如幫客戶查詢 WooCommerce 的訂單狀態（這部分我們後面會提到）。

架構設計：如何在 WordPress 中優雅地處理「等待」

在寫 Code 之前，我要囉嗦一下架構。這也是很多新手工程師會踩的坑。

OpenAI Assistants API 是一個非同步（Asynchronous）的過程。流程是這樣的：創建訊息 → 創建 Run（執行） → 等待 AI 思考 → 獲取結果。這個「等待」過程在 2026 年的模型雖然變快了，但有時候還是需要幾秒鐘。

千萬不要在 PHP 裡面用 while 迴圈傻傻地等！ 這會導致 PHP Timeout（504 Gateway Timeout），也會卡死你的 PHP Worker。比較優雅的做法是前端用 JS 輪詢（Polling）或是使用 Streaming（串流），但為了教學單純化，我們今天示範後端標準的處理邏輯，配合 WordPress REST API。

核心程式碼實戰

首先，我們需要一個簡單的 Wrapper 類別來處理 API 請求。這裡我用 WordPress 內建的 wp_remote_post 和 wp_remote_get，不用另外裝 Guzzle，保持輕量。

class Roamer_OpenAI_Assistant {
    private $api_key;
    private $assistant_id;
    private $base_url = 'https://api.openai.com/v1';

    public function __construct($api_key, $assistant_id) {
        $this->api_key = $api_key;
        $this->assistant_id = $assistant_id;
    }

    // 1. 建立對話串 (Thread)
    public function create_thread() {
        return $this->request('POST', '/threads');
    }

    // 2. 發送訊息到對話串
    public function add_message($thread_id, $content) {
        $body = [
            'role' => 'user',
            'content' => $content
        ];
        return $this->request('POST', "/threads/{$thread_id}/messages", $body);
    }

    // 3. 執行 Assistant (Run)
    public function run_assistant($thread_id) {
        $body = [
            'assistant_id' => $this->assistant_id
        ];
        return $this->request('POST', "/threads/{$thread_id}/runs", $body);
    }

    // 4. 檢查執行狀態
    public function check_run_status($thread_id, $run_id) {
        return $this->request('GET', "/threads/{$thread_id}/runs/{$run_id}");
    }

    // 5. 獲取 AI 回覆
    public function get_messages($thread_id) {
        $response = $this->request('GET', "/threads/{$thread_id}/messages");
        // 過濾出最新的 assistant 回覆
        if (isset($response['data'])) {
            foreach ($response['data'] as $msg) {
                if ($msg['role'] === 'assistant') {
                    return $msg['content'][0]['text']['value'];
                }
            }
        }
        return '';
    }

    // 統一發送請求的方法
    private function request($method, $endpoint, $body = null) {
        $args = [
            'method' => $method,
            'headers' => [
                'Authorization' => 'Bearer ' . $this->api_key,
                'Content-Type'  => 'application/json',
                'OpenAI-Beta'   => 'assistants=v2' // 2026年記得用最新版header
            ],
            'timeout' => 60
        ];

        if ($body) {
            $args['body'] = json_encode($body);
        }

        $url = $this->base_url . $endpoint;
        $response = wp_remote_request($url, $args);

        if (is_wp_error($response)) {
            error_log('OpenAI API Error: ' . $response->get_error_message());
            return false;
        }

        return json_decode(wp_remote_retrieve_body($response), true);
    }
}

整合 WordPress REST API 流程

有了上面的 Class，我們不能直接在頁面載入時呼叫，那樣使用者體驗會很卡。我們需要註冊一支 REST API Endpoint。

邏輯如下：

1. 前端 (JS): 使用者輸入問題 → 發送 POST 請求到 WP REST API。
2. 後端 (PHP):
   • 檢查使用者 Session 是否已有 thread_id，沒有就 Create 一個。
   • 呼叫 add_message 將問題丟給 OpenAI。
   • 呼叫 run_assistant 觸發思考。
   • 關鍵點： 這裡不要等結果，直接回傳 run_id 和 thread_id 給前端。
3. 前端 (JS): 收到 run_id 後，每隔 1-2 秒發送 GET 請求查詢狀態 (Polling)。
4. 後端 (PHP – 查詢端點): 呼叫 check_run_status。如果狀態是 completed，則呼叫 get_messages 回傳最終答案。

處理 File Search (RAG) 的小撇步

在 2026 年，我們通常會在 OpenAI 的後台直接上傳企業的知識庫（Knowledge Base）。在 WordPress 這端，你不需要寫程式去上傳檔案（除非你想做動態同步），你只需要確保你的 Assistant ID 已經掛載了 Vector Store。

這樣一來，當使用者問：「你們的退換貨政策是什麼？」OpenAI 會自動去你的文件中檢索，然後生成準確的回答。這比傳統的關鍵字匹配精準大概一萬倍吧。

常見的坑 (Eric 的血淚經驗)

1. Session 與 Cookie 的愛恨情仇

thread_id 是對話的靈魂。如果使用者重新整理頁面，thread_id 掉了，他就得重新開始。在 WordPress 中，建議將 thread_id 存在 User Meta (如果已登入) 或是長時間的 Cookie (如果是訪客)。

2. 逾時處理 (Timeouts)

雖然我們用前端輪詢解決了 PHP 的等待問題，但 OpenAI 有時候會卡在 in_progress 很久。記得在前端設定一個「放棄機制」，例如輪詢 30 秒還沒結果，就顯示「AI 正在深思熟慮，請稍後…」或是提供人工客服的按鈕。

3. Markdown 渲染

Assistants API 回傳的內容通常包含 Markdown 語法（例如 **粗體** 或表格）。記得在前端引入 marked.js 或類似的庫，把 Markdown 轉成漂亮的 HTML，不然使用者會看到一堆星號，覺得你的網站壞了。

結語：別讓你的網站只是個佈告欄

在這個 AI Native 的時代，網站已經不只是展示資訊的佈告欄，它應該是一個能與客戶互動的「數位業務」。透過 OpenAI Assistants API，我們可以用極低的開發成本，達到以前需要百萬預算才能建置的客服系統效果。

如果你覺得這一切聽起來很美好，但看到程式碼就頭痛，或者你想導入更進階的功能（例如 AI 自動查訂單、自動發送 Coupon），別擔心，這就是我們存在的意義。

延伸閱讀

• 客服不再崩潰！用 OpenAI Function Calling 打造能『查訂單』的 WordPress 智慧 Chatbot 實戰
• 官網還在「靜態展示」？2025 年用 AI + WordPress 打造真正會思考、自動接單的「智慧大腦」
• API 總是噴錯？資深工程師教你用 JSON Schema 打造 WordPress 堅不可摧的資料驗證層