OpenHands 1.0 架构深度解构

背景：从 OpenDevin 实验到 1.0 生产版

OpenHands 的起点是 2024 年的社区实验项目 OpenDevin：把语言模型的推理能力应用到真实软件工程任务——认领并修复 GitHub Issue——而非孤立的代码补全练习。2025 年 11 月，背后的 All Hands AI 完成 Madrona 领投的 1880 万美元 A 轮融资；到 1.0 发布时，项目已积累 85,000+ GitHub Stars、超过 900 万次下载与 500+ 贡献者。2026 年 9 月 8 日发布的 1.0 被官方定位为「研究原型到生产系统」的转折点，此后仓库以极快节奏迭代——截至 9 月 11 日已推进至 v1.18.0，软件智能体 SDK（software-agent-sdk）版本 1.44.0。

值得强调的是版本策略：1.0 的主打特性并非全新能力，而是把既有能力「加固到生产可用」。这对评估开源智能体框架是一个有参考价值的信号——智能体框架的竞争正从「谁的功能多」转向「谁的默认配置敢上生产」。

支柱一：Docker 沙箱与 SecurityAnalyzer

自主编码智能体的本质矛盾是：它必须执行自己写的代码（跑测试、装依赖、起服务）才能验证产出，但在共享主机上无隔离地执行这些操作会带来严重的安全与稳定性风险。OpenHands 1.0 把隔离做成一等系统保证，具体分三层：

• 容器级隔离：每个任务在独立 Docker 容器中执行，CPU、内存与网络访问按会话配置资源上限；镜像内以 SANDBOX_USER_ID=1000 非根用户运行，限制破坏半径
• 动作级风险分级：内置的 SecurityAnalyzer（基于 LLM 的安全分析器）在每次工具调用执行前评定 LOW / MEDIUM / HIGH 风险等级，配套 ConfirmationPolicy 决定是否需要人工确认
• 默认确认策略：默认的 ConfirmRisky 策略使 Agent 在执行高风险动作（破坏性命令、触碰凭据）前进入 WAITING_FOR_CONFIRMATION 状态——Agent 安全圈呼吁已久的高危动作「暂停等人」，在这里是默认行为而非可选插件

这层设计的行业背景值得展开：2026 年上半年多起真实智能体安全事件（含此前本栏复盘过的 OpenClaw/Moltbook 事件）反复证明，「localhost 信任假设」与「默认全权执行」是开源 Agent 的普遍设计缺陷。OpenHands 把风险分级做成默认开启，与其说是一次功能发布，不如说是对这条教训的工程化回应。

支柱二：BYOM 与模型无关层

OpenHands 1.0 的 BYOM（Bring Your Own Model）框架允许工程团队把任意语言模型 API 或本地模型接入 Agent Harness——模型选择是配置决策而非架构约束。底层通过 LiteLLM 支持 100+ 模型供应商，切换供应商不需要改代码。两条典型路径：

• 云端多模型：常规任务用便宜的开放权重模型，复杂架构问题升级到前沿模型——「harness 不在意后端模型是哪个」是早期用户的直接评价
• 本地/气隙部署：Ollama 在 localhost:11434/v1 暴露 OpenAI 兼容端点，代码、上下文与 API Key 全程不出本机或 VPC。对数据驻留有硬性要求的组织（政府、金融、部分外包合同），这是与商业 SaaS 编码智能体的本质差异

BYOM 的深层意义是把「智能体能力」与「模型供应商」解耦：一套框架、两种模型、同一套工作流。这解释了为什么同一个 OpenHands 能同时出现在「开源榜」（Qwen3-Coder 配对）与「商业榜」（Claude Sonnet 配对）上——Harness 与模型是两个独立变量。

支柱三：插件系统与 SDK 演进

1.0 引入插件系统，允许团队扩展 Agent 的自定义工具、内部 API 连接与领域知识：插件可以改变 Agent 解释任务上下文的方式、连接通用模型训练数据未覆盖的内部系统、或在执行循环中加入领域推理步骤。同期 CLI 工具被拆分到独立仓库，形成更清晰的关注点分离。

更值得关注的是其软件智能体 SDK 的架构：事件溯源状态模型支持确定性重放（审计与事故回放的基础）、不可变 Agent 配置、集成 MCP 的类型化工具系统。工作区抽象让同一 Agent 既能在本地原型运行，也能以最小代码改动切换到安全容器化远程环境，配套内置 REST/WebSocket 服务器、浏览器版 VSCode IDE、VNC 桌面与持久化 Chromium。这套设计说明 OpenHands 的长期目标不是「一个编码 Agent」，而是「可嵌入企业工程体系的智能体运行时」。

68% 与 72% 的正确读法

排行榜数字需要三层上下文，否则极易误读：

系统 / 配对	SWE-bench Verified	许可	每任务估算成本
OpenHands + Claude Sonnet 4.5（扩展思考）	72%	MIT（Harness）	约 $1–3（Token）
OpenHands + Qwen3-Coder-480B（100 轮）	68.0%	MIT	约 $0.30（Token）
OpenHands + Devstral 24B	46.8%	MIT（开放权重）	极低
Devin（Max 计划，Cognition 自报）	77.8%	专有	$200/月 + ACU 额度

其一：Devin 的 77.8% 是厂商自报数字，存在评估口径与污染风险，与独立榜不可直接对齐。其二：Harness 单独能摆动 15–20 个百分点——同一模型接不同脚手架分数差异巨大，这在本栏此前 GAIA 与 SWE-bench Pro 的评测分析中已反复出现。其三：68% 是「配前沿模型跑满 100 轮」的上限成绩，Devstral 24B 的 46.8% 才更接近低预算场景的真实水位。

第三方研究同样提醒别把基准分当生产分：波士顿大学团队 2025 年 7 月的研究显示，在 12 个复杂开放任务上，表现较好的 OpenHands 组合（配 Claude 3.7 Sonnet）平均成功率约 25%，有提示时约 39%——与 SWE-bench 上的分数差距悬殊，因为复杂开放问题的定义与验证都比基准任务模糊。

成本经济学：每任务几美分的含义

OpenHands 叙事中最容易被忽略、但对选型最有决定性的是成本模型：自托管 OpenHands 配 H100 GPU 算力，每解决一个任务的成本约 $0.20–$1.05（取决于模型与任务复杂度）；在开放权重模型（Qwen3-Coder / DeepSeek V3.2）上运行时，单任务成本约为 Devin 的 5%。

这个数字的正确打开方式不是「OpenHands 比 Devin 便宜」，而是成本调整后的吞吐量：对于依赖升级、样板代码生成、测试补齐、内部工具这类「模式已知、量大重复」的工作负载，5% 的单位成本意味着原本因预算被否掉的批量自动化变得可行。McKinsey 2026 State of AI 调研中「32% 的组织已因能用智能体工具自建而放弃采购至少一款软件」的发现，正是这条经济学曲线的宏观投影。

与同类框架技术对比

把 OpenHands 1.0 放进本栏已解构过的编码智能体谱系中：

维度	OpenHands 1.0	Claude Code	Cursor
部署形态	自托管 / 私有云 / 气隙	终端 CLI，模型绑定 Anthropic	云端 IDE，代码经厂商服务
模型策略	BYOM，100+ 供应商 + 本地模型	Anthropic 系	多模型 + 自研 Composer
安全默认	沙箱 + 风险分级 + 高危确认（默认开）	权限提示 + Leader 审批模型	云端隔离执行
扩展机制	插件系统 + MCP + SDK	Subagent / MCP	Git Worktree 隔离 + Cloud Agent
可审计性	事件溯源 + 确定性重放	会话记录	云端日志

定位差异清晰：Claude Code 强在模型与终端体验的垂直整合，Cursor 强在人机协作的 IDE 体验与并行编排，OpenHands 强在数据主权、成本弹性与可审计性——三者并非互相替代，而是对应不同的组织约束。一个务实信号是 OpenHands 官方榜单上的社区复现成绩（OpenHands + CodeAct v3 配 Claude Opus 4.6 达 68.4%，社区复现偏差约 1%），独立可复现性是开源框架相对闭源产品的结构性优势。

局限与适用边界

• 运维门槛真实存在：Docker、GPU 资源、模型路由策略都需要自建能力；对没有平台工程团队的中小组织，商业产品的「开箱即用」仍占优
• 复杂开放任务的能力天花板：第三方研究显示其在模糊定义任务上的成功率远低于基准分，自主处理「开放性架构问题」仍需人在环
• 迭代速度带来的维护成本：1.0 后两天内连发多个版本，跟随升级的 API 变动会转嫁为使用方的适配工作
• 安全依赖配置纪律：风险分级与确认策略虽默认开启，但挂载 Docker Socket 等部署选择若不收紧，隔离边界会被削弱——生产部署仍需参照官方加固指南做网络绑定限制

总体而言，OpenHands 1.0 的意义在于把「生产级安全沙箱 + 模型无关 + 可审计」三件事变成开源编码智能体的默认配置，迫使整个品类把竞争焦点从跑分转向部署经济学。目前官方及行业暂未披露更多企业级路线图细节，后续将持续跟进迭代动态。