前言：
上一篇分析了 Agent系统如何通过LLM触发Tool：
用户输入
↓
LLM决策
↓
生成 tool_call
↓
系统执行 Tool以及：
LLM只负责决策
系统代码负责执行
状态层负责持久化系统中，LLM并不会直接执行业务逻辑 。
模型只负责生成调用请求，真正完成操作的是 Tool执行层。
因此，在AI系统架构中通常会形成如下结构：
输入层
↓
LLM决策层
↓
Tool执行层
├─业务逻辑
└─状态存储（JSONL / DB）
↓
输出层本文重点梳理 Tool执行层和状态管理层的工作方式。
一、Tool执行层：AI系统真正做事情的地方
在Agent系统中，Tool层负责执行真实业务逻辑。
例如一个工作记录Agent系统中，常见Tool包括：
record_fragment
get_fragments_by_date
confirm_clock_event当LLM生成tool_call后，后端系统会解析并执行对应函数。
例如：
def record_fragment(content, author, occurred_date=None):
item = {
"id": generate_fragment_id(),
"type": "fragment",
"content": content.strip(),
"author": author,
"created_at": now_iso()
}
_append_jsonl(FRAGMENTS_PATH, item)
return {"ok": True, "saved": item}这个函数完成两个核心工作：
业务逻辑处理
数据持久化在很多AI系统中，Tool层本质上就是：
Service层负责调用：
数据库
日志系统
业务服务二、状态层：AI系统的持久化数据
Tool执行完成后，系统通常需要更新状态。
状态层的作用是：
记录系统数据
保存历史信息
支持后续查询例如一个实现可以使用 JSONL 文件。
def _append_jsonl(path, obj):
with open(path, "a", encoding="utf-8") as f:
f.write(json.dumps(obj, ensure_ascii=False) + "\n")每次记录都会写入一行数据：
{"id": "abc123", "type": "fragment", "content": "完成测试用例", "author": "张三"}
{"id": "def456", "type": "summary", "content": "今日完成任务", "author": "张三"}这种方式的优点是：
实现简单
日志可追溯
方便调试但在企业系统中，状态层通常会使用：
数据库
缓存系统
日志系统例如：
MySQL
Redis
Elasticsearch三、为什么状态层最容易出Bug
在很多AI系统中，问题往往不是出现在模型，而是出现在状态层。
常见问题包括：
并发写入
数据不一致
状态污染
日志损坏例如在测试过程中，如果多个请求同时写入 JSONL 文件：
线程A写入
线程B写入就可能出现：
空行
半行数据
JSON解析错误系统在读取日志时就会出现：
KeyError
JSONDecodeError因此在系统中通常需要：
文件锁
数据库事务
消息队列来保证数据一致性。
四、AI系统中的执行链路
结合前两篇内容，可以得到完整执行流程：
User Input
↓
LLM (Prompt + Tool Schema)
↓
tool_call
↓
Backend Parse
↓
Tool Execute
↓
State Update
↓
Return Response可以看到：
LLM → 决策
Tool → 执行
State → 持久化这三者共同构成了 AI系统的核心执行链路。
五、从测试视角看Tool层
在AI系统测试中，Tool层其实是非常重要的一部分。
需要重点关注：
Tool是否正确触发
参数是否正确
执行逻辑是否稳定
状态是否正确更新典型测试点包括：
错误参数处理
并发写入
异常恢复
数据一致性这些问题往往比模型本身更容易影响系统稳定性。
六、小结
在Agent系统中，大模型并不会直接执行系统操作，而是通过 Tool 驱动系统行为。
整个系统可以总结为：
LLM负责决策
↓
Tool负责执行
↓
状态层负责持久化梳理这一点，对于理解 AI系统架构与测试方法非常关键。
下一篇
下一篇将继续讨论：
AI系统测试实践：状态层为什么是AI系统最容易出Bug的地方
重点包括：
并发问题
数据一致性
日志损坏
系统恢复