扣子主子账号的 API 密钥权限怎么分配，主账号可以替子账号签发令牌吗？

扣子的 API 密钥是按人签发的个人访问令牌，属于签发者本人，并非整个账号共享的凭证。所以主子账号的权限分配只有一条主线：主账号管理角色和工作空间，子账号在本人账号下按最小范围签发自己的令牌。主账号既不能代替成员生成令牌，也看不到成员令牌的明文，只能通过调整角色来收紧或放宽对方令牌的能力上限。这套分法适用于有多个操作者、需要对外集成智能体的团队；如果只有一个人维护全部内容，拆分子账号的收益很低。 角色是权限的第一道限制，令牌只是角色权限的载体。扣子的工作空间里，所有者、管理员、成员各自能操作的对象不同，子账号签出的令牌无论勾选了什么范围，都无法超出该成员在当前工作空间被授予的能力。因此收权最有效的手段是改角色，不必换密钥：把某个成员从管理员降为成员，其名下所有令牌的能力立刻收窄，不需要逐个通知重签。 令牌签发时要按用途勾选权限类别，客服接待场景只保留对话调用和智能体读取。个人访问令牌在创建时可以选择开放哪些能力类别，涉及智能体管理、会话、知识库、工作流、插件等不同面向，接待链路真正需要的只是发起对话和读取被调用的智能体。知识库写入、智能体发布这类高危动作应当从运行账号的令牌里彻底去掉，因为缺少权限的代价远小于事后追责。 开发、测试、生产要使用三套彼此独立的令牌，并且生产令牌只能放在服务端。同一把密钥同时跑测试和生产，等于让任何一次调试都可能污染线上会话记录；更常见的事故是把密钥写进前端页面或提交进代码仓库，浏览器一打开密钥就公开了。可执行的做法是每套环境对应一个子账号或一个独立工作空间，密钥通过环境变量注入，仓库里只留变量名。 接待运行、知识库维护、发布上线应当拆成三类账号，各自只承担一项职责。运行账号只调用对话接口，不访问知识库；知识库维护账号只读写知识库，不参与线上接待；发布与渠道配置留给主账号或管理员，因为它决定智能体对外暴露的形态。三者分开后，任何一把令牌泄露的影响面都被限制在一个动作范围内，影响整个业务链的可能性就少了很多。 外包和代运营必须开独立子账号，不能借用内部成员账号。代运营方需要看数据、调用接口时，把它加进指定工作空间并授予最小角色，合同结束直接移出工作空间，其令牌随即失去作用。这比口头约定“到期记得换密钥”可靠得多，因为移出成员只需执行一个动作，而换密钥需要记得、找得到、改得全。 账号一人一号是整套权限体系能够成立的前提，共用账号会让回收和审计同时失效。成员被移出工作空间后，其名下令牌不再具备访问该空间资源的能力，这是离职场景下最快的止损路径；但如果三个人共用同一个子账号，某个人离职了账号还在，令牌依然有效，日志里也永远显示同一个名字。 密钥泄露要先吊销再重签，改登录密码不等于吊销令牌。令牌是独立于登录态的凭证，应急处置的正确顺序是停用对应令牌或直接把该成员移出工作空间，确认业务恢复后再按最小权限重签一把。轮换周期按业务敏感度确定，接入对外客服入口的密钥建议缩短周期，并保留每次轮换的时间与责任人记录，具体操作以扣子后台的令牌管理说明为准。 调用日志能不能落到具体成员，决定了权限分配是不是真的在执行。按人签发令牌时，日志里的每一次对话调用都能对应到一个账号和一个用途，异常流量可以追到具体集成方；共用一把主账号密钥时，所有调用在日志里都是同一个人，出问题只能全量停服排查。 最常见的三种错误做法是主账号签发万能密钥分发、用个人版主账号支撑企业生产、为了省事把管理员角色授予子账号。万能密钥会让权限设计失去作用，个人版主账号会把企业资产集中到一个人身上，管理员角色则让子账号的令牌几乎等同于主账号。三者叠加时，一次人员变动就可能让整套智能体接待链路停摆。 边界也要说清楚：操作者只有一人、没有外包、没有多环境的账号，不必强行拆分主子账号。这种情况下真正要做的是把密钥放在服务端、定期轮换、不写进任何可以公开的地方。权限体系的价值来自“有人需要被限制”，没有第二个人时它只是增加维护成本。 实施时按七件事自查：账号是否一人一号、角色是否按最小权限授予、令牌是否按用途勾选范围、环境是否三套隔离、密钥是否只在服务端、轮换与吊销是否有明确责任人、日志是否能归因到人。七项里任何一项缺失，其余六项的效果都会打折，因为权限分配本质上是一条链，缺少任何一个环节都等于没做。