打造自我品管的 AI 承包商：評估與監測

若把公司的契約和信用卡以及客戶資料庫的最高權限交給一個 AI 代理，指令非常明確：幫高階主管預訂下週去巴黎的機票跟飯店。聽起來是很單純的商務需求。但幾天之後收到帳單，發現它不止花了十萬美金訂了頭等艙，還買了一大堆巴黎米其林餐廳的餐券。為什麼？因為主管在出發前只是隨口問了一句「巴黎現在天氣如何，適合在戶外用餐嗎？」AI 就過度解讀，自己腦補了一整趟奢華旅程。

這不是科幻電影的劇情，這是把 AI 投入實際工作時最真實的風險。過去的軟體只要輸入 A 就一定產出 B；現在的 AI 建構在機率之上，給它相同的指令，它可能回給我們十種完全不同但看似都合理的執行方式，甚至產生幻覺。當 AI 從單純的聊天機器人進化成能自主執行複雜任務的智慧代理時，我們到底該用什麼科學方法來驗證它？怎麼分辨它說的是實話還是亂編的？

本文探討評估與監測（Evaluation & Monitoring）——如何測試一個不像傳統電腦那樣死板運算、而是會像人類一樣去猜測跟推理的數位員工，並把這套監測機制內化成 AI 自身的品管紀律。

傳統測試的盲點：閱卷老師看不懂同義句

過往測試軟體像是在改數學考卷，對就是對，錯就是錯，非常精準。但面對 AI，這張考卷變成了一道申論題。為什麼傳統的測試方法在這裡會完全失效？因為傳統測試要的是精確匹配（exact match），這套標準碰到 AI 反而會誤判一堆明明正確的答案。

用實際場景來說明。假設我們想測試一個地理知識的 AI，預先設定的標準答案（基準真相）是「巴黎是法國的首都」。AI 回答「法國的首都是巴黎」，意思完全一樣，人類閱卷會給滿分。但如果用傳統軟體測試最愛用的字串比對技術，系統會發現字不一樣——就算移除所有的空格、把英文字母都轉成小寫，系統還是無情地給它零分。

用程式碼來呈現，這是一個非常基礎的evaluateResponseAccuracy：

// 基礎的精確比對：兩串文字逐字比對，完全相同才給 1 分
function evaluateResponseAccuracy(agentOutput: string, expectedOutput: string): number {
  const normalizedAgent = agentOutput.trim().toLowerCase()
  const normalizedExpected = expectedOutput.trim().toLowerCase()
  return normalizedAgent === normalizedExpected ? 1.0 : 0.0
}

const agentResponse = 'The capital of France is Paris.'
const groundTruth = 'Paris is the capital of France.'
const score = evaluateResponseAccuracy(agentResponse, groundTruth)

console.log(`Response accuracy: ${score}`) // 0，兩句話意思一樣卻被判零分

這就像一個不知變通的機器人閱卷老師，只要學生的造句跟解答本差一個字就全錯。但這種方式根本無法評估 AI 到底有沒有聽懂我們的問題。這就是評估 AI 的第一個重要認知翻轉：不能再做字串比對，必須評估語義相似性（semantic similarity）。

要評估語義，必須引入更先進的自然語言處理技術。舉例來說，我們會利用嵌入模型（embedding model），把文字轉換成高維度空間裡的數學座標，然後計算這兩個座標之間的距離——也就是餘弦相似度（cosine similarity）。如果距離很近，系統就能理解這兩句話的意思其實是一樣的：

文字 → 嵌入模型 → 高維度數學座標 → 算餘弦相似度 → 意思近不近

語義相似的兩句話 ──→ 嵌入後座標很接近
"巴黎是法國的首都"  →  [0.12, -0.53, 0.98, ...]
"法國的首都是巴黎"  →  [0.10, -0.51, 0.97, ...]   ← cos θ ≈ 0.98（很近，同一件事）

語義不同的兩句話 ──→ 嵌入後座標差很遠
"巴黎是法國的首都"  →  [0.12, -0.53, 0.98, ...]
"法國的首都是東京"  →  [-0.41, 0.72, -0.15, ...]  ← cos θ ≈ 0.31（很遠，胡說八道）

這等於讓那個只會逐字比對的閱卷老師，終於搞懂文字背後的意思。

過程比結果更重要：追蹤代理軌跡

只有語義判斷還不夠，因為這裡隱藏著一個漏洞：就算最後答案對了，我們怎麼確定 AI 是真的會，而不是剛好矇對？就像考數學，光是答案正確不代表理解正確——如果解題過程全靠猜，題目只要稍微變化，它馬上就會露出破綻。

這正是評估 AI 代理的一個核心概念：代理軌跡（agent trajectory）。在 AI 代理的世界裡，過程比結果更重要，我們必須追蹤它為了解決問題一路上採取的步驟序列。具體上要怎麼追蹤？用一個明確的指令來舉例：

要求 AI 擲兩次十面骰子，然後檢查兩次加起來的總和是不是質數。

一個設計良好的測試框架不會只看最後 AI 有沒有告訴我們「是」或「不是」，它會嚴格去檢查系統日誌：

也就是說，我們不只要看它「說了什麼」，還要看它「做了什麼動作」。把代理的實際行動跟預期的理想軌跡比對，可以找出錯誤跟沒效率的地方。比對的方法有好幾種，依任務的風險程度選擇：

以兩次擲骰子為例，理想軌跡是 roll_die → roll_die → check_prime → 回答。除了呼叫次數，參數也要比對——兩次的參數（骰子面數）應該一致，如果第二次 roll_die 偷偷換了不同面數的骰子，回傳的總和基準就不一樣，軌跡比對照樣抓得到。如果 AI 只呼叫了一次 roll_die 就直接回答「是」，那就是偷工減料，軌跡比對立刻抓包。

Token 是現金，延遲是流失率

追蹤軌跡聽起來很像我們在微管理一位數位員工，連它思考幾秒鐘都要管，這樣不會讓整個系統的運算負擔變得太重、甚至矯枉過正嗎？乍聽之下是有一點，但這正是最值得注意的地方。

如果我們了解大型語言模型的運作機制，就會知道這絕對是攸關生死的財務管理。在 AI 的世界裡，token 就是白花花的現金，延遲時間直接等於使用者流失率。因為每一次呼叫模型的 API 都是按字數計費的。所以追蹤軌跡不僅僅是為了找 bug，更是為了找出哪裡有效率可以提升。

舉例來說，如果我們發現一個 AI 為了解決一個超簡單的客服問題，因為提示詞沒寫好，就在後台反覆呼叫資料庫十幾次，浪費了幾萬個 token 才得出一個答案——對公司來說這就是巨大的成本黑洞。透過監控工具，工程師就能立刻介入優化它的思考路徑。

在實務上，記錄工具可以用結構化日誌檔案（JSON）、時間序列資料庫（InfluxDB、Prometheus）、資料倉儲（Snowflake、BigQuery、PostgreSQL），或是可觀測性平台（Datadog、Splunk、Grafana Cloud）。下面是一個追蹤 token 用量的 TypeScript 概念範例（實際的 token 計數要改用各 LLM API 的計數器）：

// 概念示意：記錄每一次 LLM 互動的 token 用量
class LLMInteractionMonitor {
  totalInputTokens = 0
  totalOutputTokens = 0

  recordInteraction(prompt: string, response: string): void {
    // 真實情境請改用 LLM API 的 token 計數器或 tokenizer
    const inputTokens = prompt.split(/\s+/).length
    const outputTokens = response.split(/\s+/).length
    this.totalInputTokens += inputTokens
    this.totalOutputTokens += outputTokens
    console.log(`Recorded interaction: Input=${inputTokens}, Output=${outputTokens}`)
  }

  getTotalTokens(): { input: number; output: number } {
    return { input: this.totalInputTokens, output: this.totalOutputTokens }
  }
}

const monitor = new LLMInteractionMonitor()
monitor.recordInteraction('What is the capital of France?', 'The capital of France is Paris.')
monitor.recordInteraction('Tell me a joke.', "Why don't scientists trust atoms? Because they make up everything!")
const { input, output } = monitor.getTotalTokens()
console.log(`Total input tokens: ${input}, Total output tokens: ${output}`)

這不是在為難員工，這是在看緊錢包。追蹤這些數據，除了管理成本，還能幫助我們發現提示工程或回應產出過程中需要改進的地方。

主觀品質怎麼評？讓 AI 當裁判

客觀的步驟跟成本我們理解了，但如果是比較主觀的品質呢？譬如我們要求客服 AI 的語氣必須是「中立且有幫助的」。這種東西沒有標準答案、也沒有工具呼叫的軌跡可以看，總不能用計算機去算語氣好不好吧？

這就進入目前 AI 評估領域最前沿、也最實用的框架：讓 AI 當裁判（LLM-as-a-Judge）。讓 AI 去幫另一個 AI 打分數，聽起來難道不會有球員兼裁判的問題、偏袒自己的同類嗎？其實不會，只要把裁判的角色定義得夠嚴謹。

開發者可利用像是 Gemini 這種極度強大的模型，專門寫一套框架讓它扮演法官。舉例來說，法官被賦予一份非常詳細的評分指南，規定五個維度，例如清晰度與精確性、中立性與偏見、相關性與焦點、完整性、對受眾的適合度。它不是隨便給個讚或倒讚，而是有一套嚴格的評分標準：

對於每一個維度，法官必須給出一到五分的評分。而且更關鍵的是，它不能只給數字，必須在輸出的檔案裡用文字詳細說明為什麼給這個分數、寫評語、指出被評估的 AI 哪裡可以做得更好。用 Google GenAI 的 TypeScript SDK 寫出來大致是這樣：

import { GoogleGenAI } from '@google/genai'

const CUSTOMER_SERVICE_RUBRIC = `
You are an expert in customer service quality and a critical communication reviewer.
Evaluate the quality of a given customer service response. Provide a score from 1 to 5
for overall quality, along with a detailed rationale and specific feedback.

Focus on the following criteria:
1. Clarity & Precision (1-5)
2. Neutrality & Bias (1-5)
3. Relevance & Focus (1-5)
4. Completeness (1-5)
5. Appropriateness for Audience (1-5)

Your response MUST be a JSON object with the keys:
- overall_score: integer from 1 to 5
- rationale: concise summary of why this score was given
- detailed_feedback: bullet-point list of feedback for each criterion
- concerns: list of specific tone, empathy, or clarity concerns
- recommended_action: brief recommendation (e.g. "Rephrase to stay neutral")
`

const genai = new GoogleGenAI({ apiKey: process.env.GOOGLE_API_KEY })

async function judgeCustomerServiceTone(agentResponse: string): Promise<unknown | null> {
  const prompt = `${CUSTOMER_SERVICE_RUBRIC}\n\n---\nCUSTOMER SERVICE RESPONSE TO EVALUATE:\n${agentResponse}\n---`

  try {
    const response = await genai.models.generateContent({
      model: 'gemini-2.0-flash',
      contents: prompt,
      config: {
        temperature: 0.2, // 評分要求確定性，溫度要低
        responseMimeType: 'application/json',
      },
    })
    return JSON.parse(response.text ?? '')
  } catch (error) {
    console.error(`An error occurred during LLM judgment: ${error}`)
    return null
  }
}

const goodResponse = `
I understand your concern about the delayed delivery. While I can't share the
exact tracking details right now, I can check with our logistics team and get
back to you within 30 minutes with an update.
`
const judgment = await judgeCustomerServiceTone(goodResponse)
console.log(JSON.stringify(judgment, null, 2))

有人會問：把這個工作交給人類，不是比 AI 裁判更會捕捉語氣這種主觀的東西嗎？這其實是成本與規模的權衡。人類確實能捕捉到最細微的語氣和潛台詞，但我們不可能請一百個人類每天去評估系統產生的億萬筆客戶對話，那太貴也太慢了。傳統的自動化指標雖然快，但就像前面說的，它只看字面、不懂語氣。AI 裁判剛好是完美的折中方案——有接近人類的語義理解能力，同時又具備機器的可擴充性跟一致性。

三種評估方法各有優劣：

多代理系統：評估一個跨部門團隊

難度再往上拉一層：現在業界很流行多代理系統，不是只有一個 AI 在工作，而是一群 AI 互相合作。如果要評估一群 AI 該怎麼辦？

把多代理系統想成是評估一個公司的跨部門專案團隊，評估的焦點就從單一員工的個人績效，轉移到整個團隊的溝通與協作效率。延續一開始的旅行規劃場景，有幾個關鍵問題：

任務分派的失誤特別值得注意。使用者只是隨口問一句天氣，如果這個多代理系統的總機不能聰明地把問題發包給專業的天氣代理，反而找了個不懂的工具來頂替，回給使用者一句沒用的話——這就是在考驗整個系統架構的智慧。而擴充系統也不一定是加分項。加入更多代理看似能力更完整，但如果協作設計沒做好，大家在互相等待資料，原本一秒鐘能完成的事反而變慢，這就是可擴充性出了問題。這確實是從「評估一個打工仔」進化到「評估整間公司的營運」了。

從被動盯梢到自我品管：AI 承包商模型

從字串比對的失敗、追蹤每一秒的軌跡、請 AI 當裁判盯著，再加上解決跨部門溝通的問題——我們做了很多防護，卻也透露出一件事：對 AI 的信任很薄弱。這些評估與監控都是在補一個本質上充滿不確定性的系統漏洞，我們一直在用傳統軟體工程的思維，試圖馴服一個機率性的怪獸。與其繼續在外面層層包裝，不如換個思路：AI 必須從一個可能會出錯、需要我們無時無刻盯著的代理（agent），進化成一個有嚴格紀律、對結果負責的承包商（contractor）。兩者最大的差別在於確定性。

拿傳統的代理來比，我們丟一句模糊的提示詞，像是「幫我整理一份銷售報告」，剩下的就只能祈禱它別亂編。但承包商模型換了一套規則，我們給的不再是提示詞，而是一份形式化合約（formal contract），像規格書一樣明確：「我需要一份 PDF 報告，分析今年第一季歐洲市場，必須包含五個視覺化圖表，資料來源只能使用公司內部的 A 庫和 B 庫」。

這個模型的信任基礎建立在四個關鍵機制上：

關鍵一：形式化合約

合約不是一句「分析上一季的銷售額」，而是「一份 20 頁的 PDF 報告，分析 2025 年第一季歐洲市場銷售情況，包括五個具體的資料視覺化、與 2024 年第一季的比較分析、以及基於所附供應鏈中斷資料集的風險評估」。合約明確定義了需要交付的成果、精確規格、可接受的資料來源、工作範圍，甚至可驗證的計算結果。

關鍵二：談判機制

如果合約這麼嚴格，但公司內部資料庫剛好缺了歐洲市場的資料呢？按照現在 AI 的習性，為了達成任務，它肯定會偷上網亂抓資料，甚至直接產生幻覺、憑空編出一份資料給我們，這樣是不是很可怕？

這正是承包商模型最厲害的地方——它引入了談判機制。如果是一個真正的 AI 承包商，當它發現資料庫裡沒有足夠的資料來履行合約時，它不會硬著頭皮亂編，而是會主動終止任務、把合約退回，明確指出：「你沒有給我歐洲市場的許可權，我無法達到合約要求的精準度，請提供資料或修改合約條件」。

合約需求：分析歐洲市場 Q1 銷售
   │
   ▼
承包商檢查資料來源
   │
   ├─ 資料足夠 → 開始執行合約
   │
   └─ 資料不足 → 終止任務、退回合約
         │
         └─ 「請提供歐洲市場資料，或修改合約條件」

一個會主動說「我做不到，請給我更多資源」的 AI，比一個會亂交報告的 AI 讓人安心太多了。這就是信任的基礎。

關鍵三：以品質為中心的迭代

當承包商真的拿到資料開始工作後，它怎麼確保品質？就算人類承包商也會交出有 bug 的東西。過去的 AI 追求的是兩秒鐘內給出一個答案，但承包商 AI 追求的是合約上的滿分。如果合約是寫一段程式碼，這個 AI 在寫完之後不會馬上交卷，它會自己在背景寫測試程式、自己編譯、自己去跑安全漏洞檢查，自己當自己的 QA。如果跑出來只有八十分，它會把錯誤日誌吃進去、重新修改程式碼、再跑一次測試。這個迴圈可能在極短的時間內發生無數次，直到系統確認達到合約規定的一百分，它才會把最終成品交到我們手上：

寫程式碼 → 自己寫測試 → 自己編譯 → 跑安全檢查
   ↑                              │
   └──── 80 分：吃進錯誤日誌 ←────┤
                                  │ 100 分
                                  ▼
                              交付成品

把前面提到的評估與監測機制，全部內化成它自己的品管部門——這就是「自我品管」的意義。

關鍵四：分包分解

面對超大型的專案呢？例如我們不是要一段程式碼，而是要一個完整的電商 App。主 AI 承包商會把「做一個 App」這個大合約拆分成很多子合約，發包給專門處理視覺的 AI 代理畫介面、發包給資料庫 AI 建置後台、再發包給安全 AI 檢查漏洞：

主合約：建立電子商務行動應用程式
   │
   ├── 子合約 1：設計 UI/UX       → 視覺 AI 代理
   ├── 子合約 2：開發使用者驗證模組  → 認證 AI 代理
   ├── 子合約 3：建立產品資料庫模式  → 資料庫 AI 代理
   └── 子合約 4：整合支付閘道       → 支付 AI 代理

每個分包合約都有自己的可交付成果、規格與獨立驗收標準

每一個分包合約都是完整、獨立的合約，有自己獨立的驗收標準跟談判過程。這種結構化分解讓系統能以高度組織化、可擴充的方式處理巨大的多面向專案。

這些願景真的做得出來嗎：Google ADK 已經在做了

看到這裡或許會覺得這個願景太美好，像是科幻小說的情節。但這些不只在紙上畫畫，而是真的已經有人在做了。放眼整個 AI 工具生態，像是 Google ADK（Agent Development Kit）這類工具，它們已經在做這件事了。它們不是把 AI 當成某種神奇的黑盒子，而是把 AI 的測試直接整合進傳統軟體工程的流程裡。例如透過整合 pytest 這樣的測試框架，AI 的表現就可以像傳統程式碼一樣，在自動化管道中被持續驗證。

Google ADK 的評估支援有三種方式：

ADK 用測試檔（test file）與評估集檔（eval set file）兩種結構來描述期望的代理行為。測試檔是單一、簡單的代理互動或會話，適合開發期間的單元測試；評估集檔則包含多個可能很長的會話，適合模擬複雜的多輪對話與整合測試。

以測試檔為例，它記錄了使用者要求「關閉臥室中的 device_2」，指定代理必須使用 set_device_info 工具、帶上 location: 臥室、device_id: device_2、status: OFF 等參數，以及預期的最終回應「我已將 device_2 狀態關閉」。這跟我們前面講的代理軌跡比對是同一件事，只是被框架化、標準化了。

透過這些工具，AI 開發終於告別了靠運氣的試錯，真正變成一門嚴謹的工程學科。AI 正在脫胎換骨——從一個隨時可能出包的不穩定助手，轉變成能處理關鍵任務、具有高度責任感的員工，而且它的每一個決策步驟都可以被稽核與驗證。

對 UI/UX 的影響：評估數據怎麼變成使用者看得懂的介面

評估與監測系統看起來是後端的事，但它對使用者體驗的影響其實非常深遠，至少有三個層面：

第一個層面：使用者看到「品質」而不是「錯誤」。 當代理的產出被 AI 法官或軌跡比對判定不合格時，最糟糕的 UX 是把失敗細節丟給使用者。如果使用者訂機票，看到後端吐出一堆「trajectory mismatch」的技術錯誤，體驗就是災難。好的作法是後端吞下失敗，前端只呈現「重新嘗試」或「改用替代方案」的流暢提示。

第二個層面：評估結果變成可視化面板。 對內部使用者（工程師、產品經理）來說，評估的價值要能被「看見」。一個好的評估儀表板應該展示：

┌─────────────────────────────────────┐
│ 代理評估儀表板  (2026-08-16)          │
├─────────────────────────────────────┤
│  通過率  87%   平均延遲  120ms        │
│  今日 token  3.2M    警報  ⚠ 2 ▾詳情 │
├─────────────────────────────────────┤
│  最近失敗軌跡                         │
│  ┌─────────────────────────────────┐│
│  │ ✗ 航班預訂 → 飯店交接 (6 分鐘前) ││
│  │   hop1: roll_die ✓              ││
│  │   hop2: set_hotel ✗ month=7     ││
│  │   [查看完整軌跡] [一鍵重試]      ││
│  └─────────────────────────────────┘│
└─────────────────────────────────────┘

第三個層面：承包商模式的談判需要介面。 當承包商因為缺資料而退回合約時，使用者需要一個清楚的畫面了解「為什麼被退回、缺了什麼、可以怎麼補」，而不是收到一封拒絕信。這跟護欄被觸發時的 UX 原則是一樣的——把「被拒絕」轉譯成「導向」。護欄與評估雖然是兩個主題，但使用者體驗原則相通，可參考這篇文章-AI 代理的安全煞車：Guardrails 護欄與安全模式。

前後端技術怎麼實作

對應到這些 UI/UX 的影響，前後端有一條清晰的分工線：

後端：把評估管線做成服務

• 提供統一的評估服務，接收代理的輸出與軌跡日誌，回傳 verdict、scores、failedSteps
• 軌跡監控元件追蹤每次工具呼叫與延遲，寫入 InfluxDB / Datadog 這類時序資料庫
• 用便宜的模型（Gemini Flash）當 AI 法官，輸出結構化 JSON 分數與評語
• 用 pytest（或其他對應的測試框架）把代理測試接進 CI/CD 管道，代理表現像一般程式碼一樣被持續驗證

代理輸出 ──> ┌───────────────────────────────────┐
             │ Evaluation Pipeline               │
             │  └─ Trajectory Monitor            │──→ 時序資料庫
             │  └─ LLM-as-a-Judge (Gemini Flash) │──→ { verdict, scores,
             │  └─ pytest 整合（CI/CD）          │      failedSteps, summary }
             └───────────────────┬───────────────┘
                                 ▼
                   前端渲染結果給使用者

前端：按照回傳結果渲染不同分支

• 合格 → 正常顯示代理產出
• 不合格 → 依照 failedSteps 的型別渲染不同的提示，例如「資訊交接失敗，請重試」或「資料不足，請補充」
• 內部工具 → 繪製評估儀表板，把通過率、延遲、token 成本視覺化，失敗軌跡可展開檢視

總結

從傳統字串比對的盲點，到用語義相似性理解 AI 的回答；從追蹤代理軌跡與資源成本，到請 AI 擔任法官評估主觀品質；再到多代理系統就像跨部門溝通一樣複雜——這四個層次解決的是「如何驗證一個機率性的系統」。但更關鍵的洞察是後半段：這些外部監測，最終要內化成 AI 自己的紀律，讓它從「可能需要盯著的代理」進化成「對結果負責的承包商」。

AI 工程的真正方向是我們不能永遠靠外部工具去盯一個不可靠的系統，而是要把「評估」變成系統內建的合約義務。形式化合約讓交付物有了客觀的驗收標準，談判機制讓 AI 誠實面對能力邊界，品質迭代讓 AI 自己當自己的 QA，分包分解讓超大專案可以被信任地交付。這是 AI 從「有趣的玩具」變成「支撐高風險商業環境的基礎設施」的關鍵一步。

然而，當這個數位勞動力完全成熟，一個 AI 承包商收到任務後，在幾毫秒內就把任務拆分並發包給幾千個不同的 AI 子承包商，它們在幾秒鐘內互相簽訂合約、互相驗證品質、完成除錯，形成一個以毫秒為單位高速運作的龐大經濟體。在那個連 AI 都在互相考核的世界裡，作為人類的我們，究竟還是不是這個系統的最高決策者？還是說，我們終將成為這個完美自動化流程裡動作最慢、也最容易出錯的那一個系統瓶頸？

參考資料

• Agentic Design Patterns - Chapter 19: Evaluation & Monitoring
• adk-web
• Google ADK - Why evaluate agents¶
• LLM Agent Evaluation Survey
• Agent-as-a-Judge: Evaluate Agents with Agents
• Agent Companion