大多數企業 AI 代理項目失敗，不是因為模型不夠強，而是在代理行動的那一刻，根本沒有人事先決定它可以「知道」什麼。這個決定如今有了正式名稱：情境工程（Context Engineering）。BARC 於 2026 年 9 月 3 日發布的研究顯示，將情境工程制度化的企業，成為 AI 領先者的機率是其他企業的四倍。
什麼是情境工程？
情境工程是指在 AI 模型推理或行動的那一刻，為它組合正確的資訊、工具、指令與歷史記錄的一門學問。它取代了過去反覆修改單一提示詞的做法。對企業而言，它是讓通用模型變成一個了解你的政策、數據與界限的代理的關鍵層。
DataHub 共同創辦人兼技術總監 Shirshanka Das 在 BARC 報告中給出了最清晰的區分：情境工程是為單次代理呼叫組合正確輸入的實踐；情境管理則是在企業層面，跨多個代理與數據來源治理這些輸入的紀律。兩者都應該列入董事會議程，因為前者決定試點能否成功，後者決定成功能否複製。
業界最常引用的比喻來自 Andrej Karpathy：大型語言模型像 CPU，上下文視窗像記憶體。記憶體載入了錯誤的數據，CPU 再快也只會算出錯誤答案。因此，若你的部門去年從一個前沿模型升級到另一個，代理的可靠性卻毫無改善，問題很可能出在記憶體，而不是處理器。
上下文視窗本身是有限預算。Anthropic 的工程指南《Effective Context Engineering for AI Agents》把目標描述為：找出最小的一組高訊號 token，使期望結果的機率最大化。你塞進視窗的每份政策文件、每個工具說明、每輪對話，都在爭奪模型的注意力，而模型表現會隨視窗填滿而下降。情境不是越多越好。
為什麼情境工程對 2026 年的香港企業特別重要？
香港企業正把 AI 代理推向生產環境，同時私隱專員公署對代理式 AI 的要求正在收緊。處理電郵、合約與客戶記錄、又需兼顧三種書面語言的代理，必須依靠受治理的情境才能保持準確與合規。把情境視為基礎設施的企業，與把情境視為一段提示詞的企業，差距正在拉開。
BARC 這項題為《Context Engineering for Agentic AI: Architecture, Use Cases, and Principles for Success》的研究，訪問了全球 285 位數據、AI、IT 與業務負責人。研究將 42% 的受訪者歸類為「情境領先者」，即已落實、制度化或優化六項基礎元素：數據整合、工作流程協調、檢索方法、聯邦式元數據、提示詞工程，以及語義層。在這些領先者當中，49% 同時符合 AI 領先者的標準；其餘企業只有 12%。
同一研究也揭示了大多數企業的現況：44% 的受訪者只在單一代理、單一團隊或單一平台內管理情境，43% 則跨團隊、跨平台或在整個企業層面管理。後者可以把「活躍客戶」或「已核准供應商」的定義，在財務、營運與合規代理之間重複使用；前者每次都要重新建立，而每一次重建，都是兩個代理各說各話的機會。
香港還有兩項本地壓力。2026 年 8 月 25 日，個人資料私隱專員公署發布了《人工智能：個人資料保障模範框架》的補充指引，專門針對代理式 AI 的個人資料保障。指引把代理式 AI 視為獨立的風險類別，理由是代理獲得的存取權限與自主程度前所未有。決定代理可以看到什麼，因此不再只是工程選擇，而是《個人資料（私隱）條例》下的數據最少化決定。另一方面，香港的工作文件混雜英文、繁體與簡體中文，在美國示範中表現良好的檢索方法，在香港的合約檔案庫中往往漏掉一半內容。
情境工程與提示詞工程、RAG 有何分別？
提示詞工程是為單一請求撰寫更好的指令；檢索增強生成（RAG）是為單一答案擷取文件作依據；情境工程則治理模型在整個任務中看到的一切：指令、檢索到的數據、工具定義、記憶與先前步驟。提示詞與 RAG 是情境工程內部的組件，而不是它的替代品。
這個區分之所以重要，是因為不少香港企業在 2024 或 2025 年做過 RAG 試點，然後得出「AI 對我們來說不夠準確」的結論。在我們見過的多數事後檢討中，檢索組件其實運作正常，真正的問題是代理同時收到了過時的工具輸出、過長的系統提示，以及沒有任何規則說明何時應該查證。Redis 的《State of Context Engineering 2026》報告指出，82% 的 IT 與數據負責人同意，單靠提示詞工程已不足以支撐規模化的 AI。
向管理層簡報時，一個實用做法是點名代理在每一步都會收到的四種輸入：
--- 指令：系統提示、政策與語氣規則，應足夠具體以引導行為，但不至於在邊緣情況下崩潰。
--- 知識：為這項任務檢索的文件、記錄與指標，最好按需即時擷取，而非預先大量載入。
--- 工具：代理可以呼叫的系統，每一個的說明都要清晰到模型永遠不必猜測該用哪一個。
--- 歷史：任務至今發生了什麼，經過壓縮，讓重要決定保留、雜訊消失。
如果供應商只能談第一種輸入，你買到的只是換了名字的提示詞工程。
成熟的情境工程框架包含什麼？
按 BARC 的定義，成熟框架包含六項受治理的元素：數據整合、工作流程協調、檢索方法、聯邦式元數據、提示詞工程與語義層。語義層承載共享的業務定義，聯邦式元數據承載擁有權與權限。缺了這兩項，每個代理都會自行發明一套「事實」。
對營運總監或數碼轉型主管而言，六項元素可以轉化為向內部團隊或供應商提出的問題：
--- 數據整合：代理可以讀取哪些系統？連接是即時的，還是每季匯出一次？
--- 工作流程協調：當任務需要跨兩個系統的三個步驟，由誰決定次序？邏輯記錄在哪裡？
--- 檢索方法：代理是按關鍵字、按語義、按元數據篩選，還是綜合使用？你能否測試出是哪一種失效？
--- 聯邦式元數據：是否有記錄說明每個數據集由誰擁有、哪些職位可以向代理開放？
--- 提示詞工程：指令是否像其他受控文件一樣，有版本、有測試、有審核？
--- 語義層：「收入」、「人手」、「客戶」在財務代理與營運代理眼中，意思是否一致？
BARC 受訪者的優先次序說明了框架的用途：38% 把一致性與可靠性列為首要目標，34% 選擇準確性，只有 12% 選擇降低成本，儘管 BARC 預期隨着 token 消耗增長，成本的重要性會上升。可靠性居首，是因為一個八成時間正確、兩成時間自信地出錯的代理，不能被託付任何涉及客戶或帳目的工作。
Anthropic 的工程指引補充了三個應寫進框架文件的操作模式：按需檢索，即代理只保留輕量引用，需要時才載入完整文件；壓縮，即把冗長歷史摘要化，避免任務中途耗盡視窗；以及子代理架構，讓每個專門代理持有乾淨、狹窄的情境，再回傳精簡結果。這些機制，就是「受治理的情境」四個字背後的實質內容。
情境工程在香港企業中如何實際運作？
假設一家管理 60 個屋苑的香港物業管理集團，部署代理回答業主的維修與收費查詢。試點失敗的原因，是代理引用了上一個財政年度的管理費表。解決方法不是換更強的模型，而是一條情境規則：在回答時即時檢索現行收費表，標註生效日期，並禁止代理在沒有該表的情況下作答。
在這個物業管理案例中，第一版把 120 頁的營運手冊載入每一段對話，準確率低、每次查詢的成本卻很高，因為手冊擠掉了業主真正的問題。第二版只保留手冊的兩行索引，當查詢涉及某一章節時才檢索該章節。準確率上升、成本下降，團隊更獲得一項更有價值的東西：每個答案依賴了哪一節手冊的記錄，而這正是審計師會索取的證據。
一家連鎖零售集團面對的是另一種問題。它的代理要根據存放在英文與繁體中文的過往合約，草擬供應商協議。只按查詢語言比對的檢索，會漏掉一半的先例庫。情境工程的答案是一層雙語元數據，讓無論用哪種語言標註為「責任限制」的條款，都能被任何一種語言的提示詞檢索到；再加一條權限規則，確保供應商甲的條款絕不會在為供應商乙草擬時出現。
一家地區銀行的合規團隊則說明了治理的一面。根據私隱專員公署的代理式 AI 指引，銀行必須能夠解釋代理存取了哪些個人資料，以及原因。一個記錄每次檢索、其來源及授權依據的情境管理層，能給合規主管一個站得住腳的答案；一段提示詞做不到。
情境工程最常見的錯誤是什麼？
五個最常見的錯誤是：把所有東西塞進視窗、讓每個團隊各自定義情境、工具說明含糊、從不壓縮歷史，以及把指令當作不受追蹤的普通文字。每一項都導致同一個症狀，即代理自信地出錯；而每一項在設計階段修正的成本，都遠低於部署之後。
第一個錯誤最昂貴。團隊以為一百萬 token 的視窗意味着可以放進整個政策庫。結果表現下降、每次呼叫成本上升，而且代理開始引用錯誤文件，因為兩份相似的文件並排放在一起。Anthropic 的指引直接點出這一點：目標是最小的高訊號集合，而不是最大的可能集合。
第二個錯誤是組織性的。BARC 發現 44% 的企業只在單一代理或團隊內管理情境。實際後果是人力資源代理與財務代理對「員工」有不同定義，當兩者都被問及人力成本時，管理層得到兩個數字。解決方法是一個由中央擁有、各部門使用的共享語義層。DataHub 的《State of Context Management Report 2026》發現，93% 的企業表示很可能把情境視為共享基礎設施而非個別團隊的工具。
第三與第四個錯誤屬技術層面，但業務部門看得見。含糊的工具說明令代理選錯系統，例如答案在 ERP 卻去查 CRM。未經壓縮的歷史令長任務在十二步中的第九步失敗，在營運部門眼中就變成「代理只能處理簡單個案」。
第五個錯誤是把提示詞當作非正式文字。如果系統提示可以由任何人不經審核修改，你等於有一份不受控的政策文件，在驅動對你系統的實際操作。請為它建立版本、測試與審核，像對待任何標準作業程序一樣，因為它本質上就是一份標準作業程序。
如何向董事會或財務總監闡述情境工程？
把它表述為「可以規模化的 AI 預算」與「每個項目都要歸零重來的 AI 預算」之間的分別。用 BARC 的數字，49% 對 12%，說明受治理的情境是 AI 領先的預測指標。然後為共享基礎設施，即語義層與元數據擁有權申請預算，而不是再申請一個孤立的試點。
董事會對三種論述有反應。第一是可複製性：每個建立在共享情境上的代理，成本都比上一個低；每個孤立建立的代理，成本都與第一個相同。第二是可審計性：受治理的情境會留下代理知道什麼、為何知道的記錄，這正是私隱專員公署的代理式 AI 指引與你的內部審計委員會共同想要的。第三是選擇權：情境層與模型無關，當下一個前沿模型出現，或某供應商放慢發布節奏時，你的投資可以延續，而不必重建。
與財務總監的對話也應說明情境工程做不到的事。它不能完全消除幻覺，只能縮小幻覺可以出現的空間。它不能取代數據質素工作；BARC 受訪者把數據質素與準備列為首要挑戰，佔 49%，高於模型限制的 29% 與治理缺口的 25%。一份可信的商業方案會如實寫明這一點，並把數據工作與代理工作一起編入預算。
如果你已讀過關於前線部署工程師或企業數據保留防護的文章，情境工程正是把兩者連結起來的一層：它是工程師所建構的東西，也是防護措施所保護的數據。至於同一概念在單次呼叫層面的操作細節，可參考以 XML 標籤結構化提示詞的實務指南。
結論：企業領袖下一步應該做什麼？
把情境視為基礎設施，而非一段提示詞。盤點你的代理目前能看到什麼，為它們依賴的定義與數據集指定負責人，並在下一個試點之前，先為共享的語義層與元數據層撥出預算。BARC 數據中領先的企業正是這樣做的，而它們的代理，才是可以託付真實工作的代理。
2026 年數據中令人不安的事實是：模型能力已成為代理項目中最容易取得的部分，也最不可能是項目失敗的原因。把 49% 與 12% 區分開來的，是一項耐心的工作：決定代理可以知道什麼、記錄這些知識由誰負責，並保持更新。這項工作毫不光鮮，卻正是一家在香港服務企業 28 年的科技夥伴，早在「情境工程」一詞出現之前就一直在做的事。懂AI的冷，更懂你的難。UD 同行28年，讓科技成為有溫度的陪伴。
由 UD 企業 AI 團隊審閱。資料來源：BARC 與 DataHub《Context Engineering for Agentic AI》（2026 年 9 月 3 日）；Anthropic Engineering《Effective Context Engineering for AI Agents》；Redis《State of Context Engineering 2026》；DataHub《State of Context Management Report 2026》；私隱專員公署代理式 AI 指引（2026 年 8 月 25 日）。
準備好為你的 AI 代理建立情境層了嗎？
了解了框架，下一步是找出受治理的情境在你的組織中最快見效的切入點。UD 團隊手把手帶你完成每一步，從 AI 準備度評估、數據盤點，到代理設計、部署上線與成效追蹤，28 年企業服務經驗，全程陪你走。
