分析雲端架構從複雜 ETL 轉向「垂直整合」的趨勢，消除資料搬運成本與延遲，使架構師價值從「規劃路徑」轉向「資料治理」。作者：黃婉中（雲端架構師）

分析雲端架構從複雜 ETL 轉向「垂直整合」的趨勢，消除資料搬運成本與延遲，使架構師價值從「規劃路徑」轉向「資料治理」。

[caption id="attachment_210511" align="alignnone" width="872"] 工程師的日常工作，有大半時間在解決一個問題：「怎麼把資料從 A 點搬到 B 點？」（圖／黃婉中提供）[/caption]

身為雲端架構師，我觀察許多工程師的日常工作，有大半時間在解決一個問題：「怎麼把資料從 A 點搬到 B 點？」

在過去 10 年的大數據時代，我們的架構圖長得像迷宮。業務系統（OLTP）收到資料後，我們會寫一套 ETL 程序，把原始資料抽出來，洗乾淨後放進數據湖（Data Lake）。
為了讓老闆看報表，我們再從湖裡撈出來，轉成特定格式，放進資料倉儲（Data Warehouse, DW）。

如果資料科學家要做 AI 模型，可能又要再搬一次。

這種架構，養活了許多工具供應商，但代價是：

• 資料延遲：報表是昨天的
• 成本昂貴：同一份資料存了 3 次、算了 3 次
• 維護複雜：只要一個關卡斷了，流程就癱瘓

但我最近觀察到，這個情況正在改變。資料領域的供應商們不再各自為政，而是開始「垂直整合」。

3 大巨頭的「越界」戰爭

如果你也在觀察最近的趨勢，會發現資料界的領頭羊們，功能做得越來越重疊，邊界也越來越模糊。

1. Snowflake：從資料倉庫轉型 AI 平台

Snowflake 曾是「雲端資料倉儲」的代名詞，當年靠著運算與儲存分離的架構一戰成名，讓擴展這件事變得輕而易舉。

不過 Snowflake 顯然不滿足於只當個存放資料的倉庫。

最近，他們往 AI 領域進攻的腳步很快（像是 Cortex AI 服務）。邏輯很直覺：「資料在哪，AI 就在哪。」 與其讓客戶費工夫把資料搬出去訓練模型，不如直接在資料倉儲裡內建 AI 能力。

觀察這陣子的佈局，Snowflake 已經跳脫單純查詢引擎的框架，轉向打造一個完整的 AI 資料平台。

2. Databricks：從 ML 專家跨足資料庫

Databricks 的路徑剛好相反。這家以 Apache Spark 起家、專精大數據與機器學習（ML）巨頭，核心概念是「Lakehouse」，想把資料湖變得跟倉儲一樣好用。

最近，他們做得更徹底：發表 Lakebase，正式跨足 OLTP（交易型資料庫）。

以前他們是等資料搬過來再處理，現在提供一個基於 PostgreSQL 的資料庫，讓你的業務系統直接長在上面。

邏輯很簡單，既然資料最終都要進湖，做分析或跑模型，那為什麼不一開始就讓它「生」在我的平台裡？

這個舉動顯示 Databricks 正逆流而上。不只當後端的分析工具，也想成為底層資料庫。

3. Azure Fabric：讓搬運隱形的 Mirroring 技術

至於我最熟悉的 Azure，則推出了 Fabric。核心是 OneLake（概念就像資料界的 OneDrive）。

Fabric 強調 End-to-End 的流程整合，不僅包含資料庫與倉儲，連 AI、Spark 與報表工具都整合在一起， 也消除了 OLTP（交易處理）與 OLAP（分析處理） 之間的界線。

過去我們得手動開通多個服務，串接資料流。現在 Fabric 透過 Mirroring 技術，讓業務資料庫的變動，能即時同步到分析層，達成「湖倉一體」。

大家好奇，為什麼不需要進去查資料表也能同步？祕訣在於它讀取的是資料庫的「異動日誌」。

想像資料庫是一間繁忙的餐廳廚房。資料表（OLTP）就像是「冰箱裡的庫存」，你要盤點剩幾顆蛋，得開門進去數，這會擋住廚師的路（影響效能）。

而異動日誌則像是冰箱旁的庫存單，每進出一次，庫存單就記錄：「拿走 2 顆蛋」。

Mirroring 技術就是直接檢查那份庫存單，譬如看到廚房拿走 2 顆蛋，就同步在分析室（OLAP）的帳本上更新。

因為看的是「庫存單」而不是「冰箱」，所以不會撞到廚師，讓交易與分析能在同一個生態系中完成。

為什麼這對你很重要？

總結一下我們的觀察：

• Snowflake：由上而下（從倉儲往 AI 走）
• Databricks：由下而上（從機器學習往資料庫走）
• Azure Fabric：橫向掃蕩（用一個生態系把所有東西包起來）

不論是 Snowflake、Databricks 還是 Azure，雖然切入點不同，但目標都是：縮短資料從產生到發揮價值的距離。

對於企業來說，搬運與格式轉換的苦功正逐漸消失，而我們也能把更多精力放在挖掘商業洞見上。

當供應商完成垂直整合，對 IT 實務會帶來 3 個轉變：

1. 「資料治理」越來越重要

過去，工程師投入大量時間在處理資料搬運與格式轉換。隨著供應商將交易、分析與 AI 整合在同一平台，這些重複性的工作量將大幅減少。

架構師的價值，將從「規劃資料路徑」轉向「制定管理規則」。我們會花更多心思在資料的安全控管、確認資料正不正確，以及如何讓業務部門能自己撈資料、解決自己的問題。

2. 成本結構更單純

以前資料在不同服務間搬運，就像出國換匯，每換一次就被抽一次手續費（運算費）和匯差（存儲空間）。

現在一體化平台推動「一份資料、多種用途」。平台走向一體化，資料能做到只儲存一份，卻能同時被 SQL、Spark 或 AI 讀取。大幅減少了格式轉換產生的運算損耗，帳單更好懂了。

對企業管理層而言，也代表預算分配與資源利用率變得更清晰。

3. 加速決策

這是我最有感的轉變。

以前主管問現在的狀況，我們可能要回答「等明天的報表出來再說」。但在現在這種架構下，資料一進來就能直接分析。

當一筆交易產生的同時，AI 就能同步偵測異常或給出建議。讓技術支援與業務目標保持一致。

凡事總有不好

雖然整合很方便，但身為架構師，還是要提醒：凡事總有好不好。

選擇高度整合的平台，也代表「供應商鎖定」。哪天想換掉其中一個服務，成本會變高。

另外，整合平台並不代表能省去架構設計。相反地，因為操作門檻降低，資料量增長的速度會比以往更快。

當搬運變簡單了，垃圾資料（Garbage in, Garbage out）產生的速度也會變快。如果缺乏良好的資料治理，原本期待的一體化平台，可能在短時間內就堆積出大量資料，增加維護成本。

小結

觀察這些改變，可以幫助我們理解趨勢。這些整合是為了提高資料流動性，讓技術能跟上業務的速度。

如果你負責決策，現在是重新檢視「資料孤島」的好時機。

如果你是開發者，請不要只學工具操作，要理解背後的架構邏輯。

當你發現原本要寫好幾天的資料整合，現在能很快完成時，這代表技術替你省下了體力活。這多出來的時間，正好讓我們回歸本質，去思考更有價值的核心問題。

[caption id="attachment_210507" align="alignnone" width="845"] 專家論點【黃婉中】[/caption]

這篇文章 當 ETL 不再需要工程師：Databricks、Fabric、Snowflake 開戰，資料人的下一站在哪？｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

為何「提供存取」違法，分享如何運用 VDI、PIM等技術防線，轉為自動化合規。作者：黃婉中（雲端架構師）

為何「提供存取」違法，分享如何運用 VDI、PIM等技術防線，轉為自動化合規。

[caption id="attachment_210506" align="alignnone" width="778"] 工程師只是遠端連進去看一下畫面，沒有下載或儲存資料到電腦，這樣也會被認定不符合 GDPR 嗎？（圖／黃婉中提供）[/caption]

快速摘要

• 法規要求：根據歐洲資料保護委員會（EDPB）規定，只要資料從歐盟境內被傳輸或「提供存取」給位於第三國的對象，就必須遵守 GDPR Chapter 5 的跨境傳輸規則。
• 合規工具：根據 GDPR Chapter 5 Art 46，境外資料傳輸必須簽署標準資料保護條款 (SCC) 並執行傳輸影響評估 (TIA)。
• 技術防線：業界大廠通常透過虛擬桌面 (VDI)、臨時權限申請 (PIM/JIT) 以及客戶鎖箱機制 (Customer Lockbox) 來防堵風險。
• 不合規代價：2025 年 TikTok 因遠端存取控管不當，被重罰約 5.3 億歐元。

最近有客戶問我：「我們的客戶在歐盟，但支援團隊在中國。工程師只是遠端連進去看一下畫面，沒有下載或儲存資料到電腦，這樣也會被認定不符合 GDPR 嗎？」

更多科技工作請上科技專區：https://techplus.1111.com.tw/

答案是：會，而且可能罰很重。

延伸閱讀：聾啞創作者，如何用 AI 拿回創作的主控權？｜專家論點【黃婉中】

💡GDPR 全稱為 General Data Protection Regulation（通用資料保護規則），是一項歐盟的法律，目的是加強個人數據保護，是目前史上最嚴格的隱私法。

為什麼「看一眼」也不行？看看 TikTok 的例子

TikTok 在 2025 年被重罰 5.3 億歐元，原因之一，就是歐洲用戶的資料被中國員工遠端存取。

歐盟監管機構的認為，只要資料傳輸缺乏足夠的技術與法律保障（如 SCC 或 TIA），即便是為了技術支援，也被視為違法。

客戶問：「但工程師沒有儲存任何資料啊？」

在 GDPR 裡，資料處理不只是「存檔」。只要資料跨越了國境，進入了非合規地區，法律上就認定這是一次「資料傳輸」。

雖然你沒點「下載」，但工程師可以用手機翻拍螢幕、可以憑記憶背下客戶資料，讓敏感資料曝露在不受控的環境，風險與直接把檔案傳出去是一樣的。

💡遠端存取算傳輸嗎？ 算。根據 GDPR Art 4 對「處理 (Processing)」的定義：任何對個人資料的操作，包含讀取、使用或「提供存取 (making available)」，都算。

解決方案：國際大廠如何做到「防彈級」合規？

面對嚴格規定，跨國軟體公司通常準備了多層防護：

1. 簽標準資料保護條款 SCC

標準資料保護條款（Standard Data Protection Clauses，簡稱 SCC） 就像一份法律上的「保證書」。
企業必須與境外的支援單位簽署歐盟認可的合約，承諾：即便工程師人在境外，也會像在歐盟境內一樣嚴格保護資料。

2. 執行傳輸風險評估 TIA

傳輸影響評估 (Transfer Impact Assessment，簡稱 TIA) 是面對 GDPR 稽核時，證明企業已盡到「盡職調查」義務的證據。

自 Schrems II 判決後，法律要求單簽 SCC 已不足夠，出口商必須額外執行 TIA，確認目的地國家（如中國）的法律是否會干預資料安全。

軟體供應商如微軟，已經提供一份完整的跨境傳輸合規評估指南 (Compliance Assessment)，裡面詳細列出了針對目的地國家的法律分析與技術防護措施，幫助客戶大幅簡化 TIA 的撰寫過程。

客戶有時會把 TIA 與 DPIA 混淆，兩者雖都很重要，但重點不同：

• SCC (標準資料保護條款)：法律層面的「合約保證」。
• TIA (傳輸影響評估)：傳輸層面的「實地徵信報告」。
• DPIA (資料保護影響評估)：針對「資料處理過程」本身的風險評估（例如在 Azure 上運算的安全性）。

簡單來說：TIA 關注的是「跨境傳輸」，DPIA 關注的是「資料處理」，兩者缺一不可。

3. 使用虛擬桌面 (VDI)

虛擬桌面基礎架構 (Virtual Desktop Infrastructure，簡稱 VDI)，是最關鍵的技術防線。工程師不允許直接連線到資料庫，必須先登入一個位於歐盟境內的虛擬桌面（如 Azure Virtual Desktop）。

在這種架構下，工程師只能看到螢幕畫面，所有檔案無法下載、無法截圖，也無法將資料複製貼上到自己的本地電腦。

透過「資料不落地」的技術手段，確保敏感資訊始終留在歐盟境內的受控環境中。

4. 申請臨時存取權限

透過臨時存取（Just-In-Time，簡稱 JIT） 與特權身分管理（Privileged Identity Management，簡稱 PIM) 機制，達成「零常駐權限」的資安原則。

工程師平時不具備任何存取身分，只有在處理特定案件時，才能申請約 2 小時的臨時授權。

任務一旦結束，系統便會自動回收權限，且全程留存詳細的操作紀錄 (Logs)，確保每一筆存取都有跡可循。

5. 設置客戶核准機制

客戶鎖箱機制（Customer Lockbox） 是最後一道關卡。即便內部工程師申請了臨時權限，當他準備進入系統存取資料時，仍必須由客戶端的管理員點下「同意」，工程師的螢幕才能看到畫面。

這項機制將資料的「最終決定權」交還給客戶，確保任何一次存取，都是在客戶知情且授權的情況下發生。

談話中，我發現客戶對於合規報告，以及雲端工具如 Defender for Cloud (DFC) 如何自動化監控這些規則，很感興趣。

我發現對話已經從法條解釋，轉移到了技術實戰。

後來，那位客戶沒再問過我「看一眼行不行」的問題了。

[caption id="attachment_210507" align="alignnone" width="1038"] 專家論點【黃婉中】[/caption]

這篇文章 只是遠端看一眼也算「傳輸」？從 TikTok 被罰 5 億歐元看 GDPR 跨境合規｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

如果有一天，你發現一個完全不懂程式、甚至連母語書寫都有困難的人，竟然能自己開發出一套創作工作流和 AI 助手。你的第一直覺是什麼？作者：黃婉中（雲端架構師）

如果有一天，你發現一個完全不懂程式、甚至連母語書寫都有困難的人，竟然能自己開發出一套創作工作流和 AI 助手。你的第一直覺是什麼？

[caption id="attachment_208155" align="alignnone" width="873"] 一個完全不懂程式、甚至連母語書寫都有困難的人，竟然能自己開發出一套創作工作流和 AI 助手。你的第一直覺是什麼？（圖／AI生成）[/caption]

這不是科幻劇本，而是最近在韓國真實發生的故事。

一個關於「重新連線」的故事

故事的主角是 Min-ji So，她是一位聾啞畫家，在 Instagram 上用漫畫分享她作為聾啞母親養育聽覺正常孩子的日常生活。

更多科技工作請上科技專區：https://techplus.1111.com.tw/

對我們來說，韓語或中文是母語，但對聾啞人士而言，手語才是他們的第一語言。書寫文字（如韓文或中文）對他們來說更像是「第二外語」。

Min-ji 在創作網漫時，最感到挫折的是無法精準掌握文字的細微差別。例如韓語中「我不知道」與「難道你不知道嗎？」在語氣上的微妙差異，常讓她卡關。

過去，她必須依賴真人編輯幫她修稿。但這產生了兩個問題：第一，必須等真人回覆，創作流會中斷；第二，創作能不能往下掌握在別人手裡，讓人感到「失去自主權」。

後來，她參加了微軟的 AI 計畫，利用 Copilot 開發了一個「網漫分鏡助手」，一個 AI Agent。當她輸入簡單的意圖，AI 會反過來問她：「你想表現的是衝突感嗎？」、「要不要試試用劇本式的台詞來強化張力？」

Min-ji 說：「感覺就像多了一位創意助理。」

觀察一：意圖導向架構（Intent-based Architecture）

從這件事，我看到的第一個技術轉型是：我們正在告別 GUI（圖形介面），迎向 Intent（意圖）。

過去30年，介面設計（UI/UX）是軟體開發的重點。我們設計了各種按鈕、選單、下拉視窗，假設使用者是「標準人」，訓練他們學會我們的系統邏輯。如果使用者有特殊需求（比如視障或聽障），我們就補一塊「無障礙（Accessibility）」的補丁（Patch）。

但 Min-ji 的案例告訴我們，未來的架構將會是 「去介面化」 的。 使用者不再需要去適應軟體，而是軟體要具備「語義層（Semantic Layer）」來理解使用者的意圖。

未來的系統前端可能只是一個對話框或語音窗口，但後端需要強大的 Orchestration（編排）能力。系統必須能從模糊的語義中解構出邏輯，並驅動下層的 API。

這就是所謂的「意圖導向架構」。當系統能理解意圖，原本屬於「邊緣案例」的弱勢需求，就會自動變成系統的「原生能力」。

觀察二：將專家服務「Serverless 化」

第二個觀察是關於能力解耦（Decoupling）。

在 Min-ji 的舊流程中，「編輯與校對」是一個中心化的資源，必須仰賴特定的人力。這在系統設計上叫作「單點故障（SPOF）」，如果編輯請假，創作就癱瘓。

但在 AI 時代，這種「專業能力」正在被 SaaS 化與 Serverless 化。 以前我們談 Serverless 是指運算資源（CPU/RAM）按需分配，現在談的是「能力（Capability）」按需分配。

編輯、法律諮詢、代碼審查、數據摘要，這些原本壟斷在專家手中的隱性知識，現在被封裝進了大型語言模型（LLM）中，成為可以隨時呼叫的 API。

這對企業軟體架構有巨大的衝擊。想像一下，未來的 ERP 系統不再需要請會計師一一核對，而是由一個「會計 Agent」自動偵測數據異常並給出建議。這種「能力的去中心化」讓個體（如 Min-ji）擁有了以前只有大型工作室才有的「智庫」。

不只是身障者，我們每個人都在受益

你可能會說，我不是聾啞人士，這跟我有什麼關係？ 其實，我們或身邊的人在某些時刻都是「有障礙者」。

• 過動症（ADHD）者：在冗長的視訊會議中難以集中，AI 摘要讓他更專注。
• 口吃者：在重要簡報前，AI 語音修飾工具能將斷續的語音轉化為流暢的音軌。
• 菜鳥工程師：在面對複雜的 Legacy Code 時，AI Agent 幫他版本升級。

結語

當 Copilot 或是各種 AI Agent 成為標準配備，SaaS 產品的競爭點漸漸從「功能多寡」，轉向「理解深度」。

從架構師的角度來看，AI 賦能（Enablement）的核心價值在於擴展人類的能力邊界。它就像就像「數位義肢」一樣，接上斷掉的連線，幫助我們前往更多被遺忘的角落。

這篇文章 聾啞創作者，如何用 AI 拿回創作的主控權？｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

每週三，74 歲的 Michael 坐在倫敦的公寓裡，等著電話響起。電話那頭是他的志工朋友 Gemma。他們什麼都聊，從偵探小說聊到 Gemma 家的小狗。這通電話對 Michael 來說是救命稻草，讓他覺得自己還跟這世界連接著。作者：黃婉中（雲端架構師）

每週三，74 歲的 Michael 坐在倫敦的公寓裡，等著電話響起。電話那頭是他的志工朋友 Gemma。他們什麼都聊，從偵探小說聊到 Gemma 家的小狗。這通電話對 Michael 來說是救命稻草，讓他覺得自己還跟這世界連接著。

[caption id="attachment_208147" align="alignnone" width="783"] 接受 AI 隨時監聽你的心事嗎？或者你覺得，直接跟 AI 聊天反而更自在？（圖／AI生成）[/caption]

但我最近讀到這則報導時，注意到一個細節：這兩人的對話，後台其實有一套 Azure 的 AI 系統在「監聽」。

以雲端架構師的角度來說，這是一個很棒的技術落地案例。今天我想跳脫感性的故事，從技術人的角度聊聊我的幾個觀察。

更多科技工作請上科技專區：https://techplus.1111.com.tw/

效率革命

Age UK 服務的長者很多，疫情後通話量更是暴增。在傳統架構下，若要確保通話安全（防止志工詐騙或長者發生意外），工作人員必須「肉身監聽」。

假設一名全職員工一天工作 8 小時，他頂多只能完整聽完 16 通 30 分鐘的電話。如果要覆蓋 3 萬通以上的通話，人力成本將是天文數字。

他們採用了 Azure OpenAI 的語音轉文字（Speech-to-Text）技術。這套系統至今轉錄了超過 30,700 通電話，AI 自動過濾掉大半無風險的對話，只有約 3% 的通話需要人工介入。

這種效率倍增，是技術帶來的紅利。它讓社會福利服務從勞力密集型的「手工業」，轉化為具備雲端彈性的「智慧服務」。

是保護還是審查？

但在閱讀技術細節時，我還是覺得有點毛毛的。報導提到，系統會針對 500 個敏感詞進行監控，包括「肚子餓」、「見面」、「旅館」甚至是「WhatsApp」或「TikTok」。只要觸發關鍵字，系統就會評分並交由審查員重聽。

這讓我想起專制政權的言論審查。「保護」與「監聽」只有一線之隔。

雖然通話雙方都知道有錄音，但如果我知道自己講的每一句話都在被演算法掃描，可能很難聊得自在。

當我們為了保護長者不被詐騙而錄音，是否也剝奪了他們的隱私權？長者在通話時，如果知道每一句話都在被 AI 掃描，他們還能坦誠地分享那些微小、破碎但珍貴的心事嗎？

架構師的解藥：數據治理與被遺忘權 

如果你問我如何優化這套架構以降低不安感，我會建議從以下幾點著手：

1. 存取控制（RBAC）： 嚴格定義誰有權限調閱轉錄稿與錄音，並留下完整的審核日誌（Audit Log）。
2. 數據生命週期管理： 只要 48 小時內沒人回報問題，數據就應該物理刪除。實踐 「被遺忘權」。
3. 知情同意： 必須向長者解釋：「錄音是為了在您遇到困難（譬如被騙）時，我們能及時伸出援手。」，並獲得同意。

當 AI 成為完美的伴侶：人類志工還有位子嗎？

報導中還有一個觀點讓我思考：現在 AI 聊天技術已經這麼強，為什麼不直接讓長者跟 AI 聊就好？

從功能來看，AI 簡直是「完美伴侶」：

• 超有耐心： 它不會嫌你重複講年輕時的故事。
• 物理安全： AI 沒有銀行帳戶，不會騙走長者的退休金。
• 24/7上線： 它不怕被打擾，不需要睡覺。

但友誼的本質是雙向的。志工 Leigh 在文中提到，她在這段關係中也感到了「被需要」的快樂。這種人與人之間的情感流動，是目前 LLM（大型語言模型）即便模擬得再像，也無法真正產生的「靈魂連結」。

不過，從使用者體驗（UX）來看，這種服務也有缺陷。如果長者每次配對到的都是不同志工，每次都要重新介紹自己的生平、病史與愛好，會膩吧？

「狀態化」設計

未來這類架構可以引入「狀態化（Stateful）」的設計。AI 可以幫忙總結（Summarize）上次的談話重點，讓下一位志工接手時，先看過上次對話重點，關心長輩：「Michael，你上次說膝蓋痛，這週好點了嗎？」這種技術輔助，能幫助友誼延續。

結語

身為一名雲端架構師，我常說「技術是中性的」。同樣的語音識別技術，可以用來追蹤異議人士，也可以用來挽救一個被扣款 900 英鎊而焦慮不已的孤獨老奶奶。

我沒有一個完美的標準答案來消除那種「被監聽」的負擔感。但我認為，技術應該扮演「沉默的守護者」。 我們的努力方向，是建立一個能讓脆弱的人們安全交流的空間。

如果你是 Michael，你會為了這份安全感，接受 AI 隨時監聽你的心事嗎？或者你覺得，直接跟 AI 聊天反而更自在？歡迎留言跟我聊聊你的看法。

這篇文章 如果 AI 知道你所有的心事：長者陪伴電話背後的精靈｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

在IT圈，我們常聽到 Whiteboarding（白板討論）。這詞聽起來專業，其實說白了，就是「拿起筆，直接在白板上邊畫邊跟人討論」的過程。作者：黃婉中（雲端架構師）

在IT圈，我們常聽到 Whiteboarding（白板討論）。這詞聽起來專業，其實說白了，就是「拿起筆，直接在白板上邊畫邊跟人討論」的過程。

[caption id="attachment_206099" align="alignnone" width="835"] Whiteboarding（白板討論）。這詞聽起來專業，其實說白了，就是「拿起筆，直接在白板上邊畫邊跟人討論」的過程。（圖／AI生成）[/caption]

在 UI/UX 或軟體工程師的面試裡，這種形式很常見。但在雲端架構師的場景中，大家似乎比較少把它當成一項必修課。不過根據我的經驗，這是一個在簡報之外，非常實用的溝通輔助工具。

為什麼不只用簡報？

身為雲端架構師，我們習慣準備一疊厚厚的簡報。但架構有時很複雜，不管是混合雲遷移還是資料分析，投影片講久了，有時候客戶不一定能完全跟上。

這時 Whiteboarding 就派上用場了。它不是要「取代 」簡報，而是「補充」。當客戶對某個細節有疑問時，放下雷射筆、拿起白板筆，把死板的簡報切換成動態討論。這能幫助雙方把認知對齊，讓討論更聚焦。

簡報是靜態且封閉的，當客戶對某個設計有疑慮時，翻找投影片常會打斷思考。白板則提供了靈活性，而且不需要從零開始。通常我會先畫好核心框架，在簡報過程中針對客戶關心的特定節點進行補充。

以下跟你分享3個適合「動筆」的場景。

白板技術在不同情境的應用

1. 釐清需求：確認目前遇到了什麼問題

我常用白板和客戶盤點現有架構痛點。客戶通常比較冷靜，不會主動描述細節。這時，我會在白板上劃出簡易的現況圖（As Is），並針對可能有優化空間的部分（如資料庫、特定串接點）詢問客戶的看法。

看著圖討論，通常比對著簡報的條列清單更容易讓客戶確認現狀，減少雙方的認知誤差，也能確認哪些是優先事項。

2. 梳理需求：達成共識

一個例子是討論資料如何從地端搬遷到雲端。 企業專案經常有多種資料來源（如不同資料庫、第三方 API），簡報的更新常趕不上變動。我不止一次聽到客戶邊看簡報邊說：「這裡後來我們又加了東西，來不及畫在上面。」

我會直接在白板上畫出資料流。討論內容包含：這段資料是 Batch 還是 Real-time？傳輸過程需不需要處理去識別化？我發現這麼做以後，能夠省下許多會後email來往確認的時間。

3. 處理突發提問：展示方案的彈性

白板也很適合在既有的方案架構上，針對客戶特定需求進行局部調整。當客戶提出「如果以後要擴充到其他區域，這套架構怎麼改？」這類假設性問題時，白板就是最好的補充工具。

即使現場沒時間去改簡報，我會直接在原有的圖上繼續補充，讓客戶理解這份方案是可以根據需求微調的。

給架構師的實作建議

• 預先畫好底圖：現場時間有限，我通常會在會議開始前，先畫好大約 70% 的基礎架構。正式討論時，只針對需要變動的部分動筆，這樣比較省時間，也維持溝通的節奏。
• 工具分工：PPT 用來呈現最終目標跟結論、白板則用來處理討論過程中的變數。
• 拍照留存：建議討論完後，當場用手機拍下白板圖，直接貼進當天的會議記錄（Meeting Minute）。這能確保「共識」被保存下來，不會因為白板被擦掉就沒了。
• 參考公開資源：想學習如何把複雜雲端架構畫得清晰，可以參考 YouTube 上的 John Savill，他的視覺化邏輯非常值得學習。

結語

白板不需要畫得像藝術品，只要能把邏輯講清楚就夠了。誠如那句老話：「A picture is worth a thousand words」（一張圖勝過千言萬語）。

在雲端架構這種資訊量大的工作中，白板是一個能幫你把複雜事物變簡單的工具。下次發現會議溝通有點卡關時，不妨拿起白板筆試試看。

這篇文章 雲端架構師實測：除了 PPT，為什麼你也該試試「白板討論」？｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

讀者常問我：顧問究竟在做什麼？既然顧問也懂技術，跟工程師有什麼不同？跟你舉個例子作者：黃婉中（雲端架構師）

讀者常問我：顧問究竟在做什麼？既然顧問也懂技術，跟工程師有什麼不同？
跟你舉個例子。

雲端成本大增

前陣子《中途筆記》網站常常斷線無法使用，原因是 CPU/Memory 常會無預警的不夠用，導致頻繁斷線。

[caption id="attachment_206094" align="alignnone" width="779"] 顧問解決商業目標，而工程師搞定技術（圖／AI生成）[/caption]

觀察虛擬機器數據後，發現多數時候利用率都很低，也查不出具體原因。為了讓網站運行更穩定，我打算加上異地備援（DR）並同步進行成本優化（FinOps），將網站遷移至更合適的虛擬機器（VM）。

我的虛擬機器放在雲平台上，因此先嘗試更換虛擬機器，卻發現沒有一台機器可以選，於是開了一張 ticket 請求支援。

得到答案是我放機器的東南亞區域已經沒有容量，客服工程師建議我在東亞區域開。隨後說東亞區域容量申請完成了，可以關單了嗎？

我說換區域沒問題，但你得教我怎麼搬遷。他於是聯繫了一位虛擬機器工程師，向我解釋怎麼把同台虛擬機器搬到東亞區域。又問可以關單了嗎？

我覺得不對勁，平常幫客戶作搬遷不是這樣的阿。通常會跟客戶討論計畫，說明會造成哪些停機時間、需要多少時間能復原、對使用者影響有多少等，而你們只是教我怎麼複製磁碟？

再次解釋這只是複製而不是搬遷，網路都沒設定呢。新虛擬機器的網址根本與《中途筆記》的 IP 無法關聯。客服於是又聯繫了一位網路工程師。

網路工程師研究了幾天後回應：沒有問題啊，我看你網站好好的，可以存取，問題在哪呢？

我簡直快暈倒，說目前可以運行是因為機器現在還在東南亞區域上面跑，關掉以後怎麼存取呢？中間解釋了半天，這位工程師顯然對於一個對外網站背後，有一台虛擬機器、怎麼運作都很陌生。

總結一下目前為止發生的事：

1. 區域工程師： 告訴我東南亞區沒容量了，建議改開東亞區。他完成了容量申請，隨即問：「可以關單了嗎？」——他只在意他管轄的「配額」。
2. VM 工程師： 教我如何複製磁碟，卻無視我的網站還在運行。他問：「可以關單了嗎？」——他只在意「資料有無搬移」。
3. 網路工程師： 研究幾天後回覆：「網站現在跑得很好啊，問題在哪？」他忘了，現在跑得好是因為我還沒切斷舊主機的連線。——他只在意「當下的連線狀態」。

這張 ticket 開了兩個月，我都從台灣飛到澳洲了，問題還卡在原地。已經從「技術問題」，延伸到「溝通斷層」。

這 3 位工程師的技術能力可能都非常頂尖，但他們被框在各自的指標（KPI）與工作範圍（Scope）裡

• 區域工程師的 KPI 是「配額管理」。
• VM 工程師的 KPI 是「虛擬機存取」。
• 網路工程師的 KPI 是「連線通暢」。

當每個人都只守著自己那一塊「拼圖」時，就沒人在意整張「拼圖」最後長什麼樣子。對雲端平台商來說，他們每個環節都按照標準流程（SOP）走，技術上完全沒錯。但對客戶來說，我正在燃燒雲端預算、承擔斷線風險，這就是最大的商業損失。

這也是為什麼很多大公司雖然擁有最頂尖的工程團隊，專案卻依然會延宕，原因不是技術不夠，而是缺乏一個能把技術拼圖組裝起來、看見全局的人。

工程師搞定技術，顧問解決商業目標

注意到了嗎？使用者跟工程師使用的語言天差地遠。

對使用者來說，目標是：更省錢、更穩定地運行業務（Business Goal）。 對工程師來說，目標被拆解為：複製磁碟、修改 A 紀錄、配置網段（Technical Task）。

而不同專長的工程師團隊中間彼此不溝通、也不在意對方在做什麼。對於他們來說，「搬遷」是一個太模糊的詞彙，要細到具體技術目標，譬如複製磁碟、修改 A 紀錄等，才夠具體。

讀到這裡，你可能會好奇故事的結局是什麼？結局是我心一橫，決定將網站搬遷到另一個提供搬遷解決方案的主機商，從下單到搬遷完成只花了半天。

工程師負責產品，顧問熟悉解決方案

這就是「產品思維」與「解決方案思維」的差異：工程師負責產品，而顧問要熟悉解決方案。這個例子中，平台商是賣虛擬主機產品，而主機商賣的是搬遷解決方案。也許雲平台的主要客群都擁有一定技術能力，而不像我一樣是以營運目標為首要考量的使用者。

顧問知道搬遷並順利運行是一個技術目標，而背後的商業目標是什麼？是網站能順利的運行，所以產品能繼續銷售、公司能繼續賺錢。

此外，他還需要清楚使用者有哪些限制和期望。能用使用者的語言溝通，而不會拋出一堆聽不懂的專有名詞。更重要的是可以一步到位，不需要使用者顧前顧後，拆解成數個步驟。

• 工程師負責產品（Product）： 確保每個零件（VM、Network、Storage）正常運作。
• 顧問熟悉解決方案（Solution）： 確保這些零件組合起來，能讓客戶的網站賺錢、省錢、避險。

當然，因為執掌和專案類型不同，有時工程浩大、參與其中的成員太多，工程師沒有問題的全貌是常態。顧問也沒有工程師的技術深度。我只希望用這個例子告訴你兩種職能的差異。

科技人的轉型關鍵：從「搞定技術」到「交付價值」

如果你希望從純技術職轉向顧問職，或是在科技產業中發揮更大的影響力，這場搬遷經驗整理出的 4 個「顧問思維」核心是關鍵：

1. 鎖定最終目的地（Business Outcome）： 不糾結於技術路徑的岔路，而是問：「這動作能否達成商業目標？」
2. 提供量身訂做的解決方案： 清楚客戶的限制（如：預算、停機時間），而不是只給標準手冊。
3. 翻譯官的能力： 用客戶聽得懂的語言溝通，將「磁碟 I/O」轉化為「使用者體驗」。
4. 一步到位的交付： 顧問的價值在於「整合」，不需要客戶像拼圖一樣自己去湊合各個部門。

試著在下次接到需求時，多問一句：「這個調整對公司的業務目標有什麼幫助？」當你開始思考這個，就在通往顧問的路上了。

這篇文章 別只會搞定技術！科技人從「產品」跨向「解決方案」的4個顧問核心思維｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

解析自建 JWT 認證的隱形風險，並從 TCO 與資安角度，說明為何多數企業更適合採用託管身分服務而非自行打造。作者：黃婉中（雲端架構師）

解析自建 JWT 認證的隱形風險，並從 TCO 與資安角度，說明為何多數企業更適合採用託管身分服務而非自行打造。

[caption id="attachment_202689" align="alignnone" width="810"] 可以把 JWT 想像成一隻鑰匙，而認證伺服器（Identity Server）就是負責保管的鑰匙盒。（圖／黃婉中提供）[/caption]

身為雲端架構師，我常在會議中聽到的技術方案是：「我們打算用 JWT (JSON Web Token) 自建認證系統，既彈性又免費。」這聽起來很專業、主流，但這時我都會問團隊一個問題：「如果這台負責簽發 JWT 的伺服器被駭客做了一個 Snapshot (快照)，我們有什麼配套措施？」

延伸閱謮：如果你的Agent不能被「評估」，那它可能還沒準備好上線｜專家論點【黃婉中】

一、 誰拿走了你的「印鈔機」？JWT 的隱形危機

要理解這個問題，我們得先跳脫技術名詞。你可以把 JWT 想像成一隻鑰匙，而認證伺服器（Identity Server）就是負責保管的鑰匙盒。

在「自建認證系統」的架構下，工程師會用一串長長的、保密的「私鑰」（Private Key）來簽署每一張發出去的 JWT。只要後端 API 看到這串 JWT 上的簽章是對的，就會無條件放行。

這看起來很完美，直到 Snapshot (快照) 出現。

在雲端維運中，「磁碟快照」是標準作業。然而，如果你是「自建」認證系統，這把重要的「私鑰」通常就存在伺服器的環境變數或記憶體中。一旦有心人士取得了這台伺服器的快照，就能在自己家裡打造出一模一樣的鑰匙。

這是一個很現實的資安盲點：駭客不需要攻破你的資料庫，你的系統就會毫無防備地打開大門。

二、物理級的安全：為什麼「託管服務」成為主流？

為了應對這種軟體層面的漏洞，業界的標準解法是將金鑰儲存在 HSM (硬體安全模組) 中。這是一個「只能進、不能出」的硬體晶片。

託管服務（IDaaS，Identity as a Service）無論是 Microsoft Entra ID、Okta 還是 Auth0，這些服務的核心價值在於背後的基礎設施。它們將簽章私鑰鎖在物理級的 HSM 中，即便伺服器被快照，私鑰也無法被帶走。

以 Entra ID 為例，那把負責簽章的私鑰是鎖在微軟機房的 HSM 晶片中的。當伺服器需要簽發 JWT 時，會把資料傳進晶片中，完成數位簽章（Digital Signature）後，再吐出來。即便駭客真的駭進了雲端節點、拍了快照，也帶不走私鑰。

這種「物理級隔離」與「自動金鑰輪替 」(Key Rotation)，是多數企業自建系統時，受限於成本與人力難以做到的。這也是為什麼身分驗證逐漸從「自研開發」轉向「專業服務」的原因。

三、 破解 Netflix 迷思：大廠自建是因為「不得已」

很多工程師會問：「既然託管服務這麼好，為什麼 Netflix、Uber 這些大廠還要大費周章自建身分系統？」
大廠選擇自建，通常是基於兩個需求：

1. 規模與成本：簡單來說就是「規模經濟」， 對於擁有數億使用者的 B2C 產品，IDaaS 的授權費會是一筆天文數字。當規模大到一定程度時，自建系統的研發和維運成本會低於授權費。
2. 極端效能： 為了讓全球使用者在幾毫秒內完成驗證，大廠需要高度客製化的協議。

但對於多數的企業來說，我們並沒有 Netflix 的規模，也沒有等量的研發資源去處理 24 小時的資安維護。大廠的方案是「解藥」，但對多數企業來說可能是「毒藥」。

四、 架構師的算盤：從 Buy vs. Build 看 TCO

在決策「Buy vs. Build」時，我建議從 TCO (總持有成本) 來評估：

• 自建（Build）： 看似免費，但你需要負擔 MFA 開發、密鑰管理、修補漏補、以及萬一出事時的企業信譽損失。
• 託管服務（Buy）： 雖然有授權費，但你買到的是「合規性」與「風險轉移」。將最脆弱、風險最高的身分管理交給專門的公司（如微軟或 Okta）處理，讓你的團隊專注在核心業務上。

五、 小節與實務建議

身為在第一線接觸客戶的架構師，我見過不少選擇自建，最後卻在資安稽核或擴展性上踩坑的案例。

身分驗證不應該是展現技術複雜度的地方，它應該是系統的基礎。當你理解了快照風險與 HSM 的必要性，就能理解為什麼許多企業客戶都轉向專業託管服務。

下次討論架構時，我們可以多想一步：是要蓋一座自己的發電廠，還是只要按個開關就能有穩定的電力？

最後是我給你的 3 點小建議：

• 安全性考量： 若非得自建，請將私鑰存放在 Azure Key Vault 或 AWS KMS 這類的服務中，不要大喇喇放在伺服器裡。
• 決策基準： 使用者規模在百萬以下時，租用（IDaaS）通常比自建更划算且安全。
• 合規性： 若你的產業有 ISO 27001 或金融稽核需求，專業的託管服務能幫你省下大量的合規成本。

這篇文章 自建 JWT 身份驗證服務器 vs 身分即服務(IDaaS)：你是在省授權費，還是買下全部風險？｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

最近在跟客戶討論架構改善時，遇到了一個挑戰：客戶的 API Server 跑在 Azure VM 上，想強化安全，但對「API 管理工具 (APIM)」的高昂月費感到猶豫。作為架構師，我的職責是幫客戶在「風險」與「預算」之間找到平衡。這篇文章想分享：如果你也不想一次就買整套工具，該怎麼做到安全？作者：黃婉中（雲端架構師）

如何用分層防護在「安全」與「預算」間取得平衡，並判斷什麼時候才真的需要 APIM？

[caption id="attachment_202695" align="alignnone" width="827"] 如何用分層防護在「安全」與「預算」間取得平衡。（圖／黃婉中提供）[/caption]

最近在跟客戶討論架構改善時，遇到了一個挑戰：客戶的 API Server 跑在 Azure VM 上，想強化安全，但對「API 管理工具 (APIM)」的高昂月費感到猶豫。

作為架構師，我的職責是幫客戶在「風險」與「預算」之間找到平衡。這篇文章想分享：如果你也不想一次就買整套工具，該怎麼做到安全？

為什麼大家愛用 VM 自架 API？

其實理由很單純：省錢、順手、好控制。 很多公司覺得 API 沒幾個，自己寫程式就能擋掉一些惡意攻擊，為什麼要每個月多花幾百塊美金去買一個「管理介面」？這個想法沒錯，但在「安全」跟「預算」之間，我們得找個平衡。

3 種等級的防護

在雲端的世界裡，保護 API 就像經營一間餐廳，防護等級決定了你能擋住什麼樣的麻煩。
有這 3 種情境：

第一層：基礎設定

這就像是幫 VM 裝鐵窗（自己動手，免費）。

• 網路安全性群組規則（NSG）： 限制只有特定的 IP 可以連到這台 VM。
• 受控識別（Managed Identity）： 就像「刷臉認證」。別把資料庫密碼寫在程式碼裡，讓 VM 透過自己的「身份」直接去領取存取權。

第二層：專業保全（Application Gateway + WAF）

如果 API 要開放給合作夥伴，可以加裝 WAF (網站防火牆)。它專門擋 SQL 注入或惡意腳本。
但要注意，保全只管進來的人是不是壞蛋，管不了「這個人是不是太常來（頻率過高）」。

第三層：秘書管理（APIM）

這就是客戶目前還沒打算用的。
APIM 更像秘書，能做到：

• 限流 (Rate Limiting)： 保全管不了訪客一直按門鈴，但秘書可以。秘書可以規定「小明每分鐘只能點五道菜」，防止有人瘋狂呼叫，把伺服器拖垮。
• Developer Portal： 秘書會幫你寫好說明書（Swagger），讓客人自己看跟申請，省下你每天解釋 API 怎麼接的時間。

既然有保全，為何還要秘書？

回到案例，客戶的架構其實已經做得不錯，結合了 Private Link（讓服務只走自家通道）、Azure Monitor（紀錄紀錄呼叫足跡）以及 WAF（阻擋惡意攻擊）。

客戶問：「既然夠安全了，還有必要買 APIM 嗎？」
我的看法是：從「安全」來看已經足夠，接著要看的是「管理」需求。

如果面臨以下情境，秘書就有其必要性：：

• 使用者眾多且複雜：不只是自己人用，還有外部合作夥伴。
• 需要分級制度：需要針對不同對象限制不同的呼叫次數（配額管理）。

如果暫時不想買 APIM，我會怎麼建議？

如果暫時沒有管理需求，我會建議在程式碼裡寫好：

1. 限流： 在程式邏輯中偵測 IP 請求頻率，太頻繁就暫時不理。
2. 日誌完整性：確保 VM 的紀錄有完整保留，否則出事時就像監視器沒插記憶卡，什麼都查不到。

結論：架構沒有對錯，只有「現在適不適合」

我一直認為最適合的架構，必須評估當下的預算與規模。
如果你的 API 只有 1-2 個，而且只有自己人用，WAF、Private Lnk 和 Azure Monitor 其實就夠用了。
但如果有一天，你的 API 變成了「產品」，要給更多人用，那時候請個 APIM（秘書） ，絕對比工程師加班修伺服器還要划算。
安全是動態的，你的架構也要跟著業務一起長大。

延伸閱謮：如果你的Agent不能被「評估」，那它可能還沒準備好上線｜專家論點【黃婉中】

💡 最後分享兩個「不花錢」的安全小撇步：

1. 檢查 NSG 規則：確認是否限制「只有來自 Gateway 的流量」能進到 VM？這能防止駭客繞過防火牆直接攻擊你的主機 IP。
2. 開啟 Microsoft Defender for Cloud：它的基礎版是免費的，能自動掃描 VM 設定（如防火牆開關、硬碟加密等）。雖然進階「漏洞掃描」要付費，但光是基礎版就能幫你擋掉許多低級錯誤，不拿白不拿！

這篇文章 身為架構師，我什麼時候會勸客戶別急著買 API 管理工具（APIM）｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

自從 AI Agent 這個概念被大量討論，很多企業都急著進入 PoC 階段。
一開始大家關注的重點，多半放在資料來源、工作流能不能跑、安全機制夠不夠。再來就是應用案例和常見疑慮。作者：黃婉中（雲端架構師）

自從 AI Agent 這個概念被大量討論，很多企業都急著進入 PoC 階段。
一開始大家關注的重點，多半放在資料來源、工作流能不能跑、安全機制夠不夠。再來就是應用案例和常見疑慮。

[caption id="attachment_201845" align="alignnone" width="768"] 評估是一項容易被低估，卻對Agentic AI穩定上線影響很大的能力。（圖／AI生成）[/caption]

只要系統動得起來，「評估」往往被當成後面的事。隨著專案往前走，討論焦點才會慢慢轉移。

前陣子我和幾位資深架構師聊天，大家都同意：評估是一項容易被低估，卻對Agentic AI穩定上線影響很大的能力。

原因很簡單，很多 Agent 在 PoC 階段都「看起來正常」：流程跑得動，問題丟進去也有回答，測幾個案例都過得去，於是就上線了。

真正讓人頭痛的狀況，通常在上線之後。

例如：

• 同樣問題，回答長度開始忽長忽短
• 原本會引用具體資料來源，後來開始「腦補」
• 任務表面上有完成，仔細一看發現跳過某些步驟

整個流程沒有明顯的失敗訊號，但團隊卻發現：需要人工介入的地方變多了。

這類問題，很難靠單次測試發現，需要的是能重複執行、可以拿來比較的評估流程。

「評估」是在做什麼？

在營運階段，評估除了人工抽樣，也定期跑一組評估流程。

常見做法是：

• 準備一批測試資料
• 讓模型或 Agent 在同樣條件下跑一次
• 把輸出結果拿來比對與量化

這個過程的重點，是確認現在的表現，跟之前相比有沒有變化。

為什麼評估不能只靠一種指標

Agent 的輸出，大多是自然語言。
而自然語言的「好不好」，很難用單一數字定義。

因此實務上，評估通常會混合幾種不同角度的指標。

延伸閱讀：帳單暴增 100 倍，客戶竟然沒發現：雲端被挖礦，比你想的更常見｜專家論點【黃婉中】

第一類：用AI檢查AI

有一類評估方式，是讓模型協助判斷輸出品質。

這類指標關心這些問題：

• 回答是否有依據，而不是腦補
• 內容前後是否連得起來
• 回答可讀性、是否通順

這類評估，適合用在：

• 沒有標準答案的任務
• 開放式問答
• 摘要、解釋、建議型輸出

它們給你的是一個品質區間，用來觀察是否開始退步。

第二類：數學型指標

另一類評估是傳統NLP的做法。

前提是：
你手上有一組「正確答案」，可以拿來比對。

在這種情況下，可以用一些常見的數學指標來看，譬如與標準答案的重疊程度。

這類指標的好處是穩定、可重複，適合用在資料抽取或分類的情境。不過缺點也很明顯：
只適用在我們「已經知道正確答案」的任務。

第三類：風險與安全相關的檢查

評估也能確認內容是否安全。

實務上，常見會檢查：

• 是否出現自殘或極端內容
• 是否涉及仇恨、歧視
• 是否包含暴力或性相關描述

這類評估，能夠提早標記可能有問題的輸出。

很多平台會用既有模型來協助判斷風險程度，給出一個嚴重性分數，讓系統或人決定後續怎麼處理。

在Ｍulti-agent 架構中，評估不可或缺

當系統變複雜，評估很自然會被拉進流程裡。

例如：

• 其他Agent 完成任務後，由另一個 Agent 檢查是否符合基本條件
• 結果若品質偏低，就要求重試或調整策略
• 若出現風險訊號，直接中止流程或轉人工處理

在這種設計下，評估從獨立的分析步驟，變成系統的一部分，用來定期確認輸出是否仍在可接受範圍。

評估的價值

Agent 一旦上線，就會受到資料、使用方式和時間影響。

評估機制能提醒我們：

• 現在的結果，跟之前比起來有沒有不一樣
• 系統是不是開始偏離原本用途
• 哪些任務類型需要多注意

有了這些訊號，你才知道什麼時候該去調流程，或重新檢視模型選擇。
沒有這些訊號，很多問題不會消失，只是等到人工成本變高時才浮現。

這篇文章 如果你的Agent不能被「評估」，那它可能還沒準備好上線｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

在 Agent 專案裡，有一種狀況特別折磨人：系統沒有報錯，Agent 也有回應，流程看起來跑完了，但當使用者問：「剛剛那個結果，是怎麼產生的？」你卻答不出來。作者：黃婉中（雲端架構師）

在 Agent 專案裡，有一種狀況特別折磨人：
系統沒有報錯，Agent 也有回應，流程看起來跑完了，但當使用者問：「剛剛那個結果，是怎麼產生的？」你卻答不出來。

這不是模型的問題，只是我們缺少一條完整的觀測路徑。

[caption id="attachment_201837" align="alignnone" width="814"] Agent 系統的成本和效能，通常不是平均分布的。（圖／AI生成）[/caption]

「可觀測性」 解決的，是「人類理解問題」

很多人會把 「可觀測性」（Observability） 想成進階監控，其實它在 Agent 系統裡扮演的是另一個角色：

讓人能理解一個高度動態的系統。

在傳統系統裡，我們可以靠固定流程和明確條件，達到可預期的輸出。

但在 Agent 架構中，同一個問題：

• 可能走不同路徑
• 呼叫不同工具
• 使用不同上下文

如果沒有記錄這些過程，事後幾乎不可能還原。

延伸閱讀：帳單暴增 100 倍，客戶竟然沒發現：雲端被挖礦，比你想的更常見｜專家論點【黃婉中】

觀測在實務上，企業最常問的2個問題

在實務討論中，大家通常會先談應用案例、常見疑慮，以及企業導入時對安全、可控與既有資料架構的考量，但上線後，問題往往出現在「流程到底發生了什麼」。

問題一：這個請求實際跑了什麼？

當結果「怪怪的」時後，工程師第一個想知道是：

• 這個請求經過哪些 Agent
• 中間呼叫了哪些模型
• 有沒有重試

這也是為什麼觀測會特別強調端到端追蹤。透過端到端追蹤，我們能在多 Agent 系統中，把一次請求完整串起來。

問題二：時間和資源花在哪裡？

Agent 系統的成本和效能，通常不是平均分布的。

實務上你會看到某些任務特別慢、某些情境特別燒 token、某些 Agent 成為隱性瓶頸。如果只有帳單或平均值，我們只會知道「變貴了」，但不知道「為什麼」。

可觀測性讓我們把時間與成本，對應回實際流程步驟。

除了還原狀況和分析資源分配，在和客戶談專案的過程中，還有兩個「點閱率」很高的功能：即時監聽和對抗測試。

即時監聽：讓問題在影響擴大之前就先被看見

比起事後排查，更有價值的是「早知道」。

因此實務上會把即時監控一些指標，包含：

• 任務成功率、平均延遲、錯誤率
• LLM 呼叫次數與 token 使用量（尤其是突然飆高）
• 行為漂移的偵測（任務的路徑、工具使用模式改變）

搭配自動提醒之後，我們可以在使用者大量受影響之前先處理，把損失減到最小。

對抗測試：上線前先把洞挖出來

除了「上線後」盯著看，很多平台也把觀測的範圍往前移到「上線前」。

做法很像自動化壓力測試，例如：

• 用模擬攻擊去測Agent的弱點
• 用自動掃描去找容易產生風險內容的情境
• 產出報告，讓你知道哪些地方要先補強再上線

這類紅隊測試的價值是， 把未來可能被濫用的弱點，提前在自己的環境中驗證。

觀測不是只用在「出事時」

很多團隊第一次認真看可觀測性，是在出問題之後。
其實觀測的用途很多，還能夠幫助我們：

• 比較不同模型的差異
• 決定某個 Agent 要不要擴大使用
• 判斷某個流程調整的成效

這些決策，如果沒有觀測資料，最後都會變成主觀判斷。

「觀測」和「評估」的界線

在實務上，兩者常常一起出現，但角色不同：

• 評估：關心輸出是否可接受
• 觀測：關心流程實際發生了什麼

一個用來下判斷，一個用來找原因。

小結

觀測的價值，在於讓工程師、架構師、甚至非技術角色，都能用數據來討論系統行為。

當我們能回答「發生了什麼事」，後面的調整才有意義。

這篇文章 AI Agent，如果使用者問你「這個結果怎麼來的」，你答得出來嗎？｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。