← iPAS 補充教材總覽
iPAS AI 應用規劃師 2026 考點補充
Agentic AI 架構設計
LangGraph、多代理協作模式、工具編排，企業 Agentic Workflow 從 PoC 到生產的實務
為什麼 Agentic AI 是 2026 必考重點？
2026 年的 iPAS 考題已經從「單一模型」進化到「AI 系統設計」。考試不再只問「GPT 是什麼」，而是問「如何設計一個能自主完成複雜任務的 AI 系統」。
PDF 備考分析指出：生成式 AI 架構佔 30%，其中 Agent 與多代理編排是新增的高頻考點。
考試重點：AI Agent 的定義 — 具有環境感知、決策與行動能力的自主實體
AI Agent 核心架構
什麼是 AI Agent？
一個 AI Agent 不只是 LLM，而是由四個組件構成的自主系統：
┌────────────────────────────────────┐
│ AI Agent │
│ │
│ ┌──────────┐ ┌──────────────┐ │
│ │ 感知 │ │ 記憶 │ │
│ │ (Perceive)│ │ (Memory) │ │
│ │ 接收任務 │ │ 短期/長期記憶 │ │
│ └────┬─────┘ └──────┬───────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌──────────────────────────────┐ │
│ │ 推理與規劃 │ │
│ │ (Reasoning & Planning) │ │
│ │ LLM 作為決策核心 │ │
│ └─────────────┬────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────┐ │
│ │ 行動 (Action) │ │
│ │ 工具呼叫 / API 調用 / 程式執行 │ │
│ └──────────────────────────────┘ │
└────────────────────────────────────┘
Agent vs Chatbot
| 面向 | 傳統 Chatbot | AI Agent |
|---|---|---|
| 互動方式 | 一問一答 | 自主規劃多步驟 |
| 工具使用 | 無 | 可呼叫 API、搜尋、執行程式 |
| 記憶 | 僅單輪對話 | 短期 + 長期記憶 |
| 錯誤處理 | 無法自我修正 | 觀察結果 → 反思 → 重試 |
| 任務複雜度 | 簡單問答 | 多步驟複雜任務 |
常見題型：「定義何為 AI Agent？」→ 具有環境感知、決策與行動能力的自主實體
常見 Agent 設計模式
1. ReAct（Reasoning + Acting）
最基本的 Agent 模式，LLM 交替進行推理和行動：
思考 (Thought): 使用者問最新匯率，我需要查即時資料
行動 (Action): 呼叫匯率 API → {"USD/TWD": 32.5}
觀察 (Observation): 美元兌台幣為 32.5
思考 (Thought): 已獲得答案，可以回覆
回答: 目前美元兌台幣匯率為 32.5
2. Plan-and-Execute（規劃後執行）
先制定完整計畫，再逐步執行：
任務：幫我分析這份銷售報告並製作視覺化摘要
計畫：
1. 讀取銷售報告 PDF
2. 提取關鍵數據（營收、成長率、產品佔比）
3. 用 Python 製作圖表
4. 撰寫分析摘要
執行：逐步完成每個子任務
3. Reflection（反思模式）
Agent 執行後自我審查，發現問題就修正重做：
生成 → 反思「這段程式碼有沒有 bug？」→ 修正 → 再反思 → 完成
4. Multi-Agent（多代理協作）
多個專職 Agent 分工合作：
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 研究 Agent │ │ 撰寫 Agent │ │ 審核 Agent │
│ 負責搜尋 │──→│ 負責起草 │──→│ 負責品質把關│
└──────────┘ └──────────┘ └──────────┘
考試重點：四種設計模式各自適合的場景，不是哪個「最好」，而是哪個「最適合」
工具使用 (Tool Use / Function Calling)
什麼是工具呼叫？
LLM 本身只能生成文字。透過工具呼叫 (Tool Use)，Agent 可以：
| 工具類別 | 範例 |
|---|---|
| 資訊檢索 | 網路搜尋、資料庫查詢、文件檢索 (RAG) |
| 程式執行 | Python 計算、資料分析、圖表生成 |
| API 串接 | 天氣 API、匯率 API、CRM 系統 |
| 系統操作 | 發送郵件、建立日程、操作檔案 |
工具呼叫流程
使用者: 「台北明天會下雨嗎？」
LLM 判斷: 需要即時天氣資料 → 呼叫天氣 API
→ API 回傳: {"台北": {"明天": "多雲短暫陣雨", "降雨機率": 60%}}
LLM 整理: 「台北明天有 60% 機率下雨，建議攜帶雨具。」
考試重點：工具呼叫讓 Agent 突破 LLM 的三大限制 — 即時性（資料過時）、準確性（計算不準）、行動力（只能輸出文字）
多代理系統 (Multi-Agent Systems)
協作模式
| 模式 | 說明 | 場景 |
|---|---|---|
| 階層式 | 主管 Agent 分派任務給下屬 Agent | 專案管理、客服分級 |
| 對等式 | 多個 Agent 平等討論、投票決策 | 辯論、多角度分析 |
| 流水線式 | Agent A 輸出 → Agent B 輸入 → Agent C 輸出 | 內容生產、資料處理 |
| 競爭式 | 多個 Agent 各自提案，選最佳方案 | 創意發想、策略規劃 |
多代理的挑戰
| 挑戰 | 說明 | 解決方案 |
|---|---|---|
| 協調成本 | Agent 之間溝通需要額外 token | 設計高效的通訊協定 |
| 衝突解決 | 兩個 Agent 意見不同 | 引入仲裁 Agent 或投票機制 |
| 責任歸屬 | 出錯時不知道是哪個 Agent 的問題 | 完整的 trace log 與審計 |
| 失控風險 | Agent 自主決策可能偏離目標 | 設定行動邊界 (Guardrails) |
企業 Agentic Workflow 架構
從 PoC 到生產的四個階段
| 階段 | 架構 | 特點 |
|---|---|---|
| L1 單一 Agent | 1 個 LLM + 幾個工具 | 概念驗證，快速試錯 |
| L2 工作流 | 固定流程，Agent 填充各步驟 | 可預測、可控制 |
| L3 多代理 | 多個專職 Agent 協作 | 處理複雜任務 |
| L4 自主系統 | Agent 自我規劃、動態分工 | 最強但最難控制 |
生產環境必備組件
┌─────────────────────────────────────────────┐
│ Agentic System │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Agent A │ │ Agent B │ │ Agent C │ │
│ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │
│ │ │ │ │
│ ┌─────▼──────────────▼──────────────▼─────┐ │
│ │ Orchestrator (編排器) │ │
│ │ 任務分配、狀態追蹤、錯誤處理 │ │
│ └─────────────────┬───────────────────────┘ │
│ │ │
│ ┌─────────────────▼───────────────────────┐ │
│ │ 共享基礎設施 │ │
│ │ 記憶層 │ 工具注冊 │ 日誌追蹤 │ 安全邊界 │ │
│ └─────────────────────────────────────────┘ │
└─────────────────────────────────────────────┘
關鍵生產考量
| 面向 | 考量 |
|---|---|
| 可觀測性 | 每步決策都要有 trace log（可用 LangSmith/Langfuse） |
| 安全邊界 | 限制 Agent 可呼叫的工具、可存取的資料範圍 |
| 人類監督 | 高風險動作（付款、刪除、發送）需人類確認 |
| 成本控制 | 多代理 = 多次 LLM 呼叫 = 高 token 成本 |
| 延遲管理 | 多步驟執行的總延遲可能超過使用者耐心 |
| 錯誤恢復 | 中間某步失敗，系統能回到上一個安全狀態 |
編排框架：LangGraph 與替代方案
主流框架比較
| 框架 | 核心理念 | 適用場景 | 學習曲線 |
|---|---|---|---|
| LangGraph | 狀態圖 (State Graph) | 複雜多步驟流程 | 中等 |
| CrewAI | 角色扮演團隊 | 多角色協作 | 低 |
| AutoGen | 對話驅動的多代理 | 研究、原型 | 中等 |
| Semantic Kernel | 微軟生態整合 | 企業 .NET 環境 | 中等 |
LangGraph 核心概念
LangGraph 用有向圖描述 Agent 的工作流：
- Node（節點）：每個節點是一個執行步驟（LLM 呼叫、工具使用、判斷邏輯）
- Edge（邊）：節點之間的轉換路徑
- State（狀態）：在節點間傳遞的共享資料
- Conditional Edge（條件邊）：根據狀態決定下一步走向（分支邏輯）
[接收任務] → [分析意圖] → 條件分支
├── 簡單問答 → [直接回答] → [結束]
├── 需要搜尋 → [搜尋工具] → [整理結果] → [回答]
└── 需要計算 → [程式執行] → [驗證結果] → [回答]
考試重點：LangGraph 是「狀態圖」思維，不是簡單的 Chain；它能處理分支、迴圈、人類介入
規劃師視角：Agent 導入決策
何時需要 Agent？何時不需要？
| 場景 | 是否需要 Agent | 建議 |
|---|---|---|
| 固定格式 FAQ | 不需要 | RAG + 模板即可 |
| 客服：查訂單、改地址 | 需要（L1） | 單一 Agent + 幾個 API 工具 |
| 報告生成：搜尋+分析+排版 | 需要（L2） | 工作流 Agent |
| 軟體開發：規劃+寫碼+測試 | 需要（L3） | 多代理協作 |
| 自主研究：開放性探索 | 謹慎（L4） | 需嚴格邊界控制 |
Agent 導入的 ROI 考量
| 成本項目 | 說明 |
|---|---|
| LLM API 費用 | Agent 每步都呼叫 LLM，複雜任務可能 10-50 次呼叫 |
| 開發成本 | 工具整合、錯誤處理、測試覆蓋 |
| 維運成本 | 監控、日誌分析、模型更新 |
| 延遲預期 | 多步驟 Agent 回應時間 5-60 秒 |
風險管理
- 幻覺放大：Agent 在第一步幻覺，後續步驟可能基於錯誤資訊繼續執行
- 工具誤用：Agent 可能呼叫錯誤的工具或傳錯參數
- 無限迴圈：推理不收斂，一直重試同一動作
- 安全風險：Agent 有了行動能力（寫檔、發信、刪資料）= 有了破壞能力
考試重點：Agent 的風險核心在於「有行動能力」，因此 Guardrails 和人類監督至關重要
模擬試題
題目 1：以下何者最能描述 AI Agent 與傳統 Chatbot 的差異？
- (A) Agent 使用更大的語言模型
- (B) Agent 可以自主規劃多步驟任務並使用外部工具
- (C) Agent 只能處理文字，Chatbot 可處理多模態
- (D) Agent 不需要人類監督
查看答案
答案：(B)。AI Agent 的核心差異在於「自主規劃 + 工具使用 + 多步驟執行」的能力。(A) 模型大小不是決定因素，(C) 敘述相反，(D) Agent 仍需要人類監督（尤其高風險動作）。題目 2：某企業希望建立一個 AI 系統，能自動：(1) 接收客戶投訴郵件 (2) 分析投訴類型 (3) 查詢相關訂單 (4) 生成回覆草稿。最適合的架構是？
- (A) 單一 LLM prompt
- (B) RAG 檢索增強生成
- (C) Agentic Workflow（工具編排 Agent）
- (D) 純規則引擎
查看答案
答案：(C)。這個任務涉及多步驟（分析→查詢→生成）且需要呼叫外部系統（訂單資料庫），是典型的 Agentic Workflow 場景。(A) 單一 prompt 無法完成多步驟，(B) RAG 只解決知識檢索，(D) 規則引擎缺乏自然語言理解能力。題目 3：在多代理 (Multi-Agent) 系統中，以下哪個不是主要挑戰？
- (A) Agent 之間的通訊成本
- (B) Agent 決策衝突的解決
- (C) 單一 Agent 的推論速度
- (D) Agent 出錯時的責任歸屬
查看答案
答案：(C)。單一 Agent 的推論速度是 LLM 本身的議題，不是多代理「協作」層面的挑戰。Multi-Agent 的核心挑戰在於：協調成本 (A)、衝突解決 (B)、責任歸屬 (D)。題目 4：企業導入 Agent 系統時，以下哪項安全措施最為關鍵？
- (A) 使用最新的 LLM 模型
- (B) 設定行動邊界 (Guardrails) 與高風險動作需人類確認
- (C) 提高 API 呼叫頻率限制
- (D) 使用更多訓練資料