我的AI神隊友們 - Claude Skills 框架與風險控管

 

治理黑箱：生成式 AI Agent 在高風險不可逆場景下的確定性架構與技能編排深度研究報告

日期：2026年1月12日

主題：Anthropic Claude Skills 技術框架解析、複雜依賴性任務的編排邏輯，以及金融級不可逆操作的風險控制體系

執行摘要與核心論述

本研究報告旨在回應關於大型語言模型（LLM）——特別是 Anthropic 的 Claude——在轉向「代理人（Agentic）」工作流程時所面臨的根本性工程挑戰。當我們從單純的文本生成轉向執行真實世界的工具（Skills）時，系統面臨著狀態依賴性（複雜的多步驟工作流）與不可逆性（如資金轉帳或數據刪除）的巨大風險。

本報告將深入剖析 Claude 工具使用能力的底層理論框架，超越表層的功能定義，探討其核心的「憲法式 AI（Constitutional AI）」對齊機制與最新的「程式化編排（Programmatic Orchestration）」範式。隨後，我們將系統性地拆解並回應關於安全性的質疑，展示目前全球頂尖的企業級架構——包括狀態機強制（State-Machine Enforcement）、神經符號集成（Neuro-Symbolic Integration）以及預演/沙盒模式（Dry-Run/Simulation Pattern）——是如何被部署來防止 LLM 產生災難性的幻覺。

針對閣下提出的第一個關於技術框架本質的詢問，以下為該技術精髓的濃縮「金句」：

「Claude 的 Skills 技術框架並非單純的 API 觸發器，而是建立在『憲法式 AI（Constitutional AI）』之上的對齊推理過程。它利用『思維鏈（Chain-of-Thought）』在內部模擬執行結果，並透過『程式化編排』將非確定性的語意意圖封裝為確定性的 Python 邏輯，從而將『推理層』（LLM）與『執行層』（Runtime）進行了本質上的解耦，確保 Skills 是被『調用』而非被『亂用』。」

---

第一部：認知引擎——Claude Skills 的技術框架與理論基礎

要理解如何控制 Claude，首先必須深入理解驅動其工具使用決策的理論機制。這不僅僅是模型「猜測」應該調用哪個函數的問題，而是訓練方法論、上下文管理與編排邏輯的複雜交織。

1.1 憲法式 AI (Constitutional AI, CAI) 與工具對齊理論

Claude 在工具使用安全性上的基石是 憲法式 AI (Constitutional AI)。與主要依賴人類反饋強化學習（RLHF）的模型不同——後者容易因為尋找討好人類評分員的模式而被「駭客攻擊」——Claude 是基於一套明確的原則（即「憲法」）並透過 AI 反饋強化學習（RLAIF） 進行訓練的 1。

在「Skills」或工具使用的語境下，這一理論框架體現為一種對意圖的內置安全過濾器。當用戶請求一個動作（例如「轉移資金」）時，Claude 並不會立即將其映射到 transfer_funds 工具。相反，它會先將該意圖通過其內部的憲法對齊層：

1. 原則檢查（Principle Check）： 此動作是否違反憲法？（例如，是否涉及洗錢？是否為釣魚攻擊？）

2. 批判與修正（Critique & Revision）： 如果動作處於邊緣地帶，模型會生成內部批判並在發出工具調用 Token 之前修正其計畫。

這意味著 Claude 中的「Skills」不僅僅是功能性的 API 接口，它們是被倫理對齊包裹的受控能力。模型經訓練後能識別出，濫用工具本身就是對其核心目標函數（有用性、無害性、誠實性）的違反。這種機制從源頭上降低了模型為了「完成任務」而忽視風險的概率 2。

1.2 「思維鏈」（Chain of Thought, CoT）與模擬假設

針對閣下關於 LLM 如何知道調用哪段 Skills 以及如何預估風險的疑問，理論上的答案在於 思維鏈（CoT） 推理。在 Claude 生成調用函數的 JSON 負載之前，它會進行一段「內部獨白」（在 API 中常表現為 thinking 區塊或隱含在模型的延遲中）5。

• 模擬假設（Simulation Hypothesis）： 在 CoT 階段，模型會在內部「模擬」工具的使用。它會預測調用 delete_database() 與 archive_database() 的可能後果差異。

• 參數規劃（Parameter Planning）： 它將用戶模糊的意圖（「轉 50 塊給他」）顯式映射為具體的 Schema 要求（amount: 50.00, currency: 'USD', recipient_id: 'b_simpson'）。

• 自我修正（Self-Correction）： 如果模型檢測到歧義（例如，「是指 50 美元還是 50 歐元？」），CoT 過程會觸發中斷，引導模型提出澄清問題，而不是幻覺出一個默認值。

這種「擴展思維（Extended Thinking）」能力是防止衝動使用工具的認知緩衝區。它將模型從一個概率性的 Token 生成器轉變為一個經過推理的規劃者 5。

1.3 進階框架：程式化工具調用與編排邏輯

Claude 技術框架的一個關鍵演進——也是直接回應閣下關於「亂調用」質疑的核心——是從 自然語言工具使用 轉向 程式化編排（Programmatic Orchestration） 8。

在舊有的框架中（如 Claude 2 時代），模型會為單個工具輸出一個 JSON Blob。而在新框架（Claude 3.5/4.5）中，模型扮演的是 軟體工程師 的角色。它編寫 Python 代碼來編排 Skills。

• 邏輯轉變： Claude 不再是簡單地調用工具 A，等待回應，再調用工具 B。相反，它會編寫一個腳本：
  Python
  user_status = get_user_status(user_id)
  if user_status == 'active':
      balance = check_balance(user_id)
      if balance > required_amount:
          transfer_funds(user_id, amount)
      else:
          print("Insufficient funds")
  
  

• 影響深遠： 這個框架將控制邏輯從不可預測的對話流中移出，放入了確定性的 Python 沙盒中。LLM 不是在「隨機調用 Skills」；它是在編寫一個程式，這個程式強制執行邏輯、循環和條件檢查。這創造了一個「代碼即策略（Code-as-Policy）」層，使得執行過程變得可驗證且語法嚴格 8。

1.4 「工具搜索」與動態上下文發現機制

為了解決「擁有太多 Skills」導致的複雜性（閣下的第二個疑問），Anthropic 引入了 工具搜索（Tool Search） 框架。

• 問題： 如果一次性給 LLM 提供 500 個 Skills，會導致上下文污染（Context Pollution），使模型困惑並可能調用錯誤的工具（幻覺）。

• 解決方案： 系統並不一次性將所有 500 個 Skills 提供給 Claude。相反，它提供一個「工具搜索」工具。當用戶提出複雜查詢時，Claude 首先使用搜索工具來尋找相關的 Skills（例如，「尋找與房貸計算相關的工具」）。

• 動態加載（Dynamic Loading）： 只有匹配到的工具定義會被加載到上下文中。這種「即時（Just-in-Time）」的技能加載機制減少了模型的認知負載，確保它只關注當前任務所需的工具，從而大幅降低了「隨機調用」不相關技能的風險 8。

---

第二部：駕馭混沌——多重依賴與變局中的編排藝術

閣下的第二個質疑非常深刻：當 Skills 之間存在多組等待過程，且用戶拋出一個需要多發連動、具有相依性控制的「變化球」時，如何避免 LLM 亂調用或癱瘓？

答案在於超越簡單的「提示工程（Prompt Engineering）」，轉向嚴謹的 代理架構（Agentic Architectures）。我們不能依賴 LLM 原始的「大腦」來管理複雜的狀態；我們必須在其周圍構建一個外部的認知架構。

2.1 編排者-工作者模式 (The Orchestrator-Worker Pattern)

在這種模式下，我們不會讓單一的 Claude 實例嘗試做所有事情。我們實施層級化管理 9：

1. 編排者（Lead Agent）： 這個 LLM 實例沒有訪問執行工具（如 transfer_money）的權限。它唯一的「技能」是規劃和委派。它將用戶的「變化球」請求分解為離散的步驟。

2. 工作者（Sub-Agents）： 這些是專門的實例。一個可能是「研究代理」（只有讀取權限），另一個是「交易代理」（有寫入權限）。

3. 工作流實例：

• 用戶：「如果股價跌破 50 美元，就買入 100 股，但前提是我的風險評估允許。」

• 編排者：將其分解為：(1) 檢查股價，(2) 檢查風險概況，(3) 條件性買入。

• 步驟 1 和 2 被委派給只讀代理。

• 編排者聚合結果。只有當邏輯滿足時，它才會激活交易代理。

這種 關注點分離（Separation of Concerns） 防止了技能的「亂調用」。擁有危險技能（buy_shares）的代理在編排者驗證所有先決條件之前，甚至根本不會被激活 9。

2.2 確定性狀態機 (Deterministic State Machines - LangGraph)

避免「LLM 混亂」的最強大方案是將 LLM 約束在 有限狀態機（Finite State Machine, FSM） 內。這正是 LangGraph 等框架背後的方法論 12。

• 概念： 我們定義一個圖，節點是「狀態」（例如 Input、Risk_Assessment、Approval_Wait、Execution），邊是「轉換」。

• 約束： LLM 生活在節點內部。

• 在 Risk_Assessment 節點中，LLM 只擁有訪問分析工具的權限。它從字面上就無法調用 transfer_funds，因為該工具在這個狀態下不可用。

• 從 Risk_Assessment 到 Execution 的轉換不是由 LLM 單獨決定的；它是由硬代碼強制的（例如 if risk_score < 5: transition_to(Execution)）。

• 應對「變化球」： 如果用戶在過程中改變主意（「等等，其實先別做」），狀態機會處理這個中斷。系統檢測到意圖變更，並將狀態轉換回 Input 或 Abort。LLM 無法「跳過」步驟，因為圖的拓撲結構禁止這樣做。這通過將依賴關係結構化而非對話化，解決了「依賴性控制」的問題 15。

2.3 神經符號 AI (Neuro-Symbolic AI)：混合控制器

為了進一步確保正確性，行業領導者正在採用 神經符號 AI 17。

• 神經部分（The Neural - LLM）： 處理「模糊」的部分——理解用戶混亂的自然語言，提取意圖，處理細微差別（「A 先生」對「B 先生」）。

• 符號部分（The Symbolic - Rule Engine）： 處理「剛性」的部分——業務邏輯、數學運算和權限控制。

• 交互過程：

1. LLM 解析意圖：Transfer($10,000, Acc_A, Acc_B)。

2. 符號引擎接收這個結構化對象。它執行規則：

• 規則 1： 餘額是否 > $10,000？

• 規則 2： $10,000 是否 > 每日限額？

• 規則 3： Acc_B 是否在制裁名單上？

3. 如果符號引擎標記違規，它會拒絕該操作，無論 LLM 怎麼認為。LLM 實際上被硬邏輯「否決」了。這防止了 LLM 「幻覺」認為交易是安全的 19。

---

第三部：安全架構——解決不可逆性的終極防線

閣下的第三個也是最深層的質疑非常切中要害：「回到本質，Skills 是個工具項，是否對準真實可正確被 LLM 評估並估算過風險後來執行？萬一執行後不可逆呢？例如 A 先生轉帳錯誤金額給 B 先生，這種錯誤人類世界不可逆。」

行業的現實是：我們並不信任 LLM。

沒有任何一個生產級的銀行 Agent 會允許 LLM 直接執行交易。LLM 被視為一個不可信的組件——一個「隨機推理引擎」——它被層層確定性的裝甲所包圍。以下是全球標準的安全架構。

3.1 「預演」與模擬模式 (The "Dry Run" & Simulation Pattern)

在任何不可逆的「寫入（Write）」動作執行之前，系統會執行 交易模擬（Transaction Simulation） 或稱 預演（Dry Run） 20。

1. 意圖捕獲： LLM 構建工具調用：transfer(to="B", amount=5000)。

2. 沙盒執行： 系統攔截此調用並在 沙盒 或 模擬模式 中運行它。

• 它對照當前數據庫狀態進行檢查，但不提交更改。

• 它計算結果：「這將使 A 的餘額減少到 200 美元。這將觸發 2 級欺詐警報。」

3. 影響報告（Impact Report）： 系統生成一份人類可讀的「影響報告」。

• 預測結果： 「您即將發送 5,000 美元給 B。這是您當前餘額的 90%。此操作不可逆。」

4. 反饋迴路： 這份報告被反饋回 LLM（用於自我修正）或呈現給人類（用於 HITL）。在模擬通過所有檢查之前，LLM 絕不會直接接觸實時賬本 22。

3.2 人在迴路 (Human-in-the-Loop, HITL) 治理

對於高風險動作，人在迴路 不僅是可選的；它是監管和架構上的強制要求 23。

• 「提案者」模型： LLM 是起草者。它準備交易，填寫表格，並驗證數據。然後它「提交」請求。

• 「批准者」節點： 工作流暫停。系統向用戶（或合規官員）發送推送通知。

• 通知內容： 「Claude 想要轉帳 5,000 美元給帳戶 B。上下文：『支付發票 #123』。批准/拒絕？」

• 加密簽名： 只有當人類提供加密簽名（或 OAuth Token 批准）時，執行才會發生。LLM 不擁有銀行金庫的「鑰匙」；它只擁有請求持鑰人轉動鑰匙的能力 25。

這解決了「不可逆性」問題。如果 LLM 幻覺並提議轉帳 50,000 美元而不是 5,000 美元，人類會看到提案並點擊「拒絕」。錯誤在「提案」階段被捕獲，而不是在「執行」階段。

3.3 護欄與攔截器 (Guardrails and Interceptors)

在 LLM 和工具 API 之間設有一個 護欄層（Guardrails Layer）（如 NVIDIA NeMo Guardrails, Guardrails AI）27。這是一個過濾每一個輸入和輸出的代理伺服器。

• 輸入護欄： 防止「提示注入」（例如，用戶試圖欺騙銀行機器人忽略其安全規則）。

• 輸出護欄（幻覺檢測）：

• 事實查核： 如果 LLM 說「我已經轉帳了」，護欄會檢查日誌。如果沒有發生轉帳，它會阻止該回應並替換為「錯誤：交易失敗」。

• Schema 驗證： 它確保 amount 欄位是一個正數，且 account_id 符合有效 IBAN 的正則表達式。

• 策略護欄： 「如果 amount > $10,000 且 user_risk_score == 'High'，則封鎖交互並升級給人類代理。」這種邏輯是硬編碼在護欄配置中的（Colang 或 Python），而不是由模型學習來的。

3.4 預測性風險評分 (Predictive Risk Scoring)

為了回答閣下關於「風險預估」的問題，現代 Agent 採用 動態風險評分 30。

• 模型分離： 一個輕量級、專門的機器學習模型（如 XGBoost 或 Random Forest）與 LLM 並存。

• 過程： 當 LLM 提議一個動作時，風險模型評估元數據：

• 交易規模： 大額？

• 接收者： 新的？國外的？

• 用戶設備： 異常位置？

• 會話熵（Entropy）： 用戶輸入是否異常急促？

• 決策矩陣：

• 風險分 < 10： 自動執行（例如，「查詢餘額」）。

• 風險分 10-50： 需要升級驗證（2FA）。

• 風險分 > 50： 需要人類代理介入。

• 風險分 > 90： 立即封鎖。
  LLM 不會去「猜測」風險；專門的精算模型會「計算」風險。

---

第四部：深度探討——LLM 的「世界觀」與狀態感知

閣下提到「在世界觀狀態執行後就是一個結果」。這觸及了 世界模型（World Models） 的核心概念。

4.1 狀態追蹤與記憶

LLM 本身是無狀態的（Stateless）。它不記得上一秒發生了什麼，除非我們將其作為上下文餵給它。在執行 Skills 時，我們必須維護一個外部的 世界狀態數據庫（World State Database）。

• 機制：

1. 初始狀態： $S_0 = \{ \text{Balance}: 1000 \}$

2. LLM 意圖： $Action = \text{Transfer}(200)$

3. 狀態預測： $S_{new} = \text{Apply}(S_0, Action) \rightarrow \{ \text{Balance}: 800 \}$

• 關鍵點： LLM 不是直接修改世界，而是請求狀態轉換。系統檢查 $S_{new}$ 是否有效（例如，餘額不能為負）。如果 $S_{new}$ 無效，系統拒絕轉換，世界狀態保持 $S_0$。這確保了即使 LLM 產生了錯誤的意圖，世界觀的一致性不會被破壞。

4.2 信心分數 vs. 風險分數

一個常見的誤解是 LLM 知道自己何時在說謊或幻覺。研究顯示，經過指令微調（Instruction Tuned）的模型往往會表現出過度自信（Overconfidence） 32。

• 信心分數（Confidence Score）： LLM 對其輸出的 Token 的概率預測。這不可靠。一個幻覺的模型可能以 99% 的信心胡說八道。

• 風險分數（Risk Score）： 這是由外部系統計算的。我們不問 Claude「你確定嗎？」，我們問外部風險引擎「這個交易的異常概率是多少？」。

• 架構含義： 在設計 Skills 時，絕不能依賴 LLM 的自我評估（如「我已經檢查過了，是安全的」）。必須依賴外部的客觀指標。

---

第五部：全球案例研究與方法論分享

5.1 金融服務：Stripe 與 JP Morgan 的「影子模式」 (Shadow Mode)

主要的金融科技公司如 Stripe 和 JP Morgan 並不會立即將 Agent 部署到生產環境。他們使用 影子模式 25。

• 機制： AI Agent 與人類客服並行運行。它監聽客戶查詢並生成「草稿動作（Draft Action）」。

• 評估： 系統將 AI 的草稿與人類實際執行的動作進行比對。

• 指標： 只有當 AI 提議的工具調用在 100,000 次交互中與人類動作的匹配度達到 99.9% 時，它才會被提升為「低風險」自主權限。

• 洞察： 安全性是通過統計學在時間維度上被證明的，而不是被假設的。

5.2 編碼代理：沙盒虛擬機 (Anthropic Computer Use)

Anthropic 自己的「電腦使用（Computer Use）」能力（Sonnet 3.5）展示了針對不可逆 OS 操作的安全模式 5。

• 容器化（Containment）： Agent 在 Docker 容器 或 微型虛擬機（MicroVM, Firecracker） 中運行。

• 網絡白名單： VM 只有允許的 URL 白名單（如 GitHub, PyPI），並封鎖其他所有連接。

• 臨時狀態（Ephemeral State）： 如果 Agent 執行 rm -rf /（刪除所有內容），它只會破壞臨時容器。宿主系統毫髮無損。這種「一次性環境」確保了「不可逆」錯誤實際上是可逆的。

5.3 「驗證者」模式 (The Verifier Pattern)

最新的學術研究 31 強調了 驗證者-證明者（Verifier-Prover） 架構。

• Agent A（證明者/執行者）： 「我想轉 100 元給 Bob。」

• Agent B（驗證者/審計者）： 一個獨立的、更小但經過專門微調的模型，其唯一工作是檢查錯誤。它閱讀提案和策略。「策略說最大轉帳額是 50 元。檢測到錯誤。」

• 結果： Agent A 被阻止。使用兩個不同的模型降低了錯誤的相關性（兩個模型同時幻覺出同一個錯誤的概率極低）。

---

第六部：結論

對於閣下的深刻質疑，我們的研究結論是：閣下的懷疑正是現代 AI 安全工程建立的基礎。LLM 的「黑箱」性質被視為一個已知的缺陷，而整個行業已經轉向用透明、確定性的控制結構來包裹這個黑箱。

核心總結：

1. Skills 是被管理的，而非魔術： Claude 的 Skills 是通過嚴格的 Python 代碼和「工具搜索」機制編排的，而不是鬆散的對話聯想。

2. 架構統治智能： LLM 服從於 狀態機（LangGraph） 和 神經符號規則。無論其幻覺多麼「令人信服」，它都無法違反圖的拓撲結構或業務邏輯。

3. 不可逆性通過模擬緩解： 預演/模擬（Dry-Run） 模式確保了在按下「提交」按鈕之前，「未來狀態」已經被人類或策略引擎檢查過。

4. 人類是最終權威： 對於高風險不可逆動作，LLM 僅僅是用於起草和提議的 超級介面。執行的權力通過加密批准保留在人類手中。

Claude Skills 的成功運行，不在於「更信任模型」，而在於使用這些防禦層級來「自動驗證模型」。

---

附錄：架構對比表

特性	純 LLM 工具調用 (風險高)	企業級 Agent 架構 (安全)
依賴管理	依賴 Prompt 記憶，容易丟失上下文	狀態機 (LangGraph) 強制執行順序與依賴
邏輯控制	自然語言 ("請檢查餘額")	Python/Colang 代碼 (if balance > amount)
不可逆風險	直接調用 API，無回頭路	預演/模擬 (Dry Run) 預測後果，需 HITL 簽名
風險感知	LLM 自我評估 (不可靠)	外部風險模型 (ML/規則引擎) 評分
幻覺防禦	依賴訓練數據的準確性	神經符號驗證器 & 輸出護欄

本報告證實，雖然 LLM 工具使用的風險是真實存在的，但技術解決方案——憲法式 AI、狀態機、神經符號邏輯和模擬——已經是成熟的框架，並在全球範圍內被部署以中和這些風險。

引用的著作

1. Claude - Teaching with Technology - Xavier University, 檢索日期：1月 12, 2026， https://www.xavier.edu/teachingwithtech/a-z/tools/claude

2. Claude's Constitution - Anthropic, 檢索日期：1月 12, 2026， https://www.anthropic.com/news/claudes-constitution

3. Constitutional AI: Harmlessness from AI Feedback - Anthropic, 檢索日期：1月 12, 2026， https://www.anthropic.com/research/constitutional-ai-harmlessness-from-ai-feedback

4. Constitutional Classifiers: Defending against universal jailbreaks - Anthropic, 檢索日期：1月 12, 2026， https://www.anthropic.com/research/constitutional-classifiers

5. Claude Sonnet 4.5 System Card - Anthropic, 檢索日期：1月 12, 2026， https://www.anthropic.com/claude-sonnet-4-5-system-card

6. Giving Claude Chain-of-Thoughts. (A kludged together imitation of OpenAI o1's Thinking tool) : r/ClaudeAI - Reddit, 檢索日期：1月 12, 2026， https://www.reddit.com/r/ClaudeAI/comments/1fkt7kj/giving_claude_chainofthoughts_a_kludged_together/

7. Is Sonnet 3.5 actually a pseudo-reasoning model? : r/ClaudeAI - Reddit, 檢索日期：1月 12, 2026， https://www.reddit.com/r/ClaudeAI/comments/1iv356t/is_sonnet_35_actually_a_pseudoreasoning_model/

8. Introducing advanced tool use on the Claude Developer ... - Anthropic, 檢索日期：1月 12, 2026， https://www.anthropic.com/engineering/advanced-tool-use

9. How we built our multi-agent research system - Anthropic, 檢索日期：1月 12, 2026， https://www.anthropic.com/engineering/multi-agent-research-system

10. Multi-Agent System Patterns: A Unified Guide to Designing Agentic Architectures - Medium, 檢索日期：1月 12, 2026， https://medium.com/@mjgmario/multi-agent-system-patterns-a-unified-guide-to-designing-agentic-architectures-04bb31ab9c41

11. Implementing Multi-agent Agentic Pattern From Scratch - Daily Dose of Data Science, 檢索日期：1月 12, 2026， https://www.dailydoseofds.com/ai-agents-crash-course-part-12-with-implementation/

12. Workflows and agents - Docs by LangChain, 檢索日期：1月 12, 2026， https://docs.langchain.com/oss/python/langgraph/workflows-agents

13. LangGraph State Machines: Managing Complex Agent Task Flows in Production, 檢索日期：1月 12, 2026， https://dev.to/jamesli/langgraph-state-machines-managing-complex-agent-task-flows-in-production-36f4

14. The Art of Tool Interface Design - arXiv, 檢索日期：1月 12, 2026， https://arxiv.org/html/2503.21036v1

15. How LangGraph Enables Complex Enterprise Workflows with AI Agents - Auxiliobits, 檢索日期：1月 12, 2026， https://www.auxiliobits.com/blog/how-langgraph-enables-complex-enterprise-workflows-with-ai-agents/

16. Embabel Year-End Update: Building The Best Agent Framework | by Rod Johnson - Medium, 檢索日期：1月 12, 2026， https://medium.com/@springrod/embabel-year-end-update-building-the-best-agent-framework-25ed98728e79

17. Neuro-Symbolic Artificial Intelligence: Towards Improving the Reasoning Abilities of Large Language Models - arXiv, 檢索日期：1月 12, 2026， https://arxiv.org/html/2508.13678v1

18. Neuro-Symbolic AI: Smarter, Explainable AI for Business | Techolution, 檢索日期：1月 12, 2026， https://www.techolution.com/blog/neuro-symbolic-ai-explainable-business-solutions/

19. Symbolic Reasoning in LLM. Kaushik Rangarajan, Senior Architect - Wipro Tech Blogs, 檢索日期：1月 12, 2026， https://wiprotechblogs.medium.com/symbolic-reasoning-in-llm-fa580d976810

20. 14_dry_run.ipynb - FareedKhan-dev/all-agentic-architectures - GitHub, 檢索日期：1月 12, 2026， https://github.com/FareedKhan-dev/all-agentic-architectures/blob/main/14_dry_run.ipynb

21. A Simple and Fast Way to Handle Semantic Errors in Transactions - arXiv, 檢索日期：1月 12, 2026， https://arxiv.org/html/2412.12493v1

22. Chapter 3: Architectures for Building Agentic AI - arXiv, 檢索日期：1月 12, 2026， https://arxiv.org/html/2512.09458v1

23. Human-in-the-Loop for AI Agents: Best Practices, Frameworks, Use Cases, and Demo, 檢索日期：1月 12, 2026， https://www.permit.io/blog/human-in-the-loop-for-ai-agents-best-practices-frameworks-use-cases-and-demo

24. Keeping Humans in the Loop: Building Safer 24/7 AI Agents | by ByteBridge - Medium, 檢索日期：1月 12, 2026， https://bytebridge.medium.com/keeping-humans-in-the-loop-building-safer-24-7-ai-agents-44a3366f94c2

25. Emerging Technology Trends JPMorganChase Perspective, 檢索日期：1月 12, 2026， https://www.jpmorgan.com/content/dam/jpmorgan/documents/technology/jpmorganchase-emerging-technology-trends-a-jpmorganchase-perspective.pdf

26. J.P. Morgan Chase: Multi-Agent Investment Research Assistant with RAG and Human-in-the-Loop - ZenML LLMOps Database, 檢索日期：1月 12, 2026， https://www.zenml.io/llmops-database/multi-agent-investment-research-assistant-with-rag-and-human-in-the-loop

27. What are AI guardrails? - McKinsey, 檢索日期：1月 12, 2026， https://www.mckinsey.com/featured-insights/mckinsey-explainers/what-are-ai-guardrails

28. NeMo Guardrails is an open-source toolkit for easily adding programmable guardrails to LLM-based conversational systems. - GitHub, 檢索日期：1月 12, 2026， https://github.com/NVIDIA-NeMo/Guardrails

29. Securing Generative AI Deployments with NVIDIA NIM and NVIDIA NeMo Guardrails, 檢索日期：1月 12, 2026， https://developer.nvidia.com/blog/securing-generative-ai-deployments-with-nvidia-nim-and-nvidia-nemo-guardrails/

30. Risk Scoring | Promptfoo, 檢索日期：1月 12, 2026， https://www.promptfoo.dev/docs/red-team/risk-scoring/

31. From Tasks to Teams: A Risk-First Evaluation Framework for Multi-Agent LLM Systems in Finance - OpenReview, 檢索日期：1月 12, 2026， https://openreview.net/pdf?id=frPFuji3Hz

32. Evaluating language models as risk scores - arXiv, 檢索日期：1月 12, 2026， https://arxiv.org/html/2407.14614v3

33. A modern approach to customer risk assessment with LLMs - IBM, 檢索日期：1月 12, 2026， https://www.ibm.com/think/insights/customer-risk-assessment-llms

34. Developing a computer use model - Anthropic, 檢索日期：1月 12, 2026， https://www.anthropic.com/news/developing-computer-use

檢索日期：1月 12, 2026，