Runeward 场景：AI 编码 Agent 不再裸奔——governed execution cell 让每个操作都有安全围栏
你有没有遇到过这种情况：你让 Claude Code 帮你写个脚本，它先 curl 下载了一个包，然后 rm -rf 了临时目录——但万一它 rm -rf 错了目录呢？或者更糟，AI Agent 在不知情的情况下把 .env 文件里的 API Key 发送到了外网？
这不是危言耸听。Runeward 的作者在 README 中说得直白：“Letting an AI agent run shell commands, edit files, install packages, and hit the network is useful right up until it rm -rfs the wrong directory, exfiltrates a secret, or burns your API budget in a retry loop.” 传统的方案是”把 Agent 关进盒子（sandbox）”，但 Runeward 更进一步——在隔离层外面加了一层治理层（governance layer），就像一个安全带加飞行记录仪。
痛点对比：传统 Sandbox vs Runeward
| 维度 | 传统 Agent Sandbox | Runeward |
|---|---|---|
| 隔离（容器/VM） | ✅ 有 | ✅ 有（Docker 或 Kubernetes） |
| 默认拒绝网络出站 | ⚠️ 部分支持 | ✅ SNI 白名单 + 严格 L3 策略 |
| 每操作策略 + 审批 | ⚠️ 很少见 | ✅ 内置 CEL / OPA-Rego + 人工审批门 |
| 防篡改审计跟踪 | ⚠️ 很少见 | ✅ 哈希链 + ed25519 签名，可验证 |
| 成本/循环保护 | ⚠️ 很少见 | ✅ 硬限制：时间、执行次数、出站请求、Token/消费 |
| 多 Agent 集群 | ⚠️ 很少见 | ✅ N 个 cell + 原子任务板 |
| 认证 + 多用户 | ⚠️ 很少见 | ✅ Bearer Token + RBAC + 每用户视图 |
| Agent 原生接口 | ✅ 部分 | ✅ REST + MCP + CLI + Dashboard + Adapters |
Runeward 的核心思路是：不要依赖训练或提示来让模型表现良好——在模型外部强制执行规则，用默认拒绝的契约来约束 Agent，让它无法绕过。
快速上手：一分钟跑起来
Runeward 的安装非常简单，一行命令即可：
curl -fsSL https://raw.githubusercontent.com/Runewardd/runeward/main/install.sh | sh
如果你用 macOS 且装了 Homebrew（待 tap 发布后）：
brew install Runewardd/tap/runeward
或者从源码构建：
git clone https://github.com/Runewardd/runeward.git cd runeward go build -o bin/runeward ./cmd/runeward
安装后，先看看有哪些 profile 可用：
./bin/runeward --config-dir examples list ./bin/runeward --config-dir examples dev ./bin/runeward --config-dir examples dev -- uname -a ./bin/runeward --config-dir examples serve
然后打开 http://localhost:8080 查看 dashboard——你可以选择一个 profile，点击 New 创建 sandbox，然后通过终端、文件浏览器、审计时间线和审批收件箱来操控它。
核心功能：governed execution cell 的能力
1. Profile 即安全契约
Runeward 的核心概念是 Profile——一个声明式的配置文件，定义了 Agent 能做什么、不能做什么。Profile 可以用 TOML、YAML 或 JSON 编写，放在项目目录的 .runeward/ 下或 ~/.config/runeward/ 中。
一个典型的 profile 长这样：
[host]
type = "container"
image = "runeward-agent:dev"
workdir = "/workspace"
copy_from = "~/Documents/my-project"
[network]
egress = "deny" # 默认拒绝出站
[[env]]
name = "OPENAI_API_KEY"
secret = "op://vault/api-key" # 1Password 引用，不留痕
[[policy]]
engine = "cel"
rule = "resource.type != 'shell' || !resource.cmd.startsWith('rm -rf /')"
这个 profile 声明了：
- 使用 Docker 容器运行
- 从本地项目复制文件到 sandbox（不是挂载——Agent 永远接触不到原始文件）
- 默认拒绝所有网络出站
- 用 1Password 注入 API Key，审计日志中自动隐藏密钥值
- 策略：禁止
rm -rf /类破坏性命令
最重要的是：你没声明的东西默认就是拒绝的。你不必列出一张庞大的许可清单——不存在的权限自动就是禁用的。
2. 全程审计，防篡改
每个操作都会经过唯一的审计路径：策略 → 审批门 → 安全护栏 → 后端执行 → 审计账本，无论操作是通过 REST API、Dashboard 还是 MCP 发起的。审计账本是只追加的、哈希链式的、ed25519 签名的，可以作为独立可验证的凭证导出。
这意味着你可以随时回答”Agent 刚才做了什么？”——而 Agent 无法事后篡改这个记录。
runeward audit verify
3. 成本与循环保护
AI Agent 最常见的陷阱之一是 retry loop——Agent 反复重试同一个失败操作，把 API 账单烧掉一大笔。Runeward 提供了硬性的限制：
- 最大运行时长（wall-clock）
- 最大执行次数
- 最大出站请求数
- Token 和费用预算
这些限制在 profile 的 [limits] 中声明，超出后 sandbox 自动终止。你可以根据自己的场景灵活配置。例如，一个代码审查 Agent 可能只需要 5 分钟和 10 次 shell 执行，而一个数据分析 Agent 可能需要更长时间。
4. MCP 原生集成
如果你在用 Claude Desktop、Cursor 或 VS Code，Runeward 可以作为 MCP 服务端直接集成：
runeward mcp runeward mcp --http
通过 MCP 暴露的工具非常丰富，包括沙箱工具（runeward_create_sandbox、runeward_shell、runeward_browser 等）和集群工具（runeward_create_fleet、runeward_list_tasks 等）。当策略拒绝时，MCP 返回工具错误；当需要审批时，Agent 会暂停等待人工确认。
适用场景
Runeward 特别适合以下场景：
- 本地开发：在 Docker 中安全运行 Claude Code、Codex 或 Cursor CLI，防止误删文件或外泄凭据
- CI/CD 管道：用 Kubernetes 后端为每个 PR 创建隔离的 Agent 沙箱，执行代码审查、测试或部署
- 多 Agent 协作：用 Fleet 功能创建多个 sandbox、共享任务板，让多个 Agent 在隔离环境中协同工作
- 安全审计：保留 Agent 操作的完整可验证审计记录，满足合规要求
限制与注意事项
- 后端依赖：默认需要 Docker/OrbStack（本地）或 Kubernetes（生产），无这些运行时无法使用
- 项目较新：截至 2026 年 7 月，Runeward 刚发布不久，Homebrew tap 还在开发中
- 学习曲线：Profile 的配置语法（TOML/YAML/JSON + CEL/Rego 策略）需要一些学习时间
- 性能开销：每个 sandbox 的创建和策略检查有一定性能开销，不适合高频短周期任务
总结
Runeward 给 AI Agent 的安全提供了不同于传统 sandbox 的视角：隔离是基础，治理才是关键。通过声明式的 Profile、默认拒绝的权限模型、防篡改的审计链和成本保护机制，它让”放心让 Agent 干活”变成了可实现的目标。
如果你是 Claude Code、Codex 或 Cursor 的重度用户，或者你正在为团队搭建 Agent 基础设施，Runeward 值得一试。
- GitHub: https://github.com/Runewardd/runeward
- 文档: https://runewardd.github.io/runeward/
- 许可证: Apache-2.0