加载失败
原帖讨论的是一种 agentic test harness（让 LLM/agent 像玩家一样操作游戏）来做 playtesting，尤其适合回合制、文本化的游戏。评论里有人建议，如果游戏逻辑完全确定且能与渲染分离，headless simulator（无界面模拟器）加 Monte Carlo 批量跑局可能比让 LLM 每回合决策更便宜更稳。也有人把 MCP（Model Context Protocol，连接 AI 与外部工具的协议）、Playwright（浏览器自动化框架）、Godot（游戏引擎）或 CLI 接到游戏里，让 agent 读状态、点按钮、看截图来做 E2E tests（端到端测试）。讨论还延伸到 MUD/MOO（文字多人世界）和 Evennia（一个 Python MUD 引擎）这类可被 agents 直接进入并共同构建的虚拟世界。
不少人把 agent 当成游戏的自动试玩员，用来做回归检查和功能验证。原帖里把游戏状态暴露给 AI，再给它一套使用说明和目标，让它像玩家一样跑流程，最有效的是让它针对已知功能或 bug 进行验证，而不是指望它自己稳定发现所有问题。评论里还有人把同样思路用到 Godot、CLI 和浏览器自动化上，甚至让 agent 自己写测试并检查截图，这样可以把“实现 + 验证”一起交给机器。
如果游戏能把逻辑和渲染彻底拆开，很多人认为 headless simulator 加 Monte Carlo 才是平衡测试的放大器。评论里提到可以并行跑成千上万局，记录碰墙、卡住、待机等统计，再用 ELO 类系统比较不同 AI archetype，自动把参数调到更合理的位置。也有人宁愿让 agent 生成 deterministic bot 和决策画像，而不是每回合都调用 LLM，因为这样更适合可重复、可批量的调参工作。
效果好坏很大程度取决于 harness 的输入输出形状，而不是单纯有没有 LLM。有人问 text-only harness、菜单导航、prompt 结构和 token 消耗，回复则建议先把 playtest 过程写成明确的 skill，再把日志整理成 JSON 或 Excel，先人工看几轮再交给 LLM 找异常。另一条经验是，浏览器 E2E 里同时给 agent 源码和实时截图，比只给其中一种更可靠；而把原始 DOM 换成 accessibility tree 也能显著省 token。
实时和物理驱动的游戏更难，因为 agent 看到的往往只是间歇截图，而游戏状态在两次观察之间已经变了。有人给物理引擎加了前进/回退 step API，再配合浏览器里的 `window.game` 接口，让 AI 分别检查物理 bug 和动画/UI 问题，但仍会出现“测试通过”而角色其实卡在星球里的情况。评论里因此强调要暴露更完整的状态，或者像 Bret Victor 那样“collapse time”把轨迹一次性展开；也有人说自己最后还是从文本转向了 pixels 和 OS inputs。
MCP、MUD 和 Evennia 这类工具让讨论从“测试游戏”扩展到“让 agents 进入并改造一个世界”。有人把 MCP server 接到 MUD 上，让多个 Claude Code agent 在不同窗口里协作建房间、做教程、写战斗系统；还有人把世界设计成类似 wiki 的纯文本结构，便于编辑和链接。更激进的设想是把这种 agent 可访问的状态接口推广到 MMORPG、Home Assistant 甚至整个软件生态，让 AI 不只是聊天，而是真正参与和操控系统。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
MCP: Model Context Protocol，一种让 AI 通过标准接口调用文件、浏览器、游戏等外部工具的协议。
E2E tests: End-to-end tests，站在用户视角跑完整流程，用来验证功能、回归和界面是否正常。
MUD/MOO: 文字型多人在线世界/地下城，通常用文本命令在房间、物品和角色之间交互。
agentic test harness: 让 agent 像真实用户一样操作系统或游戏，并回传结果的自动化测试框架。