PC Watch记者若杉纪彦搭建AI自动剪辑系统后发现：智能体在定型流程中只是调度员

PC Watch记者若杉纪彦在2026年10月发表了一篇详细的实践记录：他从NVIDIA借来一台搭载RTX Spark的ASUS ProArt P16笔记本，用3天时间搭建了一套能在游戏直播结束后自动生成YouTube Short剪辑视频的系统。他没有手写一行代码，全部开发通过Claude Code以对话方式完成；运行端则使用Hermes智能体配合本地大模型Qwen3.8-27B。

系统的工作流程是：从公司NAS取出直播录像，用ffmpeg提取音频，whisper.cpp做全文转写，然后按话题切分段落，每45到70秒给一段打分，打分依据包括观众弹幕增速、笑声检测和面部微笑识别（分别用sherpa-onnx和MediaPipe实现），取出不重叠的高分片段作为候选。接着让本地大模型再读候选前后的文字，判断是否独立可理解、有无笑点，并据此调整起止点和标题，最终选出7分以上的3到5条生成竖版短视频。

真正值得注意的不是这套系统本身，而是作者在搭建过程中对智能体角色的判断。他发现，定型流程中的重复性任务——转写、切分、打分、裁剪——交给Claude写好的Python脚本执行，比让Hermes每次调用大模型推理要高效得多。Hermes实际扮演的角色，是在用户和这些脚本之间传递指令、汇总结果的调度员。作者明确写道，如果单纯为了功能实现，这套系统完全可以不用Hermes；把智能体纳入流程是为了体验其能力边界。

这一发现与当前流行的智能体叙事形成张力。行业普遍宣传让AI自主完成复杂多步任务，但若杉纪彦的实际经验表明，当工作流可以被拆解为确定性步骤时，大模型智能体的最优用法恰恰是退后一步：不做执行者，只做调度员。他在文中坦承，Hermes配合Qwen3.8-27B的本地组合在对话交互中经常感到迟缓，这也是他选择用云端Claude Code做开发、只在运行端保留本地智能体的直接原因。

当然，这一架构判断有明确的前提条件。作者的工作流高度定型——直播转写、弹幕对齐、片段评分、竖版裁剪——这些步骤的输入输出格式固定，适合用代码封装。如果任务本身需要大量开放式判断，或者流程频繁变化需要即时调整，调度员模式可能就不够用了。作者也指出，AI生成的剪辑内容大约七成可以直接使用，剩下三成需要人工修正，修正通过Telegram发送指令完成，包括指定裁剪范围、标注说话人、调整字幕时间、添加缺失字幕、指定镜头变焦等。

从性能数据看，4条预览视频生成耗时约30分钟，其中转写和话题切分约6分钟，选片约6到7分钟，每条预览制作约3分钟。修正后正式导出每条约5分钟。作者没有与之前外包剪辑的时间做对比，这是他第一次让PC做视频编辑，但他认为每条不到10分钟完成预览已经相当快。

若杉纪彦在文末将这套系统的定位说得很清楚：它不是智能体自主工作的示范，而是人在回路中、智能体做调度、代码做执行、AI做判断的混合架构。这个判断来自实际搭建和运行的摩擦——对话日志膨胀导致每次回复要重读8万token等约3分钟，他不得不让Claude写一个插件来重置会话。这些细节说明，当前智能体工作流的瓶颈往往不在模型能力本身，而在工程层面的上下文管理和执行效率。