OpenMontage 能力扩展协议：为 Agent 视频生产线安全添加脚本、Playbook、技能与工具包装器

OpenMontage 能力扩展协议为 Agent 视频生产线安全添加脚本、Playbook、技能与工具包装器【免费下载链接】OpenMontageWorlds first open-source, agentic video production system. 12 production pipelines, 100 tools, 700 agent skill and production-knowledge files. Turn your AI coding assistant into a full video production studio.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMontage导读OpenMontage 内置 100 工具与 12 条生产管线但任何系统都无法预先覆盖所有创作需求。本协议源自 skills/meta/capability-extension.md定义了当现有工具无法满足生产需求时Agent 应遵循的结构化扩展路径它用一套带护栏guardrails的规范取代了原先禁止编写临时 Python 脚本的一刀切规则明确区分一次性转换、周期性视觉需求、缺失供应商与缺失知识四类缺口并为脚本、Playbook、技能、工具包装器四类扩展物分别规定了落盘位置、契约要求与决策日志格式。读完本文你将掌握如何在 OpenMontage 中安全地扩展系统能力且全程不绕过生产管线、不触碰现有工具、不留审计盲区。何时使用从一刀切禁止到带护栏的扩展协议的核心触发场景只有一个遇到了现有工具无法覆盖的生产需求。此时 Agent 不再是简单地拒绝或绕过而是进入一条受控的扩展流程。在 OpenMontage 中工具能力由 tools/tool_registry.py 统一登记与汇报support_envelope()、provider_menu()、provider_menu_summary()等方法会持续生成系统能做什么、不能做什么的能力清单support envelopeAgent 在动手写任何代码前都应以此作为缺口确实存在的证据来源。这条协议同时是对生产纪律的强化所有生产仍必须经过管线阶段stage扩展物只是补足某个环节的工具能力而不是绕过质量门禁的捷径。评估先行先给缺口分类再决定扩展形式在写任何代码之前Agent 必须先把遇到的缺口归入下表四类之一因为每一类对应完全不同的扩展手段缺口类型Gap Type示例动作Action一次性转换One-off transform自定义图片裁剪、色彩调整、格式转换编写项目级 Python 脚本周期性视觉需求Recurring visual need新的插画风格、自定义图表类型生成自定义 Playbook 或 Remotion 组件缺失供应商Missing provider用户需要注册表中没有的特定 API创建最小化工具包装器tool wrapper缺失知识Missing knowledgeAgent 不知道如何向某个特定模型写提示词联网检索学习然后沉淀为 Layer 3 技能分类的价值在于避免用脚本解决一切的惯性一次性的用脚本、周期性的沉淀为样式资产、接口缺失的做工具包装器、知识缺失的写技能文档。对应关系在仓库中也有印证——skills/meta/skill-creator.md 明确告诫不要为一次性任务创建技能与这里一次性转换→脚本的导向完全一致。一次性脚本Ad-Hoc Scripts的六条铁律当缺口被判定为一次性转换时允许编写脚本但必须同时满足全部 6 个条件没有现有工具覆盖该需求——必须通过注册表registry预检preflight确认即对照ToolRegistry.support_envelope()/provider_menu()的能力清单逐一排查脚本必须幂等idempotent——重复运行是安全的脚本必须在项目工作区产出文件产物file artifact——不是产生副作用脚本必须记入决策日志category字段为capability_extension必须告知用户措辞形如I wrote a custom script for X because no existing tool handles Y我为 X 编写了自定义脚本因为没有现有工具能处理 Y未经用户批准不得调用外部 API。脚本统一存放在projects/project-name/scripts/目录下即项目工作区内的scripts/子目录不允许散落或污染tools/等系统目录。脚本模板幂等是硬约束协议给出了强制模板其核心是进入转换逻辑前先检查输出是否已存在One-line description of what this script does Created by capability extension protocol because: reason no existing tool covers this Decision log entry: decision_id import sys from pathlib import Path def main(input_path: str, output_path: str) - None: # Idempotent: check if output already exists out Path(output_path) if out.exists(): print(fOutput already exists: {out}) return # ... transformation logic ... print(fCreated: {out}) if __name__ __main__: main(sys.argv[1], sys.argv[2])模板的要点文档字符串即审计线索开头必须说明为什么现有工具无法覆盖并关联决策日志条目 ID入口即幂等out.exists()早退early return保证重复执行不产生重复产物、不重复消耗算力main(input_path, output_path)的签名保持输入输出分离避免把副作用藏在转换逻辑里这与 tools/base_tool.py 中工具层的幂等机制idempotency_key_fieldsidempotency_key()生成确定性缓存键是同一设计哲学在脚本层的落地可重复执行且结果确定。自定义 Playbook当现有视觉风格不匹配需求时当周期性视觉需求出现、且现有 Playbook 都与创作简报brief不符时协议要求走生成器而非手写散装 YAML使用 lib/playbook_generator.py 创建新 Playbook尽可能基于最接近的现有 Playbook 派生base_playbook参数必须通过 schemas/styles/playbook.schema.json 校验保存到styles/custom/project-name.yaml记入决策日志category: playbook_selectionsubject: custom playbook created。生成器与校验机制lib/playbook_generator.py 的实现验证了这套流程的可行性generate_playbook(name, context, base_playbookNone)支持两种起点load_existing_playbook(base_playbook)加载仓库 styles/ 目录下现有 Playbook 作为基底或_create_minimal_playbook()按mood/tone从零生成一份最小完整 Playbook内置 dark/cinematic、warm/organic、playful/bold、professional 四组默认色板与版式参数context字典可传入mood、tone、pace、audience、colorsprimary/accent/background/text、fontsheadings/body等键生成器会映射到identity、visual_language、typography等区块save_playbook()在写盘前调用jsonschema.validate()对 schemas/styles/playbook.schema.json 做强制校验并将文件名规范化为小写连字符形式后存入styles/custom/。Playbook Schema 的关键字段schemas/styles/playbook.schema.json 定义了 Playbook 必须包含的 7 个顶层区块identityname/category/mood/pace、visual_languagecolor_palette/composition/texture、typographyheadings/body含scale_system与weight_matrix、motiontransitions/animation_style/pacing_rules、audiovoice_style/music_mood/music_volume、asset_generationimage_prompt_prefix/consistency_anchors、quality_rules。此外还支持chart_palette、color_rulesharmony_type、WCAG 对比度校验开关、色盲安全开关、overlays、taste_profile、overrides允许最多 20% 场景偏离默认等高级字段。作为可参照的现成样例styles/clean-professional.yaml 完整展示了这些字段的真实取值例如motion.pacing_rules.min_scene_hold_seconds: 2.5、audio.ducking_threshold_db: -3、asset_generation.consistency_anchors四条一致性锚点等。自定义 Playbook 只要遵循同一 Schema 结构即可被 styles/playbook_loader.py 正常加载并驱动后续渲染。新技能Technique Learning把调研知识沉淀为 Layer 3 技能当 Agent 在联网调研中发现如何正确提示某个模型这类可复用的知识缺口时协议要求沉淀为项目级技能projects/project-name/skills/name.md遵循Layer 3 技能格式必须包含供应商名称与版本Provider name and version供应商专属的提示词模式Provider-specific prompting patterns该用例的最优参数Optimal parameters for this use case质量技巧与已知失败模式Quality tips and known failure modes信息来源 URLSource URLs for the information在决策日志中引用该技能若该技能具有普遍价值建议提升promote到.agents/skills/供全局复用。仓库中已有大量 Layer 3 技能的成熟样板例如 skills/creative/prompting/veo-prompting.md 精确记录了 VEO 3.1 / VEO 3 的 14 组件提示词结构、dolly/pan/zoom 三族运镜词的区别、rack focus 与 pull focus 的语义差异、负向提示词防字幕等知识skills/creative/prompting/grok-prompting.md、skills/creative/prompting/sora-prompting.md 等同目录文件均为同类格式。撰写新技能时skills/meta/skill-creator.md 还提供了补充准则技能要教思考而不只是教操作、必须包含正反示例、引用具体资源路径、以自评量表rubric收尾、记录常见坑并在 skills/INDEX.md 登记。工具包装器Tool Wrappers实现完整契约并注册当用户需要注册表中不存在的特定供应商 API 时协议允许创建最小化BaseTool子类规则如下保存到projects/project-name/tools/name.py必须继承BaseTool并实现完整契约input_schema、execute、capabilities等使用前必须先注册register记入决策日志category: capability_extension首次付费 API 调用前必须获得用户批准。BaseTool 契约全景tools/base_tool.py 定义了所有工具的抽象基类一个合格的包装器至少要覆盖以下契约成员成员作用name/version工具唯一标识与版本tier/stability/execution_mode/determinism/runtime分层core/voice/enhance/generate/source/analyze/publish、稳定性experimental/beta/production、同步异步、确定性deterministic/seeded/stochastic、运行形态local/local_gpu/api/hybridcapability/provider/capabilities顶层能力族、供应商名、具体能力标签列表input_schema/output_schema/artifact_schemaJSON Schema 化的输入输出与产物契约是注册表发现与编排的关键dependencies/install_instructions依赖声明支持cmd:、binary:、env:、python:前缀与安装指引check_dependencies()据此判定工具是否可用resource_profile/retry_policy硬件资源包络与重试策略resume_support/idempotency_key_fields断点续跑支持与幂等键字段side_effects/fallback/fallback_tools副作用声明与降级链路agent_skills关联的 Layer 3 技能名供编排器加载 API 知识execute(inputs) - ToolResult抽象方法必须实现ToolResult统一携带success、data、artifacts、cost_usd、duration_seconds等字段仓库中还提供了真实子类样板tools/graphics/code_snippet.py 是一个仅依赖 Pygments 与 Pillow 的完整示例它声明了capability graphics、provider pygments、dependencies [python:pygments, python:PIL]、完整的input_schema含code、language、theme枚举、font_size、line_numbers等、idempotency_key_fields、side_effects并在execute()中返回结构化ToolResult。编写新包装器时可直接对照此文件。注册与能力发现tools/tool_registry.py 提供了两种注册途径register(tool)显式注册实例或register_module(module)/discover()自动扫描模块内所有BaseTool具体子类并实例化注册。注册后包装器即可出现在support_envelope()、provider_menu()、provider_menu_summary()等能力报告中被编排器与用户预检菜单感知。这也正是只创建包装器、不修改现有工具的原因新增工具放进tools/或项目projects/project-name/tools/后provider_menu()会自动发现它无需改动任何存量代码。仍然禁止的事项Red Lines协议在放开扩展能力的同时划定了不可逾越的红线绕过管线Bypassing the pipeline——所有生产仍必须经过各生产阶段stage质量门禁在用户不知情的情况下调用外部 API修改tools/中的现有工具——要扩展就创建包装器wrapper不要改动原件跳过决策日志编写超出输出文件之外具有副作用的脚本——例如发送邮件、推送远程仓库、删除项目工作区外的文件。这些红线的设计意图在仓库中同样有迹可循BaseTool.side_effects字段要求每个工具显式声明自身副作用如 tools/graphics/code_snippet.py 的side_effects [writes image to output_path]从而让任何副作用都进入可见、可审计的轨道。决策日志条目格式每一次扩展都必须留痕所有扩展物脚本、Playbook、技能、工具包装器都必须记入决策日志标准格式如下{ decision_id: ext-001, stage: current stage, category: capability_extension, subject: Created custom script|playbook|skill|tool for purpose, options_considered: [ {option_id: existing-tool, label: closest existing tool, rejected_because: why it doesnt work}, {option_id: extension, label: what was created, reason: why this approach} ], selected: extension, reason: concise justification, user_visible: true, confidence: 0.8 }字段设计要点options_considered强制记录否决路径必须写下最接近的现有工具是什么、为什么不可用这是防止重复造轮子的核心机制——每次扩展都是一次对现有能力清单的再确认category区分扩展类型capability_extension用于脚本与工具包装器playbook_selection用于自定义 Playbook 创建便于日后按类别检索审计user_visible: true强制每次扩展对用户可见与脚本规则第 5 条必须告知用户呼应confidence用于记录 Agent 对方案把握程度供后续复盘与质量评估参考。总结一次扩展四条路径五道护栏OpenMontage 的能力扩展协议可以浓缩为一句话先评估缺口类型再选择对应扩展物全程遵守幂等、注册、留痕、告知用户、不越红线五道护栏。它把Agent 是否被允许写代码这个二元问题转化成了该写什么、写在哪、怎么写才合规的结构化决策——脚本解决一次性转换Playbook 沉淀周期性视觉风格Layer 3 技能固化可复用知识BaseTool包装器补齐缺失供应商。配合 tools/tool_registry.py 的能力发现、lib/playbook_generator.py 的 Schema 校验与决策日志的完整留痕这套协议让 Agent 视频生产线既能持续生长出新能力又始终处于可控、可审计、不破坏生产纪律的状态。【免费下载链接】OpenMontageWorlds first open-source, agentic video production system. 12 production pipelines, 100 tools, 700 agent skill and production-knowledge files. Turn your AI coding assistant into a full video production studio.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMontage创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考