沙箱

在一众编码智能体里，OpenHands（前身 OpenDevin，All Hands AI 出品）是绕不开的开源坐标：第三方架构综述给它标了约 7 万星，SWE-bench Verified 上报告 77.6% 的解决率，还自带一套被学术界广泛当作实验基线的 SDK。2026 年它不仅是「一个能改代码的 Agent」，更成了开源编码智能体的参考架构。值得从代码结构而不是榜单数字读一遍。 四层模块化 SDK 按其 SDK 论文（arXiv 2511.03690），工程被拆成四个包： openhands.sdk：核心抽象——Agent、Conversation、LLM、Tool、MCP，以及事件系统。 openhands.tools：具体工具实现，如 str_replace_editor 编辑文件、execute_bash 执行命令。 openhands.workspace：执行环境，默认 Docker 沙箱，可换成托管 API。 openhands.agent_server：暴露 REST/WebSocket 的 Web 服务。 这种分层的好处是：换模型、换工具、换沙箱，都不用动主循环。学术界做新方法实验时，正是靠这种可插拔性快速复现。 为什么沙箱是一等公民 OpenHands 的所有文件编辑与命令执行都在 Docker 容器里跑，这不是洁癖，是编码智能体的安全底线——Agent 要执行 shell，就必须默认它会执行危险命令。Docker 沙箱 + 可回放的事件流，让每一步「想了什么、改了什么、跑了什么」都能记录复盘。 模型侧的配合 OpenHands 还开源了 OpenHands LM 32B：在 SWE-bench Verified 上 37.2%，与 20 倍体量的 DeepSeek V3 0324（671B，38.8%）接近。这说明编码智能体的能力，框架脚手架的贡献不亚于模型本身——换个小模型，配好工具与循环，就能追到一线大厂模型的尾巴。 判断 想自建编码智能体，OpenHands 是最好的起点：它把事件循环、工具抽象、沙箱这些脏活做完了，你专注在自己的仓库上下文与评测上即可。 落地时建议先从一个真实仓库的小任务集跑起，而不是直接接生产代码库。先观察它在你自己的代码风格与构建命令下，编辑文件与跑测试的成功率有多高，再决定要不要扩大权限。开源框架给的是脚手架，仓库特定的知识仍要靠你自己喂。 和闭源编码助手相比，OpenHands 最大的优势是可控与可复现：你可以审计每一步工具调用、替换任意模型后端、把整套流程沉淀成自己的 CI 流水线。代价是要自己维护环境与评测。适合有工程团队、想把编码智能体深度定制进研发流程的组织。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：OpenHands 架构 ...

10 月 7 日更新的 Gemini API 版本说明显示，谷歌推出了 Managed Agents（托管智能体）公开预览：开发者可以借此构建并部署自主的有状态智能体，它们运行在一个由谷歌托管、安全隔离的 Linux 沙箱环境里。与此同时，Antigravity 智能体也转为正式可用。按官方文档的说法，只需一个请求，Gemini 就能在这个托管工作区里自己写代码、运行代码、搜索网络并创建文件。 它替开发者省掉了什么 做一个能真正「动手」的智能体，最烦的不是调模型，而是配套基建：你得给它一台干净的虚拟机、一个浏览器、一套文件系统，还要隔离依赖、处理超时和清理。过去这些要么自己用容器编排，要么买第三方服务。 Managed Agents 把这层全包了：有状态意味着智能体记得上下文、跨步骤保持工作区；托管意味着谷歌负责那台 Linux 沙箱的供给与回收。开发者的精力可以回到任务本身，而不是运维沙箱。 这是平台之争的下半场 把时间线拉长看：OpenAI 的 Agents API 接了 Computer Use，让开发者直接复用它的电脑操作能力，并和 AWS 推 Bedrock 托管智能体；谷歌这边则在 API 侧把沙箱托管做进自家底座。两家拼的都是同一件事——谁的 Agent 基建更省事，开发者就把工作流建在谁的云上。 这也解释了为什么谷歌企业版同时上架 Claude、Grok、Mistral 等第三方模型，并开放 Llama、DeepSeek、Qwen 等开源权重：它要做的是「跑任何模型的托管平台」，而不只是卖 Gemini。 Antigravity 智能体同步转为正式可用，说明谷歌对这条托管路线已经过了试水阶段。 判断 Agent 基建的成熟度，正在决定这波创业的存活率。沙箱、状态、工具调用这些「脏活」被云厂商接管后，独立开发者能以更低成本做出可用产品，但代价是更深地绑定某一家云。对团队，选哪家托管智能体，基本等于选了未来几年的技术栈。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：Gemini托管智能体

AI Agent 的安全困境 AI Agent 拥有执行 Shell 命令、读写文件、调用 API 的能力，这让它极其强大，也极其危险。一个不受控的 Agent 可能删除重要文件、泄露敏感数据、甚至被注入攻击利用。 Hermes Agent 构建了五层安全防线，从内到外形成纵深防御： ┌─────────────────────────────────────────────────────┐ │ 第五层：供应链安全 │ │ 技能市场审核、依赖校验、签名验证 │ ├─────────────────────────────────────────────────────┤ │ 第四层：行为审计 │ │ 操作日志、异常检测、告警通知 │ ├─────────────────────────────────────────────────────┤ │ 第三层：容器隔离 │ │ Docker 沙箱、资源限制、网络策略 │ ├─────────────────────────────────────────────────────┤ │ 第二层：危险命令审批 │ │ 命令分类、风险评分、人工确认 │ ├─────────────────────────────────────────────────────┤ │ 第一层：用户授权 │ │ 身份认证、权限分级、操作范围限制 │ └─────────────────────────────────────────────────────┘ 第一层：用户授权 身份认证 # config.yaml - 认证配置 auth: mode: token # token | oauth | multi # Token 认证 tokens: - token: "hermes-xxxx" user: "alice" role: admin # admin | user | readonly # 多用户支持 users: alice: role: admin allowed_tools: ["*"] allowed_paths: ["/"] bob: role: user allowed_tools: ["shell", "file_read", "file_write"] allowed_paths: ["/home/bob", "/tmp"] guest: role: readonly allowed_tools: ["file_read"] allowed_paths: ["/public"] 权限分级 角色 可用工具 文件访问 危险命令 管理操作 admin 全部 全部 需确认 允许 user Shell/文件/API 用户目录 需确认 禁止 readonly 只读工具 指定目录 禁止 禁止 class AuthManager: """用户授权管理""" def check_permission(self, user, action, resource): role = self.get_role(user) # 检查工具权限 if action.tool not in role.allowed_tools: return False, "tool_not_allowed" # 检查路径权限 if not self._check_path(resource.path, role.allowed_paths): return False, "path_not_allowed" # 检查危险操作 if action.is_dangerous and not role.can_dangerous: return False, "dangerous_not_allowed" return True, "ok" 第二层：危险命令审批 命令分类系统 Hermes 将所有可执行命令分为四个风险等级： ...