系统里的“角色”该怎么用

这篇论文把“角色”这个概念在不同信息系统里的用法，系统地梳理一遍。作者想解决的困惑是：今天你在权限控制里会看到“角色”，在多人协作软件里也会看到“角色”，在智能体系统、对象建模、流程设计里还是会看到“角色”。可问题是，这些地方都叫 role，它们说的到底是不是同一回事？

很多系统都在用“角色”这个词，经常只是借了个名字，没有真正把角色变成系统的底层机制。让系统设计者不再把“角色”当成一个方便贴标签的词，而是看清它在不同场景里到底承担什么功能。

这篇文章在问三个问题。第一，角色到底是什么。第二，角色在不同系统里到底扮演什么作用。第三，真想做“基于角色”的系统，设计者到底会得到哪些好处和麻烦。如果连“角色”这个东西都没想清楚，后面的权限、流程、协作、消息、职责，很容易全都搅在一起。

先把“角色”常见的几种用法分门别类。作者把它放进了几个大场景里看：对象建模、系统设计、智能体系统、角色访问控制、协作系统，以及社会心理学和管理学。这种分类提醒我们，角色不是单一物件，而是一种在不同领域里被反复借用的组织方法。角色不是“人是谁”，更像“这个人在当前情境下该怎么跟系统和别人发生关系”。协作场景里，它像一个工作壳，包住了一个人当前的责任和权利；在访问控制里，它更像一个统一发权限的中间层；在对象建模里，它像一个帮助描述对象“在特定上下文里扮演什么功能”的抽象工具。

不同领域都在谈角色，但它们关心的焦点其实不一样。对象建模里，角色更像一种“怎么看对象、怎么拆对象”的抽象工具；它帮助人们从某个视角描述对象的行为，不是把对象一次性说死。智能体系统里，角色偏向合作过程中的“接口”和“过程”两种属性。角色一方面规定一个智能体能提供什么服务、需要满足什么要求，另一方面也组织多个智能体的分工协同。

到了 RBAC，也就是角色访问控制，角色的味道又完全变了。在这里，角色最核心的任务是帮管理员省事。系统面对一大堆用户和资源时，逐个分权限会很累，就先把权限打包给角色，再把用户挂到角色上。虽然实用，作者也点出它的局限：这种角色更多是在处理“谁能访问什么”，而不是“谁该跟谁协作、怎么调整分工、怎么转移职责”。换句话说，RBAC 里的角色很强，但强在权限管理，不等于它已经把协作中的角色问题解决了。

论文指出，很多 CSCW 系统虽然也在提角色，但常常只是把它们当静态标签。系统里可能有“作者”“读者”“评论者”“管理员”这些名字，但名字背后缺少灵活的角色说明、调整、谈判和切换机制。用户虽然“有角色”，却未必真能靠角色把协作组织起来。就像系统只是给人发了工牌，却没把岗位职责、授权范围和交接机制写清楚。

作者最后总结出来的角色，不管在哪个领域都围着几件事转：定义边界，帮助分类，连接权利和责任，支持行为和互动，帮助组织关系，在复杂系统里起到减轻混乱、降低复杂度的作用。也就是说，角色最深层的价值是替系统回答“谁以什么身份、带着什么限制和能力、进入什么关系网络”这件事。

后半部分专门讲挑战和收益。收益很好理解：角色能帮人过滤无关信息，让系统更清楚地分配责任，让组织结构、权限结构、协作结构更容易被表达出来。但挑战也很硬：角色该怎么定义才不含糊？怎么存、怎么改、怎么复用？一个人同时扮演多个角色，冲突怎么管？系统想让角色更灵活，界面、消息、规则会不会变得太复杂？

所以，这篇文章给“基于角色的系统”泼了一盆很有价值的冷水。它告诉设计者真正的 role-based system，应该是从分析、设计到实现，都把角色当成一等公民，角色必须作为底层机制被定义、指定、构造和使用。

从今天来看，这篇综述把一个频繁使用、却总被混用的概念做了一次认真拆解。让人看清楚在不同系统里谈“角色”，是在谈不同层级的问题。有时是在谈视角，有时是在谈权限，有时是在谈职责，有时是在谈协作关系。如果这些层级不分清，系统设计就很容易自己绕自己。

作者简介：朱海滨，加拿大尼皮辛大学计算机科学教授，IEEE Fellow、AAIA Fellow，E-CARGO模型与Role-Based Collaboration（RBC，基于角色的协作）方法的重要创立学者，现任IEEE Systems, Man, and Cybernetics Society系统科学与工程副主席。主要研究方向包括软件工程、编程技术、协作技术与系统、基于角色的协作、自适应协作，聚焦多智能体系统、群体绩效优化、群体角色分配及E-CARGO模型应用等问题。

ORCID：0000-0003-1922-1631

DOI: 10.1109/TSMCC.2008.919168

已收藏 0

点赞 0