描述不可信：阿里云用三天把 UGC 游戏 Agent 收成可回归

描述不可信：阿里云用三天把 UGC 游戏 Agent 收成可回归

阿里云原生社区 2026-08-12 刊登 Yahai 的实践：UGC 游戏平台把 Coding Agent 接进创作链路之后，演示好看，上线体验很差。用户要一款「生存 100 天」的射击游戏，Agent 写下数千行 Lua，调了几十次工具，最后回复「全部完成」。玩家进去却发现枪、怪物和界面都在，地面没有。Agent 的描述里也没提这件事。

文章把这类问题收成一句：描述不可信，只有轨迹可信。卡住的原因同样一致：没有可核对的轨迹，没有对准业务目标的评估标准，没有能回归的数据集。优化全靠手试，改完不知道变好没有，变好了也不知道为什么。给出的路径是：观测取证、分层评估、定位根因、优化回写、数据集回归、常态监测。文中说这条路径第一次闭环用了 3 天，在生产环境抓出 5 个以上的代码生成缺陷和 API 文档缺陷。

先拆开评，不要一上来打总分

步骤 0 被写成最容易跳过、也最致命。UGC 游戏 Agent 的质量不是一个维度，混成总分既解释不了，也优化不了。落地先做两层。

通用层看事情做完没有、工具是否顺、轨迹是否合理。典型失败是去读不存在的参考文档、参数格式错误、无效重试、做到一半放弃。用 AgentLoop 里现成的评估器，例如工具调用成功率和任务完成度。事实层看生成的代码是否符合平台 API 的真实定义。典型失败是参数顺序反了、把模块函数当实例方法、调用不存在的方法。做法是自定义 Agent Judge，再挂上游戏 API Skill，把它当成唯一事实来源。

建议是通用层第一天上线，当天就能出结果；事实层紧跟着上，回报最高。文中的实际节奏：第一天用内置的「工具调用成功率」同时抓住测试环境和生产环境的失败调用，再由专家复核，这是让业务侧相信方法有效的第一下。第二天的 API 事实性评估器，直接在生产环境挖出 5 个以上的代码生成缺陷和文档缺陷。

第三层叫玩法层，判断做出来的是不是用户要的。价值高，风险也高：UGC 的玩法是玩家想出来的，不是平台事先列好的。评估标准一旦写死，就会变成创造力的天花板。所以等前两层稳住再做，文末才展开。

第一天先能取证，不要停在「看见数据」

UGC 场景的链路是：游戏客户端、Go 网关、Agent 运行时（文中举例 Claude Code）、外部依赖（模型、工具、知识库）。接入有两条路。Hook（LoongSuite Pilot Hook）适合先把管道铺通：改动小，文中写 1 小时内能接入并看到数据，LLM、工具和 RAG 三类都有，对齐 OTel 语义；代价是跨进程标签难传。语言 Agent 自动插桩适合要业务字段的时候：能加关卡、玩法类型、创作会话来源，也能把跨进程 Trace 接上；代价是要按语言装 Agent 并配环境变量。两条都可以用自然语言把安装说明交给 Agent 去做，避免手敲命令。节奏是第一天用 Hook，第二天按需要换成 Agent。换成 Node.js Agent 之后，LLM 调用、工具调用和 RAG 检索三类数据核对无误。

Hook 安装要打开日志和 Trace 采集，并填日志服务、CMS 的接入参数。本文不重复那条带占位密钥的命令。文中单独强调 service-name-prefix：评估任务以后怎么过滤，取决于这个前缀。从一开始就把环境和角色编进去，例如开发和生产各一个名字，比上线后再改省事。Node.js 路径是安装 @loongsuite/cms_node_sdk，用环境变量区分服务名和地域，再用 register 启动。业务属性要进 Span，或要解决跨进程标签，只能走这条。测试环境和海外生产同时接时，工作空间或应用名按环境分开，否则后面的过滤会很烦。

验收打开 AI Agent 可观测的 Tracing，点开任意一条 Trace：要看到 Agent 数、总 Token、输入和输出 Token、缓存命中率、LLM 次数、工具次数、TTFT；推理轨迹要能按 System、User、Assistant、Tool 展开，每次工具调用的参数和返回值都在。文中给了一条真实会话作参照，不是汇总指标：复刻一个灾难模拟器，用时 2 分 1 秒，Agent 数为 1，总 Token 1,367,194，其中输入 1,360,361、输出 6,833，缓存命中率 82%，LLM 11 次，工具 14 次。输入 Token 占 99.5%。文章把这组数同时当成成本优化的入口：上下文工程还有很大空间。超过 20 分钟的长会话，轨迹容易丢，接入后要单独验证。拉起子进程时如果上下文没传，轨迹会断，评估器就取不到证。

评估器：通用层打底，事实层才是突破

AgentLoop 有预置评估器和自定义评估器。自定义又分两种：纯 LLM Judge 只靠提示词打分；Agent Judge 是打分提示词再挂上 Skill 或 MCP，裁判可以先查证再打分。经验规则是：一眼能判断对错的用 LLM Judge；得「翻手册」才能下结论的用 Agent Judge。UGC 的 API 事实层必须用 Agent Judge。

通用层的价值是零成本起步，创建任务时勾选即可，当天拿到带证据的第一份报告。优先级是：工具调用成功率，抓失败、参数格式错误和无效重试，必选；工具选择合理性，抓「用世界掉落接口去回答放进背包」这类选错工具，必选；任务完成度，抓做到一半却回复全部完成，建议选；执行效率，抓来回试错和绕路，给成本优化提供输入，建议选；安全与毒性，面向 C 端尤其是未成年用户时是硬红线，必选。不要这一层贪多。先看成功率和工具选择。这两项掉下去，问题在工具和 Skill，和玩法设计无关，修得最快。

文中一条匿名样例的工具调用成功率是 0.9：大约 45 次调用里 3 次失败。1 次去读不存在的参考文档；2 次因参数格式错误（JSON 字符串包错）设置属性失败，随后 Agent 自己改对并执行成功；1 次试图用命令行直接注入 Lua 失败，改走 run-lua 后解决。其余 Skill、命令行、API 查询和文件操作都返回了预期结果。成功率大约 42/45。这段解释的用处不是 0.9 本身，而是指出三种失败：文档索引缺失、参数序列化规范缺失、工具选得不合适。三者以后都能写成 Skill 里的防错栏。

事实层被写成整个项目回报最高的评估器。UGC 脚本 API 有数百个模块，幻觉最集中在调用上：忘了参数顺序、把服务模块函数当实例方法、或直接编一个不存在的方法名。关键是锁死唯一事实来源。提示词开头要求裁判只根据用户原话和完整轨迹，判断生成、修改、解释或执行的代码是否严格符合 ugc-api-reference-skill 里记下的 API。评估时必须先通读该 Skill 的 SKILL.md，再按其中的查阅纪律只读待查 API 对应的参考文件。禁止用模型记忆、函数名像不像、别的游戏引擎经验、常识推断或 Agent 自己的说法代替 Skill 证据。Skill 里没有明确支持的，不能判对；Skill 里写清了的，不能被外部说法翻案。

配置对应三件事。引用变量只设 input、output 和 agent_trajectory。能力挂载把 ugc-api-reference-skill 挂到评估器上，这是 Agent Judge 和 LLM Judge 的分界：裁判打分时会真的去读手册。计分是比例，score 等于正确项除以（正确项加错误项），「无法核实」不进分母，保留一位小数。一条「参照某平台复刻灾难模拟玩法」的请求得 0.4：共查 16 项，5 项正确，9 项错误，2 项无法核实。错误细节都标了证据文件位置，原文因涉及代码细节没有展开。那 2 项无法核实是 Skill 绑定里提到、但 API 参考里没有独立定义的框架方法。文章认为这不是 Agent 的错，是文档的洞。评估器在评 Agent 的同时，也在查文档是否健康。

无论改预置还是写自定义，提示词建议按固定六段：一句话角色；需要动态基线时先从轨迹抽取再打分；逐条评估维度，有多项就标权重；公式、精度和边界（没有工具调用、幻觉、外部中断各给什么分）；评估内容只放真正参与打分的占位符，每个前面加中文标签；输出强约束为只有合法 JSON，score 是浮点，explanation 是字符串，禁止 Markdown 代码块和问候。

几条违反就会把评估器做坏的约束：占位符必须来自平台字段白名单，不要自造 reference 或 ground_truth，否则映射不上；缺基线就从 agent_trajectory 里现场抽。用 output 判断结果有没有达到，用 agent_trajectory 判断过程和约束，每个维度写清证据从哪来。explanation 必须写出计算过程，这是人工抽查和申诉的唯一依据。某一维不适用时，权重要按比例分给仍生效的维度，否则总分会被系统性地拉低。平台当时有 18 个模板，冷启动先套模板再改，不要从零写。附录骨架里，最终输出的占位符写成了 outputput，比平台字段 output 多了一个 put。这是页面模板里的写法，不能当成可用字段名照抄。边界是：轨迹里没有 API 调用、且指令也不要求调用，记 1.0；轨迹为空或因平台错误中断，按已完成部分打分并注明。只统计最终写进工程且没有被撤回的调用点。

抽样比评估器更能决定账单

任务在「评估、评估任务、新建」里配。四个参数：事实性评估用 Trace，工具调用可以用 Span，因为事实性要看完整过程，Span 粒度看不到全貌。过滤用 serviceName、环境或场景标签锁死，避免把闲聊和查文档送进游戏代码评估器。冷启动 100% 全评，稳定后可以抽样，文中举例 10%。运行上新数据持续评和历史回放一起做，前者看线上，后者做版本回归。

看结果时，分数区间是 0 到 1、精度 0.1，通常只看 0.8 以下，那是 Bad Case 的主战场。高级过滤支持 traceId、spanId、sessionId、experimentId、datasetId。比版本靠 experimentId。详情里点 traceId 可以秒级跳到调用链，这是「从分数到证据」的动作。分组视图把同一样本上各个评估器的结果放在一起，一眼看到这条 Trace 的工具成功率和 API 正确性。

0.4 分不能直接去改提示词

UGC 场景要求三级取证。第一级读评估理由，先分类：参数顺序、不存在的方法、调用形式（模块函数、实例方法、组件方法）或缺少参数。第二级回到轨迹，切到推理轨迹页，按关键词找到那次工具调用，确认当时 Agent 拿到的上下文和工具返回了什么。这一步区分「Agent 判断错了」还是「它收到的信息一开始就是错的」。第三级打开平台脚本 API 的 Wiki，再对一遍事件参数表和函数签名。实践中常在这一级发现文档自身有问题，评估器标成无法核实的项，回查后确认是文档没有独立定义，不是幻觉。

三级走完，低分样本只归三类：Skill 或知识没写清、写得含糊，回到第 5 步写防错栏；API 文档本身错了或漏了，交给文档维护并同步更新参考文件；Agent 的决策或流程有问题，才改提示词、工具描述或路由。不要跳过这步直接改提示词。文中说，那 9 个错误项的根因绝大多数在 Skill 和文档，改提示词只是治标。

回写的是最小防错，不是把提示词写长

闭环真正合上的地方是：把低分根因写成 API Skill 里最小的防错规则。第一批试点选「运行时发放物品或枪」，因为有一条 0 分样本：开局生成一把枪再放进背包。Agent 用世界掉落接口回答「放进背包」，枪永远不会出现在背包里。回写进 SKILL.md 的栏（函数名已匿名）要求先填三个槽：玩家 UIN、物品 ID、掉落类型（背包实例、地面掉落、玩家模板初始背包）。任一槽是空的，就不许写调用。「默认生成或初始背包」不是运行时 API，不能用脚本假装已经配好。「运行中放进背包」和「掉在地上、玩家旁边可捡」必须读不同的参考文件，禁止用掉落接口回答放进背包。枪必须走创建枪的 API，并留下返回的实例 ID；AddItem 的返回数量不是枪的实例 ID。只有在运行模式或真实玩家 UIN 下才能宣布成功；进不了运行模式，必须写明只完成了源码或 API 配置，背包没有实际核验。

这套栏有四点可复用：信息不齐就不许调用；把语义请求路由到具体参考文件，而不是靠记忆选 API；留下返回 ID 再读一次，把「声称成功」变成「可核验的成功」；核验不了就明说没核验。纪律是只改 Skill 的防错栏，不改自动生成的参考文件；每次回写后跑一遍 Skill 库校验，要 0 错误、0 警告；API 事实写入前逐条对过对应参考。节奏按低分密度给模块排队。第一轮之后排队的是特效资源搜索、生物预制体创建、运行模式排障。

第一批回归集只有 3 条，而且没有公布改前改后的分差

防错栏写完必须回归，否则只是觉得变好了。BadCase 数据集至少要有：id、input（用户原话，打开中文分词）、output（优化前的 Agent 输出）、score_value、explanation、写入时间 _time_，以及 tag 或 module，例如特效、背包、界面、生物预制体。收集有两个入口：评估结果里筛低分回流；调用链详情页「加入数据集」。没有语义标注，回归会把所有样本送进所有评估器，用 API 事实性去评一条纯咨询，纯属浪费。按标注路由到不同数据集，才是控成本的动作。第一版不用大。实践中第一批只有 3 条，分数分别是 0、0.4、0.5，闭环仍然跑通。价值在代表性，不在规模。

离线实验用 agentloop-sdk，指定 workspace、数据集和地域，每个样本返回输出和轨迹，实验名举例 api-skill-guardrail-v2，并行 worker 为 4，样本多时改用 RayEvaluator。跑完终端打印实验完成，记录同步回平台。很多团队第一次会漏的动作是：experiment_id 必须经上下文透传进轨迹，评估时再从轨迹上下文取出，写进评估结果。否则结果页不能按这次实验过滤，看板不能按实验比优化前后，实验记录里也不能相对基线逐条比输出和分数。另一个建议是每个任务单独开会话，避免多样本共用会话污染上下文。

第 7 步把项目做成常态。至少三块看板：线上表现，各评估器分数趋势、低分数量、按模块的分布；变更验证，按 experiment_id 看每次 Skill 回写或提示词修改前后；成本，Token 和缓存命中率。告警至少包括工具调用成功率掉到阈值以下、API 事实性周均分下滑、单会话 Token 异常升高。文中没有给出这些阈值的具体数字。

三天表是：第一天上午 Hook 接入测试加生产，能下钻到 Span；下午勾选通用评估器，抓到真实的工具调用失败并通过专家复核。第二天上午换成 Agent 接入，推理轨迹能完整回放；下午做出挂着 API Skill 的事实性评估器，能定位到错误 API 和证据文件；夜里把基础数据集、实验、轨迹上报和 experiment_id 透传跑通。第三天上午对低分做三级取证，每条低分都有可核对根因；下午回写 Skill 并通过 0 错误校验，同时建好 BadCase 集；夜里按该数据集做回归，由专家二次复核。

业务结果按匿名后的原话列出：事实性评估器上线后，在生产环境发现 5 个以上代码生成缺陷或 API 文档问题，同一类错误会在多个脚本里重复出现，人工抽查几乎盖不全。单条样本 16 项检查里 9 项错误，每项能落到函数签名和证据文件，可以直接开研发单。玩法层的试点在「生存 100 天」里找出全程没有可站立场景的执行证据，而输出没有提及；这类「声称完成、轨迹里没有证据」手工验收很容易漏。工具成功率同时抓住测试和生产的失败调用，三种失败模式都收进了 Skill 防错栏。效率上，从人工试玩找问题，变成自动打分加证据定位，文中写每条样本 3 分钟给出带完整推理链的结论；回归从做不到变成能快速验证；从零到闭环是 3 天。机制上，低分样本、可核对根因、最小防错、下一次回归，不再依赖个人经验。观测同时露出成本空间：单会话输入 Token 占 99.5%，缓存命中 82%。

玩法层故意不预设玩法名单

通用层解决顺不顺，事实层解决代码写得对不对，还没回答：做出来的是不是玩家要的。前面的试点已经说明这一层有用：枪、怪物、计分和气氛都做了，就是没有能站的场景，玩家进去会掉进虚空。工具调用全部成功，API 也写对了，结果仍然是错的。通用层和事实层都抓不到。

直观做法是把跑酷、塔防、生存、解谜列成名单，每种配一套固定 Rubric。文章判定这个方向是错的。名单一旦写死，玩家新发明的玩法会被系统性地打低分，Agent 也会为了分数收敛到那些标准形态，评估器就成了创造力的上限。原则改成：评估器不预设任何玩法，每次从用户输入里动态抽出需求清单，只判断「用户要的有没有被做对」。暂定的、与具体玩法无关的维度是：需求覆盖、能跑起来并能进入、所要求功能是否与描述一致、玩家能否看见被要求的状态、气氛和风格方向是否一致。纪律是：只给用户明确要求的项打分，用户没提的独立玩法不扣分，Agent 主动多做的创新不扣分；结论必须基于轨迹，输出里声称但轨迹里没有的，视为未完成；不评美感和好不好玩。「这一关不好玩」不是可优化信号，「用户要的传送门没做」才是。若要沉淀某种玩法的细则，只能作为可选插件，用来细化「某个需求怎样算做对」，不能变成新的必选项，也不能因为没有匹配的 Rubric 就降分或拒绝评估。上线时机是通用层和事实层已经被业务认可、Bad Case 积累到一定规模之后。这一层最主观，要先有一批人工标注来校准裁判，否则分数波动会让业务侧不认。

坑清单还有：不要用 output 打分，乐观描述要写进每条评估器的硬规则里；不要在评估器里写死工具名，按语义匹配，平台工具名会变。

限制：0.9、0.4、0、0.5、16 项里 9 项错、5 个以上缺陷、2 分 1 秒和 1,367,194 Token、每条 3 分钟、18 个模板、1 小时接入、10% 抽样，都是这篇实践里的例子或建议，不是公开的多版本对照榜。第三天夜里要求比较优化前后，正文的结果段没有给出回写之后的新分数。玩法层的五个维度仍是计划中的原则。附录里的 outputput 是模板笔误。安装命令和匿名后的函数名不进入本文。

出处：阿里云，Yahai，Alibaba Cloud Native Community，3 Days, 7 Steps: Optimizing Game Agent Performance Based on AgentLoop，2026-08-12，https://www.alibabacloud.com/blog/3-days-7-steps-optimizing-game-agent-performance-based-on-agentloop_603449