Technical note
认识HiveOS：让智能体在企业里持续工作
员工用AI整理出一份周报以后，往往还会遇到几件事：下周能不能复用这次的方法？同事能不能直接使用？每天要查的数据能不能做成一个页面？查询业务系统时，怎样沿用员工原有的权限？
这些问题连起来，就超出了一次对话或一段脚本的范围。文件、处理方法、工具、业务页面和员工身份，都需要有长期保存和配合工作的地方。
HiveOS，也就是蜂巢，是部署在单个企业内网中的员工数字分身平台。每名员工有自己的AI工作空间，对话连接文件、技能与业务系统，一次工作留下的成果和方法，可以成为下一次的起点。
员工使用工作台开展工作，管理员准备人员、模型、运行环境和企业能力，开发者负责连接业务接口。蜂巢把这些不同参与者的工作接起来，让员工既能用自然语言提出要求，也能逐渐积累自己的工具和业务页面。
从回答问题，到留下可以使用的成果
以整理工单周报为例，目标很具体：提供资料，说明统计目标，查看工具调用，核对结果，最后带走一份文件。
一轮任务可以读取表格、运行脚本、计算数据，再生成报告。文件保留在员工工作空间中，以后可以继续修改或作为另一项工作的输入。同一主题下可以继续对话，补充要求、纠正口径，直到成果满足需要。
这个过程把文字生成与程序执行连在一起。例如，模型理解“按状态汇总”的要求，Agent调用Python完成计算，再根据结果组织说明。模型负责理解与生成，运行环境负责执行程序，员工负责核对统计口径和业务结果。
本地Agent也可以做到这些。蜂巢接着处理的是：怎样把这样的环境交给企业里的多名员工，怎样分享方法，以及怎样接入企业已有的业务。
Skill留下方法，MCP连接工具
一次工作做好以后，脚本、模板和检查步骤都值得保留。Skill就是这些方法的载体：一份说明告诉智能体什么时候使用、输入是什么、按什么步骤处理，还可以附带代码和参考材料。
员工可以在技能广场中选择可用方法，把成功做法整理成个人Skill，也可以从技能市场安装同事共享的固定版本。企业提供的Skill由管理员维护和分配。
例如，一份周报Skill可以保存时间范围的确认方式、状态分类、缺失数据的处理办法和报告模板。下一周换一批资料，仍然沿用这套方法。共享出去的应该是可复用内容，客户原始数据、密码和私人记录需要先移除；安装固定版本也便于知道自己正在使用哪一份方法。
MCP解决另一类问题。它是一种让智能体发现和调用服务端工具的协议，适合把已有工具服务接进来。Skill可以说明怎样分析数据，MCP工具可以提供可查询的数据或能力，Shell和脚本则在员工环境中完成具体处理。
因此，企业可以继续使用已有的Markdown说明、Python或Node.js脚本和模板，也可以接入MCP服务，不必先把所有工作步骤改写成同一种平台专用工具。当前公开接入方案中的MCP面向远程只读服务，实际读取范围仍由服务和账号权限约束。
业务面板：把常做的事变成自己的页面
除了对话，员工还可以拥有自己的业务面板，并用聊天调整个人副本。
查工单列表、按条件筛选、查看处理进度，这些固定动作经常用页面更方便。业务面板把列表、筛选条件和按钮留在工作台中，员工不用每次都重新描述同样的查询。
企业可以提供统一面板，员工保存为个人副本以后，再让智能体调整列顺序、布局或展示内容，预览并保存。比如，客服更关心待跟进事项，可以把它放在前面；负责人更关心不同状态的数量，可以调整自己的展示方式。这里的例子用于说明定制方式，不代表这些页面已经在真实业务中验收。
这让智能体的成果多了一种形式：除了报告和脚本，还可以是一个以后反复打开的业务页面。已保存面板的正常打开不需要先启动模型或员工容器，页面由浏览器访问业务API。
个人副本改变的是前端页面和交互，不会自动创建独立后台服务，也不会因为改了按钮就取得更多业务权限。企业面板升级不直接覆盖个人副本，但业务API变化仍可能影响旧页面，需要相应维护。
数字分身代表谁，由谁决定能做什么
当智能体开始访问真实业务系统，员工身份就不能只是一段提示词。
蜂巢维护员工的平台身份，分别分配业务系统资格、Skill、MCP和面板。正式接入时，脚本或面板按需取得限定目标系统的短期员工身份，由业务网关在线核验。业务方再关联自己的业务账号，决定能读取哪些项目、修改哪些记录。
例如，同一份工单查询Skill可以给多名员工使用，实际返回的数据仍应由业务系统按各自身份与权限判断。共享方法不意味着共享一个高权限业务账号，复制一个面板也不会复制另一名员工的业务资格。
这种分工让蜂巢接入已有系统，而不把各种业务账号和权限规则重新搬进平台。它证明当前员工是谁，业务系统继续负责自己的角色、数据和操作授权；写入确认、重复请求处理及业务结果核验，也需要对应系统和接入方法负责。
持久工作空间，是这些能力共同的基础
方法、页面和文件要积累下来，Agent就需要一个可以持续使用的环境。这里可以借用“给每名员工的Agent配一台电脑”的比喻。
HiveOS的Docker方案为每名员工提供独占容器。容器是宿主Linux系统中经过隔离的执行环境，有自己的进程和文件系统视图，能够使用命令行、运行程序并管理依赖。一台服务器可以承载多个员工容器，它们共用宿主内核，并非每人独占一台物理机。
员工个人目录与容器系统层分开保存。项目、文件、个人Skill和项目依赖放在持久目录里，运行环境可以启停或重建，再把原目录挂载回来。容器系统层中的临时安装则可能需要重新准备。
同一员工的多个对话共用这套环境和个人文件。这样可以在不同任务间复用成果，也意味着一个对话覆盖或删除文件，会影响后续工作。新开对话用于分开主题，不能把它当成另一台隔离电脑。
个人记忆保存长期背景和偏好，工作规范提供企业要求，文件和Skill保存工作资产。它们共同帮助智能体接着做事，业务权限仍然需要实际授权。
这些能力怎样在架构中配合
图源：蜂巢。
左侧是两个不同入口。员工工作台用于对话、文件、技能和面板；管理员控制台维护人员、能力、模型和运行环境。两者进入Hive Core，由它管理平台身份、资源分配、任务状态和调度。PostgreSQL与对象存储保存平台记录和相应资产。
真正执行程序的是图中员工独占的运行环境。Hive Pi、OpenCode等执行引擎在里面组织任务，使用文件、Shell、Skill与MCP。Runtime Manager负责容器生命周期、挂载和执行进程等宿主管理操作，把这些管理权限留在专门服务中。
往右看，模型请求与业务请求分成两条路。模型请求经过Model Gateway，按企业配置选择上游路由，使用任务访问身份并记录调用用量。企业可以集中管理模型配置、预算和费用，而不把模型服务的长期API Key直接发给员工容器。
业务请求则访问企业业务系统，由业务方核验员工身份并决定权限。模型网关不代理所有业务请求，Core也不承担每一个业务动作的实现。这样的分工保留了Agent原生使用文件和代码的方式，同时为企业增加环境、身份和资源管理。
工作也可以从其他入口继续
工作方法稳定以后，可以把明确的周期性工作交给定时任务；配置好的消息渠道可以从常用消息软件提交工作，开放API则供其他程序创建任务、读取状态和结果。
这些入口进入同一套任务规则，继续使用相应员工的环境与能力。关闭浏览器不会自动取消已经提交的普通任务，员工可以稍后回来查看；定时执行也需要检查每次结果，不能因为保存了计划就认为以后都能成功。
这与单独在个人电脑上安装Agent的差别，主要体现在平台的组织方式：企业准备模型、运行环境和业务能力，员工在其中使用和定制工具，成果与方法按员工归属长期保存。容器是基础，Skill与MCP提供方法和工具，面板提供日常操作入口，身份机制把它们接回已有业务系统。
当前HiveOS仍面向单企业、单节点内网开发与受控验证，尚未生产就绪。内网部署也不保证模型本地运行；使用外部模型时，实际提交的内容仍会到达对应服务。文件持久化、备份和业务回滚分别处理，取消任务不会自动撤销已经发生的修改。