今天在滑 Laravel News 的時候，看到一篇滿有意思的文章，介紹一個叫做 Laravel Tackle 的套件。簡單講，它是把一個 AI coding agent 直接裝進你的 Laravel 專案裡，變成兩個 Artisan 指令：ai:code（互動式的 REPL，有 plan mode、slash 指令、可以丟圖片進去問）跟 ai:run（不用開終端機互動，直接丟一個任務進去，做完給你 exit code，還可以 --output=json 串進 pipeline）。作者是 Jordan Dalton，套件是建構在 laravel/ai 之上，預設用 Claude，但也可以透過 AI_CODE_PROVIDER 換成 OpenAI、Gemini、Groq，甚至接 Ollama 跑本地模型。

為什麼我這個寫 Laravel 的後端工程師會在意這則新聞

我每天的工作就是在 Laravel 專案裡打滾，所以看到這則新聞第一個反應不是「哇 AI 又出新玩具了」，而是「這個 agent 到底能拿到什麼權限」。因為市面上一堆 AI coding agent 的做法都是外掛一個 CLI 工具，透過檔案系統或終端機去操作你的專案，你能不能信任它，很大程度取決於一份寫在 prompt 裡的「規則」——但 prompt 是可以被誘導繞過的。

Laravel Tackle 讓我比較有興趣的地方是，它把限制寫成 PHP code，而不是寫成 prompt 裡的一句話。文章裡特別提到：路徑限制、Artisan 指令白名單、每個 session 的花費上限，這些都是套件本身的程式邏輯在把關，不是靠模型自己乖乖聽話。這個設計思路其實跟我們寫後端 API 在做權限控管的邏輯一模一樣——你不會把「這個使用者不能刪除別人的資料」這種規則寫在文件裡叫大家自己遵守，你會寫在 middleware 或 policy 裡面用程式碼強制擋下來。AI agent 要在正式環境裡被信任，走的也是同一條路。

另外一個讓我覺得「這才是重點」的功能，是它提到的 self-healer：會去監看失敗的 queue job 跟排程任務，在一個獨立的 worktree 裡面修好，然後開一個 PR 讓人審。這個流程設計得很保守——它不會直接把修好的東西推上 production，而是走 PR 流程讓人看過再合併。這跟我自己維護排程任務時的直覺很像：凌晨三點壞掉的 queue job，与其等我早上起來手動查 log，不如讓機器先把可能的修法準備好，但最後合不合併，人還是要看一眼。

結語

短期內我應該不會馬上把這種 AI agent 接進正式的 production 專案，但這種「把 agent 的能力邊界寫進程式碼、而不是寫進 prompt」的做法，我覺得是接下來這類工具能不能被工程團隊真的信任的關鍵，值得繼續關注。

消息來源

• Laravel Tackle: Run an AI Coding Agent in Your Laravel App — Laravel News