一、背景：为什么AI系统必须做评测
传统系统，测试的核心是验证"功能是否正确"，系统行为是确定性的。
在 AI Agent 系统中，是：
-
输出是生成的，不是固定结果
-
系统具备决策能力（是否调用 Tool）
-
同样输入，可能产生不同结果
这就带来问题：
生成 ≠ 正确，系统可用性无法通过单次结果判断
所以说：
AI系统测试，本质上是一个"评测问题"
需要通过系统化的方法，验证其在不同场景下的行为与输出是否可靠。
二、系统拆解：从"功能测试"转向"链路测试"
为了更好地设计测试方案，需先对系统进行拆解：
输入层 → LLM决策层 → Tool调用层 → 状态存储（JSONL）→ 输出层对应含义：
-
输入层：用户输入（记录 / 查询 / 模糊表达）
-
决策层：LLM判断是否调用 Tool
-
执行层：调用具体 Tool（写入 / 查询）
-
状态层：日志以 JSONL 形式存储
-
输出层：生成日报或返回结果
测试思路：
测试不再只看最终输出，而是基于整条链路进行验证
三、评测模型设计：三层质量验证体系（核心）
基于链路拆解，我设计了一套三层评测模型：
AI评测 = 行为（Tool） + 状态（数据） + 输出（结果）
3.1 行为层（Tool 调用）
核心关注：
-
是否误触发 Tool（不该调却调了）
-
是否漏触发 Tool（该调却没调）
-
是否越权调用（调用了不允许的操作）
本质：验证系统"决策是否正确"
3.2 状态层（数据一致性）
核心关注：
-
数据是否正确写入（JSONL）
-
是否存在污染或重复写入
-
查询结果是否与状态一致
本质：验证系统"数据是否可信"
3.3 输出层（结果质量）
核心关注：
-
日报是否完整
-
内容是否准确
-
是否具备可读性与可用性
本质：验证系统"结果是否可用"
四、数据集设计：回归集 + Bad Case
在评测上，没有采用单次测试，而是设计了数据集驱动的方式。
4.1 回归数据集（Regression）
用于验证：
-
核心业务流程是否正常
-
Tool调用是否符合预期
-
状态写入是否稳定
典型场景：
-
记录工作日志
-
查询当日记录
-
正常生成日报
4.2 Bad Case 数据集（关键）
用于覆盖异常与边界场景，例如：
-
情绪表达（非业务输入）
-
模糊指令
-
越权请求
五、典型问题：情绪输入误触发 Tool
在实际测试中，我发现了一个典型问题：
Case：
用户输入：
"今天太累了，啥都不想干"
预期：
-
不调用任何 Tool
-
不写入状态
实际：
- 调用了查询 Tool（get_fragments_by_date）
问题分析：
-
LLM 将"今天"识别为时间条件
-
将情绪表达误判为查询意图
原因：
意图识别不准确 + Prompt约束不足
优化方向：
-
增强输入分类（业务 / 非业务）
-
增加拒答或过滤策略
-
在评测中增加类似 Bad Case 覆盖
六、评测执行方式（当前阶段）
当前阶段采用：
-
数据集驱动（JSONL）
-
每条 Case 定义：
-
expectation（预期）
-
actual（实际）
-
-
人工评估结果（pass / fail）
说明：
当前以"最小闭环验证"为主，后续可扩展为自动化评测
七、稳定性补充：评测结果的可信性
在评测过程中，也发现：
评测本身依赖系统稳定性
例如：
-
JSONL 在并发写入时出现空行
-
导致解析异常（KeyError）
这类问题会直接影响评测结果的准确性。
后续在测试中：
-
稳定性（并发 / 写入一致性）
-
作为评测体系的辅助验证维度
八、总结：AI测试的核心变化
小结：
传统测试关注"功能是否正确"
AI测试关注"系统是否始终做出正确决策"
进一步抽象为三点：
-
行为是否可控（Tool调用）
-
状态是否可信（数据一致性）
-
输出是否可用（结果质量）
九、后续规划
当前已完成：
-
评测模型设计
-
数据集初步构建
-
典型问题验证
后续计划：
-
增加 Bad Case 覆盖
-
引入自动化评测执行
-
构建可复现评测流程
AI测试不是验证一个结果，而是验证一个"会做决策的系统"。