Agent、MCP 与自动化开发

Agent 的价值不在于能调用多少工具，而在于能否观察真实状态、执行受限动作并验证结果。信息截至 2026-07-14。

结论先行

五篇文章显示了一条从“截图加提示词”到“领域工具加项目上下文”的演进。2023 年的自动测试通过截图理解画面并返回有限 JSON，已具备观察、行动、再观察的循环；2024 年的自动做游戏把需求拆成阶段；2025 年用 MCP 复现 Cursor 和调用 RPG Maker，开始把文件、命令与编辑器动作封装为工具；2026 年仙剑四资源提取则展示了 Agent 在陌生格式、脚本和多轮验证中的问题求解能力。

可生产的 Agent 至少包含五部分：观察、计划、行动、验证、持久记录。MCP 解决的是上下文和工具的标准连接方式，不自动提供正确性、安全性或项目知识。游戏引擎还有场景树、序列化对象、导入状态、控制台、运行时和 Undo，这些都不能只靠读写代码文件获得。

原文演进

有效方法

工具要围绕领域对象，而不只是文件

write_file 和 run_command 很通用，却把大量引擎知识留给模型临时推理。更好的工具是 create_prefab、add_component、inspect_console、open_scene、validate_missing_references。它们用稳定 schema 暴露领域语义，并在内部处理序列化、刷新和 Undo。

将任务拆成可验证阶段

自动做游戏不应是一条超长提示。推荐阶段包括项目检查、玩法骨架、资源占位、单元或编辑器测试、运行时冒烟、视觉比较和交付清理。每个阶段都有输入、完成条件和产物，失败只回退当前阶段。

观察必须来自真实系统

代码看起来正确，不代表 Unity 已编译、场景已保存、资源已导入。Agent 应读取控制台、层级、Inspector、测试结果和运行时截图。对旧游戏提取，还需比较文件数量、骨骼数、动画时长、包围盒和可视化结果，不能以脚本退出码为唯一成功条件。

权限与可逆性设计在工具层

读取、创建、修改、删除、执行外部程序和发布应是不同权限。高风险动作支持 dry run、变更摘要、路径沙箱、超时和人工批准。编辑器动作要接入 Undo，文件改动要保存 diff。Agent 不应通过一条“万能 shell”绕开这些限制。

把项目经验固化为 Skill

RPG Maker 案例说明，通用模型配上领域工具后才真正理解工作对象。团队可进一步把命名、目录、Prefab 组合、测试和验收写成版本化 Skill。Skill 是流程和判断标准，MCP tool 是原子能力，两者角色不同。

失败原因

截图测试缺少状态覆盖

视觉模型可以发现按钮和弹窗，却难以知道隐藏状态、网络条件、存档、随机数和内部断言。只靠截图操作会慢且不稳定。应把 UI 自动化与单元测试、状态注入、日志和可访问性树结合，视觉模型只负责传统定位难以覆盖的部分。

通用代码 Agent 看不到引擎状态

外部 Agent 可能修改脚本后立即继续，却忽略 Unity 正在编译或导入。它也可能直接改 YAML 序列化文件，导致引用或版本问题。没有编辑器桥接时，所谓成功常停留在文件层。

工具数量多会扩大选择错误

为 Agent 暴露数百个相似工具，会提高选错和参数错的概率。工具应按任务动态发现，名称和描述清楚，schema 严格，并提供常见组合的高层工具。任何返回值都要包含机器可判定状态，而不是只有自然语言。

旧资源提取涉及法律与语义双重风险

技术上能解析文件并不等于有权复制或分发资源。即使获得授权，骨架、动作和场景格式也可能含项目特有语义。导出网格可打开只是第一步，仍需验证坐标系、骨骼映射、材质和动画事件。

当前技术进展

MCP 官方仓库包含规范、协议 schema 和文档，并提供多语言 SDK。当前稳定规范版本与客户端、服务器支持情况可能不同，系统应进行版本协商，不要把“支持 MCP”视为固定功能集合。MCP 官方规范仓库，访问于 2026-07-14

MCP 的官方安全说明把责任分给服务器、客户端、运营者和用户：服务器验证输入并实施最小权限，客户端展示能力并取得同意，运营者只连接可信服务器并配置限制。这些要求对可写游戏项目的 Agent 尤其重要。MCP 安全策略，访问于 2026-07-14

Unity AI 公开测试版提供 Ask、Plan、Agent、Generators 与官方 MCP Server。Unity 官方说明 MCP 可让 IDE 中的 Agent 读取场景状态、GameObject、组件、控制台和项目设置，并触发编辑器动作。这直接补足原文通用文件 Agent 看不到引擎上下文的问题，但功能仍处于 beta，项目应锁定版本并保留人工审批。Unity AI Open Beta，访问于 2026-07-14

编辑判断： MCP 使工具接入趋于标准化，真正形成壁垒的仍是领域工具设计、项目 Skill、评测集和安全治理。团队不应以服务器数量衡量成熟度。

推荐工作流

任务与权限声明
  -> 读取项目真实状态
  -> 生成分阶段计划
  -> 调用受限领域工具
  -> 编译、测试、视觉与数据验证
  -> 记录 diff、日志和证据
  -> 人工批准高风险变更

最低工具面建议包括只读检查、受限写入、编辑器状态、测试、截图、Undo 和变更摘要。所有工具返回 ok、错误代码、受影响对象和证据位置。长任务要有预算、超时和停止条件。

测试 Agent 本身时，建立固定任务集：新建简单场景、修复编译错误、替换引用、处理导入失败、执行视觉回归、面对不存在资产、面对权限拒绝。记录任务成功率、人工接管次数、错误恢复率、无关改动、耗时和成本。

适用边界

适合：重复编辑器操作；项目检索和解释；白模生成；资源批处理；编译和测试闭环；已有授权的格式转换；内部开发工具。

谨慎使用：大规模自动重构、删除和迁移资产、版本控制冲突、含密钥或未公开内容的项目、外部服务器、自动发布和商店提交。

不值得使用：没有稳定 API 的一次性小任务；人工操作更快且风险高；项目没有测试与 Undo；只是把现有脚本包装成对话，却没有减少选择和验证成本。

原始文章与延伸阅读

本专题收录 5 篇原文，完整元数据见文章索引。