~/blog/agentic-laravel-intent-driven-controllers-2026.md
Laravel 與後端開發 · 2026 / 03 / 10 · 3 views

Agentic Laravel 意圖驅動控制器:為什麼傳統 MVC 接不住 AI 代理人

Eric — 浪花科技創辦人 / AI 架構師
Eric
浪花科技創辦人 · AI 架構師
Agentic Laravel 意圖驅動控制器:為什麼傳統 MVC 接不住 AI 代理人
目錄 table-of-contents.md

時間來到 2026 年,如果你還在把 AI 代理人(AI Agent)當作單純的 API 呼叫,把 Prompt 塞滿在傳統的 Controller 裡面,還要手動去解析 LLM 回傳的 JSON 格式... 說實話,每次 Code Review 看到這種「義大利麵程式碼」,我血壓都快上來了。

這根本是在製造未來的技術債炸彈!隨著組合式 AI (Composable AI) 與多代理人協作 (Multi-Agent Workflows) 成為企業標準,傳統的 Model-View-Controller (MVC) 已經無法應付 AI 不可預測的推理邏輯。這就是為什麼今天我們要來聊聊後端架構的全新典範:突破傳統 MVC 框架:Agentic Laravel 中的意圖驅動控制器 (Intent-Driven Controllers)

為什麼 2026 年了,傳統 MVC 框架開始力不從心?

傳統 MVC 框架的設計初衷,是為了解決「確定性(Deterministic)」的問題。瀏覽器發送一個特定的 HTTP 請求到 /users/create,Router 將其分發給 UserController@store,接著進行資料驗證、寫入資料庫,最後回傳 View 或 JSON。

但在 2026 年,系統面對的往往不是單純的使用者點擊,而是 AI 代理人的自主決策與複雜意圖。當 AI 代理人傳來一個請求:「幫我找出上個月消費超過一萬元的 VIP 客戶,並發送專屬的促銷信件,如果他們沒有 Email,就改發 LINE 訊息。」

  • 傳統做法的痛點:你要寫一個超級肥大的 Controller,裡面塞滿了 if/else 判斷式,並且混雜了資料庫查詢、第三方 API 串接、以及跟 LLM 溝通的邏輯。一旦業務邏輯改變,整包 Controller 就會直接報銷。
  • 路由災難:AI 的請求不是單一路徑,而是動態生成的。傳統 RESTful 路由完全無法捕捉這種「意圖驅動」的動態行為。
  • Context 切換成本過高:LLM 需要不斷與資料庫進行狀態同步(Context Sync),傳統 Controller 的生命週期太短,無法支撐長時間的 Agent 對話。

核心解析:意圖驅動控制器 (Intent-Driven Controllers) 到底是什麼?

突破傳統 MVC 框架:Agentic Laravel 中的意圖驅動控制器 (Intent-Driven Controllers) 的核心概念,就是將「動作(Action)」轉變為「意圖(Intent)」。

在 Agentic Laravel 的架構下,Controller 不再負責處理具體的業務邏輯,而是轉變為一個「意圖解析與分發中心(Intent Dispatcher)」。它的工作流程變成這樣:

  1. 接收來自前端或 AI 代理人的自然語言/複雜指令。
  2. 透過輕量級的 LLM 或是語意路由(Semantic Router)將指令解析為具體的 IntentObject
  3. 根據 Intent 的類型,動態調用對應的 Tools 或 Sub-agents(子代理人)來執行任務。
  4. 收集執行結果,並將 Context 回傳給 AI 進行下一步決策。

傳統 Controller vs. 意圖驅動 Controller 的程式碼差異

讓我們來看看實際的程式碼對比。如果你使用傳統經典編輯器或是舊版的 Laravel,你可能會這樣寫:


// ❌ 傳統的肥大 Controller (2023年代的寫法)
public function handleAgentRequest(Request $request) {
    $prompt = "分析以下使用者的需求:" . $request->input('message');
    $response = OpenAI::chat()->create(['messages' => [['role' => 'user', 'content' => $prompt]]]);
    
    $action = json_decode($response->choices[0]->message->content)->action;
    
    if ($action === 'send_email') {
        // 處理寄信...
    } elseif ($action === 'query_db') {
        // 處理查詢...
    }
    return response()->json(['status' => 'success']);
}

你看,這種寫法不僅難以測試,而且將 Prompt 和業務邏輯死死綁在一起。現在我們來看看 Agentic Laravel 的意圖驅動寫法:


// ✅ 2026 年 Agentic Laravel 的意圖驅動 Controller
namespace App\Http\Controllers\Agentic;

use App\Intents\MarketingIntent;
use App\Agents\Dispatcher;

class MarketingAgentController extends Controller
{
    public function handle(IntentRequest $request, Dispatcher $dispatcher)
    {
        // 1. 請求已經在 Middleware 層被解析為 Intent 物件
        $intent = $request->getIntent();

        // 2. 意圖驅動分發:Controller 不管怎麼做,只管交給誰做
        $result = $dispatcher->execute($intent);

        // 3. 將執行結果與 Context 封裝回傳
        return response()->agentic($result);
    }
}

如何在 Laravel 中實作你的第一個 Intent-Driven Controller?

要導入這樣的架構,身為工程師的我們需要建立三個核心組件:

1. 定義 Intent 類別 (The Intent Definition)

每一個 Intent 都應該是一個獨立的 Data Transfer Object (DTO),它包含了 AI 代理人想要執行的意圖特徵。比如 FindVipCustomersIntent,裡面會明確定義所需的參數(如日期區間、消費金額門檻)。你可以利用 PHP 8 之後的 Attributes 來綁定對應的 MCP (Model Context Protocol) Tools。

2. 意圖解析器 (The Intent Parser)

在 Request 進入 Controller 之前,我們可以寫一個 Middleware 或 FormRequest,利用小型的邊緣模型 (SLM) 或預設的向量檢索 (RAG) 快速將使用者的自然語言轉換為我們定義好的 Intent。這讓 Controller 永遠只接收到結構化的「意圖」,而不是模糊的字串。

3. 工具分發機制 (Tool Dispatching)

當 Intent-Driven Controller 拿到 Intent 後,它會透過 Laravel 的 Service Container 依賴注入功能,自動解析出對應的 Action 類別或 Subagent。這樣一來,你的程式碼符合了單一職責原則 (SRP),未來要新增 AI 技能,只要新增一個 Tool 類別即可,Controller 一行程式碼都不用改!這才叫真正的可擴展架構!

資深工程師的血淚避坑指南

Eric 叔叔在這裡囉嗦幾句,在實作意圖驅動控制器時,千萬要注意這幾點:

  • 不要把 Prompt 寫死在 Controller 裡:請使用統一的提示詞管理庫。這點真的很重要,不然未來只要換一個模型,你的系統就會大當機。
  • 做好異常隔離與自我修復:AI 會產生幻覺(Hallucination),所以 Intent 解析出來的參數可能是錯的。務必在 Intent 進入執行階段前,加上嚴格的 Schema Validation,如果驗證失敗,直接透過 Exception 觸發 Agent 的自我修正機制。
  • 注意 API 頻率限制 (Rate Limit):AI Agent 執行意圖時往往會觸發大量的背景操作,請務必結合 Laravel 的 Queue 系統與指數退讓演算法,避免把自家的 ERP 或第三方 API 打掛。

在 2026 年,框架的意義不再是單純的把網址對應到資料庫,而是如何優雅地協調 AI 與現有商業邏輯。突破傳統 MVC 框架:Agentic Laravel 中的意圖驅動控制器 (Intent-Driven Controllers),不僅是技術的升級,更是後端工程師思維模式的根本轉變。

延伸閱讀:

如果你在升級企業架構、整合 Agentic Laravel 或導入意圖驅動開發時遇到技術瓶頸,別讓不合時宜的架構拖垮你的 AI 轉型之路!浪花科技擁有豐富的 Laravel 架構重構與 AI 代理人整合經驗。

👉 立即前往 https://roamer-tech.com/contact/ 填寫表單聯繫我們,讓我們為您的企業打造 2026 年最強大的數位中樞引擎!

// FAQ

常見問題

什麼是意圖驅動控制器(Intent-Driven Controller)?
意圖驅動控制器把傳統的「動作」轉變為「意圖」,讓 Controller 不再處理具體業務邏輯,而是擔任意圖解析與分發中心。它接收前端或 AI 代理人的指令,將其解析為結構化的 Intent 物件,再依類型動態調用對應的工具或子代理人來執行任務。
為什麼傳統 MVC 框架難以應付 AI 代理人的請求?
傳統 MVC 是為確定性的 HTTP 請求設計的,路由固定地把網址對應到 Controller 動作。但 AI 代理人會發出動態、複雜且不可預測的意圖,迫使開發者寫出塞滿條件判斷的肥大 Controller,且 RESTful 路由難以捕捉這種意圖驅動的動態行為。
實作意圖驅動架構需要哪些核心組件?
通常需要三個組件:定義意圖的 Intent 類別(一個獨立的 DTO,明確描述參數)、把自然語言轉成結構化意圖的意圖解析器(可放在 Middleware 或 FormRequest),以及依意圖解析出對應 Action 或子代理人的工具分發機制。如此每新增一項 AI 技能只需新增一個工具類別,符合單一職責原則。
導入這種 AI 控制器架構時要避免哪些常見錯誤?
不要把提示詞寫死在 Controller 裡,應使用統一的提示詞管理庫,方便未來更換模型。要在意圖進入執行前加上嚴格的 Schema 驗證,因為 AI 可能產生幻覺導致參數錯誤,驗證失敗時透過例外觸發自我修正。同時要結合 Queue 與指數退讓演算法控制 API 頻率,避免打垮自家 ERP 或第三方服務。
~/roamer-tech/newsletter // FREE
// newsletter

訂閱免費電子報

把 AI 自動化、企業系統設計與 WordPress / Laravel 開發的真實案例和可直接照做的技巧,整理成電子報寄給你。只寄精選內容、不灌垃圾信,一鍵就能退訂。

$
// final.exec()

準備好讓你的網站開始為你工作了嗎?