嵌套深度需要上限
别名: 任务栈不能无限深 · 嵌套层数封顶 · dialogue stack depth
概念解释
叫车挂起去问天气，天气没答完又要给妈妈发短信，短信写到一半再问「二加二」。每一层单独看都合理，叠在一起双方都不再能回答「现在在办哪一件」。嵌套深度上限（nesting-depth cap）给任务栈一个硬顶：超过就拒绝再压入，或把最外层收成草稿，而不是来者不拒。上限保护的是可跟踪性，不是扫兴。
机制
每一层嵌套都要在工作记忆里留一份「括号还没闭合」的标记，还要在系统状态里留一份父任务的指针。人大约能稳住一层括号，两层开始丢哪一层在等；系统可以记很多层，但用户跟不上的栈对用户等于随机。深度还会放大恢复成本：从第三层弹回来，要连续给出两个接头，任何一个接头丢了，中间那层就成为幽灵任务——还占着状态，却再也走不到。允许无限压栈的产品通常不是真的在维护栈，而是每次插入都覆盖，深度只在话术里存在。硬顶逼设计者选择：新请求是换掉当前层、拒绝、还是把当前层提交成半成品。没有顶，选择被推迟到用户已经迷路的那一拍。
怎么研究
用 Wizard-of-Oz 强制深度：同一主任务上插入 1、2、3 层互不相关的短任务，每层都完成后再按设计弹回。因变量：用户能否说出当前正在办的那一层、弹回时走错层的次数、完成主任务的比例。自变量包括每层的时长、层与层是否同域（都是查询对查询加控制）。
日志里给每个会话维护一个推断栈深，看完成率和「现在在干什么」类澄清随深度的变化。实验室若允许被试看任务清单，测到的是外部记忆下的深度，不是无屏对话里的深度。
边界
专家在固定工作流里使用的「查一下再回来」可能把两层用成习惯，上限可以略松，但第三层仍应触发确认「要先放下叫车吗」。新层若只是当前任务的子步骤（叫车里问「公司在哪」），那是槽的细化，不应计入嵌套深度。无屏设备上深度成本更高，上限应比有屏更严——屏能显示栈，耳朵不能。把上限做成「系统不支持多任务」会误伤一层合法插入；顶要设在二，而不是设在零。
怎么落地
- 任务栈写死最大深度（建议 2：一层主任务加一层插入）。第三次插入到来时，先问要放下哪一层，不要默默压入。
- 拒绝压入时点名已经挂着的任务，让用户做替换而不是猜系统在办哪件。
- 深度一旦到顶，恢复路径只允许逐层弹出，禁止从第三层直接跳回第一层而把第二层留成幽灵。
- 验证：主任务未闭合时连续插入两个新技能，再插第三个。第三个若被静默接受、或弹回时跳过了中间层，上限没有在工作。