https://yennj12.js.org/yennj12_blog_V4/tags/api/Recent content in API on YennJ12 Engineering BlogHugo -- gohugo.ioen-usSun, 21 Jun 2026 21:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase13-part1-mcp-apis-zh/Sun, 21 Jun 2026 21:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase13-part1-mcp-apis-zh/大多數人把 LLM 接上 API，然後祈禱模型不要亂呼叫。 正確做法是：設計工具邊界，讓模型只能做它該做的事。 差別不在「能不能呼叫」，而在「呼叫錯了有沒有圍欄」。 工具整合的本質，是在 LLM 的智能與外部世界的副作用之間建立可審計的閘門。 面試情境：你正在設計一個 AI 客服代理，需要讀取訂單資料庫、發送退款請求、查詢物流狀態。系統每日處理 5 萬通查詢，P99 回應要在 3 秒內。你怎麼設計工具層的架構，同時確保安全性與可觀測性？ 一、核心問題：LLM 如何安全地操作外部世界 純語言模型是無狀態的文字轉換器，它不知道今天幾號，不知道訂單狀態，也無法真正寄出一封信。但產品需求要求 AI 能夠「做事」，不只是「說話」。 這個落差催生了工具使用（Tool Use）這個範式。但工具使用帶來的不只是能力擴展，更帶來三個深層工程挑戰： 挑戰一：副作用不可逆性 模型呼叫 send_email() 後，信就出去了。模型呼叫 delete_record() 後，資料就消失了。不像純 LLM 呼叫可以重試，帶有副作用的工具呼叫必須有 idempotency 保護和操作審計。 挑戰二：工具定義爆炸 一個企業 AI 代理可能需要整合 30+ 個內外部 API。每個工具的參數 Schema 、認證方式、錯誤處理各不相同。沒有標準化協議，工具層會變成難以維護的義大利麵程式碼。 挑戰三：提示注入攻擊 當工具的輸出結果（如網頁內容、資料庫紀錄）重新進入 LLM 上下文時，惡意內容可以偽裝成工具結果，誘導模型執行非預期的指令——這是 AI 系統特有的 injection 攻擊面。 MCP（Model Context Protocol）的出現，正是為了系統性地解決這三個問題。 二、三個演進階段 Phase 1：POC（< 5K 用戶，單一工具） ╔══════════════════════════════════════════╗ ║ Phase 1：直接呼叫 API（POC 階段） ║ ╚══════════════════════════════════════════╝ 用戶輸入 │ ▼ ┌────────────┐ Function ┌──────────────────┐ │ LLM API │─────Calling────▶│ 直接呼叫外部 API │ │ (GPT-4o) │◀────結果────────│ (requests 庫) │ └────────────┘ └──────────────────┘ │ ▼ 回應輸出 特徵： - 工具定義寫死在 system prompt - 無認證管理，API key 硬編碼 - 無錯誤重試，失敗直接拋例外 - 無日誌，難以除錯 適合場景：內部 Demo、單一 API 的 Chatbothttps://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part37-legacy-integration-zh/Fri, 05 Jun 2026 15:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part37-legacy-integration-zh/Demo 時 Agent 很漂亮。 到客戶現場才發現：資料在 SAP（文件很爛）、Oracle（只有 DB 直連）、 還有一個每天凌晨 2 點才匯出的 CSV 檔案。 「連接組織」，是 FDE 和 AI 工程師最核心的差距之一。 面試情境 面試官：「客戶是一家有 30 年歷史的製造業。資料在三個地方：SAP ERP（有 REST API 但文件很爛）、Oracle 資料庫（只有 DB 直連）、一個每天從 mainframe 匯出的 CSV。他們希望 AI 能回答：庫存狀況、哪個供應商交期有問題。你怎麼設計這個整合層？」 一、問題本質：Legacy 整合的三種挑戰 Demo 的 Tool： def get_inventory(item_id: str) -> dict: return requests.get(f"https://api.example.com/inventory/{item_id}") 客戶現場的現實： SAP API： ├── 認證：OAuth + Client Certificate（文件在某個 Confluence 頁面，過期了） ├── Rate Limit：10 req/sec per user（AI 可能觸發 100 并發） ├── 回傳格式：200 欄位的 XML（Agent 只需要 5 個） └── 錯誤碼：自定義的 SAP 錯誤碼（不是標準 HTTP） Oracle DB： ├── 沒有 API，只能 JDBC/ODBC 直連 ├── 沒有任何文件，Schema 要靠 DBA 解釋 └── 有 SQL Injection 和 full table scan 的風險 Mainframe CSV： ├── 每天凌晨 2 點才有新資料（不是即時） ├── 格式偶爾會改變（沒有版本控制） └── 直接讀大 CSV 到 context = token 爆炸 這三個資料來源，需要三種不同的整合模式。 二、整合模式選型框架 選型決策矩陣： 資料來源特性 → 建議整合模式 ────────────────────────────────────────────────────────────── 有 API，但設計複雜 → API 橋接層 （認證複雜、格式冗餘、Rate Limit） ────────────────────────────────────────────────────────────── 只有 DB 直連，沒有 API → 資料庫查詢層（Stored Procedure） ────────────────────────────────────────────────────────────── 批次檔案（CSV、Excel） → 批次攝取 Pipeline（GCS → BigQuery） ────────────────────────────────────────────────────────────── 即時串流資料 → Pub/Sub → BigQuery → Agent Query ────────────────────────────────────────────────────────────── 三種模式的系統特性對比： 模式 延遲 資料新鮮度 設計複雜度 適用場景 ────────────────────────────────────────────────────────────── API 橋接層 低（ms） 即時 高 SAP 庫存查詢 ────────────────────────────────────────────────────────────── DB 查詢層 中（ms） 即時 中 Oracle 訂單狀態 ────────────────────────────────────────────────────────────── 批次攝取 Pipeline 秒-分 T+1（次日） 低 Mainframe 月報 ────────────────────────────────────────────────────────────── 製造業客戶的對應： SAP → API 橋接層 Oracle → DB 查詢層 Mainframe CSV → 批次攝取 Pipeline 三、模式一：API 橋接層設計 設計目標：隱藏 SAP API 的所有複雜性， 讓 Agent Tool 看到的是簡單、穩定的介面。 架構： ┌──────────────────────────────────────────────────────────────┐ │ ADK Agent │ │ def get_inventory(item_id, warehouse) → dict │ │ （Agent 只看到這個簡單函數） │ └──────────────────────────┬───────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────┐ │ SAP Adapter Service（你寫的橋接層） │ │ │ │ ├── 認證管理 │ │ │ Secret Manager 取 OAuth token + Client Certificate │ │ │ Token 自動更新（expiry 前 5 分鐘刷新） │ │ │ │ │ ├── Rate Limiting（Token Bucket，10 req/sec） │ │ │ 超過上限的請求排隊等待，設定 queue timeout = 5s │ │ │ │ │ ├── 格式轉換 │ │ │ 200 欄位 XML → 5 欄位 JSON │ │ │ {available_qty, unit, location, last_updated, status} │ │ │ │ │ ├── Response Cache（Redis，TTL 5 分鐘） │ │ │ 相同 item_id+warehouse 的查詢，5 分鐘內走 Cache │ │ │ │ │ └── 錯誤處理 │ │ HTTP 429 / SAP-specific 錯誤碼 → 統一轉換成 Retry 或 │ │ 結構化錯誤訊息（Agent 能理解的格式） │ └──────────────────────────┬───────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────┐ │ SAP REST API（原始系統） │ │ 認證複雜、格式冗餘、Rate Limit 10 req/sec │ └──────────────────────────────────────────────────────────────┘ Cache 的效益： 假設有 80% 的查詢是重複的相同 item_id： SAP API 實際呼叫量降低 80%，Rate Limit 問題基本消失。 對 SAP 系統的壓力大幅降低，減少影響生產系統的風險。 四、模式二：資料庫查詢層（Stored Procedure） 核心安全問題：Agent 不能直接生成 SQL 並執行。 風險分析： ❌ 直接讓 Agent 生成 SQL： Agent: SELECT * FROM orders WHERE supplier = '{user_input}' 攻擊者輸入：' OR 1=1; DROP TABLE orders; -- → SQL Injection，資料庫損毀 ❌ 直接 SELECT *： 對大型 Oracle 表的 full table scan 可能讓生產資料庫效能崩潰 ✅ 正確設計：Stored Procedure 層 架構： ADK Agent Tool def get_supplier_delivery(supplier_id, date_from, date_to) │ │ 呼叫預定義的 Stored Procedure ▼ Oracle DB EXEC sp_GetSupplierDelivery(?https://yennj12.js.org/yennj12_blog_V4/posts/specialized-agent-orchestration-patterns-zh/Thu, 19 Mar 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/specialized-agent-orchestration-patterns-zh/多 Agent Token 優化系列 pt.7：深入探討專責化 Agent 的協作模式，涵蓋團隊組織架構、動態路由、任務分解策略、狀態管理、錯誤處理等生產級實作，幫助你打造高效協調的 Agent 團隊。https://yennj12.js.org/yennj12_blog_V4/posts/agent-specialization-multi-agent-guide-zh/Thu, 12 Mar 2026 22:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/agent-specialization-multi-agent-guide-zh/深入探索 Agent 專責化策略：從單一通用 Agent 到專業分工的專家團隊，涵蓋職責劃分、System Prompt 精簡、工具最小化配置、模型差異化選擇等完整實作，幫助你大幅降低 System Prompt 的 Token 消耗並提升輸出品質。https://yennj12.js.org/yennj12_blog_V4/posts/selective-context-passing-multi-agent-guide-zh/Thu, 12 Mar 2026 20:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/selective-context-passing-multi-agent-guide-zh/多 Agent Token 優化系列 pt.5：深入探索選擇性 Context 傳遞策略，從依賴關係映射、結構化輸出到相關性過濾，提供完整實作範例，幫助你大幅降低 Agent 間通訊的 Token 消耗。https://yennj12.js.org/yennj12_blog_V4/posts/model-tiering-cost-optimization-guide-zh/Thu, 12 Mar 2026 18:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/model-tiering-cost-optimization-guide-zh/多 Agent Token 優化系列 pt.4：深入探索模型分層策略，從任務分類、智能路由到動態選擇，提供完整實作範例，幫助你在保持品質的同時大幅降低 AI 應用成本。https://yennj12.js.org/yennj12_blog_V4/posts/prompt-caching-practical-guide-rag-vector-db-zh/Thu, 12 Mar 2026 14:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/prompt-caching-practical-guide-rag-vector-db-zh/多 Agent Token 優化系列 pt.2：深入探索 Prompt Caching 的實際應用，從 Claude API 原生快取、應用層記憶體快取、到 RAG 系統整合，提供完整程式碼範例，幫助你打造高效低成本的 AI 應用。https://yennj12.js.org/yennj12_blog_V4/posts/multi-agent-token-optimization-claude-code-zh/Thu, 12 Mar 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/multi-agent-token-optimization-claude-code-zh/多 Agent Token 優化系列總覽：深入解析 Token 用量優化策略，涵蓋 Prompt Caching、Context 壓縮、Agent 專責化、模型分層、選擇性 Context 傳遞等方法，幫助你建構高效且低成本的多 Agent 系統。