Deep Hat Sift：跳过智能体运行，也需要明确批准

运维智能体可以出色地审查警报，但仍会花大部分时间得出不需要发生任何事情的结论。当事件量足够大时，那些正确却没有后续动作的运行就成为系统设计问题。

Kindo 于 2026 年 10 月 28 日发布 Deep Hat Sift，一个 System One 决策模型，它从智能体的判决中学习并评估哪些新事件值得启动智能体。它从影子模式开始，传递所有内容，只有在某人批准阈值后才开始拦下。 Kindo的公告。

有趣的部分是对不执行这一决定的批准：一次根本没有启动的运行。本指南解释了这一决定，将其与更简单的成本控制进行了比较，并概述了一个试点，该试点可以衡量重要的漏检以及避免的调用。

马里兰大学物理安全监控中心，2008 年发布。历史警报监控背景；这不显示 Kindo、Sift 或网络安全仪表板。照片：UMD-Eskin，公共领域；已缩放并添加留白。 图片来源 · 许可与图片说明. 官方产品参考。

省下一次运行，也会改变系统能够观察到的内容

当每个事件到达智能体时，系统可以检查每个判决。一旦过滤器开始阻止事件，简单的反馈路径就会发生变化。被认为最不有趣的事件成为不再受到智能体充分关注的事件。

这使得过滤不同于为同一请求选择更便宜的模型。更便宜的模型仍然会为每个事件生成结果。拦下决定会从普通路径中删除执行。测量计划必须考虑到缺失的结果。

我们的看法：跳过是一种有明确负责人的产品行为。有人必须决定哪些证据可以接受，哪些类型的事件仍然受到保护，以及当来源发生变化时会发生什么。将其视为不可见的优化会使这些决策更难以审查。

将过滤器视为调度台。它有用的工作是继续发送正确的工作，同时记录留下的工作。调度的质量很重要，因为下游专家无法调查它从未收到的东西。

对于试点，在定义过滤器的成功之前定义智能体的工作。智能体是否识别事件、请求更多背景信息、分派工单或准备调查？ “需要执行一次”应该与该工作相对应。否则，模型可能会学到与团队始终一致却不符合运营目的的判断。

中描述的从影子观察到批准的工作流程的原创说明图 Kindo的公告。这是一个简化的操作视图，而不是部署图。

影子模式在更改交付之前创建比较

Kindo 10 月 28 日发布的版本描述了一个初始观察期，其中 Sift 对事件进行评分，同时所有事件仍到达目标智能体。然后，它会根据该来源的结果预览建议的拦截行为；批准包括书面原因，并且在激活后继续进行随机抽样以发现漏检。 公布操作方法。

这样的顺序为运营团队提供了有用的反事实。在更改交付之前，它可以询问哪些历史运行会在建议的操作点消失。这个问题足够具体，可以与负责事件来源和智能体的人员一起审查。

预览应包括示例和汇总。一大批例行事件可以主导总体处理比例，而一小部分但重要的类别表现不佳。要求审批者检查遗漏会造成高昂代价的事件以及位于拟议边界附近的事件。

观察时间应遵循覆盖范围。忙碌的工作日可能与周末、发布日或异常事件不同。仅当日历期间包含对决策至关重要的条件时，它才有用。避免将一定数量的安静天数视为普遍的准备信号。

批准应注明预期的操作条件。诸如“已批准此来源和智能体，以及这些排除和此审核间隔”之类的记录比简单的“是”更有用。当源模式、智能体提示或操作优先级发生变化时，它为团队提供了重新审视的机会。

三个说明性队列需要不同类型的谨慎

重复的基础设施警报可以是一个很好的有界起点

想象一下，SRE 队列在日常维护期间接收到已知通知的多次重复。该团队已经了解来源，并拥有紧急异常情况的既定处理路径。试点可以检查智能体是否反复花费时间来达成相同的不采取行动的判决。

首先将已知的重复处理与新决策分开。如果简单的关联规则已折叠相同的事件，请保留该基线。使用模型评估来检查剩余的变化，这些变化使完整的智能体运行成本高昂或不必要。

在影子观察期间，将建议跳过的事件与智能体实际执行的操作进行比较。寻找严重性、受影响的服务或上下文的变化，这些变化使表面上相似的事件变得不同。有用的问题是过滤器是否保留了操作已经认为重要的区别。

说明性成功标准可能需要指定的审核率并且在评估期间不得遗漏受保护类别中的事件。这些条件由团队选择；它们不是通用的 Sift 保证。这项工作应该对一个来源做出明确的决定，而不是立即在整个组织范围内推广。

网络钓鱼报告队列使失误的成本更加明显

考虑一个示例性安全团队，其员工报告可疑消息。许多报告可能不需要采取进一步行动，但罕见的可采取行动的消息可能会尤为重要。过滤器的经济性取决于这种不对称性。

对于此来源，检查类似于普通信件的示例，同时包含团队关心的标志。保持下游安全工具和事件流程到位。人工智能智能体前面的过滤器应该针对路由决策进行评估，而不是被视为整个检测程序。

评估应由了解错过调查后果的分析师参与。财务利益相关者可以帮助量化运行成本，但无法单独定义可接受的事件覆盖范围。门槛是共同的运营选择，其批准需要正确的专业知识。

还审查智能体自身的错误。学习预测智能体不采取行动的判断可以重现智能体的盲点。单独的分析师审查集可以揭示智能体和过滤器彼此同意但不同意团队期望结果的情况。

工单队列需要定义有用的操作

在示例性服务台中，工单可能看起来很例行公事，但仍然需要确认、服务级别计时器或路由步骤。因此，“无需调查”和“无需运行智能体”可能是不同的标签。准确定义不执行所会省略的内容。

必要时，将强制性工作流程操作保留在不明确的决策之外。例如，票务系统可以保留对必要的收件确认的责任，而该模型有助于决定特定的调查智能体是否应该运行。这使得边界更容易解释。

测试来自不同团队、语言和请求类型的工单。主要针对一个部门的例行请求进行训练的过滤器可能与另一部门的升级模式无法匹配。针对具体来源的评估比假设仅凭事件量就认定两个队列等同更有用。

对于此试点，输出可能是更干净的调查队列而不是更少的工单。测量人类交接以及到下一个有意义的行动的时间。这使得评估与服务质量相关，而不是仅与模型调用次数相关。

四种成本控制手段回答不同的问题

以下比较描述了团队可以评估的设计选择。它并不声称特定供应商的实现赢得了每个类别。多个控件可能属于同一系统，因为它们在不同的点运行。

此比较从决策开始，这有助于避免重复计算节省。如果关联规则已删除重复事件，则过滤器也不能声称已阻止相同的下游运行。在现有控制之后定义基线，然后计算增量效果。

包括过滤器自身的运行成本。托管、监控、抽样运行和人工审核都属于试点的会计工作。一个提供商端点的较小账单很有用，但它只是完整工作流程的一个组成部分。

质量与成本属于同一话题。节省大量调用同时隐藏有用工作的阈值已经改变了服务。团队应该能够用实际队列的语言来解释这种权衡，而不是单一的通用准确率百分比。

用抽样漏检结果提出更好的问题

Kindo 的 常问问题，11 月 2 日检查，描述了默认值 3% 的抽样放行比例，可配置范围为 1% 至 5%，以及默认至少积累 400 条已标注判定。它说分布漂移或命中突破触发上限会使系统恢复到影子行为。这些是已发布的操作默认值，而不是为每个工作负载提供足够证据的保证。

一个说明性的计算说明了为什么样本覆盖率很重要。假设有 10,000 个事件会被拦下并采样 3%；产生大约 300 个采样事件。如果重要的案例很少见，团队仍然需要检查样本是否代表了其遗漏会产生影响的类别。该算术说明了采样问题，并没有估计 Sift 的实际错误率。

在您自己的评估中至少报告两个分母。其中之一描述了过滤器可能会错过的可操作事件。另一个描述了后来被判定为可采取行动的被拦下的事件的比例。这些回答了不同的操作问题：重要工作的覆盖范围和跳过集合中应采取行动事件的占比。

按源类型、严重性、团队和更改相关的输入格式检查切片。总体可以改善，而小类别则可以退化。这些类别应该反映操作的风险和工作量，而不是使图表最容易绘制的任何分组。

最后，将智能体的判断与独立审查的结果分开。与智能体判断的一致性衡量 Sift 对该智能体的预测效果。它本身并不能证明智能体的判断是正确的。当含义明确时，这两种措施都会有用。

原创决策审查辅助图。它说明了操作员应该比较的内容，并且不包含测量的节省或准确性值。抽样和批准记录在 Kindo的产品页面。

当前部署有试点必须考虑的限制

截至 11 月 2 日，Kindo 将 Sift 描述为面向 Kindo 智能体的自托管服务。它的常见问题解答列出了 单主机 Docker Compose 部署、无集群或故障转移以及没有 SSO 或 MFA 的本地帐户。没有单独的 Sift 免费试用或使用套餐。 当前版本常见问题解答。

这些条件会影响试点的适应位置。与负责身份、可用性和事件响应的人员一起审查部署边界。成功的评分演示并不能回答服务是否符合组织的运营要求。

1. 列出一个事件来源、智能体和决策负责人。 写下智能体的作用以及跳过的运行会省略的内容。保留现有的检测和票务职责。
2. 使用 Kindo 查看当前部署要求。 确认可用的托管安排以及您的团队将拥有的运营支持。
3. 定义批准的基线。 包括现有规则、相关性和模型路由，以便试点测量增量价值。
4. 从影子模式开始。 在更改交付之前收集代表性判断并检查跨重要类别的拟议拦截行为。
5. 独立审查错误。 包括分析师审查的示例和受保护的案例，而不是完全依赖与目标智能体判断的一致性。
6. 批准具体操作点和理由。 记录范围、审核人员、抽样方案以及需要再次审核的条件。
7. 练习返回影子模式路径。 确认操作员看到的内容以及完整流如何再次到达智能体。在最终评估中保留成本、质量和可用性。

结果应该是有明确负责人、边界清楚的运营决定。如果试点揭示了一个不确定的类别，那么将其保持在全面分析路径上是一个有用的结果。关键是要了解拦下的合理性，而不是一有机会就最大限度地跳过事件。

只有能说明没有掩盖重要工作，省下的调用才有价值

Sift 给智能体工作流程带来了一个重要问题：哪些事件值得完全执行，谁负责该边界？它的影子优先方法为团队提供了一个在使用决策改变交付之前检查决策的地方。

持久的衡量标准是操作是否可以显示省下的运行、观察到的漏检以及当前阈值仍然合适的原因。这就是将未发生的执行转变为有人可以支持的决定的原因。

来源

• Kindo 的 Deep Hat Sift 公告，通过美通社发布，2026 年 10 月 28 日，美国东部时间 09:00。
• Kindo：Deep Hat Sift 产品详细信息和当前版本常见问题解答，2026 年 11 月 2 日检查。

保留决策背后的材料

Telli.sh 是一个选择，可将获准保存的原始资料与审阅后的笔记放在一起。 创建笔记工作区。