為什麼這個領域重要

如今的生產級智慧代理早已不靠單條提示運作。它是拼裝出來的——檢索模組、工具呼叫模組、安全護欄、摘要器、若干子代理，全部以系統提示與工具定義的形式層層疊進同一個上下文。問題在於，這樣連接起來之後，給某個模組的指令會滲漏到相鄰模組。2026年6月發表於arXiv的論文《Instruction Bleed: Cross-Module Interference in Prompt-Composed Agentic Systems》(2606.26356) 正面探討了這個現象。你在一個模組裡寫下「簡潔作答」，本應毫無關聯的安全校驗模組卻開始草草跳過檢查。代理在生產環境中那些無法解釋、從未在展示時出現的失敗，很大一部分都能追溯到這裡。

根本原因在於，大型語言模型把所有文字幾乎以同等權重來讀。正如OpenAI在《The Instruction Hierarchy》中指出的，模型本來就把開發者的系統提示、使用者輸入與工具輸出當作同一優先順序來對待。模組越多，越難控制哪條指令侵入了哪條，一行改動就可能在系統的另一端引發回歸。於是，除了把模型做大之外，還分化出一個專門的角色，負責保證這套拼裝好的系統真正按預期隔離運作。這就是智慧代理可靠性工程師——守護的是系統可信度而非模型精度。在多模組代理成為常態的今天，這個職位正迅速固化為一項專門的工種。

所需技能

這份工作處在SRE式可靠性工程的直覺，與大型語言模型系統特有的非確定性控制之間的交叉點上。它既不是造工具，也不是搭編排——而是在拼裝好的模組之間劃出邊界，讓它們彼此不互相污染，再不停地度量這些邊界是否守住。

• 提示模組隔離。 不把每條系統提示、工具定義與子代理指令都塞進同一個上下文，而是用清晰的邊界把它們分開。設計每條指令的作用域延伸到哪裡，並阻止無關模組繼承彼此的語氣、策略或約束。
• 指令作用域與權限。 分離受信任的系統指令、使用者輸入與工具回傳文字的權限層級。把指令層級（instruction hierarchy）的概念翻譯成具體的提示結構，使低權限文字無法覆蓋高權限策略。
• 干擾評估框架。 建構回歸套件，自動捕捉「改動模組A的指令會擾動模組B的行為」這類情況。把黃金集、情境用例與對抗用例接入CI，使一行提示修改一旦破壞了遠處的模組，建構立刻亮紅燈。
• 執行時防護。 在部署之後仍保留運行中的防線：攔截疑似指令外洩的輸出，偵測策略違規，對跨越模組邊界的異常行為施加斷路器與回滾。
• 可觀測性。 追蹤每一次模組呼叫與每一個指令注入點。一旦出現故障，你必須能事後讀出究竟是哪個模組的哪條指令滲漏到了哪裡。

職業路徑

需求明確，供給卻很薄。把代理做到展示階段的人很多，但從可靠性視角除錯過數十個模組相互糾纏的生產系統的人卻很少。招聘的關鍵在於：你能不能解釋並預防「展示能跑，可一加上某個模組，毫不相關的地方就壞了」。這使它成為一個尷尬的交叉點——既不是普通的後端工程師，也不是純粹的機器學習研究者，而是在SRE與平台經驗之上疊加了大型語言模型系統直覺的中高階工程師。

入行有兩條路。一是從SRE、平台或可靠性工程師起步，接手內部代理基礎設施，再轉向非確定性控制；二是從AI工程與提示工程一側切入，向下深入到評估與執行時安全這一層。頭銜尚未定型，散落為Agent Reliability Engineer、AI Reliability Engineer、Agent Safety Engineer等。由於技能稀缺，越來越多團隊給出比同級軟體工程師高出10%~20%的薪酬。在台灣與香港，無論是大型科技公司還是剛拿到A輪的新創，只要把代理推上了生產環境，這個角色就不再是可選項，而成了平台團隊的固定職責。

最快的驗證方式是親手把它弄壞。搭一個只有三四個模組的小代理，故意往一個模組裡塞進強指令，量一量其他模組的輸出如何被污染。接著修好隔離與作用域，把干擾回歸套件接進CI，再給輸出加上執行時防護。完整跑通這一輪的經歷，勝過履歷上任何一個關鍵詞。