senv 评测 2026：给 Python 运行套上沙箱，别让一个坏依赖读走你的 SSH 密钥

虚拟环境隔离的是「依赖」，不是「代码」。这句话就是 senv 存在的全部理由。当你 pip install 或 uv add 一个包的时候，它的构建脚本是在你的机器上、用你的权限跑的——它能读 ~/.ssh、能抓环境变量、能往外发请求。等到你的项目真正运行起来，一个被污染的依赖还可能改写环境，把自己留到下一次运行。venv 和 uv 本质是 PATH 约定，不是安全边界。senv 是 h5i-dev 团队用 Rust 写的小工具，它把你本来就在用的 uv 工作流底下，焊了一道真正的操作系统级沙箱。

它最吸引人的地方在于「几乎不向你伸手要东西」。一个 senv 项目，依然是 uv 项目：还是那份 pyproject.toml、还是那个 uv.lock。从没装过 senv 的同事，照常用 uv 就行。但你每次通过 senv 去装、去跑，都会被包进一套策略里——它把两个最危险的时刻分开对待：装依赖（构建代码能碰到你的机器）和跑代码（装好的包能干什么）。结局就是那种「大家都知道该有、却懒得配」的边界，被它顺手补上了。

senv 到底做什么

核心上，senv 保留了你熟悉的 uv 命令界面，在底下加了一层默认拒绝的沙箱。uv sync 变成 senv sync，uv run pytest 变成 senv run pytest，参数原样透传给 uv，退出码和 CI 行为都不变。底层是两个阶段各有一套策略。

装依赖时，构建代码只能访问你指定的包源（PyPI 和额外配置的索引），碰不到你的源码，也碰不到你的凭据。跑代码时，你的项目目录可写，但装好的环境是只读的，网络默认断掉——除非你显式放行。受管环境放在项目之外，包没法悄悄改 .venv 让自己留到下次。senv 甚至在安装时就编译好字节码、运行时禁止可写字节码缓存，顺手堵上了「留个被改过的 .pyc」那招。

它把自己做得很窄：不是容器、不是新的包管理器、也不是自己的运行时。就是一个二进制，让你本来就在敲的 uv 命令，从「无条件信任每一行构建和运行代码」变成「默认先拒」。

适合谁用

• 跑 AI 智能体生成的 Python：如果你让 Claude Code、Codex 这类智能体在本机上搭代码、跑代码，senv 能框住那段生成代码——以及它拉来的依赖——真正能碰到的东西。
• 试用不信任的第三方包：想试一个你没读过构建脚本的库？senv sync 让那段构建代码够不到你的凭据和源码。
• CI 和共享 runner：senv run pytest 带着「失败即收紧」的默认策略直接进流水线，毒化的测试依赖就偷不到 runner 上的密钥。
• 在意供应链安全的本地开发：已经在用 uv lock 和漏洞扫描的团队，可以在原有实践之上叠一层运行期隔离，而不是替换掉它们。

关键特性

保留 uv 工作流

命令和 uv 一一对应，参数和退出码都透传，所以上手只是把肌肉记忆换一下：source .venv/bin/activate 变成 senv shell，uv run 变成 senv run。

两阶段隔离

安装阶段只放行包源网络；运行阶段默认断网、环境只读、密钥只给显式声明过的。这个拆分，是因为「构建时」和「运行时」承担的风险本来就不一样。

显式、按阶段划分的密钥

密钥在 senv.toml 里声明（env: / file: / command: 三种来源），并按阶段限定作用范围。它们绝不会暴露给安装期的构建代码；而 command: 来源因为要在宿主机上执行命令，必须额外显式开启。

策略信任模型

因为 senv.toml 就躺在项目里，一个被污染的依赖可能想把它改宽。senv 把「上一次你接受的策略快照」存在沙箱之外；一旦磁盘上的策略比快照更宽，就直接拒绝，直到你检查并用 senv trust 确认。

可审计的拒绝

senv status 告诉你当前在执行什么；被拦下的操作会打印「最小放行命令」（senv allow api.stripe.com）；senv report --suggest 只给出建议策略，绝不擅自改动。

价格

senv 完全免费，采用 Apache-2.0 开源协议。没有付费档、不需要账号、没有 SaaS 成分——纯本地优先。安装方式很多：官方脚本、uv tool install h5i-senv、pipx install h5i-senv，或 cargo install。唯一硬依赖是 PATH 上要有 uv；Linux 还需 slirp4netns 和 nftables，Windows 仅支持 WSL2。

常见问题

senv 是 Docker 的替代品吗？ 不是。Docker 隔离更强更重，而且是另一套工作流。senv 走的是轻量路线：你只是想让原本的 uv 项目别再无条件信任每一行构建和运行代码，又不想起容器。

我现有的 uv 项目会坏吗？ 不会。senv init 保留 pyproject.toml 和 uv.lock 原样；没装 senv 的同事照常 uv。它建的是一套独立的受管环境，不会覆盖你的 .venv。

会让运行变慢吗？ 开销来自沙箱本身，不是什么转换层——命令都透传给 uv。大多数本地和 CI 场景几乎无感；真正「代价」是偶尔需要 senv trust 确认一下策略放宽。

结论

senv 补的是一个真实缺口：虚拟环境隔离依赖却不隔离代码，于是恶意或粗心的包能在安装和运行时读走你的凭据、把自己留下来。senv 在保留团队已有 uv 工作流的前提下，加了一道默认拒绝的操作系统级边界，对「跑智能体生成的代码」「用不信任依赖」的人确实有用。它的信任模型和密钥处理都想得周到，Apache-2.0 加上单个 Rust 二进制也让试错成本很低。

要提醒的是成熟度和适用面。它还是 v0.1.0，社区不大（评测时约 43 星），推送也安静了一个月，CLI 按 pre-1.0 看待。而且它本质是 Python 安全工具，不是「AI 工具」——和 AI 的关联是间接的：让智能体写的代码能安全跑起来。对 9bests 的读者，它值一个扎实的 6.5/10：如果你会跑不信任的代码，值得了解；如果只是想装依赖更快，可以跳过。最后纠正一条：这个仓库在我们内部跟踪库里曾被误记成「多智能体编排 SDK」，那是错误的——它是沙箱环境工具，本文按真实产品评测。