Update nexus wiki content

wiki/sources/testing-performance-benchmarker.md

@@ -2,52 +2,47 @@
 title: "Performance Benchmarker Agent Personality"
 type: source
 tags: []
-date: 2026-04-21
+date: 2026-04-30
 ---
 
 ## Source File
-- [[raw/Agent/agency-agents/testing/testing-performance-benchmarker.md]]
+- [[Agent/agency-agents/testing/testing-performance-benchmarker.md]]
 
 ## Summary（用中文描述）
-- 核心主题：性能测试与优化专家 Agent，专注于测量、分析和改进跨应用程序和基础设施的系统性能
-- 问题域：性能基线建立、负载/压力测试、Web Vitals 优化、容量规划、可扩展性评估
-- 方法/机制：使用 k6 编写综合性能测试套件，统计置信区间分析，Core Web Vitals 监控，性能回归测试
-- 结论/价值：数据驱动的方法论，通过量化指标证明性能改进，确保系统满足 SLA 要求
+- 核心主题：AI Agent 角色定义 —— Performance Benchmarker（性能基准测试专家）
+- 问题域：系统性能测试、Web 性能优化、容量规划与可扩展性评估
+- 方法/机制：通过数据驱动的性能测试方法，建立基线、识别瓶颈、提供优化建议并持续监控
+- 结论/价值：为所有系统设定性能 SLA 标准（95% 置信度），通过 Core Web Vitals 和负载测试确保用户体验
 
 ## Key Claims（用中文描述）
-- Performance Benchmarker Agent 通过系统性性能测试确保所有系统以 95% 置信度满足性能 SLA
-- 通过 Core Web Vitals 优化（LLC < 2.5s、FID < 100ms、CLS < 0.1）提升用户体验
-- 通过查询优化可将第95百分位响应时间从 850ms 降至 180ms
-- 通过性能监控可预防 90% 的性能相关事故
+- 所有系统必须满足性能 SLA，要求 95% 置信度（Performance-First Methodology）
+- Core Web Vitals 达标标准：LCP < 2.5s、FID < 100ms、CLS < 0.1
+- 性能优化前必须建立基线，并使用统计分析和置信区间进行测量
+- 优先考虑用户感知性能，而非单纯的技术指标
 
 ## Key Quotes
-> "95th percentile response time improved from 850ms to 180ms through query optimization" — 数据驱动的优化效果量化
-
-> "Page load time reduction of 2.3 seconds increases conversion rate by 15%" — 性能与业务影响关联
-
-> "Always establish baseline performance before optimization attempts" — 性能优化的首要原则
+> "Always establish baseline performance before optimization attempts" — 性能测试核心原则
+> "95th percentile response time improved from 850ms to 180ms through query optimization" — 数据驱动的优化案例
+> "Page load time reduction of 2.3 seconds increases conversion rate by 15%" — 用户体验影响量化
 
 ## Key Concepts
-- [[LoadTesting]]：模拟正常和峰值负载，验证系统在预期条件下的性能表现
-- [[StressTesting]]：逐步增加负载直到系统崩溃，找出性能临界点和恢复行为
-- [[CoreWebVitals]]：Google 定义的页面用户体验核心指标（LCP、FID、CLS）
-- [[RealUserMonitoring]]：基于真实用户数据的性能监控，对抗合成测试的局限性
-- [[CapacityPlanning]]：基于增长预测和使用模式预测资源需求
-- [[ConfidenceIntervals]]：统计置信区间用于可靠的性能测量
+- [[PerformanceBenchmarker]]：AI Agent 角色，专注于测量、分析和改进系统性能，通过数据驱动的方法确保系统满足性能 SLA
+- [[CoreWebVitals]]：Web 性能核心指标，包括 LCP（最大内容绘制）、FID（首次输入延迟）、CLS（累计布局偏移），是衡量用户体验的关键标准
+- [[LoadTesting]]：负载测试，通过模拟真实用户行为在不同负载条件下测试系统性能，识别瓶颈
+- [[CapacityPlanning]]：容量规划，基于增长预测和Usage模式预测资源需求，评估水平/垂直扩展能力
+- [[ErrorBudget]]：错误预算，在可靠性工程中允许一定范围的故障时间，用于平衡创新与稳定性
+- [[RealUserMonitoring]]：真实用户监控（RUM），通过采集真实用户数据而非合成测试来衡量 Web 性能
 
 ## Key Entities
-- [[TestingRealityChecker]]：测试现实核查 Agent，与 Performance Benchmarker 协同工作
-- [[TestingApiTester]]：API 测试专家 Agent，共同构成全面测试体系
-- [[WorkflowOptimizerAgent]]：工作流优化 Agent，通过性能优化提升工作流效率
+- [[k6]]：开源负载测试工具，Performance Benchmarker 在示例代码中使用的性能测试框架，支持多协议和自定义指标
+- [[Lighthouse]]：Google 开发的 Web 性能审计工具，可用于测量 Core Web Vitals 分数
 
 ## Connections
-- [[TestingRealityChecker]] ← complements ← [[TestingPerformanceBenchmarker]]
-- [[TestingApiTester]] ← extends ← [[TestingPerformanceBenchmarker]]
-- [[WorkflowOptimizerAgent]] ← depends_on ← [[TestingPerformanceBenchmarker]]
+- [[TestingRealityChecker]] ← tests → [[PerformanceBenchmarker]]
+- [[TestingWorkflowOptimizer]] ← optimizes → [[PerformanceBenchmarker]]
+- [[APITester]] ← complements → [[PerformanceBenchmarker]]
+- [[TestingToolEvaluator]] ← evaluates → [[PerformanceBenchmarker]]
 
 ## Contradictions
-- 与 [[TestingRealityChecker]] 的视角差异：
-  - 冲突点：Reality Checker 强调"真实用户感受"，Performance Benchmarker 强调"量化指标"
-  - 当前观点：量化指标（p95 < 500ms）是性能优化的客观标准
-  - 对方观点：用户主观感受比指标更重要，指标可能具有欺骗性
-  - 调和：两者互补——指标指导优化方向，用户体验验证优化效果
+- 无已知冲突
+