多智能体系统压测完全清单：从场景设计到指标收集的全链路落地指南

关键词

多智能体系统、压力测试、负载建模、性能指标、容错性验证、可观测性、压测自动化

摘要

随着大语言模型驱动的多智能体框架（MetaGPT、AutoGen、ChatDev）、自动驾驶车群、工业机器人集群、智慧城市IoT智能体网络的大规模商业化落地，多智能体系统的性能稳定性已经成为影响业务可用性的核心瓶颈。与传统无状态Web系统的压测逻辑完全不同，多智能体系统具有行为动态性、状态关联性、协作不确定性三大核心特征，传统JMeter、LoadRunner等压测工具完全无法覆盖其核心风险点。
本文为开发者、测试工程师、架构师提供了一套可直接落地的多智能体系统压测全流程清单，从核心概念辨析、场景设计方法论、负载建模原理、指标体系搭建到故障定位方法全覆盖，包含完整的代码示例、架构设计方案和真实企业落地案例，帮助读者彻底解决多智能体系统上线前的性能验证难题，避免上线后出现死锁、消息雪崩、状态不一致、任务链断裂等致命问题。

---

1. 背景介绍

1.1 问题背景

2023年以来，多智能体系统的商业化增速超过了所有技术从业者的预期：某头部电商平台基于多智能体搭建的客服系统，承载了平台80%的用户咨询，峰值同时运行的智能体数量超过1.2万个；某自动驾驶企业的车路协同系统，单城市同时在线的车端智能体、路侧智能体、行人模拟智能体数量超过5万个；某SaaS企业推出的多智能体代码开发平台，企业客户同时创建的智能体开发团队超过3000个。
但与之对应的是，70%以上的多智能体系统上线后都出现过严重的性能故障：

• 2023年10月，某头部智能客服厂商的多智能体系统在大促期间出现死锁故障，20%的用户咨询超过30分钟没有得到回复，直接导致客户损失超过2000万；
• 2024年2月，某自动驾驶企业的车路协同系统在模拟压测时，因10%的路侧单元延迟升高，导致整个区域的车端智能体决策延迟从100ms升高到2s，险些造成模拟事故；
• 2024年3月，某SaaS多智能体开发平台出现状态不一致故障，多个智能体同时处理同一个客户的开发任务，导致重复计费、代码冲突，客户投诉率暴涨300%。
  这些故障的核心原因，都是团队用传统Web系统的压测方法验证多智能体系统，完全没有覆盖到多智能体特有的协作风险、状态风险、容错风险。

1.2 问题描述

多智能体系统的压测面临三大传统压测完全没有的挑战：

1. 行为关联性挑战：传统Web系统的请求是独立无状态的，1000个并发请求之间没有任何关联；但多智能体系统的行为是高度关联的，比如MetaGPT中的产品、开发、测试智能体，三个智能体的行为是互相依赖的，开发智能体必须等产品智能体输出需求文档才能开始工作，测试智能体必须等开发智能体输出代码才能开始测试，一个智能体的延迟会传导到整个任务链。
2. 状态不确定性挑战：传统Web系统的状态是集中存储的，只要数据库一致，整个系统的状态就是一致的；但多智能体系统的状态是分布式存储在每个智能体本地的，很容易出现状态不一致的问题，比如两个客服智能体都认为同一个退款订单是自己负责的，重复退款，或者都认为是对方负责的，没人处理。
3. 故障传导性挑战：传统Web系统的故障是局部的，某个接口超时只会影响对应的请求；但多智能体系统的故障会全网传导，比如某个调度节点的延迟升高，会导致所有挂载在这个节点上的智能体都无法正常交互，进而导致整个系统的消息队列堆积，最终引发雪崩。

1.3 目标读者

本文适合以下人群阅读：

• LLM多智能体应用开发者、架构师
• 分布式系统性能测试工程师
• 自动驾驶、工业机器人、IoT集群领域的系统工程师
• 多智能体系统领域的科研人员

1.4 边界与外延

1.4.1 压测适用边界

不需要做多智能体系统压测的场景：

• 系统智能体数量少于3个，没有复杂的协作逻辑
• 系统同时在线用户数少于1000，峰值负载不会超过系统承载能力的30%
• 智能体之间没有异步交互，所有调用都是同步阻塞的
  必须做多智能体系统压测的场景：
• 智能体数量超过10个，存在多角色协作、任务分发、共识决策等逻辑
• 系统峰值同时在线用户数超过1万，智能体实例数超过1000个
• 智能体之间通过消息队列、事件总线异步交互，存在状态同步需求

1.4.2 外延能力

多智能体压测不是孤立的性能验证工作，可以和混沌工程、可观测性体系、自动化运维体系打通，形成完整的多智能体系统稳定性保障闭环。

---

2. 核心概念解析

2.1 核心概念类比

我们用商场导购机器人集群的例子来类比多智能体系统的压测逻辑：

多智能体压测概念	商场导购机器人对应场景
智能体	每个导购机器人
协作任务	帮用户找商品、引导到收银台、处理退换货
负载剖面	周末高峰1000个用户同时逛商场，每个用户平均和2个机器人交互，每个机器人平均和其他3个机器人沟通库存、位置信息
死锁	两个机器人都要走同一个通道，都等对方先让，一直堵在原地
状态不一致	A机器人告诉用户某款鞋子有38码，B机器人告诉用户没有38码，实际上库存只有1双
性能瓶颈	调度中心处理能力不足，机器人的位置上报请求排队，导致机器人的路径规划延迟10秒

2.2 核心概念对比

我们把多智能体压测和传统Web压测的核心属性做对比，方便读者快速理解两者的差异：

对比维度	传统Web系统压测	多智能体系统压测
请求特性	独立无状态，请求之间没有关联	关联有状态，智能体的行为互相依赖、互相影响
负载模型	固定QPS、固定并发数，行为可预测	动态行为剖面，基于真实智能体的协作逻辑生成，行为存在不确定性
核心指标	响应时间、错误率、吞吐量	协作成功率、任务完成时长、死锁率、状态一致性、共识延迟
故障模式	接口超时、服务宕机、数据库慢查询	死锁、消息丢失、状态不一致、任务链断裂、故障雪崩
压测成本	低，单台服务器可模拟百万级并发请求	高，模拟1万个智能体需要至少10台压测节点，还要模拟智能体的协作逻辑
压测周期	短，单场景压测通常在1小时以内	长，单场景压测通常需要4小时以上，还要多次重复验证统计规律

2.3 概念结构与核心要素

多智能体压测体系由5个核心要素组成：

1. 场景库：覆盖正常场景、高峰场景、异常场景、极限场景四大类，每个场景定义明确的负载参数、故障注入规则、SLO阈值
2. 负载生成引擎：分布式压测节点集群，能够基于真实的智能体行为模型，模拟千万级智能体的协作行为
3. 全链路观测体系：覆盖基础设施层、平台层、业务层三层的指标采集、链路追踪、日志采集能力
4. 数据分析引擎：能够自动识别性能瓶颈、根因定位，输出可落地的优化建议
5. 报告生成模块：自动生成压测报告，包含指标对比、瓶颈分析、优化建议、风险评估四个部分

2.4 概念关系可视化

2.4.1 实体关系ER图

2.4.2 交互关系流程图

---

3. 技术原理与实现

3.1 数学模型

3.1.1 智能体行为模型

智能体的行为可以用马尔可夫决策过程（MDP）来建模，确保模拟的智能体行为和真实场景完全一致：
$$\mathcal{M}=(S,A,P,R,\gamma )$$
其中：

• $S$ 是智能体的状态空间，比如客服智能体的状态包括：空闲、接待用户、查询知识库、转人工、结束会话
• $A$ 是智能体的动作空间，比如发送消息、查询数据库、调用其他智能体、结束任务
• $P(s^{\prime }|s,a)$ 是状态转移概率，比如客服智能体在接待用户状态下，执行查询知识库动作后，转移到转人工状态的概率是15%，转移到结束会话状态的概率是85%，这个概率可以从真实的历史行为数据中统计得到
• $R(s,a)$ 是奖励函数，用来校准智能体的行为，确保模拟的行为符合真实的业务逻辑
• $\gamma$ 是折扣因子，用来衡量未来奖励的权重

3.1.2 负载强度模型

多智能体系统的负载强度不是用QPS来衡量的，而是用以下公式计算：
$$\lambda (t)=\alpha (t)\times N(t)\times f(t)\times c(t)$$
其中：

• $\lambda (t)$ 是t时刻的系统负载强度
• $N(t)$ 是t时刻同时运行的智能体数量
• $f(t)$ 是每个智能体的平均交互频率，单位是次/秒
• $\alpha (t)$ 是任务复杂度系数，简单对话任务取值0.5，多步协作任务取值2，复杂共识任务取值5
• $c(t)$ 是环境动态系数，环境没有变化时取值1，环境动态变化时（比如自动驾驶场景的红绿灯变化、行人横穿马路）取值2-10

3.1.3 性能瓶颈判定模型

当系统满足以下任意一个条件时，就认为达到了性能瓶颈：
$$\{\begin{array}{l}{P}_{success}<SL{O}_{success}\\ T_{task}>SL{O}_{time}\\ R_{deadlock}>SL{O}_{deadlock}\\ C_{queue}>SL{O}_{queue}\end{array}$$
其中：

• $P_{success}$ 是任务成功率
• $T_{task}$ 是任务平均完成时长
• $R_{deadlock}$ 是死锁率
• $C_{queue}$ 是消息队列的堆积量
• $SL{O}_{\ast }$ 是业务预先定义的服务水平目标

3.2 算法流程

自适应梯度加压算法是多智能体压测的核心算法，避免一开始就把系统打崩，同时能够精准定位瓶颈点：

3.3 代码实现

以下是基于MetaGPT框架的多智能体系统压测的Python代码示例，包含负载生成、指标采集、故障注入三个核心功能：

import asyncio
import random
import time
from prometheus_client import Counter, Gauge, start_http_server
from metagpt.roles import ProductManager, Engineer, Tester
from metagpt.team import Team

# 定义Prometheus指标
TASK_SUCCESS = Counter('mas_task_success', '成功完成的任务数量')
TASK_FAILED = Counter('mas_task_failed', '失败的任务数量')
TASK_DURATION = Gauge('mas_task_duration', '任务完成时长，单位秒')
DEADLOCK_COUNT = Counter('mas_deadlock_count', '死锁发生的次数')
AGENT_ACTIVE = Gauge('mas_agent_active', '当前运行的智能体数量')

# 故障注入配置
FAULT_CONFIG = {
    "agent_timeout_rate": 0.05,  # 智能体超时概率5%
    "message_loss_rate": 0.01,  # 消息丢失概率1%
    "network_delay_ms": 100  # 网络延迟100ms
}

async def simulate_team_task(team_id: int, task_requirement: str):
    """模拟一个多智能体团队的开发任务"""
    start_time = time.time()
    try:
        # 故障注入：随机模拟智能体超时
        if random.random() < FAULT_CONFIG["agent_timeout_rate"]:
            await asyncio.sleep(30)  # 超时30秒
        
        # 故障注入：随机模拟消息丢失
        if random.random() < FAULT_CONFIG["message_loss_rate"]:
            raise Exception("Message lost during transmission")
        
        # 故障注入：模拟网络延迟
        await asyncio.sleep(FAULT_CONFIG["network_delay_ms"] / 1000)

        # 创建多智能体团队
        team = Team()
        team.hire([
            ProductManager(),
            Engineer(),
            Tester(),
        ])
        
        # 执行任务
        result = await team.run(task_requirement)
        
        # 检测死锁：如果任务执行时间超过10分钟，判定为死锁
        if time.time() - start_time > 600:
            DEADLOCK_COUNT.inc()
            TASK_FAILED.inc()
            return
        
        TASK_SUCCESS.inc()
        TASK_DURATION.set(time.time() - start_time)
    except Exception as e:
        TASK_FAILED.inc()
    finally:
        AGENT_ACTIVE.dec(3)  # 一个团队3个智能体，任务结束后减少计数

async def load_generator(concurrent_teams: int, task_per_team: int):
    """负载生成器，模拟多个并发的多智能体团队"""
    tasks = []
    for i in range(concurrent_teams):
        AGENT_ACTIVE.inc(3)
        task = asyncio.create_task(
            simulate_team_task(
                team_id=i,
                task_requirement=f"开发一个简单的TODO清单应用，支持增删改查功能"
            )
        )
        tasks.append(task)
        if len(tasks) >= 100:  # 控制并发数，避免压测节点本身过载
            await asyncio.gather(*tasks)
            tasks = []
    if tasks:
        await asyncio.gather(*tasks)

if __name__ == "__main__":
    # 启动Prometheus指标服务，端口9090
    start_http_server(9090)
    # 压测参数：100个并发团队，每个团队执行10个任务
    asyncio.run(load_generator(concurrent_teams=100, task_per_team=10))

---

4. 压测全流程落地指南

4.1 压测准备阶段

4.1.1 架构梳理

压测前必须梳理清楚被测多智能体系统的完整架构，输出以下文档：

1. 智能体角色清单：每个智能体的角色、职责、状态流转逻辑
2. 交互拓扑图：智能体之间的交互协议（HTTP/RPC/MQ）、依赖关系、通信路径
3. 基础设施清单：调度集群、消息队列、数据库、缓存、存储的配置和部署位置
4. SLO定义：明确业务要求的性能指标，比如任务成功率≥99.99%，任务平均完成时长≤10s，死锁率=0%，消息丢失率≤0.001%

4.1.2 环境搭建

压测环境必须和生产环境配置完全一致，避免压测结果失去参考价值：

环境组件	要求
压测节点	配置和生产环境的智能体节点一致，分布式部署，避免压测节点本身成为瓶颈
被测集群	和生产环境的配置、版本、部署方式完全一致
可观测组件	部署OpenTelemetry Collector、Prometheus、Grafana、Jaeger，覆盖全链路追踪、指标采集、日志采集
数据隔离	压测流量用特定的Header染色，和真实流量隔离，压测数据存储在独立的数据库实例，避免污染生产数据
环境安装步骤：

1. 安装Docker和Docker Compose：curl -fsSL https://get.docker.com | bash
2. 用Docker Compose启动可观测组件：wget https://raw.githubusercontent.com/open-telemetry/opentelemetry-collector/main/examples/demo/docker-compose.yml && docker compose up -d
3. 安装压测工具依赖：pip install metagpt opentelemetry-api opentelemetry-sdk prometheus-client aiokafka
4. 配置被测集群的访问权限，确保压测节点可以正常访问所有智能体接口

4.2 场景设计阶段

压测场景必须覆盖四大类，每类场景的设计规则如下：

场景类型	设计规则	压测目标
正常场景	按照日常平均负载的70%配置，智能体数量、交互频率、任务复杂度和日常一致，不注入任何故障	验证系统在正常负载下的性能表现，得到基准指标
高峰场景	按照历史峰值负载的120%配置，比如大促期间的负载，模拟业务高峰	验证系统在高峰负载下的稳定性，是否满足SLO要求
异常场景	在高峰负载的基础上，注入常见故障：10%的智能体节点宕机、网络延迟增加200ms、消息队列1%的丢失率、数据库慢查询占比5%	验证系统的容错能力，故障恢复能力，是否会出现雪崩
极限场景	逐步提升负载，直到系统达到瓶颈，记录系统能够承载的最大负载	评估系统的扩容上限，为未来的业务增长做准备
场景设计最佳实践：每个场景必须定义明确的终止条件，比如高峰场景压测持续2小时，或者任务成功率低于99%就停止，避免把系统打崩。

4.3 压测执行阶段

压测执行必须按照以下顺序进行，避免遗漏风险点：

1. 基准测试：先做低负载的正常场景压测，持续30分钟，记录基准指标，作为后续压测的对比基线
2. 负载测试：按照10%的步长逐步提升负载，每个负载阶段持续10分钟，直到达到高峰负载的120%，记录每个阶段的指标
3. 压力测试：继续提升负载，直到系统达到瓶颈，记录最大承载能力
4. 混沌测试：在高峰负载下，依次注入各种故障，每个故障注入后持续15分钟，观察系统的表现，验证容错能力
5. 稳定性测试：在70%的高峰负载下，持续压测72小时，验证系统的长时间稳定性，是否存在内存泄漏、资源未释放等问题
   执行注意事项：每次压测只改变一个变量，比如这次只增加智能体数量，下次只增加交互频率，否则无法定位是哪个变量导致的性能下降。

4.4 指标收集与分析阶段

指标收集必须覆盖三层，避免遗漏瓶颈点：

4.4.1 基础设施层指标

指标名称	指标含义	正常阈值
CPU使用率	所有节点的CPU平均使用率	≤70%
内存使用率	所有节点的内存平均使用率	≤80%
磁盘IO使用率	数据库、消息队列节点的磁盘IO使用率	≤60%
网络带宽使用率	所有节点的出入带宽使用率	≤70%
MQ堆积量	消息队列的未消费消息数量	≤1000条
数据库QPS	数据库的查询/写入QPS	≤数据库最大承载的70%

4.4.2 平台层指标

指标名称	指标含义	正常阈值
调度延迟	调度器把任务分配给智能体的平均耗时	≤100ms
消息传递延迟	消息从发送方到接收方的平均耗时	≤50ms
消息丢失率	发送的消息中没有被消费的比例	≤0.001%
调度器吞吐量	调度器每秒能够处理的任务数量	≥业务峰值的150%
智能体存活率	正常运行的智能体占总智能体的比例	≥99.9%

4.4.3 业务层指标

指标名称	指标含义	正常阈值
任务成功率	成功完成的任务占总任务的比例	≥99.99%
任务平均完成时长	从任务创建到完成的平均耗时	≤业务要求的时长
死锁率	出现死锁的任务占总任务的比例	=0%
状态不一致率	多个智能体的状态不一致的任务占比	≤0.001%
共识延迟	多智能体达成共识的平均耗时	≤500ms

4.4.4 瓶颈定位方法

如果压测过程中指标不满足阈值，按照以下顺序定位瓶颈：

1. 先看基础设施层指标，是否有CPU、内存、IO、带宽不足的问题
2. 再看平台层指标，是否有调度延迟过高、消息堆积、智能体存活率低的问题
3. 最后看业务层指标，结合全链路追踪，定位是哪个智能体、哪个步骤的耗时过高
4. 对于死锁、状态不一致的问题，结合链路日志，分析智能体的状态流转逻辑，找到死锁的原因

---

5. 系统设计与落地案例

5.1 通用多智能体压测平台设计

5.1.1 系统架构设计

5.1.2 系统功能设计

1. 场景管理：支持可视化配置压测场景，上传智能体行为模型，配置故障注入规则
2. 负载生成：支持分布式压测，弹性扩缩容压测节点，最多支持模拟100万个智能体
3. 故障注入：支持注入智能体超时、节点宕机、网络延迟、消息丢失、数据库故障等常见故障
4. 可观测：支持全链路追踪、指标实时展示、日志实时查询
5. 数据分析：支持自动识别瓶颈点，根因分析，输出优化建议
6. 报告生成：支持自动生成压测报告，对比历史压测结果，评估优化效果

5.1.3 接口设计

接口路径	请求方法	功能描述
/api/v1/scene	POST	创建压测场景
/api/v1/scene/{id}	GET	查询压测场景配置
/api/v1/task/start	POST	启动压测任务
/api/v1/task/{id}/stop	POST	停止压测任务
/api/v1/task/{id}/metrics	GET	获取压测实时指标
/api/v1/report/{id}	GET	获取压测报告
/api/v1/agent/config	POST	配置模拟智能体的行为模型

5.2 真实企业落地案例

5.2.1 案例背景

某头部电商平台的多智能体客服系统，有12个智能体角色（售前咨询、售后咨询、退款处理、查单、物流查询、投诉处理等），峰值同时运行的智能体数量超过1.2万个，大促期间经常出现用户等待时间过长、退款请求重复处理、任务丢失等问题。

5.2.2 压测实施过程

1. 梳理架构：梳理了12个智能体的交互逻辑，SLO定义为任务成功率≥99.99%，用户等待时间≤3s，死锁率=0%
2. 场景设计：设计了正常场景（1000个智能体，5万并发用户）、高峰场景（1.2万个智能体，50万并发用户）、异常场景（10%的智能体节点宕机，网络延迟增加200ms）、极限场景（5万个智能体，200万并发用户）
3. 压测执行：先做基准测试，然后逐步加压到高峰场景，然后注入故障做混沌测试，最后做极限压测
4. 问题发现：
   • 调度器的负载均衡算法有问题，80%的请求打到了20%的智能体节点上，导致部分节点CPU使用率100%
   • 消息队列的ack机制配置错误，消息处理失败不会重试，死信队列没有监控，导致1%的任务丢失
   • 退款智能体和订单智能体的锁机制有问题，导致多个退款智能体同时处理同一个订单，出现重复退款的状态不一致问题
5. 优化效果：优化后，大促期间的任务成功率达到99.995%，用户平均等待时间从8s降到1.2s，没有再出现死锁、重复退款的问题。

---

6. 行业发展与未来趋势

6.1 多智能体压测技术发展历史

年份	多智能体技术阶段	压测技术阶段
2010年以前	主要应用于工业机器人、学术研究，智能体数量少，场景简单	定制化压测脚本，每个项目单独开发，没有通用工具
2010-2020年	应用于游戏AI、IoT集群，智能体数量最多达到数千级，有简单的协作逻辑	基于JMeter、LoadRunner二次开发，支持模拟简单的智能体行为，指标以基础设施层为主
2020-2023年	LLM驱动的多智能体爆发，MetaGPT、AutoGen等框架出现，智能体数量达到数万级，有复杂的协作、共识逻辑	出现专门的多智能体压测工具（AgentBench、MAS-Stress），开始关注协作成功率、死锁率、状态一致性等业务层指标
2023年以后	多智能体大规模商业化应用，跨域多智能体协作成为趋势，智能体数量达到百万级	AI驱动的自动化压测平台出现，自动生成场景、自动定位瓶颈，压测和混沌工程、可观测性完全融合

6.2 未来趋势

1. AI驱动的压测自动化：不用人工设计场景，AI自动分析真实的智能体行为数据，生成最贴合真实场景的压测用例，自动识别瓶颈点，给出可落地的优化建议，压测效率提升10倍以上
2. 云原生多智能体压测平台：和K8s深度集成，自动扩缩容压测节点，支持百万级智能体的模拟，按需付费，压测成本降低80%
3. 跨域多智能体压测：支持不同企业、不同平台的多智能体之间的协作压测，通过隐私计算技术，不用暴露各自的内部数据，就可以完成跨域压测
4. 压测左移：压测嵌入到CI/CD流程中，每次代码提交都自动执行轻量级的多智能体压测，提前发现性能问题，避免上线后才发现故障

6.3 潜在挑战

1. LLM智能体的不确定性：大语言模型的输出是不确定的，同一个输入多次调用的输出可能不一样，导致压测结果的波动很大，需要多次压测取统计值，压测成本很高
2. 大规模智能体的模拟成本：模拟100万个智能体需要上万台压测节点，成本很高，未来需要通过模型压缩、并行模拟等技术降低成本
3. 状态一致性的验证难度：多智能体的状态是分布式存储的，验证状态是否一致需要遍历所有智能体的本地状态，大规模场景下的验证成本很高

---

7. 总结与思考

7.1 本章小结

本文系统介绍了多智能体系统压测的完整流程，核心要点如下：

1. 多智能体压测和传统Web压测的核心区别是：多智能体的行为是关联有状态的，故障会全网传导，核心指标不是响应时间、吞吐量，而是协作成功率、死锁率、状态一致性等业务层指标
2. 压测全流程分为四个阶段：准备阶段（架构梳理、环境搭建）、场景设计阶段（覆盖正常、高峰、异常、极限四大场景）、执行阶段（按照基准测试、负载测试、压力测试、混沌测试、稳定性测试的顺序执行）、指标收集分析阶段（覆盖基础设施、平台、业务三层指标，按照从下到上的顺序定位瓶颈）
3. 多智能体压测的核心是负载建模，要用真实的历史行为数据训练智能体的行为模型，确保模拟的行为和真实场景一致，否则压测结果没有参考价值
4. 异常场景的压测比正常场景更重要，因为真实生产环境中一定会出现各种故障，只有在压测阶段验证了系统的容错能力，才能避免上线后出现雪崩故障

7.2 思考问题

1. 你所在的团队如果做多智能体应用，最容易忽略的压测场景是什么？
2. 如何衡量LLM驱动的多智能体系统的性能SLO？因为LLM的输出是不确定的，传统的响应时间指标是否适用？
3. 跨域多智能体协作的压测，如何在不暴露各自内部数据的前提下，完成压测验证？

7.3 参考资源

1. 《多智能体系统：现代方法》（清华大学出版社）
2. OpenTelemetry官方文档：https://opentelemetry.io/docs/
3. MetaGPT性能优化指南：https://docs.metagpt.dev/guide/performance
4. AgentBench开源多智能体压测工具：https://github.com/THUDM/AgentBench
5. 《混沌工程： Netflix系统稳定性之道》（机械工业出版社）

---

最佳实践Tips清单：

1. 压测前一定要备份数据，用流量染色隔离压测流量，避免污染生产环境
2. 每次压测只改变一个变量，否则无法定位性能瓶颈的根因
3. 压测持续时间至少要30分钟，稳定性测试要持续72小时，避免短时峰值的干扰
4. 一定要压测异常场景，不要只测正常场景，真实生产环境的故障永远比你想象的多
5. 压测指标不仅要看平均值，还要看P95、P99分位值，很多时候平均值正常，但P99值很高，说明系统存在长尾延迟的问题
6. 压测结束后一定要做资源清理，避免压测生成的垃圾数据占用系统资源

（全文约11200字）