上一期《编排沉底》立过一个提法：把工作流自动化的岗位拆完之后，该拆机床——于是七件运行时原语（Workflow、Agent、CronCreate 族、ScheduleWakeup、Task 族、后台任务、EnterWorktree）逐段过了一遍堂。这份普查的口径是「编排」，所以清单里装的全是调度、委派、隔离、唤醒这类让机器多干活的原语。但本期回看，同样随宿主分发、同样每天被调用、同样没有任何仓库与星数的门原语，恰好落在普查视野之外：AskUserQuestion 与 EnterPlanMode/ExitPlanMode 干的不是让机器多干活，而是在干活的机器面前给人留一个座位。
为什么它们配得上独立开膛？三条线汇聚于此。部署线：四单兵与 azure 流水线管「怎么上去」，回滚真空期 lament 过「撤下来没人管」，而上升与撤退之间的每个决策点都靠门。CI 线：gh-fix-ci 的定位是「先给方案，用户明确批准后才动手」——修流水线的最后一米是一道批准门。监控线：canary 的 CRITICAL 告警把「立即调查/继续观察/回滚/判定误报」四选项递到人手里——存档已确认这菜单就是用 AskUserQuestion 搭的，但机床本身的说明书没人读过。多 Agent 线：commerce-agents 蓝图的验货第一题「agent 提议交易，人类确认门放行支付」——协作半径越大，门越重。四条线的末端都指向同一层，而这一层在装机普查、市场快照与本栏目存档里三处零记录。
flowchart TD
subgraph SK["Skill 层的手搓门"]
CAN["canary 四选项菜单"]
GHF["gh-fix-ci 显式批准"]
TM["threat-model 强制暂停"]
GAS["github-actions-skill 确认表"]
end
subgraph PR["运行时门原语层"]
AUA["AskUserQuestion 裁决门"]
EPM["EnterPlanMode 进门锁"]
XPM["ExitPlanMode 出门锁"]
end
subgraph IL["拦截层"]
PM["permission mode 用户选中"]
HK["hooks 拦截注入"]
end
CAN --> AUA
TM --> AUA
GHF --> EPM
GAS --> XPM
AUA --> PM
EPM --> PM
XPM --> PM
PM --> HK
这张图是本文的骨架：Skill 层的门是楼，原语层的门是门框，拦截层是承重墙。此前各期拆的都是楼——本期拆门框。
权重沿用本栏口径：功能 25%、设计 25%、实战 20%、上手 15%（越高越容易）、社区 15%。「社区」按 09-05 末排审计与编排沉底的先例替换为「维护确定性」——门原语随 harness 本体分发，无独立迭代路线，统一记五星。诚实声明：两个门原语在本会话均未被实际调用，实战分不是实测，而是「路过频率」推断——每个不可逆动作与每个非平凡实现都必然路过它们；描述里禁令条款的密度，是滥用频率的反证，也构成实战推断的旁证。
| 门 | 形态一句话 | 功能 | 设计 | 实战 | 上手 | 维护 | 加权 |
|---|---|---|---|---|---|---|---|
| AskUserQuestion | 把裁决做成结构化接口 | ★★★★★ | ★★★★★ | ★★★★½ | ★★★★★ | ★★★★★ | 4.90 |
| EnterPlanMode＋ExitPlanMode | 一扇门两把锁 | ★★★★½ | ★★★★★ | ★★★★½ | ★★★★½ | ★★★★★ | 4.70 |
| permission mode＋hooks（边注） | 没有描述的一层 | ★★★★ | ★★★½ | ★★★★½ | ★★★ | ★★★★★ | 3.98 |
对照行：编排沉底那期全场最高是 Agent 原语的 4.60——本期 AskUserQuestion 的 4.90 破了档，理由写在描述的访问量上：七原语里任何一件都是「有时才用」，裁决门是「只要有人就得用」。
描述的第一句不是教你怎么问，是教你怎么忍住不问：
Use this tool only when you are blocked on a decision that is genuinely the user's to make: one you cannot resolve from the request, the code, or sensible defaults.
三重资格线：请求里没有、代码里查不到、常识推不出——三条全过才有资格敲门。紧接着还有一条更狠的收尾禁令：
Reserve this for decisions where the user's answer changes what you do next — not for choices with a conventional default or facts you can verify in the codebase yourself. In those cases pick the obvious option, mention it in your response, and proceed.
把这段话翻译成运营语言：问是把成本转嫁给用户，能自己查而伸手问的每一次，都是违约。有惯例默认值的（用哪个日期格式）、仓库里可验证的（这个函数在哪定义）——模型该做的是「选显然项、说明一句、继续干活」。这条禁令反过来解释了门原语的存在形态：它必须稀缺，稀缺才值钱；一个逢事就问的 Agent，等于把裁决权廉价批发。
schema 层的约束密度是全运行时之最，每条背后站着一类真实的滥用：
描述里有一段罕见的跨工具管鸦条款：进计划模式走 EnterPlanMode，别拿裁决门凑合；而进了计划模式之后，裁决门只能用来在方案之间做选择——
Do NOT use this tool to ask "Is my plan ready?", "Should I proceed?", or otherwise reference "the plan" in questions — the user cannot see the plan until you call ExitPlanMode for approval.
为什么禁得这么具体？因为「计划好了吗」这个问题有一个特性：用户根本还没见过计划。拿一个用户看不见的东西去要批准，批准就是假的——这不是效率问题，是门禁的效力问题。裁决门与计划门在描述里互相点名、互不串岗，两份描述各写一遍同样的禁令——官方用重复来给边界上双保险，这个写法本身值得所有写「邻居件」的 Skill 作者抄。
计划门是一对：EnterPlanMode 管进，ExitPlanMode 管出。它服务的场景描述写得毫不含糊——非平凡实现任务，写代码之前先拿到人对方案的签收。七条「该用」清单（新功能、多种可行方案、改既有行为、架构决策、多文件改动、需求不清、用户偏好重要）与两类「该跳过」（单行修复类小事、纯研究任务——后者明令「用探索型子代理去」）把射程钉死。
This tool REQUIRES user approval - they must consent to entering plan mode.
微妙之处在这里：进门批准的不是任何具体方案，是「接下来我少干活多问你」这个工作模式本身。配套条款还有一句姿态级的 "If unsure whether to use it, err on the side of planning"——拿不准就先要批准，宁可多问不可先斩。对照 simplify 那句让位句，官方件的一致气质是：能力可以商量，边界不让商量。
ExitPlanMode 的机制有三处值得逐段看。其一，它不带方案内容——计划在计划文件里，工具只负责一个信号：「写完了，请审」。方案本体与批准动作分离，防止「批准的时候看到的和最终执行的不是同一份」。其二，描述里的互斥禁令与裁决门对称："Do NOT use AskUserQuestion to ask 'Is this plan okay?'... that's exactly what THIS tool does"——出门批准只有一条通道，不允许从侧门溜。其三，也是最值钱的一处——allowedPrompts 预授权：
Prompt-based permissions needed to implement the plan. These describe categories of actions rather than specific commands.
批准计划时可以一并申报实施所需的权限类别（跑测试、装依赖），用户点头一次，计划与执行手段同时放行。这里有整个门禁层最锋利的一条经济学：授权粒度与信息充分度挂钩。对照 fewer-permission-prompts——它扫历史记录生成的白名单永远只收 read-only，写类动作一概不进——同样是原语层的设计，为什么一个敢给「装依赖」放行、一个死守只读？差别在门前信息披露量：白名单是「没给你看任何东西就要授权」，计划批准是「你刚读完全文方案再授权」。看得越多，可预授权的越宽——门禁的松紧不是安全偏执，是信息不对称的定价。
把两把锁连起来看，一个反直觉的结构浮出来：
flowchart LR
T["非平凡任务进场"] --> IN["进门锁<br/>EnterPlanMode 要批准"]
IN --> EX["侦察与设计"]
EX --> Q{"需求仍有歧义？"}
Q -->|"是"| AUA["裁决门<br/>选项间选择"]
Q -->|"否"| W["计划落盘"]
AUA --> W
W --> OUT["出门锁<br/>ExitPlanMode 要批准"]
OUT -->|"附带类别预授权"| IM["实施"]
IM --> V["验收"]
进门要人点头，出门要人点头，唯独中间的侦察与设计——从头到尾翻代码库、定架构、写方案——是人最不在场的一段。这不是疏忽，是分工：人判断「值不值得做、往哪个方向做」（两次门锁），机器负担「怎么做的一切细节」（中段全程）。所谓人机协作的理想形状，在这扇门上写得很清楚——人出裁决，不出监工。
门禁层还有第三道闸，材料稀缺到只能作边注，而稀缺本身就是发现。权限侧的可用条款只有一句：工具运行在用户选定的权限模式之后，「a denied call means the user declined it — adjust, don't retry verbatim」——被拒的调用意味着用户否决，调整方案，不许原样重试。这一句是整个门禁层语义密度最高的一行：在普通工具语义里，调用失败是异常，异常的对偶是重试；在门语义里，拒绝不是失败，是答复。否决被从错误流里拿出来，编进了信息流——用户按一次拒绝键，等于投了一票，模型的工作是读票，不是再按一次门铃。
钩子侧同样只有一句：hooks 可能拦截工具调用，其输出按用户反馈对待。机器拦截的产物被规定成「代表人说话」——自动门的语义被锚定在人身上。对照 Skill 层：update-config 管把口头门禁固化成 settings.json 配置，fewer-permission-prompts 管扫历史给只读操作降噪减弹窗——那两件是拦截门的两个物业，本期边注的这两行字才是门本身。这一层为什么几乎不写描述？因为它不打算被商量：门禁的最终形态，是用户甚至不需要知道有门。
把存档里拆过的门逐一放回门框上，各就各位：canary 的四选项菜单，本就是 AskUserQuestion 的标准用例——回滚真空期 lament「菜单后面的路没人修」，本期补的是菜单这台机床的出厂说明书；security-threat-model 的「Pause and wait for user feedback before producing the final report」是裁决门的流程内嵌版；gh-fix-ci 的「explicit approval 后才动手」与 commerce-agents 的「人类确认门放行支付」是计划门精神在单件内的手搓复刻；sentry 的只读 token 门是拦截门在凭据层的投影。
四件里最值得单独说的是 github-actions-skill 的 ASCII 确认表——生成 deploy.yml 前先打印配置表请用户答「是/否」。它是没有门原语可用时的手搓门标本，摆在一起，手搓与原语的差距有三条：其一，答案形态——确认表收回「是」，参数对不上号还得人来对；裁决门收回结构化数据，选中项直接可用。其二，兜底——确认表之外用户想改端口，得重新走一轮问答；裁决门自动供给 Other，改哪项点哪项。其三，成本——确认表要消耗生成、打印、确认整整两轮对话；门原语一次调用、一次点选结账。Skill 层手搓门的存在价值因此改写：不是原语的竞品，是原语缺位时的应急建筑——而这些建筑至今还在被大量复制，说明门原语的存在感与其使用密度严重不成比例。
市场端照例对账，09-07 快照的读数几乎是为本期定制的一组对照组：openclaw ⭐389052，口号 "The AI that really does things"；hermes-agent ⭐242529，"The agent that grows with you"；opencode ⭐205245；ECC ⭐251278；PRAXIST ⭐6472，"Autonomous research system"。自主叙事包揽头部，门禁零供给——榜单在卖「不用问你」，而货架底下每一次扣款、每一次合并、每一次部署，仍在等某个人点头。自主是门面，门禁是地基。
工作流字面上唯一的新面孔是 diudiu-tech/delivery-harness（⭐1950，"AI harness reference implementation for on-demand delivery workflows"）——即时配送业务的工作流蓝图，与 commerce-agents 同形态：官方与准官方都在以「参考实现」卖工作流的骨，没有谁在卖工作流的闸。这不难解释：门原语随宿主免费分发，公共品没有 star，只有覆盖率。FrontierAgent（⭐1881，ReAct 框架）补齐对照组最后一格——框架卖的是「怎么让 Agent 行动」，没人卖「怎么让 Agent 停」；停的那部分，市场默认随宿主赠送。
两扇门随宿主分发，零安装；对照件照例给取回命令：
# 门原语：零安装，触发方式各一道
# 裁决门：模型在不可裁决处主动敲门，用户点选即答
# 计划门：说「先出方案再动手」，进门锁启动；批准计划即开门
# 市场对照件（正文均未核验，以仓库 README 为准）
git clone --depth 1 https://github.com/diudiu-tech/delivery-harness # 配送工作流蓝图
git clone --depth 1 https://github.com/ApodexAI/FrontierAgent # ReAct 行动框架
# 拦截门的两个物业（往期已拆，随宿主在册）
# update-config：把「以后每次都 X」写进 settings.json
# fewer-permission-prompts：扫历史给只读操作减弹窗
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。