创意团队需要持续产出分镜、视觉草图、音乐视频概念等大量资产，但工具分散和人工传递上下文会让制作流程变慢。Amazon Quick 与 fal 通过 Model Context Protocol（MCP）连接后，可以把创意讨论、素材生成和结果整理放进一个可复用的 agent harness 中。
本文围绕两个实践场景展开：生成八格分镜，以及快速制作音乐视频概念原型。重点不在于一次性生成一张图，而在于让代理能够持续理解项目上下文、调用合适的工具，并把中间结果交给下一步流程。
Agent Harness 解决什么问题
一个面向创意团队的 agent harness，可以理解为包裹在代理周围的一层工作流运行时。它负责保存项目上下文、规范工具调用、记录生成资产，并把人工审核放在关键节点上。
典型上下文可以包括：
- 项目目标，例如广告、短片或音乐视频的主题。
- 视觉规则，例如画幅、色彩、角色外观和镜头语言。
- 当前任务，例如“生成八个连续镜头”。
- 已生成资产，例如图片、提示词、版本号和审核状态。
- 下一步动作，例如继续生成、修改提示词或请求人工确认。
MCP 的价值在于把 Amazon Quick 中的代理能力与 fal 的创意生成能力连接起来。代理不需要把每个工具的内部实现硬编码在对话流程中，而是可以通过 MCP 发现工具、读取参数约束，并在合适的阶段调用生成服务。
这里有一个重要边界：MCP 负责工具和上下文之间的协议连接，不会自动替团队决定艺术方向。镜头连续性、人物一致性、版权审查和最终选片仍然需要明确的规则与人工判断。
两个工作流的共同骨架
八格分镜和音乐视频原型看似不同，但可以复用同一条流水线：
- 将自然语言创意拆分成结构化镜头或场景。
- 为每个镜头继承项目级视觉上下文。
- 通过 MCP 选择并调用 fal 的生成工具。
- 保存提示词、输出地址、参数和版本信息。
- 汇总结果，交给创意人员审核。
- 根据反馈只重做需要修改的镜头。
这种设计比“让代理自由生成所有内容”更容易调试。任何一次结果不理想，都可以追溯是上下文、提示词、工具参数还是人工反馈出了问题。
八格分镜
八格分镜适合验证镜头之间的叙事连续性。代理可以先生成一个镜头表，再逐格调用图像生成工具。每格至少应包含镜头编号、景别、动作、主体、环境和与上一格的衔接关系。
例如，镜头表可以采用如下结构：
[
{
"shot": 1,
"duration_sec": 3,
"framing": "wide shot",
"action": "A cyclist enters an empty coastal road at dawn",
"visual_notes": "cool blue light, mist, restrained contrast",
"continuity": "establish the location"
},
{
"shot": 2,
"duration_sec": 2,
"framing": "medium close-up",
"action": "The cyclist checks a small red cassette player",
"visual_notes": "keep the same red jacket and bicycle",
"continuity": "carry the subject from shot 1"
}
]
实际使用时可以扩展到八个镜头，并把全局视觉规则附加到每次调用中。这样即使某一格单独重做，也不会丢失角色服装、色彩和画面比例等信息。
音乐视频概念原型
音乐视频原型更关注节奏、情绪和视觉转场。代理可以从歌曲主题或一句创意描述开始，生成一组短场景：开场建立空间、主歌中的人物动作、副歌中的视觉变化，以及结尾的记忆点。
这里不应把整支视频一次性当作一个巨大提示词。将其拆成短场景后，团队可以快速替换副歌段落、比较不同风格，或只修改某一段的色彩和动作设计。fal 负责生成相应的视觉素材，Amazon Quick 中的代理负责规划、串联和根据反馈迭代。
一个可改造的 MCP 调用示例
下面的 Bash 示例演示了一个最小 MCP 客户端动作：先查询工具，再调用一个假设名为 fal.generate_image 的生成工具。工具名称和参数必须以实际 MCP 服务暴露的定义为准，因此运行前需要替换 MCP_URL、认证头和参数结构。
#!/usr/bin/env bash
set -euo pipefail
: "${MCP_URL:?Set MCP_URL to your MCP endpoint}"
: "${MCP_TOKEN:?Set MCP_TOKEN to your MCP token}"
call_mcp() {
curl --fail-with-body -sS "$MCP_URL" \
-H 'Content-Type: application/json' \
-H "Authorization: Bearer $MCP_TOKEN" \
--data "$1"
}
printf '%s\n' 'Available tools:'
call_mcp '{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/list",
"params": {}
}'
printf '%s\n' 'Generate one storyboard frame:'
call_mcp '{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/call",
"params": {
"name": "fal.generate_image",
"arguments": {
"prompt": "Eight-panel storyboard frame 1. Wide shot of a cyclist entering an empty coastal road at dawn; cool blue light, mist, cinematic composition.",
"aspect_ratio": "16:9",
"metadata": {
"project": "coastal-music-video",
"workflow": "storyboard-8-panel",
"shot": 1
}
}
}
}'
这个示例只展示协议层的调用方式。生产环境还应增加超时、重试、幂等键、输出地址校验和敏感内容审核。对于批量分镜，不建议并发提交所有请求后直接覆盖结果；应该为每个镜头保留独立的版本和状态。
可以把一次调用封装成如下伪代码逻辑：
project_context = load_project_context(project_id)
shot_list = plan_shots(brief, project_context, count=8)
for shot in shot_list:
prompt = compose_prompt(
global_style=project_context.visual_rules,
previous_shot=previous_result,
shot=shot,
)
result = mcp.call("fal.generate_image", {
"prompt": prompt,
"aspect_ratio": project_context.aspect_ratio,
"metadata": {"project": project_id, "shot": shot.number}
})
save_asset(project_id, shot.number, prompt, result)
previous_result = result
request_human_review(project_id)
这段逻辑的假设是：项目上下文、生成结果和审核状态都有持久化存储；mcp.call 是 Amazon Quick 所使用的 MCP 客户端封装；fal.generate_image 只是示例工具名。落地时应根据实际 MCP server 的 schema 调整字段。
让上下文真正可复用
上下文复用的关键不是保存一段很长的聊天记录，而是保存代理下一次调用真正需要的结构化信息。可以将项目状态拆成三层：
- 项目层：主题、受众、画幅、风格禁用项、版权和审核要求。
- 工作流层：八格分镜或音乐视频原型、镜头数量、输出格式和当前阶段。
- 资产层：每个镜头的提示词、模型参数、输出地址、生成时间和审核结论。
对于图片或视频生成，建议显式写出连续性约束，例如“保留同一件红色夹克”“沿用上一镜头的清晨雾气”“不要改变角色年龄和发型”。这些约束应进入结构化上下文，而不是只依赖代理记忆。
同时，人工反馈也应成为上下文的一部分。与其只记录“这张不对”，不如保存可执行的修改项：
{
"shot": 4,
"review": {
"status": "revise",
"notes": [
"保持人物位置不变",
"降低背景饱和度",
"让副歌开始前的动作更有速度感"
]
}
}
代理下一次重做时，就可以只读取第 4 格的反馈，并继承项目级规则和前后镜头信息。
上线前的检查清单
- 为每个 MCP 工具定义清晰的输入 schema 和输出格式。
- 让代理先规划镜头，再执行生成，避免无法解释的批量调用。
- 为每个资产保存提示词、参数、版本和来源信息。
- 将人工审核放在发布、合成或对外分享之前。
- 设置成本、并发和超时限制，避免代理循环生成。
- 对人物、品牌、音乐和训练数据相关内容执行团队要求的版权与安全检查。
- 为失败调用保留错误记录，并支持单镜头重试。
Amazon Quick 与 fal 的组合适合从小型原型开始：先让一个代理完成八格分镜，再将同一套上下文和资产管理逻辑扩展到音乐视频概念。真正值得投入的部分，是把创意规则、工具 schema、版本管理和审核反馈固化下来。这样，代理才会从一次性的灵感助手，变成团队可以反复使用的创意生产工作流。