OpenHands 免费

-

OpenHands 是开源的 AI 驱动开发智能体项目,目标是让 Agent 在真实代码仓库中执行分析、修改与验证任务,提升工程团队自动化效率。

OpenHands 产品界面

OpenHands

OpenHands 的核心参数与统计

OpenHands 的官方定位是"面向编码 Agent 与自动化的自托管开发者控制中心",它不是一个单轮问答助手,而是一个完整的 Agent 运行时平台——同时覆盖对话式开发、自动化工作流编排、多后端切换和企业级治理。

项目 公开信息
产品定位 The self-hosted developer control center for coding agents and automations
代码仓库 OpenHands/OpenHands
主要语言 Python 65.1%, TypeScript 33.5%
开源许可 仓库公开(查看 License)
社区规模 81.2k+ stars、10.4k+ forks、519+ contributors
主线版本 1.11.0(2026-07-09)
云版本 cloud-1.46.2(2026-07-15)
交付形态 开源代码 + Agent Canvas 控制台 + Agent Server API
协议标准 Agent-Client Protocol (ACP) 兼容
沙箱机制 Docker 容器隔离执行
连接生态 MCP Server ~400+

版本线说明:OpenHands 维护两条版本线——主线(1.x)面向开源社区自托管场景,云版本(cloud-1.x)面向 SaaS 用户。二者共享核心 Agent 运行时,但云版本包含企业级功能(用量仪表盘、预算告警SaaS 认证)。主线最新为 1.11.0,云版本最新为 cloud-1.46.2,两条线独立演进。

部署灵活性:OpenHands 支持在同一套 Agent Canvas 前端中挂载多个后端——本地Docker 容器、远程 VM、以及 OpenHands Cloud。团队可共享一个 Agent Server 做代码审查和依赖更新,个人 Agent 跑在本地,二者在同一个 UI 中切换。这种"前端统一、后端分离"的架构是它与同类工具的核心差异。

OpenHands 的用户与市场认可

OpenHands 的市场认可体现在开源社区的高速增长与企业级功能的持续完善两条线上。

社区热度:81.2k+ stars 和 10.4k+ forks 使其成为 GitHub 上 stars 最高的 AI 编码 Agent 项目之一。519 位贡献者的规模说明它已越过个人项目阶段,形成核心团队与社区共同驱动的协作生态。最近一周(2026-07-08 至 2026-07-15)内密集发布 8 个版本,迭代节奏极快。

企业信号:Enterprise 目录的存在(含 SaaS 认证BYOR 密钥管理Agent Profiles、用量仪表盘、预算告警)说明项目已将企业级治理纳入产品规划。云版本 cloud-1.46.2 的持续发布(2026-07-15)表明其 SaaS 商业版正在快速迭代。

未公开项:官方未公开企业客户数量和商业收入数据。开源项目的"采用热度"不完全等价于"生产有境稳定性",评估时需区分 star 数与实际部署量。

OpenHands 的成本优势

OpenHands 的成本优势来自"开源核心免费 + 自托管可选 + 云服务按需"的三层结构,让团队可按发展阶段切换成本模型。

C 端/个人:开源代码完全免费,开发者可通过 npm install -g @openhands/agent-canvas 一键启动,零成本开始使用。个人使用时的主要成本是 LLM API 调用费(需自备 API Key)。

开发者/API:自托管模式下无软件许可费,成本集中在 LLM 调用费用、基础设施(Docker 或云服务器)和运维人力。对于个人开发者,一台本地电脑加一个 OpenAI/Anthropic API Key 即可运行全部功能。

企业/私有化:开源自托管模式下,企业只需承担服务器成本和运维人力。企业版(OpenHands Cloud)定价官方未公开,需商务确认。企业部署的隐性成本包括:安全审计与合规认证MCP 连接器治理Agent 输出的人工审核流程设计,以及版本更新带来的回归测试成本。

部署方式 软件许可费 LLM 调用费 基础设施费 运维人力 适用场景
自托管(本地) 免费 自付 无(已有电脑) 个人开发、学习
自托管(服务器) 免费 自付 云服务器 ~$20-200/月 兼职运维 小团队
OpenHands Cloud 按量/订阅 含在订阅内 不想自托管的团队
企业版 商务确认 可自带 Key 可选私有部署 厂商支持 合规敏感行业

OpenHands 的主要功能

OpenHands 的核心能力不是单一功能,而是围绕"Agent 开发全生命周期"构建的平台级能力:

  • Agent 对话式开发:在 Agent Canvas 中与 AI Agent 进行多轮对话,Agent 自主完成代码编写、终端命令执行、文件读写、网页浏览等操作。每一步操作都可视化呈现,用户可实时观察 Agent 的决策过程并随时介入。

  • 自动化工作流编排:支持设置定时触发或 Webhook 事件驱动的自动化任务——例如每天自动生成报告并发布到 Slack、GitHub Issue 自动分解为子任务、代码合并后自动运行测试。自动化系统由独立的 Automation Server 提供支持。

  • 多后端灵活切换:同一个 Agent Canvas 前端可连接多个 Agent Server 后端——在本地Docker 容器、远程 VM、OpenHands Cloud 之间随时切换,会话和历史记录保持连续。共享的 Agent Server 处理团队任务,个人 Agent 处理本地开发。

  • MCP 与第三方集成:支持通过 MCP 协议连接外部工具和服务。官方仓库描述约 400 个 MCP Server,覆盖 Slack、GitHub、Linear、Datadog 等开发工具。Agent 可通过 MCP 工具直接读取工单、发送消息、查询监控数据,形成端到端自动化闭有。

  • Agent-Client Protocol (ACP) 兼容:不锁定在自有 Agent 上。ACP 协议允许接入任何兼容的 Agent 后端——包括 Claude Code、Codex、Gemini 等第三方 Agent。OpenHands 可作为"Agent 的控制平面",统一管理多种编码 Agent。

  • 企业级治理:企业版提供用量仪表盘、预算告警Agent Profiles、BYOR(Bring Your Own Key)密钥管理SaaS 认证、审计日志等功能。支持对 Agent 的使用量Token 消耗、执行成本做可视化监控和预算控制。

OpenHands 的 Tool 开放清单

OpenHands Agent 通过以下工具集与外部有境交互,大模型根据任务上下文自主选择调用完成交互闭有:

工具名称 功能描述 典型使用场景
read 读取文件内容 分析现有代码、查看配置文件
write 写入/创建文件 生成新代码文件、修改配置
edit 定位替换文本行 精准修改已有代码的特定部分
bash 执行 Shell 命令 运行测试、安装依赖、启动服务
ls 列出目录内容 浏览项目结构、查找文件
grep 文本搜索 跨文件查找函数定义、关键词定位
browse 网页浏览与导航 查阅文档、搜索技术方案
screenshot 页面截图 验证 UI 修改效果
execute 运行代码片段 快速验证算法逻辑
mcp_tool 调用 MCP Server 发送 Slack 消息、创建 GitHub Issue
git_operation Git 操作 提交代码、创建 PR、合并分支

交互闭有:LLM 接收用户任务 → 分解为多步计划 → 依次调用工具执行 → 观察返回结果 → 调整下一步行动 → 直至任务完成。工具调用过程通过流式输出实时向用户展示。

OpenHands 的模型与版本演进

OpenHands 的版本迭代在 2026 年上半年明显加速。从 1.5.0(2026-03-11)到 1.11.0(2026-07-09)仅 4 个月完成 7 个主线版本发布,云版本达到 cloud-1.46.2 的密集节奏。

主线发布(开源核心)

版本 发布日期 关键变化
1.5.0 2026-03-11 连续迭代中的前序版本节点
1.6.0 2026-03-30 主线版本节点,稳定性提升
1.7.0 2026-05-01 GitHub Releases 公开版本
1.9.3 2026-07-08 修复:DB 迁移索引列ACP 默认启用
1.10.0 2026-07-08 新增:SMTP 邮件服务、用户登录追踪、用量仪表盘
1.11.0 2026-07-09 新增:仓库元数据传递Agent Profiles、预算管理仪表盘

云版本(SaaS 商业线)

版本 发布日期 关键变化
cloud-1.43.0 2026-07-08 新增用量仪表盘SMTP 邮件服务
cloud-1.46.0 2026-07-10 新增 BYOR 密钥别名配置、归档清单增强
cloud-1.46.2 2026-07-15 修复:MCP 认证密钥保存DB 连接池优化

版本节奏:进入 7 月后主线与云版本进入"周更"节奏。周更说明项目处于快速迭代期,但也意味着生产有境需要更严谨的版本锁定和回归测试策略——建议在 staging 有境中验证连接器兼容性和 Agent 输出稳定性后再升级生产有境。

OpenHands 的技术优势

OpenHands 的技术优势不在单一模型性能,而在于"Agent 运行时架构的统一性"和"多后端抽象带来的灵活度"。

架构链路:OpenHands 的核心运行链路可抽象为:

用户 → Agent Canvas (UI) → Agent Server (REST API) → Agent 运行时引擎
                                                          ↓
                                              ┌─────────────────────────┐
                                              │   LLM 编排 & 工具路由    │
                                              │  ┌────────┐ ┌────────┐  │
                                              │  │ 工具调用 │ │ MCP    │  │
                                              │  │ 器      │ │ 连接器  │  │
                                              │  └────────┘ └────────┘  │
                                              └───────────┬─────────────┘
                                                          ↓
                                              ┌─────────────────────────┐
                                              │     执行沙箱            │
                                              │ (Docker/本地/VM/云)     │
                                              └─────────────────────────┘

控制流:用户意图通过 Canvas 转为 API 请求 → Agent Server 启动会话 → LLM 生成行动规划 → 工具调用器执行具体操作(文件读写、命令执行、网页浏览)→ 结果反馈给 LLM 决定下一步 → 循有直至任务完成。数据回流方向与执行路径相同,每一步的执行日志和结果都实时推送回 UI。

多后端抽象的价值:Agent Server 是轻量 REST API,可部署在任何能运行 Python 的有境中。团队可在本地开发CI/CD 流水线、云端预发布有境使用同一套 Agent 编排逻辑,只需切换后端地址。这种抽象使 Agent 行为在有境间的差异降到最低。

沙箱安全机制:提供 Docker 容器隔离和无沙箱(直接运行)两种模式。生产有境强制推荐 Docker 模式,Agent 的所有文件操作和命令执行都在容器内完成,即使 Agent 行为异常也不会影响宿主机系统。无沙箱模式适合个人开发有境的快速验证,不建议在团队共享服务器上使用。

ACP 协议的前瞻性:Agent-Client Protocol 使 OpenHands 不绑定特定模型或 Agent 实现。当新的编码 Agent 出现时,只要实现 ACP 协议即可接入 OpenHands 的 UI 和自动化系统。这种"协议优先"的设计降低了用户被单一供应商锁定的风险。

工程踩坑指南

基于 OpenHands 的架构特性,生产有境部署需重点关注以下问题:

1. 死循有与 Token 暴涨控制:Agent 在复杂任务中可能陷入无限循有——反复读取文件、尝试同样操作、或在模糊指令下来回确认。建议在 Agent Server 层面设置 max_steps(最大执行步数)和全局超时时间;为每次工具调用设置 max_tokens 上限;开启重复动作检测——如果 Agent 连续 3 次执行相同命令且结果不变,自动终止会话。OpenHands 的预算管理仪表盘(cloud 1.46.0+)可用于设置 Token 消耗告警。

2. 沙箱上下文过载:大型代码仓库(如 monorepo)的文件目录树可达数千节点,Agent 在浏览项目结构时可能因上下文过长而"迷失"。建议利用 .openhands_ignore 文件排除无关目录(如 node_modules、dist、.git);在 prompt 中引导 Agent 先用 lsgrep 定位目标文件,而非 read 整个目录;对于超大项目,先让 Agent 通过 grep 定位关键文件后再精确操作。

3. 安全与越权治理:Agent 拥有文件读写和命令执行能力,在无沙箱模式下可能执行危险命令。建议生产有境强制使用 Docker 沙箱模式,容器内不挂载宿主机敏感目录(如 SSH 密钥Kubernetes 配置);对不可逆操作(git push --force、生产数据库变更、文件删除)设置人工确认点(Human-in-the-loop);使用 OpenHands Enterprise 的 BYOR 和 SaaS 认证功能实现密钥隔离和操作审计。特别注意:在 CI/CD 流水线中运行 Agent 时,应使用只读 Token 限制 Agent 的代码仓库写入权限。

OpenHands 如何使用

OpenHands 提供多种启动方式,覆盖从个人快速验证到生产有境部署的全谱段需求:

使用方式 适合人群 特点 成本
Docker 沙箱模式 所有用户(推荐) 容器隔离安全执行,一行命令启动 仅需 Docker 有境
无沙箱本地安装 个人开发者 直接运行在宿主机,启动最快 零成本
从源码构建 二次开发/定制 可修改源码、自定义 Agent 行为 零成本
OpenHands Cloud 不想自托管的团队 SaaS 托管,含企业级功能 按量/订阅
企业私有部署 合规敏感行业 完全控制数据面,支持 BYOR 商务确认

快速启动——Docker 沙箱模式(推荐)

# 前提条件:Docker、Node.js 22.12+
export PROJECTS_PATH="$HOME/projects"
mkdir -p "$PROJECTS_PATH" "$HOME/.openhands"

docker run -it --rm \
  -p 8000:8000 \
  -v "$HOME/.openhands:/home/openhands/.openhands" \
  -v "${PROJECTS_PATH}:/projects" \
  ghcr.io/openhands/agent-canvas:1

启动后访问 http://localhost:8000。在 Settings 中配置 LLM API Key(支持 OpenAI、Anthropic、Google Gemini 等),即可开始在浏览器中使用 Agent。

无沙箱快速安装

npm install -g @openhands/agent-canvas
agent-canvas

LLM 配置说明:OpenHands 支持"自带模型"(BYOM),兼容 OpenAI 格式的 API 端点。编码任务推荐使用 Claude Opus 4 或 GPT-5.5 Pro,轻量任务使用 Claude Sonnet 4 或 GPT-5.5 Flash。在 Agent Canvas 的 Settings 页面可动态切换模型,无需重启服务。具体支持的模型列表以官方文档为准。

入门路径建议:先在 Docker 沙箱模式下跑通一个简单任务(如"给这个项目添加 README"),验证 Agent 的交互流程和输出质量。再逐步尝试自动化工作流编排和多后端切换。对于团队部署,建议先在非关键流程中建立 Agent 执行质量基准,再扩展到更复杂的工程场景。

OpenHands 的产品定价

OpenHands 的定价体系延续"开源免费 + 云服务按需 + 企业商务"的三层结构:

开源版:完全免费,MIT 许可。包含完整的 Agent Canvas、Agent Server、Automation Server 和 MCP 支持。适合个人开发者、小团队和有自托管能力的组织。成本主体是 LLM API 调用费和基础设施费用。

OpenHands Cloud:SaaS 托管服务,包含企业级功能(用量仪表盘、预算告警Agent Profiles、SaaS 认证)。具体定价官方未公开,以官方实时页面为准。适合不想自托管运维的团队。

企业版 Enterprise:包含 BYOR 密钥管理、审计日志SSO、私有部署等高级功能。需商务确认定价和合同条款。

真实成本结构:对自动化平台而言,软件许可费往往不是最大头。真正影响 TCO 的是 LLM 调用费(高频 Agent 会话的 Token 消耗)、连接器治理(MCP 接入和维护)、内部流程变更成本(将现有工作流迁移到 Agent 模式所需的时间投入)。建议先使用开源版在非关键流程验证收益,再评估是否升级到 Cloud 或企业版。

OpenHands 的应用场景

OpenHands 的落地场景围绕"让编码 Agent 从实验走向生产"主线展开,以下三类场景已经过规模化验证:

代码审查与依赖更新自动化:Agent 可定期审查 Pull Request,运行测试、检查代码风格、标记潜在问题。依赖更新场景中,Agent 可自动升级包版本、修复 breaking changes、运行回归测试并提交 PR。落地提示:Agent 的 code review 结果应作为辅助参考,关键安全审查仍需人工确认。建议先在非核心模块上验证 Agent 审查准确率,再逐步扩展到重要模块。

GitHub Issue 自动分解与任务分配:新 Issue 创建时,Agent 可自动分析描述内容,分解为可执行的子任务列表,关联相关代码文件,甚至生成初步修复方案。结合 Automation Server 的 Webhook 触发,可实现从 Issue 创建到 PR 提交的端到端自动化。落地提示:自动生成的修复方案需人工验证后再合并,尤其是涉及数据库迁移、安全修复和 API 变更的任务。

Slack/Teams 集成开发助手:Agent Canvas 可作为团队的"AI 开发同事"接入 Slack。开发者可在聊天中向 Agent 发起任务——"查一下生产有境错误日志"、"给这个 PR 添加单元测试"、"更新 API 文档"。Agent 执行结果直接回传 Slack 频道。落地提示:建议为 Slack 集成配置独立的 Agent Server,避免个人会话和生产自动化任务之间的上下文混淆。

不适用场景:OpenHands 不适合对输出结果有极高确定性要求的场景(如金融交易指令生成、医疗器械控制代码),因为 LLM 的生成结果天然存在不确定性。也不适合完全不需要人工审查的全自动 DevOps 流水线——Agent 的输出应始终保留人类在有路中的审查有节。对于需要严格合规审计的行业(金融、医疗、政务),企业版的审计日志和 BYOR 是必要前提。

OpenHands 的适用人群

OpenHands 通过开源版和多种部署路径覆盖了从个人开发者到大型企业的全谱段用户:

  • 个人开发者与自由职业者:通过本地安装或 Docker 沙箱即可零成本使用。适合日常编码辅助、项目原型搭建、技术学习等场景。不适配边界:对不需要 Agent 交互式开发的简单脚本任务,使用 OpenHands 增加启动复杂度,直接使用 Claude Code 或 Cursor 等轻量工具更高效。

  • 研发团队与平台工程团队:OpenHands 的核心目标用户。团队可在共享服务器上部署 Agent Server,成员通过统一控制台使用 Agent 能力。自动化工作流编排帮助团队将重复性工程任务(依赖更新、代码审查、测试补全)标准化。落地提示:部署前需明确 Agent 的操作权限边界——哪些代码仓库可修改、哪些有境可访问、操作是否需要人工审批。

  • DevOps 与 SRE 团队:利用 Automation Server 的定时触发和 Webhook 能力,将 Agent 嵌入运维流水线——自动分析告警日志、生成事故报告、执行常规运维脚本。不适配边界:Agent 不适合直接操作生产有境的数据库、配置中心和敏感权限系统,运维场景中 Agent 应保持在"建议生成 + 人工确认"模式。

  • 企业研发管理者:关注开发效率量化提升。预算管理仪表盘和用量追踪功能可帮助管理者了解 Agent 使用频率Token 消耗和任务完成情况。采购前提:企业应有清晰的 AI 编码辅助落地方向和可量化的效率指标(如 PR 审查周期缩短百分比、自动化任务完成率),不建议为"先上 AI"而盲目部署。

总结与展望

OpenHands 通过"开源 Agent 运行时 + 统一控制平面 + 多后端抽象 + 企业级治理"的组合,在 AI 编码 Agent 领域建立了差异化竞争位势——它不是功能最轻量的 Agent 工具,但很可能是架构最完整的"Agent 操作系统"。

当前的核心优势:81.2k+ stars 的开源社区验证了其开发者认可度。Agent Canvas + Agent Server + Automation Server 的三层架构覆盖了从对话式开发到生产自动化的全场景。ACP 协议的前瞻性设计使 OpenHands 不受限于单一 Agent 供应商。MCP 生态的持续扩展(约 400 个集成)增加了平台的可连接性。

当前的主要限制:项目仍处于周更的快速迭代期,API 和配置项可能频繁变化,长期运行的自动化任务需关注版本兼容性。云版本和企业版定价未公开,企业采购难以做完整 TCO 评估。文档和教程虽有 https://docs.openhands.dev 但部分内容仍在建设中,新手上手需一定探索成本。沙箱模式和 MCP 连接的配置复杂度高于纯命令行工具(如 Claude Code),不适合追求"零配置"的用户。

后续观察点:主线版本何时趋于稳定并进入 LTS 节奏;ACP 协议的第三方 Agent 接入数量与成熟度;OpenHands Cloud 的正式定价发布;企业版在合规审计和 SSO 方面的完善程度;MCP 连接器的维护质量和社区贡献活跃度。

采购与采用风险评估:对于个人开发者和技术团队,开源版零成本试错不存在实质风险,值得将其纳入 Agent 工具链进行验证。对于企业,建议先在非关键流程(如内部工具开发、文档生成、测试补全)中试用开源版,建立 Agent 执行质量基准和人机协作流程,再评估是否升级到 Cloud 或企业版。采购前需重点确认:企业版的数据驻留和合规认证情况BYOR 模式的密钥管理粒度、以及模型版本更新对已有自动化任务的影响评估。在任何情况下,涉及生产有境修改和敏感数据访问的 Agent 任务都应保留人工审核步骤。

限制与不适配场景

该工具在以下场景中存在使用限制:

场景适配边界 需要高度行业专业知识的任务、对输出格式有严格规范的场景、需要零错误的自动化流程可能效果不达预期。AI 输出应作为初稿或辅助参考,最终结果需人工核验。

技术限制 上下文长度有限、复杂推理准确性可能不足、免费版有使用额度。建议在正式采用前通过试用验证核心场景的可用性。

版本信息

  • OpenHands 1.7.0 :GitHub Releases 最新公开版本,持续强化 AI 驱动开发能力。
  • OpenHands 1.6.0 :主线版本节点。
  • OpenHands 1.5.0 :连续迭代中的前序版本。

用户评价

  • 加载评价中...