一、背景：为什么要做AI评测
在 AI WorkLog Agent 项目中，系统核心流程：
输入 → LLM决策 → Tool调用 → 状态存储 → 输出
和传统系统不同，这类系统：
系统"能运行"，不代表"决策是对的"
例如：
-
情绪输入被当成查询
-
记录请求未触发写入
-
越权操作没有被拒绝
这些问题，传统测试很难覆盖。
所以，需要一套：
👉 可复现、可量化的评测机制
二、评测设计思路（核心框架）
这次评测围绕 Agent 决策链路，设计两类数据集：
1. 回归数据集（Regression）
用于验证正常流程：
-
记录类（record_fragment）
-
查询类（get_fragments_by_date）
-
拒绝类（reject）
2. 异常数据集（Bad Case）
用于验证异常场景：
-
情绪输入（如：今天太累了）
-
模糊指令（如：帮我做点啥）
-
非法输入（如：12345）
-
越权请求（如：删除记录）
-
多意图输入（如：查完再总结）
三、数据集结构设计（关键）
每条测试用例统一结构如下：
{
"case_id": "B001",
"case_type": "badcase",
"input": {...},
"precondition": {...},
"expectation": {
"expected_tool": null,
"should_write_state": false
}
}核心设计点：
-
使用
expected_tool作为核心判断标准 -
使用
should_write_state判断是否影响系统状态 -
保证每条case可复现、可执行
四、评测执行：自动化评测脚本
评测脚本 run_eval.py，核心流程：
评测流程
-
读取 JSONL 数据集
-
逐条执行测试用例
-
调用 Agent 核心函数
-
提取实际执行结果（tool_called）
-
与 expectation 对比
-
判定 pass / fail
-
输出结果与统计
判定规则（简化版）
expected_tool == actual_tool → pass
否则 → fail五、评测结果（关键）
第一阶段：种子数据验证
-
用例数：4
-
通过：3
-
失败：1
-
通过率：75%
失败案例：
情绪输入被误识别为查询请求
第二阶段：扩展数据集评测
-
用例数：16
-
通过：8
-
失败：8
-
通过率：50%
六、问题归因分析（核心）
通过评测，识别出三类核心问题：
1. 意图识别错误（最主要问题）
表现：
-
情绪输入 → 被识别为查询
-
无效输入 → 触发 Tool
原因：
LLM 决策层缺乏明确的"拒绝边界"
2. 记录意图识别失败
表现：
- "帮我记一下..." 未触发 record
原因：
record 关键词识别不完整 / 优先级不足
3. 越权与多意图处理问题
表现：
-
删除请求未拒绝
-
多步骤指令未拆解
原因：
缺乏安全约束与指令分解机制
七、优化方向（思路）
基于问题分析，提出优化方向：
1. Prompt约束增强
-
非任务型输入禁止调用 Tool
-
明确 record / query / reject 边界
2. 规则层补充
-
增加关键词过滤
-
增加越权操作拦截
3. 意图优先级调整
- record > query > fallback
八、总结：AI评测的核心价值
核心不是"写脚本"，而是：
构建一套可复现的评测方法
相比传统测试，这种方式可以：
-
发现"决策错误"，而非仅功能错误
-
对AI系统质量进行量化评估（通过率）
-
支持持续回归与优化验证
九、延伸思考
后续可以进一步扩展：
-
引入 LLM 作为评判（LLM as Judge）
-
接入 CI 做自动评测
-
构建长期回归数据集