测试之家

游戏测试 开源一个游戏协议抓包平台-GameTrace

ownSecurityGuard · 2026年09月26日 · 25 次阅读

开源一个游戏协议抓包平台：把游戏流量变成可查询的调试证据

仓库：https://github.com/OwnSecurityGuard/gametrace
（创作不易，给颗 star 当作鼓励，skr~）
各位对平台或者这类功能有什么见解可以在讨论区一起讨论一波~~

GameTrace 抓实时或回放的游戏流量，用独立的解码插件把报文还原成结构化协议事件，再投影成请求/响应配对、服务端推送、协议错误、字段级状态变更。人在 Web 面板上看这份 trace，自动化脚本和 AI Agent 通过 MCP 查同一份 trace。

与其说它是「抓包平台」，不如说想成为游戏网络的调试证据层——重点不是存了多少 pcap，而是这条链路：

packet → 协议事件 → 请求/响应配对 → 状态变更 → trace → Agent 查询

GameTrace 协议事件视图：请求/响应成对、协议错误、服务端推送与状态变更标记

图：「协议事件」视图——请求与响应成对、协议错误带原因、服务端推送，以及每条事件引发的状态变更。

GameTrace 协议事件视图：状态变更标记

它能拿来干什么

  • 给测试自动化 / 压测喂真实协议数据。 不必每次重新抓包 + 手工分析 + 提取字段，解码后的结构化事件可以直接当数据源；GameTrace 不做压测引擎，压测工具保持独立。
  • QA 报问题时留下完整网络证据。 QA 照常玩，后台同时记录 request / response / push / protocol error / state change / 规则命中。UI 上同一句「装备属性没变化」，在网络 trace 里可能是完全不同的四个原因：UI 没刷新、客户端没收到、收到了没应用、服务端根本没发。
  • 让异常检测从「经验」变成规则。 例如 QA 在进行功能测试的过程中,服务端返回了错误，如果客户端没有相应的表现,那么可能就遗漏了,现在项目可以带一组检查规则：一个 GJSON path + 一个 op（eq/neq/exists/not_exists/gt/in/contains/prefix…），在每条解码事件上实时求值，命中就写进会话的「命中提醒」并弹桌面通知。检查发生在抓包过程中，而不是事后翻报告,同时会协带了客户端发了什么请求，以确保能快速定位问题
  • 更适合 AI Agent。 数据一旦从 packet 变成 protocol event / request-response / push / state change，Agent 就不需要吞几百兆 pcap，只需要查询已经结构化的 trace：
这个 session 里有哪些协议？ → login 相关请求 → 它的 response 是什么？
→ 之后发生了哪些 state change？ → 为什么 Player:1001 的 hp 从 100 变成了 65？

协议接入：平台提供了写解码插件的 Skill

这是我比较想强调的一点：新协议接入不是「自己啃文档」的过程，平台自带 Skill。

  • skills/decoder-plugin-guide —— 指引用户或 AI Agent 用 Go 编写解码插件（gt.decoder/v2，基于 gametrace/sdk）：协议分析、必想的处理链路、Event 字段与持久化声明、插件骨架、TCP 重组与握手、plugin.yaml、解码诊断指标、单测与验证，并附一条 Agent 执行工作流（scaffold → connect → test → verify 的工具时序）。
  • skills/protocol-lineage-analysis —— 协议血缘分析，从规则反查能力。
  • 两个 Skill 都能通过 MCP 的 read_skill 直接读取（也注册为 MCP resource），配合现成模板 examples/http-decoder、examples/ws-decoder、examples/lp-decoder，Agent 可以自己走完「发现未知协议 → 生成插件 → 本机构建运行 → 接入 → 验证」。

插件形态是一个 Go 二进制 + 一个 plugin.yaml，作为独立 gRPC 进程运行：可热加载、可热替换，与管线崩溃隔离。而且插件源码、二进制和进程都在你自己的机器上——平台不保存源码、不编译、也不拉起插件。

Agent 应该操作证据，而不是重建一套流程

GameTrace 把抓包、查询、插件开发都通过 MCP 暴露，且和人看到的是同一份证据：

get_capabilities / read_skill                     发现能力
start_capture / get_session_status                抓包与状态
sample_bytes_plugin / get_protocol_catalog        观察流量、确认协议形态
list_decoded_data / list_connections              查结构化事件与连接
list_state_changes / list_session_alerts          追状态变更与规则命中
scaffold_plugin / connect_plugin / test_plugin / verify_plugin   写插件、接入、验证

Agent 应该操作 GameTrace 的证据，而不是自己重新发明一套抓包、解析和分析流程。

否则最后会变成「平台 + Agent 自己的抓包脚本 + Agent 自己的 parser + Agent 自己的数据格式」，平台反而没有意义。所以 GameTrace 更希望成为 Agent 的网络调试工作台。

后续计划

游戏接口自动化测试平台（重点方向）

现在 GameTrace 解决的是「看得见」——真实流量变成结构化协议事件。下一步想解决「测得动」：把同一条 trace 变成可以直接复用的测试资产，让它从观测层长成一个游戏接口自动化测试平台。

一次真实抓包
   ↓
请求模板 + 断言基线            （从 session 里的 request / response 提取）
   ↓
Agent 生成接口用例             （字段级断言：状态变更的 before / after 天然就是断言点）
   ↓
回归执行 → 响应差异比对
   ↓
失败时直接回落到网络证据        （哪一帧不对、上一帧是什么、对应的请求是谁）

这里想守住的一条边界是：GameTrace 不重造通用执行引擎，而是让协议语义、用例、断言和证据都落在同一份 trace 上，执行可以继续跑在你现有的测试框架里。

其他

  • 会话时间线与回放视图——在已有的抓包 / 会话 / 连接 / 协议事件 / 插件之上，补一等的 timeline 与 replay。
  • 回放与压测脚本生成——由 Agent 从会话 trace 生成回放、负载脚本（Scenario → Replay）。
  • 英文文档与界面——Web UI 目前只有中文。

如果你也在做游戏测试、协议分析或 Agent 工程，欢迎来看看，顺手给颗 star：

https://github.com/OwnSecurityGuard/gametrace（MIT License）

「原创声明：保留所有权利，禁止转载」
暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册。