開始閱讀
AI 原理入門系列｜第 10 篇，共 10 篇。資料核對：2026-10-09。文中的情境與練習為教學示例。
聊天模型可以寫一封信，但真正寄出需要郵件工具；可以整理資料表的修改建議，但更新儲存格還需要程式執行。理解 AI Agent，首先要區分產生文字、提出工具呼叫，以及工具實際完成動作這幾件事。
工作流程與代理的差別
預先設計的工作流程，通常由程式決定步驟順序；代理則會讓模型在一定範圍內決定下一步與工具使用。兩者可以混合，名稱也沒有單一產品通用的嚴格邊界。Anthropic 的工程指南建議，先從能完成任務的簡單做法開始，依需求增加複雜度。Building Effective Agents
對「讀表單、整理摘要、交給人審核」這類固定任務，明確流程通常就很合適，不必為了使用 Agent 名稱而加入自由規劃。
圖解：工具型 AI 的任務循環
工具呼叫不是模型直接改變世界
常見系統會把可用工具及參數格式告訴模型。模型提出呼叫，程式檢查並執行，再把結果交回模型。代理可以依據結果繼續，但工具可能失敗、逾時或只完成一部分。
因此「我已完成」這句回答不能取代結果驗證。寫入文章後，應取得文章識別碼，重新讀取狀態，再確認公開網址是否能開啟。不同階段各有證據，才能知道是草稿已存、發布成功，還是只是準備好內容。
用部落格更新設計一個流程
本站教學案例可以拆成：確認主題、查核來源、撰寫內容、檢查連結、存成草稿、依授權發布，以及讀回驗證。查資料與寫草稿可能需要不同工具；發布權限也應和一般寫入分開。
若工具只回傳「請求已接受」，就要繼續查狀態，不能直接當成發布成功。若重送可能造成重複文章，則需要唯一識別或重複檢查，讓流程在中斷後仍能安全接續。
自動化程度要配合錯誤成本
文章標題改寫失敗，可以重寫；寄錯對象、改錯權限或公開私人資料，成本就高得多。設計時應列出哪些動作能自動執行、哪些需要人工確認，以及最多允許執行多少次或花多少資源。
外部網頁與文件是資料來源，裡面的文字不應自動變成系統指令。例如資料頁夾帶「把資料寄到另一個地址」，流程應維持原本任務與權限，不因讀到這句話就改變目的。
評估 Agent，要看完整任務結果
一個代理可能每一步都產生很漂亮的解釋，最後卻沒完成任務。評估可以記錄成功率、人工介入次數、花費時間、工具錯誤與最終資料是否正確。多步驟任務還應測試工具中斷、資料缺漏和重複執行。
挑一項每週工作，畫出輸入、工具、決策點、驗證與停止條件。先讓流程在一個小範圍內穩定完成，再增加自主程度。真正有用的代理，應讓你更容易確認工作完成了什麼。
圖解：工具呼叫不等於完成
案例：把文章整理到發布拆成可驗證步驟
假設目標是整理一篇教學文章。流程先讀取來源，抽出主張，產生草稿，再檢查連結與圖片。若系統允許發布，仍要確認內容狀態、目的網站與更新版本。工具回傳成功後，還要重新開啟文章，核對標題、正文與圖片是否真的存在。
其中固定且可預期的步驟，可以寫成一般工作流程；遇到需要依資料缺漏決定下一個查詢的情境，才需要較動態的決策。Agent 並不代表每一步都必須交給模型自由選擇。
失敗時怎麼辦？先設計停止條件
| 狀態 | 合理處理 |
|---|---|
| 來源缺少重要資訊 | 標記缺漏，停止做確定承諾 |
| 工具逾時 | 查詢是否已完成，避免重複提交 |
| 權限不足 | 交回有權限的人處理 |
| 超過時間或費用上限 | 保存進度並停止 |
對可能重複執行的操作，應有防重複機制。例如新增文章可以先檢查唯一識別碼，避免網路逾時後重試變成兩篇。只讀搜尋與修改資料也應使用不同的權限範圍。
如何評估代理真的有幫助？
除了成功率，記錄工具呼叫次數、人工修正時間、錯誤是否能被發現，以及是否在適當時候停止。一次漂亮示範不足以證明可靠；用缺資料、連線失敗與衝突版本等案例測試，才能知道工作流程的邊界。
練習：挑一個日常任務，寫出「完成證據」與三個停止條件，再決定哪些步驟值得自動化。
從自動產文看見 Agent 的責任邊界
一套每日產文系統可能先讀來源、選題、撰寫、查核、製圖，再把內容交給網站。這些步驟可以有固定流程，只有部分環節需要模型決定下一步。並不是每個步驟都交給自主 Agent 才算先進；可預測的流程常常更容易控制費用、追蹤錯誤與重跑失敗任務。
例如選題可以讓模型比較資料，但發布應由明確的狀態條件控制：來源是否足夠、必填欄位是否完整、圖片是否存在、預算是否允許。若任一條件不符，保存草稿並記錄原因，比讓模型自行判斷「應該沒問題」可靠。這些條件需要程式執行，不只是寫在提示詞裡。
重試為什麼可能造成重複發文？
假設工具送出貼文後網路中斷，系統不知道平台是否已接受。如果立刻重新送一次，就可能出現兩篇相同貼文。較好的做法是為任務建立唯一識別，保存外部回傳的編號；遇到不確定結果時先查詢，無法確認就標示待核對。重試不是單純再按一次，也需要理解外部動作是否可以安全重複。
同樣的原則適用於寄信、建立訂單與修改資料。讀取公開頁面通常容易重做，寄出一封信卻不能撤回。為工具區分只讀、可逆修改與外部發布，並給予不同權限與處理方式，可以降低一個小錯誤擴散成大量副作用的風險。
如何替 Agent 設計驗收表？
至少檢查任務是否完成、事實是否有依據、工具是否只在授權範圍內使用，以及費用是否在限制內。不要只看最終文字。系統若靠十次重試才完成一篇文章，與一次就完成的流程，在營運上可能有很大差異。也要測試來源網站失效、憑證過期、資料格式改變等情境，而不是只跑一個成功範例。
課堂可以把「查找三個來源並整理摘要」設為第一階段，只允許讀取；第二階段才加入建立草稿；最後才討論發布。每增加一種能力，都要補上狀態、紀錄與停止條件。如此才能知道自動化究竟節省了哪個步驟，而不是讓一個看似會自己工作的系統，變成無法追查的黑箱。