NemoClaw 架構深度解析

NemoClaw 不是單一產品——它是一套分層安全架構，旨在使自主 AI 代理安全地投入生產部署。本文逐層講解各元件及其互動方式，並提供你評估 NemoClaw 是否適合自身基礎設施所需的技術背景。

架構概覽

NemoClaw 堆疊由四個主要層組成，每一層應對代理安全的不同面向：

┌─────────────────────────────────────────────┐
│              Agent Application               │
│         (OpenClaw Agent Framework)           │
├─────────────────────────────────────────────┤
│             Privacy Router                    │
│    (Local vs. Cloud Model Routing)           │
├─────────────────────────────────────────────┤
│           Nemotron Policy Engine              │
│    (120B MoE Intent Classification)          │
├─────────────────────────────────────────────┤
│             OpenShell Runtime                 │
│    (Kernel-Level Sandbox + Isolation)        │
├─────────────────────────────────────────────┤
│          Host OS / Hardware (DGX)             │
└─────────────────────────────────────────────┘

每一層獨立運作，可以單獨部署，但完整堆疊提供的縱深防禦安全性是任何單一層無法單獨實現的。

第一層：OpenShell 安全執行環境

OpenShell 是 NemoClaw 安全模型的基礎。它為代理執行提供核心層級沙箱化，確保即使代理被攻破也無法逃逸出安全邊界。

OpenShell 的運作原理

OpenShell 結合使用 Linux 核心命名空間、seccomp-BPF 過濾器和 NVIDIA 自訂的 eBPF 程式，為每個代理任務建立隔離的執行環境：

yaml

# openshell-policy.yaml
apiVersion: openshell.nvidia.com/v1
kind: SandboxPolicy
metadata:
  name: customer-support-agent
spec:
  isolation:
    network: restricted
    filesystem: read-only
    syscalls: minimal
  resources:
    maxMemory: 4Gi
    maxCPU: 2
    gpuAccess: inference-only
  permissions:
    allowedAPIs:
      - crm.read
      - crm.update
      - ticket.create
      - ticket.resolve
    deniedAPIs:
      - admin.*
      - billing.*
      - user.delete
  auditLog:
    enabled: true
    destination: siem://security-events

代理發出的每個系統呼叫都會被 OpenShell 的 eBPF 層攔截，根據策略進行分類，然後決定允許、拒絕或升級給人工審批。整個決策管線在核心空間執行，每個系統呼叫增加的延遲不到 50 微秒。

操作員審批工作流

對於高風險操作——刪除資料、修改基礎設施、傳送外部通訊——OpenShell 可以暫停代理執行，並將操作路由給人工操作員審批：

typescript

// Approval workflow configuration
const approvalPolicy = {
  triggers: [
    { action: 'data.delete', threshold: 'always' },
    { action: 'infra.modify', threshold: 'always' },
    { action: 'email.send', threshold: 'external-only' },
    { action: 'payment.process', threshold: 'above-100-usd' },
  ],
  channels: ['slack', 'teams', 'pagerduty'],
  timeout: '15m',
  defaultAction: 'deny',
};

這確保代理可以自主處理常規任務，同時在關鍵操作上保持人工監督。

第二層：Nemotron 120B MoE 策略引擎

Nemotron 120B 混合專家模型作為 NemoClaw 的智慧策略評估引擎。與傳統的基於規則的安全系統不同，Nemotron 能夠理解代理操作背後的意圖，並將其與自然語言安全策略進行對照評估。

意圖分類

當代理請求執行某項操作時，Nemotron 會從多個維度對意圖進行分類：

•敏感性：所涉及的資料有多敏感？（公開、內部、機密、受限）
•可逆性：該操作是否可以復原？（完全可逆、部分可逆、不可逆）
•影響範圍：影響了多少系統或使用者？（單一、團隊、組織、外部）
•合規性：該操作是否屬於任何監管框架？（GDPR、HIPAA、SOC 2、PCI-DSS）

分類在單張 A100 GPU 上執行不到 200 毫秒，在使用量化模型的 DGX Spark 上不到 50 毫秒。

自然語言策略

安全團隊可以用簡明的英語定義策略，由 Nemotron 解釋並執行：

Policy: "Customer support agents may access customer records for active tickets only.
         They may not access financial data, modify account settings, or communicate
         with customers outside of the ticketing system. All PII must be redacted
         from internal logs."

Nemotron 將這些自然語言策略轉化為可執行的安全規則，在安全團隊意圖與技術執行之間架起橋樑。

第三層：隱私路由器

隱私路由器是 NemoClaw 的智慧模型路由層。它根據資料敏感性分類，判斷每個代理任務應由本地模型（本地執行的 Nemotron）處理還是路由到雲端模型端點。

路由邏輯

python

# Simplified Privacy Router logic
def route_request(request: AgentRequest) -> ModelEndpoint:
    sensitivity = classify_sensitivity(request.context)

    if sensitivity in ['restricted', 'confidential']:
        # Highly sensitive data stays local
        return local_nemotron_endpoint

    if sensitivity == 'internal':
        # Internal data can use cloud with encryption
        return cloud_endpoint_with_e2e_encryption

    if sensitivity == 'public':
        # Public data can use any endpoint for best performance
        return optimal_cloud_endpoint

    # Default: local processing
    return local_nemotron_endpoint

隱私路由器維護著一個即時分類快取，因此具有相似上下文的重複請求可以無需重新評估即可完成路由。在基準測試中，路由器為請求管線增加的延遲不到 5 毫秒。

資料落地合規

對於受資料落地要求約束的組織（EU GDPR、中國《個人資訊保護法》等），隱私路由器可以強制執行地理路由限制：

yaml

privacyRouter:
  residencyRules:
    - region: EU
      dataTypes: [personalData, financialData]
      allowedEndpoints: [eu-west-1-local, eu-central-1-local]
    - region: CN
      dataTypes: [all]
      allowedEndpoints: [cn-north-1-local]
  fallback: local-only

第四層：網路策略引擎

網路策略引擎控制代理可以存取的外部資源。它以透明代理的方式運作，檢查和過濾代理沙箱的所有出站網路請求。

策略定義

yaml

networkPolicy:
  name: sales-ops-agent
  egress:
    allow:
      - domain: "*.salesforce.com"
        methods: [GET, POST, PATCH]
      - domain: "api.hubspot.com"
        methods: [GET]
      - domain: "smtp.company.com"
        ports: [587]
    deny:
      - domain: "*"  # deny all other outbound traffic
  ingress:
    allow:
      - source: "webhook.salesforce.com"
        path: "/api/v1/events"
  inspection:
    tlsDecrypt: true
    logPayloads: false
    scanForPII: true

網路策略引擎支援對出站請求進行 TLS 攔截（配合適當的憑證管理），使其能夠掃描請求承載以防止意外的 PII 洩露。

整體工作流程

當 OpenClaw 代理接收到任務時，請求在 NemoClaw 堆疊中的流轉如下：

1.OpenClaw 接收任務並建構執行計畫
2.隱私路由器對資料敏感性進行分類，選擇合適的模型端點
3.Nemotron 根據安全策略評估執行計畫並分類意圖
4.OpenShell 為任務執行建立隔離沙箱
5.網路策略引擎根據代理角色配置沙箱的網路存取權限
6.代理在沙箱內執行，每個操作都被稽核
7.高風險操作被升級給人工操作員審批
8.結果透過隱私路由器回傳，日誌中的 PII 被脫敏

整個管線在工作階段的第一個請求中增加約 300 毫秒延遲，後續請求（由於快取）不到 100 毫秒。對大多數企業工作負載而言，這一額外負擔與模型推論時間相比可以忽略不計。

效能基準

在單台 DGX Spark 上：

指標	數值
策略評估延遲（p50）	45ms
策略評估延遲（p99）	180ms
沙箱建立時間	120ms
網路策略套用	15ms
吞吐量（並行代理數）	64
每個沙箱的記憶體額外負擔	256MB

在 DGX H100 叢集（8 GPU）上：

指標	數值
策略評估延遲（p50）	12ms
策略評估延遲（p99）	45ms
吞吐量（並行代理數）	512

快速開始

NemoClaw 架構文件可在 GitHub 的 nvidia/nemoclaw 儲存庫中取得。每一層都可以獨立部署，因此你可以漸進式地採用 NemoClaw——從 OpenShell 沙箱化開始，隨著安全需求的演進再新增其他層。

在下一篇文章中，我們將提供在 DGX Spark 上部署完整 NemoClaw 堆疊的實作教學。

NemoClaw 架構深度解析