用聊天介面請 AI 改寫一封信，和讓 AI 每天讀取客服單、查公司政策、更新系統，工程難度完全不同。真正的 AI 應用通常由模型、資料、程式規則、工具權限與驗收流程共同組成。
最實用的起點是先問：這個任務需要生成內容、查外部資料，還是執行動作？ 需求不同，應採用的架構也不同。從 Prompt 直接跳到全自動 Agent，通常只會把原本容易發現的錯誤藏進更長的流程。
先用任務選架構
| 你的需求 | 優先方案 | 何時升級 |
|---|---|---|
| 偶爾摘要、改寫、分類 | 清楚 Prompt + 人工檢查 | 任務重複且格式固定時接 API |
| 批次處理固定流程 | API／自動化工作流 | 需要外部知識時加入檢索 |
| 查公司文件或最新資料 | RAG + 引用 | 需要跨系統執行時加入工具 |
| 呼叫查詢、寄信、更新資料 | 工具呼叫 + 明確規則 | 步驟會依結果改變時評估 Agent |
| 多步驟探索與執行 | 有界限的 Agent | 先加權限、預算、停止與確認機制 |
若條件可以完整列出，普通程式與規則通常更穩定。例如「金額超過上限一律人工審核」應寫成確定性規則，不需要交給模型猜。
第一層：用 Prompt 定義可驗收輸出
好的 Prompt 重點在於可驗收，不必堆疊客套話或「你是世界頂尖專家」等角色稱號。輸入、任務、限制和輸出格式都要清楚到可以檢查。
任務：把客服訊息分類為「退款、技術問題、帳務、其他」。
資料：只使用下方客戶原文，不推測未提供資訊。
輸出：JSON，欄位為 category、urgency、reason、needs_human_review。
規則：提到重複扣款或帳號遭盜時，needs_human_review 必須為 true。先用 20 至 50 個真實但去識別化的案例測試。加入容易混淆、資料缺漏與惡意指令等情境，記錄預期答案。Prompt 每次修改後都重跑同一批案例，才能知道品質是改善還是只換了一種錯法。
不必要求模型顯示完整思考鏈。需要可稽核性時，要求簡短理由、引用輸入欄位、計算步驟或可重現證據。更多寫法可套用 Prompt 七格公式。
第二層：用 API 把任務接進產品
API 讓程式送出輸入並接收模型結果。網頁聊天中的功能、模型名稱與 API 支援不一定相同，實作時要看供應商當下文件，不要從舊教學複製端點與模型 ID。
一個可維護的 API 流程要先保護金鑰：放在伺服器端環境變數或秘密管理服務，不能出現在前端與 Git。請求端要設定逾時、重試、速率限制與單次輸入／輸出上限，避免單一異常請求拖垮服務或累積失控費用。
輸出宜用 JSON Schema 等方式限制結構，程式端仍要驗證型別和必填欄位。每次呼叫應記錄模型版本、提示版本、延遲、Token、錯誤與結果狀態；供應商失敗、超時或拒答時，也要有可預期的回退流程。
以 OpenAI 為例，官方目前建議新的文字生成應用使用 Responses API，實際參數與 SDK 範例應查閱最新的文字生成文件。其他供應商也有自己的 SDK 與版本政策，不要把一家的介面假設成通用標準。
Token 數量取決於模型與分詞器，不能用「一個中文字固定等於一個 Token」估價。應用實際分詞器與使用紀錄計算，詳見 Token 與 API 成本入門。
第三層：用 RAG 提供私有或最新證據
RAG（Retrieval-Augmented Generation，檢索增強生成）會先從指定資料來源找出相關片段，再把片段與問題交給模型生成答案。原始 RAG 論文結合參數化模型與外部非參數記憶；今天的產品實作則常包含文件解析、分段、向量或關鍵字檢索、重排與引用。
基本流程如下：
- 匯入文件，保存來源、版本、日期與權限。
- 解析並切分內容，建立可搜尋索引。
- 收到問題後檢索候選段落，必要時重排。
- 把問題與段落交給模型，要求只依證據回答並附引用。
- 找不到足夠證據時拒答或轉人工。
RAG 不會自動消除幻覺。文件可能過期、解析可能漏表格、檢索可能找錯段落，模型也可能曲解正確證據。要分開測「有沒有找到正確段落」與「拿到段落後有沒有回答正確」，完整做法可看 RAG 實作指南。
第四層：用工具呼叫執行動作
模型可以輸出結構化的工具名稱與參數，再由你的程式實際查資料、計算或更新系統。模型提出呼叫建議，不應直接擁有資料庫最高權限。
每個工具應維持單一功能，名稱、參數與回傳狀態要清楚。身分、權限、欄位與業務規則必須在伺服器端驗證，不能相信模型產生的參數已經安全。
讀取和寫入工具應分開；刪除、付款、寄信等動作要增加確認。工具還要回傳可辨識的成功、失敗與可重試狀態，並保存誰在何時提出要求、系統實際做了什麼的稽核紀錄。
Model Context Protocol（MCP）提供主機、客戶端與伺服器之間交換工具、資源與提示的標準方式。它改善整合，不會讓工具本身變準，也不會替代認證、授權與輸入驗證。可延伸閱讀 MCP 入門。
第五層：什麼時候才需要 Agent？
Agent 通常讓模型在迴圈中觀察目前狀態、選擇下一步、呼叫工具，再根據結果繼續，直到完成、失敗或達到停止條件。它適合路徑會隨中間結果改變、無法事先寫死每一步的任務。
例如研究助理可能先搜尋，再依結果決定讀哪份文件；除錯代理可能先跑測試，再根據錯誤選擇檔案。固定的「收到表單後產生摘要並寄給主管」用一般工作流就夠，不需要 Agent。
Agent 不會因為「反思」一詞就可靠。模型可能重複呼叫、選錯工具、誤解結果或在接近完成時破壞正確狀態。至少要設定：
- 最大步數、時間、Token 與金額預算。
- 可用工具清單與最小權限。
- 高風險動作的人類確認點。
- 每一步狀態、輸入、輸出與工具結果紀錄。
- 可安全重試的冪等設計，以及中止和回復方式。
- 以完整任務成功率評測，而非只看單次回覆。
更多架構可看 AI Agent 入門與 LLM 評測指南。
用一個小專案走完整條路
以「客服單分類與回覆草稿」為例：
第 1 版：只做離線分類
準備去識別化的歷史客服單與人工標籤，讓模型輸出分類、緊急度與簡短理由。先測分類，不寄信、不連正式系統。
第 2 版：加入公司政策檢索
把退款與保固文件建成知識庫，回覆草稿必須引用政策段落。找不到適用條文就標記人工處理，不允許模型自行編規則。
第 3 版：接入唯讀工具
讓系統查詢訂單狀態，但先不開放退款、改地址或寄信。所有參數由後端驗證，並遮蔽不必要個資。
第 4 版：有限度自動化
低風險、通過規則的案例可建立回覆草稿；涉及退款、爭議、帳號安全或敏感資料仍由人確認。追蹤誤分類、被人工大幅修改和退回的案例，定期加入測試集。
這條路線讓每次升級都有明確價值與風險差異。若第一版分類都不穩，加入 Agent 只會讓失敗更難追查。
上線前檢查表
- 價值：有沒有比人工、規則或搜尋節省足夠時間？
- 資料：輸入來源、權限、保存、刪除與個資處理是否清楚？
- 品質：是否有正常、邊界、拒答與攻擊案例的固定測試集？
- 成本：是否追蹤模型、檢索、工具、重試和人工覆核的總成本？
- 安全：工具是否採最小權限，高風險動作是否需要確認？
- 營運：是否能監控、暫停、回退、重跑並追查單一事件？
- 責任：錯誤發生時由誰處理，使用者如何申訴或改正？
NIST AI 風險管理框架將治理、情境盤點、衡量與管理視為持續循環。AI 產品發布後，資料與使用方式會改變，評測與風險控制也要跟著更新。
處理公司資料前，先套用 AI 隱私檢查表；模型輸出涉及醫療、法律、財務或人事決策時，還要增加領域專家與合規審查。
建議學習順序
- 用固定案例練習 Prompt 與結構化輸出。
- 學會一種程式語言的 HTTP、JSON、環境變數與錯誤處理。
- 串接一個模型 API，加入日誌、成本與測試。
- 只有任務需要外部知識時才做 RAG。
- 先做單一唯讀工具，再加入寫入與確認流程。
- 最後才做有多步驟決策需求的 Agent。
這套建置順序用來降低複雜度，無須把它當成逐級考試的課綱。每一層都能獨立產生價值，也都應該先證明可靠，再承擔下一層風險。
常見問題
不會寫程式，也能做 AI 應用嗎？
可以先用聊天工具、自動化平台與表單建立原型。但涉及使用者帳號、機密資料、付款或正式系統寫入時，仍需要理解 API、權限、錯誤處理與資料保護，不能只靠拖拉元件上線。
Prompt、RAG 和微調應該先做哪個？
先建立 Prompt 與測試基準。缺最新或私有知識時加 RAG；需要穩定特定格式、風格或行為，且有高品質訓練資料時才評估微調。三者可以並用，但解決的問題不同。
RAG 能完全避免 AI 幻覺嗎？
不能。它能提供外部證據，但解析、檢索、排序與生成每一步都可能錯。應要求引用、設定證據不足時拒答，並分別測檢索命中率和最終答案品質。
AI Agent 和一般自動化工作流差在哪裡？
工作流的步驟通常由程式預先定義；Agent 會讓模型根據中間結果選擇下一步與工具。路徑固定時，工作流更容易預測與除錯；只有路徑確實需要動態決策時，Agent 的複雜度才值得。
怎麼估算 AI 應用成本？
除了輸入與輸出 Token，還要計入圖片或音訊、檢索與資料庫、工具 API、重試、快取、監控和人工覆核。用真實流量做小規模試跑，記錄每個成功任務的總成本，比只看模型單價可靠。