1. 项目概述为什么AI智能体也需要压力测试在AI智能体AI Agent的开发浪潮中我们往往将大量精力投入到其智能决策、自然语言交互、工具调用等核心能力的构建上。然而当一个智能体从实验室的“玩具”走向真实的生产环境面对成千上万的并发用户请求、复杂多变的输入数据以及长时间稳定运行的要求时它的表现会如何这正是AI智能体压力测试需要回答的核心问题。传统的压力测试主要关注Web服务、API接口或数据库通过模拟大量并发用户来评估系统的吞吐量、响应时间和资源消耗。但AI智能体是一个更复杂的系统它通常由大语言模型LLM驱动可能涉及多轮对话、外部工具调用、长上下文处理以及向量数据库检索等环节。其性能瓶颈可能出现在LLM API的调用延迟、提示词Prompt处理的CPU开销、外部服务的依赖甚至是智能体自身的状态管理逻辑上。因此对AI智能体进行压力测试绝非简单地用JMeter或Locust发送HTTP请求那么简单它需要一套理解智能体工作流、能够模拟真实用户交互模式、并能精准度量其“智能”层面性能的专用框架。这就是agenTest框架诞生的背景。它不是一个通用的HTTP压测工具而是一个专门为AI智能体尤其是基于LLM的Agent设计的压力测试与性能评估框架。它的目标很明确帮助开发者和团队在智能体上线前系统地评估其在高压下的稳定性、可靠性、响应速度以及成本效益。通过将压力测试无缝集成到CI/CD流水线中agenTest旨在确保每一次代码提交或模型更新都不会引入潜在的性能衰退从而为智能体的规模化应用保驾护航。2. agenTest框架核心设计思路拆解agenTest的设计哲学源于对AI智能体独特架构的深刻理解。一个典型的智能体工作流可以抽象为输入用户Query - 智能体核心LLM规划/工具- 输出Action/Response。压力测试需要覆盖这个链条上的每一个环节。2.1 核心挑战与设计目标在设计agenTest时我们主要面临以下几个挑战并据此设定了设计目标工作流模拟的复杂性智能体的交互往往是多轮、有状态的。简单的请求-响应模型无法模拟真实的对话场景。agenTest需要能够定义和回放复杂的用户会话Session。外部依赖的隔离与模拟智能体频繁调用外部API如搜索引擎、数据库、工具函数。在压力测试中直接调用真实服务不可行成本高、可能触发限流。因此框架需要支持对依赖服务的Mock模拟和Stub桩。非确定性输出的度量LLM的输出具有非确定性两次相同的输入可能得到不同的回复。传统的断言Assertion在比较文本相似度时失效。agenTest需要引入基于语义相似度如余弦相似度、BLEU分数或规则如必须包含某些关键词的柔性验证机制。成本与性能的平衡直接调用付费LLM API如GPT-4进行大规模压测成本极高。框架需要支持使用更轻量、更便宜的模型如本地部署的轻量级模型或GPT-3.5-Turbo进行压力测试同时允许在关键路径上使用目标模型进行小规模验证。与CI/CD的无缝集成测试必须自动化。框架需要能够以命令行工具或库的形式运行生成标准化的测试报告如JUnit XML, HTML并方便地与Jenkins、GitHub Actions、GitLab CI等主流CI/CD平台集成。基于这些挑战agenTest的核心设计围绕“场景定义”、“负载生成”、“依赖模拟”和“度量分析”四大模块展开。2.2 架构概览agenTest采用了分层架构从上至下分别为场景层Scenario用户在此定义测试用例。一个场景包含一系列的用户输入Prompts和预期的Agent行为如调用特定工具、返回特定格式。场景可以用YAML或Python代码定义支持参数化和数据驱动。编排层Orchestrator这是框架的大脑。它负责读取场景定义按照预设的并发模型如固定用户数、爬坡模型创建虚拟用户Virtual User并管理每个虚拟用户的会话状态。执行层Executor每个虚拟用户由一个执行器驱动。执行器负责与真实的AI智能体服务通过HTTP、gRPC或SDK进行交互发送请求接收响应并记录每一步的耗时、Token使用量、费用如果可计算等指标。Mock服务层Mock Service这是一个可选的、但至关重要的组件。它拦截智能体对外部服务的调用并返回预定义的响应。这确保了压力测试的封闭性和可重复性同时避免了对外部系统的冲击。收集与分析层Collector Analyzer收集所有执行器产生的原始指标数据进行聚合分析如计算平均响应时间、95分位响应时间、吞吐量、错误率并生成可视化报告和告警。注意与传统的“每秒请求数RPS”压测不同agenTest更关注“每秒会话数SPS”或“并发用户会话数”因为一个用户会话可能包含多次LLM调用和工具调用更能反映真实用户体验。3. 核心细节解析与实操要点理解了框架的设计思路后我们深入其核心模块看看如何具体使用agenTest来构建一个有效的压力测试。3.1 场景定义用YAML描述用户行为场景定义是测试的蓝图。agenTest推荐使用YAML来定义因为它结构清晰易于理解和版本控制。# 示例一个电商客服智能体的压力测试场景 name: “E-commerce_Customer_Service_Stress_Test” description: “模拟用户咨询订单状态、产品信息和发起退货的混合场景。” concurrency: 100 # 并发虚拟用户数 ramp_up: 30s # 在30秒内逐步启动所有用户 duration: 5m # 测试持续5分钟 # 定义虚拟用户的行为流 user_flow: - name: “login_and_query” think_time: “1-3s” # 用户思考时间模拟真实间隔 actions: - type: “llm” prompt: “我昨天的订单 #{{order_id}} 发货了吗” validation: - type: “contains” # 验证响应中必须包含“物流”或“发货”关键词 value: [“物流”, “发货”] - type: “similarity” # 语义相似度需大于0.7 threshold: 0.7 expected: “您的订单已发货物流信息如下” - type: “tool” name: “query_order” parameters: order_id: “{{order_id}}” mock_response: # 模拟工具返回 status: “shipped” tracking_number: “SF123456789” - name: “product_qa” probability: 0.6 # 60%的用户会执行此步骤 actions: - type: “llm” prompt: “{{product_name}} 有货吗什么时候能到” validation: - type: “regex” pattern: “有货|库存|预计.*送达” # 测试数据池 data_pools: order_ids: [“ORD1001”, “ORD1002”, …, “ORD1100”] # 100个订单号 product_names: [“智能手机X”, “无线耳机Y”, “笔记本电脑Z”]关键解析参数化{{variable}}这是实现真实负载的关键。通过从data_pools中随机或顺序选取数据确保每个虚拟用户的会话内容不同避免因缓存带来的性能假象。验证Validation这是确保智能体“智能”行为正确的核心。contains、regex用于简单验证similarity则使用嵌入模型计算响应与预期文本的余弦相似度更适用于开放域问答。Mock响应对于tool类型的动作直接指定mock_response。在实际压测时agenTest的Mock服务层会拦截对query_order的调用并返回此JSON而不会真正查询数据库。3.2 负载生成模型模拟真实用户agenTest支持多种负载模型以适应不同的测试目的固定并发用户数Constant Users如上例启动固定数量的用户并持续运行一段时间。适用于容量规划和稳定性测试。爬坡模型Ramp-up用户数随时间线性或阶梯式增加。用于找到系统的性能拐点或最大承载能力。峰值模型Peak Load在短时间内注入大量用户模拟促销、热点事件时的流量冲击。自定义模型通过编写脚本可以定义更复杂的用户到达率如泊松分布以模拟更真实的流量模式。实操心得对于AI智能体建议从爬坡模型开始。因为LLM API通常有速率限制RPM/TPM突然的高并发会导致大量429请求过多错误使测试结果失真。逐步增加负载有助于观察系统在逼近限流阈值时的表现。3.3 依赖模拟Mock策略Mock是压力测试的“安全气囊”。agenTest的Mock服务通常以一个独立的HTTP服务器形式运行。配置Mock规则在场景文件或单独配置中声明需要Mock的端点及其响应。mock_services: - name: “product_database” url_pattern: “/api/product/*” # 匹配所有产品查询API response: static: # 静态响应 status: 200 body: ‘{“in_stock”: true, “delivery_days”: 3}’ dynamic: # 动态响应通过JS/Python脚本生成 script: “mock_scripts/product_info.js”智能体侧的适配在测试环境中你需要将智能体配置中调用外部服务的URL指向Mock服务器的地址。这通常通过环境变量来实现。export EXTERNAL_API_BASE_URL“http://localhost:8080/mock” python your_agent_server.py注意事项Mock响应应尽可能真实包括响应延迟。你可以在Mock规则中设置delay: “50-200ms”来模拟网络延迟和下游服务处理时间这样压测结果更能反映智能体在真实链路中的性能。3.4 核心指标与度量agenTest收集的指标远超简单的HTTP状态码和延迟。以下是一些关键指标指标类别具体指标说明性能指标平均响应时间、P95/P99响应时间衡量智能体处理单个用户请求可能包含多轮的速度。每秒完成会话数SPS核心吞吐量指标。每秒Token消耗量直接关联成本。资源指标CPU/内存使用率如果智能体是本地部署的需要监控其宿主机的资源。LLM API调用耗时拆解出LLM调用在总耗时中的占比这是主要的性能瓶颈点。质量指标会话成功率完整走完一个用户流程且所有验证通过的会话比例。工具调用失败率Mock环境下应接近0若不为0则可能是智能体逻辑错误。语义相似度平均分衡量智能体回答准确性的量化指标。成本指标预估费用根据Token使用量和模型单价估算单次会话或总测试成本。经验之谈P95/P99响应时间比平均响应时间更有价值。它告诉你绝大多数用户95%或99%的体验能发现长尾问题。例如平均响应时间2秒可能看起来不错但P99响应时间10秒意味着有1%的用户经历了难以忍受的卡顿。4. 实战从零构建一个智能体的压力测试假设我们有一个基于LangChain构建的、用于分析金融新闻的智能体FinNewsAnalyst。它接收用户关于某只股票的问题然后调用工具1) 获取最新新闻2) 从新闻中提取关键信息3) 生成分析报告。现在我们要用agenTest对其进行压力测试。4.1 环境准备与框架安装首先安装agenTest。它通常是一个Python包。pip install agentest # 或者从源码安装 git clone https://github.com/your-org/agentest.git cd agentest pip install -e .准备你的智能体服务。确保它可以通过一个明确的API端点例如http://localhost:8000/chat接受请求并返回结构化的响应包含LLM回复和工具调用记录。4.2 编写测试场景文件创建一个名为stress_fin_news.yaml的场景文件。config: agent_endpoint: “http://localhost:8000/chat” output_dir: “./results/stress_test_{{timestamp}}” scenario: name: “FinNews Analyst Load Test” concurrency: 50 ramp_up: 60s duration: 10m user_flow: - name: “single_stock_query” think_time: “2-5s” actions: - type: “llm” prompt: “请分析一下 {{stock}} 最近的表现并给出未来一周的展望。” validation: - type: “contains_any” value: [“上涨”, “下跌”, “震荡”, “建议”, “风险”] - type: “cost” max_input_tokens: 1000 # 验证输入token不超过限制 max_output_tokens: 500 data_pools: stocks: [“AAPL”, “GOOGL”, “MSFT”, “TSLA”, “NVDA”, “AMZN”, “META”, “NFLX”] mock_services: - name: “news_fetcher” url_pattern: “/api/fetch_news/*” response: static: status: 200 body: ‘{ “articles”: [ {“title”: “{{stock}} 季度财报超预期”, “summary”: “公司营收同比增长20%...”}, {“title”: “行业政策利好 {{stock}}”, “summary”: “新政策预计将推动板块上涨...”} ] }’ delay: “100ms” # 模拟新闻API的延迟4.3 运行压力测试通过命令行启动测试。agenTest会先启动Mock服务如果配置了的话然后根据场景文件发起负载。# 运行测试并实时输出日志 agentest run --scenario stress_fin_news.yaml # 在后台运行并将指标输出到InfluxDB/Prometheus可选 agentest run --scenario stress_fin_news.yaml --metrics-backend prometheus://localhost:9090在测试运行期间你可以通过agenTest提供的简易仪表盘或直接查询时序数据库来观察实时指标。4.4 分析测试报告测试结束后agenTest会在指定的output_dir中生成报告。最重要的两个文件是summary_report.html一个交互式的HTML报告包含所有关键指标的图表响应时间分布、吞吐量曲线、成功率趋势等。junit_report.xml标准的JUnit格式报告包含了每个测试用例虚拟用户会话的成功/失败状态。这是CI/CD集成的基础。打开HTML报告你可能会发现响应时间随并发数上升而线性增长这可能表明你的智能体服务是计算密集型或者LLM API的并发处理能力是瓶颈。在并发40左右错误率陡增这可能触发了LLM API的速率限制或者你的服务出现了资源如内存不足。工具调用耗时占比很小这说明性能瓶颈主要在LLM推理环节优化重点应放在提示词工程或考虑使用更快的模型。踩坑记录在一次测试中我们发现P99响应时间异常的高。通过查看失败会话的详细日志发现是少数几个会话中的新闻查询工具调用超时被Mock服务模拟了。原因是我们在Mock规则中设置的延迟是固定的100ms但真实场景下该API的P99延迟可能达到2秒。于是我们将Mock延迟改为“50-2000ms”的随机分布重新测试后得到了更符合实际情况的响应时间分布。5. 集成到CI/CD流水线让性能守护自动化将agenTest集成到CI/CD中是实现“持续性能测试”的关键。目标是每次代码合并请求Pull Request或定时任务都自动运行一组核心的压力测试确保性能基线不被突破。5.1 基础集成GitHub Actions示例以下是一个GitHub Actions工作流的示例它在每次推送到主分支或发起PR时运行一组冒烟测试和轻量级压力测试。# .github/workflows/agent-stress-test.yml name: AI Agent Stress Test on: push: branches: [ main ] pull_request: branches: [ main ] jobs: stress-test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - name: Set up Python uses: actions/setup-pythonv4 with: python-version: ‘3.10’ - name: Install dependencies run: | pip install -r requirements.txt pip install agentest - name: Start Agent Service run: | # 启动你的智能体服务例如使用Uvicorn uvicorn your_agent_app:app --host 0.0.0.0 --port 8000 sleep 10 # 等待服务启动 - name: Run Smoke Test run: | # 先运行一个快速的冒烟测试验证基本功能 agentest run --scenario ./tests/smoke_test.yaml --output ./results/smoke - name: Run Light Stress Test if: github.event_name ‘pull_request’ # PR时运行轻量压测 run: | # 轻量压测10个用户运行1分钟 agentest run --scenario ./tests/light_stress.yaml \ --output ./results/light_stress \ --fail-on-error-rate 0.05 # 如果错误率5%则步骤失败 - name: Run Full Stress Test (Nightly) if: github.event_name ‘push’ github.ref ‘refs/heads/main’ run: | # 仅在主分支推送时如每日夜间构建运行完整压测 agentest run --scenario ./tests/full_stress.yaml \ --output ./results/full_stress \ --duration 5m - name: Upload Test Reports uses: actions/upload-artifactv3 if: always() # 即使测试失败也上传报告 with: name: agent-stress-reports path: results/5.2 设置性能基线与质量门禁单纯的运行测试不够我们需要定义“通过”的标准。这就是性能基线Performance Baseline和质量门禁Quality Gate。建立基线在项目性能稳定的一个版本上运行完整的压力测试将关键指标如P95响应时间 3秒会话成功率 99.5%的结果保存为基线文件如performance_baseline.json。门禁规则在CI流水线中agenTest运行结束后会自动将本次结果与基线进行比较。agentest compare --current ./results/full_stress/metrics.json \ --baseline ./performance_baseline.json \ --rules ./performance_rules.yamlperformance_rules.yaml示例rules: - metric: “p95_response_time_seconds” operator: “” baseline_value: 3.0 threshold: “10%” # 允许比基线恶化不超过10% action: “warn” # 超过阈值则警告但不会失败 - metric: “session_success_rate” operator: “” baseline_value: 0.995 threshold: “-0.5%” # 成功率不得低于基线的0.5% action: “fail” # 低于阈值则使CI步骤失败 - metric: “avg_token_cost_per_session” operator: “” baseline_value: 0.02 # 平均每次会话成本2美分 threshold: “20%” # 成本上涨不超过20% action: “fail”集成效果当有PR试图合并一个可能降低性能的修改例如引入了一个更复杂但更耗时的提示词模板时轻量级压力测试会触发并与基线比较。如果P95响应时间恶化了15%超过了“警告”阈值CI会显示警告。如果成功率跌破了失败阈值CI会直接失败阻止合并。这迫使开发者在早期就关注性能影响。5.3 进阶与监控和告警平台集成CI/CD流水线中的测试是主动的、离散的。我们还需要被动的、持续的监控。agenTest可以与监控系统如PrometheusGrafana集成。导出指标在运行长期稳定性测试如12小时浸泡测试时将agenTest的实时指标导出到Prometheus。制作仪表盘在Grafana中创建仪表盘可视化智能体的关键性能指标KPI如实时SPS、错误率、响应时间分位图。设置告警当生产环境的监控指标可通过在预发环境定期运行agenTest来模拟接近性能基线阈值时触发告警如发送到Slack或PagerDuty让运维团队提前干预。6. 常见问题与排查技巧实录在实际使用agenTest的过程中你肯定会遇到各种问题。以下是一些典型问题及其排查思路。6.1 测试结果不稳定波动很大可能原因1外部依赖如LLM API不稳定。排查查看agenTest日志中LLM调用的单独耗时指标。如果其P99延迟波动剧烈问题很可能在云端API。解决在测试中使用LLM API的Mock。或者在测试配置中增加重试机制和更长的超时时间。可能原因2测试环境资源争抢。排查监控运行agenTest和智能体服务的机器CPU、内存、网络IO。如果压测期间CPU持续100%说明环境是瓶颈。解决将agenTest负载生成器、Mock服务和被测智能体服务部署在不同的机器上避免资源竞争。可能原因3智能体服务有内存泄漏或状态累积。排查观察随着测试时间推移智能体服务的内存占用是否持续增长。长时间运行的“浸泡测试”更容易发现此类问题。解决检查智能体代码确保会话状态被正确清理没有全局变量的不当累积。6.2 错误率很高但智能体本地测试正常可能原因1并发触发了限流。现象错误日志中大量出现“429 Too Many Requests”或“Rate Limit Exceeded”。解决降低测试的并发用户数concurrency或增加think_time来降低请求频率。确认并调整LLM服务商的速率限制设置。可能原因2Mock服务响应与智能体预期不符。现象错误集中在工具调用步骤提示“解析响应失败”或“意外的数据格式”。排查对比Mock服务返回的数据与智能体代码中预期的数据结构。确保字段名、类型完全一致。解决完善Mock规则使其返回更完整、更符合契约的数据。可以使用真实的API响应样本作为Mock数据源。可能原因3验证规则过于严格。现象会话因“验证失败”而错误但人工检查LLM的回答似乎合理。解决调整验证策略。对于开放性回答使用语义相似度验证并设置合理的阈值如0.6而非精确的关键词匹配。或者将验证重点放在结构化输出如要求智能体返回JSON的字段完整性上而非自然语言的字面内容。6.3 CI/CD流水线中测试耗时太长优化策略1分层测试。做法将测试套件分为快速测试冒烟测试1分钟、集成测试中等负载2-5分钟和全面测试高负载10分钟以上。PR触发快速和集成测试只有夜间构建或发版前才运行全面测试。优化策略2使用测试切片和并行化。做法agenTest支持将场景按data_pools或user_flow切片。在CI中可以启动多个Job并行运行不同的测试切片最后合并报告。GitHub Actions示例jobs: stress-test-slice: strategy: matrix: slice: [0, 1, 2, 3] # 启动4个并行任务 runs-on: ubuntu-latest steps: - run: | agentest run --scenario ./tests/stress.yaml \ --slice ${{ matrix.slice }} \ --total-slices 4优化策略3利用缓存和预构建环境。做法在CI中缓存Python虚拟环境、Docker镜像。如果智能体服务是容器化的可以预先构建好测试镜像避免每次CI都从头构建。6.4 如何为无状态和有状态智能体设计测试这是一个关键区别。无状态智能体每次请求独立不依赖之前对话历史。测试设计最简单直接模拟并发请求即可。注意即使智能体本身无状态如果它使用了向量数据库有缓存也可能因高并发查询导致性能问题。有状态智能体多轮对话这是主要挑战。agenTest的user_flow和会话状态管理就是为了解决这个。设计要点在场景中一个user_flow代表一个完整的多轮对话。agenTest会为每个虚拟用户维护一个独立的会话上下文如Conversation ID并在后续请求中自动携带。压力点不仅要测试单轮响应更要测试在长时间对话后智能体的上下文管理能力如是否正确处理了长上下文窗口的裁剪以及内存占用是否会持续增长。最后我想分享一个个人体会对AI智能体进行压力测试初期最大的障碍往往不是工具而是思维转变。我们需要从“它能不能工作”的定性思维转向“它在多少人同时使用时能以多快的速度、多高的成功率、多低的成本工作”的定量思维。agenTest这样的框架提供了实践的路径但真正的价值来自于团队将性能和质量视为与功能同等重要的、需要持续测量和守护的核心属性。当你把压力测试报告像单元测试覆盖率一样贴在PR里讨论时高质量、高可用的AI智能体应用就离你不远了。
AI智能体压力测试实战：从原理到CI/CD集成的全链路指南
发布时间：2026/7/2 5:20:50
1. 项目概述为什么AI智能体也需要压力测试在AI智能体AI Agent的开发浪潮中我们往往将大量精力投入到其智能决策、自然语言交互、工具调用等核心能力的构建上。然而当一个智能体从实验室的“玩具”走向真实的生产环境面对成千上万的并发用户请求、复杂多变的输入数据以及长时间稳定运行的要求时它的表现会如何这正是AI智能体压力测试需要回答的核心问题。传统的压力测试主要关注Web服务、API接口或数据库通过模拟大量并发用户来评估系统的吞吐量、响应时间和资源消耗。但AI智能体是一个更复杂的系统它通常由大语言模型LLM驱动可能涉及多轮对话、外部工具调用、长上下文处理以及向量数据库检索等环节。其性能瓶颈可能出现在LLM API的调用延迟、提示词Prompt处理的CPU开销、外部服务的依赖甚至是智能体自身的状态管理逻辑上。因此对AI智能体进行压力测试绝非简单地用JMeter或Locust发送HTTP请求那么简单它需要一套理解智能体工作流、能够模拟真实用户交互模式、并能精准度量其“智能”层面性能的专用框架。这就是agenTest框架诞生的背景。它不是一个通用的HTTP压测工具而是一个专门为AI智能体尤其是基于LLM的Agent设计的压力测试与性能评估框架。它的目标很明确帮助开发者和团队在智能体上线前系统地评估其在高压下的稳定性、可靠性、响应速度以及成本效益。通过将压力测试无缝集成到CI/CD流水线中agenTest旨在确保每一次代码提交或模型更新都不会引入潜在的性能衰退从而为智能体的规模化应用保驾护航。2. agenTest框架核心设计思路拆解agenTest的设计哲学源于对AI智能体独特架构的深刻理解。一个典型的智能体工作流可以抽象为输入用户Query - 智能体核心LLM规划/工具- 输出Action/Response。压力测试需要覆盖这个链条上的每一个环节。2.1 核心挑战与设计目标在设计agenTest时我们主要面临以下几个挑战并据此设定了设计目标工作流模拟的复杂性智能体的交互往往是多轮、有状态的。简单的请求-响应模型无法模拟真实的对话场景。agenTest需要能够定义和回放复杂的用户会话Session。外部依赖的隔离与模拟智能体频繁调用外部API如搜索引擎、数据库、工具函数。在压力测试中直接调用真实服务不可行成本高、可能触发限流。因此框架需要支持对依赖服务的Mock模拟和Stub桩。非确定性输出的度量LLM的输出具有非确定性两次相同的输入可能得到不同的回复。传统的断言Assertion在比较文本相似度时失效。agenTest需要引入基于语义相似度如余弦相似度、BLEU分数或规则如必须包含某些关键词的柔性验证机制。成本与性能的平衡直接调用付费LLM API如GPT-4进行大规模压测成本极高。框架需要支持使用更轻量、更便宜的模型如本地部署的轻量级模型或GPT-3.5-Turbo进行压力测试同时允许在关键路径上使用目标模型进行小规模验证。与CI/CD的无缝集成测试必须自动化。框架需要能够以命令行工具或库的形式运行生成标准化的测试报告如JUnit XML, HTML并方便地与Jenkins、GitHub Actions、GitLab CI等主流CI/CD平台集成。基于这些挑战agenTest的核心设计围绕“场景定义”、“负载生成”、“依赖模拟”和“度量分析”四大模块展开。2.2 架构概览agenTest采用了分层架构从上至下分别为场景层Scenario用户在此定义测试用例。一个场景包含一系列的用户输入Prompts和预期的Agent行为如调用特定工具、返回特定格式。场景可以用YAML或Python代码定义支持参数化和数据驱动。编排层Orchestrator这是框架的大脑。它负责读取场景定义按照预设的并发模型如固定用户数、爬坡模型创建虚拟用户Virtual User并管理每个虚拟用户的会话状态。执行层Executor每个虚拟用户由一个执行器驱动。执行器负责与真实的AI智能体服务通过HTTP、gRPC或SDK进行交互发送请求接收响应并记录每一步的耗时、Token使用量、费用如果可计算等指标。Mock服务层Mock Service这是一个可选的、但至关重要的组件。它拦截智能体对外部服务的调用并返回预定义的响应。这确保了压力测试的封闭性和可重复性同时避免了对外部系统的冲击。收集与分析层Collector Analyzer收集所有执行器产生的原始指标数据进行聚合分析如计算平均响应时间、95分位响应时间、吞吐量、错误率并生成可视化报告和告警。注意与传统的“每秒请求数RPS”压测不同agenTest更关注“每秒会话数SPS”或“并发用户会话数”因为一个用户会话可能包含多次LLM调用和工具调用更能反映真实用户体验。3. 核心细节解析与实操要点理解了框架的设计思路后我们深入其核心模块看看如何具体使用agenTest来构建一个有效的压力测试。3.1 场景定义用YAML描述用户行为场景定义是测试的蓝图。agenTest推荐使用YAML来定义因为它结构清晰易于理解和版本控制。# 示例一个电商客服智能体的压力测试场景 name: “E-commerce_Customer_Service_Stress_Test” description: “模拟用户咨询订单状态、产品信息和发起退货的混合场景。” concurrency: 100 # 并发虚拟用户数 ramp_up: 30s # 在30秒内逐步启动所有用户 duration: 5m # 测试持续5分钟 # 定义虚拟用户的行为流 user_flow: - name: “login_and_query” think_time: “1-3s” # 用户思考时间模拟真实间隔 actions: - type: “llm” prompt: “我昨天的订单 #{{order_id}} 发货了吗” validation: - type: “contains” # 验证响应中必须包含“物流”或“发货”关键词 value: [“物流”, “发货”] - type: “similarity” # 语义相似度需大于0.7 threshold: 0.7 expected: “您的订单已发货物流信息如下” - type: “tool” name: “query_order” parameters: order_id: “{{order_id}}” mock_response: # 模拟工具返回 status: “shipped” tracking_number: “SF123456789” - name: “product_qa” probability: 0.6 # 60%的用户会执行此步骤 actions: - type: “llm” prompt: “{{product_name}} 有货吗什么时候能到” validation: - type: “regex” pattern: “有货|库存|预计.*送达” # 测试数据池 data_pools: order_ids: [“ORD1001”, “ORD1002”, …, “ORD1100”] # 100个订单号 product_names: [“智能手机X”, “无线耳机Y”, “笔记本电脑Z”]关键解析参数化{{variable}}这是实现真实负载的关键。通过从data_pools中随机或顺序选取数据确保每个虚拟用户的会话内容不同避免因缓存带来的性能假象。验证Validation这是确保智能体“智能”行为正确的核心。contains、regex用于简单验证similarity则使用嵌入模型计算响应与预期文本的余弦相似度更适用于开放域问答。Mock响应对于tool类型的动作直接指定mock_response。在实际压测时agenTest的Mock服务层会拦截对query_order的调用并返回此JSON而不会真正查询数据库。3.2 负载生成模型模拟真实用户agenTest支持多种负载模型以适应不同的测试目的固定并发用户数Constant Users如上例启动固定数量的用户并持续运行一段时间。适用于容量规划和稳定性测试。爬坡模型Ramp-up用户数随时间线性或阶梯式增加。用于找到系统的性能拐点或最大承载能力。峰值模型Peak Load在短时间内注入大量用户模拟促销、热点事件时的流量冲击。自定义模型通过编写脚本可以定义更复杂的用户到达率如泊松分布以模拟更真实的流量模式。实操心得对于AI智能体建议从爬坡模型开始。因为LLM API通常有速率限制RPM/TPM突然的高并发会导致大量429请求过多错误使测试结果失真。逐步增加负载有助于观察系统在逼近限流阈值时的表现。3.3 依赖模拟Mock策略Mock是压力测试的“安全气囊”。agenTest的Mock服务通常以一个独立的HTTP服务器形式运行。配置Mock规则在场景文件或单独配置中声明需要Mock的端点及其响应。mock_services: - name: “product_database” url_pattern: “/api/product/*” # 匹配所有产品查询API response: static: # 静态响应 status: 200 body: ‘{“in_stock”: true, “delivery_days”: 3}’ dynamic: # 动态响应通过JS/Python脚本生成 script: “mock_scripts/product_info.js”智能体侧的适配在测试环境中你需要将智能体配置中调用外部服务的URL指向Mock服务器的地址。这通常通过环境变量来实现。export EXTERNAL_API_BASE_URL“http://localhost:8080/mock” python your_agent_server.py注意事项Mock响应应尽可能真实包括响应延迟。你可以在Mock规则中设置delay: “50-200ms”来模拟网络延迟和下游服务处理时间这样压测结果更能反映智能体在真实链路中的性能。3.4 核心指标与度量agenTest收集的指标远超简单的HTTP状态码和延迟。以下是一些关键指标指标类别具体指标说明性能指标平均响应时间、P95/P99响应时间衡量智能体处理单个用户请求可能包含多轮的速度。每秒完成会话数SPS核心吞吐量指标。每秒Token消耗量直接关联成本。资源指标CPU/内存使用率如果智能体是本地部署的需要监控其宿主机的资源。LLM API调用耗时拆解出LLM调用在总耗时中的占比这是主要的性能瓶颈点。质量指标会话成功率完整走完一个用户流程且所有验证通过的会话比例。工具调用失败率Mock环境下应接近0若不为0则可能是智能体逻辑错误。语义相似度平均分衡量智能体回答准确性的量化指标。成本指标预估费用根据Token使用量和模型单价估算单次会话或总测试成本。经验之谈P95/P99响应时间比平均响应时间更有价值。它告诉你绝大多数用户95%或99%的体验能发现长尾问题。例如平均响应时间2秒可能看起来不错但P99响应时间10秒意味着有1%的用户经历了难以忍受的卡顿。4. 实战从零构建一个智能体的压力测试假设我们有一个基于LangChain构建的、用于分析金融新闻的智能体FinNewsAnalyst。它接收用户关于某只股票的问题然后调用工具1) 获取最新新闻2) 从新闻中提取关键信息3) 生成分析报告。现在我们要用agenTest对其进行压力测试。4.1 环境准备与框架安装首先安装agenTest。它通常是一个Python包。pip install agentest # 或者从源码安装 git clone https://github.com/your-org/agentest.git cd agentest pip install -e .准备你的智能体服务。确保它可以通过一个明确的API端点例如http://localhost:8000/chat接受请求并返回结构化的响应包含LLM回复和工具调用记录。4.2 编写测试场景文件创建一个名为stress_fin_news.yaml的场景文件。config: agent_endpoint: “http://localhost:8000/chat” output_dir: “./results/stress_test_{{timestamp}}” scenario: name: “FinNews Analyst Load Test” concurrency: 50 ramp_up: 60s duration: 10m user_flow: - name: “single_stock_query” think_time: “2-5s” actions: - type: “llm” prompt: “请分析一下 {{stock}} 最近的表现并给出未来一周的展望。” validation: - type: “contains_any” value: [“上涨”, “下跌”, “震荡”, “建议”, “风险”] - type: “cost” max_input_tokens: 1000 # 验证输入token不超过限制 max_output_tokens: 500 data_pools: stocks: [“AAPL”, “GOOGL”, “MSFT”, “TSLA”, “NVDA”, “AMZN”, “META”, “NFLX”] mock_services: - name: “news_fetcher” url_pattern: “/api/fetch_news/*” response: static: status: 200 body: ‘{ “articles”: [ {“title”: “{{stock}} 季度财报超预期”, “summary”: “公司营收同比增长20%...”}, {“title”: “行业政策利好 {{stock}}”, “summary”: “新政策预计将推动板块上涨...”} ] }’ delay: “100ms” # 模拟新闻API的延迟4.3 运行压力测试通过命令行启动测试。agenTest会先启动Mock服务如果配置了的话然后根据场景文件发起负载。# 运行测试并实时输出日志 agentest run --scenario stress_fin_news.yaml # 在后台运行并将指标输出到InfluxDB/Prometheus可选 agentest run --scenario stress_fin_news.yaml --metrics-backend prometheus://localhost:9090在测试运行期间你可以通过agenTest提供的简易仪表盘或直接查询时序数据库来观察实时指标。4.4 分析测试报告测试结束后agenTest会在指定的output_dir中生成报告。最重要的两个文件是summary_report.html一个交互式的HTML报告包含所有关键指标的图表响应时间分布、吞吐量曲线、成功率趋势等。junit_report.xml标准的JUnit格式报告包含了每个测试用例虚拟用户会话的成功/失败状态。这是CI/CD集成的基础。打开HTML报告你可能会发现响应时间随并发数上升而线性增长这可能表明你的智能体服务是计算密集型或者LLM API的并发处理能力是瓶颈。在并发40左右错误率陡增这可能触发了LLM API的速率限制或者你的服务出现了资源如内存不足。工具调用耗时占比很小这说明性能瓶颈主要在LLM推理环节优化重点应放在提示词工程或考虑使用更快的模型。踩坑记录在一次测试中我们发现P99响应时间异常的高。通过查看失败会话的详细日志发现是少数几个会话中的新闻查询工具调用超时被Mock服务模拟了。原因是我们在Mock规则中设置的延迟是固定的100ms但真实场景下该API的P99延迟可能达到2秒。于是我们将Mock延迟改为“50-2000ms”的随机分布重新测试后得到了更符合实际情况的响应时间分布。5. 集成到CI/CD流水线让性能守护自动化将agenTest集成到CI/CD中是实现“持续性能测试”的关键。目标是每次代码合并请求Pull Request或定时任务都自动运行一组核心的压力测试确保性能基线不被突破。5.1 基础集成GitHub Actions示例以下是一个GitHub Actions工作流的示例它在每次推送到主分支或发起PR时运行一组冒烟测试和轻量级压力测试。# .github/workflows/agent-stress-test.yml name: AI Agent Stress Test on: push: branches: [ main ] pull_request: branches: [ main ] jobs: stress-test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - name: Set up Python uses: actions/setup-pythonv4 with: python-version: ‘3.10’ - name: Install dependencies run: | pip install -r requirements.txt pip install agentest - name: Start Agent Service run: | # 启动你的智能体服务例如使用Uvicorn uvicorn your_agent_app:app --host 0.0.0.0 --port 8000 sleep 10 # 等待服务启动 - name: Run Smoke Test run: | # 先运行一个快速的冒烟测试验证基本功能 agentest run --scenario ./tests/smoke_test.yaml --output ./results/smoke - name: Run Light Stress Test if: github.event_name ‘pull_request’ # PR时运行轻量压测 run: | # 轻量压测10个用户运行1分钟 agentest run --scenario ./tests/light_stress.yaml \ --output ./results/light_stress \ --fail-on-error-rate 0.05 # 如果错误率5%则步骤失败 - name: Run Full Stress Test (Nightly) if: github.event_name ‘push’ github.ref ‘refs/heads/main’ run: | # 仅在主分支推送时如每日夜间构建运行完整压测 agentest run --scenario ./tests/full_stress.yaml \ --output ./results/full_stress \ --duration 5m - name: Upload Test Reports uses: actions/upload-artifactv3 if: always() # 即使测试失败也上传报告 with: name: agent-stress-reports path: results/5.2 设置性能基线与质量门禁单纯的运行测试不够我们需要定义“通过”的标准。这就是性能基线Performance Baseline和质量门禁Quality Gate。建立基线在项目性能稳定的一个版本上运行完整的压力测试将关键指标如P95响应时间 3秒会话成功率 99.5%的结果保存为基线文件如performance_baseline.json。门禁规则在CI流水线中agenTest运行结束后会自动将本次结果与基线进行比较。agentest compare --current ./results/full_stress/metrics.json \ --baseline ./performance_baseline.json \ --rules ./performance_rules.yamlperformance_rules.yaml示例rules: - metric: “p95_response_time_seconds” operator: “” baseline_value: 3.0 threshold: “10%” # 允许比基线恶化不超过10% action: “warn” # 超过阈值则警告但不会失败 - metric: “session_success_rate” operator: “” baseline_value: 0.995 threshold: “-0.5%” # 成功率不得低于基线的0.5% action: “fail” # 低于阈值则使CI步骤失败 - metric: “avg_token_cost_per_session” operator: “” baseline_value: 0.02 # 平均每次会话成本2美分 threshold: “20%” # 成本上涨不超过20% action: “fail”集成效果当有PR试图合并一个可能降低性能的修改例如引入了一个更复杂但更耗时的提示词模板时轻量级压力测试会触发并与基线比较。如果P95响应时间恶化了15%超过了“警告”阈值CI会显示警告。如果成功率跌破了失败阈值CI会直接失败阻止合并。这迫使开发者在早期就关注性能影响。5.3 进阶与监控和告警平台集成CI/CD流水线中的测试是主动的、离散的。我们还需要被动的、持续的监控。agenTest可以与监控系统如PrometheusGrafana集成。导出指标在运行长期稳定性测试如12小时浸泡测试时将agenTest的实时指标导出到Prometheus。制作仪表盘在Grafana中创建仪表盘可视化智能体的关键性能指标KPI如实时SPS、错误率、响应时间分位图。设置告警当生产环境的监控指标可通过在预发环境定期运行agenTest来模拟接近性能基线阈值时触发告警如发送到Slack或PagerDuty让运维团队提前干预。6. 常见问题与排查技巧实录在实际使用agenTest的过程中你肯定会遇到各种问题。以下是一些典型问题及其排查思路。6.1 测试结果不稳定波动很大可能原因1外部依赖如LLM API不稳定。排查查看agenTest日志中LLM调用的单独耗时指标。如果其P99延迟波动剧烈问题很可能在云端API。解决在测试中使用LLM API的Mock。或者在测试配置中增加重试机制和更长的超时时间。可能原因2测试环境资源争抢。排查监控运行agenTest和智能体服务的机器CPU、内存、网络IO。如果压测期间CPU持续100%说明环境是瓶颈。解决将agenTest负载生成器、Mock服务和被测智能体服务部署在不同的机器上避免资源竞争。可能原因3智能体服务有内存泄漏或状态累积。排查观察随着测试时间推移智能体服务的内存占用是否持续增长。长时间运行的“浸泡测试”更容易发现此类问题。解决检查智能体代码确保会话状态被正确清理没有全局变量的不当累积。6.2 错误率很高但智能体本地测试正常可能原因1并发触发了限流。现象错误日志中大量出现“429 Too Many Requests”或“Rate Limit Exceeded”。解决降低测试的并发用户数concurrency或增加think_time来降低请求频率。确认并调整LLM服务商的速率限制设置。可能原因2Mock服务响应与智能体预期不符。现象错误集中在工具调用步骤提示“解析响应失败”或“意外的数据格式”。排查对比Mock服务返回的数据与智能体代码中预期的数据结构。确保字段名、类型完全一致。解决完善Mock规则使其返回更完整、更符合契约的数据。可以使用真实的API响应样本作为Mock数据源。可能原因3验证规则过于严格。现象会话因“验证失败”而错误但人工检查LLM的回答似乎合理。解决调整验证策略。对于开放性回答使用语义相似度验证并设置合理的阈值如0.6而非精确的关键词匹配。或者将验证重点放在结构化输出如要求智能体返回JSON的字段完整性上而非自然语言的字面内容。6.3 CI/CD流水线中测试耗时太长优化策略1分层测试。做法将测试套件分为快速测试冒烟测试1分钟、集成测试中等负载2-5分钟和全面测试高负载10分钟以上。PR触发快速和集成测试只有夜间构建或发版前才运行全面测试。优化策略2使用测试切片和并行化。做法agenTest支持将场景按data_pools或user_flow切片。在CI中可以启动多个Job并行运行不同的测试切片最后合并报告。GitHub Actions示例jobs: stress-test-slice: strategy: matrix: slice: [0, 1, 2, 3] # 启动4个并行任务 runs-on: ubuntu-latest steps: - run: | agentest run --scenario ./tests/stress.yaml \ --slice ${{ matrix.slice }} \ --total-slices 4优化策略3利用缓存和预构建环境。做法在CI中缓存Python虚拟环境、Docker镜像。如果智能体服务是容器化的可以预先构建好测试镜像避免每次CI都从头构建。6.4 如何为无状态和有状态智能体设计测试这是一个关键区别。无状态智能体每次请求独立不依赖之前对话历史。测试设计最简单直接模拟并发请求即可。注意即使智能体本身无状态如果它使用了向量数据库有缓存也可能因高并发查询导致性能问题。有状态智能体多轮对话这是主要挑战。agenTest的user_flow和会话状态管理就是为了解决这个。设计要点在场景中一个user_flow代表一个完整的多轮对话。agenTest会为每个虚拟用户维护一个独立的会话上下文如Conversation ID并在后续请求中自动携带。压力点不仅要测试单轮响应更要测试在长时间对话后智能体的上下文管理能力如是否正确处理了长上下文窗口的裁剪以及内存占用是否会持续增长。最后我想分享一个个人体会对AI智能体进行压力测试初期最大的障碍往往不是工具而是思维转变。我们需要从“它能不能工作”的定性思维转向“它在多少人同时使用时能以多快的速度、多高的成功率、多低的成本工作”的定量思维。agenTest这样的框架提供了实践的路径但真正的价值来自于团队将性能和质量视为与功能同等重要的、需要持续测量和守护的核心属性。当你把压力测试报告像单元测试覆盖率一样贴在PR里讨论时高质量、高可用的AI智能体应用就离你不远了。
相关文章
●从零理解 DSI 屏幕撕裂：一条数据流水线的故事
1. 整个系统在干什么 你的板子在做一件事：把 HDMI 输入的画面缩小后，显示在一块 MIPI DSI 小屏幕上。 数据流是这样的： HDMI 源（笔记本） → rk628 芯片 → DSI 面板 720720 （缩小到&…
计算机毕业设计之基于一体化运营管理的电商ERP系统
在Internet高速发展的今天，我们生活的各个领域都涉及到计算机的应用，其中包括一体化运营管理的电商ERP系统的网络应用，在外国电商ERP已经是很普遍的方式，不过国内的电商ERP可能还处于起步阶段。一体化运营管理的电商ERP系统具有进…
转移癌原发灶难定？CK7/20 组合拳精准锁定“元凶”
转移癌原发灶难定？CK7/20 组合拳精准锁定“元凶”在病理科的日常工作中，最让人头疼的莫过于面对一张转移性腺癌的切片，却对它的“老家”一无所知。原发灶不明的转移癌（CUP）不仅让临床医生在制定治疗方案时束手无策&…
睾丸支持细胞（Sertoli Cell, SEC）的研究进展与应用前景
睾丸支持细胞（Sertoli Cell, SEC）是雄性动物曲细精管内的核心功能细胞，依托独特的结构与分泌功能，构建睾丸稳定微环境、调控精子发生全过程，同时兼具免疫调节、细胞营养支持与组织损伤修复等多重生物学功能。相较于犬睾…
Trilium中文版完整指南：3步打造你的专属知识管理系统
Trilium中文版完整指南：3步打造你的专属知识管理系统 【免费下载链接】trilium-translation Translation for Trilium Notes. Trilium Notes 中文适配, 体验优化 项目地址: https://gitcode.com/gh_mirrors/tr/trilium-translation 你是否曾经因为英文界面而…
铜钟音乐：5分钟掌握纯净无干扰的免费听歌平台终极指南
铜钟音乐：5分钟掌握纯净无干扰的免费听歌平台终极指南 【免费下载链接】tonzhon-music 铜钟「Tonzhon」: 干净纯粹的音乐平台 (铜钟已不再使用原来的 tonzhon.com，现在的 tonzhon.com 不是正版的铜钟) 项目地址: https://gitcode.com/GitHub_Trending/…
npm audit 实战避坑指南：AI编程工具自动修复 3 类高危依赖漏洞
1. npm audit 不是“一键修复”，而是三类高危漏洞的精准外科手术 我第一次在 CI 流水线里看到 npm audit --audit-level high 报出 7 个 HIGH、2 个 CRITICAL 漏洞时，下意识点了 npm audit fix --force。5 分钟后，测试全部挂掉，jsonwebtoken 升级到 v9.x 后 verify() 接口…
Python开发中常见的10个错误及解决方法
你会以为Python简单到不会犯错？等踩过这些坑再说话。错误1：把可变对象当作函数默认参数几乎每个Python新手都会栽在这里。看这段代码：def add_item(item, lst[]): lst.append(item) return lst print(add_item(1)) # [1] print(add_item(2)) …
npm 版本总出错？用 semver 语义化规则管理包发布的 3 类版本号
1. 版本号不是“随便加一”的数字，而是团队协作的契约语言 我见过三个项目在同一天因为 npm version patch 命令执行后，CI 流水线集体报错：一个依赖包的 peerDependencies 突然不满足，另一个下游服务在安装时提示 UNMET PEER DEPENDENCY，第三个直接在构建阶段抛出 TypeEr…
Selenium元素定位全解析：从八大方法到实战策略
1. 项目概述：从“找东西”到“精准操控” 做自动化测试，尤其是Web UI自动化，最核心也最让人头疼的一步是什么？不是写复杂的业务逻辑，也不是处理异步加载，而是最基础的—— 让程序找到页面上那个你想操作的…
移动端UI自动化测试框架Maestro终极指南：从入门到实战
1. 项目概述：为什么是Maestro？ 如果你正在寻找一个能让你快速上手、告别繁琐配置、并且对移动端UI自动化测试真正友好的框架，那么Maestro很可能就是你一直在等的那个答案。我接触过Appium、Espresso、XCUITest，也折腾过各种基于图…
BurpSuite Cluster Bomb模式深度避坑指南：从原理到实战的完整爆破策略
1. 项目概述：从“能用”到“精通”的必经之路如果你正在学习或从事网络安全测试，尤其是Web应用安全评估，那么BurpSuite的Intruder模块绝对是你绕不开的核心工具。而Intruder模块里，功能最强大、也最让人又爱又恨的，莫过…
AI Coding 六个月真实ROI账本：产品经理的血泪教训，研发的冷静忠告
6个月前的2025年12月，Boris Cherny 公开宣布自己卸载了 IDE。一时间，Vibe Coding 成了全行业最热的话题。6个月后，当我们回过头来拉一份真实账本，发现事情远没有"一句话生成一个App"那么浪漫。本文从产品经理和研发两个…
华为OD机试2025C卷-字符统计及重排[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率
📫 个人主页：深夜coding算法 📣 专栏系列：2026年华为最新OD机试题库详解 🔥 一次订阅，永久解锁 | 持续更新100篇 | 6语言全覆盖 文章目录❄️前言：☀️一：题目描述🌙 题目…
华为OD机试2025C卷-寻找相同子串[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率
📫 个人主页：深夜coding算法 📣 专栏系列：2026年华为最新OD机试题库详解 🔥 一次订阅，永久解锁 | 持续更新100篇 | 6语言全覆盖 文章目录❄️前言：☀️一：题目描述🌙 题目…
FAE放射组学分析工具：医学影像特征探索的完整解决方案
FAE放射组学分析工具：医学影像特征探索的完整解决方案 【免费下载链接】FAE FeAture Explorer 项目地址: https://gitcode.com/gh_mirrors/fae/FAE 你是否曾经面对海量医学影像数据感到无从下手？想要从CT、MRI等影像中提取有价值的定量特征&#…
0.69B参数实现中文多模态AI：揭秘Qwen3-SmVL模型融合技术的完整实战指南
0.69B参数实现中文多模态AI：揭秘Qwen3-SmVL模型融合技术的完整实战指南 【免费下载链接】happy-llm 📚 从零开始构建大模型 项目地址: https://gitcode.com/GitHub_Trending/ha/happy-llm 还在为大型多模态模型动辄数十亿参数、显存占用高而烦恼&…
解锁AMD Ryzen处理器性能潜力的SMU调试神器：从新手到专家的完整指南
解锁AMD Ryzen处理器性能潜力的SMU调试神器：从新手到专家的完整指南 【免费下载链接】SMUDebugTool A dedicated tool to help write/read various parameters of Ryzen-based systems, such as manual overclock, SMU, PCI, CPUID, MSR and Power Table. 项目地址…