boss/docs/competitor-comparison.md

多设备编码代理主控平台竞品对比

更新日期：2026-03-23

目标定义

本对比只关注和下面目标相关的产品或框架：

• 主控端统一管理多个编码代理
• 支持多入口触发，如聊天工具、Web、IDE、CLI
• 能把任务拆成子任务并持续回传进度
• 最好能兼容或借鉴本地设备 worker，而不只是云沙箱

不纳入重点范围的产品：

• 只做本地单机结对编程
• 只做代码补全
• 只做通用办公 agent，不强调编码任务编排

一页结论

• 最接近企业级成品中控：Devin、Factory
• 最适合搬运和二次开发：OpenHands
• 最适合作为主账号大脑：OpenAI Codex
• 最适合作为设备侧 worker：Claude Code、Codex CLI、Aider、Cline、Roo Code
• 最适合作为协议层：MCP
• 最适合作为 agent-to-agent 通信层：A2A

竞品对比表

产品/方案	类型	中控能力	子任务/多代理	多设备本地 worker 适配	聊天入口	自建/二开友好度	适合借鉴的点	主要短板	结论
Devin Enterprise	商业成品	很强	强	弱到中	强	低	企业级组织管理、RBAC、API、调度、外部集成	更偏云环境，不是为本地多设备编队设计	可参考“成品控制台”
OpenAI Codex	商业成品 + 平台能力	强	强	中	强	中	主账号统一对话、多入口、云并行任务	不是现成的多物理设备 fleet 管理器	可作为 manager brain
Factory	商业成品	很强	很强	中	很强	低到中	Subagents、Missions、多入口控制	生态较新，闭源较重	值得重点借鉴交互与控制面
OpenHands Cloud / SDK	开源平台 + 托管服务	强	强	中到强	强	很高	Cloud UI、SDK、远程沙箱、权限、可自建	仍需自己补产品化细节	最适合做底座
GitHub Copilot coding agent	商业成品	中到强	中	弱	中	低	Issue/PR 驱动、GitHub 闭环、组织策略	太 GitHub-centric	只适合借鉴局部流程
Cursor Background Agents	商业成品	中	中	中	强	低	远程 agent + Slack 入口	更偏账号级，不像团队总控台	值得借鉴轻量远程协作
Claude Code	本地 agent	弱	中	很强	中	中	本地终端执行、开发体验强	local-first，不是中控台	非常适合当 worker
Sourcegraph + Batch Changes + MCP	平台底座	中	弱到中	弱	弱	中	批量改仓、代码搜索、分析能力	不是 agent control plane	可作为代码情报层
LangGraph	编排框架	中到强	很强	中	弱	很高	状态机、工作流、持久状态	UI、权限、执行层都要自建	适合完全自研时使用
AutoGen	多代理框架	中	很强	中	弱	高	多代理协作范式成熟	产品化要自己做	适合研究协作逻辑
CrewAI	工作流框架	中	很强	中	弱	中到高	Flow、观测、流程编排	编码执行层不够强	可借鉴业务流程层
MCP	工具协议	不适用	不适用	强	不适用	很高	工具统一接入标准	不是 agent 调度协议	必须纳入架构
A2A	agent 通信协议	不适用	强	强	不适用	高	跨 agent 通信和任务协作	生态仍在发展	建议前瞻纳入

重点产品拆解

1. Devin Enterprise

适合借鉴：

• 企业级组织、权限、审计、API
• 从 Slack、Teams、GitHub、Linear、Jira 等入口发起任务
• 定时 session 和共享工作流

不完全适合直接照搬的点：

• 更偏云端 Devin machine
• 对本地 Windows/Mac 设备级 agent 编队支持不是它的核心卖点

适合你们的参考角色：

• 作为“企业中控台形态”参考

来源：

• https://docs.devin.ai/enterprise/get-started
• https://docs.devin.ai/release-notes

2. OpenAI Codex

适合借鉴：

• 主账号统一发起和跟踪任务
• 跨 App、CLI、IDE、GitHub、Slack、Linear 协作
• 云端并行任务和账户级工作台体验

不完全适合直接照搬的点：

• 更像围绕账户和任务的 agent 工作台
• 不是专门面向“多台真实开发设备”的设备编排系统

适合你们的参考角色：

• 作为 manager brain
• 作为主对话入口和任务拆分层

来源：

• https://openai.com/index/codex-now-generally-available/
• https://help.openai.com/en/articles/11369540-codex-in-chatgpt

3. Factory

适合借鉴：

• Missions 和 Custom Droids 的任务拆解思路
• Slack、Teams、GitHub App、IDE、CLI、Web 的多入口控制
• 远程和本地结合的控制面叙事

不完全适合直接照搬的点：

• 闭源较重
• 需要较多逆向产品层理解，难直接搬运技术实现

适合你们的参考角色：

• 作为“多入口 + 子代理协同”交互范式参考

来源：

• https://docs.factory.ai/
• https://docs.factory.ai/user-guides/droids/creating-custom-droids

4. OpenHands Cloud / SDK

适合借鉴：

• OpenHands SDK 已经是 CLI 和 Cloud 的底层引擎
• 有 Cloud UI、Cloud API、权限、预算、远程沙箱
• 自建和二开空间大

不完全适合直接照搬的点：

• 如果要做极强的多设备本地 worker 编排，仍需扩展 agent server 和 worker registry

适合你们的参考角色：

• 最优先底座候选

来源：

• https://docs.openhands.dev/sdk
• https://docs.openhands.dev/usage/cloud/cloud-ui

5. Claude Code

适合借鉴：

• 本地执行体验强
• 非常适合挂在 Windows/Mac 上做 worker
• 终端型编码任务执行成熟

不完全适合直接照搬的点：

• 官方定位是 local-first，不是统一云端中控

适合你们的参考角色：

• 设备侧 worker 执行器

来源：

• https://claude.com/product/claude-code

我们的推荐路线

路线 A：最快做出产品

• 底座：OpenHands SDK
• Manager：Codex
• 设备侧 worker：Claude Code / Codex CLI
• 对话入口：Web 为主，Slack/Telegram 为辅

适合：

• 先把真实可用的多设备协作跑起来

路线 B：完全自研控制面

• 编排：LangGraph 或 AutoGen
• Manager：Codex
• 工具层：MCP
• agent 协作层：A2A
• 设备侧 worker：你们自己的 daemon，内部再调 Claude Code / Codex CLI

适合：

• 你们希望最终拥有自己的协议、调度和产品层壁垒

路线 C：先验证，再重构

• 第一阶段用 OpenHands 风格快速拼装 MVP
• 第二阶段把设备注册、任务队列、审计、聊天入口收回自研

适合：

• 你们既想快，又不想被单一底座绑死

对你这个产品最关键的判断

如果目标是：

• 主账号持续对话
• 实时调整需求
• 控制多台真实 Windows/Mac
• 支持协同开发和独立开发两种模式

那么最好的产品结构不是“一个超强 agent”，而是：

• 一个 control plane
• 一个 manager agent
• 多个设备侧 worker
• 一套可中断、可续跑、可审计的任务系统

也就是说，真正应该对标的不是“谁最会写代码”，而是“谁最会调度一群会写代码的代理”。

下一步建议

完成第 1 项后，建议继续做：

1. 系统架构图
2. MVP 功能清单
3. 技术选型建议
4. 消息协议与任务状态机