- 衡量 AI 的標準正從 IQ（知識）走向 AQ（Action Quotient，行動力）——模型能不能實際操作、完成任務,成為新的評比重點。
- 企業導入的關鍵不是「用哪個工具」,而是用 「快思／慢想」框架設計人機協作,並把 AI 嵌進核心流程 + 內部資料。
- 治理從 Human-in-the-loop 走向 Human-on-the-loop:把 Agent 當「人」管——給邊界、給權限、追蹤全程。
- 真正的護城河,是把企業知識梳理、累積成 不可複製的 AI 優勢。
2026 年 6 月,資策會產業情報研究所(MIC)韓主任在一場企業 AI 共學分享中,完整梳理了企業導入 AI Agent 的全貌。這篇文章把當天上午場的重點重整成可帶走的架構——從衡量典範的轉移、人機協作的設計框架,到 AI 治理與組織經濟結構的改變。如果你正在思考公司該怎麼把 AI 真正用進核心業務,而不只是停在「試用哪個工具」,這份筆記會很有用。
為什麼 Data-Driven 是 AI-Driven 的地基?
2015 年曾有人預測「2025 是 data 的時代」,但到了 2025,現實是多數公司的 data governance(資料治理)仍落不了地——因為資料清整、資料平台這些底層問題都還沒解決。2020 年又有人說「Data + AI driven 要 2030 年以後才會真正實現」。
結論很直接:要成為 AI-driven enterprise,前提一定是先把 data 清整好。沒有乾淨、有結構、帶業務語意的資料,再強的模型也只能用猜的。
LLM 六大發展動態:未來 AI Agent 的能力來源
韓主任用一張總圖,把當前 LLM 的發展歸納成六個方向。這六項決定了未來 AI Agent 能做到什麼。
| 發展動態 | 重點 |
|---|---|
| 長文化 | 處理長文本／長脈絡 + 記憶能力 |
| 專責化 | 走向專業專職的應用 |
| 領域化 | 推理模型 + 公司自有資料(小模型 SLM 也行) |
| 小型化 | 成本低、可邊緣／在地部署 |
| 多模、多工化 | Text／Voice／Picture／Video 全包 |
| 代理人化 | 自主執行任務,AQ 為主導 |
什麼是 AQ?從衡量 IQ 到衡量 Action Quotient
AQ(Action Quotient,行動力)是衡量 AI Agent 能不能實際操作、完成任務的指標。過去我們衡量模型的「知識與推理(IQ)」;在 AI Agent 時代,重點轉成「它能不能真的把事情做完」。業界已經發展出成套的 Agent benchmark,按能力分類:
| 能力分類 | 代表 Benchmark |
|---|---|
| 網頁操作 | WebArena、WebVoyager、VisualWebArena |
| 電腦操作 | OSWorld |
| 手機操作 | AndroidWorld、AndroidLab、MobileWorld |
| 研究能力 | OpenAI BrowseComp |
| 電商客服／比價 | CRMArena、ECom-Bench、WebMall |
| 長期營運／助理 | Vending-Bench、GAIA |
核心框架:用「快思慢想」設計人機協作
這是整場分享的主骨架。韓主任借用《快思慢想》(Kahneman)的概念:AI 是一個「放大器」——你本身多強,它放大多強,而且人與機器是雙向互相指導。把「快思(直覺快速)」與「慢想(深度思考)」拆開,就能衍生出三種清楚的協作模式。
| 模式 | 適用 | 代表實例 |
|---|---|---|
| ① AI 快思 | 簡單經驗判斷、快速反應 | 卡車司機語音議價、客服(Sierra)、SAP Joule、n8n |
| ② 人慢想 + AI 快思 | 策略沉澱、學習 | 企業內訓虛擬教室、K-12 蘇格拉底教材、智慧眼鏡幫失智者、3D 天文教學 |
| ③ 人慢想 + AI 慢想 | 創新、科學 | 數學專案一週解 1800 萬條、AlphaFold、矩陣相乘 49→48 次、AutoML 一晚疊 20 種模型 |
幾個讓人印象深刻的實例
- 語音議價:美國卡車司機每趟打電話議價,現在另一端就是 AI——多模態模型即時產生語音,會說「你等我一下,我查一下」假裝真人。
- 防詐騙漫畫:把每種詐騙手段寫成 20 幾部漫畫,自動生成、每天自動寄一部給長輩看。
- 科學代工:一位年輕數學家與微軟合作,把全世界 4000 多個領域、200 萬個待證事實,在一週內解了 1800 萬條——AI 代工的是「思考與推理」。
- 省一次乘法的意義:Google DeepMind 把矩陣相乘從 49 次降到 48 次。因為矩陣相乘是所有資料中心都在做的事,全世界省 2~3% 效能就非常可觀。
「人,才是最大的摩擦力(bottleneck)。」矽谷工程師睡前若沒把任務派下去,隔天起床就等於虛度 8 小時——因為 AI 整夜都能幫你跑。此外,根據 Cloudflare 統計,現在網路上的瀏覽量約有三成已經是 AI 在看,而不是人。
AI 治理:從 Human-in-the-loop 到 Human-on-the-loop
「AI 用起來很強,但要怎麼管好?」是韓主任說今年最多企業在討論的問題。核心做法是把 Agent 當「人」來管:
- 評估與測試每一個 Agent。
- 給邊界與權限——這個 Agent 能做什麼、界線在哪。
- 追蹤、監控全過程——它做了哪些事,要留下軌跡。
管理模式也隨之轉變:過去是 Human-in-the-loop(人在迴圈內逐步把關),現在轉為 Human-on-the-loop——人站在迴圈之上,監督(supervise)各個不同 Agent 的狀態。
人才、組織與經濟結構怎麼變?
- 人才:軟體人力需求回升(AI native 工程師進場);人要強化的是判斷力、soft skills、推進力、領導力。
- 組織:從管 API／SDK,轉為管 Agent OS;科技巨頭在做組織重整,把多層管理歸併到 5~8 層。
- 經濟:範疇經濟(scope economy)> 規模經濟——自動化之外會產生更多新需求,需要更多人進來解決。
- 數位員工:未來你的同事,很大一部分不是人。
對企業的行動含義
- 不要停在「比哪個 AI 工具好用」;要把 AI 嵌進採購、物流、倉管等核心流程與內部資料。
- 先選 1~2 條高頻、可驗證的流程,用「快思」模式快速落地;策略性題目用「慢想」模式跟 AI 共創。
- 同步建立治理:Agent 的邊界、監控、人機協作 SOP。
- 把企業知識梳理、累積成不可複製的 AI 優勢——這才是真正的護城河。
延伸一:模型有哪些「型態」?多模態到底分哪幾種
韓主任提到「多模態」時,很多人以為就是「會看圖」。其實多模態(multimodal)是一整個光譜,理解端與生成端、不同模態(文字、圖、音、影)的成熟度差很多。企業選型前,先搞清楚自己要的是哪一種能力,才不會買錯。下表把當前模型按能力分類(型號版本演進極快,以下以「系列/家族」為準,實際版本請以各廠官方為準):
| 型態 | 能做什麼 | 代表模型(系列) |
|---|---|---|
| 純文本 / 推理型 | 只吃文字、只出文字,靠「延長思考」攻數學/程式/邏輯;看不懂圖、不生圖 | DeepSeek(V3/R1 系列)、OpenAI o 系列、Qwen Max、GLM |
| 視覺理解(看得懂圖) | 看圖、讀掃描件/PDF/表格、OCR;但不會畫圖 | GPT、Claude、Gemini、Qwen-VL(開源)、Llama vision(開源) |
| 圖像生成(文字→圖) | 生圖、局部編輯、打光;圖內文字渲染近年大進步 | Gemini Image(Nano Banana Pro)、GPT Image、FLUX(開源)、Stable Diffusion(開源)、Imagen |
| 語音 / 音訊 | STT(語音轉文字)、TTS(文字轉語音)、原生語音對話 | Whisper(開源)、OpenAI Realtime、Gemini Live、Deepgram、ElevenLabs |
| 影片(理解 / 生成) | 看懂影片做問答/摘要;或文字→影片(部分已能原生配同步音訊) | Google Veo、OpenAI Sora、快手 Kling、Runway |
| 原生多模態(any-to-any) | 一個模型同時吃文字+圖+音+影,context 共享、延遲低 | Gemini(Omni)、Qwen Omni(開源)、GPT-4o 起的 OpenAI 系列 |
原生 = 一個模型內部跨模態推理(如 Gemini Omni、Qwen Omni),context 共享、延遲低、跨模態一致。
拼接 = 多個模型串起來(模型 A 寫稿 → B 生圖 → C 配音),彈性高但延遲與一致性較差。
一句話:「理解端」愈來愈能用單一模型搞定,「生成端」(生圖、生語音、生影片)目前仍常是多模型拼接。
另一個切角:開源 vs 閉源,開源再分「巨獸」與「小鋼炮」
上面是按「能力(型態)」分;對企業選型,更實用的另一個切角是「拿不拿得到權重」。閉源只能用 API、拿能力天花板;開源能自己架、拿資料主權。而開源裡又分兩種體型完全不同的玩家——動輒上百 B、要整櫃顯卡的巨獸,和單卡甚至手機就能跑的小鋼炮(SLM)。
| 類別 | 代表模型(系列) | 特點 / 適合誰 |
|---|---|---|
| 閉源(只能 API,拿不到權重) | OpenAI GPT／o 系列、Anthropic Claude、Google Gemini／Veo／Imagen／Nano Banana Pro、Sora、快手 Kling、Runway、ElevenLabs | 能力天花板最高、免維運、上線快;但資料要送出去、會被廠商綁定、模型可能被抽換 |
| 開源·巨獸(100B+,要重裝備) | DeepSeek(V3／R1,671B MoE)、Qwen 大型(含 Qwen-VL 235B)、Llama 4 大型、GLM | 可自架做 air-gapped 私有大腦、資料完全落地;但要多卡／高 VRAM,部署門檻高 |
| 開源·小鋼炮(SLM,單卡/手機) | Microsoft Phi、Google Gemma(2B／9B)、Qwen 小型(0.5–7B)、Meta Llama 3.2(1B／3B)、Mistral 小型;生圖開源 FLUX、Stable Diffusion;語音開源 Whisper | 便宜、低延遲、可在地／邊緣、易微調;配上領域資料就是即戰力 |
但開源模型真正的績效,是「在有限資源下,看你要的那幾種模態,挑剛好夠用的最小體型」。所以巨獸和小鋼炮都得標出各自的模態與資源。先看巨獸:
| 開源·巨獸 | 規模 | 模態 | 可跑硬體(概估) |
|---|---|---|---|
| DeepSeek V3／R1 | 671B MoE(active 37B) | 純文字／推理(看圖另有 DeepSeek-VL) | 8× H200(FP8 近 1TB);INT4 可壓 |
| Qwen-VL(235B) | 235B MoE | 文字 + 視覺(看圖／讀文件／影片理解) | 多卡／單機多 GPU |
| Llama 4(大型) | 大型 MoE | 文字 + 視覺(原生) | 多卡／高 VRAM |
| GLM（+ GLM-V） | 大型 | 文字;視覺另有 GLM-V | 多卡 |
再看小鋼炮——這格才是企業在有限資源下的主力,重點是「需要哪種模態,就挑那種專長的小模型」:
| 開源·小鋼炮 | 規模 | 模態 | 可跑硬體 |
|---|---|---|---|
| Microsoft Phi | 3.8–14B | 文字／推理(另有 Phi-vision 看圖) | 單張消費卡 |
| Google Gemma | 2B／9B(Gemma 3 加視覺) | 文字;Gemma 3／PaliGemma 可看圖 | 單卡／邊緣 |
| Qwen 小型 / Qwen-VL 小型 | 0.5–7B | 文字;Qwen-VL(3B/7B)看圖;Qwen-Audio 聽音 | 單卡／手機(小尺寸) |
| Qwen-Omni(7B 版) | ~7B | 原生多模態:文字+圖+音+影(輸出可含語音) | 單張消費卡 |
| Meta Llama 3.2 | 1B／3B | 純文字(11B 版才有視覺) | 手機／筆電 |
| Mistral 小型 / Pixtral | 3–12B | 文字;Pixtral 12B 看圖 | 單卡 |
| FLUX / Stable Diffusion | ~12B / 中小 | 圖像生成(文字→圖) | 單張 24GB 卡 / 可離線 |
| Whisper | tiny–large | 語音轉文字(STT) | CPU / 小卡即可 |
看出規律了嗎?在開源世界裡:純文字需求,小鋼炮就夠;要看圖,挑 VL 版;生圖、語音是專門的開源模型(FLUX／SD 生圖、Whisper 聽寫);要一個模型全包(原生多模態),開源選擇還很少——Qwen-Omni 7B 是難得能在單卡跑的全模態小鋼炮。這就是開源的玩法:不是追最大,而是把需要的模態,用剛好夠用的最小模型湊齊。
閉源拿「能力天花板」、開源巨獸拿「資料主權」、小鋼炮拿「成本與落地」。多數企業的務實組合是:用閉源 API 探路、驗證價值 → 再用開源小鋼炮 + 領域資料落地到核心流程;只有資料主權要求極高、用量極大的少數場景,才值得養開源巨獸。
企業情境:處理一封「含圖片的客戶 email」會用到哪些模態?讀內文(文字理解)→ 看懂附圖,如故障照片、收據、合約掃描件(視覺理解 + OCR)→ 若有語音留言則轉文字(STT)→ 判斷該退貨或報修(推理)→ 產生回信草稿(文字生成),必要時回語音(TTS)或附示意圖(圖像生成)。若用原生多模態模型,前面「讀文字+看圖+聽語音」可由一個模型一次吃下,省掉多模型編排。
延伸二:哪個模型要多少資源?VRAM 換算與部署選擇
「小模型也可以」是韓主任的重點之一。但小到什麼程度、要多少顯卡?這裡給一條最實用的換算口訣,以及一張規模對照表。
7B 模型 × 2 ≈ 14GB 權重。量化後再砍:8-bit ≈ 參數量 × 1、4-bit ≈ 參數量 × 0.5。
實務上要再加 25–40% overhead(KV cache、context、batch),context 越長吃越多。所以「能跑」的實際顯存,通常比純權重再高一截。
| 規模 | 4-bit 顯存(概估) | 適合硬體 | 適合場景 |
|---|---|---|---|
| 1–3B(SLM) | < 1–2GB | 手機 / 筆電 / 邊緣 | 裝置端、即時、隱私敏感、單一窄任務 |
| 7–8B | 4–8GB | 單張消費級 GPU(RTX 4090) | 部門級助理、RAG、客服、agentic worker |
| 13–34B | 8–28GB | 24GB 消費卡 ~ 單張 A100/H100 80GB | 較複雜推理/程式、中型企業內部服務 |
| 70B | 40–48GB | 單張 80GB(4-bit)或多卡 | 高品質通用、需較強推理且願自建 |
| 120–235B MoE | 60GB+ ~ 多卡 | 80GB H100 / 工作站 / 單機多卡 | 接近 frontier 的私有(air-gapped)部署 |
| 671B MoE | 近 1TB(FP8) | 8× H200 / 多節點 | 國家 / 大企業級私有大腦,極少數情境 |
MoE 的坑(企業最常誤判):混合專家模型(MoE)看的是總參數,不是每次 active 的參數。例如 120B 級 MoE 每個 token 可能只動用約 5B,但 120B 全部權重都得載進顯存;DeepSeek 671B 雖只 active 約 37B,還是要近 1TB 記憶體。別被「active 參數很小」騙了。
量化(quantization)就是用較低精度存權重來換顯存:FP16→INT8 省約一半、FP16→INT4 省約四分之三。企業常用的甜蜜點是 4-bit(Q4_K_M / AWQ)——品質損失小、能塞進受限顯存。但要注意:數學、邏輯、程式生成對精度損失較敏感,摘要與對話則較耐受;Q2 等過度量化會明顯退化,不建議生產用。
雲端 API 還是自建 GPU?用 token 量決定
| 選擇 | 什麼時候選 |
|---|---|
| 雲端 API(按 token 計費) | 用量低或不穩、要最新 frontier 能力、團隊無 MLOps 人力、想快速上線。善用 cache(命中只收約 10%)與 batch(約 5 折換 SLA)省錢。 |
| 自建 GPU | 用量大且穩定、資料落地/合規要求、長期成本敏感、有工程量能。注意硬體只佔真實投入的 30–40%,要抓 2.5–3 倍乘數(電力、機房、工程人力)。 |
粗略的打平點(隨模型與供應商差異很大,僅供量級參考):相對於高階 API,大約每月數百萬到上千萬 token 的穩定用量,自建就開始划算;相對於便宜的小模型 API,則要每月數千萬 token 以上才划算。實際數字請以當期官方定價試算為準。
延伸三:企業要微調怎麼做?Prompt → RAG → Fine-tune
「想微調」是很多企業的第一反應,但業界共識正好相反:微調是最後手段,不是第一選擇。客製化是一條由輕到重的光譜,先把便宜的試完,不夠才往上爬。
| 層級 | 改變什麼 | 適用 |
|---|---|---|
| Prompt / few-shot | 不改模型,只改輸入 | 任務簡單、需求多變、快速試錯 |
| RAG(檢索增強) | 不改模型,外掛知識庫 | 知識會變動、要事實正確、要可溯源 |
| Fine-tune(PEFT/full) | 改模型權重/行為 | 要固定的風格/格式/語氣、行為一致 |
| Continued pre-training | 大量加深領域知識 | 領域與通用語料差異極大(成本最高) |
要「最新、會變的事實」→ 用 RAG(知識庫每天變,不必重訓還能溯源)。
要「固定的行為/格式/語氣」→ 用 Fine-tune。
最強的其實是混合:fine-tune 調行為 + RAG 拉事實 + 短 system prompt 導向。
LoRA / QLoRA:為什麼便宜、要多少資源
LoRA 把原模型權重凍結,只額外訓練一組很小的「adapter 低秩矩陣」,只更新約 0.1–1% 的參數;QLoRA 再把底模型做 4-bit 量化,記憶體又砍一刀。以 7B 模型為例:
| 方法 | 7B 顯存(概估) | 品質保留 |
|---|---|---|
| Full fine-tuning | 100–120GB(H100 等級) | 100%(基準) |
| LoRA | 比 full 省 60–80% | 約 full 的 90–95% |
| QLoRA | ~13GB(可塞 16GB 卡,壓到極致 6–10GB) | 約 80–90% |
換句話說,一張一千多美元的 RTX 4090 就能用 QLoRA 微調 7B 模型,70B 用 QLoRA 也能塞進單張 A100 80GB。資料量則是品質遠勝數量:多數任務 200–500 筆高品質的「指令-回應」範例就有意義效果,建議約 1,000 筆起跳並留驗證集——「1,000 筆精選 > 10,000 筆平庸」。
實務工具:雲端託管 vs 開源自建
- 雲端託管(求快與合規):Azure OpenAI、Google Vertex AI、AWS Bedrock 都提供託管微調,資料留在自家雲帳號、整合身分權限。注意一個趨勢訊號:據報 OpenAI 正在逐步收斂其自助式 fine-tuning 平台、改推 prompt/RAG/工具呼叫等「模型外層」客製路徑(實際時程與政策請以 OpenAI 官方公告為準)——這也反向強化了「先 prompt + RAG」的產業共識。
- 開源自建(求掌控與成本):底層多建在 Hugging Face PEFT 之上,常用框架有 Unsloth(2–5× 快、省約 80% 記憶體,適合單卡入門)、Axolotl(YAML 設定、適合多卡上規模)、LLaMA-Factory(支援上百種模型)。
四個常見的坑
- 以為什麼都要微調——多數需求 prompt + RAG 就解決。
- 微調 vs RAG 搞混——RAG 給「知識/事實」,微調給「行為/格式」;拿微調去塞會變動的事實是反模式,而且會過時。
- 災難性遺忘——連續微調會讓模型忘掉原本的通用能力,且模型越大可能越嚴重;用 LoRA/PEFT(只動少量參數)天然較不易遺忘。
- 資料品質差——髒資料、缺驗證集,效果一定差。
- 先 Prompt / few-shot——最便宜、最快迭代。
- 不夠 → 上 RAG,接知識庫、不重訓。
- 還不夠且要穩定行為 → 才 Fine-tune,先 PEFT(LoRA/QLoRA)別一上來就 full。
- 領域差異極大且有量 → 才考慮 continued pre-training(算進長期推論成本)。
- 全程用 evals 量測——微調與否都要有可驗證指標。
延伸閱讀:AI 不是答案販賣機:企業導入人機協作的實戰心法、當 AI 夠重要,價值與風險就是一體兩面:談 AI 治理與 ROI、一張圖看懂 AI Agent 系統:Loop、Harness、MCP、A2A 差在哪。
發佈留言