响应规则

响应规则决定一类事件来了该做什么。规则存放在虹元，类型为 response，智悟只读。每次登记追加一个新版本，旧版本保留，规则变化有据可查。

规则体

一条完整的规则：

json

{
  "priority": 10,
  "enabled": true,
  "match": {
    "event_types": ["person.fight", "person.*"],
    "min_severity": "medium",
    "hours": [20, 6],
    "tz_offset_min": 480,
    "site_refs": ["<场站编码>"],
    "camera_refs": ["<摄像头编码>"]
  },
  "action": {
    "kind": "notify",
    "severity": "critical",
    "channels": ["feishu", "sms"],
    "assignee_org": null,
    "due_minutes": 15,
    "cooldown_s": 300,
    "llm": true,
    "message": "{camera} 发生 {type},请立即处置"
  }
}

登记时外层再包一层：tenant_code（必填）、name（规则名，如 resp.person.fight）、kind 固定为 response。

匹配条件

字段	说明
`event_types`	事件类型列表，精确匹配或末尾 `` 通配，如 `vehicle.`
`min_severity`	最低严重度，四级：`low` < `medium` < `high` < `critical`
`hours`	当地时间窗，跨夜写成 `[20, 6]`
`tz_offset_min`	现场时区相对 UTC 的分钟数，配合 `hours` 用
`site_refs`	只对这些场站生效
`camera_refs`	只对这些摄像头生效

条件都是可选的，写了才检查。租户先于一切条件：规则只对它登记的租户生效。

通配符别写太宽

烟火规则写 fire.* 会把夜间异常光源（fire.night_light）一起吃掉。要分开处理的类型，各写各的精确码。

动作

字段	说明
`kind`	`notify` 通知、`dispatch` 派单、`review` 待复核。不写默认待复核
`severity`	任务严重度。不写取事件自己的严重度，再没有取 `medium`
`channels`	通知通道，认 `feishu`、`sms`、`inbox` 三个值，其他值丢弃
`assignee_org`	派单给哪个组织
`due_minutes`	处置时限，分钟。到期未接手会触发超时升级
`cooldown_s`	冷却秒数。同租户、同摄像头、同类事件、同规则在冷却期内只通知一次
`llm`	要不要补大模型语境摘要，默认开
`message`	消息模板

冷却只对通知类动作生效。冷却期内的事件仍落任务，标"已抑制"，看板上能统计到。

消息模板占位符

占位符	内容
`{camera}`	摄像头名称，没有名称时退回编码
`{camera_ref}`	摄像头编码
`{type}`	事件类型中文名，如"打架斗殴"
`{type_code}`	事件类型原码，如 `person.fight`
`{severity}`	严重度中文：低、中、高、紧急
`{severity_code}`	严重度原码
`{site}`	场站
`{time}`	发生时间
`{event_id}`	事件编号

不写 message 时用默认模板："{camera} 发生 {type}(等级 {severity}),请处置"。

优先级与默认裁定

规则按 priority 从小到大排，首个命中即定，后面的不再看。建议留出间隔（10、20、30），方便日后插规则。

没有任何规则命中时，智悟落一条默认待复核任务：严重度按事件自己的等级，高及以上记高，其余记低；不通知，不设时限，不补摘要。消息是"{camera} 发生 {type}, 无匹配响应规则, 待人工复核"。

一套起步规则

按事件类型分档是常见写法：

优先级	匹配	动作
5	烟、火	通知，紧急，飞书 + 短信，时限 5 分钟，冷却 120 秒
10	打架、倒地	通知，紧急，时限 10 到 15 分钟，冷却 300 秒
20	攀爬、周界入侵、危险区域靠近	通知，高，时限 15 分钟，冷却 180 秒
30	夜间异常光源、强光干扰，限夜间时段	通知，高，时限 20 分钟
40	车辆类	派单，中，时限 30 分钟，冷却 600 秒
90	防护装备、聚集、环境、设备类	待复核，低，不通知

最后一档量大、单帧噪声多，只落任务不通知，等人看。

登记、生效、停用

登记。 走虹元的规则对象接口，或值守台的 POST /api/mind/rules。从门户进入的用户只能登记本租户的规则。
生效。 智悟每 60 秒重新加载一次；登记成功后也会主动触发；POST /api/uanmind/rules/reload 可立即触发。
停用。 登记一个 enabled: false 的新版本，再登记 true 恢复。不删记录。
查看。 GET /api/uanmind/rules 返回当前内存里的规则摘要；值守台"响应规则"页能看列表并启停。

查看与重载两个接口都要登录：从门户进入的会话，或请求头带管理密钥 x-admin-key。客户租户的会话只看得到自己租户的规则。

规则体不合法会被跳过并计数，状态接口的 badRules 能看到。缺 tenant_code 的规则按坏规则丢弃：宁可少一条规则，也不能有一条对所有租户生效的规则。

判定阈值

置信门槛、轨迹关联门槛、超时升级宽限这几个数也当规则管，类型为 threshold，规则名固定 threshold.uanmind，每租户一份：

字段	含义	兜底默认
`judge_min_conf`	行为判定置信门槛，低于它判误报	0.6
`traj_min_link`	轨迹关联分数门槛	0.5
`traj_link_gap_s`	跨相机两段最大间隔，秒	900
`traj_same_cam_gap_s`	同相机断续再续的最大间隔，秒	120
`escalate_grace_s`	超时升级宽限，秒；负数关闭升级	0

字段全可选，只登记想改的。越界值拒收并保留原值。虹元拉不到时沿用上次的值，不重置。

虹元不可达时

每次从虹元拉成功，智悟把响应规则、提示词、阈值、模型台账四类口径原样写进本地缓存文件（默认工作目录下的 rules_cache.json，可用 RULES_CACHE_FILE 改路径，配成 off 不落盘），只留本实例服务的租户。启动时先读缓存，虹元拉不到时继续用。

状态接口的 ruleSource 标出每类口径的来源：core 取自虹元，cache 取自缓存，builtin 是内置兜底。来自缓存时写明那份口径是什么时候从虹元取到的。

缓存只存口径，不存事件和游标。

响应规则 ​

规则体 ​

匹配条件 ​

动作 ​

消息模板占位符 ​

优先级与默认裁定 ​

一套起步规则 ​

登记、生效、停用 ​

判定阈值 ​

虹元不可达时 ​

相关文档 ​