MTG Bench：测试大语言模型玩《万智牌》的能力

背景

《万智牌》（Magic: The Gathering，简称 MTG）是一款规则极其复杂的集换式卡牌游戏。对于人工智能而言，理解并执行其规则、模拟对局过程是一项极具挑战性的任务。近期，一个名为 MTG Bench 的基准测试项目引发了关注，旨在评估大语言模型（LLMs）在模拟《万智牌》对局中的表现。

该项目的核心理念在于：如果一个大语言模型足够智能，能够下出高水平的《万智牌》，那么它也应该足够智能，以至于不需要依赖传统的规则引擎来强制执行合法操作。虽然规则引擎可以提高性能的下限，但作者认为它并不会提升整体模拟的质量。相反，通过让 LLM 直接调用工具库来模拟游戏状态，可以更真实地反映模型的推理和决策能力。

核心内容

基准测试的工作原理

MTG Bench 的运作机制主要依赖于大语言模型与一个 MCP（Model Context Protocol）服务器之间的交互。

1. 工具调用与状态管理： 每次 LLM 调用都可以访问一个包含基础库操作的 MCP 服务器。这些操作包括从牌库顶部抽牌、将牌放回牌库底部、洗牌等。为了模拟更高级的操作（如“探查” Scry 或“搜寻” Tutor），模型需要多次调用库工具。除了基础库之外，所有其他逻辑均由 LLM 自行管理。

2. 合法性检查与评分： 基准测试中的合法性检查和评分工作由 gpt-5.5 (medium) 模型完成。作者测试发现，LLMs 在评估模拟回合是否合法方面，表现远优于实际执行合法回合模拟的能力。

3. 示例表现：

   • 成功案例：Fable 5 成功执行了探查土地并查看牌库顶牌的操作；Gemini 3.5 flash 完成了包含探查、发现（Discover）和搜寻效果的复杂回合。
   • 失败案例：模型常因过度 eager（急切）地调用工具而导致状态错误，例如抽牌后意识到错误却无法撤销，导致模拟非法。

为何选择 MCP 服务器而非基础函数调用

作者选择使用 MCP 服务器而非简单的函数/工具调用，主要基于对 OpenAI 和 Anthropic API 特性的考量：

1. 代理循环（Agent Loop）托管： OpenAI 和 Anthropic 允许在 API 请求中提供远程 MCP 服务器 URL。这意味着由 OpenAI 或 Anthropic 处理代理循环，而非由应用代码处理。

2. 主要优势：

   • 成本优化：由于是一次 API 调用，模型在每次工具使用后无需为缓存的输入 token 付费（至少对于 OpenAI 而言）。
   • 批量 API 支持：可以使用批量 API 节省 50% 的费用，而无需在每次工具调用后提交新的批次。

输入 Token 缓存与定价争议

作者对当前大模型 API 的输入 Token 缓存计费方式提出了批评，特别是在代理循环场景下：

• 计费逻辑的不合理性：目前的定价逻辑适用于独立请求。如果多个独立请求使用相同的大型系统提示词，缓存机制能带来折扣。但在代理循环中，每次工具调用后，系统提示词都会被重新计费为“缓存输入”。
• 成本示例：假设系统提示词为 10k token，模型串行调用 10 个工具函数。即使工具调用本身的 token 消耗可忽略不计，计费也会变成：10k（初始）+ 10k * 10（后续每次调用重新计算缓存）= 110k token。
• 厂商差异：
  • OpenAI：处理较为合理。使用远程 MCP 服务器的单次 API 调用仅对输入提示词收费一次。
  • Anthropic：处理方式类似上述低效示例，每次代理回合都会对大型系统提示词收取缓存输入费用。
• 实际数据：在 gpt-5.5 (medium) 的基准测试中，每回合平均输入 token 为 11,386；而 claude-fable-5 (medium) 的平均值为 51,610。

过度工具调用的惩罚机制

该基准测试对“过度 eager”调用工具的模型惩罚力度较大。在大多数基准中，工具调用仅用于检索信息，即使调用过多，后果通常只是浪费输入 token 和上下文窗口，且状态变更通常可逆。

但在《万智牌》模拟中，状态变更往往是不可逆的：

• 不可逆操作：如果模型抽了一张牌，随后意识到这是错误操作，它不能简单地将牌放回牌库。即使放回，模型已经“知道”了这张牌是什么，导致模拟非法。
• 常见失败模式：模型开始工具调用后意识到错误，但无法纠正。例如，Opus 4.8 的例子显示，模型先以“Draw for turn”为由抽牌，随后以“No-op check not needed; cancel”为由将牌放回，接着又以“noop”和“stop”为由反复尝试返回同一张牌，导致逻辑混乱。

未来展望与应用

作者开发了 MTG Auto Deck 作为“氛围编程”（vibe coding）的尝试，整个项目和基准测试均未手写代码，完全由 LLM 生成。

• 当前局限性：目前的应用版本（含账户和支付功能）主要用于展示快速实现能力，并不推荐付费使用。因为当前模型的成本和速度使得逐回合模拟比手动使用在线工具进行“Goldfishing”（单人模拟练习）更慢，且并行运行数十次模拟以生成摘要的成本过高。
• 未来潜力：随着更便宜、更强大的 LLM 发布，该应用将具备实用价值。作者设想的功能包括：
  • 运行数百次模拟，提供关于卡牌优劣的统计结果。
  • 自动优化卡组，通过替换卡牌来调整策略。

关键要点

• 核心理念：LLMs 若能高水平模拟《万智牌》，则无需依赖传统规则引擎；LLMs 在评估合法性方面优于执行模拟。
• 技术架构：利用 MCP 服务器托管代理循环，通过单次 API 调用实现工具交互，旨在优化成本并支持批量处理。
• 成本痛点：当前 Anthropic 等厂商对代理循环中的系统提示词缓存计费方式导致成本激增，而 OpenAI 的处理方式更为合理。
• 主要挑战：模型容易因过度调用工具导致状态错误，且《万智牌》的某些操作（如抽牌）具有不可逆性，增加了模拟难度。
• 实际应用：当前版本因成本高、速度慢而缺乏实用价值，但未来有望用于卡组统计分析和自动化优化。

意义与影响

MTG Bench 不仅是一个游戏测试基准，更是对当前大语言模型在复杂逻辑推理、状态管理和工具调用策略方面的深度压力测试。

1. 揭示模型能力边界：通过《万智牌》这一高复杂度规则系统，该基准清晰地展示了 LLM 在“理解规则”与“执行操作”之间的差距，特别是在处理不可逆状态变更时的局限性。
2. 推动 API 计费模式反思：作者对输入 Token 缓存计费的批评，直接指出了当前 AI 基础设施在代理循环（Agent Loop）场景下的经济模型缺陷。这可能会促使云服务商重新评估针对长上下文、多步骤推理场景的定价策略。
3. 探索 AI 辅助决策的新范式：虽然目前《万智牌》模拟应用尚不成熟，但其背后的逻辑——即通过大规模模拟生成统计数据和优化建议——为 AI 在策略游戏、金融建模甚至复杂系统优化中的应用提供了可行的原型。随着模型成本下降，这种“模拟-统计-优化”的闭环有望成为 AI 辅助决策的标准工具。