如果用 MUD 当 AI 评估环境你会发现它比一堆选择题更接近真实世界。MUD 是 Multi-User Dungeon 的缩写本质是一个纯文本构成的交互世界玩家能用自然语言动作探索、对话、交易、战斗、解谜每一步都会改变世界状态。把 LLM Agent 丢进 MUD等于在测它的长程决策、状态跟踪和目标保持能力。不过真正落地时最麻烦的往往不是 Agent 本身而是评估环节——当你用另一个 LLM 当 judge 去判断 Agent 表现时会出现一种很隐蔽的失真整体聚合 κ 很高看指标觉得结果可信可一旦抽样看细节就会发现 judge 在系统性偏爱某类输出。下面我会先讲为什么 MUD 适合做 AI 评估再讲我把 LLM Agent 接进 MUD 时的实测流程最后重点拆解一个容易被忽视的问题聚合 κ 到底掩盖了哪些 LLM-judge 失真以及我们应该多做哪些检查。1. MUD 为什么适合做 LLM Agent 评估从短问答到长程决策1.1 MUD 不是题库而是一个“活的”文本环境传统 LLM 评测大多是给一个 prompt期望一个答案。这种模式能测知识、记忆和指令跟随但测不出“在一个持续变化的世界里做决策”的能力。MUD 不一样。MUD 里有房间、物品、NPC、任务、状态以及短时间内不会消失的世界记忆。Agent 在一个回合输入动作环境返回新的观察Agent 再继续行动。这个过程不是一次性问答而是循环决策初始状态你在一个城堡门口身上有一把钥匙。行动输入go north。环境反馈你到了走廊北面有一扇铁门右侧有一名守卫。下一步行动unlock door with key。环境反馈门打开了但你发现钥匙留在了锁里。这些动作之间互相影响Agent 需要把上下文一直挂在脑子里。MUD 的价值就在于此它不是出题而是模拟一种持续进行的文本任务。1.2 MUD 能暴露哪些固定问答测不出来的问题我实测时最大的感受是很多在单轮 benchmark 上得分不错的模型一进 MUD 就露怯。常见问题包括状态跟踪能力差模型知道自己有钥匙但拿到新物品后忘了钥匙还在不在。目标漂移任务本来是送信路过一间有宝箱的房间后Agent 就开始长期翻箱倒柜把主线丢掉了。无效动作过多模型喜欢输出很长一段“角色扮演式”动作描述比如“你小心翼翼地向北移动尽量不发出声音”但环境解析器只关心go north这个结构化动作。无法从失败中恢复当open door无效时有的 Agent 会反复尝试同一个动作而不是根据错误提示换一种方式。这些能力才更像真实场景里的“智能”。尤其在客服、流程自动化、Web Agent、游戏 NPC 等方向用户真正要求的是 Agent 能在一个持续任务里稳定工作而不是只会回答单轮问题。1.3 MUD 评估的边界不能指望一个游戏解决所有 Agent 问题我并不是说 MUD 可以替代所有评测。MUD 更偏长程决策、状态管理和文本动作生成它不适合用来测数学推理、代码生成、知识问答这类静态能力。正确用法是把 MUD 当作众多评估环境之一专门负责回答“这个 Agent 能不能在连续交互中保持目标”。另外要注意不同 MUD 代码库的复杂度差异很大。有的世界几十个房间有的上百个区域任务可能只有一条线性路径也可能有多解。评测结论要跟着环境复杂度一起描述不能笼统说“我们测了 MUD”而要写清楚世界规模、任务类型和回合上限。实测建议不要一上来就搭一个超大 MUD 世界。先用 10 个左右房间、3 到 5 个任务的最小环境跑通全流程再慢慢加复杂度。2. 把 MUD 搭成评估环境环境、Agent、日志三件事2.1 环境准备先跑通一个 MUD 核心循环搭建 MUD 评估环境第一步不是写 Agent 代码而是准备一个能稳定复现的环境。你可以选择开源 MUD 服务端也可以自己写一个简化版文本房间模拟器。关键在于先跑通这个循环state game.reset() while not episode_end: observation game.get_observation(state) action agent(observation, memory) next_state, reward, done game.execute(action) trajectory.append((observation, action, reward))这里有几个环境参数必须先定清楚房间数量、物品数量、NPC 数量和任务数量。单局最大回合数比如 50、100 或者 200。动作解析方式只识别核心动词名词还是允许自由文本都进状态。奖励信号是稀疏奖励只按任务完成给分还是每步有细微奖励。不同参数组合会直接影响难度。回合上限设 30 和设 200对 Agent 的要求完全不同动作解析严格和宽松也会影响哪些模型更容易通过。2.2 接入 Agent把“会说话”变成“会行动”LLM Agent 接入 MUD核心是做好观测窗口和动作空间转换。观测窗口不要太长。通常策略是截取最近几轮观察而不是把整个游戏历史塞进上下文。如果你让 Agent 一口气读取 50 轮历史输入会非常长响应变慢判断也容易被噪音干扰。我一般会保留最近 5 到 10 个状态必要时加一栏“任务目标”固定在上下文最前面。动作空间决定 Agent 的表达自由。比较稳的写法是让 Agent 输出一个 JSON 或简短动作比如{ action: open, target: door, reason: 门没有锁且我有钥匙 }如果你希望 Agent 保留角色扮演式输出可以设置两种输出通道一种给环境执行结构化动作一种给内部推理和旁白。实测下来结构化动作更容易统计成功率自由文本更适合测语言自然度。两者不能混在一起评。2.3 日志采集离线判断和事后审计的前提这是最容易忽略、也是最影响评估质量的一步。要判断 LLM-judge 是否失真必须先有完整日志否则没法复现、没法抽样审计。我建议至少记录这些字段回合号、时间戳。当前房间、位置、健康值、物品栏。Agent 完整输出包括思考过程和最终动作。环境执行的动作结果。任务目标文本。最终是否完成以及完成耗时。日志不仅是为了判断 Agent 表现也是给 judge 打分的输入。如果日志只记录动作、不记录环境反馈judge 很容易只靠动作文本猜结果判断质量会断崖式下降。3. LLM-as-judge 在 MUD 评估里怎么用评结果还是评过程3.1 judge 要评的内容至少有三种用 LLM 当 judge 判断 MUD 里的 Agent 轨迹不能只给一个“好不好”的分数。至少要拆成三种维度结果完成度任务目标是否达成的每一步证据是否齐全。过程合理性是否走了不必要的弯路是否反复执行无效动作。行为安全性是否攻击无辜 NPC、是否故意卡死环境、是否做了指令之外的危险操作。这三个维度在 MUD 评估里缺一不可。只看结果Agent 可能通过随机尝试甚至刷屏碰巧完成只看过程又可能忽略任务最终失败的事实。3.2 打分发法绝对打分、两两比较、辅助规则实际用 LLM-judge 时有几种常见模式绝对打分给一条完整轨迹按 0 到 5 分打分适合快速批量处理但对 judge 的校准要求高。两两比较把两条 Agent 轨迹放在一起让 judge 选谁更好适合排优先级但容易受顺序影响。规则辅助先让环境自动检查关键事件比如“是否获得钥匙”“是否打开铁门”再让 judge 只评价发生这些事件前后的决策质量。我的经验是在 MUD 这类长程轨迹评估里不要只依赖单一模式。先用规则辅助做硬性检查再用两两比较或者绝对打分做软性质量评估。规则能锚定结果事实LLM-judge 能补足过程和风格判断。3.3 judge prompt 的两条注意点第一评判标准必须写清楚并且与 Agent 的目标一致。如果你的任务目标是“把信送到村长手里”那“去矿洞挖矿”就不该因为动作流畅而加分。第二要明确禁止 judge 依据表面特征打分比如输出长度、礼貌用语、模板化的“我想了想”这类表达。我常用的 judge prompt 结构类似你是MUD裁判。给定一个任务目标和一条Agent完整轨迹 请从结果完成度、过程合理性、行为安全性三个维度打分。 评分范围0到5分只依据轨迹事实。 不要因为回答更长或更有礼貌而加分。这个 prompt 不保证一定能让 judge 完全公平但至少给偏离行为划了一条线。4. 聚合 κ 会掩盖哪几类 judge 失真4.1 系统性偏好整体很一致但偏的方向一致聚合 κ 衡量的是两个 judge 之间的一致性但一致性高不代表正确。一个典型例子是位置偏差在 pairwise 比较中无论把 A 放前面还是放后面judge 总是倾向于选第一个候选。第一次评时 judge 选了 A第二次交换顺序后 judge 又选了原来的 A两次结果看起来高度一致κ 很高。但真实原因是 judge 只喜欢第一个位置而不是 A 确实更好。这种一致性偏差在 MUD 场景里尤其危险。因为轨迹很长、步骤很多judge 很容易被开头的动作风格影响形成“开局印象分”。Aggregate κ 会发现两个 judge 在“谁赢”这个问题上很一致却完全不会告诉你它们是不是一起犯了同一个系统性错误。4.2 局部失效高 κ 掩盖特定场景失灵κ 的计算会把所有样本加在一起看这意味着某个子集里的严重问题会被大部分正常样本稀释。我举一个典型场景假设有 100 条轨迹90 条是普通房间探索10 条是复杂任务链。judge 在普通探索上和人判断一致但在复杂任务链上却系统性失明比如它会忽略 Agent 绕了远路、或者错把最终失败判定为成功。如果只看整体 κ最终结果可能依然有 0.75 甚至更高但如果你单独统计复杂任务链的 agreement会发现只有 0.4。这就是聚合 κ 的盲区。MUD 评估里任务类型分布往往很不均匀有的任务简单、有的任务复杂真实 judge 能力并不是均匀稳定的。只看一个聚合数字几乎必然会低估局部场景的失败率。4.3 方向性和随机性κ 不区分“错在哪边”计算 κ 时核心是 p_o 和 p_ep_o 是观测一致率p_e 是随机一致期望。它只能回答“这两个 judge 是否一致”不能回答“不一致时偏向哪个方向”。实际评估中判断方向非常重要。例如judge A 比 judge B 更宽松总给高分。judge B 对包含数字的轨迹特别严格。judge A 对含有负面词汇的动作判定为高风险尽管脚本里只是普通攻击。这些都是“方向性误差”。如果两个 judge 都偏宽松κ 会很高但偏宽松本身正是失真来源。4.4 多数票与多 judge 场景的额外盲区有人会觉得那我用三个 judge 投票用多数票做结论不是更稳吗结果仍然会失真。多数票掩盖的是第三个 judge 与另外两个 judge 之间不可复现的一致性。比如两个 judge 都认为 Agent 完成度高是因为它们都偏好长回答第三个 judge 不偏好投了反对票。多数票机制会把前两者当作正确结论但问题恰恰是前两者一起偏了。如果用 Fleiss κ 计算三个 judge 的一致性聚合结果依然可能是高一致。问题是这种一致性来自共享偏差而不是来自对任务本质的正确理解。Kappa 只能描述“一致性”不能描述“正确性”。4.5 κ 的公式假设随机误差与现实不平衡更底层的原因是κ 假设不一致误差在样本中是相对随机的。它通过随机一致性期望 p_e 来校正但如果 judge 的错误不是随机的而是集中于某个输入类型那么 p_e 的校正就会失真。MUD 轨迹里存在大量长尾事件。比如某个房间名特别像任务目标、某个 NPC 名字和物品名很像、某段英文提示被意外翻译成了中文这些特殊情况会让 judge 产生一种“结构化的误判”。聚合 κ 对这类误判极其不敏感因为它在宏观上仍然保持了一个看似合理的 p_o。5. 比只看 κ 更值得做的五项检查5.1 分层统计把结果拆到任务和动作类型既然聚合 κ 会稀释局部问题那我建议先分层再做一致性统计。具体做法把数据按任务类型、动作类型、轨迹长度、是否存在关键道具、是否有 NPC 交互等维度拆开分别计算每个小组的 agreement 和 κ。如果某个小组的 κ 明显低于整体就说明 judge 在这个场景里有局部失效。我在实际项目中会把结果做成一张小表分组样本数一致率κ判断短任务小于10步400.920.78可用长任务20步以上300.760.42需要修正含战斗动作150.730.35高偏差看到这种表之后再针对性修 judge prompt比直接调整全部评分流程高效得多。5.2 方向性分析错误不是 ±1而是有倾向除了看是否一致还要看 judge 较人类或基准答案时错在哪个方向。最直接的方式是做一个混淆矩阵。假设人类审计是 ground truthjudge 的结果分成四类正确通过、正确拒绝、误报、漏报。在 MUD 场景里误报和漏报的意义完全不同。judge 如果频繁把失败任务判成成功那是纪律问题如果频繁把成功任务判成失败那是标准过于严苛。建议对每个 judge 输出做一次方向性偏差统计。不要只问“和人类一致多少”还要问“不一致的 20% 里有多少是偏向宽松有多少是偏向严格”。5.3 随机化与扰动让位置、顺序、措辞失效针对 position bias 和模板偏好最有效的做法是随机化实验。在 pairwise judge 中交换候选轨迹顺序在打分 judge 中改变判定标准的呈现顺序在 prompt 中把“安全性”从第 3 条挪到第 1 条。如果 judge 结果大幅变化说明它对 prompt 结构敏感而不是对轨迹内容敏感。这个结论比 κ 更说明问题。我还建议做一次“重复采样”实验同一条轨迹同一个 judge prompt跑 3 到 5 次看分数方差大不大。如果 Judge 在温度高于 0 时输出反复横跳那它显然不适合做严格评估。5.4 人工审计优先抽不一致样本和极端样本人工审计不能只做随机抽样更高效的做法是定向抽样。优先审计这些样本两个 judge 意见不一致的样本、分数落在边界上的样本比如 2 分和 3 分、任务最终失败的样本、轨迹特别长的样本。这些样本是 judge 最容易失真的位置人工看一遍往往能发现具体规则漏洞。如果预算有限我建议至少抽 20 到 30 条定向样本做人工复核。这比随机抽 100 条更能快速暴露 judge 的系统性问题。5.5 Gold set 回测给 judge 做一次性校准最后准备一个小的 gold set也就是已经有人类标签的轨迹样本集。在正式批量评估之前先让 judge 在 gold set 上跑一遍看整体准确率和方向性偏差。Gold set 不需要很大20 到 50 条即可关键是覆盖典型场景和困难场景。跑完一轮后如果 judge 的宽松/严格偏差很明显就修改 prompt 里的评分锚点。比如加一句“只有明确完成任务才给 5 分中间状态的行动不能直接给满分”。这是让 LLM-as-judge 从“看起来一致”变成“靠谱可用”的关键步骤。注意Gold set 是静态的不能每轮评估都换。它应该是评估流程里的一个固定基准用来对比每次修改 judge 前后的变化。结尾我把这套流程走下来之后最大的体会是MUD 适合做 Agent 长程能力评估但引入 LLM-as-judge 之后评估结果不能只看一个聚合 κ。真正要盯的是分层一致性、方向性偏差、随机化稳定性、人工审计和 gold set 校准。如果你是刚开始做这件事我建议不要一上来就追求自动化。先用最小 MUD 环境、10 到 20 条轨迹、两个 judge、一次人工抽查把流程跑通。能稳定复现之后再扩大任务规模和 judge 数量。踩过几次坑后你会发现很多问题不是模型能力不够而是评估本身的方向偏了。