# 逐次确认有一个盈亏平衡点 只有当被拦下的调用足够例外，值得人重新做一次决定时，逐次确认的成本才划算。一旦日常生产工作持续产生提示，这项控制就会让团队为同一个决定反复付费。盈亏平衡点通常比人们预计的低，因为点击是最便宜的部分。等待、阅读足够的上下文以信任请求，以及在中断后重新找回思路，才是主要成本。 有效的比较需要两本分开的账。一本记录操作人员的时间，另一本记录扩大授权窗口带来的安全后果。把二者混在一起，会得到诸如`一天十二个提示让人烦`或`生产环境必须每次都点确认`这样的坏答案。这两句话都没有说明提示是否改变了决定。下面的模型会给中断标价，但不会假装破坏性数据库命令与只读状态查询具有相同风险。 ## 计算一次确认的完整成本 一次确认的完整成本等于响应时间，再加上该提示实际造成的那部分中断恢复时间。请用秒，不要使用`摩擦很小`之类的模糊评级。定义以下数值： - `p`：每天出现的确认次数 - `t`：从提示出现到完成决定的响应秒数中位数 - `r`：恢复被中断任务所需秒数的中位数 - `q`：在专注工作期间到达的提示比例 - `d`：其个人提示次数包含在`p`中的开发者人数 如果`p`是每位开发者的次数，团队每日成本为： ```text per_use_seconds = p * d * (t + q * r) ``` 如果`p`已经统计整个团队的全部确认，则去掉`d`： ```text per_use_seconds = p * (t + q * r) ``` 这个区别能避免电子表格中最常见的错误：把团队总提示数再乘一次团队人数。请在每个输入旁写明单位。`8 prompts/person/day`和`48 prompts/team/day`可能描述的是同一个六人团队。 `t`应使用中位数，因为少量无人处理的提示会扭曲平均值。不过，不要隐藏这些未处理请求。把它们另行统计为失败工作。恢复时间要测到开发者重新开始上一项有意义的操作，而不是测到审批窗口关闭。开发者九秒内批准请求，随后用两分钟重新构建查询思路，付出的成本是129秒，不是九秒。 `q`项避免模型为任务之间处理的提示收取恢复成本。如果暂时无法测量，请分别用`q = 0.5`和`q = 1`算出范围。一个诚实的范围胜过建立在猜测上的精确数字。 ## 在人实际感受到的边界上计数 统计人必须做出的每个决定，不要统计每个API请求，也不要统计系统发出的每条通知。一张审批卡覆盖五次重试，就算一次确认。自动重试循环产生五张卡，即使底层操作在逻辑上属于一个任务，也要算五次确认。模型计算的是人的工作，所以单位必须与人的决策边界一致。 提示变得可以处理时就开始计时。一张卡已经出现，但必须打开终端才能看懂，它已经消耗响应时间。拒绝、过期提示和重复请求都占用注意力，必须计入。把从不要求人工介入的自动调用单独记录，它们关系到风险和容量，但没有直接的确认成本。 即使每日总量不变，突发形态也很重要。十小时内分散出现二十个提示可能可以承受。同样二十个提示如果在发布期间集中出现，就可能拖住唯一能诊断发布问题的人。简单记录任意15分钟窗口内的最大确认次数。每日公式估算劳动量，突发数字则揭示运行延迟。 不要因为一条警报发给几个人，就把它算成多次确认，除非确实有多人查看。如果一个生产提示同时发送给四名开发者，而通常有两人在其中一人批准前打开它，就记录两次人工响应。通知送达并非成本边界，注意力才是。 一条合理的事件记录只需要几个字段： ```text ts, request_id, responder, decision, shown_at, decided_at, prior_task_resumed_at, key_class 2026-07-21T14:03:10Z, r-1842, dev-3, allow, 14:03:10, 14:03:22, 14:05:01, deploy-read ``` 在这条记录里，`t`是12秒，观察到的恢复时间是99秒。它还能帮助你发现同一请求的重复提示、响应者之间负担不均，以及成本很高的密钥类别，同时无须收集密钥或请求载荷。 ## 会话授权改变了审批的含义 会话授权并没有取消确认。它把决定从每次使用移到一个有边界的代理运行开始时。因此，比较单位从调用变成了会话。会话审批应标识具体进程，并在该进程退出时结束；只绑定一个友好显示名称或没有明确期限的时间窗口，是另一种更弱的控制。 定义`s`为每位开发者每天新启动的代理会话数，`a`为检查并批准会话所需秒数的中位数。每日操作成本为： ```text session_seconds = d * s * a ``` 计算结果很快会偏向会话，因为一个决定可以覆盖许多调用。安全上的代价是已批准运行中的权限范围更宽。被入侵或走错方向的进程可以在不显示新提示的情况下再次发起允许的调用。因此，时间比较不能宣布一个普遍适用的赢家。 会话必须有清楚的终点。进程退出容易理解：授权随获得它的进程一起消失。固定八小时的窗口可能比任务活得更久，跨过交接，并覆盖审批时无人考虑的后续操作。如果授权系统无法撤销活动会话，或不能显示哪个进程持有会话，就应把它视为控制缺陷计价，而不能假装没有成本。 会话提示还必须提供足够的身份信息，让响应者可以作决定。路径名和代理标签都可以被复制。代码签名主体、可执行文件身份和启动上下文能提供更强的启动者证据。人批准的是某个主体在一段时间内的权限，不是在为一句`代理想要访问`背书。 ## 盈亏平衡公式揭示真实阈值 当逐次确认每天的完整秒数超过会话审批成本时，它的人工成本就更高。对于按开发者统计的提示次数，让两个公式相等： ```text p * d * (t + q * r) = d * s * a p_break_even = (s * a) / (t + q * r) ``` 如果每位开发者的提示率和会话率相同，团队规模会在公式中抵消。这并不意味着`d`无关紧要，而是说明随着团队扩大，人均阈值保持不变，两边的总成本同时增长。当工作分配不均、多人查看同一提示，或只有部分团队成员启动代理会话时，团队规模会重新进入计算。 考虑一个六人团队。每人每天启动两个可访问生产环境的代理运行，一次会话决定需要15秒。逐次决定的中位数为12秒，其中70%在专注工作时到达，中断恢复中位数为90秒。 ```text p_break_even = (2 * 15) / (12 + 0.70 * 90) p_break_even = 30 / 75 p_break_even = 0.4 confirmations per developer per day ``` 当每位开发者每天收到八个逐次提示时，团队要处理48个提示。完整成本是： ```text 48 * (12 + 0.70 * 90) = 3,600 seconds = 60 minutes/day ``` 12次会话审批的成本是`6 * 2 * 15 = 180 seconds`，即三分钟。每个生产工作日相差57分钟。如果只计算点击时间，逐次审批只会显示9.6分钟，漏掉大部分成本。 0.4这个阈值并不是让所有会话都获得宽泛权限的指令。它说明，对于可比较的日常调用，重复提示已经成为成本更高的审批方式。那些每次调用的后果都可能改变决定的操作，仍要保留逐次决定。只有当会话身份、生命周期、允许的通道和撤销行为都让其权限范围可以接受时，才把可预测且有边界的工作移到会话范围。 行动前先做敏感性检查。保持其他输入不变但把恢复成本设为零，阈值变成`30 / 12 = 2.5`次提示/开发者/天。恢复时间为三分钟时，阈值会降到0.22以下。如果只有不现实的恢复估值才能改变建议，决策就很稳定。如果建议在可信范围内翻转，就去测量恢复时间，不要继续争论。 ## 便宜的提示也能卡住整项操作 人工成本和经过时间回答的是不同问题。上面的公式合计人的时间，但没人能处理时，代理也在等待。一个15秒的决定可能只消耗15秒人工，却因为提示无人看到225秒而让部署多花四分钟。两个值都要跟踪。前者告诉你控制给团队带来的成本，后者告诉你它给生产流程带来的成本。 考虑一个执行五次调用的发布检查代理：读取部署状态、获取最近错误、检查当前修订版、通过SSH运行健康命令，然后记录结果。每次调用都使用配置为逐次审批的密钥。第一张卡在值班开发者审查代码时到达。开发者检查后返回差异。40秒后，代理处理完第一个响应，下一次调用到达。这个过程不断重复，直到工作流结束。 五次点击可能总共只花一分钟，但它们不是一次中断，因为间隔足以让开发者重新进入审查，又再次被拉走。如果每次中断需要75秒恢复，完整人工成本达到435秒：`5 * (12 + 75)`。代理的经过延迟还可能更长，因为每项工作都串行等待批准。如果仪表盘只报告点击延迟，这两个数字都不会出现。 现在假设第四次调用要求对一台意外主机运行健康命令，开发者拒绝了它。这次拒绝证明有一条提示包含有用的调用特定信息，但不能证明另外四次日常读取都需要单独决定。更好的设计可以为已识别的代理进程授权三个已知只读调用，对SSH保留逐次审批，并拒绝预定范围外的主机。模型按密钥类别归组成本和拒绝，因此能支持这种拆分，而不是把整个工作流取平均。 这个故障也暴露了串行确认的成本。调用依赖先前结果时，审批延迟位于关键路径上。对于互不依赖的调用，代理可能同时发出多个请求，形成响应者必须处理的突发。每日完整时间公式对同样数量的人工决定会给出相近结果，但运行形态不同。在意发布速度和事件响应时，还要记录工作流经过时间或代理等待时间。 不要把代理等待时间直接换算成开发者人工费用。等待中的进程不是正在工作的人。把它报告为经过延迟，再判断它损害了什么：部署时长、事件诊断、自动任务期限，或根本没有实质影响。分开记账，才能避免得出一个看似惊人却错误的总数。 拒绝的调用也应遵守同一原则。拒绝能避免不需要的操作带来的后果，这个后果可能远大于中断成本，但没有证据就无法赋予可信的金额。请具体报告审批门拦下了什么。`Denied SSH to an unrecognized host`是决策证据。除非调查已经确认，否则`审批避免了一次重大事故`只是猜测。 把这个故障过程当作设计测试。如果删除四个提示也会删除发现第五个问题所需的上下文，拟议的会话范围就太宽。如果每次调用使用独立的密钥类别，而敏感调用保留自己的门，日常提示只会增加成本，对那个决定没有帮助。盈亏平衡公式告诉你何时检查设计，调用序列告诉你从哪里切开。 ## 响应时间中位数会漏掉队列和弃置工作 响应时间中位数描述的是典型已处理提示，但生产工作常常在尾部失败。等待唯一获授权开发者的提示，阻塞代理、部署或事件检查的时间可能远超中位数。除了劳动公式中使用的数值，还要记录响应时间第90百分位、过期提示和到首位有效响应者的时间。 不要简单地把第90百分位代入所有成本计算，那会把每个提示都按慢速情况收费。用中位数估算日常劳动，再把尾部作为运行约束单独报告。例如：`42 loaded minutes/day; median decision 11s; p90 decision 96s; 3 expirations/week`。这行简洁信息比一个混合分数更真实。 中断恢复也有长尾。阅读日志时出现的提示可能只花半分钟。若同一个人正把尚未执行的数据库修复步骤记在脑中，提示可能迫使他重新检查全部步骤。把之前的任务分为日常、专注和事件等两三个类别。你要找的是策略边界，不是写一篇神经科学论文。 弃置的工作也属于成本账。如果代理等待超时后重试并展示另一张卡，第一条提示不会因为无人批准就变成零成本。统计它获得的注意力、给代理造成的延迟，以及后来有人查看的重复提示。 提示数量很大并不能单独证明审批疲劳。要观察同一密钥类别的重复批准、检查时间下降、重复请求，以及日常操作的拒绝率接近零。这些信号说明界面要求人们再次确认一个已经确立的决定。如果拒绝率很高，说明即使提示很贵，它们仍能区分可接受与不可接受的调用。 ## 更多开发者改变的是协作而非乘数 生产响应者人数之所以重要，是因为提示分配很少均匀。把团队总提示数乘以人数会夸大成本，而把它平均到所有人又可能掩盖几乎所有中断都由两个人承担。先计算每人的完整分钟数，再求和。除了团队总数，还要报告中位响应者和最忙响应者。 假设一个十人生产组收到60个提示，但路由把45个发给主要两人。平均每人六个提示并不能描述任何人的一天。即使团队其他人几乎感觉不到摩擦，主要响应者也可能需要让日常调用使用会话授权。轮换主要角色可以分散痛苦，但不会降低总成本，还可能增加交接工作。 扇出还会产生另一项成本。如果提示发给多人，一次批准就会结束等待，但其他开发者可能已经阅读。加入`w`，表示平均每个提示有多少人查看。团队总量形式变为： ```text per_use_seconds = p * w * (t + q * r) ``` 只有当每次查看成本相近时才使用此形式。如果最终批准者花20秒，其他人只扫两秒，请分组计算。运行方式要求时，模型应增加一点细节，而不是因为电子表格还有空列就增加变量。 会话成本也可能集中。如果只有两名指定操作员启动可访问生产的运行，会话侧应使用二，而不是可能收到逐次提示的十人。请在每项旁注明统计人群。人数本身不是风险乘数，权限如何分配以及谁真正投入注意力才是。 队列归属也在这里发挥作用。由明确值班响应者负责的共享审批队列，可以减少重复查看。向全团队广播每个请求，也许能更快得到一次点击，却会悄悄消耗更多集体专注力。批准得快和批准得便宜是两个不同指标。 ## 风险决定哪些调用保留逐次门 调用量能说明控制很昂贵，后果则决定是否值得继续付费。请按同一会话中又一次调用可能造成的结果，拆分密钥或操作类别。只读清单、启动部署、修改生产数据和管理凭据，不应仅因由同一个代理调用就继承同一种设置。 行业经常混淆身份验证、授权和确认。身份验证确定进程或人员是谁，授权给予一个范围，确认要求人重新考虑某一次用途。反复确认无法修复薄弱的进程身份，强身份也不会让宽泛授权变安全。混淆三者，就会导致团队对每次调用都点击，却把权限给了错误的进程。 当请求包含会实质改变决定的事实时，请保留逐次确认，例如目标主机、操作类别、环境或受影响资源。即使调用量很大，针对生产的破坏性命令也可能值得重新检查。如果它每天出现五十次，响应者已经不读就批准，设计已经失败。应减少源头数量或缩小允许的操作，而不是把快速点击当作控制。 当人可以一次性对进程和范围作出有意义的决定时，会话授权适合重复调用。好的候选应有明确生命周期、可预测通道、可见身份、即时撤销，以及足以还原每次调用的审计记录。会话不能变成全天有效、在无关进程间传递的持有者授权。 混合决策往往正确。把日常API读取和已知部署检查放进进程绑定会话，对少数可以修改生产或管理凭据的密钥保留逐次批准。这样既能降低中断数量，又能在单次操作会改变风险的位置保留一道有意设置的停点。 不要用`提示越多越安全`来为逐次确认辩护。人们反射式批准的控制，仪式成本很高，区分能力却很弱。应判断提示改变决定的频率是否足以支付其完整成本。 ## 改变范围前测量一个生产周 只要样本包含正常生产工作和至少一个繁忙时段，一周通常足以把猜测换成可信范围。不要为了测量故意制造事件。导出提示事件，让响应者为少量样本记录恢复时间，并让工作表保持简单，确保有人能完成。 每位响应者每天一行： ```text date | responder | prompts_seen | prompts_allowed | prompts_denied | median_response_s | focus_share | median_recovery_s | sessions_started | median_session_approval_s 2026-07-21 | dev-3 | 11 | 10 | 1 | 12 | 0.70 | 90 | 2 | 15 ``` 计算以下单元格： ```text loaded_per_use_min = prompts_seen * (median_response_s + focus_share * median_recovery_s) / 60 session_min = sessions_started * median_session_approval_s / 60 break_even_prompts = sessions_started * median_session_approval_s / (median_response_s + focus_share * median_recovery_s) ``` 随后按密钥类别检查提示。团队总量可以告诉你需要改变，类别细分则告诉你改什么。如果80%的提示来自只读状态检查，而少数被拒绝请求涉及生产修改，把所有密钥切换到一种模式会丢掉证据中最有用的部分。 为每次拒绝记录一个简单原因类别，例如目标错误、操作异常、重复或上下文不足。自由书写事件长文很难汇总。原因分布会显示审批门是在抓危险请求，还是在弥补难以理解的提示。 恢复抽样不需要监视员工。让每位响应者为一部分提示标记`0`、`30`、`90`或`180+`秒，或者从由本人控制的本地工作轨迹推断恢复。发布结果时同时说明方法。一个粗略的实测分布胜过精确到两位小数的虚构常数。 改变授权前，先写下预测：哪些提示类别会消失，会由多少次会话审批替代，哪些逐次门会保留。下一周用相同字段测量。如果代理因为不再等待而增加调用量，请比较人工决定数，而不是原始API请求数。 ## 把确认花在能改变决定的地方 模型应为每个类别产出路由决定，而不是一个全局阈值。对每个密钥类别，比较逐次确认完整分钟数和会话审批分钟数，再写明已批准会话中多一次调用会产生什么后果。成本差距大且会话后果可以接受的日常类别可以迁移。高影响类别即使时间成本明显，也要保留逐次审批。 根据观察到的行为设定复审触发条件。当提示量翻倍、响应者群体变化、会话长度变化或拒绝原因转移时，重新计算。照搬其他团队的阈值几乎没有用，因为各团队的恢复时间和扇出差异远大于点击时间差异。 改变范围后，控制系统必须保留证据。记录会话开始、获批身份、撤销和每次调用。否则会话授权只是通过删除调查代理行为所需的轨迹来节省时间。应验证审计历史能在不依赖执行操作的代理的情况下，暴露删除或修改。 Sallyport把这种拆分实现为固定阶梯：保险库锁定时拒绝所有操作，新代理进程默认接受一次会话决定，选定的密钥仍可要求每次使用都审批。Sessions和Activity日志分别保留运行级与调用级记录，因此改变确认范围不会抹去单次操作。 不要在会议上用`感觉有多烦`来设阈值。把七天的提示放进公式，清楚标出单位，并把日常调用与那些事实会改变决定的调用分开。保留原始工作表和决策记录，让团队日后可以质疑假设。当一个人已经几十次批准同一个有边界的权限且从未拒绝时，再来一张相同卡片并不能保留判断力，只会消耗判断力。