項目案例 · Agentic AI

建立 AI Agent，
真正困難的往往不只是模型

要建立一個真正可以執行工作的 AI Agent，選擇模型其實只是其中一步。

更多工作通常發生在模型之外：定義任務、連接工具與資料、設計工作流程、管理記憶與權限，以及確保每一步都能夠被測試和追蹤。

以下是我在實際設計 AI Agent 時，會採用的一套工程框架。

看九個步驟

模型只是系統的一部分

5%

5%｜模型

模型主要影響 Agent 的理解、推理及生成能力。需要考慮：

  • 推理能力
  • Context Window
  • Tool Calling
  • Multimodal 能力
  • 速度
  • 成本
95%

95%｜系統工程

真正影響 Agent 能否穩定工作的，往往是模型周邊的設計：

  • Agent 負責什麼
  • 可以取得哪些資料
  • 可以使用哪些工具
  • 如何拆解及執行任務
  • 哪些操作需要人工批准
  • 失敗時如何處理
  • 如何記錄及評估結果

「5% / 95%」並不是精確比例，而是我用來理解 Agent 系統的一個簡化框架。

建立 Agent 的九個步驟

  1. 01

    定義目的與範圍

    首先需要決定 Agent：

    • 要解決什麼問題
    • 服務哪些使用者
    • 什麼結果算成功
    • 哪些事情不應處理

    如果 Scope 不夠清楚，後面的 Prompt、Workflow 和 Evaluation 都會較難準確設計。

  2. 02

    設計 System Prompt

    定義 Agent 的角色、規則及決策邊界：

    • 如何理解任務
    • 哪些規則必須遵守
    • 什麼情況需要確認
    • 什麼情況必須停止
    • 什麼情況需要交給人工

    System Prompt 可以理解為 Agent 的 operating rules。

  3. 03

    選擇模型

    根據實際任務選擇模型，而不只是單純選擇最大或最新的模型。

    主要考慮：

    • 推理能力
    • Context Window
    • Tool Calling
    • Multimodal
    • Latency
    • Cost

    目標是在品質、速度及成本之間取得合適的平衡。

  4. 04

    接入工具

    如果 Agent 只能生成文字，它的能力仍然會比較接近傳統 Chatbot。

    真正讓 Agent 能夠執行工作的，是不同工具的接入：

    CRM API · Gmail MCP · Calendar · Google Sheets · Database · Internal API

    Agent 可以根據任務需要，選擇並調用合適的工具完成操作。

  5. 05

    設計記憶

    決定 Agent 應該記住什麼，以及需要保留多久。

    例如：

    • 當前對話
    • 任務進度
    • 使用者偏好
    • 過往處理紀錄
    • 長期業務狀態

    同時亦需要考慮資料私隱及 retention。

  6. 06

    接入企業知識

    企業 Agent 不應只依賴模型本身的公開知識。

    我會建立較受控的知識來源，例如：

    SOP · Policy · FAQ · Product Documentation · Internal Knowledge Base

    讓 Agent 可以先搜尋較可信的資料，再產生答案或採取行動。

  7. 07

    設計工作流程

    這通常是 Agent 很核心的一部分工程工作。

    需要定義：

    • 任務如何開始
    • 每一步如何排序
    • 工具失敗如何重試
    • 什麼情況需要人工批准
    • 多個 Agent 如何交接
    • 任務失敗如何 recovery

    Agent 的價值不只是「理解」，而是能夠相對可靠地完成一連串操作。

  8. 08

    設計使用介面

    最後需要考慮 Agent 應該如何進入使用者原本的工作流程。

    例如：

    Chat UI · Web App · WhatsApp · Teams · Slack · Enterprise Portal

    一個好用的 Agent 未必一定需要一個新的 App。

    很多時候，更重要的是讓它出現在使用者本身已經工作的地方。

  9. 09

    測試與評估

    Agent 是否「好用」，不應只透過一次 Demo 判斷。

    我會建立固定測試集，持續量度：

    • Task Success Rate
    • Accuracy
    • Tool Success Rate
    • Latency
    • Token Usage
    • API Cost
    • Safety / Permission

    每次修改 Prompt、模型、工具或 Workflow，都重新執行同一組測試。

    這樣會比較容易判斷系統是真的改善了，還是只是產生了不同的結果。

實例

一個 Agent 如何完成任務

假設使用者輸入：

請幫我跟進上星期仍未回覆的客戶。

Agent 背後並不只是生成一句答案。

它可能會完成一整條 workflow。

Task #A1042

  1. 10:32:14
    User Request

    收到跟進客戶的要求。

  2. 10:32:16
    Planning

    Agent 將任務拆成：查詢客戶 → 準備 Follow-up → 發送 Email → 更新 CRM

  3. 10:32:22
    CRM API

    找到 8 位仍未回覆的客戶。

  4. 10:33:08
    Gmail

    生成並發送 8 封個人化 Follow-up Email。

  5. 10:34:02
    CRM Update

    更新客戶 Follow-up Status。

  6. 10:34:02
    Response

    向使用者確認任務已完成。

Task Completed · 1m 48s

但完成任務還不夠

如果 Agent 做錯了，我需要知道：哪一步錯了？

因此 Production Agent 必須具備 Observability。

我需要能夠重新查看：

Conversation

使用者當時說了什麼，以及完整 Context。

Agent Reasoning / Execution

Agent 選擇了什麼 Workflow。

Tool Trace

用了哪個工具、傳入什麼資料、返回什麼結果。

Performance

Latency、Token Usage、API Cost、Success Rate。

Governance

哪些 Tool 可以使用、哪些操作需要 Approval，以及誰修改過 Agent 的設定。

這些資料不只是用來 Debug。

它亦會成為下一輪 Evaluation 的基礎。

一個可以 Demo 的 Agent，和一個可以上線的 Agent，是兩回事

Demo

只證明 Agent 有一次成功完成任務。

Production

要證明 Agent 可以持續、可靠、可控制地完成任務。

所以我設計 Agent 時，不會只問「應該用哪個模型？」。

我會問：

Scope 是否清楚？
資料是否可靠？
工具是否受控？
Workflow 是否可以 recovery？
結果是否可以量度？
整個過程是否可以追溯？

這些才是 Agent 從 Prototype 走到 Production 的關鍵。