7.1 KiB
7.1 KiB
多设备编码代理主控平台竞品对比
更新日期：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 编队支持不是它的核心卖点
适合你们的参考角色：
- 作为“企业中控台形态”参考
来源：
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 的多入口控制
- 远程和本地结合的控制面叙事
不完全适合直接照搬的点：
- 闭源较重
- 需要较多逆向产品层理解，难直接搬运技术实现
适合你们的参考角色：
- 作为“多入口 + 子代理协同”交互范式参考
来源：
4. OpenHands Cloud / SDK
适合借鉴：
- OpenHands SDK 已经是 CLI 和 Cloud 的底层引擎
- 有 Cloud UI、Cloud API、权限、预算、远程沙箱
- 自建和二开空间大
不完全适合直接照搬的点：
- 如果要做极强的多设备本地 worker 编排，仍需扩展 agent server 和 worker registry
适合你们的参考角色：
- 最优先底座候选
来源：
5. Claude Code
适合借鉴：
- 本地执行体验强
- 非常适合挂在 Windows/Mac 上做 worker
- 终端型编码任务执行成熟
不完全适合直接照搬的点：
- 官方定位是 local-first，不是统一云端中控
适合你们的参考角色：
- 设备侧 worker 执行器
来源：
我们的推荐路线
路线 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 项后，建议继续做：
- 系统架构图
- MVP 功能清单
- 技术选型建议
- 消息协议与任务状态机