网易雷火游戏服务端二面：Agent Harness 与网络模型

《面试题目》

1. 请自我介绍；之前两个月是否在实习、现在是否离职？
2. 怎样考虑游戏行业和游戏服务端岗位？平时玩什么游戏，网游多吗？
3. 选一到两个最能代表能力的项目；Agent SDK/Harness 做什么、个人负责什么？
4. 输入 Token 的降幅是怎么算出来的？这能说明 Agent 效果提升吗？
5. 是否有评测集？怎样标注、回放和比较不同模型？你本人负责吗？
6. 上下文方案最大的实现难点是什么？参考 Claude Code 后做了什么定制？
7. 这套 Harness 的应用场景和产品定位是什么，内部还是外部使用？
8. 平时主要使用什么语言？C++ 和 Linux 熟悉吗？
9. Linux 进程崩溃后怎样定位？如何用 GDB 查看所有线程和某个线程的调用栈？
10. 平时使用哪些 AI 工具？拿到大型陌生代码库时怎样分析？
11. 常用哪些模型，不同模型有什么体感差异？
12. 大代码库的目录、模块和调用关系怎样沉淀？个人 Memory 会不会撑爆？多人项目怎么办？
13. 普通互联网后端与王者荣耀类游戏服务端有什么区别？
14. 王者荣耀类实时游戏更适合 UDP 还是 TCP？
15. UDP 怎样保证不可丢数据？QUIC 如何可靠，为什么不直接用 TCP？
16. 内网不丢包且已经建立长连接时，UDP 相比 TCP 还有什么优势？
17. 怪物 50 点血，每次造成 1 或 2 点伤害，恰好击杀有多少种攻击序列？
18. 若剩 1 点血时用 2 点伤害也算击杀，怎样修改 DP？为什么只改边界就正确？

《参考解析》

Token 降幅怎么算才有说服力：不能只说”降了百分之多少”，要交代口径——统计的是什么（输入 token 总量还是单次请求均值）、样本是什么（同一批任务、同样步数）、对照是什么（同一模型、同一任务集在改动前后的对比）。更要命的是”Token 降了不等于效果好了”：可能只是压缩过度导致关键信息丢失、任务成功率反而下降。所以必须把 token 成本与任务成功率、人工接管率放一起报告，才能说明是”更省且不更差”。

上下文方案的最大难点与定制：难点通常集中在”压缩与召回的矛盾”——压得越狠越省 token，但越容易丢掉后续步骤真正需要的细节。参考 Claude Code 后常见的定制是：保留原文可回查的指针（压缩只作用于送入模型的上下文，原文落库并可按 ID 拉回）、按工具结果类型分别制定压缩规则（代码/日志/JSON 各有不同的截断方式）、以及把不变的稳定前缀固定下来以命中 Prefix Cache。

GDB 定位崩溃与线程栈：先看 core dump（ulimit -c unlimited 后 gdb <bin> <core>）或直接 attach（gdb -p <pid>）。看所有线程用 info threads，切到某个线程用 thread <n>，打印调用栈用 bt（加 full 看局部变量）。定位崩溃点用 bt 最上层帧 + frame/info locals；常见原因是空指针解引用、越界写、栈溢出（bt 会显示很深的递归）。生产上还可以先看 dmesg 里的 segfault 日志拿到出错地址和指令指针。

游戏服务端 vs 互联网后端：关键差异在实时性、状态驻留和广播。互联网后端多为无状态、请求-响应、可水平扩容、接受百毫秒级延迟；游戏服务端是长连接、有状态（房间/战斗状态常驻内存）、要求几十毫秒内的帧同步、且要频繁向一群玩家广播状态。另外游戏服要处理”确定性”（相同输入产生相同结果，便于回放与反作弊）、帧同步/状态同步的选型，以及大量短生命周期对象的分配压力（对象池）。

UDP 还是 TCP：实时竞技类通常选 UDP。原因是 TCP 的重传与队头阻塞会惩罚实时性——一个丢包会让整条有序流卡住，等它重传完，新产生的状态早已过期，游戏里表现为”所有人都卡一下”。UDP 允许应用层自己决定”哪些数据必须可靠（关键事件）、哪些丢了就丢（位置更新，下一帧的新包会覆盖），以及过期的包不再重传”。QUIC 在 UDP 之上实现了可靠传输、拥塞控制、多路复用和 0-RTT，好处是没有 TCP 的队头阻塞、连接迁移友好（切网不断线）、握手更快；但它本质仍是可靠有序的流，对”丢掉过期状态包”这种需求并不比 TCP 更合适，所以游戏常用自研的轻量可靠层而不是直接上 QUIC。内网不丢包时 UDP 的优势还有：无连接所以无握手与状态维护开销、不需要拥塞控制与 ACK 回传、头部更小（8 字节 vs 20 字节起）、且天然支持一对多广播/组播。