前言：
在上一篇文章中，总结了 AI系统测试的六层模型：输入层、规则层、LLM层、Tool层、状态层、输出层。
本文重点讨论其中最核心的一层：LLM 决策层测试。
很多人说"AI系统测试"，只停留在：
-
测 Prompt
-
看回答对不对
实际项目里的 LLM，是在做 决策：
用户输入
↓
LLM理解意图
↓
判断是否调用Tool
↓
选择Tool
↓
生成Tool参数
↓
Tool执行
↓
生成回复所以这一篇重点是：
LLM 在系统中到底负责什么，以及测试应该怎么做。
一、LLM 在 Agent 系统中到底负责什么
在很多 AI 应用中，LLM 似乎只是一个 回答问题的模型。
但在 Agent 系统中，LLM 的角色更接近：
决策引擎。
典型流程：
用户输入
↓
LLM理解意图
↓
判断是否调用Tool
↓
选择Tool
↓
生成调用参数
↓
返回结果例如在 WorkLog Agent 项目中，LLM需要完成几个任务：
-
理解用户输入
-
判断用户意图
-
决定是否调用工具
-
提取工具参数
-
生成最终回复
在测试时，需要验证的不只是 回答是否正确，而是：
决策是否正确。
二、为什么 LLM 决策层容易出问题
LLM 决策层的问题通常来自三个方面。
1 意图识别不稳定
例如用户输入：
昨天干啥来着模型可能理解为：
-
查询日志
-
让系统总结
-
普通聊天
如果意图识别错误，就会导致系统行为异常。
2 Tool 调用错误
在 Agent 系统中，LLM需要决定：
是否调用Tool
调用哪个Tool例如用户输入：
今天修复登录Bug正确行为应该是：
调用 record_fragment但如果 LLM 判断错误，可能：
-
不调用工具
-
调错工具
-
直接生成回答
3 参数提取错误
即使 Tool 调用正确，也可能出现：
日期错误
内容错误
字段缺失例如：
昨天修复登录Bug正确参数：
date: 2025-03-10
content: 修复登录Bug但模型可能输出：
date: today这会导致数据记录错误。
三、LLM 决策层测试重点
在测试中，需要重点关注三类问题。
1 意图识别测试
验证模型是否正确理解用户输入。
例如：
昨天修复Bug
今天写接口测试
帮我看看昨天做了什么系统应该分别识别为：
记录日志
记录日志
查询日志如果识别错误，就会影响整个 Agent 行为。
2 Tool 调用测试
验证 LLM 是否正确调用工具。
例如：
今天写了接口测试模型应该生成：
tool_call: record_fragment需要测试：
-
是否调用
-
调用哪个工具
-
是否重复调用
3 参数提取测试
验证 LLM 是否能正确生成工具参数。
例如：
昨天修复登录Bug需要验证：
date 是否正确
content 是否完整如果参数提取错误，系统会记录错误数据。
四、LLM 决策层测试方法
可以通过 构建测试集 的方式验证模型行为。
例如设计一组测试输入：
昨天修复Bug
今天写测试
帮我看看昨天干了啥然后验证：
意图是否正确
Tool是否正确
参数是否正确这类测试可以：
-
手工验证
-
或通过脚本批量运行
五、经验
在 WorkLog Agent 项目中，LLM 决策层最容易出现的问题是：
1 Tool 未触发
用户输入明确，但模型没有调用工具。
2 Tool 参数不完整
例如缺少日期字段。
3 意图误判
例如把查询日志理解成普通聊天。
因此在系统设计中，引入：
规则优先 + LLM 兜底
也就是说：
高频、明确的请求由规则处理，
复杂输入才交给 LLM。
这样可以显著提高系统稳定性。
六、小结
在 Agent 系统中，LLM 的作用不仅是生成回答，更重要的是：
决策。
测试 LLM 决策层时，需要重点关注：
-
意图识别
-
Tool 调用
-
参数提取
而不是只验证回答是否正确。
梳理核心：
1️⃣ Agent 决策视角
2️⃣ Tool 调用测试
3️⃣ 规则优先 + LLM兜底
下一步继续梳理，
状态层测试：为什么 AI 系统最容易出 Bug 的是状态层
JSONL 并发写入
↓
空行
↓
KeyError