> ## Documentation Index > Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt > Use this file to discover all available pages before exploring further. # 运行并审查审计 > 运行审计，验证其覆盖范围，并检查最终的发现结果。 在审计目标和范围足够明确、其他运营人员能够判断有效发现标准之后，再运行审计。 ## 运行并检查 1. 前往 **Analyze → Audits**，打开相应审计，选择 **run now**。显示排队状态表示调度器即将启动该审计。 2. 打开新运行，查看其状态、时间窗口、持续时长、发现数量及报告。 3. 选择证据会话以打开精确的追踪记录。 4. 返回审计页面，可编辑设置、禁用计划，或查看历史运行记录。 审计详情页，显示未解决的发现、上次与下次运行状态、扫描窗口、上下文、立即运行控件及排名发现。 ```bash theme={null} fp audits run checkout-reliability fp audits runs checkout-reliability --limit 10 fp --json audits runs checkout-reliability fp audits findings --audit checkout-reliability ``` 参阅 [`fp audits` 参考文档](/zh/reference/cloud-cli#audits)，了解运行历史、发现结果及分类处理命令。 ## 运行前准备 * 确认所选时间窗口内存在会话数据。 * 验证环境与代理过滤条件。 * 检查参考上下文是否为最新内容。 * 确保目标描述的是故障模式，而非预期结论。 ## 审查运行结果 从运行状态、会话覆盖情况以及模型分析是否已执行开始审查。随后逐条检查每项发现的严重程度、描述、证据会话、支撑查询及建议的预防路径。 使用发现状态功能对其进行确认、静默、驳回、解决、重开或分配处理。即便驳回某项发现，也应保留其证据；这些证据能说明当初做出该决定的原因。 ## 解读空结果或延迟运行 | 运行状态 | 含义 | 处理方式 | | ------------- | ------------------------------------------------------- | ---------------------------------------------------- | | 分析已完成但未产生任何发现 | 在当前灵敏度配置下，所选证据不足以支撑发现。 | 确认范围内包含具有代表性的会话，若目标和上下文描述清晰，可将结果视为健康状态。 | | 模型分析被跳过或失败 | 运行以零发现完成，但并未执行代理调查。确定性凭证与 PII 扫描仍会在运行统计中报告匹配数量，但不会创建发现。 | 修复分析服务或配置后重新运行。不要将空结果解读为目标总体健康的证据。 | | 模型分析已禁用 | 运行以零发现成功完成。确定性扫描无法替代模型分析或创建发现。 | 请启用模型分析，或直接禁用该审计，而非依赖一个无法产生发现的审计。 | | 当前没有可用的分析容量 | 审计保持排队状态并进行重试，而不会跳过当前总体数据。 | 等待容量释放，或分散审计锚点。自托管运营人员应扩展 audit-agent 副本数量及相应的调度器容量。 | | 在重试窗口内容量持续不可用 | 运行放弃并以零发现结束，并在可发送邮件时发送失败通知。 | 检查审计集群是否已饱和或持续重启。 | 当分析未能运行时，`since_last` 类型的审计会将未分析的窗口保留至下次成功运行。现有发现不会被自动关闭，因为跳过分析并不能证明故障已消失。 ## 了解失败通知 运行失败或模型分析步骤失败时，系统将使用该审计配置的邮件收件人。若审计未配置邮件渠道，Failproof AI 将回退至组织级别的 `alerts.email_default_recipients` 设置，以确保静默故障的审计仍有上报路径。 组织必须已启用邮件功能且配置了 SMTP，否则失败事件仅会被记录日志，无法发送邮件通知。运行失败不会影响审计的固定计划锚点。 每次运行还会为每个代理使用的确切[代理上下文](/zh/audits/agent-contracts)存储一份合约快照。后续编辑不会更改早期运行所记录的证据标准。 不要直接根据未经验证的发现部署拦截策略。请先打开所引用的追踪记录，确认该规则能够将不安全行为与正常工作区分开来。