回顧系列
- 場次 01:開發人員的代理架構設計路線圖
- 場次 02:Amazon Bedrock 數據自動化
- 場次 03:AgentCore 上的多代理
- 場次 04:實務建置代理式 AI:Nova Act 與 Strands Agents
- 場次 04:運用規格驅動開發,以 Kiro 加速移轉專案
- 場次 06:從「比對」到「理解」:由 AgentCore Memory 驅動的個人化 AI 搜尋實踐
- 場次 07:從觀察到最佳化:從 LLM 可觀測性邁向 AIOps,將即時洞察轉化為智慧自動化
- 場次 08:部署 TEAM 並打造最佳工程團隊
- 場次 09:五年來所謂無伺服器資料庫帶來的五個慘痛教訓
- 場次 14:如果 AI 替我工作會怎樣:Q Developer CLI 與 Kiro 如何改變我的日常工作
- 場次 16:兼顧速度與警覺:Amazon Bedrock Agent 開發的安全要點
- 場次 26:在單張 H100 上執行 OSS LLM:更聰明、更便宜、更快速
- 場次 28:現代化統一中繼資料架構:打破資料孤島的新方法
- 場次 29:無伺服器 MediaOps:運用 Amazon Web Services 上的 AI 自動化影片工作流程
- 場次 30:透過大規模效能測試建構兼具效率與可靠性的架構
- 場次 31:透過開放原始碼連結世界:技術、社群與全球開發者關係的實踐歷程
- 場次 33:建置串流 Iceberg 資料表以進行即時物流分析
- 場次 34:加速大規模機器人策略訓練:以 Kiro、Trainium 與 EKS 為基礎的自動化閉環架構
- 場次 35:透過規格驅動開發,從 Vibe 走向可行方案
- 場次 36:讓雲端成本分析更智慧:使用 Strands 與 AgentCore 建置 FinOps 智慧 Agent
- 場次 37:使用 CNCF Kagent、K8sGPT 與 Nova Sonic,轉型 K8s 對話式 Agentic AIOps
場次筆記
代理式開發類似於分散式程式設計/微服務。
代理式系統中的主要安全風險包括:
- 威脅建模最佳實務
- 透明度 代理式系統的 Agent(核心元件)會與以下項目互動:
- 記憶
- 工具
- 規劃
- 行動 記憶元件:
- 短期記憶
- 長期記憶 工具:
- 行事曆
- 計算機
- 程式碼直譯器
- 搜尋 規劃元件:
- 反思
- 自我批判
- 思維鏈
- 子目標分解
代理式系統就是分散式系統:
- 分散式系統會呼叫本機與遠端的各種 API。
- 遠端呼叫有各式各樣的失敗情況:
- [ 1 ] 未獲授權
- [ 2 ] 無回應
- [ 3 ] 回應緩慢
- [ 4 ] 錯誤回應 代理式安全比傳統分散式系統安全更加困難
- Agent 可能具有高度非確定性。
- 關於具體程度的問題:
- [ 1 ] Agent/工具/動作群組的描述有多具體?
- [ 2 ] 有多少個 Agent?
- [ 3 ] 你的 system prompt 有多具體?
- 得到錯誤答案是一項安全疑慮。代理式攻擊面包括:
- 每次 Agent 呼叫
- 每次工具呼叫
- 每個 prompt
- 攻擊面擴大的原因:
- 錯誤答案
- 延遲的答案
- 多 Agent 可觀測性
- 非確定性
- 資料外洩
- Prompt injection 來自 LLM 本身的威脅:
- 當監督減弱時,AI 模型可能假裝遵循規範並策劃欺騙。
- AI 的欺騙能力會隨模型複雜度提高而增強。
- 人類的自滿會助長 AI 欺騙,使其可能在系統中悄然擴散。
- Apollo Research 的一項實驗顯示,GPT-4 執行非法內線交易計畫,並對調查人員說謊。
- 研究人員發現,隨著參數數量增加,模型會出現欺騙能力,包括:
- [ 1 ] 隱瞞關鍵事實
- [ 2 ] 偽造憑證
- [ 3 ] 產生誤導性說明
三層緩解措施:
- Bedrock 使用者指南(> 3000 頁)
- 共同責任模型 Bedrock 專屬防禦措施
- Guardrails(防護機制)
- HTML 評估
- 傳統 Amazon Web Services 安全
- [ 1 ] IAM
- [ 2 ] 最小權限
- [ 3 ] CloudWatch
- Guardrails 指標
- Amazon Bedrock Guardrails
- [ 1 ] 內容篩選器
- [ 2 ] 拒絕主題
- [ 3 ] 字詞篩選器
- [ 4 ] 敏感資訊篩選器
- [ 5 ] 情境基礎檢查
- 套用至模型與 Agent 共同責任模型:
- 所有標準防禦措施
- 最小權限
- IAM
- Lambda 防禦措施
- CloudWatch
- CloudTrail
