AI Agent 的游戏技术路径¶

普通 LLM NPC 通常是“玩家说一句，模型回一句”。Agent 多了世界状态、工具调用和结果回传，能根据执行结果继续下一轮：

读取观测
  → 选择目标
  → 调用工具
  → 检查结果
  → 修正计划

公开项目可以看的是：它们怎样把画面、文字和动作接起来，哪些环节仍然需要人工约束。

Cradle：截图输入，键鼠输出¶

Cradle 的目标是让同一个 Agent 框架运行多个商业游戏。它用截图作为输入，用键盘和鼠标作为输出，项目里包含《荒野大镖客 2》《星露谷物语》《城市：天际线》和《Dealer's Life 2》等环境。¹

它的工程结构有几个具体点：

• 每个游戏有自己的环境配置、原子技能、组合技能和技能注册表。
• 实时游戏在等待模型返回时会暂停，避免角色在推理期间被攻击。
• 不稳定的图标会先替换成文字，减少视觉模型把相似图标认错。
• 每次执行保存截图、动作和中间结果，便于回放。

这套方案适合自动化测试和跨游戏实验，但成本不只在模型：

• 截图频率高于模型调用频率时，会积压帧；低于交互速度时，会漏掉短动画。
• 游戏窗口分辨率、缩放和遮挡会改变识别结果。
• 键鼠输入依赖窗口焦点和输入法状态。
• 每次测试是否从同一个存档开始，决定了结果能不能比较。
• 只看到画面时，很难判断“按钮没响应”还是“动作已经发出但游戏卡住了”。

如果用来做回归测试，至少要有固定的启动存档、明确的进入条件、动作后的断言和失败回放。没有这些，Agent 只能算“看起来在玩”，不能算稳定测试。

Voyager：课程、技能库和代码执行¶

Voyager 是 Minecraft 里的研究项目。它的核心流程包括三个循环：

1. 自动课程根据当前状态生成下一个目标。
2. 模型编写可执行代码完成目标。
3. 执行结果、错误和自检结果回到下一轮提示。
4. 验证通过的代码进入技能库，后续可以检索和组合。

技能库解决的是重复探索的问题。学会“砍树”和“合成工作台”以后，下一次不必从零生成整段代码，而是先找已有技能，再组合成新技能。

Voyager 给出的实验结果是：获得的独特物品数量是之前方法的 3.3 倍，移动距离是 2.3 倍，解锁关键技术树节点最多快 15.3 倍。² 这些数字来自特定环境、模型和实验设置，不能直接当成自己项目里的预期收益。

这里最容易被忽略的是执行安全。技能库保存的是代码，不是普通文本。正式游戏里直接运行模型生成的代码，需要沙箱、资源限额、网络和文件访问限制；没有这些条件时，更稳的做法是保存参数化工具调用，或者只允许运行审核过的脚本版本。

技能还要跟着构建版本失效。游戏更新后，物品 ID、交互距离和 UI 流程都可能变化，旧技能上次成功不代表这次仍可用。

Generative Agents：记忆和社交模拟¶

Generative Agents 在 Smallville 里放了 25 个 NPC。每个 NPC 有记忆流、检索、反思和计划，模拟步长是 10 秒。³

它的结构适合处理长期社交状态：

• 观察先写入记忆流。
• 检索时综合新近程度、重要性和相关性。
• 定期把零散记忆整理成更高层的反思。
• 计划和反思再写回记忆，影响后续行为。

这套机制适合研究 NPC 之间的关系、日程安排和对话一致性，不适合直接承担实时战斗。10 秒一个模拟步，意味着角色在两次决策之间不会对每个动作做出反应。把它接到实时游戏里，需要额外的行为层和中断机制。

另一个实际问题是记忆规模。记忆越多，检索、压缩和一致性维护的成本越高。研究环境可以用较长的时间预算，线上游戏还要考虑每个 NPC 的 token、存储和并发成本。

TaskFrame：高层规划和帧级控制分开¶

2026 年的 TaskFrame 把游戏 Agent 分成两层：

• 上层视觉语言模型负责把目标拆成原子指令。
• 下层控制器根据当前画面生成键盘、鼠标和视角动作。

它把目标 token 的隐藏状态缓存下来，控制器每一步复用，不需要在每个控制周期重新跑完整规划器。论文采用三阶段训练：规划器训练、控制器预训练、联合对齐，并在 Minecraft 中做端到端评测。⁴

这里的关键是职责划分：高层可以慢，低层必须在帧预算内完成；高层输出“去砍这棵树”，低层决定这一帧怎么转向、走哪一步、什么时候点击。

边界也很明显：

• 控制器依赖训练时的画面、动作空间和游戏版本。
• 画面风格、分辨率、UI 和输入延迟变化后，需要重新验证。
• 只适合有明确目标的离散动作，不适合所有类型的游戏。
• 端到端结果不能直接证明在真人玩家、网络抖动和异常 UI 下同样稳定。

能复用什么¶

这些项目的共同点是把一部分决策交给确定性代码。工具、状态机、寻路、战斗判定和存档规则仍然由游戏实现，模型只处理需要语言理解和开放目标的环节。

失败信号¶

Agent 出问题时，日志里通常有几个固定信号：

最危险的是“看起来执行了”。例如 move_to 返回成功，但角色只走了一步就被门挡住；say 返回成功，但 NPC 已经离开对话范围；use_item 扣了物品，但任务状态没有更新。所有工具都要有可验证的后置条件。

一个最小实验¶

不要先接十个 NPC。先做一个 NPC、一个任务、三个工具：

1. get_observation：只读当前任务相关状态。
2. move_to：返回到达、阻挡、打断或超时。
3. say：只接受已存在的对话 ID，不接受自由文本直接写 UI。

然后固定存档、随机种子和构建，跑同一段任务 20 次，记录：

• 完成率。
• 每步耗时和首动作延迟。
• 重复调用和无效参数次数。
• 观测过期次数。
• 失败后能否回到安全状态。

这组数据比一次演示更能说明 Agent 是否可上线。能够稳定完成一个短任务，再考虑增加技能库、记忆和自动课程。

Agent 适合“需要理解上下文、可以慢一点”的任务，例如任务规划、NPC 对话、关卡测试和开放世界目标分解。实时战斗、精确瞄准和帧级移动仍然交给行为树、Utility AI 或专门控制器。