一句话定义：子智能体授权（Subagent Authorization）是指主智能体把任务拆给子智能体时，系统依据这个子智能体声明的能力（Agent Skill），自动推导出它能调用哪些工具、参数能取到什么范围、能访问哪些数据，并把权限收窄到刚好够用。
从声明反推权限
Agent Skill 是声明式的：你写的不是“该怎么做”，而是“这个角色需要什么能力”。比如一个“周报汇总”技能声明了三件事：读团队周报文档（只读）、读日历忙闲信息（只读）、把摘要发到指定频道（可写，但只能是 #team-weekly）。系统读这份声明，就能反推出它需要文档读取、日历忙闲、消息发送三个工具；发送工具的频道参数只能是那一个固定值，不能是任意字符串；数据边界则是周报目录及其子目录。
打个比方，这像给外包人员办门禁卡。不是先发一张万能卡再让保安盯着，而是合同里写清“需要进 3 楼会议室和档案室”，行政据此只开通这两扇门，档案室还只能看不能改。声明是源头，门禁是推导出来的结果。
与相邻概念的分工
| 维度 | 子智能体授权 | 逐次审批弹窗 | AI 词典：智能体最小权限">智能体最小权限原则 |
|---|---|---|---|
| 是什么 | 机制与配置 | 运行时交互 | 设计原则 |
| 何时起作用 | 派发任务之前 | 每次动作发生时 | 设计与评审阶段 |
| 回答的问题 | 权限从哪来、边界在哪 | 例外情况由谁拍板 | 到底该不该给 |
| 典型失效 | 声明写得太宽 | 弹窗疲劳 | 停留在口头上 |
最小权限原则（Least Privilege）是目标，子智能体授权是把它变成可执行的机制；逐次审批则是运行时兜底。审批的软肋是疲劳：一天弹两百次确认，人就会闭眼点“允许”。所以合理的分工是：静态推导把绝大多数日常动作圈在安全区内静默放行，弹窗只留给越界行为和高危操作，比如写生产库、对外发邮件、产生费用。授权负责“平时不用问”，审批负责“例外必须问”。
权限怎么被推导和收窄
一是能力映射：声明里的能力项对应到具体工具清单，没声明的工具一律不可见。二是参数收窄：声明中的约束变成参数白名单或枚举，发消息的频道、查询的时间跨度都被钉死。三是取交集：子智能体继承发起方的身份，但实际权限是“主智能体的权限”与“技能声明的需求”的交集，不是并集。四是单向递减：子智能体还能再派孙智能体，每往下一层只能取子集，不能扩权。五是随任务回收：权限绑定任务生命周期，任务结束即失效。
对从业者的意义
别把权限写成提示词里的一句“请不要删数据库”，那只是请求；写进声明并由系统强制执行（enforcement）才算数。声明写得越具体，推导出的权限越窄，需要弹窗的场景越少，自动化率反而越高。自查清单很朴素：每个技能是否列出了工具清单、参数范围、数据范围、是否需要人工确认。
对普通职场人来说，理想状态是两件事同时成立：AI 干活时你不必每次点确认，但它也确实动不了别的部门的数据。如果你发现某个助手能把文件发到公司外、能改客户记录，值得问一句：这个权限，是谁在声明里给的？
各平台对能力声明的字段与写法不尽相同，具体以官方页面为准。