总体架构与职责边界

从四层职责理解系统

蜂巢采用模块化单体控制面、独立宿主管理服务、员工独占运行环境和可替换智能体的组合。当前面向单企业、单Linux节点，重点是让身份、任务、文件和业务访问有清楚的归属，不把首版部署建立在微服务集群或高可用假设上。

层次	主要组件	负责什么
访问层	员工工作台、管理员控制台	分别提供工作与管理入口，展示过程和状态
控制与数据层	Core、PostgreSQL、对象存储、Model Gateway	维护身份和任务，保存记录与版本，连接模型上游
宿主编排层	Runtime Manager、Docker Engine	按固定规则管理员工容器、目录、配额和执行进程
员工执行层	Workspace Runtime、Hive Pi或OpenCode、Skill	实际读写文件、运行代码、调用模型与业务工具

Core中的账号、任务、资源和备份等模块共用关系数据库，使需要一起改变的状态能在本地事务中提交。操作宿主机的职责由Runtime Manager承担；员工代码在自己的运行环境中执行，不能把任意宿主命令交给控制面运行。

员工提交消息后，Core创建本轮任务，确认工作空间配置可用，再交给运行环境中的智能体。智能体需要推理时，通过Model Gateway访问模型；需要业务数据时，通过已获准工具或脚本访问业务系统。

Model Gateway负责模型身份、固定路由、调用事实和预算检查，不代理企业业务HTTP请求。业务网关核验蜂巢提供的短期员工身份，由业务方关联自己的用户并判断权限。面板也可以在浏览器中直接访问业务API，不需要先启动聊天或员工容器。

PostgreSQL保存账号、关系、任务状态、事件和平台审计。员工持久目录保存工作文件、个人配置、依赖与技能。S3兼容对象存储保存不可变资源包、加密备份和导出。运行中的进程与临时认证另外管理，不把所有状态混在一份容器文件系统中。

这种划分意味着数据库事务无法同时覆盖文件、容器和外部业务。上传资源、安装Skill或恢复资产时，需要核对版本、摘要和操作阶段；超时不等于外部动作一定没有发生。

一名员工长期拥有一份工作空间，可以建立多段对话。每次发送消息创建一轮任务；任务结束后，文件和可恢复的成功会话状态继续保留。同一员工的对话共享文件，并行任务也不会因此获得第二套独立工作空间。

执行细节见任务生命周期，文件保存规则见持久工作空间。当前部署与隔离仍有明确限制，应结合安全边界阅读，不能把架构图直接当作生产验收结论。