讓 AI 代理聰明更要精明：資源感知最佳化

談到開發 AI 應用，大家最先關注的往往是模型能有多聰明。追求最強大的模型、要求最精準的邏輯推理，感覺就像我們唯一的目標是打造一個無所不知的超級大腦。可是當我們真的把這個「超級大腦」部署上線，讓它毫無節制地處理每個使用者的請求時，下個月收到 API 帳單的那一刻，心跳絕對會漏跳一拍。費用報表驚人，系統還可能因為運算負載太高而慢得令人抓狂。

這篇文章不談怎麼讓 AI 更聰明，要談的是怎麼讓 AI 更精明。從實驗室轉往真正的商業級應用，這是最痛的一步。聰明是一回事，但在現實世界殘酷的物理條件與財務預算限制下生存下來，完全是另一門學問。這正是資源感知最佳化（Resource-Aware Optimization）要解決的事。如果我們正在開發自己的 AI 代理，或公司打算導入 AI 解決方案，這篇內容或許能救系統一命，至少也能救錢包一命。

從「只會做事」到「懂得看餘額」

傳統的 AI 規劃往往只在乎執行步驟——給一個任務，就想辦法一步一步完成，根本不管背後付出多少運算代價、燒掉多少錢，使命必達就好。資源感知最佳化完全打破了這種線性思維，它要求 AI 代理在指定的資源預算內做動態決策，等於系統不僅要會做事，還要懂得看餘額。

這其實就像開了一家公司的老闆，不會花時薪一萬台幣去請一位頂級資深併購顧問下樓跑腿買咖啡。買咖啡這種超級簡單的任務，交給實習生跑就好了，便宜又快。但如果明天就要併購另一家對手公司，我們會毫不猶豫把預算砸在頂級顧問身上。這是合理的資源配置。

問題是，AI 的世界裡，系統在哪些實際場景下會面臨這種抉擇？

不管是為了省錢、搶時間，還是省電，系統都需要一種機制來自動判斷任務的輕重緩急。這不是隨機亂猜，而是一套系統級的分工架構。

路由器代理：系統級的分工

在多代理架構裡，任務分流通常交給一個角色：路由器代理（Router Agent）。我們用一個具體的應用來舉例——旅行規劃器。路由機制的完整脈絡，可參考這裡-自主 AI 代理的進化之路：從架構設計、意圖分流到平行加速。

如果我們對系統說：「規劃下個月去日本京都的五天四夜家族旅行，預算大概十萬，有老人也有小孩，喜歡看歷史建築，但不能走太多路。」這就是一個超高複雜度的規劃任務，需要強大的上下文理解與複雜的邏輯推理。路由器代理會意識到這點，把核心任務分配給像 Gemini Pro 這樣強大但相對昂貴的模型。

                    ┌─────────────────────────────────┐
                    │        路由器代理（Router）      │
                    │   依複雜度 + 預算決定走向        │
                    └───────────────┬─────────────────┘
                                    │
                    ┌───────────────┴───────────────┐
                    ▼                               ▼
        ┌─────────────────────┐        ┌─────────────────────┐
        │  Gemini Pro（貴）    │        │  Gemini Flash（省）  │
        │  複雜規劃：拆解行程、  │        │  跑腿任務：查機票價格、│
        │  邏輯決策、深度推理   │        │  查飯店空房、找餐廳評論│
        └─────────────────────┘        └─────────────────────┘

但有趣的地方在於接下來發生的事。當 Pro 模型把模糊的請求拆解成一系列有邏輯的步驟清單後，裡面有一個步驟是「查詢十月五號從台北飛大阪的機票價格」。這就變成標準的跑腿任務了——去網路上抓個價格而已，根本不需要高深的推理能力。這種具體、重複性的網頁查詢任務，就轉交給像 Gemini Flash 這種速度快又經濟實惠的模型執行。

Google 甚至為此提供了 ADK（Agent Development Kit） 開發框架，專門支援這種模組化的動態 LLM 路由。它的多代理架構讓不同代理可以各自處理專門的任務，模型靈活度也高——除了直接用各種 Gemini 模型（Pro、Flash），也可以透過 LiteLLM 整合其他模型供應商。路由器可以根據簡單的指標（例如查詢的字數長短），或透過一個微調過的小型機器學習模型，精準判斷要把任務分發給誰。更進階的路由器還會分析查詢的細微差別與複雜度：需要事實回憶的查詢路由到 Flash 模型，需要深度分析的複雜查詢路由到 Pro 模型。ADK 內建的評估功能還能把代理效能系統化地量化，回饋給整體系統持續改進。

評論家代理：校正路由的暗樁

路由器本身也是個模型，它怎麼愈變愈聰明？這就要引入另一個角色：評論家代理（Critique Agent）。它在一旁持續監控、評估其他代理給出的回答。這裡有個非常核心的質疑：我們整個大前提是為了節省資源，結果現在為了省資源，居然特別建立一個評論家代理——它不但要讀取原本所有的對話，還要花算力去評估，這不是消耗更多 API 額度嗎？

乍看之下確實像在增加額外的運算開銷，但評論家代理發揮的作用是間接的預算管理。如果沒有評論家，路由器可能因為一開始的判斷邏輯不夠精準，把一大堆很簡單的問題持續錯誤地丟給昂貴的 Pro 模型處理——白白浪費大錢。或者反過來，把需要深度推理的複雜問題丟給 Flash 模型，結果給出糟糕的答案，使用者不滿意，系統還得重新處理一次，浪費更多時間與算力。這些都是巨大且無形的資源浪費。

評論家代理的功能其實不只校正路由，它有三個角色：

評論家靠的是提供回饋訊號，白話來說就是給路由器的決策打分數。它也可以配置成只看應答代理輸出的文字，或同時看原始查詢與輸出，以便全面評估回應與初始問題的一致性：

路由器分發正確  →  評論家正向回饋  →  獎勵訊號
路由器殺雞用牛刀 → 評論家負向回饋  →  懲罰訊號
         │
         ▼
   微調路由器模型的權重
   讓分流決策愈來愈神準

這個分數在機器學習領域可以作為強化學習的獎勵或懲罰訊號。隨著時間推移，回饋機制會從底層微調路由器模型的權重。長遠來看，因為精準路由省下的鉅額成本，會遠大於評論家代理那點評估開銷——這是一筆投資報酬率很高的交易。

實作範例：把請求分成三類

把這些理論寫成程式時，事情就變得非常具體。OpenAI 模型讓系統將使用者的提示詞分成三個類別：

特別看一下 internet_search 這個分類——一旦系統判斷使用者需要的是最新資訊，它根本不浪費 LLM 的算力去回想或產生幻覺，而是直接觸發 Google Custom Search API 抓取最新結果。這就是典型的資源分流：把不適合 LLM 去做的「硬背最新事實」工作，直接交給傳統的搜尋引擎 API，既省算力又提高準確度。系統會把不同類型的查詢導向最佳化的處理方法：簡單問題用便宜模型省錢，複雜問題用推理模型保證品質，需要最新資訊的直接上網查，不靠模型瞎猜。

// 路由器：把請求分類後，分派到最合適的處理路徑
import OpenAI from 'openai'

type Classification = 'simple' | 'reasoning' | 'internet_search'

const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY })

async function classifyPrompt(prompt: string): Promise<Classification> {
  const res = await client.chat.completions.create({
    model: 'gpt-4o',
    temperature: 1,
    messages: [
      {
        role: 'system',
        content: [
          '你是一個分類器，把使用者的提示詞分為三類之一：',
          'simple、reasoning、internet_search',
          '規則：',
          '- simple：直接事實問題，不需推理或最新資訊',
          '- reasoning：需要邏輯、數學或多步驟推理',
          '- internet_search：涉及時事、近期資料，或不在訓練資料內',
          '只回傳 JSON：{ "classification": "simple" }',
        ].join('\n'),
      },
      { role: 'user', content: prompt },
    ],
  })

  const reply = res.choices[0].message.content ?? ''
  return JSON.parse(reply).classification
}

async function googleSearch(query: string, num = 1) {
  const url = new URL('https://www.googleapis.com/customsearch/v1')
  url.searchParams.set('key', process.env.GOOGLE_CUSTOM_SEARCH_API_KEY!)
  url.searchParams.set('cx', process.env.GOOGLE_CSE_ID!)
  url.searchParams.set('q', query)
  url.searchParams.set('num', String(num))

  const response = await fetch(url)
  const data = await response.json()
  return (data.items ?? []).map((item: any) => ({
    title: item.title,
    snippet: item.snippet,
    link: item.link,
  }))
}

async function generateResponse(prompt: string, classification: Classification, searchResults: any[] = []) {
  let model = 'gpt-4o'
  let fullPrompt = prompt

  if (classification === 'simple') {
    model = 'gpt-4o-mini'
  } else if (classification === 'reasoning') {
    model = 'o4-mini'
  } else {
    const context = searchResults
      .map((r) => `Title: ${r.title}\nSnippet: ${r.snippet}\nLink: ${r.link}`)
      .join('\n')
    fullPrompt = `Use the following web results to answer the user query:\n${context}\nQuery: ${prompt}`
  }

  const res = await client.chat.completions.create({
    model,
    temperature: 1,
    messages: [{ role: 'user', content: fullPrompt }],
  })
  return { answer: res.choices[0].message.content, model }
}

// 主流程：分類 →（需要時）搜尋 → 生成
async function handlePrompt(prompt: string) {
  const classification = await classifyPrompt(prompt)
  const searchResults =
    classification === 'internet_search' ? await googleSearch(prompt) : []
  const { answer, model } = await generateResponse(prompt, classification, searchResults)
  return { classification, answer, model }
}

獨立開發者救星：OpenRouter

如果只是獨立開發者或資源有限的新創團隊，要從頭刻整套路由邏輯、串接不同公司的模型，甚至寫一個評論家代理來訓練路由器——這是一場維護噩夢。所以市面上出現了 OpenRouter 這樣的工具，對不想自己打造路由基礎設施的開發者來說是極佳的解決方案。它提供一個單一的 API 端點，背後整合了數百個不同的人工智慧模型。其中兩項核心功能特別值得注意。

自動模型選擇

只要把問題丟給 OpenRouter，它就會根據問題內容，自動在茫茫模型海中挑選一個性價比最高的模型來回答。只要在 request 裡指定 model: "openrouter/auto"，系統會從精選的可用模型中選擇最佳化模型，實際使用的模型識別碼會在回應的 metadata 中回傳，方便我們追蹤每次請求到底用了哪顆引擎。

{
  "model": "openrouter/auto"
}

順序模型回退（Sequential Model Fallback）

更能展現系統強韌度的是另一種路由方法。我們可以設定一個模型清單，比如首選是最高階的 GPT-4，但現實世界裡 API 常遇到速率限制（呼叫太頻繁被暫時阻擋），或伺服器半夜過載直接當機。沒有這個機制，使用者就會看到冷冰冰的錯誤訊息，整個服務徹底中斷。

有了順序模型回退，系統一旦發現首選模型沒有回應，不會讓整個應用程式崩潰，而是自動、無聲無息地往清單的下一個選項切換，例如切換到 Claude 或某個稍微小一點的開源模型，直到成功拿到回應為止。使用者根本不會發現有問題。

{
  "models": ["anthropic/claude-3.5-sonnet", "gryphe/mythomax-l2-13b"]
}

這在軟體工程上稱為優雅的降級（Graceful Degradation）。比起追求一個完美但根本無法送達的答案，系統應該優先確保服務的連續性——確保服務可用，永遠比直接崩潰好。

進階策略：把餵給模型的東西也省下來

切換模型其實只是最外層的防護罩。要達到極致的效率，還得深入看看我們到底餵給模型什麼東西。這塊可統整為九種技術，除了前面已談過的動態模型切換與優雅降級，還有：

接著挑幾個對成本影響最直接的做法深入看。

上下文修剪與總結

現在很多模型標榜可以處理超長上下文，動輒幾十萬、上百萬個 token，但這其實是常見的迷思。我們先釐清 token 是什麼——可以把它想像成 LLM 閱讀的每一個字碎片。模型處理的每個 token 背後都是白花花的伺服器運算成本，而且會直接拖慢回應速度，讀愈多愈慢也愈貴。

很多時候使用者與 AI 之間有幾十輪的對話歷史，但裡面充斥著寒暄或早就無關緊要的廢話。如果每次問新問題，系統都要把過去幾萬字的廢話重新讀一遍，就是在瘋狂燒錢。系統有兩種修剪方式：

這就像是跟大老闆報告之前，先自己把冗長的會議紀錄精簡成一頁投影片——老闆的時間很貴，模型的算力也一樣。

主動資源預測

如果遇到突發的極端狀況呢？某個應用突然爆紅，或搶演唱會門票時瞬間湧入海量流量。就算任務已經修剪得很輕量，只要數量一夠大，還是能把系統壓垮。主動資源預測解決的就是這個問題——不是等塞車了才切換模型，而是透過預測未來的工作負載，提前分配資源。

這就像高速公路的交控中心，透過過往的大數據預判「這個週末是連假」，所以提前調撥車道、開啟路肩。預測模型發現未來半小時內流量即將暴增時，就自動啟動預先配置好的伺服器節點，防止瓶頸發生。

成本敏感型探索與並行化

在多代理架構中還有一件事常常被忽略：代理之間溝通本身也有成本。想像公司裡的不同部門，為了確認一個小細節開了幾十次會、來回寄了一百封 email——在 AI 系統裡，這就意味著產生大量的 API 呼叫。系統必須把探索與溝通的成本也納入最佳化的考量，確保代理之間只有在真正必要的時候才交換資訊。

那如果是為了加速處理，能不能像工廠生產線那樣讓很多代理同時開工？這就非常依賴高度結構化的並行化機制，有點類似傳統運算裡的 MapReduce 邏輯。多代理如何分工協作而不互相干擾，可參考這裡-多代理協作（Multi-Agent Collaboration）— 從單打獨鬥的 AI 到各司其職的 AI 專家團隊：

    ┌────────────────────────────┐
    │  總控代理（Map 階段）       │
    │  把龐大資料集切割成         │
    │  完全獨立互不依賴的小區塊   │
    └────────────┬───────────────┘
                  │ 分別交付
    ┌─────────────┴─────────────┐
    ▼       ▼       ▼       ▼
 [代理A]  [代理B]  [代理C]  [代理D]   同時處理，互不干擾
    │       │       │       │
    └─────────────┬─────────────┘
                  ▼
    ┌────────────────────────────┐
    │  彙整代理（Reduce 階段）     │
    │  把五份結果會診成完整答案    │
    └────────────────────────────┘

總控代理先把龐大資料集切割成完全獨立的區塊（Map 階段），五個代理在不同的機器上同時處理自己的區塊，完全不需要互相對話。全部處理完之後，再由另一個代理把結果會診起來（Reduce 階段）。透過這種設計，系統能在不引發混亂的前提下成倍提高吞吐量。

經驗法則

無論我們現在是一位正在架構全新 AI 產品的軟體工程師，還是正在評估是否全面導入 AI 解決方案的專案經理，經驗法則非常明確：停止盲目追求把所有的任務都塞給最頂級的模型。有五種情境特別適合用這個模式：

只要命中其中任何一項，就該考慮把資源感知最佳化內建到系統設計裡。

對 UI/UX 的影響：把精明看得見

資源感知最佳化發生在後台，但使用者完全感受得到。UI/UX 的核心是讓使用者理解系統的資源決策，而不是只看到一個黑箱結果。

模型選擇與成本的透明度

當路由器代理選擇了便宜的模型來回應時，使用者應該知道這次回應「用了一顆小引擎」，而不是以為每次都是旗艦模型在回答。以旅行規劃器為例：

┌─────────────────────────────────────────────────────────┐
│  ✈️ 旅行規劃助手                                         │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  使用者：幫我規劃下個月去京都的家族旅行                │
│                                                         │
│  規劃引擎（Gemini Pro）     ✔ 已完成 · 2.1 秒           │
│  │  拆解：住宿、交通、行程、飲食                       │
│  ▼                                                      │
│  ┌─ 子任務：查詢 10/05 台北→大阪機票價格 ──────────┐   │
│  │  執行模型：Gemini Flash（經濟型）  ✔ 已完成       │   │
│  │  本次查詢成本：約 NT$0.03                        │   │
│  └──────────────────────────────────────────────────┘   │
│                                                         │
│  ⚡ 本次會話累計成本：NT$0.87 | 預算上限 NT$50         │
│     ────────────────────────                           │
│     剩餘預算          ██████████░░░░░░  86%            │
│                                                         │
│  ┌──────────┐  ┌──────────────────────────┐            │
│  │ 改用 Pro │  │  查看路由決策            │            │
│  └──────────┘  └──────────────────────────┘            │
└─────────────────────────────────────────────────────────┘

把「用哪個模型執行、花了多少成本、還剩多少預算」攤在介面上，有三個好處：一是建立信任，使用者知道系統不是隨便應付；二是可預期，面對預算上限的對話，使用者可以主動調整要求；三是可控制，提供「改用 Pro」的手動覆寫，讓高價值的請求可以升級處理。

順序回退的可見性

優雅降級發生時，使用者不該只看到「系統正常」，也不該看到一堆錯誤碼。三層式的呈現策略：

以旅行規劃器遇到伺服器當機為例，資訊層的呈現：

┌─────────────────────────────────────────────────────────┐
│  ✈️ 旅行規劃助手                                    ⚠️ 部分  │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  主要模型（Gemini Pro）暫時無法回應                     │
│  ⓘ 已自動切換至後備模型，回應品質可能略有差異          │
│                                                         │
│  使用者：京都哪家百年老舖的抹茶甜點最有名？            │
│  AI：京都的抹茶名店主要集中在中京區，例如...           │
│  ┌────────────────────────────────────────────────┐    │
│  │  ⟳ 重試主要模型    還原此請求的完整回答        │    │
│  └────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────┘

前後端技術怎麼落地：把資源決策變成事件

這些介面很好看，但真正的問題是：後端要把哪些資料送出來，前端才有東西可以畫？ 資源感知最佳化的 UI/UX 影響，有一個跟 RAG：讓 AI 從閉卷考變開卷考 類似的本質矛盾：路由決策（選了哪個模型、花了多少錢）在生成答案之前就完成了，如果後端等全部完成再一次回傳，前端就做不到「先看到路由決策，再看到逐字答案」的漸進效果。

後端：把每個階段當作事件推送

解法是讓後端把每個階段當作事件，透過 SSE 即時推給前端：

// 後端：資源決策事件串流
import { createServer } from 'node:http'

createServer(async (req, res) => {
  res.writeHead(200, {
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache',
    Connection: 'keep-alive',
  })

  const send = (event: string, data: unknown) => {
    res.write(`event: ${event}\ndata: ${JSON.stringify(data)}\n\n`)
  }

  // 1. 路由器完成分類，先推模型選擇與預估成本
  send('routing', {
    prompt: '查詢 10/05 台北→大阪機票價格',
    classification: 'simple',
    model: 'gemini-2.5-flash',
    estimatedCost: 0.03,
  })

  // 2. LLM 生成時，逐字推送
  for (const token of await streamAnswer()) {
    send('token', token)
  }

  // 3. 完成後回報實際成本
  send('cost', { actualCost: 0.028, totalSessionCost: 0.87 })
  send('done', {})
})

關鍵不是用了什麼協定，而是後端把「路由決策」和「答案」拆成不同的事件，前端才能分開渲染。成本估算的邏輯（estimateCost(model, tokens)）必須放在後端，前端只負責把數字畫出來。

前端：分層渲染路由決策

後端把事件送出來了，前端的工作就是把每一種事件渲染成對應的 UI：

// 前端（React）：把 SSE 事件渲染成資源決策視圖
import { useEffect, useState } from 'react'

type RoutingInfo = {
  model: string
  classification: string
  estimatedCost: number
  fallbackActive: boolean
}

function AgentResponse() {
  const [answer, setAnswer] = useState('')
  const [routing, setRouting] = useState<RoutingInfo | null>(null)
  const [cost, setCost] = useState(0)
  const [fallback, setFallback] = useState(false)

  useEffect(() => {
    const es = new EventSource('/api/agent-query')

    es.addEventListener('routing', (e) => {
      const data = JSON.parse(e.data)
      setRouting(data)
      setFallback(data.fallbackActive ?? false)
    })

    es.addEventListener('token', (e) => {
      setAnswer((prev) => prev + JSON.parse(e.data))
    })

    es.addEventListener('cost', (e) => {
      setCost(JSON.parse(e.data).actualCost)
    })

    return () => es.close()
  }, [])

  return (
    <div className="agent-response">
      {routing && (
        <div className="routing-badge">
          執行模型：{routing.model} · 預估 {routing.estimatedCost} 元
          {fallback && ' ⚠️ 已切換至後備模型'}
        </div>
      )}
      <p>{answer}</p>
      {cost > 0 && <div className="cost">本次成本：{cost.toFixed(3)} 元</div>}
    </div>
  )
}

幾個設計決策：

判斷在後端，呈現在前端

最後的重點跟 RAG、A2A 系列一致：前端絕對不能自己決定「該用哪個模型」。路由、成本估算、回退順序這些判斷，必須在後端用確定性規則算好，前端只負責把結果和理由畫出來。正確的分工是：

後端（資料與判斷）              前端（呈現與互動）
┌─────────────────────┐    ┌─────────────────────┐
│ 路由器代理分類請求     │    │ 渲染執行模型徽章      │
│ 估算成本與預算扣減     │───▶│ 呈現累計成本與剩餘預算 │
│ 順序回退決定          │    │ 顯示後備模型警示      │
│ 產生路由事件          │    │ 可展開的路由決策面板   │
└─────────────────────┘    └─────────────────────┘
      只管「資源怎麼分配」         只管「怎麼呈現」

路由邏輯放在後端，才能跟 UI 分開測試、被其他系統（報表、排程）重複使用。前端畫得再漂亮，後端不把決策送出來，一切都只是空談。

總結

在智慧代理的開發世界裡，系統輸出的品質與它所需要的資源之間，永遠存在著一道必須權衡的天平。沒有什麼一體適用的完美模型，只有最適合當下情境的動態策略。透過路由器代理的分流、評論家代理的強化回饋、確保服務不中斷的順序回退機制，以及上下文修剪與主動資源預測這類底層優化，我們才能建立真正可擴充、夠穩健、具備永續性的 AI 系統。

用「永續性」形容 AI 系統，再適合不過了。今天談了很多極致的精打細算——代理透過回饋機制學會怎麼最省錢、最省力地分配資源，也談到邊緣裝置上的節能部署。試想一下，如果未來的 AI 代理系統透過資源感知最佳化不斷進化，最後學會極致的生存法則，會不會就不再需要那些龐大、昂貴、耗電量又驚人的雲端巨型模型？

未來的 AI 發展或許不再只是科技巨頭們拼命追求一個無所不知的單一超級大腦，而是演變成由無數個極度節能、直接在我們的手機、智慧手錶、甚至感測器上本地執行的微型代理蟲群。它們每個單體可能都不怎麼聰明，只能做最簡單的判斷，但只要透過完美的路由、低成本的溝通與並行化運算，這群蟲群就能無縫完成所有複雜需求。就像那群買咖啡的實習生，已經能透過極致的團隊合作完美搞定一場跨國併購案——到那時，我們還真的需要那個時薪一萬塊的頂級顧問嗎？這是值得我們在技術狂熱中靜下心來持續觀察的未來。## 參考資料

• 第 16 章：資源感知優化
• OpenRouter
• OpenRouter - AI Model Rankings