视觉语言模型使得构建能够在生产规模上理解视频的视觉 AI 智能体成为可能。更困难的问题在于，如何将这种能力转化为一个可维护的系统，该系统结合了摄取、流处理、事件检测、检索、摘要和报告。
NVIDIA Metropolis 视频搜索与摘要蓝图（VSS）及其智能体技能帮助开发者更快地构建视觉 AI 智能体。VSS 连接了视觉语言模型（VLM），如 NVIDIA Cosmos，LLM，如 NVIDIA Nemotron，检索增强生成（RAG）和模型上下文协议（MCP）工具，将实时和录制的视频转化为自然语言搜索、视觉问答、经过验证的警报和自动报告。
VSS Blueprint 3.3 还从两方面降低了成本：通过新的 Build Vision Agent 技能（vss-build-vision-ai
）加快应用组合，以及通过自适应高效视频采样（EVS）在运行时降低 VLM 处理成本。
本文涵盖成本降低的两个方面。在开发方面，单个提示在 30 分钟内构建并部署一条装瓶线溢出智能体，仅需几美元的编码智能体使用费。在运行时方面，自适应 EVS 为 60 分钟摘要减少了 80% 的 VLM 输入令牌，并在同一 GPU 上增加了 46% 的并发流。
要了解更多信息，请于太平洋时间 10 月 1 日上午 9 点加入我们的直播，我们将通过单个提示构建一个视觉 AI 智能体。
视频 1：一个提示构建并部署了一个用于橙汁装瓶线的视觉 AI 智能体，然后该智能体发出并验证溢出警报。溢出是为演示合成生成的
为什么视觉 AI 智能体成本高昂
生产环境中的视觉 AI 智能体通常跨越多个工作流。智慧城市应用可能需要车辆检测、碰撞警报、可搜索的事件片段、每小时摘要和操作员报告。仓库应用可能需要人员和叉车跟踪、险情警报、SOP 检查和后续问答。每个工作流本身都有用，但只有当这些工作流协同工作时，实际部署才变得有价值。
这产生了 3 个反复出现的成本驱动因素：
开发成本：团队必须选择并连接微服务、共享服务（如 Kafka、Redis、Elasticsearch 和视频 IO 与存储（VIOS））、模型端点、环境变量和 API，而无需重复基础设施。运营成本：视觉 AI 工作负载可能导致大量令牌使用，每增加一个流、帧窗口、提示和视觉令牌，都可能增加 GPU 使用率、排队延迟和端到端摘要延迟。- 变更成本：团队必须从概念验证转向生产，添加功能，并保持配置、文档和运营的一致性。
用于构建和运行视频分析 AI 智能体的 VSS 3.3 更新
VSS Agent Skills 允许编码智能体（如 Claude Code、Codex 或任何兼容 agentskills.io 的智能体）通过自然语言请求部署和操作 VSS。VSS 3.3 增加了两项更新，降低了部署两方面的成本：
构建视觉智能体技能（vss-build-vision-ai）：将 VSS 工作流（如告警、搜索和摘要）整合到一个应用程序中，用于 SOP 合规或交通管理等场景，并可在不重建整个堆栈的情况下扩展正在运行的部署。自适应 EVS：这项新功能通过修剪帧中与前一帧相比未发生变化部分的视觉 token，并围绕事件发生的时刻批量处理 VLM 工作，从而减少冗余的 VLM 处理。EVS 已在 vLLM 和 Cosmos NIM 微服务中以固定修剪率发布。VSS 3.3 中的自适应版本集成到实时 VLM 微服务中，并针对每个补丁和每帧决定保留哪些 token。
图 1. 一个提示词变成一个组合、验证、运行的视觉 AI 智能体，此处用于仓库，然后回答关于其视频的问题
构建视觉智能体技能通过组合和扩展部署来降低开发和变更成本。自适应 EVS 通过减少 VLM token 和花费在未变化视频上的 GPU 时间来降低运营成本。
使用构建视觉智能体技能降低开发成本
早期的 VSS 技能处理单个操作，如部署、摄像头设置、摘要、搜索、告警和分析。VSS 3.3 将它们组织为部署技能、操作技能、工具和基准，并由 vss-build-vision-ai 组合其余部分。
开发者描述他们想要的应用程序，构建视觉智能体技能将该意图转化为涵盖配置文件、微服务、配置和运行时操作的部署计划。
该技能不是从头生成部署，而是从四个经过验证的开发者配置文件中最接近的一个开始，每个配置文件都是一个工作流的完整、经过测试的堆栈（见下方表 1）。该技能将该起始配置文件称为 Foundation，并仅更改请求所需的内容。
配置文件 | 能力 |
base | 对片段进行 VLM 密集描述和问答 |
alerts | 实时 VLM 告警，或带行为分析和 VLM 告警验证的 RT-CV 检测 |
lvs | 长视频摘要 |
search | 对象和视频嵌入与智能体搜索 |
表 1：构建可以从中开始的四个开发者配置文件。该技能选择一个作为 Foundation，并在其基础上计算最小的增量
然后该技能计算最小的增量：仅添加或删除确切的服务键，仅保留请求的能力实际到达的服务，并将共享角色收敛到一个实例上。
两个都需要检测器的能力得到一个检测器。两个都需要 Kafka 和 Elasticsearch 的能力共享一个消息总线和一次 Elasticsearch 部署，各自写入自己的索引。当规则无法确定选择时，该技能会提出一个结构化问题，而不是猜测。
图 2：每次构建都是在经过验证的 Foundation 之上的增量：只添加某项能力所需的内容，剪除无人触达的部分，并将共享角色收敛为单一实例
该技能自动化的内容
- 将应用目标映射到所需的 VSS 工作流和微服务。
- 将告警、搜索和摘要等工作流组合到一个部署计划中。
- 复用共享基础设施，包括 VIOS、Kafka、Redis、Elasticsearch、HAProxy ingress 和 MCP 服务。
- 将部署生成为自包含的构建：_builds/
/override.env（Foundation、生效的 Compose profiles，以及仅你更改过的设置）、compose.yml 和 resolved.yml——一个通过 docker compose config 生成的扁平化 Compose 文件，可独立部署。仓库的 deploy/docker/ 目录树绝不会被修改。 - 在写入或部署任何内容之前展示架构图以供审查，然后运行验证、部署和就绪检查，使开发者能够在构建应用逻辑之前先验证整个技术栈。
- 询问是否部署 agent harness。默认是 NemoClaw，一个安装了 VSS 技能的主机侧沙箱；回答否将生成由 VSS CLI 驱动的无头技术栈。 - 通过更小的增量扩展现有部署，复用已有服务。
这缩短了探索过程，使组合可重复，并避免跨工作流重复建设摄取、存储、消息传递和分析基础设施。
使用 VSS 构建装瓶线视觉 AI agent
对于一条橙汁装瓶线，团队希望有一个 agent 能够监视灌装机和封盖机摄像头，在溢出或洒漏时告警，搜索过往事件，并生成班次报告。
手动开发需要连接事件检测、告警验证、存储、搜索摄取、摘要和报告。借助 Build Vision Agent 技能，开发从期望的结果开始。
示例提示词
Build a VSS vision agent for an orange juice bottling line. Use two RTSP cameras on the filler and capper. Detect bottle overflows and juice spills, verify each alert with the VLM, make alert clips searchable, and generate a shift report for the line supervisor.
该 agent 所组装的内容
- 由 VIOS 支持的 RTSP 摄像头和录制片段摄取。
- 实时检测、跟踪、字幕生成或基于 VLM 的告警，具体取决于 Foundation profile。
- 针对溢出、洒漏和产线停机事件的行为分析或规则。
- VLM 验证，确认告警并解释其推理过程。
- 跨已验证片段和已索引视频的自然语言搜索。
- 用于操作员交接和事件审查的摘要与报告。
- 共享的消息传递、存储、API 和可观测性。
在配备两块 GPU 的 RTX PRO 6000 Blackwell 主机上，该技能通过复用现有服务并仅添加一个告警桥接和实时 VLM，将搜索与告警结合起来。FP8 Cosmos 3 Nano 与检测器共享 GPU，避免了重复。一次录制告警构建在 30 分钟内达到了可实时预览的部署状态。
其结果是一个可复用的模式：一次摄取视频，跨工作流共享证据，并为操作员提供自然语言搜索、告警、摘要和报告。
自适应 EVS 如何降低运营成本
一旦上述示例中的装瓶线代理开始运行，其摄像头就会全天候持续产生视频，而每一帧的大部分内容从不改变：灌装机、防护罩、地板。只有在其间移动的瓶子会发生变化，而溢漏很少发生。
每一帧窗口仍然会成为 VLM 的视觉上下文，因此模型将大部分计算用于重新读取与前一帧完全相同的区域。这种 VLM 处理是已部署视觉 AI 代理的主要运行时成本驱动因素之一，而 Adaptive EVS 正是针对这一成本。
图 3：四个场景中大多数帧重复前一帧。Adaptive EVS 将 VLM token 用于事件，而非等待
Adaptive EVS 在流水线中的改变
动态剪枝。每个图像块使用余弦相似度与前一帧进行比较；未变化的图像块在到达语言模型之前被丢弃。事件感知批处理。Token 保留率指示活动：高于约 70% 的片段作为事件进行批处理，低于约 30% 的片段被丢弃或刷新，其余正常运行。
图 4：大多数帧重复前一帧。Adaptive EVS 仅保留发生变化的图像块，丢弃安静帧，保留事件，VLM 的答案在少量 token 上保持不变
性能影响
在运行 Cosmos 3 Super FP8 的 NVIDIA RTX PRO 6000 Blackwell 上，Adaptive EVS：
- 将警报上下文化延迟降低 17%，从 1,021 毫秒降至 844 毫秒，同时类似地减少 token 使用量。
- 将并发实时 VLM 流增加 46%，从 13 增至 19。
- 以约一半的时间总结 60 分钟视频，VLM 输入 token 减少 80%。
结果因场景运动、块长度和相似度阈值而异；在选择生产默认值之前，请对代表性素材进行基准测试。
当 VLM 读取许多帧并产生简短响应时，Adaptive EVS 最有用，例如在密集字幕生成、长视频摘要和警报验证中。对于从少量帧生成长输出的情况，它提供的益处较少，它在 RT-VLM 容器内运行而非针对远程端点，并且是可选的。在 override.env 中启用它，然后在代表性素材上对准确性、吞吐量和延迟进行基准测试：
VIA_EVS_SESSION=true
VLM_VIDEO_PRUNING_RATE=0.5 # 0.0 to 1.0; higher prunes more
VLLM_EVS_SIMILARITY_THRESHOLD=0.2
成本影响：团队会发生哪些变化
- 通过多工作流应用的自然语言组合，降低集成工作量。
- 减少告警、搜索、摘要、报告和问答之间的重复基础设施。
- 通过剪除未变化的视觉区域，提高 GPU 效率。
- 通过跳过无事件的视频，降低摘要和事件审查延迟。
- 通过复用正在运行的部署进行增量变更，使扩展更容易。
这些变化共同减少了前期开发工作，以及跨环境和应用使用 VLM 处理视频所需的 GPU 工作量。
VSS 3.3 入门
- 克隆 VSS Blueprint 仓库，并检出包含 3.3 技能的分支。
- 在你的编码代理的标准技能目录中安装 VSS 技能。
- 描述所需的代理，包括视频源、工作流和部署约束，或说“构建一个视觉代理”以获取指导。
- 查看架构图和 _builds/
/override.env，尤其是 GPU 放置、模型端点、端口、存储和安全边界。 - 对于 RT-VLM 工作负载，启用 Adaptive EVS，调整剪枝率，并在代表性视频上对准确率、吞吐量和延迟进行基准测试。
- 部署在可信的隔离网络上，并配置身份验证、TLS、速率限制和外部控制。
示例设置命令
git clone https://github.com/NVIDIA-AI-Blueprints/video-search-and-summarization.git
cd video-search-and-summarization
让你的编码代理安装这些技能：
阅读 skills/README.md 以及 skills/ 下的每个 SKILL.md。使用标准 skills 目录为当前主机安装每个技能，
采用符号链接而非复制，这样 git pull 就能让它们保持最新。
技能安装完成后，你可以从类似这样的提示词开始：
构建一个 VSS 视觉代理，为我的仓库摄像头整合警报验证、自然语言视频搜索
和每小时摘要功能。尽可能复用现有的 Kafka 和 Elasticsearch
服务，并在运行 Docker Compose 之前生成部署计划。
进一步探索
- 克隆 VSS Blueprint 仓库 - 安装
VSS Agent Skills - 使用上述示例提示词在你自己的摄像头上试用 Build Vision Agent 技能