文章摘要
未来AI助手的发展方向正从目前不可枚举的多会话体验,转向可枚举的单助手或多助手模式,这一趋势非常明确。核心的划分在于,究竟是采用单个助手,还是多个可明确区分的助手,而在这个表面选择之下,底层架构还有诸

未来AI助手的发展方向正从目前不可枚举的多会话体验,转向可枚举的单助手或多助手模式,这一趋势非常明确。

核心的划分在于,究竟是采用单个助手,还是多个可明确区分的助手,而在这个表面选择之下,底层架构还有诸多细节需要权衡。

从用户的使用视角来看,生活场景更适合单个助手,而工作场景则需要多个助手。值得注意的是,工作场景中的多个助手并非服务于单个员工,而是整个团队共享;如果只是服务于某一位员工,那本质上还是单个助手。未来工作场景里,不会是每位员工都拥有专属的AI助手,而是采用共享模式,类似团队中的小组长,下属有不同分工的成员,员工可跨组协作,助手也按角色划分职责,权限有明确分配,同时支持跨角色协作。

为什么工作场景需要多助手模式?主要有四个原因:

第一,并行任务处理需求。单个助手很难同时处理多项任务,生活中这类需求不多,但工作中却很常见。虽然有人提出超级助手加多个子助手的架构,但子助手的任务管理会成为问题;若像某些产品那样在不同频道拆分多个会话,又会偏离高效管理的初衷。采用可枚举的多个助手,既能让用户注意力更集中,又能让任务按角色天然划分,用户记住角色职责比记住具体任务要容易得多。

第二,上下文复杂度差异。工作场景的上下文复杂度远高于生活场景,生活中核心上下文就是用户自身,足够了解自己就能完成大部分任务;但工作场景涉及团队、项目、业务流程等多方面信息,上下文复杂度大幅提升。

第三,严谨性要求不同。生活场景不需要太高的严谨性,而工作场景需要多方复核,这就要求采用多助手模式,甚至需要不同上下文的助手互相核验,确保结果准确。

第四,权限分级需求。如果一家公司只有一个助手,显然无法满足不同部门、项目的需求;但如果每位员工都有专属助手,助手的能力会被员工个人的权限和生产力限制,无法发挥更大价值。

因此,工作场景更合理的模式是“助手团队”:拥有多个助手,每个助手有不同权限、特定上下文,并且能互相核验。这些助手不属于单个员工,而是属于整个公司。

人和助手之间可以相互协作,每位员工都能向任何助手发出指令、询问问题、进行沟通。在这种模式下,人和助手几乎是平等的,人可以把控关键环节,甚至助手也能带领团队,这都是完全可能的。

生活场景不需要这种复杂的多助手模式,因为所有权限都由用户自己把控,也不需要多方审核,单个助手模式就足够;而工作场景目前还没有完全贴合的模式,现有产品如Grok助手和Claude Tag接近,但也有不足。Claude可以脱离具体用户,在整个组织的上下文中发挥作用,所有人都能在同一个频道中使用它,但它没有将上下文明确对应到具体的助手角色;而Grok助手虽然明确了角色,但没有纳入公司组织的多团队协作上下文,即使它能连接到协作工具,别人@的还是属于个人的助手角色,而非团队的公有角色,代表的是个人而非团队。

以上内容不代表本平台立场,仅供读者参考