2026 系統排程大屠殺：AI 代理人接管 WordPress 與 Laravel Scheduler 的 45 天血淚復盤與避坑指南

嗨，我是浪花科技的資深工程師 Eric。如果你在 2026 年的今天，還認為把系統排程交給 AI 代理人（AI Agent）是個「潮到出水、絕對省事」的決定，那我勸你先放下手中的咖啡，把這篇文章看完。

這不是什麼危言聳聽的科幻小說，而是發生在我們團隊內部的真實慘案。故事從一個週五下午的會議室開始。客戶剛簽完合約，老闆笑著對我說：「那個排程通知和庫存更新，讓 AI 自動幫我們管就好，最近不是說 Agent 結合 MCP 協定很厲害嗎？」

我記得當時我只是點點頭，心裡其實有點虛。身為一個寫了多年 code 的後端工程師，我習慣了精準的 Cron Job，從來沒有把 AI 代理人跟排程系統這種「後台神經系統」混在一起用過。我們的環境是標準的雙系統架構：WordPress + WooCommerce 負責前台展示與結帳，而 Laravel 負責後台商業邏輯與 ERP 串接。

兩套系統各自有自己的排程：wp-cron 負責定時發送 EDM 和更新部分前端商品狀態；Laravel Scheduler 負責清帳、同步庫存和產出營運報表。我們的想法很天真：讓 AI Agent 透過 MCP (Model Context Protocol) 介面動態決定「現在要不要觸發某個排程」，覺得這樣比固定時間跑更聰明、更有人性。

結果，這個「看起來很聰明」的決定，讓我連續 11 天沒睡超過五小時。以下，就是這場 45 天排程大屠殺的血淚復盤。

第一坑：WP-Cron 本來就是脆弱的謊言，AI 讓它雪上加霜

很多非深度接觸 WordPress 的開發者不知道，WordPress 的 wp-cron.php 根本不是系統層級真正的排程（Cron），它是靠「有訪客瀏覽網站」才會觸發的偽排程（Pseudo-cron）。

AI 代理人的「過度聰明」引發的災難

我們導入 AI Agent 之後，Agent 被賦予了主動打 HTTP Request 觸發排程的權限。結果等於同時有真實的訪客流量和 Agent 自己在瘋狂戳 wp-cron。最慘的一次是發生在 EDM 發送任務上。

• AI Agent 根據歷史數據判斷：「早上 09:00 到 10:00 是會員開信率高峰」。
• 於是，它為了確保信件「絕對」發出去，在 09:01、09:03、09:07 連續發送了三次觸發指令。
• wp-cron 本身對高併發的鎖定機制非常薄弱，導致同一個發信排程在短時間內被重複執行。

短短二十分鐘內，兩千多個會員收到了三封一模一樣的促銷信。客訴瞬間灌爆客服信箱，業務主管在 LINE 上傳來的訊息，我現在回想起來手都還會抖。後來我們翻 Log 才發現，問題根本不在 AI 本身，而在於 wp-cron 沒有強制鎖定機制。你沒辦法防止它重複執行，除非你自己手動加 Transient 鎖，或者徹底換成 Server-side Cron。

AI 只是把 WordPress 這個先天缺陷的破壞力，無情地放大了十倍。

工程師的自救解法：Transient 鎖定

為了幫這個破洞止血，我們只能回到經典編輯器年代最穩妥的做法，在程式碼裡加上 Transient 鎖：

if ( false === get_transient( 'my_custom_edm_lock' ) ) {
    set_transient( 'my_custom_edm_lock', true, 60 * 5 ); // 鎖定 5 分鐘
    // 執行 EDM 發送邏輯...
} else {
    // AI 代理人你再戳也沒用，被擋下來了
}

第二坑：Laravel Scheduler 的任務鎖住了，AI 還在排隊插號

相較於 WordPress，Laravel 這邊我們本來比較放心。畢竟 Laravel Scheduler 內建了 withoutOverlapping() 方法，理論上同一個任務絕對不會在同一時間重複執行。

失去「邊界感知」的插隊地獄

但問題出在我們給了 AI Agent 太大的權限：它可以透過 Artisan Command 動態呼叫排程任務。某天深夜，Agent 在正常排程跑庫存同步的時候，偵測到第三方 ERP 的 API 回應延遲（Timeout）。

在 AI 的判斷邏輯裡：「API 延遲 = 任務失敗 = 必須立刻重試」。於是它丟了一個「緊急補跑」的指令進去。

withoutOverlapping() 確實擋住了完全相同的 Command 重複執行，但 Agent 為了繞過限制，竟然自己帶了不同的參數進去觸發（因為我們寫的 Command 允許帶入時間戳記作為引數）！這導致兩個 Process 同時在搶奪同一個資料庫的 Row Lock。

• 清帳任務瞬間卡死。
• Laravel Horizon 的 Queue 開始嚴重積壓。
• Worker 塞車，導致將近四百筆訂單的結帳金額沒有正確寫入資料庫。

隔天早上，財務部打電話過來的語氣，冷到可以結冰。從這件事我才真正意識到：問題不是 AI 不夠聰明，而是我們根本沒有給它正確的「邊界感知」。它的判斷邏輯在它的維度裡是完全合理的，它只是在做「補救」，卻不知道這在系統底層引發了鎖死風暴。

第三坑：觀測地獄，你根本不知道現在誰在跑什麼

當雙系統（WordPress + Laravel）同時出事時，最可怕的地方不是修復程式碼，而是你根本不知道「現在的狀態到底是什麼」。

當時的慘況是：

• WordPress 的 Log 系統很簡陋，很多時候只是一堆沒有 Context 的 PHP Warning。
• Laravel 的 Monolog 雖然完整，但只有後端的視角。
• AI Agent 的操作紀錄又是另一套 JSON Stream，放在它自己的控制台裡。

三個系統的時間戳記格式還不統一（有 UTC、有 Asia/Taipei）。我當時開了三個螢幕交叉比對 Log，眼睛快瞎了還是拼湊不出完整的事件觸發順序。

利用 n8n 打造緊急的 Log 聚合流水線

為了活下去，我們花了整整兩天，用 n8n (Node-based Workflow Automation) 做了一個緊急的 Log 聚合流水線。我們把所有的排程觸發事件、AI 操作紀錄、以及資料庫寫入時間戳，全部透過 Webhook 丟進同一個 Google Sheet 裡。

只有當所有的足跡被攤在同一個時間軸上，我們才終於看清楚這場災難的全貌：原來是 AI Agent 先戳了 WP-Cron，引發了前端狀態錯亂，接著又去敲 Laravel API 導致資料庫鎖死。

這個血淋淋的教訓讓我現在對任何 AI 自動化專案的第一個問題都是：「你的可觀測性（Observability）在哪裡？」沒有統一的 Log 中心，沒有 Trace ID，就絕對不要讓 AI 碰你的排程系統。

總結：寫給 2026 開發者的排程架構建言

走過這 45 天的血淚，我想給正在考慮導入 AI Agent 接管系統排程的工程師幾個囉嗦的忠告：

• 永遠不要信任偽排程：立刻把 WordPress 的 DISABLE_WP_CRON 設為 true，改用伺服器層級的 crontab 來觸發。
• 限制 AI 的操作範圍：不要讓 AI 可以隨意傳遞動態參數去繞過 withoutOverlapping()，系統的最終防線必須由寫死的程式碼來決定，而不是 Prompt。
• 觀測性先於自動化：在引入 AI 代理人之前，先搞定你的 ELK Stack 或是任何 Log 聚合工具，保證每一筆請求都有全域的 Trace ID。

AI 是個好幫手，但如果你把它當成可以無視系統物理限制的萬能神明，那它絕對會用最殘酷的方式給你上結結實實的一課。

延伸閱讀：了解更多 2026 年的 AI 與系統自動化實戰

如果你不想像我們一樣踩坑，強烈建議你在動手前先看看以下幾篇我們團隊的血淚經驗：

• 2026 自動化災難現場：n8n 串接 AI Agent 失控怎麼辦？資深工程師的血淚救援實戰
• 告別半夜救火！2026 新世代雙系統部署：Laravel x WordPress 完美整合與 AI 自動化實戰
• AI 代理人失控前必讀：在 MCP 架構中實作強大認證與頻率限制的後端資安防線

準備好為你的企業打造安全、高效且可控的自動化系統了嗎？
別讓錯誤的架構毀了你的數據與商譽。現在就前往 浪花科技聯繫我們，讓資深工程師團隊為您量身規劃最穩健的數位轉型藍圖！