315 lines
6.3 KiB
Markdown
315 lines
6.3 KiB
Markdown
# Boss 技术选型建议
|
||
|
||
更新日期：2026-03-23
|
||
|
||
## 选型原则
|
||
|
||
- 先保证系统能跑，再追求最优雅
|
||
- 持久状态优先于纯内存编排
|
||
- 结构化事件优先于拼字符串日志
|
||
- 尽量复用成熟 agent 运行时，而不是自己重写编码 agent
|
||
|
||
## 总体选型建议
|
||
|
||
| 层 | 推荐 | 备选 | 原因 |
|
||
|---|---|---|---|
|
||
| 前端控制台 | Next.js | Remix, Nuxt | 适合快速做管理台和流式 UI |
|
||
| Desktop | Tauri | Electron | 后续需要时再补，Tauri 更轻 |
|
||
| 后端 API | NestJS 或 Fastify | Express, Go Fiber | 结构清晰，适合长期维护 |
|
||
| 工作流引擎 | Temporal | Inngest, BullMQ + 自建状态机 | 长任务、中断、审批、恢复是核心需求 |
|
||
| 队列/事件 | Redis Streams | NATS, Kafka | MVP 阶段足够轻，开发快 |
|
||
| 主数据库 | Postgres | MySQL | 事务、JSON、查询能力更适合控制平面 |
|
||
| 缓存 | Redis | KeyDB | 用于会话热数据、限流、事件流 |
|
||
| Manager Agent | Codex | Claude API, GPT-5.x Responses | 适合做规划、汇总、重规划 |
|
||
| Worker Runtime | Codex CLI + Claude Code | OpenHands agent runtime | 直接复用成熟编码 agent |
|
||
| 工具协议 | MCP | 自定义 tool API | 标准化工具接入 |
|
||
| 浏览器自动化 | Playwright | Puppeteer | 成熟稳定，适合 agent 使用 |
|
||
| 聊天入口 | Slack 或 Telegram | 飞书, 企业微信 | 文档、生态和迭代速度更合适 |
|
||
| 身份认证 | Clerk 或 Auth.js | 自建 OAuth | MVP 快速起步 |
|
||
| 监控 | OpenTelemetry + Grafana | Datadog, Sentry | 方便追踪任务链路 |
|
||
|
||
## 为什么推荐这个技术组合
|
||
|
||
### 1. Next.js 作为控制台前端
|
||
|
||
原因：
|
||
|
||
- 适合做 dashboard、对话界面、任务树、设备面板
|
||
- 容易做流式更新和服务端渲染
|
||
- 与 TypeScript 一体化
|
||
|
||
不建议现在单独起 React Native：
|
||
|
||
- 当前核心不是移动端，而是 control plane
|
||
|
||
### 2. NestJS 或 Fastify 作为后端
|
||
|
||
如果团队偏工程化：
|
||
|
||
- 选 NestJS
|
||
|
||
如果你想更轻更快：
|
||
|
||
- 选 Fastify
|
||
|
||
建议：
|
||
|
||
- 先用 Fastify 或 NestJS 中你更熟的那个
|
||
- 关键是把服务边界拆干净
|
||
|
||
### 3. Temporal 作为工作流引擎
|
||
|
||
这是当前最关键的选型之一。
|
||
|
||
Boss 不是短请求系统，而是长任务系统。你需要天然支持：
|
||
|
||
- 几分钟到几小时的任务
|
||
- 中途暂停
|
||
- 审批等待
|
||
- worker 断线重连
|
||
- 任务恢复
|
||
|
||
如果不用工作流引擎，后面会自己补很多分布式状态机逻辑。
|
||
|
||
如果 MVP 阶段不想上 Temporal：
|
||
|
||
- 可以先用 `BullMQ + Postgres 状态表`
|
||
- 但要尽快收敛到真正可恢复的工作流模型
|
||
|
||
### 4. Postgres 作为主数据库
|
||
|
||
Boss 的核心不是海量日志，而是：
|
||
|
||
- 会话
|
||
- 任务树
|
||
- 审批
|
||
- worker 注册
|
||
- 状态快照
|
||
|
||
这些都非常适合 Postgres。
|
||
|
||
### 5. Codex 作为 manager
|
||
|
||
原因：
|
||
|
||
- 你希望主账号持续对话和重规划
|
||
- manager 不需要最强本地执行，它更需要任务理解、拆解和汇总
|
||
- Codex 在多入口和云任务语境里更契合 manager 角色
|
||
|
||
推荐职责：
|
||
|
||
- 规划
|
||
- 重规划
|
||
- 汇总
|
||
- 风险解释
|
||
|
||
不建议让 manager 干太多底层执行：
|
||
|
||
- 容易把规划和执行耦合死
|
||
|
||
### 6. Claude Code / Codex CLI 作为 worker runtime
|
||
|
||
原因：
|
||
|
||
- 本地设备执行体验成熟
|
||
- 适合接 terminal、filesystem、git、browser
|
||
- 真实开发环境兼容性更好
|
||
|
||
建议策略：
|
||
|
||
- Mac 和 Windows worker 都先抽象成统一 `executor`
|
||
- 底层可配置使用 `codex` 或 `claude`
|
||
|
||
## 服务拆分建议
|
||
|
||
### 第一阶段服务
|
||
|
||
- `api-gateway`
|
||
- `session-service`
|
||
- `task-service`
|
||
- `scheduler-service`
|
||
- `worker-gateway`
|
||
- `notification-service`
|
||
|
||
### 第二阶段可拆
|
||
|
||
- `approval-service`
|
||
- `memory-service`
|
||
- `git-integration-service`
|
||
- `chat-connector-service`
|
||
|
||
## 数据存储建议
|
||
|
||
### Postgres 表
|
||
|
||
建议至少有：
|
||
|
||
- `users`
|
||
- `project_sessions`
|
||
- `messages`
|
||
- `tasks`
|
||
- `task_dependencies`
|
||
- `worker_nodes`
|
||
- `worker_capabilities`
|
||
- `worker_assignments`
|
||
- `task_events`
|
||
- `approval_requests`
|
||
- `artifacts`
|
||
|
||
### Redis 用途
|
||
|
||
- worker 在线状态
|
||
- 事件总线
|
||
- UI 实时订阅
|
||
- 节流和限流
|
||
|
||
## Worker 设计建议
|
||
|
||
### worker 进程结构
|
||
|
||
组成：
|
||
|
||
- `boss-worker` 守护进程
|
||
- `executor` 适配层
|
||
- `tool adapters`
|
||
- `sandbox policy`
|
||
- `event reporter`
|
||
|
||
### worker 本地目录策略
|
||
|
||
建议：
|
||
|
||
- 一个统一工作根目录
|
||
- 每个任务一个独立 workspace
|
||
- 每个任务一个独立 git worktree
|
||
|
||
示例：
|
||
|
||
```text
|
||
~/boss-worker/
|
||
repos/
|
||
worktrees/
|
||
cache/
|
||
artifacts/
|
||
```
|
||
|
||
### worker 能力声明
|
||
|
||
每个 worker 启动时上报：
|
||
|
||
- OS
|
||
- shell
|
||
- 是否支持浏览器自动化
|
||
- 是否支持特定 IDE
|
||
- 是否有移动端模拟器
|
||
- 是否具备 repo 热缓存
|
||
|
||
## 协议选型建议
|
||
|
||
### MCP
|
||
|
||
用途：
|
||
|
||
- 统一工具调用
|
||
|
||
适合接：
|
||
|
||
- Git
|
||
- 文件系统
|
||
- 浏览器
|
||
- Issue 系统
|
||
- CI
|
||
|
||
### A2A
|
||
|
||
用途：
|
||
|
||
- 中长期用于 agent 之间通信
|
||
|
||
建议：
|
||
|
||
- MVP 不强依赖
|
||
- 但内部消息模型尽量向 agent-to-agent 协作靠拢
|
||
|
||
## 前后端通信建议
|
||
|
||
### 控制台实时能力
|
||
|
||
推荐：
|
||
|
||
- WebSocket 或 Server-Sent Events
|
||
|
||
用途：
|
||
|
||
- 推送任务状态
|
||
- 推送审批请求
|
||
- 推送设备在线变化
|
||
|
||
### worker 连接方式
|
||
|
||
推荐：
|
||
|
||
- WebSocket 长连接
|
||
|
||
原因：
|
||
|
||
- 需要双向通信
|
||
- 需要下发中断和恢复命令
|
||
|
||
## 安全建议
|
||
|
||
### 最小权限原则
|
||
|
||
- worker 不要默认拥有所有仓库权限
|
||
- 每种工具调用都要有权限分级
|
||
|
||
### 高风险动作审批
|
||
|
||
必须纳入审批的动作：
|
||
|
||
- 删除大量文件
|
||
- 强推分支
|
||
- 执行危险 shell
|
||
- 访问敏感路径
|
||
|
||
### 审计
|
||
|
||
必须记录：
|
||
|
||
- 谁发起了什么
|
||
- 哪个 worker 执行了什么
|
||
- 哪个 agent 建议了什么
|
||
- 审批前后状态
|
||
|
||
## 推荐的 MVP 技术栈
|
||
|
||
### MVP 最稳组合
|
||
|
||
- 前端：Next.js
|
||
- 后端：NestJS
|
||
- 数据库：Postgres
|
||
- 缓存和事件：Redis
|
||
- 工作流：BullMQ，后续升级 Temporal
|
||
- Manager：Codex
|
||
- Worker：Codex CLI + Claude Code
|
||
- 聊天入口：Telegram 或 Slack
|
||
|
||
### 如果你要一步到位更稳
|
||
|
||
- 前端：Next.js
|
||
- 后端：NestJS
|
||
- 数据库：Postgres
|
||
- 缓存：Redis
|
||
- 工作流：Temporal
|
||
- Manager：Codex
|
||
- Worker：Codex CLI + Claude Code
|
||
- 监控：OpenTelemetry
|
||
|
||
## 不推荐的坑
|
||
|
||
- 不要一开始就全微服务
|
||
- 不要一开始就自研完整 agent runtime
|
||
- 不要把聊天平台当成主控制台
|
||
- 不要让多个任务共用一个工作目录
|
||
- 不要把审批做成“日志里提示一下”而不是显式状态
|