盲测先藏标准答案：阿里云用 13 类投诉看日志结论停在哪

晚上 9:47，玩家说刚付了 648 元，钱扣了，充值包没到。订单显示支付成功，回调的签名也通过了。发货日志只有一行 deliver_status=failed，顺着 trace_id 到系统日志，错误码是 BAG_FULL。熟手知道这是背包满了，系统重试发货仍失败。新手看到的只是散落在不同 LogStore 里的字段。阿里云社区在 2026 年 10 月 29 日写的是，SLS 语义层和 DataAgent 怎么把这些字段翻成可以核对的业务结论。SLS 是阿里云的日志服务。DataAgent 是挂在语义层上的对话式排查助手。演示日志是合成的，项目名叫 semantic-game-demo。

同类投诉通常要跨多个 LogStore，按顺序查 3 到 6 次。查到数据也不等于看懂。不同团队对「收入」「到账」「赢了却掉分」的算法不一样，先得问这句话指的是哪一种定义。

1. 日志只记事实

deliver_status=delivered 和 item_id=WPN_LEG_001 本身不写「已发货」和「大剑」。语义层把字段、枚举、指标、术语和样例收成一本业务词典。DataAgent 至少挂一个 Context Model，把玩家的原话对上明确的指标和数据源，再查、再串证据，最后给出结论和回复草稿。每一步都可以回看。

订单日志里，金额单位是分。他们把「认可充值收入」写成 SUM(CASE WHEN deliver_status = 'delivered' THEN amount ELSE 0 END)。玩家说的「大剑」，日志里是 WPN_LEG_001。没有这层对照，模型往往会拿玩家的原话做全文搜索，搜不到就说道具没丢。

直接让模型查日志，也会停在第一个像样的答案：看到发货失败，就归咎发货，不再问为什么失败。语义层规定先看支付、再看发货、再看系统错误和背包容量，结论才落到库存满。

2. 三层各自干什么

全部合成日志写进 semantic-game-demo。排查时 DataAgent 只用三个业务证据库。game-biz 放订单、支付回调、发货、背包和道具变化，以及礼物邮件、公会和赛季奖励。game-audit 放支付风控、玩家交易、对局结算、反作弊和申诉。game-system 放故障、依赖、性能和赛季规则。多数事件带 user_id、server_id、时间戳和 trace_id。跨库再靠 order_id、battle_id、item_uuid 把证据串起来。

Source Model 和项目一对一，不用另起名字。自动生成时，模型一起看仪表盘、告警、Scheduled SQL 和抽样，抽出字段语义、指标和术语。耗时看 LogStore 数量和数据量，通常几分钟。结果分三态：证据够就自动采纳；证据薄或有歧义则未采纳，等人确认；人核对过的是人工采纳。DataAgent 只用已采纳的内容，拿不准的字段不会被当成业务事实。

Context Model 是账号级语义层。一个业务跨多个项目时，先选相关项目的 Source Model，再从里面挑这个业务真正要用的 LogStore。这篇的客服模型只选上面三个库。无关数据和只用于评测的数据源都不进业务查询。选中库在 Source Model 里已有的内容会自动同步过来，最多延迟 60 秒，而且只增不删。人手补上的指标、术语和样例，自动同步不会改。Codex、OpenClaw、Claude 一类 Agent 也可以接这个模型复用。

3. 盲测先把标准答案藏起来

测试跑在可复现的合成日志上，覆盖 13 类投诉。game-qa-logstore 只放题目、标准答案和评测证据，不是业务查询源。盲测时不能给 DataAgent 这个库的查询权，否则它会看见答案。

充值没到账这题，DataAgent 先看支付：回调成功，签名通过，钱确实付了。再看发货：失败，并且重试了 3 次。然后查原因，系统错误和背包容量指向同一件事：背包满了。最后的结论要支付、发货、系统三份日志一起撑着，单靠一个错误码到不了。

三则代表题把边界写得很紧。道具缺失：用 item_uuid 把背包流水和交易记录对上，登录设备和登录行为未见异常，change_reason=trade_sell，售价 64663 金币。结论只说，现有日志显示这件道具是从当前账号卖到拍卖行的，到目前没有异常登录或异常设备的证据，建议把交易记录给玩家，并提醒检查账号安全。它没有说「没被盗」。

对局 BT_FC3E058B：battle_result=win，分数从 1259 降到 1237，rank_change_reason=disconnect_penalty，断线 130 到 200 秒，超过 120 秒阈值。掉分来自「断线算弃赛」，不是普通胜场计分坏了。

误封申诉 CHT_922FE15A：检测值 8.85，大约比阈值 8.5 高 4.1%；ml_score=0.62，低于高置信门槛 0.7；内存扫描干净；ping 180 到 250 毫秒。现有证据更支持高延迟造成的移速计算偏差，建议交给反作弊人工复核。它没有推翻封禁。

问题可能对上多个指标时，DataAgent 先问要用哪一种，再继续查。例如「revenue」可能是订单面值、实付金额，或已经交付的金额。想少问几次，就要在 Context Model 里把术语、指标说明和样例写得更死。

4. 能自动到哪一步

搭起来有四个前提动作：为 semantic-game-demo 生成 Source Model；未采纳的条目先核对业务含义，再批量采纳或逐条改完采纳；建游戏 Context Model，说明覆盖充值、道具、排位和反作弊；创建客服 DataAgent 并挂上这个模型。日志要已经在项目里，相关 LogStore 要有查询所需的字段索引，操作者也要有创建和配置 DataAgent 的权限。

运行时默认用系统 RAM 角色 aliyunslsdataagentrole。授权没完成就先走授权链接。若要限制它能访问的资源，改用自定义角色，操作者需要对应的 ram:PassRole。

退款、补发、封禁、解封不交给它执行。它只出证据和建议，人复核之后才能做。定义也要先于覆盖：金额单位、状态枚举、时间字段、唯一标识和指标公式，错一个，覆盖的问题越多，偏得越远。

还有三道产品限制。Context Model 和 DataAgent 只在 cn-beijing。Source Model 按地域部署，支持 cn-beijing、cn-shanghai、cn-hangzhou、cn-chengdu、cn-heyuan。Context Model 和 DataAgent 的数量，每个账号、每个用户默认各 50 个，可以申请提高。

13 个场景仿的是常见投诉，不是某一家工作室的真实数据。这篇没有公布 13 类各自的通过率或得分，只规定了盲测隔离、证据要串到哪一步，以及结论必须停在证据停止的地方。

阿里云，阿里云社区，The Player Says 'My Top-Up Never Arrived.' The Log Only Says BAG_FULL.，2026-10-29，https://www.alibabacloud.com/blog/the-player-says-my-top-up-never-arrived--the-log-only-says-bag-full-_603701