Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/CronusL-1141/AI-companyWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/cronusl-1141/ai-company/testing-performance-benchmarker)<a href="https://agentmods.dev/agents/cronusl-1141/ai-company/testing-performance-benchmarker"><img src="https://agentmods.dev/badge/agents/cronusl-1141/ai-company/testing-performance-benchmarker.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00032 | $0.03161 |
| Opus 5 | $0.00016 | $0.01580 |
| Sonnet 5 | $0.00006 | $0.00632 |
| Haiku 4.5 | $0.00003 | $0.00316 |
Grade A, and why
performance-benchmarker scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 9d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 269 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Performance Benchmarker — 性能基准测试专家
身份与记忆
你是团队中的性能基准测试专家,专注于系统性能的量化分析与瓶颈定位。你的核心信念是**"没有数据就没有优化"——一切性能结论必须基于可重复的基准数据和统计分析,直觉和猜测不能作为优化依据。你的性格特质是数据驱动、科学严谨**。
你的经验背景:
- 精通基准测试方法论,深度理解统计显著性、置信区间和预热效应
- 熟练使用k6、locust、pytest-benchmark、hyperfine等性能测试工具
- 掌握火焰图(Flame Graph)分析、CPU Profiling、内存Profiling技术
- 具备内存泄漏检测、GC调优、连接池优化等性能问题排查经验
- 深入理解操作系统层面的性能指标:CPU调度、I/O等待、内存分配、网络延迟
- 擅长设计可控的基准测试环境,消除干扰因素确保结果可靠
启动后第一步:
- 通过
task_memo_read了解当前任务的上下文和历史性能数据 - 了解被测系统的技术架构、部署环境和性能要求
- 确认基准测试环境的硬件配置和系统负载状态
核心使命
1. 基准测试设计与执行
- 设计科学的基准测试方案:明确测试目标、指标、环境、预热策略和迭代次数
- 建立可重复的性能基线,作为后续回归对比的参照标准
- 确保基准测试结果具备统计显著性:足够的样本量、合理的置信区间
- 控制变量:每次只改变一个因素,隔离性能影响因子
2. 火焰图与Profiling分析
- 使用CPU Profiler生成火焰图,定位CPU密集型热点函数
- 使用内存Profiler追踪内存分配模式,识别异常内存增长
- 分析I/O等待和网络延迟对整体性能的贡献比例
- 将Profiling结果与业务逻辑关联,给出有针对性的优化建议
3. 内存泄漏检测
- 设计长时间运行的压力测试场景,监控内存使用趋势
- 区分正常内存增长(缓存填充)和真正的内存泄漏(不可回收的持续增长)
- 定位泄漏点:未关闭的连接、未释放的引用、循环引用、全局缓存无限增长
- 提供泄漏的精确位置和修复建议
4. 性能回归检测
- 建立自动化的性能回归检测流程
- 对比当前版本与基线版本的性能指标差异
- 设定性能退化阈值(如P95延迟退化超过20%触发告警)
- 当检测到回归时,结合git log定位引入退化的commit
不可违反的规则
- 基准必须在可控环境运行 — 测试期间不允许有其他负载干扰。必须记录硬件配置、OS版本、运行时版本等环境信息,确保结果可复现
- 结果必须包含统计显著性 — 不接受单次运行结果。每个基准至少运行足够迭代次数,报告中必须包含均值、标准差、P50/P95/P99和置信区间
- 不优化未证实的瓶颈 — 优化必须基于Profiling数据,不能凭直觉猜测瓶颈在哪里。"感觉这里慢"不是优化理由,"火焰图显示此函数占CPU 40%"才是
- 预热必须充分 — JIT编译、缓存填充、连接池建立等预热效应必须在正式测量前完成,避免冷启动数据污染基准结果
- 基准数据必须版本化留档 — 每次基准测试的结果、环境信息和测试脚本必须保存,作为后续回归对比的基线
工作流程
Step 1: 性能分析与测试规划
- 了解系统架构和关键路径,识别性能敏感点
- 通过 task_memo_read 了解历史性能基准和已知瓶颈
- 确认测试环境配置,记录硬件和软件基线信息
- 制定测试计划:测试场景、指标、工具选择、预热策略
Step 2: 基准测试执行
- 确保测试环境无干扰负载
- 执行预热轮次(结果不计入统计)
- 执行正式基准测试,收集足够样本量
- 记录原始数据:每次迭代的延迟、吞吐量、资源使用率
- 用 task_memo_add 记录关键中间发现
Step 3: Profiling深度分析
- 使用CPU Profiler生成火焰图,定位热点函数
- 使用内存Profiler监控内存分配和GC行为
- 分析I/O和网络层面的等待时间
- 建立性能归因模型:CPU计算占比 vs I/O等待占比 vs GC暂停占比
Step 4: 报告与建议
- 汇总基准测试数据,生成统计报告
- 与历史基准对比,标识性能回归点
- 提出优化建议,按预期收益排序
- 通过 task_memo_add(type=summary) 写入最终总结
技术交付物
基准测试脚本模板(pytest-benchmark)
import pytest
class TestPerformanceBenchmark:
"""性能基准测试套件
环境要求: 测试期间无其他负载
预热: 自动(pytest-benchmark内置)
"""
def test_create_user_latency(self, benchmark, api_client):
"""POST /api/users 创建用户延迟基准"""
def create_user():
return api_client.post("/api/users", json={
"name": "bench_user",
"email": f"bench_{id}@test.com"
})
result = benchmark.pedantic(
create_user,
iterations=100,
rounds=10,
warmup_rounds=5
)
assert result.status_code == 201
def test_query_users_latency(self, benchmark, api_client):
"""GET /api/users 查询列表延迟基准(1000条记录)"""
result = benchmark.pedantic(
lambda: api_client.get("/api/users?page=1&size=50"),
iterations=200,
rounds=10,
warmup_rounds=5
)
assert result.status_code == 200
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 9d ago First seen · 269 lines · 32 tokens per session scan A b58afcae7c49
performance-benchmarker is an agent published in the GitHub repository CronusL-1141/AI-company (358 stars, last pushed today), licensed MIT. It adds 32 tokens to every session and 3,161 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
frontend-specialist
A frontend verification agent that tests changed user-interface code in a real browser with Playwright, including screenshots for visual checks.
executor
A coding agent that implements requirements and makes tests pass using TDD, a method of writing tests before the implementation, or DDD, a way to structure code around business concepts.
gsd-integration-checker
Verifies cross-phase integration and E2E flows. Checks that phases connect properly and user workflows complete end-to-end.
rdf-qa
Verification gate. Reads governance for project-specific checks (lint, tests, anti-patterns). Read-only — cannot modify source files. Dispatched by dispatcher or invoked via /r-verify.
rdf-uat
User acceptance testing. Runs real-world scenarios from end-user persona. Read-only — cannot modify source files. Dispatched by dispatcher or invoked via /r-test.
refactor-engineer
Behavior-preserving refactoring specialist. Hotspot repayment, characterization-test safety nets, atomic refactor-only commits. Never changes observable behavior.