217 lines
7.1 KiB
Markdown
217 lines
7.1 KiB
Markdown
# 多设备编码代理主控平台竞品对比
|
||
|
||
更新日期：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. 消息协议与任务状态机
|