十条「不要这么做」：一份写给 agent 的负面清单

2026-08-09

大多数项目的 agent 说明文档都写成「你应该这样做」。OpenMontage 的 AGENT_GUIDE.md 也有大量这类正面条款，但它把整份文件的最后一节留给了一串禁止句，标题就叫 What Not To Do，十条，条条以「不要」开头。

一份契约把压轴位置给负面清单，这本身就是个信号：作者预期 agent 会往哪几个方向跑偏，是有具体画面的。

这份清单长在哪里

AGENT_GUIDE.md 是仓库根目录下的一份 714 行的 agent 契约。我们实读它的标题结构，一共 46 个标题，从 First Interaction — Onboarding 开始，中间经过 Rule Zero、Decision Communication Contract、Mandatory Preflight、Reviewer Protocol、Human Checkpoint Protocol 这些分节，最后收在 What Not To Do。

先把边界说清楚：除了 Rule Zero、What OpenMontage Is、What Not To Do 这三节，这份契约其余章节的正文我们没有读过。下面凡是引用条款原意的地方，都出自这三节；凡是提到其它章节，只用标题本身说话，不编造里面的细则。

另外，这份契约管的是模型的行为。它是给 AI 编码助手看的指令文本，不是运行时的拦截器——OpenMontage 的架构主张原文就是 There is no code orchestrator，Python 只提供工具和持久化。所以「契约里写了不许做」和「装好之后就不会发生」之间，隔着一整个模型的服从度。这一点后面还会回来讲。

第一组：三条守流程的（对应 Rule Zero）

前三条是同一件事的三个切面。

第一条，不要绕过流水线。 原文说得很直白：绝不写临时脚本直接调工具，所有制作都走带导演 skill 的流水线阶段，并直接引用 Rule Zero。Rule Zero 那节的加粗原文是 Every video production request MUST go through the pipeline system. No exceptions.

第二条，不要在没读 Layer 3 skill 的情况下调生成类工具。 做法给得很具体：查工具的 agent_skills 字段，读被引用的 skill，然后用那份指导来写 prompt。

第三条，不要跳过阶段导演 skill。 执行任何一个流水线阶段之前，先读它的导演 skill，因为质量标准、工作流和评审标准写在那里面。Rule Zero 给的路径是 skills/pipelines/<pipeline>/<stage>-director.md，而且强调是「在该阶段做任何工作之前」。

这三条要合起来看才有意思。OpenMontage 把知识分成三层——Layer 1 是 tools/ 加 pipeline_defs/（有什么），Layer 2 是 skills/（OpenMontage 希望你怎么用），Layer 3 是 .agents/skills/（外部技术本身是怎么回事）。我们实读目录，skills/ 下 156 个 .md，.agents/ 下 567 个，相加 723 个。这个体量意味着：agent 一旦跳过读 skill 这一步，仓库里绝大部分内容就等于没有参与这次生产。Rule Zero 的收尾金句正是这个意思：The intelligence is in the skills, not in improvised code.

所以这三条禁止句的判定动作也很好落地——回看一次会话记录，如果 agent 在生成第一批素材之前，没有出现「读 pipeline_defs/<pipeline>.yaml」「读 <stage>-director.md」这两个动作，那它就是在自由发挥，不是在跑这套系统。

顺带一提，Rule Zero 那一节自己也带了一组 Do NOT，内容和这里高度重叠：不写临时 Python 脚本直调工具、不跳过流水线直奔 API 调用、不在读导演 skill 之前生成素材、用工具不查它的 Layer 3 提示词指导、不绕过 preflight / checkpoint / review。同一件事在一份文件里写两遍，位置一头一尾。

第二组：两条关于命名与硬编码的

第四条，不要使用已被删除的旧名称。 原文点名了三个：tts_cloud、tts_engine、video_gen。这条是十条里最琐碎、也最容易被忽略的一条，但它对付的是一类真实存在的失败模式——模型凭训练时见过的旧写法调用一个已经不存在的工具名，然后报错，然后开始瞎猜。

第五条，不要硬编码 provider 名、API key 名或安装 URL。 正确来源写得很明确：从 registry 的 install_instructions 和 dependencies 字段读。

第五条值得多说一句，因为仓库里正好有一处可核实的口径差异能佐证「别照着文档背 provider 名单」这件事。config.yaml 的 llm.provider 那行注释里列了七个可选值：anthropic | openai | gemini | openrouter | ollama | mistral | minimax，默认值是 anthropic。而 README 明写通过 Ollama 和 LM Studio 支持本地 LLM 是 “Coming soon”。两处写的不一样，以仓库当前状态为准；我们不推断哪一处更准，也不建议你据此认为本地 LLM 已经可用——README 把它写成计划，那它现在就是计划。至于安装 URL 和依赖名，同理，以 registry 当时返回的内容为准。

第三组：两条关于「先说再做」的

第六条，不要在用户批准制作计划之前就开始生成素材。

第十条，不要在没有事先告知用户的情况下更换 provider、模型或渲染路径，改动重大时还要拿到批准。

这两条最容易落到 config.yaml 里的具体数值上——那份文件里有一段 budget，实读值是：mode: warn（另两个模式是 observe 和 cap），total_usd: 10.00，reserve_pct: 0.10，single_action_approval_usd: 0.50，require_approval_for_new_paid_tool: true。还有一段 checkpoint，默认 policy: guided，另两个可选值是 manual_all 和 auto_noncreative。

把配置和条款对起来读：single_action_approval_usd: 0.50 定的是单次动作的审批阈值，require_approval_for_new_paid_tool: true 说的是遇到没用过的付费工具默认要问一声，policy: guided 决定 checkpoint 停在哪些位置。第六条和第十条则规定了 agent 在这些点位上必须开口。默认预算模式是 warn 而不是 cap，这一点尤其别看漏——不要因为看到 total_usd: 10.00 就把它当成一道硬性支出上限。这几行怎么配都不等于不会超支，真正拦住花销的是每一个批准动作，而做出批准动作的是你。这里只转述配置默认值与契约原文，不给「这样配就安全了」的结论；安全相关做法请结合你自己的环境评估。

第四组：三条关于「怎么把话说全」的

剩下三条全是信息呈现规则，也是这份清单里最有产品味道的部分。

第七条，不要隐藏降级路径。 替换和被阻断的选项要明确记录。

第八条，不要孤立地呈现单个不可用工具。 原文要求永远展示完整能力图景，还给了句式：X of Y providers configured for this capability.

第九条，不要在 preflight 时跳过 Provider Menu。 原文的理由是：用户必须看到他有什么，以及他还能解锁什么。

这三条拦的是同一种坏体验：agent 试了一个工具，失败了，然后只丢给你一句「这个用不了」，你既不知道还有几个备选，也不知道它偷偷换成了什么。第八条那个句式之所以要写进契约，是因为「3 of 8 已配置」和「这个不能用」在信息量上完全不是一回事——前者顺手告诉了你还有五个可以去配。

这一组和第十条其实是一体的：不隐藏降级、不孤立呈现、不跳能力菜单、不静默换 provider，四条合起来定义的是同一件事——任何一次替换都必须留下痕迹。这也呼应了这个项目的职责划分原文：所有创意决策、编排逻辑、评审标准都活在可读的指令文件里，每个决策都会被记录，含考虑过的备选项、置信度分数和每次选择背后的理由。

为什么写成禁止句

正面规范说的是「理想路径长什么样」，负面清单说的是「你最可能从哪儿掉下去」。对一套把编排权交给模型的系统来说，后者的信息密度更高：它等于把作者观察到的、模型反复犯的那几类错，一条一条钉在了文档的最后一页。

也正因如此，读这份清单最实用的方式不是背下来，而是拿它当验收表。你不需要看懂全部 156 个 skill 文件，只要在一次制作跑完之后回头问十个问题：走流水线了吗？读导演 skill 了吗？查 agent_skills 了吗？用的是不是已删除的旧工具名？provider 名是硬编码的还是从 registry 读的？素材是在你点头之后才开始生成的吗？降级路径记下来了吗？能力菜单完整吗？Provider Menu 出现了吗？中途换 provider 告诉你了吗？

最后必须说清楚的还是那句：这十条是指令，不是保障。契约里写着「MUST」「No exceptions」，那是写给模型看的措辞强度，不是运行时的强制力。能不能真的落地，取决于你用的是哪个 AI 编码助手、它当时的上下文里还剩多少空间、以及它有没有真的去读那些文件。所以这份清单对你的价值，恰恰在于它让你有办法事后核查——它给了你十个可以对着问的问题，而不是十个可以放心不管的承诺。

本文依据 OpenMontage 官方仓库（github.com/calesthio/OpenMontage）的 README、 AGENT_GUIDE.md、config.yaml、pipeline_defs/ 与 lib/ 下的治理模块整理，核对日 2026-08-09。本文内容为仓库源码与文档口径，我们没有安装或运行过该系统，也没有调用过其中任何一个 provider API，文中出现的成本数字均为项目方在 README 中自行标注的金额，非我们的实测结果。该项目以 AGPL-3.0 发布，部分流水线在 manifest 中自标 stability: beta，请以仓库最新内容为准。安全相关做法请结合自身环境评估，本文不构成安全方案建议。