摘要
如果 AI 只是回答一個問題，成本通常還算容易估。真正會把預算吃掉的，是 AI Agent：它會拆任務、查資料、呼叫工具、讀記憶、操作瀏覽器、重試、請另一個代理協助，最後還要留下 trace、評估與人工審核紀錄。
這不代表企業不該用 Agent。相反，Agent 很可能是 AI 從聊天工具變成生產力基礎設施的關鍵。但越接近真實工作，越不能只看「一次模型呼叫多少錢」。你要管理的是一整條任務路徑：每個目標允許跑幾步、能用哪些工具、什麼時候停止、哪些結果必須人工批准、失敗時如何降級。
核心結論
AI Agent 的成本黑洞，不是模型比較貴，而是「一個需求」會被展開成「一串不可見的工作」。
| 常見誤判 | 真正要管理 |
|---|---|
| 只估單次 token 成本 | 估整個任務的模型步數、工具步數、檢索、重試與審核 |
| 只問 Agent 能不能完成任務 | 問它完成任務前最多能跑幾步、用哪些工具、讀哪些資料 |
| 只看成功案例 | 看失敗時是否會無限重試、誤用工具或把問題丟給更貴模型 |
| 只記錄最終答案 | 記錄中間步驟、工具呼叫、延遲、成本、錯誤與人工介入 |
| 只追求全自動 | 把人工批准設計成責任邊界與成本節流閥 |
Agent 的價值不是「自動工作者越多越好」，而是讓每個自動工作者都有明確任務、預算、權限、停損線與回報方式。
目錄
- 為什麼 Agent 比聊天更容易失控
- 一個需求如何變成一串成本
- 五種最容易放大算力的 Agent 設計
- 產品上線前的 Agent 預算表
- 工具權限與人工批准怎麼設計
- 把 Agent 從黑盒變成可營運系統
- 參考來源與資料時間
- 常見問題
為什麼 Agent 比聊天更容易失控
聊天工具大多是一問一答。使用者問，模型答；答錯了，人再追問。
Agent 不一樣。Agent 的目標通常是「完成一件事」：整理競品、建立名單、寫一封追蹤信、檢查網站轉換流程、生成報表、更新 CRM 草稿、比對文件或操作瀏覽器。
為了完成這件事，它可能會做出一串動作：
- 先理解目標。
- 拆成幾個子任務。
- 查內部知識庫。
- 呼叫外部工具。
- 讀網頁或文件。
- 產生中間摘要。
- 發現資料不足後重查。
- 請另一個代理處理特定步驟。
- 合併輸出。
- 進行自我檢查或請人批准。
每一步都可能消耗模型推論、檢索、儲存、網路、工具 API、觀測資料與人工時間。這就是為什麼「AI 變便宜」不會自動讓 Agent 成本消失：單位成本下降，可能反而讓團隊把更多流程交給 Agent，總用量跟著放大。
一個需求如何變成一串成本
假設你讓 Agent 幫業務團隊準備一份潛在客戶研究摘要。表面上，它只是回答「這家公司適不適合開發」。
實際成本可能來自：
| 步驟 | 成本來源 | 風險 |
|---|---|---|
| 讀公司網站 | 瀏覽器操作、頁面擷取、摘要模型 | 頁面資料過期或被錯誤理解 |
| 查公開資料 | 搜尋、外部 API、重複檢索 | 搜到相似公司或不可靠來源 |
| 比對 ICP | 模型分類、規則判斷、資料庫讀取 | 分類標準不一致 |
| 產生初信 | 較強模型、品牌語氣、個人化資料 | 對外承諾過度或語氣不當 |
| 寫入 CRM 草稿 | 工具調用、權限檢查、操作紀錄 | 寫錯欄位或覆蓋資料 |
| 人工審核 | 主管時間、修正時間 | 如果摘要不可追溯，審核成本更高 |
如果這套流程每天跑 10 次還好；如果變成每位業務、每個客戶、每次追蹤都自動跑，Agent 就不再是小工具，而是一條新的營運產線。
這條產線必須有預算、品質門檻與停損線。
五種最容易放大算力的 Agent 設計
1. 沒有步數上限的任務
最危險的 Agent，不是笨，而是太努力。它查不到資料就重查，工具失敗就重試，輸出不滿意就自我修正，最後把一個低價值任務跑成高成本任務。
每個 Agent 任務都應該設定：
- 最大模型呼叫次數。
- 最大工具呼叫次數。
- 最大瀏覽器操作步數。
- 最大執行時間。
- 失敗後是否降級成草稿或交給人工。
沒有上限，就不要接正式流程。
2. 把所有工具一次打開
OWASP 對 LLM 應用的 excessive agency 風險提醒很實際：如果系統給模型過多功能、過大權限或過高自主性，就可能造成可靠性、隱私與信任問題。
企業常見錯誤是把 Agent 接上所有工具：讀文件、查 CRM、寄信、改表單、更新資料庫、跑瀏覽器、呼叫 API。看起來很強，實際上是把每個任務都變成高成本、高風險路線。
比較穩的做法是按任務開工具：
| 任務類型 | 可開工具 | 不該預設開放 |
|---|---|---|
| 研究摘要 | 搜尋、只讀知識庫 | 寄信、改 CRM、付款 |
| 客服草稿 | FAQ、訂單只讀、政策文件 | 退款、改地址、承諾補償 |
| 銷售追蹤 | CRM 只讀、草稿建立 | 自動寄信、改成交機率 |
| 報表整理 | 資料倉儲只讀、圖表生成 | 刪除資料、改正式指標 |
工具越多，成本越難估；權限越大，人工審核越不能省。
3. 每個問題都走最強模型
Agent 工作流裡不是每一步都需要最強模型。分類、去重、格式整理、欄位抽取、簡單摘要，可以先用較低成本路線；只有高價值判斷、複雜推理、對外輸出或例外情境，才升級到較強模型。
產品經理可以先把任務切成三層：
| 層級 | 適合處理 | 建議 |
|---|---|---|
| 低成本層 | 分類、格式、標籤、簡單摘要 | 優先用規則、小模型或批次處理 |
| 標準層 | 一般草稿、摘要、比對 | 設定固定提示詞與品質抽查 |
| 高價值層 | 商業判斷、客戶訊息、風險結論 | 限量使用，保留人工批准 |
省成本不是把所有模型降級，而是讓每一步用合適的能力。
4. 沒有快取與記憶邊界
Agent 常需要記憶，但記憶不是越多越好。
產品規格、FAQ、政策摘要、固定格式、客戶常見問題與內部 SOP，應該盡量做成可審核版本、可快取結果與可追溯來源。不要每次任務都重新讀一遍全部資料，也不要讓 Agent 把未審核的臨時輸出長期寫入記憶。
記憶要分三種：
- 可公開重用的穩定知識。
- 只在單次任務內使用的暫存上下文。
- 需要人工批准才可保存的長期記憶。
如果這三種混在一起，成本、品質與資料風險都會變得難管理。
5. 沒有 trace 的多代理流程
多代理不是問題，黑盒才是問題。
OpenAI、Google Cloud 與 Microsoft 的 Agent 文件都把 tracing、evaluation、monitoring 或 agent evaluation 視為正式工作流的重要能力。原因很簡單：當 Agent 出錯時，你不能只看到最後答案；你要知道它用了哪些工具、花了多久、哪一步重試、哪個資料來源造成錯誤、哪個模型或代理改變了結論。
沒有 trace 的 Agent 成本，就像沒有發票的採購。看似能工作，但出事時沒有人能追。
產品上線前的 Agent 預算表
把 Agent 放進產品或內部流程前，先不要急著寫完整架構。先填一張預算表。
| 問題 | 建議填法 |
|---|---|
| 這個 Agent 解決哪一個任務？ | 不要寫「提高效率」，要寫具體任務，例如整理客服退款原因 |
| 一次任務最多跑幾步？ | 模型、檢索、工具、瀏覽器、重試都分開算 |
| 每步最高可接受延遲是多少？ | 分清即時、準即時、批次 |
| 哪些步驟可以快取？ | FAQ、政策、產品資料、固定摘要 |
| 哪些步驟可降級？ | 高峰時改用草稿、批次、小模型或人工排隊 |
| 哪些工具必須人工批准？ | 寄信、付款、退款、改資料、對外發布 |
| 什麼情況必須停止？ | 資料不足、工具失敗、成本超標、信心不足、高風險關鍵字 |
| 每月如何回查？ | 成本、成功率、人工介入率、錯誤案例、客訴與停用紀錄 |
這張表不只是財務文件，也是產品規格。沒有它，工程團隊很難知道該做哪些限制；主管也很難判斷 Agent 是否值得擴大。
工具權限與人工批准怎麼設計
人工批准不是落後，也不是效率敵人。對 Agent 來說，它是責任邊界。
可以用五級權限設計：
| 等級 | Agent 可以做 | 例子 |
|---|---|---|
| 只讀 | 讀資料、摘要、分類 | 讀 FAQ、整理公司網站、摘要會議紀錄 |
| 草稿 | 產生建議但不送出 | 初信草稿、報表說明、客服回覆草稿 |
| 低風險寫入 | 寫入可回復的內部草稿 | 建立待辦、建立 CRM 備註草稿 |
| 批准後執行 | 人確認後才做 | 寄信、改商機、發布文章、更新公開頁 |
| 禁止自動化 | 不交給 Agent 獨立處理 | 付款、法律承諾、醫療財務建議、刪除重要資料 |
這張表的重點不是限制創新，而是讓每個流程知道「哪一步需要人」。
對企業來說，真正昂貴的不是多按一次確認，而是 Agent 在錯誤資料、錯誤工具或錯誤權限下完成了一個看似成功的任務。
把 Agent 從黑盒變成可營運系統
Agent 要進入正式營運，至少要能回答四個問題。
1. 它做了什麼？
記錄模型呼叫、工具呼叫、資料來源、重試、延遲與輸出版本。不是為了監控而監控，而是為了出錯時能復盤。
2. 它花了多少？
成本不能只看總帳單。要拆到任務、流程、部門或客戶類型。否則你只會知道 AI 很貴，但不知道哪個 Agent 在浪費。
3. 它有沒有改善結果？
看成功率、人工修正時間、一次完成率、錯誤案例、客訴、轉單率或內部工時。不要只用「看起來很聰明」當驗收。
4. 它失敗時怎麼停？
每個 Agent 都要有降級路線：改成草稿、轉人工、排程晚點跑、只做只讀摘要、停用工具或直接拒答。
真正成熟的 Agent 系統，不是永遠全自動，而是知道什麼時候該慢下來。
參考來源與資料時間
本文資料時間為 2026-08-23。以下來源用於理解 Agent 工具調用、電腦操作、追蹤、評估與風險治理方向：
- OpenAI Agents SDK
- OpenAI Evaluate agent workflows
- Anthropic Tool use with Claude
- Anthropic Computer use tool
- Google Cloud Gemini Enterprise Agent evaluation
- Microsoft Foundry agent tracing overview
- NIST AI Risk Management Framework
- OWASP LLM06:2025 Excessive Agency
本文提供企業 AI Agent 成本、權限、觀測與治理流程建議，不構成法律、資安、合規、採購、成本節省、模型品質、安全或商業結果承諾。平台功能、定價、資料保存、工具權限、追蹤與評估能力，應以各官方最新文件與企業內部審查為準。
常見問題
AI Agent 一定比一般聊天模型貴嗎？
不一定。單一步驟可能不貴，但 Agent 常把任務拆成多步，還會呼叫工具、檢索資料、重試與留下紀錄。真正要估的是整個任務成本，不是單次回答成本。
企業應該禁止員工使用 Agent 嗎？
不需要一刀切。比較務實的做法是先允許只讀與草稿任務，再逐步開放低風險寫入；對外寄送、付款、退款、法律承諾、敏感資料處理與正式系統變更，都應保留人工批准。
多代理流程是不是一定比較好？
不是。多代理適合任務需要不同角色、資料來源或審核步驟時使用。如果單一流程就能完成，不必為了看起來先進而增加代理數量。每多一個代理，就多一層成本、延遲與追蹤需求。
要先做完整 LLMOps 才能上 Agent 嗎？
早期不一定需要完整平台，但至少要有任務紀錄、工具紀錄、成本紀錄、錯誤紀錄與人工批准紀錄。當 Agent 進入客戶流程、營收流程或正式資料寫入，就應導入更完整的 trace、eval 與監控。
如何判斷 Agent 是否值得擴大？
不要只看它能不能完成一次 demo。應看每月任務量、成功率、人工修正時間、錯誤案例、成本上限、客戶或內部滿意度，以及失敗時是否能快速停用或降級。
延伸閱讀
- 真正昂貴的是算力：AI 越便宜，GPU 需求反而越大
- Hermes Agent 導入前的安全清單：哪些任務可以放手，哪些一定要人工批准
- 如何評選 AI Agent 平台？從工作流自動化到企業級 Agent 編排
想把 AI Agent 放進真實工作流，先不要追求全自動。可以從 FlyPig AI 未來領航者 回到主題地圖，先選一條低風險、可衡量、可人工批准的流程開始。