Appearance
微服务设计
本页整理旧 docs/MICROSERVICES_DESIGN.md 的核心结论，用来说明 SoulBrowser 如果继续拆分服务，应该沿什么边界做，而不是把现状误解成已经完全微服务化。
当前状态
项目现在仍然以 monorepo + workspace 为主，核心运行时集中在 soulbrowser-kernel。
也就是说：
- 代码是模块化的
- 运行时仍偏单体内核
- 很多未来的服务边界已经在 crate 层先出现
为什么要考虑微服务
旧设计里提出拆分的原因主要有三个：
- 认证、计费、任务执行、浏览器运行的扩缩容特征不同
- 浏览器执行链路对资源和安全隔离要求更高
- 长期看需要让不同能力独立部署和演进
推荐拆分边界
API / Gateway
负责：
- 统一 HTTP 入口
- 认证接入
- 请求转发
- 外部协议适配
Runtime / Agent Service
负责：
- session 与 task 生命周期
- agent loop / planner
- tool orchestration
Browser Runtime
负责：
- CDP 连接
- 本地桥接
- stealth / anti-detection
- 浏览器实例管理
Product Services
包括但不限于：
- auth
- billing
- memory / conversation context
- timeline / analytics
不应该过早拆的部分
以下部分更适合先保持在 workspace 内部模块化，而不是立刻拆远程服务：
- perception 子模块
- tool primitives
- 状态格式化和 prompt 组装
- 一些强依赖本地类型系统的基础设施层
原因是这些部分跨模块调用非常频繁，过早网络化会显著增加复杂度。
迁移策略
更合理的顺序是：
- 先在 crate 层明确边界
- 再把接口抽成 trait / contract
- 最后才选择是否独立进程部署
所以微服务设计文档最重要的价值，不是“今天就拆”，而是帮助我们避免把边界继续写乱。
适合继续保留的工程做法
- monorepo 统一管理类型和协议
- 在 docs 中先定义服务责任，而不是先定义容器编排
- 对外契约优先走稳定 API，而不是内部结构体直接外泄