使用 CLI、技能和 AI 编码智能体开发 NVIDIA Holoscan 应用

NVIDIA Holoscan 是一个用于在边缘构建实时 AI 应用 (从医学成像到机器人) 的平台。HoloHub 是其配套资源库：一个不断增长的参考应用和组件集合，展示了各种可能性。

我们希望探索通用编码智能体如何使用工程师在实际开发任务中可用的相同示例、文档和开发工具。

在本文中，我们将介绍如何使用 AI 编码智能体构建实时内窥镜工具分割应用。HoloHub 示例和文档提供实施模式，开发技能可指导智能体完成 HoloHub 开发流程。 

通过 Holoscan CLI 包装器调用的 Holoscan CLI 提供了共享执行接口。智能体可以通过 CLI 发现开发操作，而工程师可以检查和重复相同的命令。

开发工作流程会进行迭代：

• 工程师定义目标和约束条件
• 编码智能体检查相关示例，实现应用程序特定的代码，并使用 CLI 运行所需的开发操作
• 工程师审核代码、输出和测试，然后为下一次迭代设定目标

该工作流程与智能体无关；在本示例中，我们使用了带有 GPT-5.6 Sol max 模式的 Codex，所提及的智能体处理时间是近似值。

设置和开发目标

总体目标是端到端内窥镜工具分割应用：借助分割掩模的实时可视化进行实时推理，并进行统计分析渲染。

我们重复使用了现有的 MONAI 内窥镜工具分割模型 和 Holoscan 示例视频，并确认现有的应用程序 monai_endoscopic_tool_seg 在本地运行。我们专注于重新使用深度学习分割管道的新应用程序，并添加了全面的可视化、运行时遥测和可重复的基准测试。

此外，他们还获得了：

• 具有 Bash 执行权限的 Holoscan CLI
• HoloHub 仓库，通过 agents.md 以渐进式披露模式提供文档
• HoloHub 开发技能，包括 holohub-app-lifecycle 和 holohub-debug-build-run

后续章节将展示这些组件如何在由工程师指导的代理式开发工作流中协同工作。

迭代 0：划分目标

开发者不应尝试使用单个提示词构建整个应用程序，而是应将最终目标分解为由不确定性和证据指导的较小、可验证的工程迭代。这种方法可确保及时审查设计方案。 

因此，我们可以将综合目标构建为一系列可回顾的主题：

• 开发环境配置是否正确，是否可在本地运行类似的现有应用？
• 现有模型和视频能否在单独的端到端应用中运行？
• 可视化是否呈现有意义的信息？
• 延迟是否可以重复测量？
• 能否在不出现特征回归的情况下提高渲染吞吐量？

每次迭代都会产生可审查的代码、输出和测试，为下一次迭代提供提示和设计选择。

迭代 1：创建最小的可用应用程序

第一个提示定义了结果，同时限制了模型和数据的重用。

开发者提示 1：

Use $holohub-app-lifecycle to create a separate new Python HoloHub application for displaying endoscopic tool tracking as model outputs https://github.com/Project-MONAI/model-zoo/tree/dev/models/endoscopic_tool_segmentation. Reuse the MONAI endoscopic tool segmentation model, sample data, preprocessing, and inference. Show the model-derived mask, coverage and timeline, and useful uncertainty measurements in a polished HoloViz overlay. Do not train or modify the model weights. Make the sample video work end to end.

这将实现选项留给智能体，同时保持模型重用、视觉证据和权重完整性的明确性。

智能体从指定来源收集信息：阅读应用生命周期技能、附近的 HoloHub 示例、项目元数据和 CLI 文档。 

我们按预期执行了不同类型的操作：

• 检查了相关的内窥镜检查、分割、HoloViz、记录和测试模式；monai_endoscopic_tool_seg、endoscopy_tool_tracking、surgical_scene_recon 是特别有用的参考
• dry-run 并调用./holohub create 以生成和注册标准支架
• 使用现有的 Holoscan 运算符和资产实现应用程序图形、执行模式、测试和文档
• 使用 CLI 定义的应用元数据，通过./holohub run 构建和运行应用

生成的应用程序连接了视频回放、预处理、TensorRT 推理、SDK 分割后处理器、遥测和 HoloViz。对每个回放帧运行推理和掩码后处理。Overlay 会报告帧衍生的测量结果。

代理式处理时间为 40 分钟。开发者可以通过智能体使用的相同 CLI 来查看实时应用：

./holohub run endoscopy_tool_segmentation_dashboard visual --language python

在审查实施、可视化输出和测试用例后，我们确认重复使用的模型和示例视频在新应用中有效。直观回顾还表明，叠加层需要更清晰的测量值，因此我们继续定义下一次迭代。

迭代 2：通过实施基准测试，使未来的审查具有可重复性

第二个提示将视觉演示变成了可重复的开发构件：

开发者提示 2：

Revise the visual output, add more meaningful statistics, tool area, mask motion, temporal intersection-over-union as a stability indicator, edge entropy, FPS, bounding box position, and remove values that remain unchanged during replay. Add a benchmark mode that records actual latency and plots the results in Python. Export the figures to the build folder and also show them interactively when the environment supports it.

作为回应，该智能体修改了动态测量结果和屏幕截图的可读性，然后进行了视觉审查，并对显式应用模式进行了基准测试。该应用有三种命名应用模式：

借助 Holoscan CLI 和应用程序生命周期管理，无需记住详细的容器和应用程序脚本配方，即可发现和运行模式和测试：

./holohub modes endoscopy_tool_segmentation_dashboard --language python
./holohub run endoscopy_tool_segmentation_dashboard benchmark --language python
./holohub test endoscopy_tool_segmentation_dashboard --language python

基准测试模式通过Holoscan 数据流追踪对视频回放的配置路径从预处理、推理、遥测、离屏 HoloViz 和渲染帧接收。它有效地重复了现有Holoscan Flow 基准测试模块中提出的想法。代理式处理时间为 20 分钟。

修订后的基准测试提供了更具可重复性的测量结果。在该基准可用的情况下，下一次迭代可以调查性能，而无需仅依赖视觉检查。

迭代 3：研究并降低延迟

当应用可测量后，开发者发出了第三个提示：

开发者提示 3：

Check whether the deep-learning model runs on every frame. Investigate ways to reduce latency, including approaches that take advantage of similar neighboring segmentations, and show the new benchmark results.

对此，该智能体确认仍在每一帧上运行推理。它考虑在相邻帧中重复使用掩码，这可以避免一些推理工作，但需要一个策略来决定何时可以接受过时的输出。在此工程迭代中，它对每一帧都进行推理，并首先消除了低风险仪表板开销：

• 重复使用 HoloViz 输入规范和静态坐标张量，同时为每一帧刷新文本和动态几何图形。
• 将当前 10 个值的 GPU 到主机遥测副本异步加入两个固定缓冲区，并使用先前完成的值进行渲染。

我们将第一次迭代的实现与同一测试系统上的最后一次迭代进行了比较。在全部五项测量试验中，优化版本的速度更快。代理式处理时间为 30 分钟。

最终移交提示和重新验证

经过三次工程迭代后，开发者给智能体一个单独的传递提示。

开发者提示 4：

Commit the implementation and keep the benchmark logs.

为了完成进度，我们重新运行应用程序和测试，验证输出数据和无外设测试结果。通过 ./holohub env-check 和 ./holohub env-info 保留实现和基准测试证据以及提交哈希和依赖项版本。

开发迭代显示了工作流程所产生的结果。为了更好地了解 CLI、技能和文档的影响，接下来我们将相同的开发任务与这些资源的不同组合进行比较。

消融研究

我们比较了在相同设置下使用相同编码代理和沙盒环境的资源使用情况 (请注意，上一次研究是在 8 月 1 日进行的，使用 Codex 0.146.0 和 GPT-5.6 Sol 进行最大推理努力) 。所有评估均基于第一次迭代中使用的单一提示词 (如果技能名称不可用，则删除技能名称) ，目的是创建一个新的应用。

CLI+ 技能+ 文档/ 示例 (此博客)

代理处理时间为 40 分钟，总计花费 1100 万个 token。

CLI 文档/ 示例

智能体将获得 agents.md，包括 CLI 使用指南和文档，以及 HoloHub 代码库。未提供 HoloHub 开发技能。

代理处理时间为 65 分钟，总计 2000 万个 token。虽然该工作流程产生了一个完整的应用程序，实现了实现目标，但该流程的效率较低。这些代理可以正确地在 HoloHub 资源库中找到类似的应用，但倾向于使用通用的 Bash 工具，这需要对开发环境进行更多的试错探测。例如，他们经常在基于 CLI 的 Lint 之前应用通用 Lint 工具，或者尝试直接在主机上安装 Python 依赖项并运行推理脚本 (应始终在容器中工作) 。

文档/ 示例

这些智能体获得了 HoloHub 代码库，但没有 agents.md 和有关 CLI 使用的明确指导。未提供 HoloHub 开发技能。

代理式处理时间为 40min，总造价 1500 万 token。

由于未提供 CLI 指导，编码代理仍然 (从整个代码库示例中) 了解了 CLI，并将其用作主要的开发工具。然而，与其他两种设置相比，编码质量欠佳：

• 第三方模型配置和代码未正确嵌入应用代码
• 在不利用现有 HoloHub 基础镜像的情况下创建的 Dockerfile 已具备所有必需的依赖项
• 在实施中，TensorRT 推理和格式转换器等现有优化的 Holoscan 运算符被忽略，因此此版本的速度比其他两个设置慢 2.6 倍

虽然后续提示可能会解决这些问题，但 CLI、技能和文档/ 示例的结合能够以最低的资源开销提供最佳开发者体验。

面向工程师和智能体的共同开发循环

本文遵循可验证的小型开发循环。其结果是基于现有模型、示例视频和 Holoscan 组件构建的工程原型。它可以端到端运行，提供多种应用模式和自动测试，保留模型权重，并记录可复制的基准证据。

主要要点是开发者和智能体共享的开发循环：./holohub 提供一致的操作，技能编码特定于项目的序列和检查，示例和文档提供工程上下文。智能体和开发者使用相同的 CLI 命令。开发者可以专注于定义目标、设置约束条件、评估权衡取舍，以及确定证据是否充分。

参考资料

• HoloHub：https://github.com/nvidia-holoscan/holohub/tree/holoscan-sdk-4.5.0
• Holoscan CLI：https://github.com/nvidia-holoscan/holoscan-cli/tree/v4.5.0
• HoloHub 技能来源： https://github.com/nvidia-holoscan/holohub/tree/main/skills
• NVIDIA 目录中的 HoloHub 技能： https://build.nvidia.com/skills?filters=library%3Alibrary_holoscan&q=holohub