claude-howto 实战：为 pr-review 插件设计 performance-analyzer 性能影响分析 Subagent-开发者社区

claude-howto 实战：为 pr-review 插件设计 performance-analyzer 性能影响分析 Subagent

【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto

导读

本文以 performance-analyzer.md 为讲解主体，剖析该文件如何用 YAML frontmatter + Markdown 正文的方式，在 pr-review 插件中定义一名专职评估“改动对运行性能影响”的 AI Subagent。你将掌握：这类审查代理的字段语义（名称、描述、工具白名单）、四类核心检查维度（算法复杂度、数据库查询效率、内存占用、缓存机会）的落地方法、它与其他审查代理（security-reviewer、test-checker）的分工协作，以及在/review-pr全流程中的被调度位置。文中所有结论均可在当前仓库 07-plugins/pr-review 目录下的源码、命令、钩子与 MCP 配置中找到依据。

一、文件定位：pr-review 插件中的“性能裁判”

performance-analyzer.md位于 pr-review 插件的 agents 目录中，与另外两个专职审查代理并列：

代理文件	关注点	工具
security-reviewer.md	安全漏洞（认证授权、数据暴露、注入、安全配置）	Read、Grep、Bash
test-checker.md	测试覆盖率与质量（缺失用例、边界情况）	Read、Bash、Grep
performance-analyzer.md	性能影响评估（算法、查询、内存、缓存）	Read、Grep、Bash

三者共同构成 07-plugins/README.md 所描述的“多组件插件”模式：一个插件可打包多个 slash commands、subagents、MCP 服务器与 hooks，并支持一次命令安装。pr-review 插件的目录结构完整印证了这一模式：

07-plugins/pr-review/ ├── agents/ │ ├── performance-analyzer.md # 本文讲解的性能影响分析代理 │ ├── security-reviewer.md │ └── test-checker.md ├── commands/ │ ├── check-security.md │ ├── check-tests.md │ └── review-pr.md ├── hooks/ │ └── pre-review.js └── mcp/ └── github-config.json

从插件根 README.md 可知，插件安装后通过 GitHub 集成（mcp/github-config.json）获取 PR 数据，由pre-review.js钩子先校验仓库环境，再由三个子代理分头输出安全、测试、性能三份评审意见，最后由主代理综合成报告。performance-analyzer 是这份“三角色评审”中唯一专职回答『这次改动会不会让线上变慢』的代理。

二、Subagent 定义格式逐字段拆解

performance-analyzer.md的完整定义可分为两个部分：YAML frontmatter（元数据区）与 Markdown 正文（角色说明区）。

2.1 frontmatter 元数据

--- name: performance-analyzer description: Performance impact analysis tools: Read, Grep, Bash ---

对照 04-subagents/README.md 中给出的 Subagent 配置字段规范，可逐一解读：

字段	取值	含义
`name`	`performance-analyzer`	唯一标识符（小写字母 + 连字符）。主代理通过该名称发起显式委派，例如 “Use the performance-analyzer subagent”；v2.1.140 起匹配对大小写与分隔符不敏感
`description`	`Performance impact analysis`	自然语言用途说明，是主代理判断“何时该用它”的依据；若想鼓励自动调用，通常会在描述中加 “use PROACTIVELY”
`tools`	`Read, Grep, Bash`	只读能力白名单：Read 读文件、Grep 检索代码、Bash 执行命令。注意该定义没有包含 Write/Edit，说明设计意图是“只诊断、不修改”，符合 PR 审查阶段只产结论的定位。根据 Subagent 规范，省略该字段才会继承全部工具

未出现的可选字段：该定义没有写model、permissionMode、memory、maxTurns、hooks、mcpServers等。按 Subagent 字段默认语义（见 04-subagents/README.md 的“Configuration Fields”表），model省略时继承会话配置的 subagent 模型；tools之外的字段缺省即关闭对应能力。这是“最小化配置”的典型写法——因为它是插件内置代理，插件沙箱本身还禁止子代理声明hooks、mcpServers、permissionMode（详见该 README 的 “Plugin Subagent Security” 一节），防止插件通过子代理越权。

2.2 Markdown 正文：四维检查框架

正文标题下方定义了它的核心使命：评估改动带来的性能影响，检查面覆盖四个维度：

Evaluates performance impact of changes: - Algorithm complexity - Database query efficiency - Memory usage - Caching opportunities

这段正文不是系统提示词的全文，而是给主代理的“能力速览”。实际执行时，主代理会在自己的独立上下文窗口中结合该提示词完成具体分析。仓库中与之呼应、可作深度补充的模板是 04-subagents/performance-optimizer.md——那份“Performance Optimizer”代理给出了同一批维度的、可直接执行的技术清单，可作为理解本代理检查点含义的底层参考（下表逐条对照）：

performance-analyzer 维度	具体关注点（结合仓库依据展开）
Algorithm complexity	是否把 O(n²) 替换为 O(n log n)/O(n)；是否选用合适数据结构换取 O(1) 查找；是否存在冗余迭代与重复计算；是否需要 memoization/缓存高频昂贵调用
Database query efficiency	N+1 查询问题（改 JOIN 或批量抓取）；高频过滤/排序列是否缺索引；是否用分页避免无界结果集；是否做投影只取所需列；是否复用连接池
Memory usage	是否把整文件读入内存（应改流式）；是否清理定时器与事件监听器防泄漏；热路径上的对象分配是否过多
Caching opportunities	是否缓存重复计算的昂贵结果（含 TTL）；是否利用合适的键值结构避免反复命中慢路径

因此一个合格的 performance-analyzer 输出，通常应能回答：改的是哪一段代码、时间/空间复杂度如何变化、是否引入额外 DB 往返、峰值内存是否上升、哪里可以加缓存而不破坏正确性。

三、它在`/review-pr`全流程中的调度位置

在 pr-review 插件 README 的 “Example Workflow” 一节，完整展示了这条调用链：

1. Runs pre-review hook (validates git repo) 2. Fetches PR data via GitHub MCP 3. Delegates security review to security-reviewer subagent 4. Delegates testing to test-checker subagent 5. Delegates performance to performance-analyzer subagent 6. Synthesizes all findings 7. Provides comprehensive review report

也就是说，performance-analyzer 在第 5 步被并行委派（subagent 拥有独立上下文窗口、默认后台运行），其结论在第 6 步与安全、测试结论汇总。README 给出了一个合成报告样例，其中性能行形如：

✅ Performance: No significant impact 📝 Recommendations: Add tests for edge cases

3.1 触发入口：`/review-pr`与独立评审

入口 slash command 定义在 commands/review-pr.md，其 frontmatter 描述为 “Start comprehensive PR review with security and testing checks”，正文列出的五项检查中第 5 项正是 “Performance impact assessment”。用户的实际用法只有一行：

/review-pr

执行前置条件由 hooks/pre-review.js 保证：先用git rev-parse --git-dir校验当前目录是 Git 仓库（否则直接报错退出），再用git status --porcelain探测未提交改动并给出警告。也就是说，性能分析在合法、可追踪的 Git 变更集上展开，避免对一堆游离文件做无意义的“云评审”。

3.2 数据来源：GitHub MCP

PR 的 diff 数据由 mcp/github-config.json 提供：

{ "mcpServers": { "github": { "command": "npx", "args": ["@modelcontextprotocol/server-github"], "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" } } } }

使用时需先导出令牌：export GITHUB_TOKEN="your_github_token"（见 pr-review README 的 Requirements/Configuration）。令牌通过${GITHUB_TOKEN}环境变量注入，而不是硬编码进 JSON——这一写法也是安全实践的直接示范。

四、安装、运行与验证

4.1 安装插件

/plugin install pr-review

安装完成后，插件内的 agents（含 performance-analyzer）、commands、MCP 与 hooks 即被统一注册。也可以在会话中显式点名该子代理，例如：

> 用 performance-analyzer subagent 评估这次改动的性能影响 > Have the performance-analyzer subagent look at the recent changes

由于 subagent 名称匹配不区分大小写与分隔符，performance_analyzer同样可解析到该代理。

4.2 独立运行

若只想做性能专项检查，可直接要求代理聚焦性能维度，不必走完整/review-pr。此时它用 Grep 定位热点代码、用 Read 精读实现、用 Bash 跑轻量命令（例如time、git diff统计、或数据库EXPLAIN），产出形如下面的结构化结论：

性能影响： - 热点：src/queries.py#L40-L58（改动新增循环） - 复杂度：O(n) → O(n²)（内层重复全表扫描） - 数据库：每次迭代额外 1 次查询，存在 N+1 风险 - 建议：将查询提出循环并批量抓取，或为该列加索引

需要说明的是：该文件正文仅给出维度枚举，具体输出格式由主代理根据模型与场景编排；若需要固定模板，可参考仓库中 04-subagents/performance-optimizer.md 的 “Output Format” 建议（Bottleneck / Root Cause / Before / Change / After / Trade-offs）。

五、扩展与自定义建议

把 performance-analyzer 应用到自己的仓库时，可以从以下几个方面演进，均以仓库中既有事实为依据：

丰富正文细则：将正文的四行维度扩展为检查清单，可借鉴 04-subagents/performance-optimizer.md 中 Algorithms & Data Structures / Database / Memory 三节的操作项。
调整工具集：若希望代理能直接读数据库 Explain 输出或执行压测脚本，可在tools中按需增补；若需约束命令前缀（如Bash(npm:*)），Subagent 规范亦支持（见 04-subagents/README.md 的 Conditional Tool Access 示例）。
加入输出模板：规范化的输出便于主代理汇总，也能让生成的评审报告被检索与引用。
配套评审纪律：性能结论应基于基线数据（改动前/后指标），避免“凭感觉下判断”；这也是仓库中性能类代理反复强调的 “Measure and verify improvements” 原则。

六、版本与兼容性说明

文件元数据注明：

Last Updated：2026-08-04
Claude Code Version：2.1.220（即文档撰写/验证所基于的 CLI 版本）
Compatible Models：Claude Fable 5、Claude Opus 5、Claude Sonnet 5、Claude Sonnet 4.6、Claude Opus 4.8、Claude Haiku 4.5
插件整体要求 Claude Code 2.1+ 且需要 GitHub 访问权限（见 pr-review README）

这意味着：本文描述的 frontmatter 字段、工具白名单与多代理委派流程，均以 2.1.x 系列 CLI 行为为准；若使用的版本差异较大，应以实际claude --version及 04-subagents/README.md 中标注的各能力引入版本（如后台运行、背景子代理、名称匹配等变更点）为准核对。

七、小结

performance-analyzer.md用不到二十行定义，把一个“只读、专职、聚焦四类性能风险”的审查代理嵌入了 pr-review 插件的协作流水线。从仓库证据链可以看到它的完整运行环境：/review-pr命令负责编排（review-pr.md），pre-review.js 钩子负责前置校验（pre-review.js），GitHub MCP 负责供给 PR 数据（github-config.json），而它与 security-reviewer、test-checker 三个子代理并行产出、由主代理综合——这一“关注点分离 + 独立上下文 + 汇总报告”的结构，正是理解插件级 AI 代码评审的最小可复用样板。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

claude-howto 实战：为 pr-review 插件设计 performance-analyzer 性能影响分析 Subagent