MTG Bench：测试LLM玩万智牌的能力

# MTG Bench：测试LLM玩万智牌的能力有多强 来源：https://mtgautodeck.com/articles/mtg-bench/ ## 结果 点击上方图表可查看每个基准测试的模拟结果。 ### 成功案例 1. Fable 5 打出一张预视地并查看牌库顶牌 (https://app.mtgautodeck.com/public/benchmarks/f360847d-fbb6-466e-8715-75d1928d6b0b?simulation=8d5f2c18-0428-4555-81f4-3dc4948b8a4a&turn=1) 2. Gemini 3.5 flash 执行了一个包含预视、发现和导师效应的复杂回合 (https://app.mtgautodeck.com/public/benchmarks/0b5b448b-d276-461b-85ea-542593639e35?simulation=4918197c-8310-48e2-afb7-3266318b16f2&turn=5) ### 失败案例 1. Opus 4.8 错误地将一张牌放回牌库，随后自行报告了错误 (https://app.mtgautodeck.com/public/benchmarks/6349dda2-4069-4825-971e-8c11234260c4?simulation=4f815543-1abd-4cc7-9be1-efe1194a80fd&run=f7c47fe5-6a86-4991-96c5-73719cd1baa8&turn=1) 2. Gpt 5.5 忘记将因发现效应放逐的牌放回牌库，并自行报告了错误 (https://app.mtgautodeck.com/public/benchmarks/79d1ed51-ca1d-4783-a71c-66e46af6e718?simulation=65b815bd-d3b0-4295-b01a-50eb5e8b4c91&run=b834f6e6-0796-47b6-9525-203aa3e83d63&turn=5) 3. Fabel 5 出现了工具调用错误，随后默默尝试重新开始该回合（后被评估环节发现） (https://app.mtgautodeck.com/public/benchmarks/f360847d-fbb6-466e-8715-75d1928d6b0b?simulation=23dd7ee6-ea30-413c-b9c2-a88b1ca0e3ad&run=96b43eba-a442-4872-a390-1c5c86a5b5c0&turn=5) ## 基准测试的工作原理 核心思路是：如果一个LLM足够聪明，能够玩好万智牌，那么它也足够聪明，不需要规则引擎来辅助。强制执行合法行动的规则引擎固然能提高性能下限，但我认为它不会提升模拟的整体质量。 每次LLM调用都可以访问一个MCP服务器，该服务器提供基础的牌库操作。它可以执行诸如从牌库顶抓牌、将牌放回牌库底、洗牌等操作。要模拟更高级的操作，如预视 (https://mtg.fandom.com/wiki/Scry) 或探查 (https://mtg.fandom.com/wiki/Surveil)，则需要通过多次牌库工具调用来完成。 除牌库外的一切都由LLM自行管理。合法性检查以及基准测试的评分均由gpt-5.5 (medium)完成。根据我的测试，LLM在评估模拟回合是否合法方面的能力，远强于它们实际执行一个合法回合模拟的能力。 ## 我为何选择使用MCP服务器 既然我能完全掌控数据和LLM API调用，那为何不直接用基本的函数/工具调用，而要选择MCP呢？ 主要原因在于，OpenAI和Anthropic允许你在API请求中提供一个远程MCP服务器URL。这意味着OpenAI或Anthropic会替你处理Agent循环。这带来了两个主要好处： 1. 由于只需一次API调用，你无需在每次工具调用后为缓存的输入token付费（至少OpenAI是这样，后面会进一步说明）。 2. 你可以使用批处理API（batch api）节省50%的费用，而无需在每次工具调用后提交新的批处理。 ## 输入token缓存 在我看来，缓存输入token的计费方式对于Agent循环来说并不合理。这种定价对于独立请求是合理的：如果多个独立的API调用都以相同的大型系统提示开始，那么输入缓存可以让你免费或以小额缓存费获得折扣。 但在Agent循环中，每次工具调用后，大型系统提示都会按缓存输入价格计费。考虑一个例子：假设系统提示已被缓存，且工具调用消耗的可忽略不计的token。 - 大型系统提示 = 10k token - Agent调用了10个工具函数（非并行） - 计费缓存输入token = 10k + 10k * 10 = 110k token 我认为，如果LLM只是暂停了不到一秒钟等待工具函数结果，却在每次Agent回合后都向系统提示收费，这是不合理的。这里忽略了一些细节，比如调用工具需要消耗输出token，而工具函数结果仍需作为输入token处理。但在我的案例中，API成本主要来自每次Agent回合后大型系统提示被作为缓存输入token计费。 当你的应用程序代码包含Agent循环，并在每次工具调用后发起新的API请求时，Agent循环的定价是可以理解的。但当你提供一个远程MCP服务器，且不自行处理Agent循环时，这种定价就更不合理了。OpenAI的处理方式是正确的：向OpenAI发起一个带有远程MCP服务器的API请求，只会针对输入提示收费一次。然而，Anthropic带有远程MCP服务器的API调用则像上面的例子一样。 一些实际数据：gpt-5.5 (medium)基准测试中，每回合魔法牌平均输入token为11,386。而claude-fable-5 (medium)的平均输入token则为51,610。 ## 过于激进的工具调用 这个基准测试对过于急切调用工具的模型惩罚更重，远超大多数基准测试。在很多情况下，工具调用只是为了获取信息，因此如果模型调用了过多工具，唯一的代价就是浪费输入token以及工具结果占用的上下文窗口。即使工具改变了状态，通常也可以撤销，从而保证最终结果正确。 但在模拟万智牌时情况并非如此。如果你抓了一张牌，然后意识到这是个错误，你无法简单地把牌放回去。即使你将牌放回了牌库，你现在已经知道了这张牌是什么，因此模拟是非法的。 一个常见的失败模式是：模型开始调用某个工具，然后意识到这是个错误，却无法纠正。所有牌库MCP函数都有一个必需的reason字段。如果你查看 Opus 4.8 的这个例子 (https://app.mtgautodeck.com/public/benchmarks/6349dda2-4069-4825-971e-8c11234260c4?simulation=14d0d2df-c5af-4c78-83ed-6131ff589b34&run=ad893839-5bbd-4695-8fe2-1a3e80d0dd8b&turn=1)，会看到它用reason为“Draw for turn”抓了一张牌，然后又用reason为“No-op check not needed; cancel”将牌放回牌库。接着它又用reason为“noop”将一张名为“x”的牌放回牌库，然后又用reason为“stop”重复了该操作。 ## 下一步计划 我创建了MTG Auto Deck (https://mtgautodeck.com/) 作为尝试“氛围编码”（vibe coding）的方式。我之前并未跟上基于LLM的编码发展，最终在未手写一行代码的情况下完成了这个项目和基准测试。 我之所以制作了包含账户和支付功能的在线版本，仅仅是因为实现起来非常快。该项目在GitHub上 (https://github.com/CallumFerguson/mtg-auto-deck)，如果你想运行它并使用自己的API密钥或本地 llama.cpp。 我不建议实际为在线版本付费。考虑到当前能准确玩万智牌的模型的价格和速度，该应用并没有提供太多实用性。逐回合模拟比使用在线工具手动黄金鱼测试套牌要慢得多。而且并行运行数十次模拟并给出摘要的成本过高。 随着更好、更便宜的LLM发布，我认为这个应用会有一个有用的版本。我可以想象运行数百次模拟，然后给出关于哪些牌好哪些牌差的统计结果。或者通过自动替换牌来优化套牌。