sandboxed.sh
自托管的自主 AI 代理任务执行后端：隔离的 Linux 工作区、Git 版本化的技能库和 MCP 驱动的任务编排。
- 源仓库
- Th0rgal/orb
- Star 数
- ★ 534
- 最近更新
- 今天
- 主语言
- Rust
- FA 评分
- 52/100 · 缺口较多
30 秒速览
- 运行形态
- 可在哪里用
- 通用 · 跨平台Codex · Claude Code
- 费用
- 软件免费，模型调用费用自付
- 上手难度
- 中 · 需要几步配置
- 开始前需要
- 典型场景
- 将整个开发周期交给代理：指向 GitHub issue，编写代码，测试，并在测试通过时打开 PR。
- 不适合
- 需要开箱即用、无需协调器的用户：sandboxed.sh 只是两半系统中的执行端
- 只使用 Ubuntu 24.04 以外系统做原生部署的团队
- 不愿授予容器特权（privileged: true）或运行未稳定版本的用户
- 源码审查
- 52/100 · 缺口较多
这个 Agent 能做什么，适合哪些场景？
sandboxed.sh（前身为 Open Agent）是一个自托管的自主 AI 代理任务执行后端，在隔离的 Linux 工作区（systemd-nspawn 或 Docker 容器）中运行编码代理。它与协调器（如 Hermes 分支 hermes-agent）配合使用，后者通过 MCP 决定运行哪些任务；sandboxed.sh 则负责执行。它支持 Claude Code、OpenCode、Codex、Gemini 和 Grok 运行时，管理项目、控制器定时任务和具有结构化状态的 MCP 工具任务。一个 Next.js Web 控制面板和 SwiftUI iOS 应用提供实时监控、基于 Git 的库（技能、工具、规则、代理、MCP）以及类 cron 的自动化。部署方式为 Docker（约 5 分钟）或 Ubuntu 24.04 上的原生（约 30 分钟）。项目处于活跃开发中，采用 MIT 许可证。
通过 MCP 接收来自协调器（例如 hermes-agent）的 start_mission 和 list_projects 等任务，在 systemd-nspawn 或 Docker 的隔离工作区中启动代理运行时（Claude Code、OpenCode、Codex、Gemini、Grok），流式传输结果，并通过结构化的 MCP 工具（update_project_status、set_project_grant、link_mission_to_project）维护 projects.db 中的项目记录。支持带健康检查的提供商回退链模型路由、OpenAI 兼容的代理队列模式以及原生推理协议（Chat Completions、Responses、Anthropic Messages）。
- 将整个开发周期交给代理：指向 GitHub issue，编写代码，测试，并在测试通过时打开 PR。
- 运行多天无人值守操作：在隔离沙箱中设置模型微调。
- 保持敏感数据本地：在隔离容器中进行本地推理，不将数据发送到外部服务。
- 通过调度控制器管理具有结构化自治授权的多个长期项目。
- 通过控制面板的实时流和系统指标远程监控任务。
如何安装或部署这个 Agent？
Docker（推荐）：git clone https://github.com/Th0rgal/sandboxed.sh.git && cd sandboxed.sh && cp .env.example .env（编辑设置）&& docker compose up -d，然后打开 http://localhost:3000。若要实现容器工作区隔离，请在 docker-compose.yml 中取消注释 privileged: true。原生（Ubuntu 24.04）：遵循文档指南；需要 git pull + cargo build。
如何使用这个 Agent？
安装后，遵循入门指南配置后端连接、设置库仓库，并创建您的第一个任务。将 MCP 兼容的协调器（如 hermes-agent 或任何 MCP 助手）连接到任务的 MCP 工具。使用 Web 控制面板或 iOS 应用启动、停止和监控任务；在 Git 支持的库中管理技能和 MCP 服务器。
这个 Agent 有哪些优点和局限？
- 通过 systemd-nspawn/Docker 实现真实的容器隔离，确保代理操作被限制范围。
- 多运行时支持：在相同基础设施上运行 Claude Code、OpenCode、Codex、Gemini 和 Grok。
- MCP 原生：任何 MCP 兼容的助手都可以充当协调器；Hermes 是参考实现。
- 基于 Git 的库，用于对技能、工具、规则和代理进行版本控制。
- 结构化项目状态（授权、跟踪、决策），而非自由格式的文本。
- 需要协调器（MCP 客户端）才能有用；sandboxed.sh 是两部分系统的一半。
- 原生安装仅支持 Ubuntu 24.04；Docker 路径需要 privileged: true 才能进行容器隔离。
- 项目处于活跃开发中（进行中），可能存在不稳定性。
- 编排架构（控制平面、任务、控制器）增加了学习成本。
- 许可证仅列为 MIT；未提供其他合规性保证。
这个 Agent 与同类方案有什么区别？
源将 Hermes（hermes-agent）作为参考协调器，但明确指出任何 MCP 兼容的助手都可以担任该角色。
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | 形态 / 费用 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|---|
| sandboxed.sh 当前 | 52 · 缺口较多 | 自托管服务免费 + 模型费 | ★ 534 | 今天 | Rust | Codex · Claude Code |
| Cezar — AI 编码代理编排器 | 63 · 存在缺口 | 命令行工具免费 | ★ 796 | 1 天前 | TypeScript | Codex · Claude Code |
| Vicoa | 52 · 缺口较多 | 桌面应用免费 + 模型费 | ★ 519 | 12 天前 | Python | Codex · Claude Code |
| Solo Agent | 48 · 缺口较多 | 自托管服务免费 + 模型费 | ★ 594 | 1 个月前 | Go | Codex · Claude Code |
FollowAgents 如何评估这个 Agent？
查看各维度的扣分理由
最小权限：README 建议 Docker 下启用 privileged: true，原生模式用 systemd-nspawn，容器隔离有一定设计但 privileged 容器实质上放弃了隔离，扣分严重。用户确认：自治 mission 可开 PR、SSH 到家用 GPU、无人值守多天运行，未见到强制人工确认点。数据流透明：架构图与 docs/AGENT_CONTROL_PLANE.md 把项目/任务/回执/证据结构描述得较清楚，给 2。敏感数据：Cargo.toml 显示 AES-GCM/PBKDF2 加密密钥，README 强调本地推理与隔离，但加密实现本身未在样本中可见，给 2。依赖安全：Cargo.toml 版本声明常规，无锁定策略或审计说明，1 分偏上给 2 不够——未见 cargo audit/deny，扣为 2。外部影响：mission 可写代码开 PR、SSH 远程主机，影响面大但文档有 grant（merge authority、budget）概念，部分缓解。回滚：仅提到 zip 备份/恢复依赖，无明确回滚流程。来源归属：作者为 'sandboxed.sh Contributors'，未验证发行方，引用上游 hermes-agent 有 FORK.md 说明，给 1。
自洽性：README 与 Cargo.toml 描述一致（版本 1.3.0、多个 MCP 二进制、Hermes 协同），无内部矛盾。依赖可用性：核心依赖 tokio/axum 均为主流维护版本，但 rust-version 1.91 与 Cargo.toml 中注释提到的 MSRV 1.75 存在张力，扣分。失败信息：测试文件显示测试大量使用 waitForTimeout 和宽泛的 catch 忽略，错误路径覆盖薄弱，样本中未见结构化错误文档。
受众与场景：README 明确面向自托管开发自动化（交接开发周期、GPU 训练、本地数据分析），场景描述具体。能力边界：明确区分 coordinator 与 sandbox 职责、in-conversation 子代理与 mission 的分工规则，边界陈述清晰。触发精度：controller cron 触发机制只有概念性描述，样本中无配置示例，给 1。环境适配：Docker 与 Ubuntu 24.04 原生双路径，Xvfb/X11 桌面自动化说明，环境覆盖良好。
信息架构：README 组织优秀，文档索引覆盖安装/架构/API/调试，导航清晰，给 3。安装说明：双安装指南+首次设置指南存在，但 Docker 默认非 privileged 与'建议取消注释 privileged'的顺序安排令人担忧。命名稳定性：项目'formerly known as Open Agent'更名，历史名称仍在代码/文档中可能残留，给 1。示例与 FAQ：无 FAQ，示例主要为安装命令，缺实际使用示例。已知局限：明确标注 'Work in Progress'。许可证：README 声明 MIT，但无 LICENSE 文件出现在样本中，且元数据'unknown'，给 2。版本与变更日志：Cargo.toml 有版本号 1.3.0，但未见 CHANGELOG，发布依赖 GitHub 自动生成 notes。维护责任：'active development, contributions welcome'，无具体维护者承诺或更新路径，给 1。
输出可用性：结构化回执/证据/SSE 流式结果的设计表明输出被认真考虑，多端（web/desktop/iOS）呈现一致 roster。边际价值：将多运行时 agent 沙箱化编排+项目控制面组合是真实差异化，但生态依赖自家 Hermes fork，扣分。成本收益：部署成本（privileged Docker、Ubuntu 24.04、自托管）与自治收益之间的权衡未量化，~5/30 分钟的设置时间估计是唯一数据点，给 1。
主张可追溯性：README 的许多主张（mission 隔离、加密、健康检查路由）引用了文档文件但样本中无法核实这些文档的实际内容，给 1。跨源印证：CI workflow、测试文件与 README 描述的 dashboard 功能部分印证，但核心安全主张（隔离、加密）在提供的文件中无法交叉验证。事实与推断分离：README 将 'Work in Progress' 与功能列表区分较清楚，愿景部分以'What if'明示为愿景，给 2。
- Docker 部署默认建议启用 privileged: true，这会基本消除容器隔离；在自治 agent 环境下这是高风险配置，部署前必须评估替代方案（如 rootless 容器或原生 systemd-nspawn）。
- 自治 mission 可执行开 PR、SSH 远程主机等外部动作，样本中未见强制人工确认门槛；使用 autonomy grant/budget 前应核实其实际实现与默认值。
- 许可证仅在 README 中声明 MIT，样本中未见 LICENSE 文件，法律层面应自行确认。
- 未发现 CHANGELOG 与明确的维护者承诺；项目自我标注为 Work in Progress，API 与行为可能频繁变动。
- 静态审查置信度低：隔离与加密等安全主张均来自文档描述，未经执行验证。
最近版本
来自该项目 GitHub Releases 的最新发布记录，说明为上游原文摘录，未经本站改写或测试。
-
v0.12.0 v0.12.0 — Grok Build, Needs You, iOS UX
发布说明摘录
v0.12.0 — Grok Build, Needs You, transcript streaming, iOS UX Grok Build — first-class backend - Full xAI OAuth flow (device-auth), ~/.grok/auth.json mirrored per mission workspace, container-aware --cwd translation, grok-build default model exposed via /api/providers. - /goal <objective> for Grok. Grok ships no native goal mode, so sandboxed.sh drives the loop: a sentinel protocol (<goal_complete/> / <goal_continue/> / <goal_aborted reason="…"/>) is injected into the first-turn prompt, then an AgentFinished automation re-fires a short continuation prompt every tu …在 GitHub 查看 ↗ -
v0.11.5 v0.11.5 - Native Harness Loops & iOS Network Resilience
发布说明摘录
Bundles PR #432 — clean reimplementation of the still-unique work from the abandoned #430 (Codex goal mode + iOS network resilience WIP). Features Native harness loops as Automation rows Claudecode and codex /goal continuation loops now materialize as first-class rows in the Automations panel, with iteration badges and a per-row stop button — alongside OA-scheduled automations. - New NativeLoopAdapter trait + registry in src/backend/native_loops.rs …在 GitHub 查看 ↗ -
v0.11.1 v0.11.1 - Mission Workbench BugBot Fixes
发布说明摘录
v0.11.1 highlights Patch release for the Mission Workbench and Needs You inbox rollout. Changes - Aligns Mission Workbench running-state rendering with the header's effective running-state logic instead of treating any RunningMissionInfo object as running. - Keeps running missions indigo in the workbench, while stale/finished running records fall back to the stored mission status. - Preserves the Needs You inbox total-count fix from v0.11.0 and the workbench running-color fix from PR #404. - Bumps backend and dashboard package versions to 0.11.1. Verification …在 GitHub 查看 ↗