从 LobeChat 到 LobeHub：几个 AI 助手，终于有了共同的工作页

让一个 AI 查资料，另一个写文案，第三个挑问题，看起来像一支小团队。真正做起来，却很可能是你夹在中间复制粘贴：研究结论搬到写作窗口，初稿再搬到审稿窗口，修改后又得重新解释背景。

原来的 LobeChat 仓库现在已重定向为 LobeHub，当前项目把 Agent Groups、Pages 和项目组织放到更重要的位置。它想解决的，是多助手之间如何围绕同一项工作产生可继续修改的内容，而不只是给同一个聊天框换几套角色提示词。当前官方仓库

协作要有一个共同的产物

LobeHub 的官方说明中，Pages 用来让多个助手在共享上下文中撰写和修改内容，Agent Groups 则组织协作。把这两项放在一起看，比单独说“支持多 Agent”更容易理解。

以准备一份产品介绍作教学情境：资料助手整理官方事实，文案助手把信息组织成读者能读的稿子，审稿助手指出缺证或承诺过度的地方。若各自只吐出一段聊天回复，仍然需要人拼接；共同页面提供的是一个持续修改的对象，让意见更容易落回同一份稿件。

这不是说角色越多就越可靠。同一个错误前提传给三个助手，也可能得到三个口气不同的错误答案。分工应当对应不同检查职责，例如“找原始依据”和“检查标题有没有兑现”，而不是仅仅把一个大任务复制三遍。

官方项目还列出 Project、Workspace、Schedule 与 Personal Memory 等能力。项目组织当前任务，记忆则涉及跨任务保留的个人信息和偏好；两者不宜混为一谈。临时客户要求应跟着项目走，长期写作偏好才可能适合放进个人记忆。

LobeHub 把记忆描述为结构化且可编辑。对用户的实际意义，是有机会检查助手究竟记住了什么，而不是把一切都交给不可见的聊天历史。记错的偏好如果无法被发现，长期使用反而容易不断重复同一种不合适的回答。能力说明

Schedule 能把任务安排到某个时间运行，但运行完成和工作完成并不是同一回事。准备每日资料时，定时搜集和整理可以成为前半段，最终是否采用、是否对外发布，仍应由任务里的检查安排决定。

模型、工具权限和运行方式会影响真实可用的能力，也会带来调用成本。当前仓库提供自托管路线，但并不意味着所有模型推理免费或留在本地。LobeHub 使用社区许可证，对基于它开发与分发衍生作品等商业用途有附加条件，不能当作标准 Apache 2.0 项目直接概括。许可原文

对经常在多个助手之间手工搬运上下文的人，值得关注的是共同页面和明确分工能否减少这段交接，而不是页面里能同时摆下多少个 AI 头像。