8.0
热点
AI SCORE
技术实践2026-08-11 21:41
用 MCP 构建可审查的 AI 视频生成 Agent
dev.to · AI#MCP#Agent#视频生成
Editor brief · 编辑速览
详细拆解了 AI 视频 Agent 的最小可靠闭环：brief→discover→inspect→validate→preview→approve→render→verify，并给出了 MCP 工具调用的具体设计。
一个 AI 视频 Agent 不应该从渲染调用开始。
它应该首先证明自己理解了其将要使用的引擎、选择的构图，以及决定输出是否可读、是否可以安全发布的约束条件。
最小可靠的循环是：
brief
-> discover
-> inspect
-> validate
-> preview
-> approve
-> render
-> verify
这个序列不像一键 Prompt 演示那样引人注目，但它更接近一个真实团队可以运作的系统。
完整的工具序列
iLoveVideoEditor 通过其 MCP server 暴露了 14 个带类型的工具。一次可审查的运行按明确顺序使用其中的一个子集：
ilovevideoeditor_list_templates
-> ilovevideoeditor_get_template
-> ilovevideoeditor_get_layer_capabilities
-> ilovevideoeditor_measure_text
-> ilovevideoeditor_local_preview
-> ilovevideoeditor_local_capture
-> ilovevideoeditor_local_analyze
-> human approval
-> ilovevideoeditor_render_template or ilovevideoeditor_render_json
-> ilovevideoeditor_get_render_status
-> ilovevideoeditor_get_download_url
模型仍然在推理。只不过它是在一个真实的契约上进行推理，而不是去凭空发明模板变量、特效、转场或渲染行为。
在 MCP 兼容的客户端中配置发布的包：
{
"mcpServers": {
"ilovevideoeditor": {
"command": "npx",
"args": ["-y", "@ilovevideoeditor/mcp-server"],
"env": {
"VF_API_KEY": "vf_live_..."
}
}
}
}
将真实的密钥保留在客户端的私密环境变量中。永远不要将它粘贴到 Prompt、文章、截图、评估 fixture 或提交的配置文件里。
本文中的序列已针对 @ilovevideoeditor/mcp-server v1.0.2 进行了校验。
第一个调用不应该花费额度或创建任务。
使用 ilovevideoeditor_list_templates 来发现候选模板，然后调用 ilovevideoeditor_get_template 来检查所需的文本、图片、颜色和文件变量。
这可以捕捉一个常见的规划错误：Agent 创建了一个无法映射到所选模板的详细故事板。
一个兼容的模板必须支持的不仅仅是总体视觉风格，还必须支持：
目标宽高比；
所需的媒体类型；
计划的文案密度；
场景的数量和用途；
品牌约束；
预期的行动号召（CTA）。
如果工具发现或 schema 检查不稳定，添加付费渲染调用只会让失败更难诊断。
当 Brief 要求某种运动效果或转场时，在将其添加到计划之前调用 ilovevideoeditor_get_layer_capabilities。
排版也是如此。一句话可能在语法上正确，但在 9:16 的构图中仍然无法使用。ilovevideoeditor_measure_text 让 Agent 可以在决策仍然廉价的时候缩短、拆分或重构文案。
这个阶段的输出应该是一个小的、可审查的产物：
{
"scene": "cta",
"purpose": "Close with one action",
"copy": "Start your first reviewable render",
"templateVariable": "ctaText",
"durationSeconds": 2.5,
"assumptions": [],
"reviewRequired": ["Confirm destination URL"]
}
这是一个比原始 Prompt 更好的审批边界，也是一个比完成渲染更便宜的审批边界。
一个结构上有效的载荷仍然可能产生一个弱视频。
在提交云渲染之前，启动本地预览、捕获代表性帧并分析它们。视觉检查应该寻找具体的失败：
被裁剪或溢出的文本；
空的或视觉上薄弱的场景；
行动号召出现时间过短。
报告应该足够具体，能够推动修正：
{
"scene": "cta",
"time": 11.4,
"checks": {
"textOverflow": false,
"safeMargins": true,
"contrast": "pass",
"missingMedia": false
},
"reviewRequired": ["Confirm destination URL"]
}
视觉检查不会消除人工审查。它只是给审查者一个更小、边界更清晰的决策集。
一个绿色状态对于品牌视频是不够的。
将以下视为独立状态：
Schema 有效——请求与工具和构图契约匹配。
渲染完成——引擎产生了预期的文件。
视觉检查通过——构图满足定义的质量规则。
人工批准——声明、媒体、时机和 CTA 都经过了审查。
分发授权——输出可以发送到其目标位置。
一次完成的渲染不能证明价格是最新的、产品声明有依据、面孔或声音已获得授权、字幕无障碍，或者目标 URL 是正确的。
这些决策仍然是显式的。
在故事板和预览获得批准后，使用 ilovevideoeditor_render_template 或 ilovevideoeditor_render_json。
然后用 ilovevideoeditor_get_render_status 轮询任务状态，并用 ilovevideoeditor_get_download_url 取回完成的输出。
运行记录应该包含：
规范化的 Brief；
选定的模板和版本；
捕获的审查帧；
渲染任务 ID 和状态历史；
存储决策，而不是密钥。从 Prompt、截图、日志和 fixture 中删除 API 密钥、私有源 URL、客户标识符和敏感转录文本。
第一次证明可以在渲染之前停止：
安装 MCP server；
列出可用的工具；
检查一个模板；
测量一行短文本；
一旦这条路径稳定了，添加本地预览、一个捕获的帧和一次批准的渲染。
探索当前的工具面和安装路径：
披露：iLoveVideoEditor 构建了本文描述的 MCP server 和渲染系统。产品行为和计数已根据仓库事实注册表和 MCP server v1.0.2（2026-08-11）进行了校验。