企業 AI Agent 廠商怎麼選？RFP、PoC 與供應商評估清單

企業找 AI Agent 廠商，最容易出錯的地方是拿不同公司的 Demo、模型名稱與報價直接比較。這些資料可以參考，但不足以回答哪一家真的能接手公司的工作。

比較有效的方法，是先把一條真實工作寫成 RFP，再要求不同供應商使用相同資料、相同權限與相同驗收條件完成 PoC。最後比較的應該是工作結果、風險、人工負擔、總成本與能否移交，而不是誰的展示最流暢。

重點快讀

RFP 先寫業務問題、輸入、輸出與成功條件，再談模型和技術。
資料、身份、權限、Audit、重大錯誤處理應設成必要條件，不能全部混進平均分數。
不同供應商最好使用同一組代表性案例做 PoC。
採購成本要計入模型、工具、整合、人工覆核、維運、重試與退出。
合約應先寫清楚資料、Workflow、程式碼、Evaluation Set、Logs 與移交權利。

已經決定委外，才進入這份評選

企業在找廠商以前，先確認一件事：公司是真的需要委外、購買平台或找顧問，還是目前連流程都還沒有整理完成。

如果還在考慮 SaaS、自建、Managed Platform 或外包，先看站內的 AI Agent 自建還是委外？中小企業 7 個判斷點與試點路徑。

這一頁從下一個階段開始：

已決定找外部方案
↓
寫 Requirement
↓
發 RFP / 詢價
↓
Vendor Shortlist
↓
Security / Data Review
↓
PoC
↓
Scorecard
↓
Commercial Review
↓
Contract
↓
Limited Production

RFP 的功能，是讓所有供應商回答同一個問題。

RFP 第一頁先寫業務問題

不要用：

我們想導入最先進的 AI Agent。

應該改成：

公司每月收到約 1,000 件詢價 Email，目前由業務人工讀取內容與附件、確認品項與缺失資料，再建立報價草稿。第一階段希望 Agent 完成資料擷取、缺件辨識與草稿產生；正式價格與寄送仍由業務人員批准。

這段會直接決定後面的技術、資料與驗收方式。

至少寫清楚：

欄位	企業需要提供什麼
Current Process	現在怎麼完成工作
Volume	每天／每月多少件
Input	Email、PDF、CRM、Excel 等
Output	最後要得到什麼
Owner	誰對結果負責
Allowed Actions	Agent 可以做什麼
Forbidden Actions	哪些事情不能做
Success	什麼情況算完成
Baseline	現在人要花多少時間與成本

如果這些內容都還無法回答，發 RFP 後收到的通常會是一堆互相無法比較的技術方案。

AI Agent RFP 至少要有八個區塊

1. Business Scope：到底要完成哪一件工作？

要求供應商說明：

哪一段適合使用 Agent；
哪一段會使用固定 Workflow；
哪些步驟仍建議人工處理；
有哪些已知限制；
第一階段不會處理哪些情境。

這可以快速看出供應商是在解決業務流程，還是只想把所有問題包成模型呼叫。

2. Data：資料會去哪裡？

這一部分不要只問「資料安全嗎？」

要問具體問題：

會讀哪些公司資料？
資料在哪個地區處理？
資料會保存多久？
Logs 保存哪些內容？
Prompt、附件與 Tool Output 是否保存？
資料是否會用於模型訓練？
Subprocessor 有哪些？
合約終止後多久刪除資料？
能否提供刪除或匯出證據？
測試環境可以使用去識別或 synthetic data 嗎？

如果涉及個資、財務、醫療、客戶機密或受管制資料，再依企業所在產業增加對應要求。

3. Identity 與 Permission：Agent 代表誰做事？

Agent 一旦可以呼叫 Email、CRM、ERP 或其他企業系統，身份就成為採購問題。

RFP 應要求供應商說明：

User
↓
Agent Identity
↓
Permission
↓
Tool
↓
Action
↓
Audit

至少確認：

Agent 是否有自己的身份；
是否使用共用帳號；
是否能做 least privilege；
Token 是否能過期與撤銷；
不同 Tool 能否分別限制權限；
高風險動作能否要求人工批准；
誰可以修改 Agent 權限；
權限改變是否留下紀錄。

對可以寫入企業系統的 Agent，這一項應比「使用哪個模型」更早驗收。

4. Integration：不要只問「支援 CRM 嗎？」

「可以串 Salesforce」、「可以串 Gmail」還不是完整答案。

應要求說明：

用官方 API、MCP、Browser Automation 或其他方式；
Authentication 如何處理；
Rate Limit 怎麼處理；
API Timeout 怎麼處理；
Schema 改變怎麼處理；
Retry 是否可能造成重複副作用；
寫入成功後是否重新 Read-back；
Connector 由誰維護；
API 更新後的維修責任屬於誰。

例如 Agent 執行：

create_order()

API 回傳成功，不應立即把工作標記成 PASS。

更穩定的流程是：

create_order()
↓
API Response
↓
重新讀取 Order
↓
比對 ID / 金額 / 狀態
↓
PASS

這類能力很難從一般 Demo 看出來。

如果要深入比較 Runtime、IAM、Sandbox、Evals 與可攜性，可以另外看企業 Agent Platform 怎麼選？

5. Evaluation：要求供應商說清楚怎麼證明 Agent 有用

不要接受：

準確率可達 95%。

先問 95% 的分母是什麼。

更有效的要求包括：

Evaluation Set 有多少種類型；
是否使用公司真實案例；
正常案例怎麼測；
缺件怎麼測；
模糊輸入怎麼測；
Tool Failure 怎麼測；
Prompt Injection 怎麼測；
高風險要求怎麼測；
同一案例是否重複執行；
模型或 Prompt 更新後是否跑 Regression；
Test Results 公司能不能取得。

最有價值的是要求供應商在 同一組企業案例 上交付結果。

這樣 A、B、C 三家公司才能真正比較。

6. Operations：上線之後誰負責？

PoC 可以由一位工程師照顧，Production 不行。

RFP 至少要問：

問題	需要的答案
服務故障	誰接手
Model API 故障	有沒有 fallback
Tool 故障	Retry 或轉人工
Agent 異常	怎麼停用
重大錯誤	Incident 流程
Logs	保存與查詢方式
Monitoring	看哪些指標
版本更新	誰批准
SLA	回應與恢復承諾
Owner	供應商與企業各是誰

正式 Agent 還需要清楚的停止方式。

企業應該知道：

如果今天下午 Agent 開始做錯事，我們可以在幾分鐘內停止哪一部分？

7. Commercial：比較 TCO，不只比較建置費

假設兩家廠商：

A：建置 NT$200,000
B：建置 NT$400,000

不能直接判斷 A 比較便宜。

還要加上：

Initial Build
+
License
+
Model
+
Tools
+
Infrastructure
+
Integration
+
Human Review
+
Support
+
Maintenance
+
Retry / Failure
+
Change Request
+
Exit Cost

RFP 可以要求供應商提供三種使用量情境：

Low Volume；
Expected Volume；
High Volume。

這樣比較容易發現 Token、API、Automation Run、Seat、Storage 或 Outcome 費用在規模擴大後會不會突然上升。

需要進一步計算預算，可以搭配 AI Agent 導入費用怎麼算？

8. Exit：合約還沒簽，就要先問怎麼離開

AI Agent 很容易形成平台與供應商鎖定。

至少要求回答：

公司資料可以完整匯出嗎？
Prompt／Instructions 可以取得嗎？
Workflow configuration 可以匯出嗎？
Tool Schema 屬於誰？
Evaluation Set 屬於誰？
Logs 能否取得？
客製程式碼屬於誰？
API 帳號由誰持有？
文件與 Runbook 是否交付？
合約終止後資料如何刪除？
新供應商是否能接手？

「我們可以協助移轉」不是完整答案。

應該要求交付格式、期限、費用與責任。

先設 Hard Gate，再做供應商打分

有些條件不適合用「總分高就算了」。

例如某供應商：

模型能力    95
介面        95
價格        90
資料控制     20

平均仍可能看起來不錯。

但如果公司的客戶資料不能符合該方案的處理條件，就應先淘汰。

適合作為 Hard Gate 的項目包括：

Gate	未通過時
必要資料條件	不進 PoC
身份與權限不可控制	不進 Production
高風險寫入沒有 Approval	不進 Production
無法取得必要 Audit Evidence	不進 Production
無法說明資料刪除	不簽長約
核心資產無法移交	重新談合約
Critical Error 無法停止	不擴大

通過必要條件後，再做加權評分。

一份 100 分供應商 Scorecard 範例

以下權重是 YOLO LAB 的採購示意，不是產業標準。企業應依流程風險自行調整。

評估面向	示例權重
Business Fit	20
Data / Security / Permission	20
Evaluation / Reliability	15
Integration / Tool Execution	15
Operations / SLA	10
TCO / Commercial	10
Portability / Exit	10
合計	100

這樣可以避免一個常見現象：

業務主管喜歡 A 的 Demo、工程師喜歡 B 的 API、採購喜歡 C 的價格，最後沒有人使用同一把尺。

PoC 不要讓每家廠商自己選題目

比較三家廠商時，最好提供同樣的：

需求；
Sample Data；
Tool；
權限；
測試案例；
Success Criteria；
Time Window。

例如準備 50 個詢價案例：

35 個正常案例
+
5 個格式變化
+
5 個缺件／矛盾
+
5 個高風險／超出範圍

50 只是示意，不是標準數量。

真正重要的是案例能覆蓋實際工作。

評估時至少留下：

Task
Vendor
Version
Output
Tools Used
Pass / Fail
Human Edit
Latency
Cost
Error Type
Evidence

最後比較的是證據，不是 Sales Presentation。

Demo 很漂亮，仍然要故意讓它失敗

PoC 至少應測：

工具逾時

CRM API 不回應時，Agent 會重試、停止還是亂猜？

權限不足

如果 Agent 沒有修改價格的權限，會停止還是換其他方式繞過？

資料矛盾

Email 和附件價格不同時，會選一個還是交給人？

部分成功

CRM 已更新，但網路在 Response 前中斷。

系統會不會再更新一次？

Prompt Injection

Agent 讀到外部 Email 或網頁中要求忽略公司規則的內容，會發生什麼？

這些測試通常比再跑十個正常案例更能區分供應商能力。

合約驗收不要只寫「系統完成」

比較清楚的方式是拆成 Milestone。

例如：

M1
Current Workflow + Requirement

M2
Data / Permission / Architecture

M3
Prototype

M4
Evaluation Report

M5
Shadow Mode

M6
Acceptance

M7
Handover

每個 Milestone 都寫明：

Deliverable；
Owner；
Due Date；
Acceptance Criteria；
不通過如何修正；
最多幾輪；
誰有權簽收。

這會比合約最後只寫「AI Agent 系統一套」更容易管理。

台灣企業可以借用政府資訊採購的哪個概念？

台灣政府軟體採購流程把資訊服務分成規格制定、資格與服務方案評選、決標與履約管理等階段。

私人企業不需要照搬政府採購程序，但這個拆法很有用：

規格
↓
資格
↓
方案
↓
評選
↓
履約

AI 專案特別適合把「供應商有沒有資格做」和「哪個方案最好」分開。

例如：

資格層

是否符合公司的資料要求；
是否能接受必要資安條款；
是否提供企業需要的 Audit；
是否願意接受退出與移交條件。

方案層

才比較：

完成率；
人工時間；
整合方式；
使用體驗；
TCO；
擴充能力。

這能降低「最會提案的廠商」直接勝出的風險。

RFP 評選至少要有哪些人？

只由 IT 評選不夠，只由業務評選也不夠。

至少需要五種責任：

角色	負責判斷
Business Owner	工作是否真的改善
IT / Architecture	整合與維運是否成立
Security / Privacy	資料與權限
Procurement / Finance	價格、TCO、合約
Actual Users	人工接手與實際可用性

若流程涉及法規、高風險決策或重要客戶承諾，再加入 Legal／Compliance。

最後一定要有一位具名 Sponsor 負責 Go／Stop。

七個供應商紅旗

只談模型，不問工作

沒有先問輸入、輸出、頻率、Owner 與成功條件。

只展示成功案例

沒有 Error Taxonomy，也不願意測失敗案例。

成功率沒有分母

宣稱 95%，卻無法說明 Dataset 與 Pass Criteria。

Logs 無法交付

供應商自己能看到，但企業無法取得足夠的 Trace 或 Audit。

直接要求正式權限

還沒完成 PoC 就要求 Production Token、完整 CRM 或管理員帳號。

Exit Plan 很模糊

只能回答「日後可以協助」。

所有問題都靠 Change Request

初始報價看起來便宜，但資料調整、API 更新、模型替換、測試與維運全部另外計費。

這些問題通常比哪一家用了最新模型更能預測專案後續成本。

最後怎麼決定？

供應商評選可以依序做五個決策：

1. Requirement Fit
↓
2. Hard Gate
↓
3. PoC Evidence
↓
4. TCO + Contract
↓
5. Exit / Handover

只要其中一個必要 Gate 沒過，就先解決那個問題。

三家公司都能通過必要條件時，才使用 Scorecard 比較商業價值。

這樣得到的決策會比「我們覺得 A 的 Agent 比較聰明」更容易在半年後被驗證。

常見問題

AI Agent RFP 一定要很長嗎？

不用。小型 PoC 可以先用幾頁清楚寫完問題、資料、權限、測試、交付物與成本。文件長度不是重點，可比較性才是。

找 AI Agent 公司前一定要先有 PoC 嗎？

不用。供應商可以協助建立 PoC，但公司至少要提供自己的業務問題與成功條件。否則 PoC 很容易變成供應商自己的 Demo。

最便宜的方案可以先試嗎？

可以，但要使用相同驗收條件。初始建置費低，不代表 Cost per Verified Task 或長期 TCO 最低。

可以要求供應商保證 100% 正確嗎？

對多數含模型判斷的 Agent，這通常不是實際的驗收方式。更適合定義哪些錯誤必須為零、哪些可以轉人工，以及其他品質與效率指標需要達到多少。

下一步

如果還沒決定要自建、買平台或委外，先看 AI Agent 自建還是委外？

如果正在比較底層 Agent Platform，再看企業 Agent Platform 怎麼選？

如果已經找到候選供應商，下一步應該把一條真實工作、Baseline 與 Test Set 準備好，再進入 AI Agent 導入流程：7 步驟與 30 天試點。

如果公司還缺少 Requirement、資料盤點與驗收條件，可以先透過 YOLO LAB 的 AI Agent 導入評估，把工作流程整理成可詢價、可 PoC、可驗收的需求，再決定是否進入正式建置。

主要資料來源

UK Government：Guidelines for AI procurement
UK Government：Artificial Intelligence Playbook for the UK Government
Microsoft Learn：Govern agents by risk
Microsoft Learn：Secure agents: Identity, access, and data protection
NIST：AI Risk Management Framework — Generative AI Profile
數位產業署政府軟體採購網：資訊服務採購與資安要求