企业官网建设流程全解析

1. 从一次“失控”事故说起

先说个真事儿。几个月前我给某个内部业务做了个 AI Agent，功能很简单：让大模型读客户发来的邮件附件，提取关键字段，然后回写进 CRM 系统。前期本地测试一切正常，模型对样例数据的抽取准确率也挺漂亮。结果一上生产就翻了车——某个附件里藏了段特殊指令，Agent 不仅把该转发的数据拿了出来，还顺手调用了另一个工具，去读取了服务器上跟此业务完全无关的环境变量文件。

排查到最后，问题不在模型推理，而是整个执行链路没有任何边界。Agent 的代码跑在宿主机进程里，能访问的目录是整个项目目录，能调用的工具全部是全局注册的，网络出口也没有管控。那次之后我才意识到，大模型本身再聪明，只要执行侧没有围栏，它依然是裸奔的。

这也是我后来重点研究 DeepSeek Harness 的原因。这套框架解决的核心问题非常聚焦：当 AI Agent 要执行代码、调用工具、读写文件、访问网络时，怎么把它的权限限制在最小范围内，同时不影响正常功能。它不是给你加一层认证鉴权就完事的应用层安全，而是从进程、文件系统、网络、资源配额四个维度把 Agent 包进一个可控的沙箱里。

这篇内容对谁有价值？两类人。第一类是已经在做 Agent 开发、但还没认真考虑过执行隔离的工程师，你能从中找到一套可以直接落地的隔离策略模板；第二类是架构师或技术负责人，正在评估 Agent 应用的安全方案，需要理解沙箱隔离到底隔离了什么、能做到什么粒度、有哪些绕不过的坑。下面所有内容都基于我和团队实际部署 DeepSeek Harness 的经验，以及我们对沙箱原理的拆解。

2. 沙箱隔离策略的整体设计思路

2.1 先想清楚风险边界在哪里

很多团队做 Agent 安全时，第一反应是“给工具调用加权限校验”。比如 Agent 要读某个文件，先判断它有没有权限；要调某个 API，先验证 API Key。这种做法当然有用，但它是应用层的逻辑判断，意味着所有规则都依赖上层代码老老实实地执行。一旦模型被提示注入、工具实现有漏洞、或者某个参数传得不对，上层校验就可能被绕过。

DeepSeek Harness 的沙箱设计思路恰恰相反：它假设 Agent 没有不透风的墙，所以把执行环境本身做成了“一个房间”。房间里你可以随便折腾，但房间的墙是硬的，你想出去必须先撞墙。这个“墙”不是逻辑层的 if-else，而是操作系统层面的隔离机制——进程跑在独立的命名空间里，文件系统被挂载成只读，网络出口要过代理网关。逻辑可以绕过，系统机制不好绕过。

这个思路的转变很重要。做安全的人常说“信任边界”，在 Agent 场景里，你的信任边界不应该画在“Agent 的代码逻辑”上，而应该画在“运行沙箱的边界”上。前者是一堆可被诱导的指令判断，后者是内核帮你兜底的强隔离。

2.2 四层隔离模型

DeepSeek Harness 的隔离策略可以概括为四层：

• 进程层：每个 Agent 实例跑在独立的命名空间中，拥有自己的 PID、网络栈、挂载点视图。进程之间互不可见。
• 文件层：沙箱内看到的文件系统是经过重映射的视图，宿主机目录只读挂载，Agent 可写的目录被限制在一个临时存储区。
• 网络层：沙箱内外网隔离，Agent 的联网请求统一走网关代理，由策略引擎决定是否放行。
• 资源层：CPU、内存、磁盘、超时时间都有配额上限，防止 Agent 因为模型幻觉或死循环把宿主机资源吃光。

这四层是递进关系。进程层解决“你是谁”的问题，文件层解决“你能看什么”的问题，网络层解决“你能去哪里”的问题，资源层解决“你能占多少”的问题。每一层都有独立的配置项，也可以单独启用或关闭。

2.3 为什么选择“默认拒绝”而不是“默认允许”

常见的访问控制有两种模式：黑名单（默认允许，碰到危险项拦截）和白名单（默认拒绝，碰到明确允许项才放行）。DeepSeek Harness 在沙箱策略上强制走白名单模式。

举个例子，Agent 需要读取某个数据文件，你不能说“允许读取 /data 目录下的所有文件”，否则 Agent 可能读走敏感的子目录；你需要精确配置“允许读取 /data/input/ 下的 .csv 文件，路径模板为 /data/input/*.csv”。每一个规则都要明确：主体是谁、动作是什么、对象是什么、路径匹配模式是什么。

这种模式对配置的要求很高，一开始会明显拖慢开发节奏——每次 Agent 要访问新资源，都得先去加一条规则。但它的好处是持久的安全确定性。黑名单模式永远在追赶攻击者的创造力，白名单模式把 Agent 的活动空间收敛到一个可枚举的集合内。对于一个会自主决策的程序来说，让它的行动空间可枚举，比让它自由行动然后靠监控告警兜底，安全水位高了一个量级。

3. 核心隔离机制与实操要点

3.1 进程隔离：用 Linux 命名空间构建“看不见的墙”

DeepSeek Harness 的沙箱底层默认依赖 Linux 命名空间（Namespace）和 cgroup 实现。一个沙箱实例启动时，Harness 会先创建一组隔离的命名空间，再把 Agent 的执行进程放进这组命名空间里。

说直接一点：沙箱里的进程看到的 PID 列表、网络接口、文件系统挂载点、主机名和宿主机看到的完全不一样。它可能以为自己是 PID 1，实际上在宿主机上只是某个进程的子进程；它以为自己在监听 8000 端口，但那个端口只存在于它自己的网络命名空间里，外面根本访问不到。

这里有一个很容易被忽略的配置点：是否启用 user namespace 映射。如果不做 UID/GID 重映射，沙箱内的 root 用户实际上就是宿主机上的普通用户，权限还是受限的；但如果做映射，需要额外处理挂载、设备文件等细节，配置复杂度会上来。我的建议是生产环境一定启用 UID 重映射，开发环境可以简化。

进程隔离的实操配置大致长这样：

sandbox: process: isolators: - type: namespace mounts: private pid: true net: true ipc: true uts: true - type: user_namespace uid_map: "0:1000000:65536" gid_map: "0:1000000:65536"

这段配置的意思是：每个沙箱实例拥有独立的挂载、PID 列表、网络栈、IPC 和主机名；容器内的 UID 0 映射到宿主机的 UID 1000000 以上，避免权限逃逸。

3.2 syscall 过滤：凡未明确允许的，一律禁止

命名空间解决的是“看得见”的问题，但解决不了“够得着”的问题。就算进程看不到宿主机上的其他进程，它依然可以调用一些完整的系统调用去访问内核资源。这时候需要 seccomp（Secure Computing Mode）做系统调用过滤。

DeepSeek Harness 默认对沙箱内进程应用一套 seccomp profile，里面只放行 Agent 正常运行所需的系统调用子集。比如openat、read、write、execve、mmap、brk这些基础调用放行，而mount、reboot、ptrace、kexec_load这类高风险调用直接拦截。

实际填配置时，大多数人不需要手写 seccomp profile，因为 Harness 内置了几套基准模板：default、strict、runtime。default适合大多数 Python/Node.js 脚本型的 Agent；strict适合纯文本处理或不依赖外部扩展的轻量 Agent；runtime适合需要跑动态代码编译（比如临时编译 C 代码）的场景，放行的调用会多一些。选择方法上我倾向于先选strict跑一遍测试集，报错再往runtime放宽，而不是一上来就放宽。

seccomp 是一把双刃剑，配置过严会让 Agent 在运行中莫名其妙出错，比如某些数据库驱动会调用不在白名单里的 syscall，导致连接中断。所以 Harness 也提供了审计模式（audit mode），在这个模式下 seccomp 不拦截，只记录每次调用是否越界。正式上生产前，我会在审计模式下跑一周业务流量，把所有告警记录收集起来，再决定哪些 syscall 需要放行。

3.3 文件系统隔离：只读根目录 + 临时可写区

文件系统隔离的模板化配置是 Harness 里日常改动最频繁的部分。每个沙箱实例启动时，会构建一个 overlay 文件系统：底层是一个只读的镜像目录，里面预置了 Python 解释器、必要的依赖和 Agent 代码；上层是一个临时的可写层，Agent 运行期间产生的所有写入都落在这一层。

这个设计有两点好处：第一，Agent 无论如何都改不了底层镜像里的文件，哪怕它拿到了任意写权限，破坏范围也仅限于临时层；第二，沙箱销毁时，可写层直接删除，不会污染宿主机文件系统。如果你的场景要求 Agent 必须持久化输出文件，需要显式地把某个宿主机目录挂载进沙箱，并且建议选只读挂载或指定文件名的可写挂载。

挂载配置示例：

sandbox: filesystem: root: "harness://images/agent-base:v1" writable: "harness://tmp/{{session_id}}" mounts: - host: "/opt/data/input" guest: "/work/input" mode: ro - host: "/opt/data/output" guest: "/work/output" mode: rw path_pattern: "*.csv"

注意这里的四个关键点：

• root不能直接指向宿主机根目录，必须是一个预构建的镜像或目录快照。
• writable建议使用会话级临时目录，这样每次会话结束后数据自动清理。
• 挂载宿主机目录时，尽量用ro而非rw。能只读解决的问题就不给写权限，是文件层隔离的第一原则。
• 给rw挂载时，可以配合path_pattern限制可写文件的匹配模式。比如只允许写 .csv 文件，那 Agent 写了 .sh 文件也会被拒绝落盘。

3.4 网络隔离：仅允许白名单域名与协议

网络层隔离是很多人一开始觉得无所谓、出事之后才捶胸顿足的部分。Agent 能访问网络意味着什么？意味着它可以把读到的数据发出去。如果它的出口没有被管控，那么它的行为边界完全取决于它自己——这在安全上不可接受。

DeepSeek Harness 的网络模型是：沙箱内没有直接的网络接口，所有出网请求都会经过一个代理网关（默认是内置的 egress proxy）。策略规则定义在这个网关上，例如“允许访问 api.github.com 的 443 端口”“允许访问 pypi.org 的 80/443 端口”“其余一律拒绝”。

实践中的网络策略通常分成两组常见规则：一组是基础包管理域名（比如 pypi.org、registry.npmjs.org），Agent 运行时要拉依赖；另一组是 Agent 业务实际要调用的外部 API。前者可以直接用 Harness 预置的软件源规则，后者需要按业务域名和白名单端口逐条添加。

一条网络规则包三个要素：目标域名、协议与端口、动作。域名支持通配符和子域前缀，但不支持后缀通配。换句话说，你可以写*.example.com，但你不能写example.*——这是刻意为之，防止规则过宽导致无法收敛。

网络策略示例：

sandbox: network: egress: enabled: true rules: - domain: "*.pypl.org" port: [80, 443] protocol: tcp action: allow - domain: "api.trace.moe" port: [443] protocol: tcp action: allow default: deny

另外，内网地址（RFC 1918 范围、链路本地地址等）默认就是禁的。这条不用配置，Harness 在代理层做了硬编码排除。网上有些文章会说“沙箱内可以访问宿主机 127.0.0.1 上的数据库”，这种情况出现在网络层没绑代理、直接共享宿主机网络栈的错误配置下。正确设置下，沙箱内访问 127.0.0.1 只会指向沙箱自己的回环地址，并且也没人监听它。

3.5 资源配额与超时：防止 Agent 把事故变成故障

资源配额更像是一种保险措施。大模型驱动的代码执行有一个显著特点：它的执行路径不是预设的，而是由模型每一步生成的。这意味着一个逻辑上没问题的任务，可能因为某一步模型决策跑偏，进入一个资源消耗爆炸的分支。

我遇到过的一个典型案例：Agent 在处理一批图片时，为了循环生成文件名，使用了while True的拼接逻辑，结果循环条件在特定输入下永远不会满足，直接把单核 CPU 跑满接近十分钟，直到外层超时被杀掉。如果没有 CPU 配额，这个失控任务会把宿主机上其他正常服务的响应拖垮。

DeepSeek Harness 的资源配额配置支持内存、CPU、磁盘、进程数和绝对超时时间：

sandbox: resources: memory: 1Gi cpu: 0.5 disk: 512Mi processes: 128 timeout: 120s

实践中最常被问到的两个参数需要单独说：

timeout 怎么定。太短会导致正常的重活跑不完，太长又起不到保护作用。我一般会先开一个月的业务采样，统计所有正常任务的执行耗时 P95 值，然后把 timeout 设为 P95 的 2 倍。这样做既给了长尾任务足够的余量，又能拦掉绝大多数失控执行。

memory 给多大。这取决于你的 Agent 是纯 Python 逻辑还是跑着本地模型推理。纯逻辑脚本给 512Mi 到 1Gi 足够了；如果要加载本地模型，就得根据模型大小和中间特征的最大内存占用往上加。有一个建议是：不要按“模型大小 + 推理库开销”来估算，而是直接压测一个最大输入的推理请求，观察峰值内存再加 20% 余量。

4. 实操部署：从零搭建一个带沙箱的 Agent 服务

4.1 部署模式选择

DeepSeek Harness 支持两种部署形态：桌面版和服务器版。桌面版适合本地开发调试，因为安装简单，图形界面能直接看到每个沙箱实例的状态和日志；服务器版适合生产环境，核心组件包括一个主控服务（harness-controller）、一个沙箱运行时守护进程（harness-runtime）和一个策略引擎（harness-policy）。

我推荐的生产架构是“一主多沙箱”模式：独立的 Controller 节点负责接收 Agent 任务的调度请求，多个 Runtime 节点负责实际拉起沙箱实例。Controller 和 Runtime 之间通过内部 gRPC 通信，所有策略配置集中在 Controller 端的 policy store 里，Runtime 每次启动沙箱前从 Controller 同步策略。

这种架构的优势在于策略可审计。Agent 任务在哪个沙箱里跑、用了哪个策略版本、哪个时间点启动的，全部有记录。出问题时，先把审计日志拉出来，定位是哪一层被突破了，再针对性加固，而不是像以前那样对着宿主机看半天不知道发生了什么。

4.2 安装主控与运行时

桌面版安装这里不展开，下载对应安装包按向导走完即可。服务器版的安装流程我列一下关键步骤。

假设你在两台 Linux 服务器上操作，一台做 Controller（IP 10.0.1.10），一台做 Runtime（IP 10.0.1.20）。

在 Controller 上先装主控：

curl -fsSL https://get.harness.example.com/install.sh | sh harnessctl --mode=controller harnessctl config set --listen=0.0.0.0:9650 harnessctl storage init --driver=sqlite --path=/var/lib/harness/controller.db harnessctl service start controller

在 Runtime 上安装运行时：

curl -fsSL https://get.harness.example.com/install.sh | sh harnessctl --mode=runtime harnessctl config set --controller-addr=10.0.1.10:9650 harnessctl service start runtime

然后回到 Controller 注册 Runtime 节点：

harnessctl node add --name=node01 --addr=10.0.1.20 harnessctl node approve --name=node01

这个流程里容易忽略的一步是 Runtime 节点注册后必须手动 approve，否则 Controller 不会给它下发任务。我第一次部署时卡在“任务一直 pending”，查了半天才发现 Runtime 节点状态还停在 waiting approval。

要在 Windows 上做本地开发调试的话，安装桌面版后需要启用 Hyper-V 虚拟化支持或 WSL2 内核，因为沙箱运行时底层需要运行轻量虚拟机或容器运行时。安装时如果提示硬件虚拟化未开启，需要去 BIOS 里打开 VT-x/AMD-V，这个步骤没法通过软件绕过。

4.3 配置第一份沙箱策略

安装完成后，先做一份最小化的策略文件，再逐步放行。以“让 Agent 读取本地 CSV 文件，调用外部天气 API，并把结果写入指定目录”为例，一份完整的策略文件长这样：

apiVersion: sandbox.harness.io/v1 kind: SandboxPolicy metadata: name:>harnessctl policy apply -f>