在前兩天的內容中，寫了 AI Agent 的概念以及 Semantic Kernel 的 Function Calling 機制。但隨著 AI Agent 概念的火熱，也許該思考一下：是不是所有的 LLM 應用都需要設計成 Agent？

首先還是得聲明一下，Agent 定義為具有決策能力，能夠根據需求變化調用外部系統具有行動能力。

先說明本篇僅僅是從我個人的論點，也許答案可能會讓一些追求技術潮流的開發者失望：凡是都該是個 Agent，我個人覺的並非如此並不是的。

事實上，很多場景下，傳統的「輸入 → LLM → 輸出」模式不僅更簡單、更穩定，也更符合實際需求。今天我們就來聊聊什麼時候該用 Agent，什麼時候該回歸簡單，以及如何在 Semantic Kernel 中實現這兩種不同的設計模式。

不是所有應用都需要「智慧決策」

先看幾個常見的 LLM 應用場景：

場景一：會議摘要

輸入：一段 2 小時的會議錄音逐字稿
處理：請幫我整理出會議的重點摘要，包含決議事項和待辦任務
輸出：結構化的會議摘要文件

場景二：智慧標籤生成

輸入：一篇部落格文章
處理：請為這篇文章生成 5 個相關的標籤
輸出：#技術分享 #AI應用 #程式開發 #Semantic Kernel #最佳實務

場景三：多語言翻譯

輸入：一段中文技術文件
處理：請將以下內容翻譯成英文，保持技術術語的準確性，請盡可能使用自然流暢的短語句表達，避免逐字翻譯以及文謅謅的句子
輸出：對應的英文技術文件

應該不難發現，這些應用都有一個共同特點：任務目標明確、流程固定、不需要動態決策。

在這些場景中：

• 使用者知道自己要什麼
• 處理邏輯是線性的、可預測的
• 不需要調用外部 API 或工具，LLM 本身就能完成任務
• 成功與否可以明確衡量

如果我們硬是要把這些應用包裝成 Agent，添加 Function Calling、多步驟推理等複雜機制，反而會：

1. 增加不必要的複雜度 - 原本一次 API 調用就能完成的事，可能變成多次
2. 降低系統穩定性 - 決策環節變成由 LLM 負責，這同時也表示可能創造出更多出錯的可能性，不可否認 LLM 的不可預測性是一個挑戰，這就會影響整體系統的可靠性
3. 增加延遲與成本 - 更多不必要的 token 消耗和處理時間，在不需要的情況下使用高成本的 Agent 架構，可能導致資源浪費

什麼時候該用 Agent？什麼時候該用簡單生成？

適合 Agent 的場景特徵

1. 任務複雜且多步驟

   • 需要串接多個不同的服務或 API
   • 需要根據中間結果決定下一步行動
   • 例如：「幫我規劃一個三天兩夜的台北旅遊行程，並預訂相關服務」

2. 需要動態決策

   • 根據當下狀況選擇不同的處理方式
   • 需要與外部系統互動取得即時資訊
   • 例如：智能客服需要根據問題類型調用不同的查詢函數

3. 具備學習與適應能力

   • 需要記住使用者偏好或歷史互動
   • 能夠根據回饋調整行為
   • 例如：個人化的投資顧問助理

適合簡單生成的場景特徵

1. 單一、明確的轉換任務

   • 輸入和輸出格式固定
   • 處理邏輯穩定不變
   • 例如：文字摘要、語言翻譯、內容分類

2. 對穩定性要求很高

   • 不能容忍意外的行為或錯誤
   • 需要可預測的響應時間
   • 例如：法律文件分析、醫療報告摘要

3. 大量批次處理

   • 需要處理大量類似的任務
   • 對成本敏感
   • 例如：社群媒體內容審核、新聞自動分類

在 Semantic Kernel 中實現兩種模式

簡單生成模式實作

對於簡單的生成任務，我們可以直接使用 Semantic Kernel 的基本功能，不需要 Function Calling，甚至連對話歷史記錄都可以不用：

public class DocumentSummaryService
{
    private readonly Kernel _kernel;
    
    public DocumentSummaryService()
    {
        _kernel = Kernel.CreateBuilder()
            .AddOpenAIChatCompletion(
                apiKey: Config.OpenAI_ApiKey,
                modelId: "gpt-4")
            .Build();
    }
    
    public async Task<string> SummarizeAsync(string document)
    {
        string prompt = $"""
            請為以下文件生成摘要，包含：
            1. 主要重點（3-5 點）
            2. 關鍵決議事項
            3. 後續行動項目
            
            文件內容：
            {document}
            
            請用繁體中文回覆，格式要清楚易讀。
            """;
            
        var response = await _kernel.InvokePromptAsync(prompt);
        return response.ToString();
    }
}

這種設計的優點：

• 簡單可靠 - 單一 API 調用，減少失敗點
• 可預測 - 相同輸入產生相似輸出
• 效能好 - 最少的 token 使用和處理時間
• 易測試 - 輸入輸出明確，容易撰寫單元測試

Agent 模式實作

而對於需要動態決策的複雜任務，我們則使用完整的 Agent 架構：

public class TravelPlannerAgent
{
    private readonly Kernel _kernel;
    
    public TravelPlannerAgent()
    {
        var builder = Kernel.CreateBuilder()
            .AddOpenAIChatCompletion(
                apiKey: Config.OpenAI_ApiKey,
                modelId: "gpt-4");
        
        _kernel = builder.Build();
        
        // 註冊各種工具
        _kernel.Plugins.AddFromType<WeatherService>();
        _kernel.Plugins.AddFromType<HotelBookingService>();
        _kernel.Plugins.AddFromType<RestaurantService>();
        _kernel.Plugins.AddFromType<TransportationService>();
    }
    
    public async Task<string> PlanTripAsync(string destination, int days, string preferences)
    {
        ChatHistory history = new();
        
        string systemPrompt = $"""
            你是一個專業的旅遊規劃助理，能夠：
            1. 查詢目的地天氣資訊
            2. 搜尋並推薦住宿
            3. 規劃餐廳與美食
            4. 安排交通方式
            
            請根據使用者需求，主動使用適當的工具來規劃行程。
            """;
        
        history.AddDeveloperMessage(systemPrompt);
        history.AddUserMessage($"幫我規劃{destination}的{days}天行程，我的偏好是：{preferences}");
        
        var settings = new OpenAIPromptExecutionSettings
        {
            FunctionChoiceBehavior = FunctionChoiceBehavior.Auto()
        };
        
        var chatService = _kernel.GetRequiredService<IChatCompletionService>();
        var response = await chatService.GetChatMessageContentAsync(history, settings, _kernel);
        
        return response.Content;
    }
}

選擇的判斷標準

在決定使用哪種模式時，可以問自己這些問題：

複雜度評估

• 這個任務需要多少個步驟？
• 是否需要根據中間結果做決策？
• 是否需要與外部系統互動？

穩定性需求

• 對錯誤的容忍度有多高？
• 是否需要保證一致的輸出格式？
• 響應時間的要求是什麼？

成本考量

• 預期的使用頻率是多少？
• 對成本的敏感度如何？
• 是否有預算限制？

維護性考量

• 團隊的技術能力如何？
• 後續維護的複雜度可以接受嗎？
• 是否需要頻繁調整業務邏輯？

漸進式演進策略

在實際專案中，我會建議採用漸進式的演進策略：

第一階段：從簡單開始

先用最簡單的生成模式解決核心問題，驗證商業價值和技術可行性。

第二階段：識別瓶頸

在使用過程中識別哪些環節確實需要更複雜的邏輯，哪些地方用戶會遇到困難。

第三階段：選擇性升級

只針對真正需要的部分引入 Agent 機制，保持其他部分的簡單性。

第四階段：持續優化

根據實際使用情況和使用者實際回饋，持續調整架構設計。

結語

技術選型的智慧不在於使用最新、最複雜的技術，而在於選擇最適合當下問題的解決方案。AI Agent 是個強大的概念，但並不意味著所有 LLM 應用都需要變成 Agent。在 Semantic Kernel 的世界裡，有足夠的靈活性來實現各種不同的架構模式。關鍵是要根據實際需求，在簡單性與複雜性之間找到適當的平衡點。

記住：好的架構設計是解決問題的藝術，而不是展示技術的舞台。有時候，最簡單的方案就是最好的方案。