我們做了一個 MCP 套件，讓網站的維護人員在 Claude 或 ChatGPT 的對話視窗裡直接改網站內容，不用再登入後台。

實際的運作流程是：在 Claude 的對話中貼上 MCP 設定的網址，並要求 Claude 執行，瀏覽器便會跳出登入頁，使用者用平常那組後台帳號登入、按下同意授權，之後就能在 Claude 對話裡進行後台的內容編輯。要改什麼就直接透過 AI 處理，像是「幫我把上週那篇活動文章的日期改成 9/12，改完先存草稿」。以上內容聽起來就是很常見的 MCP（Model Context Protocol） 可以做到的事情。在以新版本 Laravel 開發的專案要做到這樣的支援功能，可以依靠 Laravel 官方的 laravel/mcp，協定、傳輸、OAuth 授權都包好了，再針對內容操作的那幾支工具，很容易就能裝上去使用。而我們真正想解決的是：那些已經上線好幾年、還在維運的舊專案。

為什麼是舊專案

laravel/mcp 要 PHP 8.2 以上、Laravel 11 到 13。我們把手上還在維運的專案掃過一遍，有很多還是 Laravel 8 到 10、PHP 7.3 到 8.2 這個區間，都無法直接使用官方的 MCP 套件。

這些專案不是不能升級，只是每個客戶都有各自的限制。有的跑在客戶自己管的主機上，一些核心的設定不太能輕易的大改；有的系統跑了五六年一直很穩定，客戶暫時也沒有理由為了一個新功能承擔改版風險；也有的升級工程要拆到框架底層，時程和預算得另外談，不是很簡單就可以安排的事情。

但即便如此，我們也認為應該可以幫這些客戶想一些解決方法，在現在 AI 這麼興盛的時代，怎麼樣在最小成本下，讓客戶有更好的網站服務體驗。希望把問題從「要搞 AI 支援要先系統升級」變成「可以嘗試用外掛來無痛支援」，讓這些現在被正在維護使用的網站，在不做大變動的前提下，直接可以讓 AI agent 安全地協作內容。

我們沒有自己重寫一個舊版

第一個想法是參考官方套件的做法，自己寫一個能跑在舊版 Laravel 和 PHP 7.3 上的外掛套件版本。評估完之後放棄了這個設計方向。

主要原因是：一是要自己寫的話，得在一個 2021 年底就停止官方支援的 PHP 版本上，把協定層和整套 OAuth 授權從頭刻出來。授權這塊我們不想自己寫，客戶的後台帳號是接在上面的。二是 MCP 規範本身還在改，2026 年 7 月又發了一版，自己維護一套就等於以後每次規範動，我們都要跟著改一次。算下來花在維護上的時間，會比省下來的多很多。

Sidecar：直接在原來的專案服務旁邊加掛一組微服務

跑不動新套件的是舊專案的 PHP 版本，不是它的資料庫，而內容都在資料庫裡。

所以我們在旁邊另外架一個很小的新版 Laravel 12 應用，套件裝在它上面，直接連舊專案的資料庫。舊專案的程式碼一行都不用改，也不用升級，繼續跑它原本的版本；sidecar 跑自己的新版 PHP，兩個版本在同一台主機上並存。

這樣可行是因為套件本來就把「哪些東西可以被編輯」抽成一份設定檔：哪個資料表、哪些欄位能改、允許哪些操作，都寫在裡面。sidecar 的差別只是在那些條目上多指定一個資料庫連線，套件還是同一份，不會分岔成兩套程式碼要維護。

授權走原本的後台帳號

這點我們比較在意。如果 sidecar 自己另外弄一組帳號，那等於在客戶網站旁邊多開一個沒人管的入口。這些舊專案的後台不是 Laravel 原生的帳號系統，是我們自己那套後台套件在管。我們讓 sidecar 的授權頁直接接上它，所以維護人員按下同意之前看到的，就是他平常在用的那個後台登入畫面，舊專案的程式和資料表都不用動。

授權出去之後，權限是綁在「哪一個帳號」加「哪一個 AI 工具」這一個對應資料上面。如果後台把某個帳號停用或刪掉，那組授權在下一個請求就會被擋掉。

部署上的設計邏輯

sidecar 是刻意做成微服務：沒有佇列、沒有快取伺服器、沒有排程，前端也沒有東西要編譯，唯一一個網頁就是授權頁。這樣它才不會變成一個要另外照顧的系統。

接法有兩種，用子網域，或者直接掛在原本網站的一個路徑下，後者連 DNS 和憑證都不用動。整個安裝流程我們包成一份自動化腳本，之後每個專案只要幾分鐘就可以跑起來。

另外它跟原本的網站是分開的。sidecar 出問題不會影響網站本身，不想用了就把它關掉，網站照常運作。這是我們在設計時就先決定好的邊界，讓客戶不用為了試一個新東西承擔網站異常的風險。

MCP sidecar 服務是獨立在專案以外，且有完整的tool可以給 Claude 調用

我們想做到的事

現在維護一個網站的內容，大概是這樣：登入後台、切到文章列表、找到那一篇、開編輯頁、改完存檔，然後去另一個模組確認一下有沒有漏。內容散在文章、頁面、輪播、FAQ 這些不同的地方，要彙整一份東西出來，就得一頁一頁開、一筆一筆抄。

我們想做到的是用講話取代這些翻找。「這個月有哪幾篇還沒發布」、「把去年活動頁裡的舊報名連結列出來」、「幫我把這三則公告整理成一段摘要，我要貼給客戶」，這種查詢和彙整的工作，本來要開十幾個後台頁面來回對，交給 AI 一次就問完了。改動也一樣，把一篇文章的日期改掉、把一批文章的分類調整，講一句就好，不用記得那個欄位在哪一個分頁裡。重點還是這些 CMS MCP 可以做到的內容，在舊專案也可以體驗。

同時我們也希望它是可以放心被安裝的。每一次寫入都會留下紀錄，包括是誰、用哪個 AI 工具改的，改動之前也會先存一份原本的版本，改壞了可以還原。哪些欄位能動、哪些操作要另外確認，都在安裝時就設定清楚，AI 看不到設定以外的東西，也無法針對帳號或是一些高級權限進行編輯。對一個上線五年以上的網站來說，這是它能得到的、成本最低卻又感受最巨大的一次體驗更新。

透過 Claude 直接查詢現有文章

透過 Claude web fetch 功能，給予資料來源直接建立相關文章

題外話：開源與客製化的套件邊界設計

這個套件一開始就有一個決定要先做：哪些東西放在套件裡，哪些留在每個專案裡。

我們的分法是，通用的機制放套件，包括授權、寫入前留一份版本、操作紀錄，以及那些內容操作的工具本體。每個客戶不一樣的東西留在專案自己的設定檔：哪些資料表可以被編輯、哪些欄位能動、哪些操作要另外確認。所以接一個新專案的時候，我們改的是設定，不是套件。這條線如果沒守住，套件為了某個客戶的特殊需求長出一個分支，維護成本又會回到每個專案各自為政的狀態，這不是我們理想的維護情境。

同時也留了讓專案自己增加編輯邊界的空間。客戶想要一支自己的工具，例如查訂單，可以在他們的專案裡註冊進來，套件不用動。內容被改動的時候套件會發出事件，要接通知還是清快取，都在專案這邊決定。授權頁的樣式也可以換成客戶自己的，這樣維護人員看到的是他們家的系統，不是我們的套件。

同時目前有打算把核心部分進行開源，移除我們自己公司的慣例，單純把「支援舊版本 Laravel 的MCP解決方案」這件事情做一個分享。

後續進度

還需要花時間更進一步謹慎思考的其實是資安層面。我們做完 MVP 版本後之後自己又做了一輪 review，找到幾個可能會有安全疑慮的設計點，即便開發後所有測試是全綠。當然測試本身的設計並沒有一個是站在攻擊者的角度進行。這部分和更細節的技術做法和後續進度，之後會持續和大家分享。

我們是得寬科技。如果您手上也有幾個暫時不打算大改的舊網站，想讓它可以用 AI 來維護內容，歡迎跟我們聯絡，我們可以先看看現在的狀況適合哪一種做法。