前言：

根据上一篇性能测试分层理论，梳理一下L2 状态层的压测。

在 Agent 系统里，真正危险的不是慢，而是乱。
这一篇只讲 L2：状态层压测，我是如何一步步定位出三个问题的。

1、为什么单独测 L2

项目的核心链路：

自然语言 → 路由 → tool → JSONL 落盘

只要落盘层出问题：

• L3 summary 会被污染

• 查询会读到脏数据

• 后续分析全部失真

所以顺序是：

先压 L2，再谈生成层。

2、第一轮压测：单线程对照组

场景 S1：单线程 200 次写入（JMeter）

配置：

• 线程数：1

• 循环：200

• 输入：record 类自然语言

结果：

• 错误率：0%

• JSONL 校验：全部合法

校验脚本：

import json

with open('fragments.jsonl','r',encoding='utf-8') as f:
for i,line in enumerate(f,1):
json.loads(line)

无异常。

结论：

在无并发条件下，系统稳定。

这一步比较重要，因为它为后续问题提供了对照组。

3、第二轮压测：幂等缺失问题出现

重复运行同一个压测脚本两次。

发现：

• 同样的输入

• 生成两条完全相同的记录

让Claude code检查代码：

item = {
    "id": uuid.uuid4().hex,
    "content": content
}
_append_jsonl(...)

每次都会生成新的 UUID，没有查重逻辑。

这说明：

系统没有幂等保障。

这不是并发问题。
是状态一致性设计问题。

4、第三轮压测：并发异常（KeyError）

场景 S2：10线程 × 100循环

结果：

• 总样本：1000

• 异常率：42.40%

失败响应：

{
  "error_type": "KeyError",
  "error": "'tools'"
}

说明：

并发下有部分请求在决策阶段直接崩溃。

这已经不是“慢”，而是“不可用”。

5、第四轮验证：文件真的被写坏了吗？

并发压测结束后，我没有直接看 TPS。

而是：

对 JSONL 做逐行校验。

结果：

总记录数: 574
第 390 行 JSON 解析失败

0389: {...正常JSON...}
0390: '\n'
0391: {...正常JSON...}

第 390 行是空行。

6、为什么空行意味着并发写失败

JSONL 格式要求：

每一行必须是完整 JSON。

出现空行说明：

• 多线程写入没有互斥

• 写操作不是原子

• 文件结构已被污染

这是：

存储层并发安全缺陷。

7、用对照组确认原因

再次运行：

• 单线程 200 次

• 校验 JSONL

结果：

• 无异常

可以确定：

文件损坏是并发竞态导致，而非业务逻辑错误。

8、L2 当前问题

编号	问题	类型
L2-01	幂等缺失（重复写入）	状态一致性
L2-02	并发请求 KeyError	上下文竞态
L2-03	并发写入 JSONL 损坏	存储安全

9、本轮压测的价值

这轮压测不是在找 TPS 上限。

而是：

1. 系统是否具备基本幂等能力？

2. 并发下是否稳定？

3. 数据是否会被破坏？

答案是：

• 幂等：否

• 并发稳定：否

• 存储安全：否

但这些问题都有对照组和证据链支持。

10、下一步计划

1. 为 JSONL 写入增加互斥保护

2. 排查并发上下文问题

3. 复跑 L2 并发压测

4. 在稳定状态下再做 L3 并发生成压测

小结

Agent 的性能测试，核心不是“压到多少 TPS”。

而是：

用并发测试，把隐藏在本地文件、上下文共享、幂等设计里的问题压出来。

项目地址：https://github.com/test202005/project1-suite