为什么选择 DCC-MCP
DCC-MCP 是什么？
DCC-MCP 是连接 AI Agent 与创作软件的开源工具集。AI Agent 是能调用工具执行任务的 AI 助手；DCC 指数字内容创作（Digital Content Creation），常见应用包括 Maya、Blender、Houdini 和 Photoshop。
它让 Agent 和自动化程序调用这些应用中的工具，完成建模、材质、动画、渲染等任务。这里的“类型化工具”指明确规定了参数、参数类型和返回结果的工具，调用前可以查询和校验。
MCP（模型上下文协议）、REST API 与 dcc-mcp-cli 共用工具发现、参数校验、应用选择、安全策略和结果验证逻辑。Core 提供这些共享基础设施；各应用的适配器负责接入，Skill 则提供可复用的工作流指南。
DCC-MCP 的设计来自实际的应用接入工作。不同软件反复遇到相似问题： 操作必须在主线程执行、需要选定正确的应用实例、长任务需要跟踪状态、 失败后需要找到原因。我们在确认这些问题具有共性后，才将解决方式纳入共享接口和规则。
先整理生产流程
Agent 使用团队提供的流程，但不能替团队定义流程。
明确生产标准 → 整理操作流程 → 将流程封装为工具 → 交给 Agent 调用
先明确命名规则、输入、输出、检查项、责任分工和验收标准，再将各个步骤整理成可重复 执行的流程，最后封装成类型化工具。人、脚本、持续集成（CI）和 Agent 都可以调用同一套工具。
临时脚本为什么无法规模化
让模型临时编写并执行 mayapy、hython 或 Blender Python 适合探索。 进入持续使用后，会遇到这些限制：
- 模型每轮重新生成相似代码，结果会发生变化；
- DCC API 往往要求在主线程执行，还需要确认应用是否已准备就绪；
- 同时打开多个场景或应用实例时，执行目标并不明确；
- 长任务需要报告进度、支持取消，并能从检查点恢复；
- 进程成功退出，不代表目标场景或文档真的发生了预期变化；
- 缺少参数类型校验、请求编号、日志和调用追踪时，失败很难复现。
这些问题会在多个应用适配器中出现，因此由共享基础设施统一处理。
问题与对应契约
| 反复遇到的问题 | 我们得到的经验 | DCC-MCP 的应对 |
|---|---|---|
| 模型每轮重写任务逻辑 | 制作流程不应随着模型或提示词变化而丢失 | 将流程保存在有版本记录的 Skills 中，复用带参数定义和校验的工具 |
| 每个适配器都重复实现通信和任务管理 | 应用接入需要统一的接口和规则 | Core 运行时、Gateway 网关和 CLI 处理共性问题，适配器专注于应用接入 |
| DCC API 要求主线程执行，且应用必须准备就绪 | 启动一个进程并不足以完成可靠操作 | 检查就绪状态、选择应用实例，并通过应用内的执行接口调度主线程 |
| 工具目录过大会占用上下文并干扰选择 | Agent 只应发现当前任务需要的能力 | 渐进式 search -> load/describe -> call |
| 创作任务耗时长，也可能只完成一部分 | 需要跟踪任务从提交到结束的状态，不能只看返回值 | 异步任务、进度、取消、检查点和输出文件交接 |
| Agent 调用容易成为黑盒 | 生产团队需要可检查的证据 | 请求编号、策略记录、审计、日志、调用追踪、指标、健康检查和回放 |
| 旧工具有时没有可用 API | 优先使用原生接口，必要时才操作界面 | 通过 DCC-CUA / UI Control 绑定指定进程和窗口，限定操作范围并检查策略，按 snapshot -> find -> act -> wait -> verify 观察、定位、操作、等待和验证 |
| 有价值的工作流需要跨人员和项目复用 | 共享脚本目录还不足以管理版本和分发 | Marketplace 软件包、固定的源码版本、热重载，以及项目或团队范围的配置 |
各层负责什么
系统将共享服务与各应用特有的操作逻辑分开。
| 层次 | 职责 |
|---|---|
| Agent 接口 | MCP/REST 接口、类型化 CLI 命令、参数定义、资源、提示词和结构化结果 |
| 控制面 | Gateway 网关负责发现和选择应用实例、检查策略、管理任务状态，并提供日志和诊断信息 |
| DCC 运行时 | 检查应用就绪状态、调度主线程、执行任务，以及处理取消和检查点 |
| Adapter（适配器） | 由各应用仓库维护安装、兼容性、应用 API 和专属操作逻辑 |
| Skill（工作流指南） | 保存已验证的制作流程、参数校验方式，以及项目或团队约定 |
Core 架构文档 记录当前共享接口和规则。各应用的安装、兼容性和排错说明由对应适配器仓库维护。
CLI、MCP 与 REST 共用一套实现
共享服务代码与 REST/OpenAPI 接口定义是这三种入口的共同基础。dcc-mcp-cli 调用 Gateway REST API；MCP 提供 search、describe、load_skill 和 call，为仅支持 MCP 的客户端提供同一套工作流。两条路径复用相同的发现、 校验、路由、策略和调用服务。
| 使用方 | 推荐入口 | 是否需要 AI Agent |
|---|---|---|
| 美术人员、技术指导（TD）、运维、Shell 脚本与 CI | 类型化 CLI 或 REST | 不需要 |
| 工作室自动化与自研应用 | REST 与 OpenAPI 生成客户端 | 不需要 |
| 仅支持 MCP 的 AI 开发环境与助手 | MCP 的发现、描述和调用接口 | 需要 |
| 智能工作流画布与云端编排平台 | REST/OpenAPI；有 Agent 参与时再使用 MCP | 不需要 |
没有 AI Agent 时，制作管线也可以直接调用 REST API、从 /v1/openapi.json 生成客户端，或在 CI 与运维中使用 CLI。有 Agent 时， 再通过精简的 MCP 接口调用相同能力。
团队已有的 OpenAPI 3.x 服务也可以接入为 MCP 工具。原服务仍是普通 REST 服务，不需要围绕 AI 重写。
优先复用现有协议
MCP 是通用的 Agent 接口协议。DCC-MCP 使用这一协议，并允许通过 REST、Python、C++、HTTP、命令端口、原生插件或厂商官方工具集接入应用。
DCC-MCP 不替代 Agent、DCC API 或厂商集成。厂商已有可用的原生能力或 官方 MCP 时，适配器会保留其工具名称和参数定义。DCC-MCP 补充工具发现、 应用选择、安全检查、任务管理、分发和诊断等共用能力。
Skill 保存工作流经验
Skill 保存经过验证的工作流，记录版本和参数要求，便于测试、分发和复用。
所有权边界如下：
- Core 和适配器负责连接、线程安全、应用选择、策略检查和诊断；
- 技术指导（TD）和技术美术（TA）维护项目命名、场景检查、资产准备、发布检查、导出规范和审核交接，并复用团队已有的管线代码；
- Agent 根据工具说明选择操作，填写参数并经过校验后调用，无需每次重新编写整套流程。
它减少重复生成代码，也让工作室可以按项目、部门或制作阶段分发不同能力， 无需为此另行维护一套 Core。
保留失败证据
诊断首先核对请求编号（request_id）、调用的工具与参数、目标应用实例和实际结果。 Gateway 与 CLI 提供健康检查、日志、调用追踪、统计和结构化反馈。
由此形成一个具体的闭环：
- 在实际应用中复现问题；
- 判断问题属于 Core、适配器还是 Skill；
- 在负责该功能的模块中做最小修复；
- 重新验证同一个调用；
- 保留证据，让下一次改进从经验开始，而不是从猜测开始。
已知边界
DCC-MCP 不会声称所有创意应用都能变得完全一样。
- 优先使用原生 Skill 和 API，必要时才通过 DCC-CUA / UI Control 操作界面，并绑定指定进程和窗口。
- Core 不定义各应用特有的制作流程和业务规则。
- 应用没有事务 API 时，适配器不能承诺安全回滚。
- Marketplace 扩展用于增加能力，不用于掩盖 Core 或适配器缺陷。
- 项目为 Agent 提供基础设施，但不规定必须使用哪个 Agent 或模型。
仍然依赖人的判断
很多生产任务可以标准化、验证和自动执行，但审美判断、艺术指导、构图、 节奏和风格取舍仍很难用固定规则准确表达。
DCC-MCP 先处理可重复部分，并让 Agent 在约束内使用真实工具。模型的感知、 推理和创意判断改进后，可以继续使用同一批类型化工具，不需要重建每个 DCC 集成。