夜雨聆风
最近在做AI智能体管理平台的权限体系，碰到一个看起来很小但讨论了很久的问题：角色应该管到哪一层？
两个选项摆在面前。选项A：角色决定"你能用哪个智能体"。选项B：角色决定"你进了这个智能体之后能用里面哪些技能"。
直觉上肯定选B。颗粒度越细越好嘛。管得越精确，权限越安全，越不会出事。
但你把这个设计交给业务管理员的时候，问题就来了。
"销售主管这个角色，在华东销售助手里，可以用客户洞察和报告生成两个技能，但不能用数据导出；销售代表可以用客户洞察，但不能用报告生成和数据导出。"
这只是一个智能体。你有10个。每个里面平均5个技能。3种角色。
管理员面对的不是一张权限表，是一张排列组合的地图。他不会填——不是因为他不聪明，是因为认知负担超出了正常人的处理能力。
我去看了业界的做法。Coze、Dify、微软Copilot Studio、Salesforce Einstein，思路出奇一致：角色只管到智能体可见性。进去之后，所有人能用的东西是一样的。
如果两类人确实需要不同的能力组合怎么办？答案是拆成两个智能体。"销售助手-主管版"挂5个技能，"销售助手-代表版"挂3个。角色A能看到主管版，角色B能看到代表版。完事。
这个做法的好处是：管理员的心智模型始终一致。他永远只需要想一个问题——"这个人该用哪个助手"。不需要理解里面的技能组合、不需要关心工具依赖链、不需要配排列组合。
有人会说，这不是把问题转嫁了吗？万一智能体膨胀到很多个呢？
确实。但10个智能体的可见性管理，和10个智能体×5个技能×3个角色的交叉矩阵，完全不是一个量级。前者是线性增长，后者是指数增长。
而且真正需要精细控制的场景，远比你想象的少。大多数时候，一个智能体服务一类人、做一件事。只有极少数情况下会出现"一个智能体塞太多功能"的问题——这个问题本身就是产品设计不当的信号，应该用拆分来解决，而不是用更复杂的权限来兜。
我们最终的做法是：主线走"角色管智能体可见性"，如果确实拆不干净，留一个技能可见性开关作为高级选项，收在设置深处，不在主流程暴露。同时平台会在智能体配了太多技能时主动建议拆分。
做权限设计，最容易犯的错不是管少了——管少了可以加，代价可控。管多了才是真问题。你的管理员会用脚投票：要么随便配一通权当交差，要么根本不配等出了事再说。结果比不管还糟。
少管一层，反而管得住。这不是偷懒，是对管理成本的尊重。
本文是「AI产品手记」系列第1篇。下一篇：《做新权限体系，最值钱的东西不用重建》
