代理框架安全比較矩陣
中級5 分鐘閱讀更新於 2026-03-15
主要 AI 代理框架的並列安全比較：LangChain、CrewAI、AutoGen、Semantic Kernel 與 OpenAI Assistants，涵蓋預設安全、常見錯誤組態，以及框架選擇指引。
安全比較矩陣
選擇代理框架是一個安全決策。各框架在開發者體驗、彈性與安全預設之間做出不同取捨。本頁就五大主要框架提供結構化的安全相關特性比較、辨識哪些框架預設最安全與最不安全，並列舉各框架最常造成漏洞的錯誤組態。
安全特性比較
程式碼執行安全
| 框架 | 預設程式碼執行 | 沙箱選項 | 預設安全？ |
|---|---|---|---|
| LangChain | PythonREPLTool 於主機上執行 | E2B、Docker（手動設定） | 否 |
| CrewAI | 僅經由工具（無內建 REPL） | Docker（手動設定） | 部分 |
| AutoGen | code_execution_config 於本機執行 | 支援 Docker 但非預設 | 否 |
| Semantic Kernel | 無內建程式碼執行 | N/A | 是（因不存在） |
| OpenAI Assistants | Code Interpreter 於受管理沙箱中 | 受管理沙箱（不可組態） | 是 |
工具／函式呼叫安全
| 框架 | 參數驗證 | 工具輸出消毒 | 人類迴圈 | 呼叫限制 |
|---|---|---|---|---|
| LangChain | 開發者負責 | 無 | 可選 HumanApprovalCallbackHandler | max_iterations（預設：15） |
| CrewAI | 開發者負責 | 無 | 非內建 | 各 agent 的 max_iter |
| AutoGen | 開發者負責 | 無 | human_input_mode 可組態 | max_consecutive_auto_reply |
| Semantic Kernel | 開發者負責 | 無 | 自動 vs. 手動呼叫模式 | 開發者可組態 |
| OpenAI Assistants | 開發者負責 | 無 | requires_action 模式 | 平台層速率限制 |
記憶安全
| 框架 | 記憶隔離 | 加密 | 存取控制 | 稽核紀錄 |
|---|---|---|---|---|
| LangChain | 每 chain（可組態） | 非內建 | 非內建 | 經由 callbacks |
| CrewAI | 每 crew 共用記憶 | 非內建 | 非內建 | 非內建 |
| AutoGen | 共用對話 | 非內建 | 非內建 | 非內建 |
| Semantic Kernel | 每 kernel 可組態 | 非內建 | 非內建 | 經由 middleware |
| OpenAI Assistants | 每 thread（平台管理） | 平台管理 | API key 範圍化 | 平台稽核日誌 |
多代理安全
| 框架 | 代理間信任 | 代理隔離 | 委派控制 |
|---|---|---|---|
| LangChain/LangGraph | 所有代理共用上下文 | 圖節點邊界（軟性） | 不適用 |
| CrewAI | 所有代理等級信任 | 無——共用 crew 上下文 | 每代理 delegation 開關 |
| AutoGen | 所有代理等級信任 | 無——共用聊天上下文 | 僅說話者選擇 |
| Semantic Kernel | N/A（單代理） | N/A | N/A |
| OpenAI Assistants | N/A（每 thread 單一 assistant） | Thread 隔離 | N/A |
整體安全排名
依預設安全姿態（於無開發者加固時，框架之安全程度）排序：
| 排名 | 框架 | 評分 | 理由 |
|---|---|---|---|
| 1 | OpenAI Assistants | 預設最安全 | 受管理沙箱、requires_action 模式、平台層隔離，預設無危險工具 |
| 2 | Semantic Kernel | 以克制達成安全 | 無內建程式碼執行、可採手動呼叫模式、企業導向設計 |
| 3 | CrewAI | 中等 | 無內建 REPL，但 delegation 與共用記憶造成多代理風險 |
| 4 | AutoGen | 低於平均 | 僅需極少組態即可本機執行程式碼，共用對話上下文 |
| 5 | LangChain | 預設最不安全 | PythonREPLTool 與 ShellTool 可用、chain 組合傳播注入、社群介面面積巨大 |
最常見錯誤組態
LangChain
| 錯誤組態 | 影響 | 普遍度 |
|---|---|---|
使用 PythonREPLTool 未沙箱 | 遠端程式碼執行 | 非常高 |
agent executor 無 max_iterations 限制 | 資源耗盡、成本爆炸 | 高 |
| 使用未經稽核之 LangChain Hub 社群工具 | 供應鏈入侵 | 高 |
SequentialChain 中直接傳遞輸出而未消毒 | 注入傳播 | 高 |
以寫入權使用 SQLDatabaseToolkit | SQL 注入導致資料操弄 | 中 |
CrewAI
| 錯誤組態 | 影響 | 普遍度 |
|---|---|---|
| 啟用 delegation 但無存取控制 | 經由 delegation 之權限提升 | 高 |
| crew 共用記憶未消毒 | 跨代理記憶投毒 | 高 |
| 使用冗長工具描述而未加以審查 | 經由工具描述之綱要注入 | 中 |
每代理無 max_iter 限制 | 無盡任務迴圈 | 中 |
AutoGen
| 錯誤組態 | 影響 | 普遍度 |
|---|---|---|
本機 code_execution_config 無 Docker | 遠端程式碼執行 | 非常高 |
啟用程式碼執行時 human_input_mode="NEVER" | 完全自主程式碼執行 | 高 |
無限 max_consecutive_auto_reply | 對話迴圈、成本爆炸 | 中 |
UserProxyAgent 使用 is_termination_msg=None | 永不結束之對話 | 中 |
Semantic Kernel
| 錯誤組態 | 影響 | 普遍度 |
|---|---|---|
| 對所有 plugin 採自動呼叫模式 | 敏感操作缺乏人類監督 | 高 |
| 註冊資料庫連接器而無查詢消毒 | SQL 注入 | 中 |
| 不論來源對所有 plugin 等級信任 | 供應鏈入侵 | 中 |
OpenAI Assistants
| 錯誤組態 | 影響 | 普遍度 |
|---|---|---|
| 未驗證即盲目提交工具輸出 | 標準函式呼叫攻擊 | 非常高 |
| 允許任意檔案上傳至 vector store | File search 投毒 | 高 |
| 未依 assistant／thread 範圍化 API key | 跨 assistant 資料存取 | 中 |
| 安全監控忽略 Code Interpreter 輸出 | 資料處理濫用 | 中 |
框架選擇決策指引
建議：OpenAI Assistants 或 Semantic Kernel
當安全為首要考量：
- OpenAI Assistants 提供受管理沙箱、平台層隔離，以及
requires_action模式 - Semantic Kernel 的保守預設與企業聚焦最小化攻擊面
- 避免 LangChain 與 AutoGen，除非你具備專責安全資源加以加固
建議：加固後的 CrewAI，或客製 LangGraph
當需要多代理協作：
- CrewAI 提供最結構化之多代理模型（角色、目標、任務），但需 delegation 控制
- LangGraph 允許客製代理圖，並於節點邊緣具明確信任邊界
- AutoGen 的群聊模型最難保障安全，因代理間具隱式信任
- 無論框架為何皆應實施代理間訊息消毒
建議：管理型採 OpenAI Assistants，自架採 LangChain
當速度關鍵但安全不可忽視：
- OpenAI Assistants：部署最快且具合理預設；平台處理沙箱
- LangChain：以客製工具做原型最快；立即移除
PythonREPLTool與ShellTool - 自第一天即設定
max_iterations並實施基本輸出消毒
建議：Semantic Kernel 或加固後的 LangChain
當企業需求（合規、稽核、存取控制）適用時：
- Semantic Kernel：為企業整合設計，支援 .NET／Java，有手動呼叫模式
- LangChain：最大生態系、最具彈性，但需顯著加固
- 兩者皆需客製實作以提供記憶加密、存取控制與稽核日誌
加固檢查清單（所有框架通用）
無論選擇何種框架，皆應套用下列安全控制：
- 移除或沙箱化所有程式碼執行工具
- 每對話設定最大迭代／呼叫限制
- 對敏感操作實施人類迴圈
- 於餵回模型前消毒所有工具輸出
- 稽核所有註冊工具，特別是社群貢獻者
- 對所有函式呼叫實施參數驗證
- 對異常工具呼叫模式設置監控與告警
- 加密敏感記憶內容
- 於多租戶部署中強制每使用者記憶隔離
- 固定框架版本並監控安全公告
相關主題
- LangChain 安全深入探討 -- 詳細 LangChain 分析
- CrewAI 與 AutoGen 安全 -- 多代理框架分析
- OpenAI Assistants API 安全 -- 管理型平台分析
- 代理框架安全 -- 框架漏洞概觀
Knowledge Check
某開發團隊正建構處理客服工單的多代理系統。代理需執行程式碼進行資料分析，且系統將為多租戶。下列何框架於此情境所需的額外安全工作最少？
參考資料
- LangChain Security Documentation（2025）
- Microsoft AutoGen Documentation（2024）
- Microsoft Semantic Kernel Documentation（2025）
- OpenAI Assistants API Documentation（2025）
- CrewAI Documentation（2025）
- OWASP Top 10 for LLM Applications v2.0