开发与工程 agent-canvascontrol-centerautomationacpself-hosted

OpenHands Agent Canvas

自托管的编码智能体控制台,可接入 OpenHands、Claude Code、Codex 等任意 ACP 智能体

FollowAgents 评估 · FARS-2.1
推荐
76/ 100 五分制 3.8 / 5
1 2 3 4 5 6
1信任安全21 / 29 · 3.6/5

证据显示:AGENTS.md 详细描述了遥测架构,强调用户同意控制(setTelemetryConsent)和硬禁用(configureTelemetry(false)),并明确禁止组件直接调用 opt_in/opt_out_capturing,体现了最小权限原则。数据流透明性高,明确列出了遥测数据流向(PostHog)和事件属性。敏感数据处理方面,明确禁止在 X-OpenHands-Client 头中放置设备代码、API 密钥等,并限制 live E2E 中凭据的暴露。依赖安全方面,有 dependabot 每周更新和 CI 中的 npm ci,但未提供漏洞扫描证据。外部影响方面,明确遥测事件和自动化行为,但未提供用户确认外部操作的机制。回滚方面,未提及配置或状态回滚机制。来源归属方面,明确遥测事件附加不可变属性,但未涉及代码来源归属。扣分原因:回滚机制缺失,外部影响缺乏用户确认。

2可靠稳定11 / 14 · 3.9/5

证据显示:AGENTS.md 内部一致,详细描述了运行时服务、测试框架和遥测架构,无矛盾。依赖可用性方面,明确列出运行时包(sirv、httpxy)和构建依赖,但未提供依赖可用性保证。失败消息方面,live E2E 运行器会解释缺失凭据,但未提供一般错误处理。扣分原因:依赖可用性未提供保证,失败消息覆盖有限。

3适用触发16 / 18 · 4.4/5

证据显示:受众明确为开发者和自托管用户,场景包括本地、Docker、云后端。能力边界清晰,明确区分了本地和云后端,以及 live E2E 与 mock-LLM 测试。触发精度方面,明确 live E2E 只在特定条件下运行,但未提供用户触发机制。环境适配方面,支持多种部署方式(npm、Docker、源码、Electron),并提供了 Windows 指南。扣分原因:触发精度未涉及用户交互。

4规范维护14 / 18 · 3.9/5

证据显示:信息架构清晰,有 README、docs、AGENTS.md 等。安装说明详细,包括 npm、Docker、源码和 Windows。命名稳定性方面,有版本号和 changelog,但未明确命名约定。示例和 FAQ 方面,有 quickstart 和文档链接,但无 FAQ。已知限制方面,README 中警告无沙箱运行的风险,但未全面列出。许可证为 MIT,明确。版本控制有 changelog 和 release-please,但未提供详细变更日志。维护责任方面,有 CI 和 dependabot,但未明确维护者。扣分原因:命名约定未明确,FAQ 缺失,已知限制不全面。

5有效结果9 / 13 · 3.5/5

证据显示:输出可用性方面,提供了 UI 和 CLI,但未提供输出格式说明。边际价值方面,提供了自动化、多后端支持,但未量化。成本效益方面,有 CI 和测试,但未提供性能数据。扣分原因:输出格式未说明,边际价值和成本效益缺乏量化。

6证据核验5 / 8 · 3.1/5

证据显示:声明可追溯性方面,AGENTS.md 描述了测试框架和 CI,但未提供具体测试结果。跨来源佐证方面,有 README 和文档,但未提供独立验证。事实与推断分离方面,AGENTS.md 区分了描述和指令,但未明确标注推断。扣分原因:缺乏测试结果和独立验证。

证据充分度: 评估于 2026年8月9日 审查版本 68de5c58872a
上游仓库在本次评估后已有新提交;当前评分仍对应所示审查版本,可能尚未覆盖最新改动。
使用前请注意
  • 该仓库包含遥测功能,默认使用 PostHog 键,可能向外部发送数据;部署时应设置 VITE_DO_NOT_TRACK=1 或配置自己的键。
  • 无沙箱模式运行 agent-server 会给予代理完全的文件系统访问权限,存在安全风险。
  • live E2E 测试需要 LLM 凭据,且 CI 中可能暴露凭据,需确保 fork PR 被跳过。
查看完整评分方法 →

这个 Agent 能做什么,适合哪些场景?

OpenHands 最初以自动化软件工程智能体著称,如今这个仓库已转型为 Agent Canvas——一个自托管的开发者控制台,用来发起对话并把日常任务自动化(例如生成报告并发布到 Slack、把 GitHub issue 自动拆解成任务)。它可以在本地、Docker、远程或云端运行智能体后端,并支持切换使用 OpenHands 自带智能体、Claude Code、Codex 等任意兼容 Agent-Client Protocol(ACP)的第三方智能体。

提供一个自托管的控制台界面,用来创建对话、配置自动化工作流;可以连接本地、Docker 容器、VM 或云端的智能体后端,并与 Slack、GitHub、Linear、Notion 等第三方服务集成,按计划或 webhook 事件触发自动化任务。

  1. 把 GitHub issue 自动拆解成任务并分配给智能体处理
  2. 定期生成报告并自动发布到 Slack 频道
  3. 在公司内部基础设施上自托管,统一管理多个智能体后端
  4. 在 OpenHands 自带智能体和 Claude Code / Codex / Gemini 等第三方智能体之间按需切换

这个 Agent 有哪些优点和局限?

优点
  • 不锁定单一智能体,可在本地、Docker、远程、云端等多种后端间切换
  • 内置自动化能力,能对接 Slack/GitHub/Linear 等常用协作工具
  • 历史积累的社区规模很大(8 万+ Star),生态和讨论资源丰富
  • 支持完全自托管,适合有数据合规要求的团队
局限
  • 仓库正处于迁移期,源码分散在多个新仓库,短期内查找当前实现略麻烦
  • 定位已从单一自动化编码智能体转向更泛化的控制台,如果只需要一个开箱即用的编码智能体,可能不是最直接的选择
  • 实际安全性和效果高度依赖你接入的具体智能体后端,本仓库本身更多是调度层

如何安装或部署这个 Agent?

该仓库目前处于迁移阶段:控制台前端源码见 OpenHands/agent-canvas,智能体与 Agent Server 源码见 OpenHands/software-agent-sdk。具体自托管步骤(本地部署、VM 部署等)请参考官方文档 docs.openhands.dev 的 Self-Hosting 章节,避免直接照搬本仓库过时的安装说明。

如何使用这个 Agent?

部署完成后,通过控制台发起一个对话,选择要使用的智能体后端(OpenHands 自带、Claude Code、Codex 等),描述任务或配置自动化触发条件(定时/webhook),由控制台调度对应后端执行。

这个 Agent 与同类方案有什么区别?

与 Claude Code、Codex CLI 这类单一厂商的终端编码智能体不同,OpenHands Agent Canvas 定位是「智能体调度控制台」——它本身不是某一个智能体,而是让你在同一个自托管界面里管理和调用多种智能体后端并配置自动化。如果你只需要一个终端里能跑的编码助手,Codex CLI/opencode 更直接;如果你需要跨多个智能体、多种后端做统一编排和自动化,Agent Canvas 更贴合这个场景。

常见问题

OpenHands 还是原来那个自动化编码智能体吗?
原有的 Agent 与 Agent Server 源码已经迁移到 OpenHands/software-agent-sdk,这个仓库现在是叫 Agent Canvas 的控制台产品,用来调度和管理智能体,而不是智能体本身。
必须使用 OpenHands 自己的智能体吗?
不需要,只要是兼容 Agent-Client Protocol(ACP)的智能体(如 Claude Code、Codex、Gemini)都可以接入。
可以完全部署在自己的服务器上吗?
可以,官方文档提供本地、VM 等多种自托管方式,也可以选择使用 OpenHands Cloud/Enterprise 托管版本。

对比同类 Agent

用同一套 FARS 评审,横向比较这个 Agent 所属的短名单。

相关 Agents