i-member: τ-bench 思想下多智能体工作流评测实践（Multi-Agent Evaluation Practice）

i-member 是一个基于 LangGraph 构建的品牌智能导购系统。9 个 Agent 协同工作，支撑起工单、推荐、咨询三大子图。

在一个典型的退货场景中，从“我要退货”到工单闭环，背后经过了意图路由、技能匹配、步骤规划、ReAct 工具调用及动态追问。每一轮对话路径都由 LLM 即时决策，这种灵活给系统带来了不可预测的非确定性。

面对这种不确定性，如何构建一套可回归、可量化的评测体系？本文将分享我在 i-member 项目中的踩坑经验、技术选择以及分层评测的阶段性答案。

1. 系统总览

2. Agent eval 核心痛点

Agent 系统的测评难点不在于固定逻辑，而在于那些无法被预设的动态交互。针对 i-member 的多 Agent 协作特性，我总结了以下核心痛点：

2.1 对话路径的非确定性

对于工单服务这类任务，模型需要通过追问和交互补全信息。Agent 每轮“问什么”、“怎么问”，完全取决于 LLM 的即时推理，无法通过预设的固定 Case 来覆盖所有可能的对话分支。

2.2 模拟器侧的熵增（不可控性）

在端到端（E2E）评测中，用户模拟器的表现直接影响结果。模拟用户可能配合、可能词不达意、也可能随时改主意。这种用户行为的随机性，导致测评环境的熵值极高，穷举所有组合几乎是不可能的。

2.3 行为正确性 vs. 回复质量

引用 Anthropic 在 Demystifying evals for AI agents 中的观点：Code-based Graders（基于代码的判定）  擅长回溯 Tool Call 和数据准确性，但无法判定话术的同理心和是否编造数据。这需要引入 Model-based Graders（基于模型的裁判） ，但裁判模型本身也存在推理成本和不确定性，需要精细的 Trade-off。

2.4 LLM 裁判的可靠性波动

同一个场景跑两次，可能一次过一次挂。Pass^n（多次通过）虽然能提升可靠性，但会带来翻倍的评测成本。如何用可接受的成本换取可信的结果，是工程化落地的一大挑战。

3. i-member 评测目标

本次构建评测体系的核心驱动力在于：

• 确保改动可回归：任何 Prompt 或模型的调整，不应导致已知场景的退化。
• 确保中间链路稳定：核心工具调用（Tool Call）及其参数提取必须 100% 正确。
• 确保对话体验：话术流畅、语气合理，且能在恰当时机主动推送交互卡片。
• 抗干扰能力：在非预期或复杂的交互场景下，系统不脱缰、不编造。
• 高置信度判定：确保核心场景的通过率指标具有统计学意义。

4. τ-bench 思想：以“状态变化”为核心

在评测框架的选择上，深度借鉴了 τ-bench 的核心理念。τ-bench 的高明之处在于它跳出了“话术比对”的泥潭：

1. 场景模型化：将一次对话抽象为“人设 + 目标 + 终态”。
2. 交互协议化：建立固定的 Simulator ↔ Agent 循环，直到任务触发“终态信号”。
3. 环境终态作为真理（Ground Truth） ：不看 Agent 说了什么，而是看数据库（Mock SCRM）的状态变化。工单是否创建成功、字段是否与用户诉求一致。

5. 三层金字塔：分层治理策略

基于“成本、速度、精度”的权衡，i-member 最终采用了三层递进的评测结构：

以 “能用代码断言的，绝不交给模型”  原则，将任务进行解耦：

测评维度	场景	裁判类型 (Grader)	通过标准	核心目标
单元测试	纯逻辑函数（非 LLM）	code-based	100%	确保底层原子函数稳健
Agent 单测	单个 Agent 内部逻辑	code-based	1/1 (一次性通过)	验证工具调用、状态机转换、槽位提取
全链路 E2E	完整对话（模拟器/Case）	model-based + 人工	加权评分 ≥3.0	评估对话质量、交互时机、无幻觉编造

6. 具体实现：如何让评测自动化？

6.1 Runner 设计：Case 是数据，不是代码

在 i-member 中，没有为每个场景写 test_xxx()。而是实现了一套 Harness，实现了 Case 与 Runner 的解耦。

新 Case 只需增加一个 JSON 文件：

{
  "case_id": "ticket_003",
  "agent": "ticket_executor",
  "scenario": "用户想要退货，订单号 12345，理由是尺码不合",
  "setup": {
    "mock_db": { "order_status": "delivered" },
    "existing_slots": {}
  },
  "reference": "订单12345已签收，符合退货政策", // 关键：给 Grader 的真理
  "expect": {
    "intent": "create_refund",
    "required_slots": ["order_id", "reason"]
  }
}

6.2 CodeGrader：守住逻辑底线

在底层针对不同 Agent 编写了专门的判定方法，只做确定性检查：

• Router: 验证 intent 是否准确命中。
• Guard: 验证 guard_decision 是否拦截了违规请求。
• Planner: 验证 steps 规划是否包含必要工具，且在白名单内。
• Executor: 验证 slots 槽位提取的准确性。
• QA/RAG: 验证工具调用链中是否召回了预期的知识片段。

6.3 ModelGrader：加权评分体系

对于“好不好”这种主观维度，采用一套 Rubric 提示词，让裁判模型输出三维评分：

Total Score = Correctness(0.5) + Groundedness(0.35) + Card_Usage(0.15)

• Correctness: 对话质量如何？是否正确回答用户问题、满足用户需求？
• Groundedness: 所有的陈述是否都有工具返回或 Reference 作为支撑？
• Card_Usage: 交互卡片、商品卡片是否在最恰当的时机弹出？

7. 真实测评数据 (i-member v1)

以下是第一版测试 case 全量跑批的结果，E2E 场景涵盖用户配合、用户不配合、用户答错、商品推荐锚点依赖等场景。通过这份数据可以清晰看到：越是灵活的链路，稳定性挑战越大。

测试套件	Case 数量	均分/结果	状态	结论
单元测试	6 模块	100% Pass	✅	基础函数极稳
Agent 单测	37 Case	100% Pass	✅	原子能力已过关
E2E Ticket	6 Case	3.15 - 5.00	⚠️	多轮对话存在微小波动
E2E Recommend	4 Case	3.25 - 4.00	⚠️	推荐理由的 groundedness 待加强
E2E Error Handling	2 Case	Pass	✅	边界防御正常

目前，大部分 E2E Case 仍存放在 capability（能力测试）中。进入回归的标准是：只有连续 5 次跑批均分 > 4.0 的 Case 才能进入 regression（回归库）加入 CI 门禁。

8. 落地踩坑

8.1 模拟器“告别循环”

现象：第一版模拟器在任务完成后，会不停跟 Agent 说“谢谢”、“再见”、“你真棒”，而 Agent 也会礼貌回复。对话能跑 15 轮还不结束。 解法：在 scenario 中增加任务结束的判断标准，并增加 should_end 字段，让模拟器判断是否可以结束任务。并使用 with_structured_output(SimulatorOutput) 强制 LLM 输出 Pydantic Schema：

class SimulatorOutput(BaseModel):
    message: str
    should_end: bool # 核心：强制模型判定是否该闭环

结果：对话在 3-7 轮内精准结束，评测效率提升 200%。

8.2 裁判模型的“主观偏见”

现象：在退货测试中，Agent 查询到订单未收获，裁判模型凭“常识”认为“没收到货怎么退货？”，判了低分。

解法：引入 Reference 字段，Grader 评分时以 Reference 为事实判断依据。

8.3 模拟器的“幻觉”

现象：模拟器会编造数据，比如订单里是“鞋子”，它非要退“蓝色风扇”。

解决方案：

1. Harness 结构化下发：给模拟器的 Context 只包含 {reply, card, products} 的关键 Key。
2. 约束 Prompt：除非是 scenario 的特意设计，模拟器“必须基于当前卡片和商品真实数据进行交互”。
3. 上下文压缩：使用 _compact_interaction 只喂核心 label，防止全量长文本干扰模型判断。

9. Case 生命周期管理

为了平衡开发效率与系统质量，建立了一套 Case 进化体系：

1. Capability 库：新功能 Case 试验场，允许失败，用于辅助开发。
2. Regression 库：从 Capability 毕业的“高素质”Case，作为 CI 门禁。

10. 结语

Agent 评测不是为了追求完美的 100 分，而是为了建立 “改动的信心”。当我们替换了底层模型（比如从 GPT-4o 换到 Claude 3.5），或重构了 Prompt ，测评体系能帮助我们判断：系统是否依然可靠。

这是智能体迈向生产级的必经之路。

附录：来自 Anthropic 的评测启示

构建 i-member 的过程，参考了行业先进方法论，以下是几点关键共识：

1. 从小开始，从 Bug 中提取：不要等攒够几百个 Case 再测。从真实失败的线上 Bug 中提取 20-50 条测试，就是极好的起点。

2. 写无歧义的任务：如果两个人类专家对结果判定不一致，说明任务定义有 Bug，而非 Agent 不行。

3. 三种 Grader 的黄金组合：

   • Code-based: 测状态和工具路径（确定性）。
   • Model-based: 测交互质量（开放性）。
   • Human: 做定期抽样校准。

4. 测终态，而非对话文本：Agent 嘴上说“已退款”不算数，数据库里真的生成了退款记录才算过。

5. 评测本身也需要校准：如果 Model Grader 评分与人工判断持续不一致，第一时间调优 Rubric。

---

参考资料：

• Anthropic: Demystifying evals for AI agents
• τ-bench: A Benchmark for Tool-Use Agents
• Anthropic: Automated Auditing