事件背景：省下的不是一句提示詞，而是整條推理鏈
Elastic 資安團隊在內部 SOC 流程中部署了 14 個 AI Agent，用來處理真實環境的資安告警。依 Elastic Security Labs 公布的案例，同一類工作原本最多需要 19 次大型語言模型（LLM）呼叫，經過調整後降至 7 至 9 次，約減少六成。關鍵並不是換用更便宜的模型，也不是單純縮短提示詞，而是讓 Agent 少走重複、沒有產生行動或缺乏停止條件的推理迴圈。原始案例：https://www.elastic.co/security-labs/ai-agent-optimization-production-scale
必須先界定證據強度：19 次降至 7 至 9 次，是 Elastic 對自家生產環境的量測結果，並非第三方稽核，也沒有公開足以重現完整實驗的告警資料、模型版本及逐案品質評分。因此，本文將它視為可信的第一方案例，而不是所有 SOC 導入 Agent 後都能直接套用的普遍節省率。
運作機制：每多想一步，舊上下文通常還要再付一次
傳統提示詞工程著重「能否回答正確」；生產環境的 Agent 最佳化，則同時關心正確率、行為一致性及每次任務成本。Agent 每完成一輪推理，可能選擇查詢日誌、取得程序關聯、呼叫外部工具，再把結果帶入下一次模型推理。當對話歷史與工具輸出持續累積，後面的呼叫往往具有更大的輸入上下文。
Elastic 表示，其窄範圍專用 Agent 每次呼叫平均約有一萬個輸入 token，工具較廣的技能型 Agent 則約三萬六千個。這也是為何少掉六次呼叫的效果，可能遠大於把系統提示詞刪短三分之一：被省下的是多輪上下文、重複查詢與工具回傳，而不只是最前面那段指令。
這項機制也獲得獨立研究的方向性交叉驗證。一篇分析多種 Agent 架構的研究發現，具有工具操作的系統平均需要比單次 Chain-of-Thought 基準多 9.2 倍 LLM 呼叫；較複雜的樹狀搜尋架構平均甚至達每個請求 71 次。研究同時觀察到，多輪步驟會累積長輸入上下文，而增加推理深度的準確度收益會逐漸遞減。這不能證明 Elastic 的「60%」數字，但支持其基本判斷：Agent 架構及迭代次數本身，就是成本與延遲的重要來源。研究資料：https://arxiv.org/abs/2506.04301
五步最佳化：先看執行軌跡，再改指令
- 建立基準：記錄每次任務的 LLM 呼叫數、總 token、中位數及相似告警之間的變異。
- 建立代表性測試集：涵蓋端點、雲端、SaaS 等不同告警，並納入已知容易拖長或漏步驟的案例。
- 閱讀完整執行軌跡：找出重複呼叫工具、重新查詢既有資料、先探索欄位結構、取得整份文件卻只使用少數欄位，以及只有推理而沒有行動的回合。
- 在 QA 環境修改與重測：使用完全相同的輸入，比較呼叫數與 token，同時確認判斷品質沒有退步。
- 上線後監測漂移：當偵測規則、資料格式或告警組合改變，重新執行同一套分析。
最具代表性的修改，是把「請在 5 至 10 輪完成，最多 12 輪」改成明確的停止清單：依序取得告警程序脈絡、追蹤一層程序祖先、執行實體行為關聯，完成後立即輸出結論。前者只給數字，Agent 每一輪仍可能發現另一個「值得確認」的假設；後者則把完成條件寫成可執行的流程。
Elastic 的官方 API 文件也確認，Agent Builder 的 consumption endpoint 可回傳每段對話的輸入與輸出 token、round count、LLM call count，以及高 token 警示，並支援分頁與依總 token 排序。這證明案例所依賴的觀測欄位確實存在，不只是文章中的概念描述；但該端點目前標示為實驗性功能，且需要相應管理權限。文件：https://www.elastic.co/docs/api/doc/kibana/operation/operation-post-agent-builder-agents-agent-id-consumption
為何現在值得注意：Agent 正從展示品變成長期營運成本
聊天機器人的成本通常由使用者發問頻率決定；自動化 SOC Agent 則可能對每一筆符合條件的告警啟動，重複執行全天候流程。單次多幾輪看似有限，一旦每天運行數百次，重複查詢與上下文累積就會形成穩定支出。更麻煩的是，模型價格下降不一定能解決流程浪費：價格變便宜後，組織往往會處理更多告警，低效率也會隨規模放大。
作者觀點是，這起案例真正重要的地方，不是「提示詞技巧能省六成」，而是 SOC Agent 開始需要像軟體服務一樣接受效能工程：有追蹤資料、有基準、有回歸測試，也有上線後的異常監控。提示詞因此不只是文字內容，而逐漸成為可變更、可測試的流程規格。
實際影響與容易忽略的限制
呼叫次數下降通常有利於降低 token 消耗與等待時間，也能減少查詢後端日誌及外部服務的負載。然而，Elastic 並未公布實際帳單降幅、端到端延遲改善或錯判率變化，因此不能把「呼叫少 60%」直接解讀成「總成本少 60%」，更不能據此宣稱告警品質同步提升。
停止條件也具有安全代價。若清單過度僵化，Agent 可能在罕見攻擊仍有重要線索時提前結案。Elastic 自己也要求：若成本指標改善、輸出品質卻退步，就應放寬限制並重新測試。換言之，最佳化目標不能只有 token，而應同時涵蓋漏判、誤判、未完成結論與人工覆核結果。
另一項限制是測試樣本。Elastic 建議每個 Agent 先取二至四段代表性對話，這適合找行為模式，卻不足以證明統計上的整體品質。正式導入仍需用更大規模的歷史告警回放、紅隊案例與罕見事件驗證，尤其不能只用大量、容易判斷的日常告警製造漂亮平均值。
對台灣企業 SOC 的意義
對人力有限、同時管理端點、雲端與 SaaS 告警的台灣企業而言，優先工作不一定是添購更強模型，而是盤點每類告警究竟需要哪些證據、查詢順序與停止條件。若既有 SOP 本身模糊，Agent 只會以更快速度放大模糊與重工。
較務實的導入方式，是先選擇規則明確、結果可人工核對的高量告警，記錄每案呼叫數、token、工具次數及分析師是否推翻結論，再逐步擴大範圍。Elastic 的六成成果可當作「流程浪費可能很大」的警訊，但不應成為採購預算中的保證值。
後續觀察指標
- 各類告警的 LLM 呼叫數與總 token 中位數，而非只看平均值。
- 相似告警的呼叫數變異，以及是否出現少數失控的極端案例。
- 同一工具被重複呼叫、已知資料被重新查詢及查詢錯誤的比例。
- 端到端處理時間、外部工具成本，以及後端搜尋負載。
- 分析師推翻率、漏掉必要調查步驟的比例與重大告警升級率。
- 偵測規則或資料格式變更後，成本與品質是否同步漂移。
Agentic SOC 的下一階段，競爭焦點不只是哪個模型更會推理，而是誰能把推理限制在值得付費、可被驗證的步驟內。Elastic 案例提供的核心提醒很簡單：自主性若沒有觀測、停止條件與回歸測試，就容易從生產力工具變成無聲累積的營運成本。