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 架构深度解析