9月游戏圈最热闹的话题除了新游发售就是“游戏Agent”了。这个词今年被反复提起但9月的进展让我觉得它真正从一个偏学术的玩具概念变成了游戏行业可以拿起来就用的工程工具。所谓游戏Agent说人话就是“能像人一样在游戏里做事的AI角色”它可以自动跑图测试游戏、在剧情里扮演有记忆的NPC、甚至替玩家执行重复劳动。这篇内容不打算写成新闻汇总而是结合我9月实际跟踪的一些技术动向和动手实验聊聊游戏Agent到底是什么、最近哪些进展值得关注、以及我自己搭原型时踩过的坑。适合读这篇的大概是三类人游戏客户端或测试开发的工程师正在琢磨怎么把大模型塞进游戏场景产品策划和技术负责人想判断这类技术到没到能落地的程度还有对AI Agent感兴趣、想找个具体切入点练手的同学。1. 9月游戏Agent进展全景技术圈到底在忙什么1.1 从“复读机NPC”到“会记事的NPC”今年9月的风向以前游戏里的NPC背后大多是行为树或者状态机。你能感觉到它在“演戏”对话选项固定台词翻来覆去就那几句哪怕你上一秒把它队友杀了下一秒它还能当无事发生继续发任务。这不算Agent顶多叫“触发式脚本”。9月我观察到好几个团队不约而同把大模型接进了游戏角色里思路出奇一致给NPC加一个“记忆模块”。有个工作室的演示印象很深NPC会记住玩家之前的行为——你偷过它商店里的东西它再见到你会言语不善你帮过它跑腿它会主动给你打折。技术实现并不神秘就是把游戏里的事件流谁、何时、对谁、做了什么灌进大模型再让NPC带着这些“记忆碎片”去生成行为和台词。更有意思的是9月出现了一批专门干脏活的Agent。某实验室放出了一个测试Agent能自己控制角色在开放城市场景里跑图自动触发各种可交互物体遇到卡死、穿模、任务断链这类bug就截图录视频最后生成一份带定位信息的测试报告。据说某次测试覆盖了96%的可交互对象发现十几个严重问题。以前这活儿要人力反复跑现在Agent一晚上能跑好几个小时相当于测试团队多了个不知疲倦的工具人。1.2 框架和基准在补课游戏Agent的“尺子”出现了9月之前游戏Agent最缺的不是模型能力而是两类基础设施一是“怎么写都别扭”的工程框架二是“根本不知道好不好”的评估标准。框架这块社区里开始出现面向游戏场景封装的轻量Agent框架。这类框架把“感知游戏状态、调用大模型、执行动作、写入记忆”这一套流程沉淀成公共模块开发者只需要填游戏自己的接口不用从零搭管道。9月的进展是这类框架开始支持游戏引擎的接入层也就是Agent可以直接拿到引擎里的对象、坐标、背包数据不用靠读取屏幕像素去猜。评估基准更值得聊。以前大家说“我这个Agent挺聪明”都是放几个demo视频自证主观性太强。9月有团队搬出了针对游戏场景的评估体系把“Agent玩得好不好”拆成任务完成率、行为合理性、对话自然度和资源效率几个维度。任务完成率好理解让Agent去目标点、打Boss、找NPC成功多少次。行为合理性看的是Agent有没有绕远路、有没有原地抽搐、有没有违反游戏基本规则。对话自然度偏主观但也用上了人工打分配合自动化指标。有了这把尺子后面迭代优化才说得上有方向。1.3 为什么说9月是个“进度条跳格”的月份说实话游戏Agent不是今年才有的概念。强化学习打游戏都火了好几年了前几年就有AI打《星际争霸》《Dota》的成果。但那些东西离普通游戏开发者太远你要懂强化学习、要搭训练环境、要买一堆显卡。9月这波不一样的地方在于所有方案都是围绕“大模型游戏”的组合而大模型是可以通过API直接用的。这意味着一个普通游戏工作室哪怕只有两三个后端工程师也有可能在几周内接入一套能做事的游戏Agent。成本门槛从“组建算法团队”降到了“接几个API”。9月正好是这种“降门槛”趋势最明显的时刻工具链补上了、评估方法出来了、范例场景也多了。在我看来游戏Agent的赛道算是正式开始“铺路”不再只是前沿论文里的概念验证。2. 核心系统拆解一个能跑起来的游戏Agent到底由什么组成2.1 感知层先让Agent“看到”游戏我见过很多刚上手的人第一步就问“怎么让AI看到游戏画面”。答案其实有两种主流路线各有利弊。第一种是读接口拿结构化状态。如果游戏本身是自研的或者有测试接口Agent可以直接拿到当前位置、血量、任务进度、背包物品这些JSON数据。这种方式解析快、准确度高、大模型理解起来几乎不费力输入Prompt之前不用做任何图像处理。缺点是它要求游戏内部开放数据层很多商业游戏不给你这个机会。第二种是屏幕截图给多模态模型。Agent每隔几秒截一张屏连同一段文字说明丢给多模态大模型让模型“看图说话”判断角色在哪、前面有没有敌人、宝箱在不在视野里。这种方式通用性强理论上任何游戏都能跑但代价也很明显——图像token比文本token贵得多延迟高而且模型偶尔会把画面看错产生“幻觉”。9月的进展里多数演示都选择了第一种、或者两种混合。混合策略通常是常规状态读接口遇到视觉判断类的复杂情况比如识别一个特殊道具是否出现才截图让模型看。2.2 记忆系统短期、长期和“关键时刻”这是9月讨论度最高的模块因为NPC“记事”和Agent“不迷路”都靠它。我用一个生活类比来解释人的记忆分三层。第一层是工作记忆也就是眼前这几秒正在处理的信息对应Agent的对话上下文通常只有几百到几千个token装不下多少东西。第二层是短期记忆比如最近几分钟聊过什么、走过哪些路对应Agent维护的一个“最近N步动作和反馈”的消息队列。第三层是长期记忆比如你的老同学叫什么名字、上次一起吃饭是什么时候对应Agent存进向量数据库的角色档案和世界事件。9月一个很有价值的技术点是把长期记忆的记忆压缩做细了。以前的做法很粗暴所有历史事件一股脑往上下文里塞塞不下就丢最早的。现在的主流做法是分层摘要——重要的事玩家攻击过某个NPC、完成了某个主线节点保存完整细节不重要的事比如玩家在空旷地带走了十步只保留一句话概览。每周或者每几千步做一次异步总结把旧事件的原始日志压缩成摘要存回向量库。这样做的好处是Agent“什么都知道一点关键节点还记得很清楚”而不是一截断就彻底失忆。2.3 决策与规划从“下一步动作”到“目标拆解”感知和记忆解决的是“Agent知道什么”决策层解决“Agent接下来干什么”。最简单的决策是单步策略把当前状态和任务描述拼进Prompt让大模型输出一个动作上楼、向左走、打开背包。这种模式实现快但问题在于大模型没有“计划性”它像一个只顾眼前的玩家不知道自己在做一个多步骤任务时可能会走弯路。所以9月更受关注的方案是任务级规划。把“去村子找铁匠交付材料”这个大目标先拆成几个子目标导航到村子、找到铁匠铺、触发对话、选择交付选项。每个子目标再拆成具体的动作序列。这种“目标-子目标-动作”的层级结构让Agent的行为看起来像真人玩家在玩游戏而不是随机乱试。实现方式上很多团队用了类似ReAct的模式Agent思考当前目标找出需要调用的工具然后观察工具返回的结果再进入下一轮思考。工具在这里很关键导航工具、对话工具、背包工具、地图工具都是预先封装好的能力接口。大模型的任务不是“手搓动作”而是“决定调用哪个工具、传什么参数”。9月我看到几个不错的演示Agent发现自己打不开一扇上锁的门没有傻傻地反复尝试而是调用“询问NPC”工具打听钥匙下落再调用“前往坐标”工具去拿钥匙。这种规划能力是游戏Agent能被叫“Agent”而不是“脚本”的核心原因。2.4 动作执行与安全护栏防止AI“演脱轨”模型输出动作之后游戏端不能无条件信任。这里面有个很现实的坑大模型非常容易“幻觉”编出一个游戏里根本不存在的技能或者往反方向移动。如果没有安全护栏Agent可能直接把角色带进墙里。我在实际项目中就见过这种场面模型因为上下文里出现过“闪现”这个词就在输出里写了“使用闪现技能”我用的模拟环境当然没有这个技能动作解析直接报错。所以动作执行层必须做三件事一是结构化输出。不让模型输出自由文本而是强制输出JSON比如{action: move, target: [3, 3]}。解析稳定也方便校验。二是白名单校验。所有动作必须落在一个预先定义好的动作列表里不在列表里的一律拒绝执行同时触发重试逻辑——让模型重新生成或者走一条兜底路径。三是反馈闭环。Agent执行动作后的环境变化坐标变了没有、血量降了没有、对话框弹了什么必须回到记忆模块作为下一轮决策的输入。没有这个闭环Agent就只能“自己导自己演”根本感知不到动作失败。3. 手把手搭建一个轻量游戏Agent原型3.1 选环境先从“玩具级”开始很多人一上来就想接3A大作我强烈劝退。原因很简单商业游戏不会给你完整的数据接口你只能靠截图和模拟点击调试一轮要十分钟错误信息还隐晦。我自己搭原型用的是自制的网格世界——一个10乘10的格子角色在格子里上下左右移动走到终点格子就算赢。选择“玩具级”环境不是因为能力不够而是因为迭代速度就是一切。在这个环境里我随时可以看到Agent每个动作的完整状态报错了可以马上定位是感知、决策还是执行的问题。把一个极简闭环跑通再替换成复杂环境才是靠谱的路线。9月我身边好几个动手实践的朋友都是从这类模拟环境起步的。3.2 核心代码感知-决策-执行的闭环下面这套代码是我9月搭原型的精简版本去掉了一些业务细节但保留了完整的闭环结构你可以直接抄走跑起来。import json # 1. 极简游戏环境10x10网格世界 class MiniGame: def __init__(self): self.player {x: 0, y: 0, hp: 100} self.target {x: 7, y: 8} self.has_reached False # 执行动作返回新状态 def step(self, action: str) - dict: if action up and self.player[y] 9: self.player[y] 1 elif action down and self.player[y] 0: self.player[y] - 1 elif action left and self.player[x] 0: self.player[x] - 1 elif action right and self.player[x] 9: self.player[x] 1 if (self.player[x], self.player[y]) (self.target[x], self.target[y]): self.has_reached True return self._get_state() def _get_state(self) - dict: return { player: dict(self.player), target: dict(self.target), reached: self.has_reached } # 2. 感知函数把环境状态整理成Prompt def perceive(env: MiniGame) - dict: return env._get_state() # 3. 决策函数调用大模型输出动作 def decide(state: dict, memory: list) - str: # 这里是模拟接口实际替换为你使用的大模型API prompt ( f你是一个网格世界里的游戏Agent。\n f当前状态: {json.dumps(state, ensure_asciiFalse)}\n f你的目标是到达target位置。\n f请只输出一个动作: up/down/left/right。\n f动作: ) # memory 是历史上下文传给大模型 # resp llm_chat(messages[*memory, {role: user, content: prompt}]) # 这里用固定策略替代模型输出先水平移动再垂直移动 if state[player][x] state[target][x]: resp right elif state[player][x] state[target][x]: resp left elif state[player][y] state[target][y]: resp up elif state[player][y] state[target][y]: resp down else: resp down return resp # 4. 主循环感知-决策-执行-记忆 env MiniGame() memory [] MAX_STEPS 50 for step_index in range(MAX_STEPS): state perceive(env) action decide(state, memory) # 执行动作拿到反馈 new_state env.step(action) # 记录到记忆队列保留最近10条 memory.append({ role: user, content: fstep{step_index}: state{state}, action{action}, result{new_state} }) memory memory[-10:] print(fStep {step_index}: action{action}, pos{new_state[player]}) if new_state[reached]: print(Agent reached target!) break这套代码里的决策函数我默认用了固定策略顶替大模型调用方便你跑通流程。换成真实大模型时只需要把prompt发出去再把大模型返回的文本解析成动作字符串。整个闭环的逻辑是通用的感知拿到状态决策产出动作执行反馈回环境经历写进记忆。3.3 关键参数与配置说明真正对接大模型时参数调参比想象中重要。我9月踩了一圈整理了下面这张常用配置表参数推荐值说明temperature动作决策 0.1~0.3对话生成 0.6~0.8动作输出必须稳定温度高了会随机漂移对话可以带点随机性max_tokens动作任务 50~100对话任务 150~300动作类输出不需要长篇大论限制长度可以压延迟超时时间5~10秒模型响应偶尔卡顿超时重试比无脑等待更合理重试次数2~3次重试不是无底洞超过次数降级到预设兜底动作记忆窗口最近10~20条消息超过这个范围的信息应该走长期记忆和摘要而不是硬塞上下文动作格式JSON结构化输出便于白名单校验别让模型放飞自我这里特别想提醒的是temperature的配置。新手最容易犯的错是把所有请求都用同一个温度结果动作指令时而向左时而向右Agent像个喝多了的玩家。我的习惯是涉及“执行动作”的请求一律低温低随机涉及“角色对话”的请求才把温度调上去。这个原则适用于所有游戏Agent场景不只是网格世界。4. 9月实操踩坑实录常见问题与排查思路4.1 Agent打到一半“失忆”忘了目标在哪现象很典型Agent开头几步方向感很好走到第20步突然绕路甚至往回走。排查后发现它根本不是“变笨了”而是上下文被截断了——前面提到目标位置的内容已经滑出了记忆窗口。对小模型尤其明显几千token的上下文窗口塞几轮状态更新就满了。我的解决思路是分层记忆。把“目标位置”“关键路径节点”这类最关键的信息单独抽出来放在每轮Prompt的最前面永远不参与滑动淘汰。剩下那些过程性的状态变更才放进最近消息列表里。这就像你出门旅行会把目的地写在小纸条上揣兜里而不是指望手机的聊天记录帮你记住。4.2 Agent原地转圈来回横跳第二个高频问题Agent在某个格子附近反复执行“左-右-左-右”像卡了Bug。排查时我发现根源是Agent缺少“位置变化”的感知反馈它不知道自己刚才已经在原地打转。它还觉得自己的每次动作都是“新的探索”实际上绕了好几圈。解决方法是给决策函数加一个“最近N步位置记录”。当Agent发现自己在连续5步内位置没有实质变化就触发兜底策略暂停随机移动重新读取导航逻辑或者直接往目标方向直线走几步。这个技巧在复杂环境里尤其管用相当于给Agent安装了一个“原地踏步检测器”。4.3 动作幻觉模型生成一个不存在的技能这个前面提过再展开说说。有次我在测试环境里让Agent“尽可能快地到达房间角落”模型居然输出了一个“瞬移”动作——我的环境根本没这个动作定义。解析阶段直接卡死Agent停在那儿不走了。后来我发现是因为Prompt的历史记录里会包含不同角色的技能描述模型被带偏了。解决分两步。第一步强约束输出格式要求模型只能从候选项里选不能自由发挥。比如在Prompt末尾写“候选动作列表: [up, down, left, right, interact]”并明确要求“如果你不确定就输出down”。第二步动作执行前白名单校验程序层面把非候选动作一律拦截拦截后自动用上个有效动作重试一次。两道关卡下来幻觉动作基本绝迹。4.4 延迟和成本每个动作都要等模型返回最后是性能问题。每一步决策都调一次大模型接口快则200毫秒慢则2秒以上而且费用随调用次数线性增长。在需要高频决策的游戏测试场景里这可能是个大麻烦。我9月的优化思路有三条一缓存。相同或极其接近的状态直接复用之前的决策结果不重复请求模型。二批量处理。如果任务是跑一条固定路线可以把路线处理成一次性的计划让Agent按计划分批执行而不是每一步都问模型。三本地小模型兜底。简单动作比如直线导航用本地部署的小模型判断遇到复杂决策比如需要综合多条件选择策略才调用大模型。这样精度不牺牲太多延迟和成本能降一个量级。5. 我说几句掏心窝的话5.1 为什么我觉得9月是个分水岭9月发生的事单独拎出来看每一项都不算颠覆NPC能记事了测试Agent能跑地图了评估基准能打分了。但放在一起意义就不一样了。这相当于一个行业在“材料准备期”突然同时补齐了框架、尺子和场景案例。以前你说要做游戏Agent基本是从零开始造轮子现在你至少能站在一堆开源实践的肩膀上专注解决自己游戏的特殊问题。方向已经有人蹚过了你还犹豫什么。5.2 给想入局的人三条建议第一千万别想着一步到位把Agent做成“全能玩家”。先找一个小而准的场景切口比如让Agent只负责跑地图找bug或者只负责一个特定NPC的对话和记忆。场景收得越窄技术选型越简单落地概率越高。跑通了再横向扩展这个节奏最稳。第二重视评估。如果团队打算投入做游戏Agent第一天就顺手定一套最小评估方案任务完成率怎么算、行为合理性怎么评、数据从哪收集。没有这套标准你后面根本分不清哪次改动是优化、哪次改动是退化。9月开源的那些评估维度直接拿来改改用就行。第三别忽视“人机协作”的设计。游戏Agent不是要替代玩家和测试工程师而是把机械重复的部分扛走。比如测试Agent负责24小时不间断跑冒烟测试真正需要人判断的“这算不算设计缺陷”还是交给人工。把Agent定位成“超级工具人”产品设计和工程排期都会顺很多。我自己的体会是游戏Agent现在最缺的不是技术而是“愿意动手把场景打磨到能用”的人。模型能力在那里框架也齐全了剩下的就是拿着真实游戏场景去磨磨性能、磨稳定性、磨体验。9月的进展让我相信这个方向接下来几个月还会加速而且第一批吃螃蟹的人大概率已经在闷声干事了。