為什麼你的 AI Agent 差點把客戶資料寄給陌生人？企業 AI 真正缺的是 Context Engineering
那位負責維運客服系統的主管，是在下班前十分鐘看到那封升級信的。
一位客戶在線上詢問「我朋友的訂單能不能一起查」，公司新上線不久的 AI 客服 Agent，把另一位客戶的完整訂單紀錄和聯絡資訊，直接回覆了過去。資安團隊在兩小時內把這個功能緊急關閉，法務單位要求出具事件報告：這個 Agent 當初是誰核准上線的？它為什麼「看得到」那筆不該看的資料？
（以上為示意情境，用於說明業界已出現的普遍模式，非特定真實客戶案例。）
這不是聳動的假設。企業策略觀察家 Bernard Marr 在他主持的商業與科技趨勢 Podcast 節目中，直接點出這類事件已經在真實世界發生：「我們已經看過 AI Agent 刪掉關鍵業務資料、洩漏了不該分享的商業機密，只因為某些防護機制沒有到位，就把客戶資料交了出去。」而在那一集節目裡，他找來 Elastic 的 Masimo Merlo，一起拆解這一連串事件背後真正的病灶——不是模型不夠聰明，而是企業普遍漏掉了一塊叫做「context engineering（上下文工程）」的拼圖。
你以為問題出在模型，其實出在「地基」
Masimo 開門見山地說，企業 AI 的實驗階段已經結束了。多數組織已經跑過 pilot，現在正面對的是 AI 當初承諾的效果、跟它實際交出來的成果之間，那道令人不太舒服的落差。
他把原因拉回到一個更長的時間軸：企業軟體是過去四、五十年一層一層疊起來的——資料層、上下文層、應用邏輯層、使用者體驗層。而 AI 這一次，是同時把這幾層全部打亂重組。企業如果以為只要「把模型接上現有系統」就能坐等奇蹟發生，很快就會發現，資料流從來不是為 AI 設計的，治理機制也跟不上這個速度。把一個能力很強的模型，硬接到一個沒有整理好的地基上，並不會產生轉型，只會產生——用 Masimo 的話說——「一個更有自信版本的舊問題」。AI 很擅長的一件事，就是在被餵進錯誤資訊時，非常有效率地給出錯誤答案。
如果 AI 是大腦，Context 就是記憶
那 context engineering 到底在解決什麼？Masimo 提出一個他聽過、覺得很貼切的比喻：如果 AI 是大腦，context 就是記憶。 大腦處理速度再快，沒有記憶——沒有經驗、沒有走過的路——也判斷不出眼前這個當下該做什麼決定。
用在企業身上是同一件事：一個訓練在全世界公開資料上的模型，並不會自動理解「你」的公司——不理解你的客戶、你的政策、你過去發生過的事、你對風險的容忍度、你想達成的目標。它只會處理資料、給出一個聽起來還算合理、但其實相當通用的答案。Context engineering 這門學問，做的正是把「連接對的資料、對的模型、在對的時間點」這件事變成一套紀律：定義模型能看到什麼，並且建立護欄，讓它輸出的東西值得被信任、可以被拿去執行。
從「討厭」到「危險」：AI 一旦開始自己做決定
Masimo 特別強調一個轉折點：當 AI 只是回答問題時，答錯了頂多是個麻煩，你當場就能糾正；但當 AI 變成能自主推薦、決定、行動的 Agent，同樣一個錯誤答案，性質完全不一樣了——它可能直接變成商業風險、法規曝險，或是安全事故。
他舉了兩個具體例子。一個是安全維運中心（SOC）裡的 Agent：它需要看得到即時的威脅情資、過去的事件歷史紀錄、明確的升級流程，少了任何一項，判斷就會失真。另一個是詐欺偵測 Agent：它不能只看眼前這一筆交易，還得知道這位客戶過去的往來紀錄、適用的政策、組織能接受的風險門檻、誰有權限採取行動、事後要留下什麼樣的證據軌跡。把這些拿掉、卻給它完整的行動權力，你得到的不是一個「能力打折」的 Agent，而是一個真正的負債——這正是本文開場那個客服 Agent 事故背後的邏輯。
為什麼「把資料全部搬到模型旁邊」是個陷阱
順著這個邏輯，訪談接著談到即時資料的角色。Masimo 的說法很直接：一套 AI 系統，只跟它看得到的資料一樣新。如果決策依據的是兩年前、甚至更久以前的世界樣貌，得到的答案不會只是「不夠有用」，而是根本錯誤。
很多企業的直覺反應是把資料集中搬到模型旁邊，但 Masimo 認為這在現實中不切實際——企業資料量太大、太敏感、也太分散，經不起不斷搬動。更聰明的做法，是讓 AI 在資料原本存放的地方，取得受治理、可被信任的即時存取權，而不是把資料本身搬家。
這也解釋了為什麼「檢索（search/retrieval）」不但沒有因為生成式 AI 出現而過時，反而變得更關鍵。早期市場曾經懷疑：既然模型能直接生成答案，為什麼還需要檢索？Masimo 說，事實正好相反——檢索與上下文層，才是那套「找到對的資訊、理解它的意義、在 AI 需要的當下即時提供」的基礎設施，它決定的是 AI 產出的東西究竟值得信任，還是只是「聽起來很有說服力」。
好的 Context Engineering，做的第一件事不是選模型
那實務上該怎麼做？Masimo 提出一個很具體的判準：AI 專案最常犯的第一個錯誤，是把正式上線當成「模型問題」來處理，但它幾乎永遠是「工作流程與資料問題」。真正做對的組織，不會先問「該用哪個模型」，而是先問「這個模型需要看到什麼」——從工作流程出發，理解這個流程依賴哪些資料、定義好權限、把整個過程留下可追蹤的紀錄，讓你看得到 AI 在正式環境裡實際做了什麼。少了這層地基，Masimo 的說法很直白：那就只是一個「看起來很酷的聊天機器人」。
Bernard 與 Masimo 在這一點上意見一致：模型本身不會帶來競爭優勢，因為所有人拿得到的模型都差不多；真正拉開差距的，是你自己組織內部沉澱的資料品質，以及你重新設計工作流程的能力。這正好呼應了 Masimo 稍早提到的雲端運算類比——當年許多企業把既有系統原封不動「搬」上雲端，期待問題自動解決，結果反而製造出更多問題。同樣的陷阱，現在正在 AI 身上重演：把能力很強的模型硬接到破碎的工作流程上，然後稱之為策略，往往只會失敗。
轉折：你解決了「會不會出事」，卻可能沒發現正在付另一種代價
訪談全程沒有出現「token」這個字，但 context engineering 這套思路背後，藏著一個對任何導入生成式 AI 的企業都繞不開的現實——這是我們從 Token 治理角度延伸出來的觀察，並非受訪者原話。
Context 餵得越完整——歷史紀錄、政策文件、稽核軌跡、即時資料——AI 每一次呼叫，輸入端要處理的內容量就越大，而這正是 Token 用量與費用的來源。這也是為什麼治理不能只停在「安全」與「準確」兩個層次：沒有經過整理的 context，常常等於把能想到的資料全部塞進去，結果是一份又大又亂的輸入，每次呼叫都在為重複、過期、不相關的資訊付費；而真正被治理過的 context——只留下這個任務當下真正需要看到的那一部分——通常反而更精簡，也更精準。換句話說，把 context engineering 做扎實，往往同時解決了「這個答案可不可信」跟「這次呼叫要花多少錢」兩個問題，只是後者容易被忽略，因為帳單通常是下個月才被財務部門看到。
下一次評估 AI 專案，先問「模型需要看到什麼」
Masimo 對未來三到五年的判斷是：企業 AI 會變得更「agentic」，更深地嵌進安全維運、可觀測性、客服、甚至第一線與軟體開發等各種工作流程裡。但真正能領先的組織，不會是部署速度最快的那一批，而是有紀律先把地基——資料基礎、上下文層、治理架構——建好的那一批。他觀察到市場已經分裂成兩種路線：一種是「蠻力式」，不斷用昂貴、重複的模型呼叫去硬解那些原本可以靠更好的上下文基礎設施更聰明解決的問題；另一種是把心力放在從資料裡萃取意義、把 context engineering 當第一優先，讓系統隨時間變得更準確、更值錢，而不必每次都從頭硬做一遍。後者的地基會隨時間持續累積優勢，讓後進者越來越難追上。
回到本文開場的那個場景：如果那位客服主管在功能上線前，先問的不是「這個 Agent 聰不聰明」，而是「它能看到什麼？誰核准它能看到這些？這件事測試過了嗎？」——那封升級信，或許根本就不會出現。這個問題，遠比選哪個模型更關鍵，也比多數人以為的，更直接決定下個月的帳單會長什麼樣子。
FAQ
Q1：什麼是 Context Engineering（上下文工程）？
根據 Elastic 的 Masimo Merlo 在訪談中的說法，這是把「對的資料、對的模型，在對的時間點連接起來」的一套紀律：定義 AI 模型能看到哪些企業資料（客戶紀錄、政策、歷史事件等），並建立護欄，讓它的輸出值得被信任、可以安心拿去執行。
Q2：Context Engineering 跟一般說的 RAG（檢索增強生成）是同一件事嗎？
兩者高度相關但不完全相同。訪談中提到的檢索與上下文層，是讓 AI 即時取得正確資料的其中一種關鍵基礎設施；但 context engineering 涵蓋的範圍更廣，還包括權限設計、資料治理、流程監測與護欄建置等，是一套組織層級的工程紀律，而不只是單一技術做法。
Q3：為什麼 AI Agent 比一般聊天機器人更需要重視 context？
因為聊天機器人答錯了，使用者當場就能發現並糾正，頂多是個麻煩；但當 AI 能自主推薦、決定、採取行動時，同一個錯誤可能直接轉化成商業風險、法規曝險或安全事故——訪談中稱這是從「討厭」變成「危險」的轉折點。
Q4：企業要導入 Context Engineering，第一步該做什麼？
依據訪談中 Masimo 提出的判準，第一步不是挑選模型，而是從工作流程出發：釐清這個流程依賴哪些資料、定義清楚的存取權限，並讓整個過程可被追蹤觀察，確保你隨時看得到 AI 在正式環境裡實際做了什麼。
Q5：Context Engineering 會增加還是降低 AI 的 Token 成本？
訪談本身並未討論 Token 成本，但延伸來看，兩種效果都可能發生：如果只是把所有能想到的資料一股腦塞進 context，會讓每次呼叫的內容量暴增、成本跟著墊高；但如果依照文中邏輯，只保留當下任務真正需要的資料，通常反而能讓每次呼叫更精簡、也更精準，同時改善答案的可信度與成本效率。
資料來源聲明
本文改寫、解讀自 Bernard Marr 主持之商業與科技趨勢 Podcast 節目，該集主題為《Why Context Is The Missing Piece In Enterprise AI》，來賓為 Elastic 的 Masimo Merlo，發布日期 2026-07-02，觀看次數 79,830（資料來源：Apify 平台於本文逐字稿抓取當下實測驗證，viewCountVerified）。原始影片連結：https://www.youtube.com/watch?v=mNSJC7UEbxc。文中關於「context engineering」定義、企業案例與未來趨勢之描述，均依訪談逐字稿改寫整理；文中「Context Engineering 與 Token 成本之關聯」一節，為 AI Token King 編輯團隊依訪談內容延伸之觀點，並非受訪者原話，特此註明。
延伸閱讀
立即體驗
看懂「模型需要看到什麼」只是第一步，下一個容易被忽略的問題是：這些呼叫實際換算成多少開銷？免費試用 AI Token King，把透過同一把金鑰使用的各家 AI 模型用量與費用整理進同一個儀表板，讓你不用等到下個月帳單寄來，才第一次看見這筆帳。
留言