Suna 源码解读项目地址https://github.com/kortix-ai/sunaSuna 是 Kortix AI 开源的开源版 Manus——一个端到端的通用型 Agent 平台能够自主完成数据分析、网页爬取、报告生成、办公自动化等复杂任务。本文从产品形态、源码结构、技术架构、适用场景四个维度做一次完整拆解重点剖析其 Sandbox 隔离、Redis 流式总线、Supabase 数据中心三大设计。1. 产品形态及效果1.1 形态上很像 ManusSuna 的产品形态可以直接对标 Manus对话式任务下发用户用自然语言描述任务Suna 自主规划、执行、产出结果多模态产出可以输出文本报告、Excel、图表、网页截图甚至直接操作浏览器完整的 Agent 工具集内置浏览器自动化、代码执行、文件系统、API 调用、数据库查询等十余类工具1.2 实际体验很慢外网中间件 任务多公开 Demo 的体验比单轮 LLM 慢一个数量级原因有两层任务复杂度一个调研 生成报告任务往往要 20~80 次 LLM 调用 多次工具调用串行执行天然就慢。依赖外网中间件Suna 的 Sandbox 跑在 Daytona 云沙箱上浏览器自动化用 Browserbase对象存储用 Supabase Cloud国内访问这些海外服务有额外延迟。工程启示自部署时要把这些海外中间件换成国内/自建服务如 Daytona → 自建 Docker、Supabase → 自建 Postgres MinIO否则生产体验上不去。2. 源码结构与部署流程2.1 代码结构suna/ ├── backend/ # 后端服务Python / FastAPI │ ├── agents/ # Agent 主循环、Prompt、工具集 │ │ └── tools/ # 浏览器、代码、文件、API 等工具实现 │ ├── api/ # FastAPI 路由 │ └── ... ├── frontend/ # 前端应用Next.js / React / TailwindCSS ├── docs/ # 文档与架构图 ├── README.md └── docker-compose.yml # 一键起 Supabase Redis 后端 前端2.2 部署流程自托管git clone https://github.com/kortix-ai/suna cd suna cp .env.example .env # 填 OpenAI / Supabase / Redis / Daytona 密钥 docker compose up -d # 起所有服务需要的核心外部依赖LLM APIOpenAI / Anthropic或用 LiteLLM 接国内模型Supabase用作认证、Postgres、对象存储可自建Redis流式响应缓冲必须Daytona代码沙箱可换成自建 Docker2.3 源码要点后端 APIFastAPI 实现负责业务逻辑、Agent 调度、与 LLM/Supabase/Redis/Daytona 等服务集成。所有 Agent 执行都从这里的/agent/execute端点发起。前端Next.js 实现提供聊天界面、仪表盘、文件管理、浏览器远程查看等交互能力通过 SSE/WS 订阅后端流式推送。Agent Docker / Daytona每个智能体都跑在独立的容器中支持浏览器自动化、代码解释、文件系统访问。这是 Suna 区别于普通 Agent 框架的核心。Supabase负责用户认证GoTrue、数据存储Postgres、会话管理、文件存储S3 兼容、行为分析analytics。3. 技术架构3.1 整体架构图┌────────────┐ ┌─────────────┐ ┌────────────────┐ │ Frontend │◄───►│ Backend │◄───►│ LLM API │ │ (Next.js) │ SSE │ (FastAPI) │ │ (OpenAI/Claude)│ └────────────┘ └─────┬───────┘ └────────────────┘ │ ┌────────────┼────────────┬──────────────┐ │ │ │ │ ▼ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ Redis │ │Supabase │ │ Daytona │ │ Browser │ │ (Stream)│ │(Data/Auth)│ (Sandbox)│ │base/CDP │ └─────────┘ └─────────┘ └─────────┘ └─────────┘3.2 技术特点Suna 的设计有几个值得深挖的点3.2.1 SandboxDaytona 容器隔离每个 Agent 任务都会拉起一个独立的 Docker 容器通过 Daytona SDK 调度实现Agent 之间的隔离A 任务的代码不会污染 B 任务文件系统、环境变量完全隔离效果的稳定浏览器自动化、依赖安装都在沙箱内宿主机不被污染资源限额单任务 CPU/内存/网络可限制避免恶意任务拖垮宿主安全用户提交的代码、Prompt 注入诱导执行的代码都跑在沙箱里攻击面被收窄# 简化的沙箱启动流程伪代码 from daytona_sdk import Daytona ​ daytona Daytona() sandbox daytona.create() # 起一个隔离容器 sandbox.exec(pip install pandas) # 在沙箱里装包 result sandbox.exec(python analysis.py) # 在沙箱里执行 daytona.remove(sandbox) # 任务结束销毁生产建议Daytona 是商业云服务自部署可以替换成自建 Docker hostdocker-in-docker 或 Kubernetes Job核心是把Agent 执行环境和主服务做物理隔离。3.2.2 Redis 作为流式响应缓冲这是 Suna 最值得借鉴的设计——LLM 流式输出不直接推给前端而是先写 Redis Stream前端再从 Redis 读。# 写入端推理进程 for chunk in llm.stream(messages): redis.xadd(fagent_run:{run_id}, {token: chunk}) ​ # 读取端推送进程 / SSE 端点 last_id request_last_id or 0 while True: entries redis.xread({fagent_run:{run_id}: last_id}, block1000) for entry in entries: yield entry.token last_id entry.id3.2.3 Supabase 作为数据中心Supabase 在 Suna 里一身多职对个人开发者特别友好一个服务搞定认证 数据库 存储GoTrue邮箱/OAuth 登录Postgres用户、会话、消息、Agent run、文件元数据Storage上传的文档、Agent 产出物报告、Excel、截图Realtime可选的实时订阅取舍Supabase Cloud 免费档对个人项目够用但企业生产建议自建 Postgres MinIO避免 vendor lock-in。4. Redis 作为流式响应与推送中间件的利弊分析这一节单独展开因为这个设计是 Suna 区别于直接用 OpenAI SDK 流式的关键也是企业级 Agent 必然会遇到的架构决策。4.1 优点4.1.1 解耦模型推理与前端消费推理和前端消费完全解耦支持异步、分布式运行前端可随时连接 / 断开 / 重连流式接口。支持多前端 / 多客户端同时订阅同一个agent_run的流式输出手机 网页同步看到一份回复。4.1.2 容错与重连能力前端断线、刷新、网络抖动时可重新连接Redis 保留历史响应前端不会丢失消息。支持断点续传前端只需记录上次消费的 indexStream ID重连后从该 ID 续读。4.1.3 多实例 / 分布式支持多个后端实例可通过 Redis 共享流式数据天然支持横向扩展和高可用。推理进程和推送进程可分布在不同机器 / 容器——推理跑在 GPU 机器推送跑在普通 Web 机器。4.1.4 统一流式通道不管底层用什么大模型OpenAI / Claude / 本地模型都可统一用 Redis 作为流式总线前端实现不变。便于后续接入多种模型、工具型响应如代码执行进度、浏览器操作日志、混合流式输出等复杂场景。4.1.5 支持中断、控制信号通过 Redis 控制通道灵活中断推理、通知前端增强交互体验。例如用户点停止后端读到一个 cancel 标志就 break 出流式循环。4.1.6 历史数据可追溯Redis 保留所有响应便于后续查询、调试、回放、分析。一个 agent_run 的全流程可以完整重放。4.2 缺点4.2.1 增加系统复杂度需维护 Redis 服务涉及连接、订阅、消息管理等开发和运维成本提升。需处理 Redis 的持久化、容量、过期策略等问题Stream 默认不裁剪要配MAXLEN。4.2.2 引入延迟每条流式响应先写入 Redis再由 stream 接口读出推送前端比直接转发多一步增加微小延迟通常在毫秒级可忽略。4.2.3 内存消耗Redis 作为内存数据库所有流式响应暂存于内存。长文本 / 高并发 / 大批量推理时内存压力大。缓解策略XADD ... MAXLEN ~ 10000控制单 stream 长度冷数据落 Postgres。4.2.4 一致性与幂等性处理需保证消息不会重复推送、不会丢失断点续传场景下消息索引和消费状态管理更复杂。推荐Stream 自带的消费组Consumer Group ACK 机制。4.2.5 对流式模型原生特性利用有限某些大模型流式接口有特殊中间 token 事件、速率控制、心跳等特性经过 Redis 中转后可能无法 100% 还原原生体验如 Claude 的message_delta中的stop_reason。5. 适用场景直接使用或二次开发5.1 何时选 Suna适合在以下场景直接使用或基于源码二次开发安全要求高每个智能体之间不会互相干扰Sandbox 隔离到位并发要求高Redis 多实例架构很容易做分布式扩展需要本地优先 数据自主开源可完全自托管数据不出企业5.2 适合的业务场景5.2.1 智能信息检索与数据分析市场 / 竞品分析自动收集、整理和分析行业、竞品信息生成报告。舆情监控与分析抓取论坛、社交媒体、新闻等公开数据聚类、总结用户反馈和市场动态。科学文献 / 专利 / 政策检索自动查找、对比、总结学术论文、专利、政策文件等。5.2.2 自动化办公与文档处理报告自动生成根据输入需求自动生成市场、财务、技术等各类报告。表格 / 文档自动处理批量生成、整理、分析 Excel、Word、PDF 等文件。邮件 / 通知自动撰写与发送根据业务流程自动生成并发送邮件、通知等。5.2.3 数据抓取与集成网站 / 平台数据抓取自动化爬取公开网站、API 数据支持多平台集成。API 聚合与自动化调用集成第三方 API如 LinkedIn、Amazon、金融数据等实现自动化业务流程。5.2.4 智能助手与对话系统企业内部智能助手为员工提供知识问答、流程自动化、数据查询等服务。客户支持机器人自动应答客户问题、收集需求、分发工单等。5.2.5 研发与创新AI 工具链集成作为 AI 研发的底座集成多种 LLM、自动化工具快速搭建原型。定制化智能体开发根据行业需求开发专属智能体扩展工具集和业务逻辑。5.3 二次开发建议5.3.1 模块化扩展利用backend/agent/tools/目录可以方便地开发和集成新的工具如自定义爬虫、API 调用、数据处理等。前后端分离便于替换 UI 或对接自有系统。5.3.2 安全与合规生产环境建议加强沙箱隔离、权限控制和日志审计防止数据泄露和越权操作。敏感数据存储和传输建议加密遵循相关法规如 GDPR、个保法。5.3.3 多租户与权限管理如果面向多企业 / 多团队建议扩展用户、角色、权限体系支持多租户隔离。Supabase 的 RLSRow-Level Security天然支持多租户。5.3.4 高可用与扩展性后端可容器化部署结合云服务如 Supabase、Redis 云服务实现弹性扩展。前端可独立部署支持自定义品牌和界面。5.3.5 LLM / 工具适配可根据业务需求切换或集成不同的 LLM如私有大模型、本地模型等。推荐用 LiteLLM 做模型层抽象。工具层支持快速适配新业务场景。5.3.6 自动化与流程编排可结合工作流引擎如 Temporal、Prefect实现更复杂的自动化任务编排和多步操作补足 Suna 偏自由 Agent而弱强一致工作流的短板。6. 一句话总结Suna 是一个工程完成度很高的开源通用 Agent 平台。它的工程价值在于三个抽象Sandbox隔离执行、Redis Stream解耦流式、Supabase一体化数据。二次开发时把这三块换成自建基础设施就能落地为企业级生产系统。