Figma 讓 AI agent 接手資安 on-call：解案時間砍 71%，關鍵在幫它裝上記憶
警報一響，AI 先把歷史脈絡、相似案例、相關 PR 整理好貼進 Slack，工程師只要複核。Figma 資安團隊把一套 production agent 系統整個攤開講——尤其是讓它越用越準的那層記憶。
on-call 工程師一整晚最花時間的，往往是把散在 Slack、Asana、pull request、audit log 各處的線索，重新拼回同一張桌上：這個警報跟上週那個像不像？有沒有一支 PR 已經在處理它？某條 Slack thread 是不是提過相關的事？
Figma 資安團隊把這段拼圖工作交給一套 AI agent 系統。警報一響，agent 先把歷史脈絡、相似案例、相關程式碼變更整理好貼進 Slack，工程師的角色從「從零開始調查」變成「複核 agent 找到的東西」。複雜警報的解案時間因此掉了七成。
這篇文章把一套真的在 production 環境跑的 agent 架構整個攤開講——從檢索層、多 agent 分工，到讓它越用越準的那層記憶。對每天都在用 AI 工具的設計師來說，這是難得能看到「一套 agent 系統內部到底怎麼運作」的一手材料。
Figma 的資安工程團隊每天要防的威脅一直在變：雲端基礎設施頻繁更動、開發者換工具、每個人筆電上跑的東西每季都不一樣（文中舉的例子很有畫面感——當 Designer Advocate 團隊開始自己 vibe coding 做 app 跟自動化）。他們用 SIEM 工具 Panther 掃雲端、端點、SaaS、身分系統，一偵測到可疑就往 Slack 丟警報、同時在 Asana 開一張票給 on-call 工程師接。
問題出在「接」這個動作。過去 on-call 花最多力氣的環節，是蒐集脈絡。團隊一開始只想做一件小事：警報再度觸發時，把上一次工程師的判斷理由撈出來給你看。這個小專案最後長成一整套會調查警報、查 audit log、寫 code、開 PR，還會靠自己的記憶越做越好的 agentic 系統。下面這張圖，就是這隻 agent 手上握有的工具全貌。
先講清楚這套系統到底在省什麼。Panther 偵測到事件會發警報，但一則原始警報本身資訊很薄——你得自己去回答一串問題：這個 actor 是誰、他在 Okta 裡該有哪些權限、他警報前兩小時在 AWS 做了什麼、他的端點上跑了哪些程序、有沒有 Slack thread 或 PR 已經在處理。這些問題的答案分散在十幾個系統裡，人要一個一個 tab 開過去。
Figma 的做法是把「蒐集脈絡」這件苦工整包交給 agent。而且它刻意不改變工程師既有的習慣：當有人在 Slack 警報串裡留一句判斷筆記，系統就把那句話重新索引回原本的警報上，變成下一次相似警報的判斷依據。用他們自己的話說，既有的工作流本身就是訓練資料，不需要另外做標註工具或訓練管線。
整套系統的第一塊，是蓋在 AWS Bedrock Knowledge Bases 加 Amazon Kendra 上的「檢索增強分類」層——他們把這叫做 case memory（案例記憶）。警報一觸發，Lambda 會把它轉成標準化文件、抽出 IP、actor、AWS 帳號 ID 等結構化欄位丟進 Kendra 索引。下一則相似警報進來時，就用警報標題當向量去做語意比對，把過去的處理紀錄撈回來。
兩個細節讓推薦變準：一是偏向「最近」的結果——兩天前的相似警報，比六個月前一模一樣的警報有用得多，因為判斷方式本身一直在演化；二是偏向那些「有留下 investigation context」的警報，也就是工程師實際留過筆記的案例（一則沒人留言、直接關掉的警報幾乎沒有參考價值）。光是這層，加上「高信心判定為重複或良性就自動把 severity 降級」，就讓 on-call 被叫醒的次數少了兩成。
光有檢索還不夠，下一步是在 RAG 上疊一層真的會「動手」的 agent。他們用 Tines 做工作流自動化，看中的是它能用明確的工具介面跑 LLM 迴圈：讀一條 Slack thread、查一個 Okta 使用者、query Panther 資料、在特定 repo 開 PR。工程師掃一眼工具清單，就能推理出這隻 agent 能做什麼、不能做什麼——當你把 production 安全資料的存取權交給一套自動系統，這種可稽核性很值錢。
被 tag 之後第一件事是 intent routing：先用一個輕量模型（像 Claude Sonnet）讀完整條 Slack thread，判斷這是警報 triage、平台安全問題、還是 app 審核詢問，再把它分派給對應的專責 agent。每個 agent 有自己 scoped 的工具庫、授權層跟 system prompt。真正扛下大部分調查工作的是 alert triage agent（用像 Claude Opus 的模型），它手上握有 Okta、端點安全工具 Santa、雲端安全 Wiz、Slack、Panther，以及一個能開 PR、還有一個專門寫 SQL 的 sub-agent。把工具拆給不同 agent，好處是每隻都聚焦，不會養出一隻「什麼都能碰」的巨獸。
triage agent 用直接的工具能回答很多問題，但有些調查得往更深挖：這個使用者警報前兩小時在 AWS 做了什麼？他的端點上有哪些程序在跑、有沒有異常？這種時候，triage agent 會把問題丟給一個專門的調查 sub-agent。
這個 sub-agent 接到自然語言問題，把它翻成 Snowflake SQL，去查 Panther 的資料倉儲——裡面吃進了整間公司的 audit log：AWS CloudTrail、Okta 系統日誌、GitHub 事件、GCP、osquery 端點遙測、Santa 事件、Wiz 發現，還有大約上百張表。母 agent 呼叫它的方式，就像你請同事幫忙跑一句查詢：「找 X 使用者過去 48 小時最近的 Okta 登入」。但這裡有個現實的坑：表結構很亂，欄位命名各家不一致、join key 沒文件、時間分割函式每張表都不同。沒有輔助的話，sub-agent 光是摸清 schema 就要浪費四五次查詢——這個問題怎麼解，答案在下一段的記憶層。
記憶，是整套系統裡對「越用越有用」貢獻最大的部分——而且把不同種類的記憶分開，很關鍵。上面那張卡列了四種，這裡只講最有畫面感的兩個對照。
steering memory 跟 case memory 的界線，他們踩過坑才學會：一次性的教訓（某個特定警報該怎麼看）該進 case memory，當成未來相似警報的判例；而會改變 agent 對「所有警報」處理方式的行為規則，才該進 steering memory。早期他們把什麼都塞進 steering memory，結果它開始用不想要的方式覆蓋 agent 的行為——用他們的話說，判例跟政策是兩回事，該放在不同地方。
真正的轉捩點是 procedural memory。他們給調查 sub-agent 一個自己的記憶庫，查完一次需要摸 schema 的調查後，就把學到的東西存下來（例如「某張表的職稱欄位叫 jd」）。第一次問 Zoom 相關活動要跑好幾次探索查詢；存了記憶之後，同樣的問題一次查詢就搞定。這個模式在各個資料源反覆發生，agent 靠試錯替自己寫出了一本操作手冊。
最讓團隊意外省時間的一步，是 agent 從「我搞懂發生什麼事了」直接跨到「這是一支修好它的 PR」。兩條路徑：偵測規則、allowlist、警報抑制這類改動，開 PR 到 Panther detections repo；基礎設施、Terraform、RBAC 這類則對 monorepo 動手。他們特別補了一課——bot 開的 PR 會讓 git blame 指向服務帳號，幾個月後根本查不到這改動的來龍去脈，所以現在會把提出需求的工程師名字跟原始 Slack thread 連結寫進 PR 描述。
但放權的前提是 guardrail。每一支 agent 開的 PR 都會被自動設成 draft——這一步做在 Tines 工作流裡，是確定性的後處理，而非靠 prompt 叮嚀 agent「記得設 draft」，因為他們早就發現指望 LLM 記住這種事不夠可靠。同樣用這種工具呼叫的契約，確定性地擋掉一堆事：agent 拿 Okta 資料時不會收到敏感員工資訊、不會去關或改不是它自己開的 PR。他們的原則很清楚——當行動是有界、可逆、有明確證據支撐時，才比較放心交給 agent 自動執行；廣泛、破壞性、難稽核的操作則不。
把這篇拉高一層看，設計師最該記住的，是一套 production agent 系統實際長成什麼樣子。它的本體更接近一組工程結構——檢索、分工、工具契約、四種分層記憶，再加上一堆確定性 guardrail 疊起來的成果，而非單一顆無所不能的大模型。讓它真正拉開差距的，是那層會自己累積、越用越省的記憶。
這跟你我手上的 AI 設計工具是同一套邏輯。當「vibe coding」跟 agent 開始進入日常，看得懂這種系統怎麼把人的判斷沉澱成可重用的資產、怎麼在放權跟可控之間畫線，會慢慢變成一種基本的工作素養。工具會一直換，這套關於記憶與邊界的思路不會。
