「让模型直接写个 Python 脚本」的隐性代价

每个 AI 驱动的 DCC 项目里都有那样一个瞬间：演示跑通了，团队以为最难的部分已经过去了。有人让模型写个脚本，脚本执行了，屏幕上出现了形状，所有人都在鼓掌。

其实最难的部分还没开始。

脚本是为"顺利路径"优化的

生成脚本是对一个复杂状态机的一次性赌注。它假设当前激活对象就是它想要的那个、集合一定存在、单位一定匹配、也不会有算子上下文的问题。一旦假设不成立，失败方式毫不优雅——一个 traceback，外加一个改到一半的场景。

工具调用则是另一回事。工具带 schema，所以 Agent 在下发请求之前就知道什么样的请求是合法的。一次被拒绝的调用是廉价、可恢复的事件；一个被拒绝的脚本则是案发现场。

还不存在的脚本，没人审得了

评审才是那个安静的成本。一个 200 行的生成脚本没有稳定接口：改一行，整段就是需要重新评审的新代码。工具面是稳定的，评审者只要审一次策略，之后就可以信任契约。

这也是为什么工作室批准 DCCMCP 部署的速度，快过批准"我们给模型开了 Python 权限"。关键不在模型，而在于评审者究竟能看到什么。

影响半径问题

想一想，无人值守的 Agent 一旦拿到裸脚本执行权，能够到什么地方：

• Blender 进程能打开的每一个文件
• 项目里链接的每一个库
• 宿主机上的网络访问
• 未保存场景的撤销栈

而一份精心收窄的工具清单，会把暴露面限制在你决定暴露的范围内，其余部分由拒绝规则清除。脚本页签做不到这一点。

问题从来不是"模型够不够聪明"，而是"完成这项工作所需的最小能力集合是什么，又是谁批准的"。

从财务角度看这笔成本

生成脚本的单位成本很低，事故成本极高。每一次生产事故都拖着一条尾巴：损坏的文件、重渲的时间、跟客户的解释、以及结论为"我们应该加护栏"的复盘。

类型化工具把这笔支出前置了。你在策略设计上一次性付费，而不是在事故恢复中反复付费。

| 成本项 | 生成脚本 | 类型化工具面 | | --- | --- | --- | | 第一次跑通演示 | 数小时 | 数小时 | | 生产环境调试 | 持续发生 | 极少 | | 评审投入 | 每个脚本一次 | 每个策略一次 | | 事故恢复 | 不可预期 | 受回滚能力约束 | | 审计就绪度 | 基本为零 | 默认具备 |

换成该问供应商的问题

评估一个集成时，别只看演示，问这几个问题：

1. 哪些操作属于读、写、执行？完整清单能不能给我看？
2. 当 Agent 的目标对象不存在时，会发生什么？
3. 破坏性调用能不能做成可回滚的？回滚需要多久？
4. 日志存在哪里、保留多久、能不能导出？
5. 默认拒绝的是什么？

能在一页纸里回答完这五个问题的供应商，卖给你的不是演示，而是可以拿去给技术总监看的东西。

想看这些答案落到实处长什么样，MCP for Blender 和 MCP for QGIS 页面列出了工具面、每个工具的风险等级以及默认策略。