AI Agent 编程的安全盲区：Capakit 从构建到运行全程沙箱化实战

场景：你用 Claude Code 或 Codex 生成了一段代码，它从 npm 拉了 30 个依赖，在 postinstall 里跑了两个 shell 脚本——而你完全不知道那些脚本做了什么。AI 编程工具的安全困境不在于「能写多少代码」，而在于「写出来的代码背后跑了什么」。

为什么「只沙箱运行」不够？

AI 编码 Agent 的典型工作流是：生成代码 → 安装依赖 → 运行测试 → 部署。绝大多数安全工具只关注最后一步——把运行中的进程放进沙箱，限制其网络和文件系统访问。

但真正危险的动作发生在构建阶段：

• npm install 可以执行任意 postinstall 脚本。一个恶意的依赖包能在你不知情的情况下读取 ~/.ssh/id_rsa 或环境变量里的 API 密钥。
• Agent 生成的 Dockerfile 可能包含敏感信息。如果 Agent 在构建阶段把凭据写入了镜像层，即使运行时被沙箱隔离，这些凭据也已经永久固化在了镜像中。
• 依赖链的供应链攻击。Agent 不会手动审查每个依赖包——它相信 npm 的返回。而 npm 生态中每年都有数千个被篡改的包。

CapaKit（capakit.com）的切入点正是这个盲区：把沙箱从「运行时」前推到「构建时」，让整个 AI 应用生命周期都在隔离环境中完成。

安装：一行命令

CapaKit 目前仅支持 macOS（Apple Developer ID 签名和公证），安装非常简单：

curl -fsSL https://capakit.com/install.sh | sh

或者通过 Homebrew：

brew install capakit/tap/capakit

安装后即可使用 capakit 命令。

核心概念：AI App Kit

CapaKit 引入了一个叫 AI App Kit 的概念——一个自包含的项目格式，描述了一个 AI 应用的全部信息：名称、工作负载、公共路径、依赖、主机挂载点、密钥声明和连接策略。

一个最简单的 Kit 示例如下（来自 CapaKit 官方的 hello-world demo）：

name: hello-world
workloads:
  main:
    type: bun
    source: ./src
    public_paths:
      - path: /mcp
        protocol: mcp

工作负载（Workload）是 Kit 内部的隔离进程——每个 Workload 运行在独立的 macOS seatbelt 沙箱中，互不干扰。

实战场景一：沙箱化运行 GitHub 上的 AI 应用

最常用的命令是 capakit run——它从一个 GitHub 仓库下载 Kit，构建、运行，全程沙箱化：

capakit run https://github.com/capakit/hello-world-demo-kit

输出大致如下：

[ephemeral seatbelt sandboxes on macOS]
  url=http://127.0.0.1:50958/mcp

在这个沙箱中，所有网络流量默认被阻止——只有 capability.yml 中明确声明的出口才被允许。依赖安装（bun install）也在沙箱内执行，postinstall 脚本无法触及宿主机文件。

实战场景二：让 AI Agent 通过沙箱创建应用

CapaKit 内置了 Agent 指令，你可以直接在 Claude Code 或 Codex 中描述你的需求：

> Use capakit to create a new AI app Kit called invoice-helper.
> I want a web UI where I can upload invoice text and see extracted fields:
> vendor, date, total, and line items.
> Please test it and leave clear run instructions.

Agent 会读取 CapaKit 的内置指令和 manifest 模板，在沙箱化环境中生成 Kit 代码、安装依赖、运行测试——每一步都在隔离中完成。你可以在 capakit.com/docs 查看更多模板和生成示例。

实战场景三：导出为 Agent Skill

如果你的 Kit 暴露了 MCP 工具，可以一键安装为 Codex 或 Claude 的 Skill：

capakit run https://github.com/capakit/hello-world-demo-kit --global-skill codex

CapaKit 会自动生成 provider 特定的 Skill 结构：

~/.codex/skills/hello-world/
├── SKILL.md
├── hello-world
└── .hello-world.conf

生成的 Skill 文件是临时的——当 capakit run 退出时自动清理，不会在宿主机留下残留。

安全模型的核心设计

CapaKit 的安全模型有四个关键设计：

声明式挂载是个值得学习的细节。Kit 不能随意访问宿主机目录——必须在 capability.yml 中声明：

host_mounts:
  - path: /Users/me/models
    mount_path: /models
    read_only: true

运行时要显式挂载：

capakit run my-kit --mount models=/path/to/models

测试验证：沙箱内运行集成测试

CapaKit 提供了 capakit test 命令，在沙箱内执行在 capability-test.yml 中定义的测试用例：

capakit test .

测试用例可以验证 workload 是否正常启动、MCP 工具是否响应、依赖是否满足预期。所有测试都在沙箱中运行，不影响宿主机状态。

对于更细致的权限控制，还可以用 capakit exec 在沙箱中执行特定命令：

capakit exec main -- npm audit

这会在 main workload 的沙箱上下文中运行 npm audit，检查依赖安全性而无需在宿主机安装任何东西。

CapaKit vs 其他方案

注意事项

1. 目前仅支持 macOS。Capakit 使用 macOS seatbelt 沙箱 API，Linux 和 Windows 支持尚未提供。
2. Alpha 阶段。部分 workload 类型还在适配中——如 Chromium 驱动的工作负载目前不工作。
3. 不是 Docker 替代品。Capakit 定位在「本地 AI 应用的构建与运行沙箱」，适合开发阶段的快速迭代，生产部署仍需容器化方案。
4. 无中央仓库 Stars。Capakit 没有统一的 GitHub 仓库——Kit 分布在各自的 GitHub 仓库中，以 org capakit 下的 demo-kit 为主。

总结

Capakit 解决的是一个被大多数人忽略但后果严重的问题：AI 编程工具在构建阶段的供应链安全。当 Agent 生成的代码开始拉取依赖、执行脚本时，你其实在信任一个你从未审查过的执行链——从 npm 包作者到 postinstall 脚本到 CI 管道。

Capakit 的做法简单直接：把整个生命周期关进沙箱。不是等到代码运行那一刻才隔离，而是从第一条 npm install 命令开始就隔离。对于每天都在使用 Claude Code、Codex 或 Cursor 的开发者来说，这种「默认安全」的思维方式，比事后修补要可靠得多。

参考：Capakit 官网 | Capakit Docs | HN 讨论