10 月 2 日，agent-wow 的作者贴出一次实验记录。他给 Codex 一句话：

create an orc character and complete all quests in the starting zone

40 分钟后，任务清单清空了，角色一次没死，路上也没出什么岔子。整个过程里，他没有给模型看过一帧游戏画面，没有模拟键盘鼠标，也没有去动游戏客户端。模型背后是 GPT-6 Astra，推理档位拉到了 xhigh，它连的是游戏服务器本身。

作者的原话是，他一开始根本不信这事能成。就算能成，也以为要折腾几个小时，中间还得走一堆弯路。

为什么挑魔兽世界当考场#

这是作者从经典旧世一路玩到巫妖王的游戏，熟。更实际的理由是，魔兽世界在长期规划和短期操作之间有一个少见的平衡点。

练满级这件事本身就是一棵依赖树：把前置任务链清完、装备凑到能进本、找到职业搭配合理的公会。每根枝条还能继续往下拆。某个部位的毕业装备要靠制造，制造又要资源和技能，角色可以自己去刷，也可以花钱买，两种做法通往同一个结果，路径完全不同。

再往上就是团本。25 个人要同步，技能循环要打满伤害，脚下还得躲开火，一切都发生在几秒钟之内。

这种结构正好能压测 agent：一部分任务需要提前好几步想清楚，另一部分必须当场做对。作者把目标放得很远，他想把整个服务器塞满 AI agent，看它们能不能在英雄难度下打通冰冠堡垒。打不过也行，能看到它们走到哪一步就算收获。

这个框架不提供动作，只提供模块#

agent-wow 的取舍很硬。

它不给模型截图，不模拟键鼠，也不去 hook 客户端。它的做法是让 agent 直接跟服务端讲话，用的是魔兽世界自己的网络协议。

更要紧的是，这个框架里没有任何游戏动作。没有移动，没有攻击，没有对话。它只提供一套模块系统，agent 缺什么能力，自己写。

作者原本不是这么想的。他最初的方案是做一个完全无头的魔兽客户端，把 agent 会用到的原语都封装整齐。写了 1.6 万行代码之后，移动原语还是一堆 bug，寻路做得很难看，整个方案被推翻。换成模块系统之后，框架本身的复杂度降了至少一个数量级。

这个思路来自 Mindcraft。那边的做法是，当内置命令不够用时，允许 agent 自己生成代码去调 Mineflayer 的 API。agent-wow 沿用了同一条路，只是连内置动作都省掉了。作者还提到一个副作用：跑的次数多了，看 agent 反复自己实现哪些模块，就知道哪些原语是真需要的，可以收进核心，剩下的不必操心。

实验全部跑在本地私有服务器上，用的是开源项目 AzerothCore，版本 3.3.5a，也就是巫妖王之怒的最后一个版本。线上服务器一次没连。

它没有用你准备好的高层接口#

作者原本押注 agent 会搭一层高层抽象，把 moveTo、castSpell 这类 RPC 方法暴露出来，好绕开底层的数据包。实际结果反过来了，它在协议层干得挺顺。

它最后只写了一个模块，订阅 28 种服务端消息，把它们存在内存里。这些消息覆盖的场景包括角色进入世界、周围对象发生变化、怪物移动、NPC 对话、任务列表与详情、任务完成、拾取、施法失败、攻击距离不对、升级、学技能、购买训练师技能，等等。模块通过 JSON-RPC 对外露出 send 和 poll 两个接口。Python 脚本调 poll，把上次检查点之后的包全部取回来解码，据此更新自己的世界模型：血量、附近的生物、任务进度、掉落。需要动作时再用 send 把客户端消息发回服务端。

模型并没有要求谁把原始协议包装成人话，那些字段它自己就能认。

任务清单是从数据库文件里挖出来的#

事后看，这个做法几乎是最优解。

agent 去读 AzerothCore 的 SQL 文件，把任务需求、发布任务的 NPC、交任务的 NPC、刷新坐标统统抽出来，得到一份具体的清单和位置表。有了这份东西，它排得出任务顺序，也算得清准备工作：先把前置链走完，顺手把垃圾卖掉，换上更好的装备，在进最后一段山洞之前把技能学掉。它还发现山洞里挂着两个任务，于是同时接下，一趟跑完。

作者对这一步的评价挺宽容。他说这跟一个真人花几个小时泡 Wowhead 查攻略差不多。

他划的线在另一头：如果 agent 拿到运行中服务器和管理数据库的权限，直接改里面的数据，那就不行了。这次实验没有放进沙箱，所以它理论上够得着那些东西。

寻路是它自己写的一段 C++#

寻路一直是这类机器人最难啃的部分。

agent 的处理方式是自己写了个 C++ 小工具：接收起点和终点的六个数字，加载 AzerothCore 的导航网格文件，用 Detour 这个寻路库在相连的可通行表面上找一条路，最后把路线作为 JSON 坐标数组返回。Python 脚本调用这个可执行文件，读到航点，再发移动包沿路走。

这个工具还处理了导航网格的分块问题，它先把起终点附近可能用到的地图分片都加进网格，再开始算。返回的结果如果中途断了，它会直接报错，而不是给一条半截的路线。

顺带出现了个挺有意思的副作用。录像里能看到角色穿过了墙，估计是某些墙体缺了碰撞属性。agent 的目的只是从 A 走到 B，地图上有洞，它就走了洞。

穿墙这件事，值得多想一层#

我不觉得这是模型的错，但它说明了一个机制。

agent 只认自己收到的目标，环境里有什么缝，它就用什么缝。放在游戏里，这是从墙里穿过去；放在正经项目里，同一个机制会变成把失败的测试跳过、把类型断言改成 any、把超时调长直到 CI 变绿。它不是想作弊，它只是发现这条路更快。

所以沙箱和人工审查不是形式主义。agent 越有能力，越需要有人盯住它能够到什么。

这些事情跟日常写代码有什么关系#

别急着替 agent 设计好用的接口。 那 1.6 万行无头客户端，是「我先想清楚它需要什么」这条路走到尽头的代价。只要 agent 能看见原始接口，它往往自己就能搭出够用的那一层，而且它搭的版本更贴合手上的任务。给 Codex 交代工作时也是同一个道理：给约束和目标，比给实现路径更有用。

能读数据的人赢。 从 SQL 文件里挖任务清单，换个说法就是读源码。人类程序员接手陌生系统时也这么干，先翻 schema、迁移脚本和配置，把领域模型抠出来，再动手。agent 能做同样的事，前提是这些东西在仓库里看得见。只活在文档、聊天记录或者某个人脑子里的知识，对 agent 来说等于不存在。

那条线其实很难画。 读静态文件可以，读运行中的数据库不行。可真实系统里，静态和运行时的边界相当模糊：配置中心算哪一种？只读副本算哪一种？作者自己也是先承认「这次没沙箱，它想做是能做的」，然后才回头计划补一个。

观测是个被顺手暴露的问题#

录像不是靠录屏来的。作者借了 AzerothCore 自带的 GM 命令，写了两个宏：一个把自己的视角绑到 agent 的角色身上，顺手打开 GM 模式并把 GM 标记藏起来，另一个用来解绑。角色走到哪，视角跟到哪。

这招应付单角色、短时间的会话够用。时间拉长、角色变多就不行了。他自己也承认，要跑多 agent 的长会话，得专门写一个 AzerothCore 模块加游戏内插件，把观测这件事做进系统里。

下一步#

作者列了几个问题。单个 agent 能不能自己练到 80 级，路上它必须给自己造哪些工具，又要花多久？多个 agent 能不能配合起来，用游戏里的社交功能一起做任务、一起下副本？

另外还有两件杂活：把观测工具做厚一点，好在挂机的时候跟踪角色；给 agent 加一个沙箱，管住它能访问和修改的东西。

最后#

这次实验里，模型总共只收到一句话。协议、清单、路线和一堆小工具，都是它自己在这一句话底下拆出来的。

看完全程录像，最容易记住的大概是穿墙那一下。但真正值得带走的，是它一路往底层走的选择：接口窄不窄，对它来说不构成障碍，它自己会去找一条能走的路。

参考来源：GPT-6 Astra plays World of Warcraft for the first time with agent-wow，2026 年 10 月 2 日。项目仓库：agent-wow/agent-wow，服务端为开源项目 AzerothCore。