我经常使用 Unity 中的 AI 代理，然而有一点让我疯狂：一个巨大的上下文窗口在模型接触场景之前就消失了。
在我的基线测量中，Unity 的 MCP expose 48 个工具，共 93,119 个字符的序列化模式。
使用通常的字符到令牌近似值，约有 23,280 个令牌的工具定义。不是场景数据。不是代码。只是描述工具可以做什么的说明。
然后代理会检查一个大型层次结构，读取一个嘈杂的控制台跟踪，或者接收一个包含它不需要的字段的大型通用响应。越来越多的上下文被消耗，模型变得越来越不专注，简单的 Unity 任务开始需要太多的回合旅行。
我已经花了很多时间优化 MCP 工作流程，而在 MCP Hub 和一个类似的 Blender 设定中工作时。同样的模式一直持续出现：
模型很少需要整个 API 表面。
它需要一个非常小的、可预测的界面，找到正确的操作的好方法，以及可以在必要时扩展的紧凑结果。
所以我建了 Unity MCP Efficient：
https://github.com/Vangardo/unity-mcp-efficient
它不会替换或分叉 Unity 的 MCP。原来的 Unity MCP 还是会处理实际工作。这是一个薄的外壳和 Codex 技能放在它的前面。
而不是暴露数十个大型工具模式给模型，外壳暴露六个小工具：
- 搜索相关的 Unity 能力
- 只检查所需的操作模式
- 执行单个操作
- 批量多个操作
- 检查 Unity 的紧凑形式
- 仅当需要时才检索或扩展存储结果
在这些六个工具下，377 个 Unity 操作仍然可用。
以下是当前测量结果：
| 测量 | 原始表面 | 效率外壳 | 减少 |
|---|---|---|---|
| 暴露的 MCP 工具 | 48 | 6 | 87.5% |
| 序列化模式大小 | 93,119 个字符 | 3,657 个字符 | 96.07% |
| 模式令牌近似值 | 23,280 | 915 | 96.07% |
| 通过模式呈现的参数字段 | 5,566 | 1,798 | 67.7% |
| 大型合成层次结构响应 | 628,110 个字符 | 875 个字符 | 99.86% |
包含的搜索评估目前在所有 15 个测试意图中都找到了预期的 Unity 操作。
层次数是故意进行的压力测试，而不是平均场景。96% 的数字特指暴露的工具模式表面。 我们不claim 每个 Unity 会话都会变成 96% cheaper。实际节省取决于模型、任务、缓存和请求场景数据的多少。
还有一些不那么可见的问题也需要解决：
- 大型原始结果在压缩之前存储起来，以便模型可以稍后检索详细信息而不重复 Unity 操作。
- FastMCP 和 Pydantic 响应对象在 JSON 序列化期间安全地进行归一化，而不是失败。
- 异步测试作业保留其
job_id。 - 内部 Unity 失败不能错误地出现外部
ok: true。 - 领域重载、陈旧的编辑器状态和暂时缺失的 Unity 会话返回紧凑的重试指南。
- 相关操作可以通过有界批量调用而不是每个小操作都花费一个完整的模型回合旅行。
- 场景检查首选摘要、组件计数和分组信息而不是默认情况下将每个顶点或层次结构字段都 Dump。
当前项目有 35 个自动化测试，CI 在 Python 3.10-3.13 上，重现的基准测试脚本，MIT 许可证和安装指南。Codex。
我建了这个项目，因为我想 Unity 代理花费他们的上下文在思考游戏，而不是反复读取数千个 API 文档令牌。
如果你已经使用 Unity 的 MCP，我会真诚地感谢实际项目可以打破这个方法。巨大的场景、ProBuilder 工作流、嘈杂的控制台、长的测试跑和痛苦的领域重载案例都特别有用。
仓库：
https://github.com/Vangardo/unity-mcp-efficient
基准和方法：
https://github.com/Vangardo/unity-mcp-efficient/blob/main/BENCHMARKS.md
评论 (0)