玩家一句“充值没到账”，客服为何要查多份日志？
晚上 9:47，游戏客服小林收到一条加急工单：
“我刚充了 648 元，钱已经扣了，充值礼包却没到账。”
小林先查订单：支付成功。再看支付回调：签名验证通过。可玩家的礼包为什么没有到账？她继续切换到发货日志，只看到 deliver_status = failed；顺着 trace_id 查到系统日志，又出现了一个错误码：BAG_FULL。
对熟悉业务的老客服来说，这条线索意味着“玩家背包已满，发货重试仍然失败”。但对刚接手业务的人来说，它只是几个分散在不同 Logstore 里的字段和值。为了给玩家一句准确答复，小林需要在订单、支付、发货和背包流水之间来回切换，把机器记录的事实翻译成玩家能够理解的结论。
这并不是一张特殊的工单。游戏运营客服每天都要处理大量类似的咨询和投诉，问题遍布充值支付、道具变动、匹配排位、反作弊申诉和社交纠纷等场景。为了回答一个问题，客服往往需要跨多个 Logstore，连续执行 3～6 步查询：
- 排查慢：客服需要在订单、支付回调、发货和背包流水之间反复切换。
- 依赖经验：同一个字段，新手和资深客服可能得出不同结论。
- 口径不一：“收入”“到账”“赢了扣分”等表述，在不同业务团队中可能对应不同的计算规则。
游戏客服缺的不是日志，而是“业务翻译”
小林遇到的难点，并不是查不到日志，而是日志没有直接说出业务结论：日志记录了事实，却没有完整记录这些事实对应的业务含义。 仅看到 deliver_status = delivered、item_id = WPN_LEG_001，人和 AI 都无法天然知道它们分别代表“已发货”和“裂天刃”。
SLS 语义层与 DataAgent 正是为了补齐这层“业务翻译”：
- 语义层（Semantic Layer） 把 Logstore 中的字段、枚举值、业务指标、术语和示例组织成可复用的“业务字典”。
- DataAgent 绑定至少一个业务模型，将自然语言问题映射到明确的业务口径和数据源，再构造查询、分析证据并生成结论。
三层协作：从原始日志到客服结论
以某款示例游戏为例。模拟日志统一写入 SLS Project semantic-game-demo。DataAgent 排查时使用以下三个业务证据 Logstore：
| Logstore | 主要数据 |
game-biz-logstore |
订单、支付回调与发货，背包与道具变动，礼物邮件、公会及赛季奖励等业务流水 |
game-audit-logstore |
支付风控、玩家交易、匹配与对局结算、反作弊与申诉、举报及赛季参与等审计记录 |
game-system-logstore |
服务错误、依赖异常与恢复、性能指标、赛季规则配置等系统运行记录 |
多数玩家事件包含 user_id、server_id、timestamp 和 trace_id 等通用字段；跨 Logstore 排查还会使用 order_id、battle_id、item_uuid 等业务标识关联证据。在此基础上，三层能力各有分工：
1. 事实模型（Source Model）：描述数据本来的样子
事实模型与 Project 一一对应，无需单独规划名称。启动自动生成后，系统借助 LLM 综合分析仪表盘、告警、Scheduled SQL 和数据抽样，提取字段语义、指标和术语。
提取结果按证据充分程度分为三种状态：
- 自动采纳：证据充分，可直接使用。
- 未采纳：证据不足或存在歧义，需要人工确认。
- 人工采纳：已由人工核对并确认。
事实模型提取和沉淀的语义元素主要包括：
| 语义元素 | 游戏场景示例 | 解决的问题 |
| 字段 | 订单日志中，deliver_status = delivered 表示已发货，amount 的单位为分 |
字段和枚举值怎么解释 |
| 指标 | “充值确认收入” = SUM(CASE WHEN deliver_status = 'delivered' THEN amount ELSE 0 END) |
业务指标怎么计算 |
| 术语 | “钻石” = currency_diamond；“裂天刃” = WPN_LEG_001 |
玩家的说法如何映射到日志 |
DataAgent 只使用已采纳的内容，避免将存疑的字段含义当成业务事实。
2. 业务模型（Context Model）：沉淀可复用的业务字典
业务模型是账号级的中心化语义层。一个 Project 对应一个事实模型（Source Model）。当业务横跨多个 Project 时，可以：
- 选择相关 Project 对应的事实模型；
- 从中框选当前业务需要的 Logstore；
- 将分散的数据语义汇聚成统一的业务模型。
例如，本文的游戏客服业务模型只选择三个业务证据 Logstore，不选择与业务无关或仅用于评测的数据源。
业务模型中的内容来自两部分：
- 自动同步：所选 Logstore 在事实模型中的内容会自动同步，最大延迟为 60 秒，且只增不删。
- 手工补充：可以追加指标、术语和示例，进一步完善业务口径；这部分内容不受自动同步影响。
这种“按业务框选、中心汇聚”的方式，让业务模型既能聚焦特定业务，又能供 DataAgent、Codex、OpenClaw、Claude 等多种 Agent 对接和复用。
3. DataAgent：按照统一口径开展智能排查
DataAgent 是面向对话的智能助手实例，创建时需绑定至少一个业务模型。它不只生成 SQL，还会沿着统一的业务口径完成一条可核对的分析链路：
玩家投诉 ↓ 识别业务术语与指标口径 ↓ 选择数据源并构造查询 ↓ 串联多步日志证据 ↓ 输出结论、证据和答复草稿
四步搭建游戏客服 DataAgent
准备工作
- 已在 Project
semantic-game-demo中准备业务日志。 - 相关 Logstore 已配置查询所需的字段索引。
- 操作者具备创建和配置 DataAgent 所需的权限。
第一步：为 semantic-game-demo 生成事实模型
从 SLS 控制台首页进入 DataAgent。
在“事实模型（Source Model）”页签下，选择业务 Project semantic-game-demo。
启动事实模型生成任务后，可在详情页查看任务状态。生成时间取决于 Project 下 Logstore 的数量和数据规模，通常可在数分钟内完成。
生成完成后，系统会展示从 Logstore 中提取的字段语义、指标和业务术语。
对于“未采纳”的内容，应先核对其业务含义。确认无误后，可以批量采纳，也可以修改后逐项采纳。只有已采纳的内容会被 DataAgent 使用。
第二步：创建游戏业务模型
创建业务模型（Context Model），并关联 Project semantic-game-demo 对应的事实模型。建议在描述信息中说明模型覆盖的业务范围和主要用途，例如充值、道具、排位和反作弊等客服场景。
关联完成后，事实模型中已采纳的字段语义、指标和术语会同步到业务模型。还可以根据实际业务补充专有术语、指标口径和常用示例。示例中可以包含问题描述、查询语句及相关字段。
第三步：创建游戏客服 DataAgent
创建 DataAgent，并绑定刚才创建的业务模型。
DataAgent 运行时需要使用独立的 RAM 角色。默认可使用系统角色 aliyunslsdataagentrole；如果尚未完成授权，请先通过授权链接完成操作。如需限定可访问的资源，可以改用自定义角色；此时操作者需具备对应的 ram:PassRole 权限。
第四步：使用典型客诉进行对话测试
新建对话并选择刚创建的 DataAgent，然后输入玩家投诉原文。DataAgent 会结合业务模型识别业务术语和指标口径，查询相关日志，并输出关键证据、分析结论和客服答复草稿。
效果示例：从一句投诉到可核对结论
以下测试基于可复现的模拟日志，共覆盖 13 类客诉场景。
评测隔离说明：
game-qa-logstore只用于保存问题、标准答案和评测证据，不属于业务查询数据源。盲测时不应向 DataAgent 授予该 Logstore 的查询权限，以免泄漏标准答案。
以“充值未到账”为例，DataAgent 会依次完成三步排查：
- 确认支付：支付回调成功，签名验证通过。
- 检查发货：发货失败，且已重试 3 次。
- 定位原因：结合系统错误与背包容量，确认背包已满。
最终结论由支付、发货和系统日志共同支撑，而不是根据单个错误码直接推断。
除上述充值场景外，下表再列出三个典型案例，展示内容仅作示意：
| 玩家问题 | DataAgent 串联的关键证据 | 输出结论 |
| 道具消失 裂天刃 WPN_LEG_001 |
通过 item_uuid 串联背包流水与交易记录；登录设备正常，无异地登录；change_reason = trade_sell，成交价 64,663 金币 |
从现有日志看，该道具通过当前账号在交易行售出，暂未发现异地登录或异常设备操作证据。建议提供交易记录并提示玩家检查账号安全 |
| 赢了扣分 对局 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 的高置信标准；内存扫描结果为 clean；Ping 为 180～250 ms |
现有证据更支持高延迟导致的移速计算偏差，建议转交反作弊团队进行人工复核 |
当一个问题可能对应多个业务口径时，例如“收入”可能指订单面额、实付金额或已发货金额，DataAgent 可以先向提问者确认所需口径，再继续查询。若希望减少此类澄清，可在业务模型中补充更精确的术语、指标描述和示例。
让 DataAgent 答得更准的三个建议
- 从高频、高价值场景开始。 优先沉淀充值未到账、重复扣款等问题，更容易建立可验证的效果基线。
- 先校准口径，再追求覆盖率。 重点确认金额单位、状态枚举、时间字段、唯一标识和指标计算式。
- 把人工复核写进流程。 为退款、补发、封禁和解封等操作设置明确边界，DataAgent 输出证据和建议，由人审核后执行。
使用限制
| 项 | 限制 |
| 中心化服务（业务模型、DataAgent） | 仅支持 cn-beijing 中心地域 |
| 事实模型 | 按 Region 部署，支持 cn-beijing、cn-shanghai、cn-hangzhou、cn-chengdu、cn-heyuan |
| 业务模型 / DataAgent 数量 | 单账号 / 单用户默认各 50 个，可申请调整 |
上述限制请以最新产品文档和控制台为准。
结语：让数据从“少数人会查”走向“更多人可用”
游戏客服只是一个切入口。类似的数据查询需求，还广泛存在于业务运营、售后服务、故障排查、风控审计、安全分析和设备运维等场景。
真正隐藏的是业务语义
数据已经写入 SLS，但理解数据所需的知识，往往散落在不同地方：
- 字段含义藏在程序代码里；
- 状态解释写在零散文档里；
- 指标口径存在于业务人员脑中；
- 查询路径依赖少数专家的经验。
因此，查询的门槛从来不只是 SQL。新人需要反复请教，业务人员需要依赖研发，AI 也可能因为不了解真实口径而得到错误结论。
改变的不是一条 SQL，而是数据使用方式
| 过去 | 使用 SLS 语义层与 DataAgent 后 |
| 人先学习字段和日志结构 | 系统提供明确的业务语义 |
| 查询依赖个人经验 | 字段、术语、指标和示例可复用 |
| 业务问题需要研发协助 | 使用者可以用自然语言发起查询 |
| 结果依赖人工拼接判断 | DataAgent 串联证据并给出可核对结论 |
通过事实模型与业务模型，原本隐含在程序和人脑中的知识被沉淀到语义层；DataAgent 再利用这些语义理解问题、选择数据源、执行查询并组织证据。数据查询由此从“人适应日志”转向“系统理解业务”。
从一个高频问题开始
落地不必追求一步到位，可以先建立一个最小闭环：
- 选择问题：找出团队每天都在重复回答的高频问题。
- 沉淀语义：选定相关 Logstore，确认字段、术语和指标口径。
- 验证闭环：补充典型问法与查询示例，让 DataAgent 完成从提问到结论的全过程。
- 逐步扩展：验证有效后，再覆盖更多问题、Project 和业务角色。
每沉淀一个字段含义、一个指标口径或一条查询路径，都是在把个人经验转化为组织可复用的数据资产。随着这些知识持续进入语义层，客服可以直接追查客诉，运营可以自助分析异常，安全和运维人员可以更快定位问题，研发团队也能减少重复的数据解释工作。
从一个“过去只有熟悉日志的人才能回答”的问题开始，让更多人真正用起数据。
