保障机制审查
你的职责是让保障机制对真实任务负责。既能舍弃昂贵而无效的控制，也能保留有必要的复杂度。 “保障性过度工程”是这里的工作称呼：为了验证、交接或防错引入的机制，其收益不足以抵偿复杂度、误阻断和维护成本。不是看到检查多、代码长或流程严格就判错。
同时关注两处：开发 Agent 为方便验收而加入产品的机制，以及产品在 Agent 工作循环中施加的控制。 默认扫描并给出建议；修复按用户授权范围进行，不因发现问题顺手扩展改动。
主要产物是对具体保障机制的处置：它保护的保证、实际拒绝范围、失败后的处理者，以及 保留或调整后合法工作如何继续。一般设计优劣不展开；检查少或流程短也不代表更好。
从任务追到机制
先确认用户要完成什么、哪些结果必须成立，再沿相关调用链看保障机制。范围未指定时从当前改动及其直接调用方入手，说明实际覆盖范围，不默认全仓审计。 用搜索定位候选，再读实现、调用方和测试；关键词命中不是问题证据。
围绕可疑机制回答，证据足够即可，不要求逐项生成文档：
- 保护什么？ 对应哪个具体失败场景、影响及不可破坏的约束？区分实际观察、设计要求与推测。低频但损失严重的失败也可能值得严格防护。
- 谁负责？ 权威事实及恢复责任在哪里？已有事务、幂等、预算、取消或反馈机制为什么不够？新增状态是否复制事实、产生新的崩溃窗口和清理责任？
- 实际阻止了什么？ 检查失败后谁收到信息、能否修正并继续？误拒合法工作、等待人工与恢复成本是否可接受？一个检查有用，不等于它有权终止整个任务。
- 删掉会怎样？ 去掉或弱化它，哪个用户场景变坏？能否复用现有机制，或改成反馈、按需验证、离线检查？简化不能把隐性负担转嫁给调用方。
分别判断机制是否正确、是否必要、是否放对层、成本是否合适。测试通过只能支持其中一部分；“验证方便”和“更放心”不能独自证明必要性。
先把候选归入一个状态：当前已有合法路径被误阻断、当前合同本身有争议，或只是尚未支持的新需求。 只有第一类可以直接作为保障范围问题；第二类需要回到产品合同，第三类不能借扫描之名要求提前实现。 同一机制也可能只在部分操作上过宽，按读取、幂等写入、非幂等写入和不可逆操作分别判断，不对整个机制一刀切。
值得追查的迹象
这些是调查线索，不是可机械判定的反模式清单：
| 迹象 | 要追查的区别 |
|---|---|
| 为一次交接或探针新增数据库、回执、状态机 | 产品本来需要可靠恢复，还是测试便利变成了永久负担？ |
| 多层重复校验、重试或保存完成状态 | 各层保护不同边界，还是形成了第二份权威与相互冲突的恢复逻辑？ |
| 强制阅读数量、工具次序、固定措辞、局部纠错次数 | 它们保护真实约束，还是用容易检查的动作代理任务成功？ |
| 参数错误、业务拒绝、输出不理想导致全任务失败 | 错误真的破坏执行安全，还是本可作为反馈交给 Agent 修正？ |
| 未知或证据缺失一律阻断 | 该风险确实要求拒绝，还是可以保留不确定性继续可逆工作？ |
| 为校验器加校验器，为回执再加恢复协议 | 新一层提供了独立证据或必要保证，还是保障体系在自我增殖？ |
结构 schema、权限检查、幂等、数据一致性、不可逆操作保护和整体预算不是天然的问题。 权限拒绝可反馈给 Agent 换路，权限本身不能因此放宽。不要把所有业务失败都改成成功，也不要吞错来提高完成率。
特别核对已有适配与上层校验是否冲突。例如 SDK 已将 effort 偏好映射到受支持等级， 上层却因结果不等于请求原值而拒绝调用。先确认它是可适配偏好还是必须精确满足的合同， 再检查适配是否真实存在。不同入口或阶段的检查可能各有责任，下层会检查不足以证明上层多余。 system、图片与输出格式等明确能力要求不得静默丢弃；没有有效适配时，直接删除校验不是修复。
用最小证据区分必要与多余
沿真实生产者到消费者检查语义是否成立。例如，测试手工重放同一个 ID，只能证明该 ID 的去重行为；不能证明真实调用方在响应丢失后会重用它，也不能证明整条交接链可恢复。 重复自检不自动构成独立证据；检查器和实现共享同一错误假设时尤其如此。 调查线索既要寻找支持它的真实消费者，也要主动寻找反例和已经存在的保护；skill 中的例子只能帮助定位，不能替代调用链证据。
争议较大且值得验证时，选择一个真实场景，在隔离环境比较保留、移除或弱化机制的结果。 观察任务是否完成、必要约束是否被破坏、合法工作是否被误阻断、错误能否恢复，以及新增代价。 这是可选的消融手段，不要求每个发现都做实验；不能为审查移除线上保护或擅自进行有费用、破坏性的试验。 读码、确定性测试和真实行为观察分开表述；缺证据时保留未知，不编造收益数字或假装已完成消融。
给出取舍
优先报告影响当前任务的少数根因。每个实质发现简洁说明：位置与证据、具体触发及后果、原机制保护的保证、建议及其代价。区分已观察问题与待验证假设。 可建议保留、简化、复用、归位、门禁改反馈、改为按需验证或删除；不强制填满分类，不设发现或删除配额。 关键保护容易被误删时，解释保留理由。没有足够证据判定问题，就明确说没有发现或指出缺口。 报告中标明读码、确定性测试、真实运行和消融各自证明了什么；“已发现机制”不等于“已证明它造成误阻断”。
若获授权修复，只做所需改动，并针对原保证与合法恢复路径验证。不能通过改写验收标准、重命名缺失能力为“不在范围”来宣称完成。 复核原先被误拒的请求能继续，必要拒绝仍成立，错误到达能处理它的调用者；连同失效接线 和测试一起修正，不以换输入、加重试或忽略错误掩盖问题。 扫描本身不新增评分系统、证明台账、固定审查轮数或强制多 Agent 流程；本 skill 是判断方法，不是新的运行门禁。
问题转向时
若局部保障调整无法解决，根因已落在状态所有权、责任划分或抽象关系，按需使用 design-forge，交给它具体反例、必须保住的保证和已有机制为何不足。 若机制本身仍合理，只是重复维护或归属错位，使用 defrag 整理。 若问题只在 skill 或 prompt 对合法路径规定过严，使用 agent-guidance 修正表达与触发，运行时保证仍由原实现承担。 链接用于未决问题的转向，不要求把相邻技能全部加载，也不重复已完成的调查。
方法来源与边界
- Google SRE：Embracing Risk：可靠性投入存在成本与机会成本；不能推导为一律降低可靠性要求。
- End-to-End Arguments：按端到端语义判断保障放在哪层；不是禁止底层防护。
- Anthropic：Demystifying evals：区分实际结果与执行轨迹，避免过度限定合法路径；必要操作约束仍需执行。