【Agent工程】18—— 人机协同确认点文章目录【Agent工程】18—— 人机协同确认点1. 全自动链路挡不住误执行1.1 与第 6 篇 pending 的分工1.2 确认疲劳是真实故障模式2. 确认点落在哪一层2.1 确认策略字段2.2 策略引擎确认与人确认3. 运行时流程与裁决契约3.1 裁决接口最小约定3.2 过期与取消3.3 轨迹字段4. 确认页与角色4.1 最小展示集4.2 角色与双人确认4.3 通知渠道5. 贯穿示例工单助手5.1 一次升级主路径5.2 与灰度的组合5.3 批量关单的双人路径6. 可运行示意确认点与 SLA6.1 确认点状态机6.2 执行门闩7. 与编排、评测、灰度的衔接7.1 编排侧状态7.2 自动批准的白名单7.3 确认与成本、限流的顺序8. 四个常见误区8.1 排查清单9. 适用边界9.1 迁移步骤9.2 术语速查10. 小结与下一篇摘要第 6 篇给出高危写的 pending 队列第 17 篇用灰度控制策略包影响面线上仍常见两类事故——该拦的写操作被模型「自说自话」执行或不该拦的步骤把值班淹没。本篇把人机协同确认点写成可配置的边界确认落在哪一层、谁有权裁决、过期如何处理、页面展示什么、如何降低确认疲劳。贯穿示例继续用工单助手。适合读完 【Agent工程】6—— 危险写操作与二次确认、【Agent工程】17—— 灰度发布与回滚、准备把确认从「提示词嘱咐」升级成运行时硬点的工程师。读完可以独立完成为工具 / 步骤 / 任务卡配置确认点并实现带 SLA 的裁决与轨迹字段。1. 全自动链路挡不住误执行权限、scope、限流、成本配额解决的是「能不能调用、还能不能花」。确认点解决的是这次副作用现在要不要发生。模型在上下文里写「用户已同意」或值班口头说「发吧」都不是可审计的裁决没有独立 approve 记录复盘只能猜。机制管什么不管什么权限 / scope是否越权合法但危险的写是否现在执行灰度哪一版策略在跑单步是否需要人点头成本配额是否超支一次通知措辞是否得当确认点危险步是否获准不能替代评测与灰度工程结论确认点是误执行半径的闸门提示词只能辅助表达不能替代运行时硬约束。前文见 【Agent工程】6—— 危险写操作与二次确认、【Agent工程】13—— 超时取消与协作中断、【Agent工程】14—— 审计日志与轨迹字段、【Agent工程】17—— 灰度发布与回滚。1.1 与第 6 篇 pending 的分工维度第 6 篇本篇焦点高危工具两阶段执行确认点分层、角色、SLA、疲劳产物pending 队列 approve 接口确认策略表 值班协同约定读者问题怎么拦住危险写拦在哪、谁来拦、多久必须裁决本篇默认已经具备 pending 快照与「确认不改参」底线若尚未实现先补第 6 篇再谈协同面。1.2 确认疲劳是真实故障模式把所有写操作都设成确认值班会习惯性点 approve确认点名存实亡。设计目标不是「确认越多越安全」而是高风险少而清晰低风险默认自动中风险可按租户收紧。2. 确认点落在哪一层层级触发对象典型场景工具级单个高危tool_idnotify_oncall、删除、付款相关外发步骤级一组连续写或批量工具一次关 50 张单、跨系统同步任务卡级目标或策略变更用户目标从「查询」变为「批量升级」同一张卡可以同时存在多层确认卡级批准「允许升级策略」后工具级仍可对notify_oncall再要一次。卡级同意不等于工具级自动执行。2.1 确认策略字段建议在注册表或策略包中显式配置{tool_id:notify_oncall,risk_level:high,confirm:{required:true,mode:human,roles:[oncall,ticket_owner],min_approvers:1,ttl_seconds:1800,on_expire:reject_and_degrade}}字段含义modehuman/dual_control/policy策略引擎非模型自批roles允许裁决的角色集合min_approvers最少同意人数ttl_seconds确认点存活时间on_expire过期动作拒绝、取消卡、降级路径critical级工具不允许卡片把required改成 false卡片只可以收紧不可以放宽。2.2 策略引擎确认与人确认部分中风险动作可用规则引擎自动批准例如「工作时间内、影响面 ≤ 1 张单、金额字段为空」。规则引擎确认必须写入独立decided_bypolicy:rule_id规则版本进入轨迹命中失败时回落到人工而不是静默执行禁止把「模型输出 JSON 表示已批准」当成 policy 确认。3. 运行时流程与裁决契约推荐顺序鉴权 → scope → 选策略包→ 成本预检 →创建确认点或直接执行→ 裁决 → 执行快照。3.1 裁决接口最小约定动作效果approve用创建时快照执行实现层reject不执行写原因码编排可 degradecancel与任务取消对齐关闭确认点接口只接受confirm_id或pending_id不接受客户端重传工具参数。参数以入队快照为准防止确认页被篡改。3.2 过期与取消确认点必须有 TTL。过期后常见策略on_expire适用reject_and_degrade通知类过期则走站内留言等降级cancel_card强依赖该写才能继续的任务keep_waiting仅低峰人工队列需配合告警慎用与第 13 篇协作任务卡被取消时所有未裁决确认点一并cancel避免卡已终态仍弹出过期 approve。3.3 轨迹字段至少记录event_type内容confirm.createdconfirm_id、tool_id、ttl、rolesconfirm.decidedapprove/reject、decided_by、耗时confirm.expired过期动作tool_call确认后关联 confirm_id评测集第 15 篇应包含未确认不得执行、过期不得执行、错误角色不得 approve。4. 确认页与角色值班不是审代码。确认页一眼要能回答四件事要做什么、对谁做、风险多大、还剩多久。4.1 最小展示集任务目标card.goal原文或摘要拟执行动作工具名 参数可读摘要脱敏后影响对象工单号、租户、批量规模风险与过期risk_level、剩余 TTL、过期后果策略包版本pack_id灰度中尤其重要缺少 goal 时值班只能对着孤立参数点按钮误批概率上升。4.2 角色与双人确认模式规则单人任一合法角色 approve 即可双人两名不同decided_by且不能是同一人会话回避任务发起人不得独自批准涉及自己的敏感写按合规要求双人确认适合批量关单、资金相关外发普通notify_oncall通常单人足够。不要把双人确认当成默认否则队列堆积会逼出「互相代点」。4.3 通知渠道确认点创建后需要可靠触达IM、邮件、值班页红点。触达失败应写confirm.notify_failed并允许二次投递不要假设模型回复里的「已提醒值班」等于触达成功。5. 贯穿示例工单助手动作确认策略说明写内部备注无需确认可逆、影响面小notify_oncall单人、30 分钟 TTL过期则 degrade 为站内留言bulk_close双人、主管角色批量不可轻易撤销退款建议外发财务角色与工单值班角色分离5.1 一次升级主路径Agent 完成读票与优先级更新自动提议notify_oncall→ 创建确认点卡进入waiting_confirm值班在确认页核对措辞与工单approve网关用快照发送轨迹关联 confirm_id若 30 分钟无裁决 → 过期拒绝 → 走站内留言降级 → 终态degraded验收承认不要求通知一定发出但要求未确认零外发、过期有明确终态。5.2 与灰度的组合候选策略包可以把更多工具设为需确认收紧但不得在灰度中偷偷去掉critical确认。观察指标除失败率外增加指标用途确认等待 P50/P95SLA 是否过紧过期率触达或人力是否不足误批事后撤销数页面信息是否不够每卡确认次数是否确认过多导致疲劳早高峰若过期率突然升高优先查 IM 触达与值班人力不要先放宽 TTL放宽 TTL 只会让队列更长进一步拖垮响应。若候选包把大量 medium 工具改成确认导致每卡确认次数翻倍应视为灰度观察失败信号之一——即使终态成功率尚可。5.3 批量关单的双人路径bulk_close建议拆成两段可见信息关闭范围张数、筛选条件与不可撤销后果。第一人 approve 后进入waiting_second_approve第二人看到「已有谁批准」但仍需独立点同意。两人必须使用不同账号同一浏览器会话切换账号不算双人。轨迹里应能查出两次confirm.decided且decided_by不同。6. 可运行示意确认点与 SLA6.1 确认点状态机from__future__importannotationsfromdataclassesimportdataclassfromtypingimportAnydataclassclassConfirmPoint:confirm_id:strtool_id:strargs_snapshot:dict[str,Any]roles:set[str]ttl_seconds:intcreated_at:floatstatus:strpending# pending / approved / rejected / expired / cancelleddefis_expired(self,now:float)-bool:returnnowself.created_atself.ttl_secondsdefdecide(self,action:str,role:str,actor:str,now:float)-str:ifself.status!pending:returnCONFIRM_NOT_PENDINGifself.is_expired(now):self.statusexpiredreturnCONFIRM_EXPIREDifrolenotinself.roles:returnCONFIRM_FORBIDDENifactionapprove:self.statusapprovedreturnokifactionreject:self.statusrejectedreturnokreturnCONFIRM_BAD_ACTIONif__name____main__:cpConfirmPoint(c1,notify_oncall,{ticket_id:T-1,text:请处理},{oncall},ttl_seconds30,created_at1000.0,)assertcp.decide(approve,guest,u1,1010.0)CONFIRM_FORBIDDENassertcp.decide(approve,oncall,u2,1040.0)CONFIRM_EXPIREDcp2ConfirmPoint(c2,notify_oncall,{},{oncall},30,1000.0)assertcp2.decide(approve,oncall,u2,1010.0)okassertcp2.statusapprovedprint(cp2.status)6.2 执行门闩from__future__importannotationsfromtypingimportAny,Callabledefrun_after_confirm(confirm:Any,role:str,actor:str,now:float,exec_fn:Callable[[dict],str],)-dict[str,Any]:codeconfirm.decide(approve,role,actor,now)ifcode!ok:return{ok:False,error_code:code}resultexec_fn(confirm.args_snapshot)return{ok:True,result:result,confirm_id:confirm.confirm_id,args:confirm.args_snapshot,}if__name____main__:fromdataclassesimportdataclassdataclassclassC:confirm_id:strargs_snapshot:dictroles:setttl_seconds:intcreated_at:floatstatus:strpendingdefis_expired(self,now:float)-bool:returnnowself.created_atself.ttl_secondsdefdecide(self,action:str,role:str,actor:str,now:float)-str:ifself.is_expired(now):self.statusexpiredreturnCONFIRM_EXPIREDifrolenotinself.roles:returnCONFIRM_FORBIDDENself.statusapprovedreturnokcC(c9,{ticket_id:T-9},{oncall},60,0.0)outrun_after_confirm(c,oncall,alice,10.0,lambdaa:fsent:{a[ticket_id]})assertout[ok]isTrueassertout[args][ticket_id]T-9print(out[result])生产环境把确认点放进共享存储approve 用条件更新仅statuspending可翻转防止双人重复执行。7. 与编排、评测、灰度的衔接层级本篇补充第 6 篇协同面角色、TTL、页面、疲劳第 7 / 9 篇waiting_confirm为合法中间态拒绝可 degrade第 13 篇取消卡时级联取消确认点第 14 / 15 篇confirm.* 事件可断言第 17 篇灰度可收紧确认不可取消 critical7.1 编排侧状态任务卡在等待确认时应对外可见避免用户以为系统卡死。超时文案区分「等待人工确认」与「模型推理中」。7.2 自动批准的白名单仅当同时满足时允许confirm.requiredfalserisk_level 为 low 或注册表明确允许影响面有硬上限例如单对象、非批量可逆或有补偿工具评测集覆盖误执行后果白名单变更本身应走灰度并写入变更单。7.3 确认与成本、限流的顺序成本预检应在创建确认点之前若额度已不足不要把「注定发不出的通知」丢给值班审批。限流同理队列已满时先返回明确错误而不是堆积确认点。确认点是稀缺的人力资源只留给「钱够、权够、只差人点头」的步骤。对终端用户等待确认时的文案建议区分「已提交值班确认预计 30 分钟内处理」——有 TTL「系统繁忙请稍后重试」——限流或成本触顶「需要你补充信息」——缺槽位不是确认点三类状态混用会让用户对「卡在确认」产生错误预期并增加重复提单。8. 四个常见误区误区典型表现更稳妥的做法模型自确认回复里写「已同意」就执行独立 approve 与角色校验确认可改参页面上改收件人再执行只认入队快照无过期策略pending 挂数天TTL 过期动作 告警处处要确认值班习惯性点头分级低自动、高确认、极高双人还有一种隐蔽问题确认页展示的是摘要执行用的是另一份未展示字段隐藏 cc、隐藏金额。摘要必须由同一快照生成禁止两套数据源。8.1 排查清单高危工具是否强制确认且 critical 不可放宽approve 是否只认 confirm_id 快照是否有 TTL 与过期动作取消卡是否级联关闭确认点轨迹是否含 confirm.created / decided每卡确认次数是否纳入看板9. 适用边界本篇方法适合已有工具门禁与 pending需要值班协同与 SLA存在对外通知、批量写、资金相关外发准备把确认纳入评测与灰度观察本篇不覆盖完整审批流引擎 / OA 选型电子签与合格电子签名合规细节安全与合规核对清单——下一篇展开若人力不足以支撑确认 SLA优先减少确认点数量并加强自动规则而不是无限延长 TTL。组织面上建议明确谁可以配置确认策略、谁可以临时豁免。临时豁免必须写变更单、设过期时间并在轨迹标记confirm.bypasstrue禁止在群聊里口头豁免后长期生效。灰度抬升权限与确认豁免权限应分离避免同一人既能放大流量又能关掉确认。9.1 迁移步骤盘点工具 risk_level标出必须确认的集合为确认点增加角色、TTL、过期动作确认页补齐 goal / 影响面 / pack_id轨迹与评测断言补 confirm.*看板增加等待时长、过期率、每卡确认次数9.2 术语速查术语含义确认点危险步执行前必须完成的人机或策略裁决confirm_id确认点唯一编号快照参数入队时冻结的工具参数裁决后不可改TTL确认点存活时间双人确认需要两名合法角色分别同意确认疲劳确认过多导致习惯性批准10. 小结与下一篇上线与边界单元继续补齐人侧闸门分层确认工具 / 步骤 / 任务卡角色与 SLA谁批、多久必须裁决、过期如何处理页面可读goal、影响面、风险、版本一眼可见防疲劳低风险自动高风险少而硬值班核对表核对项通过标准critical 是否不可放宽卡片无法关闭确认裁决是否不改参只认快照过期是否有动作拒绝或降级不悬挂取消是否级联卡终态无残留确认点评测是否覆盖未确认零执行疲劳是否可观测每卡确认次数进看板下一篇写安全与合规核对确认点解决「这一步该不该做」合规核对解决「整条链路是否满足留痕、最小化与可追责」——把权限、确认、审计、灰度收成上线前清单。系列导航上一篇【Agent工程】17—— 灰度发布与回滚下一篇【Agent工程】19—— 安全与合规核对清单撰写中 【Agent工程】（18）—— 人机协同确认点
【Agent工程】18—— 人机协同确认点文章目录【Agent工程】18—— 人机协同确认点1. 全自动链路挡不住误执行1.1 与第 6 篇 pending 的分工1.2 确认疲劳是真实故障模式2. 确认点落在哪一层2.1 确认策略字段2.2 策略引擎确认与人确认3. 运行时流程与裁决契约3.1 裁决接口最小约定3.2 过期与取消3.3 轨迹字段4. 确认页与角色4.1 最小展示集4.2 角色与双人确认4.3 通知渠道5. 贯穿示例工单助手5.1 一次升级主路径5.2 与灰度的组合5.3 批量关单的双人路径6. 可运行示意确认点与 SLA6.1 确认点状态机6.2 执行门闩7. 与编排、评测、灰度的衔接7.1 编排侧状态7.2 自动批准的白名单7.3 确认与成本、限流的顺序8. 四个常见误区8.1 排查清单9. 适用边界9.1 迁移步骤9.2 术语速查10. 小结与下一篇摘要第 6 篇给出高危写的 pending 队列第 17 篇用灰度控制策略包影响面线上仍常见两类事故——该拦的写操作被模型「自说自话」执行或不该拦的步骤把值班淹没。本篇把人机协同确认点写成可配置的边界确认落在哪一层、谁有权裁决、过期如何处理、页面展示什么、如何降低确认疲劳。贯穿示例继续用工单助手。适合读完 【Agent工程】6—— 危险写操作与二次确认、【Agent工程】17—— 灰度发布与回滚、准备把确认从「提示词嘱咐」升级成运行时硬点的工程师。读完可以独立完成为工具 / 步骤 / 任务卡配置确认点并实现带 SLA 的裁决与轨迹字段。1. 全自动链路挡不住误执行权限、scope、限流、成本配额解决的是「能不能调用、还能不能花」。确认点解决的是这次副作用现在要不要发生。模型在上下文里写「用户已同意」或值班口头说「发吧」都不是可审计的裁决没有独立 approve 记录复盘只能猜。机制管什么不管什么权限 / scope是否越权合法但危险的写是否现在执行灰度哪一版策略在跑单步是否需要人点头成本配额是否超支一次通知措辞是否得当确认点危险步是否获准不能替代评测与灰度工程结论确认点是误执行半径的闸门提示词只能辅助表达不能替代运行时硬约束。前文见 【Agent工程】6—— 危险写操作与二次确认、【Agent工程】13—— 超时取消与协作中断、【Agent工程】14—— 审计日志与轨迹字段、【Agent工程】17—— 灰度发布与回滚。1.1 与第 6 篇 pending 的分工维度第 6 篇本篇焦点高危工具两阶段执行确认点分层、角色、SLA、疲劳产物pending 队列 approve 接口确认策略表 值班协同约定读者问题怎么拦住危险写拦在哪、谁来拦、多久必须裁决本篇默认已经具备 pending 快照与「确认不改参」底线若尚未实现先补第 6 篇再谈协同面。1.2 确认疲劳是真实故障模式把所有写操作都设成确认值班会习惯性点 approve确认点名存实亡。设计目标不是「确认越多越安全」而是高风险少而清晰低风险默认自动中风险可按租户收紧。2. 确认点落在哪一层层级触发对象典型场景工具级单个高危tool_idnotify_oncall、删除、付款相关外发步骤级一组连续写或批量工具一次关 50 张单、跨系统同步任务卡级目标或策略变更用户目标从「查询」变为「批量升级」同一张卡可以同时存在多层确认卡级批准「允许升级策略」后工具级仍可对notify_oncall再要一次。卡级同意不等于工具级自动执行。2.1 确认策略字段建议在注册表或策略包中显式配置{tool_id:notify_oncall,risk_level:high,confirm:{required:true,mode:human,roles:[oncall,ticket_owner],min_approvers:1,ttl_seconds:1800,on_expire:reject_and_degrade}}字段含义modehuman/dual_control/policy策略引擎非模型自批roles允许裁决的角色集合min_approvers最少同意人数ttl_seconds确认点存活时间on_expire过期动作拒绝、取消卡、降级路径critical级工具不允许卡片把required改成 false卡片只可以收紧不可以放宽。2.2 策略引擎确认与人确认部分中风险动作可用规则引擎自动批准例如「工作时间内、影响面 ≤ 1 张单、金额字段为空」。规则引擎确认必须写入独立decided_bypolicy:rule_id规则版本进入轨迹命中失败时回落到人工而不是静默执行禁止把「模型输出 JSON 表示已批准」当成 policy 确认。3. 运行时流程与裁决契约推荐顺序鉴权 → scope → 选策略包→ 成本预检 →创建确认点或直接执行→ 裁决 → 执行快照。3.1 裁决接口最小约定动作效果approve用创建时快照执行实现层reject不执行写原因码编排可 degradecancel与任务取消对齐关闭确认点接口只接受confirm_id或pending_id不接受客户端重传工具参数。参数以入队快照为准防止确认页被篡改。3.2 过期与取消确认点必须有 TTL。过期后常见策略on_expire适用reject_and_degrade通知类过期则走站内留言等降级cancel_card强依赖该写才能继续的任务keep_waiting仅低峰人工队列需配合告警慎用与第 13 篇协作任务卡被取消时所有未裁决确认点一并cancel避免卡已终态仍弹出过期 approve。3.3 轨迹字段至少记录event_type内容confirm.createdconfirm_id、tool_id、ttl、rolesconfirm.decidedapprove/reject、decided_by、耗时confirm.expired过期动作tool_call确认后关联 confirm_id评测集第 15 篇应包含未确认不得执行、过期不得执行、错误角色不得 approve。4. 确认页与角色值班不是审代码。确认页一眼要能回答四件事要做什么、对谁做、风险多大、还剩多久。4.1 最小展示集任务目标card.goal原文或摘要拟执行动作工具名 参数可读摘要脱敏后影响对象工单号、租户、批量规模风险与过期risk_level、剩余 TTL、过期后果策略包版本pack_id灰度中尤其重要缺少 goal 时值班只能对着孤立参数点按钮误批概率上升。4.2 角色与双人确认模式规则单人任一合法角色 approve 即可双人两名不同decided_by且不能是同一人会话回避任务发起人不得独自批准涉及自己的敏感写按合规要求双人确认适合批量关单、资金相关外发普通notify_oncall通常单人足够。不要把双人确认当成默认否则队列堆积会逼出「互相代点」。4.3 通知渠道确认点创建后需要可靠触达IM、邮件、值班页红点。触达失败应写confirm.notify_failed并允许二次投递不要假设模型回复里的「已提醒值班」等于触达成功。5. 贯穿示例工单助手动作确认策略说明写内部备注无需确认可逆、影响面小notify_oncall单人、30 分钟 TTL过期则 degrade 为站内留言bulk_close双人、主管角色批量不可轻易撤销退款建议外发财务角色与工单值班角色分离5.1 一次升级主路径Agent 完成读票与优先级更新自动提议notify_oncall→ 创建确认点卡进入waiting_confirm值班在确认页核对措辞与工单approve网关用快照发送轨迹关联 confirm_id若 30 分钟无裁决 → 过期拒绝 → 走站内留言降级 → 终态degraded验收承认不要求通知一定发出但要求未确认零外发、过期有明确终态。5.2 与灰度的组合候选策略包可以把更多工具设为需确认收紧但不得在灰度中偷偷去掉critical确认。观察指标除失败率外增加指标用途确认等待 P50/P95SLA 是否过紧过期率触达或人力是否不足误批事后撤销数页面信息是否不够每卡确认次数是否确认过多导致疲劳早高峰若过期率突然升高优先查 IM 触达与值班人力不要先放宽 TTL放宽 TTL 只会让队列更长进一步拖垮响应。若候选包把大量 medium 工具改成确认导致每卡确认次数翻倍应视为灰度观察失败信号之一——即使终态成功率尚可。5.3 批量关单的双人路径bulk_close建议拆成两段可见信息关闭范围张数、筛选条件与不可撤销后果。第一人 approve 后进入waiting_second_approve第二人看到「已有谁批准」但仍需独立点同意。两人必须使用不同账号同一浏览器会话切换账号不算双人。轨迹里应能查出两次confirm.decided且decided_by不同。6. 可运行示意确认点与 SLA6.1 确认点状态机from__future__importannotationsfromdataclassesimportdataclassfromtypingimportAnydataclassclassConfirmPoint:confirm_id:strtool_id:strargs_snapshot:dict[str,Any]roles:set[str]ttl_seconds:intcreated_at:floatstatus:strpending# pending / approved / rejected / expired / cancelleddefis_expired(self,now:float)-bool:returnnowself.created_atself.ttl_secondsdefdecide(self,action:str,role:str,actor:str,now:float)-str:ifself.status!pending:returnCONFIRM_NOT_PENDINGifself.is_expired(now):self.statusexpiredreturnCONFIRM_EXPIREDifrolenotinself.roles:returnCONFIRM_FORBIDDENifactionapprove:self.statusapprovedreturnokifactionreject:self.statusrejectedreturnokreturnCONFIRM_BAD_ACTIONif__name____main__:cpConfirmPoint(c1,notify_oncall,{ticket_id:T-1,text:请处理},{oncall},ttl_seconds30,created_at1000.0,)assertcp.decide(approve,guest,u1,1010.0)CONFIRM_FORBIDDENassertcp.decide(approve,oncall,u2,1040.0)CONFIRM_EXPIREDcp2ConfirmPoint(c2,notify_oncall,{},{oncall},30,1000.0)assertcp2.decide(approve,oncall,u2,1010.0)okassertcp2.statusapprovedprint(cp2.status)6.2 执行门闩from__future__importannotationsfromtypingimportAny,Callabledefrun_after_confirm(confirm:Any,role:str,actor:str,now:float,exec_fn:Callable[[dict],str],)-dict[str,Any]:codeconfirm.decide(approve,role,actor,now)ifcode!ok:return{ok:False,error_code:code}resultexec_fn(confirm.args_snapshot)return{ok:True,result:result,confirm_id:confirm.confirm_id,args:confirm.args_snapshot,}if__name____main__:fromdataclassesimportdataclassdataclassclassC:confirm_id:strargs_snapshot:dictroles:setttl_seconds:intcreated_at:floatstatus:strpendingdefis_expired(self,now:float)-bool:returnnowself.created_atself.ttl_secondsdefdecide(self,action:str,role:str,actor:str,now:float)-str:ifself.is_expired(now):self.statusexpiredreturnCONFIRM_EXPIREDifrolenotinself.roles:returnCONFIRM_FORBIDDENself.statusapprovedreturnokcC(c9,{ticket_id:T-9},{oncall},60,0.0)outrun_after_confirm(c,oncall,alice,10.0,lambdaa:fsent:{a[ticket_id]})assertout[ok]isTrueassertout[args][ticket_id]T-9print(out[result])生产环境把确认点放进共享存储approve 用条件更新仅statuspending可翻转防止双人重复执行。7. 与编排、评测、灰度的衔接层级本篇补充第 6 篇协同面角色、TTL、页面、疲劳第 7 / 9 篇waiting_confirm为合法中间态拒绝可 degrade第 13 篇取消卡时级联取消确认点第 14 / 15 篇confirm.* 事件可断言第 17 篇灰度可收紧确认不可取消 critical7.1 编排侧状态任务卡在等待确认时应对外可见避免用户以为系统卡死。超时文案区分「等待人工确认」与「模型推理中」。7.2 自动批准的白名单仅当同时满足时允许confirm.requiredfalserisk_level 为 low 或注册表明确允许影响面有硬上限例如单对象、非批量可逆或有补偿工具评测集覆盖误执行后果白名单变更本身应走灰度并写入变更单。7.3 确认与成本、限流的顺序成本预检应在创建确认点之前若额度已不足不要把「注定发不出的通知」丢给值班审批。限流同理队列已满时先返回明确错误而不是堆积确认点。确认点是稀缺的人力资源只留给「钱够、权够、只差人点头」的步骤。对终端用户等待确认时的文案建议区分「已提交值班确认预计 30 分钟内处理」——有 TTL「系统繁忙请稍后重试」——限流或成本触顶「需要你补充信息」——缺槽位不是确认点三类状态混用会让用户对「卡在确认」产生错误预期并增加重复提单。8. 四个常见误区误区典型表现更稳妥的做法模型自确认回复里写「已同意」就执行独立 approve 与角色校验确认可改参页面上改收件人再执行只认入队快照无过期策略pending 挂数天TTL 过期动作 告警处处要确认值班习惯性点头分级低自动、高确认、极高双人还有一种隐蔽问题确认页展示的是摘要执行用的是另一份未展示字段隐藏 cc、隐藏金额。摘要必须由同一快照生成禁止两套数据源。8.1 排查清单高危工具是否强制确认且 critical 不可放宽approve 是否只认 confirm_id 快照是否有 TTL 与过期动作取消卡是否级联关闭确认点轨迹是否含 confirm.created / decided每卡确认次数是否纳入看板9. 适用边界本篇方法适合已有工具门禁与 pending需要值班协同与 SLA存在对外通知、批量写、资金相关外发准备把确认纳入评测与灰度观察本篇不覆盖完整审批流引擎 / OA 选型电子签与合格电子签名合规细节安全与合规核对清单——下一篇展开若人力不足以支撑确认 SLA优先减少确认点数量并加强自动规则而不是无限延长 TTL。组织面上建议明确谁可以配置确认策略、谁可以临时豁免。临时豁免必须写变更单、设过期时间并在轨迹标记confirm.bypasstrue禁止在群聊里口头豁免后长期生效。灰度抬升权限与确认豁免权限应分离避免同一人既能放大流量又能关掉确认。9.1 迁移步骤盘点工具 risk_level标出必须确认的集合为确认点增加角色、TTL、过期动作确认页补齐 goal / 影响面 / pack_id轨迹与评测断言补 confirm.*看板增加等待时长、过期率、每卡确认次数9.2 术语速查术语含义确认点危险步执行前必须完成的人机或策略裁决confirm_id确认点唯一编号快照参数入队时冻结的工具参数裁决后不可改TTL确认点存活时间双人确认需要两名合法角色分别同意确认疲劳确认过多导致习惯性批准10. 小结与下一篇上线与边界单元继续补齐人侧闸门分层确认工具 / 步骤 / 任务卡角色与 SLA谁批、多久必须裁决、过期如何处理页面可读goal、影响面、风险、版本一眼可见防疲劳低风险自动高风险少而硬值班核对表核对项通过标准critical 是否不可放宽卡片无法关闭确认裁决是否不改参只认快照过期是否有动作拒绝或降级不悬挂取消是否级联卡终态无残留确认点评测是否覆盖未确认零执行疲劳是否可观测每卡确认次数进看板下一篇写安全与合规核对确认点解决「这一步该不该做」合规核对解决「整条链路是否满足留痕、最小化与可追责」——把权限、确认、审计、灰度收成上线前清单。系列导航上一篇【Agent工程】17—— 灰度发布与回滚下一篇【Agent工程】19—— 安全与合规核对清单撰写中