Back to Details

vss-manage-alerts

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Purpose

用途

Operate the VSS alert pipeline (mode detection, Alert-Bridge subscriptions, Slack notifications, queries, camera onboarding, verifier-prompt customization).
操作VSS告警流水线（模式检测、Alert-Bridge订阅、Slack通知、查询、摄像头接入、验证器提示自定义）。

Prerequisites

前置条件

  • Active VSS deployment reachable on 
    $HOST_IP
    (see 
    vss-deploy-profile
    and 
    references/
    ).
  • NGC credentials in 
    $NGC_CLI_API_KEY
    and 
    $NVIDIA_API_KEY
    for any image pulls.
  • curl
    , 
    jq
    , and Docker available on the caller.
  • 可通过
    $HOST_IP
    访问的活跃VSS部署（参见
    vss-deploy-profile
    和
    references/
    目录）。
  • 用于镜像拉取的
    $NGC_CLI_API_KEY
    和
    $NVIDIA_API_KEY
    格式的NGC凭证。
  • 调用端需安装
    curl
    、
    jq
    和Docker。

Instructions

操作说明

Follow the routing tables and step-by-step workflows below. Each section that ends in workflow, quick start, or flow is intended to be executed top-to-bottom. Detailed reference material lives in 
references/
and helper scripts live in 
scripts/
— call them via 
run_script
when the skill points to a script by name.
遵循下方的路由表和分步工作流。所有以workflow、quick start或flow结尾的章节都需要从上到下执行。详细参考资料位于
references/
目录，辅助脚本位于
scripts/
目录——当技能指向某个脚本名称时，通过
run_script
调用它们。

Examples

示例

Worked end-to-end examples are kept under 
evals/
(each 
*.json
manifest contains a runnable scenario) and inline in the per-workflow 
curl
blocks below. Run a Tier-3 evaluation with 
nv-base validate <this-skill-dir> --agent-eval
to replay them.
完整的端到端示例保存在
evals/
目录下（每个
*.json
清单包含一个可运行场景），同时内嵌在下方各工作流的
curl
代码块中。运行
nv-base validate <this-skill-dir> --agent-eval
即可重放这些示例，完成Tier-3评估。

Limitations

限制条件

  • Requires the matching VSS profile / microservice to be deployed and reachable from the caller.
  • NGC-hosted models and NIMs may be subject to rate-limits, GPU memory requirements, and license restrictions.
  • Concurrency, GPU memory, and storage limits depend on the host hardware and the profile's compose file.
  • 要求匹配的VSS配置文件/微服务已部署，且调用端可访问。
  • NGC托管的模型和NIM可能受速率限制、GPU内存要求和许可证限制约束。
  • 并发数、GPU内存和存储限制取决于主机硬件和配置文件的compose文件。

Troubleshooting

故障排查

  • Error: REST call returns connection refused. Cause: target microservice not running. Solution: probe 
    /docs
    or 
    /health
    ; redeploy via 
    vss-deploy-profile
    or the matching 
    vss-deploy-*
    skill.
  • Error: HTTP 401/403 from NGC pulls. Cause: missing/expired 
    NGC_CLI_API_KEY
    . Solution: 
    docker login nvcr.io
    and re-export the key before retrying.
  • Error: container OOM or model fails to load. Cause: insufficient GPU memory for the selected profile. Solution: switch to a smaller variant or free GPUs via 
    docker compose down
    .
  • 错误：REST调用返回连接拒绝。原因：目标微服务未运行。解决方案：探测
    /docs
    或
    /health
    端点；通过
    vss-deploy-profile
    或对应的
    vss-deploy-*
    技能重新部署。
  • 错误：NGC拉取时返回HTTP 401/403。原因：
    NGC_CLI_API_KEY
    缺失或过期。解决方案：执行
    docker login nvcr.io
    并重新导出密钥后重试。
  • 错误：容器内存不足（OOM）或模型加载失败。原因：所选配置文件的GPU内存不足。解决方案：切换到更小的变体，或通过
    docker compose down
    释放GPU资源。

VSS Alert Management

VSS告警管理

The alerts profile is deployed in one of two modes at a time. The mode is chosen at 
/vss-deploy-profile -p alerts -m {verification,real-time}
.
  • CV (verification) mode runs the static CV pipeline (RT-CV + Behavior Analytics + 
    alert-bridge
    VLM verifier) and the dynamic 
    rtvi-vlm
    real-time service. Workflow A (static CV alerts) and Workflow B (VLM monitoring) are available; Workflows D and E require VLM real-time mode.
  • VLM (real-time) mode runs only 
    rtvi-vlm
    for dynamic real-time alerts. CV pipeline (RT-CV, Behavior Analytics) is not running, so Workflow A is unavailable.
This skill routes by deployed mode + user intent (monitoring vs subscription CRUD vs Slack webhook operations).
告警配置文件一次仅能以两种模式之一部署。模式通过
/vss-deploy-profile -p alerts -m {verification,real-time}
选择。
  • CV（验证）模式运行静态CV流水线（RT-CV + Behavior Analytics + 
    alert-bridge
    VLM验证器）以及动态
    rtvi-vlm
    实时服务。支持工作流A（静态CV告警）和工作流B（VLM监控）；工作流D和E需要VLM实时模式。
  • VLM（实时）模式仅运行
    rtvi-vlm
    以实现动态实时告警。CV流水线（RT-CV、Behavior Analytics）未运行，因此工作流A不可用。
本技能根据部署模式 + 用户意图（监控 vs 订阅增删改查 vs Slack webhook操作）进行路由。

When to Use

使用场景

  • Start or stop a real-time alert on a sensor ("Start real-time alert for boxes dropped on sensor warehouse_sample")
  • Create, list, or stop realtime subscription rules on Alert Bridge ("List active realtime rules on warehouse-dock-1")
  • Set up or manage Slack incident notifications ("Start alert Slack webhook and send test notification")
  • List or query detected incidents / alerts
  • Add a new camera to the alerts pipeline
  • Customize the VLM-verifier prompts (CV mode)
  • Check verdicts (confirmed / rejected / unverified)
  • 启动或停止传感器上的实时告警（"为warehouse_sample传感器启动实时告警，检测掉落的箱子"）
  • 在Alert Bridge上创建、列出或停止实时订阅规则（"列出warehouse-dock-1上的活跃实时规则"）
  • 设置或管理Slack事件通知（"启动告警Slack webhook并发送测试通知"）
  • 列出或查询已检测到的事件/告警
  • 将新摄像头添加到告警流水线
  • 自定义VLM验证器提示（CV模式）
  • 查看判定结果（已确认/已拒绝/未验证）

Deployment prerequisite

部署前置条件

Requires the VSS alerts profile on 
$HOST_IP
in either 
verification
(CV) or 
real-time
(VLM) mode.
bash
undefined
要求
$HOST_IP
上的VSS alerts配置文件处于
verification
（CV）或
real-time
（VLM）模式之一。
bash
undefined

Either perception-alerts (CV mode) OR rtvi-vlm (VLM mode) must be present.

必须存在perception-alerts（CV模式）或rtvi-vlm（VLM模式）其一。

curl -sf --max-time 5 "http://${HOST_IP}:8000/docs" >/dev/null
&& docker ps --format '{{.Names}}'
| grep -qE '^(perception-alerts|rtvi-vlm)$'

If the probe fails, ask the user which mode to deploy and hand off to
`/vss-deploy-profile -p alerts -m <mode>`. If the user declines, stop. If the
caller pre-authorized autonomous deploy, run it directly with mode
`verification` by default. If it passes, detect the mode per Step 1.

---
curl -sf --max-time 5 "http://${HOST_IP}:8000/docs" >/dev/null
&& docker ps --format '{{.Names}}'
| grep -qE '^(perception-alerts|rtvi-vlm)$'

如果探测失败，请询问用户要部署哪种模式，并转交至`/vss-deploy-profile -p alerts -m <mode>`。如果用户拒绝，则停止操作。如果调用者预先授权自动部署，则默认以`verification`模式直接运行。如果探测通过，请按照步骤1检测模式。

---

The Two Modes (Deploy-Time Choice)

两种模式（部署时选择）

ModeDeploy flagEnv (
.env
)		What runsWhat is available
CV (verification)
-m verification
MODE=2d_cv
RT-CV (Grounding DINO) + Behavior Analytics + 
alert-bridge
VLM verifier + 
rtvi-vlm
Both static CV pipeline (Workflow A) and dynamic VLM real-time alerts (Workflows B/D)
VLM (real-time)
-m real-time
MODE=2d_vlm
alert-bridge
+ 
rtvi-vlm
Only dynamic VLM real-time alerts (Workflows B/D) and 
alert-bridge
backend. No static CV pipeline.
Switching modes requires the 
vss-deploy-profile
teardown and deploy flow with the other 
-m
flag. Going from VLM → CV adds the static CV pipeline; going from CV → VLM tears down the CV pipeline. 
rtvi-vlm
is present in both modes.
模式部署参数环境变量（
.env
）		运行组件可用功能
CV（验证）
-m verification
MODE=2d_cv
RT-CV（Grounding DINO） + Behavior Analytics + 
alert-bridge
VLM验证器 + 
rtvi-vlm
同时支持静态CV流水线（工作流A）和动态VLM实时告警（工作流B/D）
VLM（实时）
-m real-time
MODE=2d_vlm
alert-bridge
+ 
rtvi-vlm
仅支持动态VLM实时告警（工作流B/D）和
alert-bridge
后端。无静态CV流水线。
切换模式需要使用
vss-deploy-profile
的销毁和部署流程，并搭配另一个
-m
参数。从VLM切换到CV会添加静态CV流水线；从CV切换到VLM会销毁CV流水线。
rtvi-vlm
在两种模式下均会运行。

Step 1 — Detect the Currently Deployed Mode

步骤1 — 检测当前部署模式

Before running any alert workflow, check which mode is live. Use CV-only containers as the signal — 
rtvi-vlm
is not a reliable mode signal anymore because it runs in both modes.
bash
undefined
在运行任何告警工作流之前，请检查当前处于哪种模式。以仅CV模式的容器作为判断信号——
rtvi-vlm
不再是可靠的模式信号，因为它在两种模式下都会运行。
bash
undefined

CV verification mode (behavior analytics + perception-alerts are CV-only)

CV验证模式（behavior analytics + perception-alerts为仅CV组件）

docker ps --format '{{.Names}}' | grep -qx vss-behavior-analytics-alerts && echo "mode=CV"
docker ps --format '{{.Names}}' | grep -qx vss-behavior-analytics-alerts && echo "mode=CV"

VLM real-time mode (no CV pipeline; only rtvi-vlm)

VLM实时模式（无CV流水线；仅运行rtvi-vlm）

docker ps --format '{{.Names}}' | grep -qx vss-behavior-analytics-alerts ||
docker ps --format '{{.Names}}' | grep -qx rtvi-vlm && echo "mode=VLM"

If `vss-behavior-analytics-alerts` is present → **CV mode** (which also has `rtvi-vlm`).
If only `rtvi-vlm` is present (and no CV pipeline) → **VLM mode**.
If neither matches, the alerts profile is not deployed — direct the user to the `vss-deploy-profile` skill.

Alternative signal (preferred when `docker ps` isn't accessible): check the profile's `.env`:

```bash
grep -E '^MODE=' deployments/developer-workflow/dev-profile-alerts/.env
docker ps --format '{{.Names}}' | grep -qx vss-behavior-analytics-alerts ||
docker ps --format '{{.Names}}' | grep -qx rtvi-vlm && echo "mode=VLM"

如果存在`vss-behavior-analytics-alerts` → **CV模式**（同时包含`rtvi-vlm`）。
如果仅存在`rtvi-vlm`（且无CV流水线） → **VLM模式**。
如果两者都不匹配，则告警配置文件未部署——引导用户使用`vss-deploy-profile`技能。

替代判断信号（当无法访问`docker ps`时优先使用）：检查配置文件的`.env`文件：

```bash
grep -E '^MODE=' deployments/developer-workflow/dev-profile-alerts/.env

MODE=2d_cv → CV mode (full superset)

MODE=2d_cv → CV模式（完整功能集）

MODE=2d_vlm → VLM real-time mode (rtvi-vlm only)

MODE=2d_vlm → VLM实时模式（仅rtvi-vlm）


---

---

Step 2 — Route by Deployed Mode

步骤2 — 根据部署模式路由

Deployed modeUser asks about…Action
VLM real-timeSlack webhook setup/status/test/stopRun Workflow E (Slack Notifications) — follow 
references/alert-notify.md
VLM real-timesubscription / rule CRUD, or set up / create / watch / flag a realtime alert on a specific sensor with a detection conditionRun Workflow D (Alert Subscriptions) — follow 
references/alert-subscriptions.md
for Alert Bridge rule management.
CV verificationsubscription/rule CRUD or Slack/notification setupRefuse — see Canonical refusal text below
CV or VLMgeneric start/stop monitoring via VSS Agent without a specific detection condition (e.g. "start real-time alert for sensor warehouse_sample")Run Workflow B (VLM) — call the VSS Agent with a detection prompt. 
rtvi-vlm
runs in both modes.
CV or VLMincident lookup / list / query (recent alerts, time-range queries)Run Workflow C (Query) — 
video_analytics_mcp.get_incidents
works on both deployments.
CVstatic CV alert onboarding (just add the camera and let CV pipeline emit alerts) / verdict prompts customizationRun Workflow A (CV) — onboard RTSP via 
vss-manage-video-io-storage
skill; CV pipeline picks it up automatically. No per-request create call.
VLMspecifically a CV / behavior-analytics / PPE-rule alert that requires the static CV pipelineRedeployment required. Confirm with the user first, then point to the 
vss-deploy-profile
skill for 
-m verification
.
Always confirm before triggering a redeploy. A mode switch stops all currently-running monitoring and restarts services.
部署模式用户需求…操作
VLM实时Slack webhook设置/状态/测试/停止运行工作流E（Slack通知）——遵循
references/alert-notify.md
VLM实时订阅/规则增删改查，或为特定传感器设置/创建/监控/标记带检测条件的实时告警运行工作流D（告警订阅）——遵循
references/alert-subscriptions.md
进行Alert Bridge规则管理。
CV验证订阅/规则增删改查或Slack/通知设置拒绝——参见下方标准拒绝文本
CV或VLM通过VSS Agent进行通用启动/停止监控，无特定检测条件（例如"为warehouse_sample传感器启动实时告警"）运行工作流B（VLM）——调用VSS Agent并传入检测提示。
rtvi-vlm
在两种模式下均运行。
CV或VLM事件查询/列出/检索（最近告警、时间范围查询）运行工作流C（查询）——
video_analytics_mcp.get_incidents
在两种部署中均可使用。
CV静态CV告警接入（仅添加摄像头，让CV流水线自动生成告警）/判定提示自定义运行工作流A（CV）——通过
vss-manage-video-io-storage
技能接入RTSP；CV流水线会自动获取流。无需逐请求创建调用。
VLM明确需要静态CV流水线的CV/行为分析/PPE规则告警需要重新部署。先与用户确认，然后引导至
vss-deploy-profile
技能并使用
-m verification
参数。
触发重新部署前务必确认。模式切换会停止所有当前运行的监控，并重启服务。

Intent precedence (first match wins)

意图优先级（匹配即生效）

  1. Workflow E (Slack) — Slack-specific keywords (
    slack
    , 
    webhook
    + 
    slack
    , 
    bot token
    , 
    slack channel
    ). 
    notify
    alone is not sufficient.
  2. Workflow D (Subscriptions) — sensor name plus a detection condition, or rule CRUD keywords (
    rule
    , 
    subscription
    , rule ID).
  3. Workflow B (VLM monitoring) — generic start/stop on a sensor with no detection condition.
  4. Workflow C (Query) — incident lookup (
    show/list incidents
    , 
    recent alerts
    , time-range queries).
  5. Workflow A (CV) — CV deployment handling for anything not matched above.
Disambiguation (B vs D): if a sensor is named with start/monitor language but the detection condition is unclear, ask:
"Do you want me to (a) create a persistent alert rule on Alert Bridge that keeps running until you delete it, or (b) start a one-time monitoring session via the VSS Agent?"
If a prompt mixes workflows ("start monitoring and send to Slack"), ask one clarifying question to split execution order.
  1. 工作流E（Slack）——包含Slack特定关键词（
    slack
    、
    webhook
    + 
    slack
    、
    bot token
    、
    slack channel
    ）。仅
    notify
    一词不足以触发。
  2. 工作流D（订阅）——包含传感器名称以及检测条件，或规则增删改查关键词（
    rule
    、
    subscription
    、规则ID）。
  3. 工作流B（VLM监控）——针对传感器的通用启动/停止操作，无检测条件。
  4. 工作流C（查询）——事件查询（
    show/list incidents
    、
    recent alerts
    、时间范围查询）。
  5. 工作流A（CV）——CV部署下未匹配上述情况的操作。
歧义处理（B vs D）：如果请求包含传感器名称和启动/监控表述，但检测条件不明确，请询问：
"请问您需要我（a）在Alert Bridge上创建持久化告警规则，该规则会持续运行直至您删除；还是（b）通过VSS Agent启动一次性监控会话？"
如果请求混合多个工作流（例如"启动监控并发送至Slack"），请提出一个澄清问题以拆分执行顺序。

CV-mode refusal text for D and E intents

CV模式下针对D和E意图的标准拒绝文本

When the deployed mode is CV verification and the user asks for an alert-subscription or Slack/notification intent, refuse with this message verbatim:
"Alert subscriptions and Slack notifications are only supported in VLM real-time mode. Your current deployment is 
<CV verification | not deployed>
. To use these features, redeploy with 
/vss-deploy-profile -p alerts -m real-time
(note: switching tears down current CV monitoring)."
No auto-redeploy. The user decides whether to switch modes.
当部署模式为CV验证，且用户请求告警订阅或Slack/通知相关操作时，请逐字使用以下消息拒绝：
"告警订阅和Slack通知仅在VLM实时模式下支持。您当前的部署为
<CV验证 | 未部署>
。如需使用这些功能，请通过
/vss-deploy-profile -p alerts -m real-time
重新部署（注意：切换模式会销毁当前CV监控）。"
禁止自动重新部署。由用户决定是否切换模式。

Prereq for Either Mode: Sensor Must Be in VIOS

两种模式的共同前置条件：传感器必须已加入VIOS

Both modes require the camera to be registered in VIOS first.
  • If the user hands you only an RTSP URL (or an IP camera) — defer to the 
    vss-manage-video-io-storage
    skill     to add it via 
    POST /sensor/add
    (see 
    vss-manage-video-io-storage
    skill Section 6). Record the returned 
    sensorId
    / name.
  • If the user names an existing sensor — confirm it is listed by 
    GET /sensor/list
    via the 
    vss-manage-video-io-storage
    skill before proceeding.
On a CV deployment, adding the RTSP is the entire onboarding step — the pipeline picks up the stream automatically once it is in VIOS. On a VLM deployment, adding the RTSP is a prerequisite to Workflow B.
两种模式都要求摄像头先在VIOS中注册。
  • 如果用户仅提供RTSP URL（或IP摄像头）——转交至
    vss-manage-video-io-storage
    技能    ，通过
    POST /sensor/add
    添加（参见该技能第6节）。记录返回的
    sensorId
    /名称。
  • 如果用户指定现有传感器——在继续操作前，通过
    vss-manage-video-io-storage
    技能的
    GET /sensor/list
    确认该传感器已列出。
在CV部署中，添加RTSP就是完整的接入步骤——一旦传感器在VIOS中注册并上线，流水线会自动获取流。在VLM部署中，添加RTSP是工作流B的前置条件。

The Agent 
/generate
Endpoint

Agent 
/generate
端点

All VLM-flow actions and all query actions go through the VSS Agent's natural-language endpoint:
bash
AGENT="http://<AGENT_ENDPOINT>"   # default http://localhost:8000 on the alerts profile

curl -s -X POST "$AGENT/generate" \
  -H "Content-Type: application/json" \
  -d '{"input_message": "<natural-language request>"}' | jq .
Endpoint resolution: use the agent endpoint from the active VSS deployment context. If unavailable, ask the user. Do not discover via filesystem.
Availability check: 
curl -sf --connect-timeout 5 "$AGENT/docs"
.
Do not call the 
rtvi-vlm
microservice endpoints directly — always go through the agent. The agent internally dispatches to 
rtvi_vlm_alert
, 
rtvi_prompt_gen
, and 
video_analytics_mcp.get_incidents
.
所有VLM流操作和查询操作都通过VSS Agent的自然语言端点完成：
bash
AGENT="http://<AGENT_ENDPOINT>"   # 告警配置文件的默认地址为http://localhost:8000

curl -s -X POST "$AGENT/generate" \
  -H "Content-Type: application/json" \
  -d '{"input_message": "<自然语言请求>"}' | jq .
端点解析：使用活跃VSS部署上下文的agent端点。如果不可用，请询问用户。不要通过文件系统查找。
可用性检查：
curl -sf --connect-timeout 5 "$AGENT/docs"
。
请勿直接调用
rtvi-vlm
微服务端点——始终通过agent调用。agent会内部调度至
rtvi_vlm_alert
、
rtvi_prompt_gen
和
video_analytics_mcp.get_incidents
。

Workflow A — CV Mode (
-m verification
/ 
MODE=2d_cv
)

工作流A — CV模式（
-m verification
/ 
MODE=2d_cv
）

CV alerts are deployment-driven, not request-driven — there is no agent call to "create" one.
  1. Check if the sensor is already in VIOS via 
    vss-manage-video-io-storage
    's 
    GET /sensor/list
    (idempotent — never blindly 
    POST /sensor/add
    ).
  2. If missing, onboard via 
    vss-manage-video-io-storage
    POST /sensor/add
    (see that skill's Section 6). The CV pipeline picks up the stream automatically once it is registered and online.
  3. Confirm online: 
    curl -s "http://<VST_ENDPOINT>/vst/api/v1/sensor/<sensorId>/status" | jq .
  4. Wait for alerts to land in Elasticsearch (Behavior Analytics → 
    alert-bridge
    VLM verification per 
    alert_type_config.json
    ). Query results with Workflow C.
If the user asks for a static-CV-pipeline alert on a VLM-only deployment, that is a mode mismatch — see the routing table above.
CV告警是部署驱动，而非请求驱动——无需调用agent来"创建"告警。
  1. 通过
    vss-manage-video-io-storage
    的
    GET /sensor/list
    检查传感器是否已加入VIOS（幂等操作——请勿盲目执行
    POST /sensor/add
    ）。
  2. 如果缺失，通过
    vss-manage-video-io-storage
    的
    POST /sensor/add
    接入（参见该技能第6节）。一旦传感器注册并上线，CV流水线会自动获取流。
  3. 确认在线：
    curl -s "http://<VST_ENDPOINT>/vst/api/v1/sensor/<sensorId>/status" | jq .
  4. 等待告警写入Elasticsearch（Behavior Analytics → 
    alert-bridge
    VLM验证，遵循
    alert_type_config.json
    ）。通过工作流C查询结果。
如果用户在仅VLM部署中请求静态CV流水线告警，属于模式不匹配——参见上方路由表。

Workflow B — VLM Real-time Monitoring (CV or VLM mode)

工作流B — VLM实时监控（CV或VLM模式）

Generic start / stop intents through the VSS Agent for a named sensor without a detection condition (if a condition is present, route to Workflow D). 
rtvi-vlm
runs in both modes.
bash
undefined
通过VSS Agent对指定传感器执行通用启动/停止操作，无检测条件（如果存在检测条件，请路由至工作流D）。
rtvi-vlm
在两种模式下均运行。
bash
undefined

start: input_message = "Start real-time alert for sensor <id>"

启动：input_message = "为传感器<id>启动实时告警"

stop: input_message = "Stop real-time alert for sensor <id>"

停止：input_message = "为传感器<id>停止实时告警"

curl -s -X POST "$AGENT/generate" -H "Content-Type: application/json"
-d '{"input_message": "<start|stop> real-time alert for sensor <id>"}' | jq .

Under the hood the agent calls `rtvi_prompt_gen` then
`rtvi_vlm_alert action="start"`. Alert semantics: every chunk is
captioned; a chunk whose VLM response contains `yes` / `true`
(case-insensitive) publishes an incident to `mdx-vlm-incidents`.
Prompts must force a Yes/No answer. A static-CV-pipeline request on a
VLM-only deployment is a mode mismatch — see the routing table.

---
curl -s -X POST "$AGENT/generate" -H "Content-Type: application/json"
-d '{"input_message": "<start|stop> real-time alert for sensor <id>"}' | jq .

底层逻辑为agent先调用`rtvi_prompt_gen`，再调用`rtvi_vlm_alert action="start"`。告警规则：每个片段都会被标注；如果VLM响应包含`yes`/`true`（不区分大小写），则会向`mdx-vlm-incidents`发布事件。提示必须强制返回Yes/No答案。在仅VLM部署中请求静态CV流水线属于模式不匹配——参见上方路由表。

---

Workflow D — Alert Subscriptions (VLM real-time mode only)

工作流D — 告警订阅（仅VLM实时模式）

Create / list / delete persistent realtime alert rules on Alert Bridge. Route here when the prompt has rule keywords (
rule
, 
subscription
, a rule ID) or when it pairs a specific sensor with a specific detection condition (e.g. "Set up a realtime alert on warehouse-dock-1 for PPE violations", "Watch sensor entrance-1 for tailgating", "Stop rule 496aebd1-…").
Not here: generic start/stop without a condition (→ Workflow B) or Slack operations (→ Workflow E).
Load and follow 
references/alert-subscriptions.md
as the authoritative playbook for subscription CRUD. VLM real-time mode only; refuse with the canonical refusal text on CV.
在Alert Bridge上创建/列出/删除持久化实时告警规则。当请求包含规则关键词（
rule
、
subscription
、规则ID）或将特定传感器与特定检测条件配对时（例如"为warehouse-dock-1设置实时告警，检测PPE违规"、"监控entrance-1传感器的尾随行为"、"停止规则496aebd1-…"），路由至此。
不路由至此的情况：无检测条件的通用启动/停止（→工作流B）或Slack操作（→工作流E）。
加载并遵循
references/alert-subscriptions.md
作为订阅增删改查的权威指南。仅支持VLM实时模式；在CV模式下请求时使用标准拒绝文本拒绝。

Workflow E — Slack Notifications (VLM real-time mode only)

工作流E — Slack通知（仅VLM实时模式）

Use when the user explicitly mentions Slack or the webhook relay (start/stop webhook server, check status/health, send a test message, set Slack channel/token). The word 
notify
alone is not enough.
alert-notify
(port 9090) ≠ 
vss-alert-bridge
(
/api/v1/realtime
). Do NOT touch 
vss-alert-bridge
for Slack ops.
Examples that route here: "Set up Slack notifications for alerts", "Check if alert-notify is running", "Send a test alert notification to Slack", "Start the alert webhook for Slack".
Examples that do NOT route here: "Notify me when someone enters the zone" (→ Workflow D/B), "Alert and notify on my phone" (ambiguous — ask).
Load and follow 
references/alert-notify.md
. Code lives in 
scripts/alert-notify/
. VLM real-time mode only.
当用户明确提及Slack或webhook中继时使用（启动/停止webhook服务器、检查状态/健康、发送测试消息、设置Slack频道/令牌）。仅
notify
一词不足以触发。
alert-notify
（端口9090）≠ 
vss-alert-bridge
（
/api/v1/realtime
）。 请勿为Slack操作调用
vss-alert-bridge
。
路由至此的示例："为告警设置Slack通知"、"检查alert-notify是否运行"、"向Slack发送测试告警通知"、"启动告警Slack webhook"。
不路由至此的示例："当有人进入区域时通知我"（→工作流D/B）、"告警并通知我的手机"（歧义——请询问）。
加载并遵循
references/alert-notify.md
。代码位于
scripts/alert-notify/
目录。仅支持VLM实时模式。

Workflow C — Query / List Alerts (works on either mode)

工作流C — 查询/列出告警（两种模式均支持）

Both CV- and VLM-generated alerts land in Elasticsearch and are queryable via the agent's 
video_analytics_mcp.get_incidents
tool. POST natural-language requests to 
$AGENT/generate
— "Show me recent alerts for sensor X", "List confirmed alerts from the last hour", "Show collision incidents from Camera_02 between 
<ISO>
and 
<ISO>
". For richer / non-natural-language filtering (sensor-level, time-series, counts) use the 
vss-query-analytics
skill (VA-MCP on port 9901).
CV和VLM生成的告警都会写入Elasticsearch，并可通过agent的
video_analytics_mcp.get_incidents
工具查询。向
$AGENT/generate
发送自然语言请求——"显示传感器X的最近告警"、"列出过去一小时内已确认的告警"、"显示Camera_02在
<ISO>
至
<ISO>
时间段内的碰撞事件"。如需更丰富的非自然语言过滤（传感器级别、时间序列、统计数），请使用**
vss-query-analytics
技能**（VA-MCP，端口9901）。

Verdict interpretation (CV mode only)

判定结果解读（仅CV模式）

Verified alerts carry an extended 
info
block:
verdict
Meaning
confirmed
VLM determined the alert is real
rejected
VLM determined it is a false positive
unverified
Verification could not complete (error)
Check 
verification_response_code
(200 = success) and 
reasoning
for the VLM's explanation. VLM-mode incidents are always "confirmed" at source (the trigger itself is a Yes/No VLM answer), so there is no separate verdict field.
已验证的告警包含扩展
info
块：
verdict
含义
confirmed
VLM判定告警真实有效
rejected
VLM判定为误报
unverified
验证无法完成（错误）
查看
verification_response_code
（200=成功）和
reasoning
字段获取VLM的解释。VLM模式下的事件在源头上始终为"已确认"（触发本身就是VLM的Yes/No回答），因此无单独的判定字段。

Customize CV Verifier Prompts (CV mode only)

自定义CV验证器提示（仅CV模式）

CV-path verifier prompts live in 
deployments/developer-workflow/dev-profile-alerts/vlm-as-verifier/configs/alert_type_config.json
. Each entry maps a CV 
alert_type
(the 
category
field emitted by Behavior Analytics) to the VLM 
system
/ 
user
/ optional 
enrichment
prompts.
Key rules:
  • alert_type
    must match the 
    category
    emitted by Behavior Analytics.
  • output_category
    is the display name in Elasticsearch / UI.
  • enrichment
    triggers a second VLM call for a richer description; requires 
    alert_agent.enrichment.enabled: true
    .
  • Edits require an 
    alert-bridge
    container restart to take effect.
VLM real-time prompts are not configured in a file — they are per-request, shaped by 
rtvi_prompt_gen
from the user's natural-language detection description.
CV路径的验证器提示位于
deployments/developer-workflow/dev-profile-alerts/vlm-as-verifier/configs/alert_type_config.json
。每个条目将CV的
alert_type
（Behavior Analytics输出的
category
字段）映射到VLM的
system
/
user
/可选
enrichment
提示。
关键规则：
  • alert_type
    必须与Behavior Analytics输出的
    category
    匹配。
  • output_category
    是Elasticsearch/UI中的显示名称。
  • enrichment
    会触发第二次VLM调用以生成更丰富的描述；需要
    alert_agent.enrichment.enabled: true
    。
  • 修改后需要重启
    alert-bridge
    容器才能生效。
VLM实时提示不通过文件配置——它们是逐请求的，由
rtvi_prompt_gen
根据用户的自然语言检测描述生成。

Cross-Skill Links

跨技能链接

TaskSkill
Deploy, redeploy, or switch alert mode
vss-deploy-profile
 skill — 
/vss-deploy-profile -p alerts -m {verification,real-time}
Add an RTSP / IP camera to VIOS
vss-manage-video-io-storage
 skill — Section 6 (Add Sensor / Stream)
List sensors, take a snapshot, download a clip
vss-manage-video-io-storage
 skill
Time-range incident / occupancy / PPE metrics from Elasticsearch
vss-query-analytics
 skill (VA-MCP :9901)
Generate a detailed incident report from an alert
vss-generate-video-report
 skill
Alert subscriptions (create/list/delete rules)Sub-workflow: 
references/alert-subscriptions.md
Forward incidents to Slack webhookSub-workflow: 
references/alert-notify.md
, code in 
scripts/alert-notify/
任务技能
部署、重新部署或切换告警模式**
vss-deploy-profile
**技能——
/vss-deploy-profile -p alerts -m {verification,real-time}
将RTSP/IP摄像头添加至VIOS**
vss-manage-video-io-storage
**技能——第6节（添加传感器/流）
列出传感器、拍摄快照、下载片段**
vss-manage-video-io-storage
**技能
从Elasticsearch获取时间范围事件/占用率/PPE指标**
vss-query-analytics
**技能（VA-MCP :9901）
根据告警生成详细事件报告**
vss-generate-video-report
**技能
告警订阅（创建/列出/删除规则）子工作流：
references/alert-subscriptions.md
将事件转发至Slack webhook子工作流：
references/alert-notify.md
，代码位于
scripts/alert-notify/

Gotchas

注意事项

  • alert-notify
    (port 9090) ≠ 
    vss-alert-bridge
    .     "Slack webhook" → Workflow E (
    alert-notify
    ). Never route Slack intents to 
    vss-alert-bridge
    's 
    /api/v1/realtime
    .
  • Workflow scope by mode: Workflow A is CV-only. Workflows B and C work on either mode. Workflows D and E (subscriptions and Slack) are VLM real-time only — refuse with the canonical refusal text if attempted on CV.
  • Don't use 
    rtvi-vlm
    container presence as a mode signal.     It runs in both modes. Use 
    vss-behavior-analytics-alerts
    (CV-only) or the 
    MODE
    env var instead.
  • A mode switch tears down the current deployment. Any running VLM monitoring streams and any CV alert state not already in Elasticsearch will be lost.
  • Don't call the 
    rtvi-vlm
    microservice directly     from this skill. Always go through 
    $AGENT/generate
    . The agent handles sensor→RTSP lookup, stream registration, and teardown.
  • Sensor must already be in VIOS for either mode. If the user hands you only an RTSP URL, use the 
    vss-manage-video-io-storage
    skill first.
  • VLM alert trigger is a 
    "yes"
    / 
    "true"
    token match     on the VLM response (case-insensitive). 
    rtvi_prompt_gen
    enforces the Yes/No pattern — don't hand-craft prompts that break it.
  • Stopping a VLM alert is one agent call ("Stop real-time alert…"); the agent handles both the caption-stream and the stream-registration teardown.
  • Prompt changes to 
    alert_type_config.json
    need an 
    alert-bridge
    restart.     
    alert_agent.enrichment.enabled: true
    is required for the 
    enrichment
    prompt to fire.
bump:1
  • alert-notify
    （端口9090）≠ 
    vss-alert-bridge
    。     "Slack webhook" → 工作流E（
    alert-notify
    ）。请勿将Slack意图路由至
    vss-alert-bridge
    的
    /api/v1/realtime
    。
  • 工作流范围取决于模式：工作流A仅支持CV模式。工作流B和C支持两种模式。工作流D和E（订阅和Slack）仅支持VLM实时模式——在CV模式下请求时使用标准拒绝文本拒绝。
  • 请勿将
    rtvi-vlm
    容器的存在作为模式信号    。它在两种模式下均运行。请使用
    vss-behavior-analytics-alerts
    （仅CV组件）或
    MODE
    环境变量。
  • 模式切换会销毁当前部署。所有正在运行的VLM监控流以及未写入Elasticsearch的CV告警状态都会丢失。
  • 请勿直接调用
    rtvi-vlm
    微服务    。始终通过
    $AGENT/generate
    调用。agent会处理传感器→RTSP查找、流注册和销毁。
  • 传感器必须已加入VIOS才能在两种模式下使用。如果用户仅提供RTSP URL，请先使用
    vss-manage-video-io-storage
    技能。
  • VLM告警触发条件是VLM响应中匹配
    "yes"
    /
    "true"
    令牌    （不区分大小写）。
    rtvi_prompt_gen
    会强制Yes/No格式——请勿手动编写破坏该格式的提示。
  • 停止VLM告警只需一次agent调用（"停止实时告警…"）；agent会处理字幕流和流注册的销毁。
  • 修改
    alert_type_config.json
    中的提示需要重启
    alert-bridge
    。
    alert_agent.enrichment.enabled: true
    是
    enrichment
    提示生效的必要条件。
bump:1