# autogpt_platform/README.md:14
cd AutoGPT/autogpt_platform
cp .env.default .env
docker compose up -d
# 浏览器打开 http://localhost:3000  ← 可视化构建器

# 或分开跑（开发）：
make start-core       # 只起 Supabase + Redis + RabbitMQ
make run-backend      # 后端
make run-frontend     # 前端

后端不是单个进程，而是一群。app.py:34 的 main() 用 run_processes() 一次拉起所有子进程（app.py:49）：

# app.py:49 —— 一次启动所有后端进程
run_processes(
    DatabaseManager(),      # 数据库访问
    Scheduler(),            # 定时任务（Day 14）
    NotificationManager(),  # 通知
    WebsocketServer(),      # 实时推送（Day 15）
    AgentServer(),          # REST API（Day 18）
    ExecutionManager(),     # 执行引擎（Day 12）★核心
    # ... CoPilot 相关进程
)

• 独立伸缩：执行引擎（executor）是最吃资源的，可以单独多开几个实例扛并发；REST 服务开一两个就够。分开进程才能各自伸缩。
• 故障隔离：某个执行卡死/崩溃，不影响 REST 服务继续接请求。
• 职责单一：每个进程干一件事，代码清晰、易维护。
• 异步解耦：REST 收到"执行请求"后不自己跑，而是丢进队列（RabbitMQ），executor 进程去消费——REST 立刻返回，执行在后台进行。

REST app（api/rest_api.py:208）装了几个中间件：

• SecurityHeadersMiddleware：加安全响应头。
• GZip 压缩：响应 >50KB 才压——专为 /api/blocks（列出 300+ 块，响应很大）优化。
• CORS：跨域控制（前端和后端不同端口）。

• RabbitMQ（任务队列）：REST 把"图执行请求"发到队列，executor 进程消费。保证任务不丢（executor 挂了消息重回队列）、不超载（一个 executor 只取它能跑的量）。
• Redis（缓存 + 事件总线）：① 缓存（如 Block 清单）；② 事件总线——executor 每次节点状态变化就 publish 事件到 Redis，WebSocket 进程订阅后转发给前端（Day 15）；③ 分布式锁（保证同一执行不被两个进程重复跑）。

前端是 Next.js + TypeScript 的可视化构建器（Day 03 讲过画布对应 Graph 模型）。有个工程细节：前端的 API 客户端是自动生成的——后端出 OpenAPI 规范，前端用 Orval 工具生成 TS 客户端（pnpm generate:api）。

✋ 动手

P=autogpt_platform
sed -n '14,70p' $P/README.md                          # 启动方式
grep -n 'run_processes\|ExecutionManager\|WebsocketServer' $P/backend/backend/app.py
grep -nE 'rest_server|executor|rabbitmq|redis|clamav' $P/docker-compose.yml | head