扣子主子账号的 API 密钥权限怎么分配，子账号能不能只拿到自己智能体的调用权？

扣子的 API 密钥本身没有独立于账号的权限开关，它的能力上限由密钥所属账号的角色决定，所以分配顺序是先用角色划定子账号能做什么，再按用途发放独立密钥，最后用工作空间和环境隔开；主账号密钥只保留给成员管理、配额调整和审计，不下发到业务侧。这个结论的前提是账号体系里存在主子账号与角色划分，如果只有一个登录账号，任何一把密钥都等价于账号所有者权限，只能靠流程和人工复核来保底。 把角色分清楚，比把密钥分清楚更重要。主账号或所有者负责成员增删、密钥创建与吊销、计费配额和日志审计，这类操作一个团队保留一个负责人即可；子账号按实际职能分成开发、运维、客服运营等角色，每个角色只保留完成本职工作所需的操作项。角色给多了，后面无论怎么设计密钥分级都会被绕过。 按用途把密钥切成三类，是成本最低的隔离办法。管理类密钥只用于成员、配额、渠道等账号级操作，留给主账号或一名管理员；开发调试类密钥发给开发者子账号，并限定在具体工作空间内；生产调用类密钥挂到服务账号名下，只用于对话接口调用和会话读取，不参与工作流编排、渠道发布和成员管理。 生产调用密钥不建议挂在具体员工名下。智能体一旦上线接待，密钥就变成基础设施，人员调岗或离职都会导致接待链路中断；做法是为每个上线的智能体建一个专属服务子账号，角色只给调用和日志查看，密钥托管在密钥管理服务里，由运维统一注入业务系统，员工只拿到封装后的服务地址。 工作空间是按业务线隔离最直接的手段。不同业务线、不同客户项目各自建独立空间，密钥只在所属空间内有效，A 业务的密钥就改不动 B 业务的智能体和知识库。多人协作的团队里，这一步能减少大部分误操作，也让后续权限回收有明确边界：项目结束整个空间停用，不用逐个排查密钥。 环境要分三套，密钥也要分三套。开发、预发、生产各用独立密钥，禁止跨环境复用；测试密钥只能连测试知识库和沙箱渠道，生产密钥只连正式对客渠道。把测试密钥接到生产知识库，最容易造成内部资料通过测试智能体外泄，而且日志里看不出异常，因为调用方本来就是合法账号。 密钥的生命周期要有明确节点：创建、分发、轮换、吊销。分发不走群聊、邮件正文和代码仓库明文，改用密钥管理服务或一次性交付；轮换按季度或按项目周期执行；人员离职、项目下线、密钥疑似泄露三种情况立即吊销并重建。吊销之后要同步更新调用方配置，否则第二天客服智能体直接掉线。 审计权限要归到主账号，不能分散给每个子账号。需要保留记录的信息至少包括密钥归属人、用途、创建时间、最近调用时间和调用量；在客服接待场景里，还要看会话调用失败率和异常来源。发现某把密钥的调用量突然放大，或出现在非约定来源，先停用再排查，不要等确认原因。 最常见的四个错误，后果都很直接。主账号密钥写进网页或小程序前端，等于把整个账号公开；多人共用一把密钥，出问题无法定位到人；只做调试的子账号被授予发布权限，测试内容可能直接上到对客渠道；测试智能体连着生产知识库，内部资料容易外泄。这四种情况里，前两种靠密钥分级解决，后两种靠角色和空间隔离解决。 客服接待场景的密钥可以再收窄。接待侧真正需要的只有对话调用、会话记录读取和知识库检索三项，不需要工作流编排、渠道发布和成员管理；客服运营子账号可以查看会话、维护知识库，但不具备创建密钥的权限，密钥由管理员按需代发。权限越窄，智能体回答出问题时的影响面越小。 实际执行时，一张权限矩阵就够了。行是角色，包括所有者、管理员、开发者、运维、客服运营；列是密钥类型、工作空间和环境。所有者和管理员持有管理类密钥，运维托管生产调用密钥，开发者只拿限定空间的开发密钥，客服运营不持有密钥。矩阵写进团队规范，新人入职按行开通，比口头约定可靠。 这套分配解决的是人和密钥的对应关系，解决不了智能体本身答得准不准。权限再细，知识库内容错、提示词写歪，接待质量照样上不去；反过来，权限混乱时，一次误删或一次泄露就可能让整个客服链路停摆。两者要分开投入，先保证密钥可追溯，再谈回复质量优化。