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、Bashtest-checker.md测试覆盖率与质量缺失用例、边界情况Read、Bash、Grepperformance-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 配置字段规范可逐一解读字段取值含义nameperformance-analyzer唯一标识符小写字母 连字符。主代理通过该名称发起显式委派例如 “Use the performance-analyzer subagent”v2.1.140 起匹配对大小写与分隔符不敏感descriptionPerformance impact analysis自然语言用途说明是主代理判断“何时该用它”的依据若想鼓励自动调用通常会在描述中加 “use PROACTIVELY”toolsRead, 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 efficiencyN1 查询问题改 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 cases3.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 MCPPR 的 diff 数据由 mcp/github-config.json 提供{ mcpServers: { github: { command: npx, args: [modelcontextprotocol/server-github], env: { GITHUB_TOKEN: ${GITHUB_TOKEN} } } } }使用时需先导出令牌export GITHUB_TOKENyour_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 次查询存在 N1 风险 - 建议将查询提出循环并批量抓取或为该列加索引需要说明的是该文件正文仅给出维度枚举具体输出格式由主代理根据模型与场景编排若需要固定模板可参考仓库中 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 Updated2026-08-04Claude Code Version2.1.220即文档撰写/验证所基于的 CLI 版本Compatible ModelsClaude 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.mdpre-review.js 钩子负责前置校验pre-review.jsGitHub MCP 负责供给 PR 数据github-config.json而它与 security-reviewer、test-checker 三个子代理并行产出、由主代理综合——这一“关注点分离 独立上下文 汇总报告”的结构正是理解插件级 AI 代码评审的最小可复用样板。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 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、Bashtest-checker.md测试覆盖率与质量缺失用例、边界情况Read、Bash、Grepperformance-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 配置字段规范可逐一解读字段取值含义nameperformance-analyzer唯一标识符小写字母 连字符。主代理通过该名称发起显式委派例如 “Use the performance-analyzer subagent”v2.1.140 起匹配对大小写与分隔符不敏感descriptionPerformance impact analysis自然语言用途说明是主代理判断“何时该用它”的依据若想鼓励自动调用通常会在描述中加 “use PROACTIVELY”toolsRead, 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 efficiencyN1 查询问题改 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 cases3.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 MCPPR 的 diff 数据由 mcp/github-config.json 提供{ mcpServers: { github: { command: npx, args: [modelcontextprotocol/server-github], env: { GITHUB_TOKEN: ${GITHUB_TOKEN} } } } }使用时需先导出令牌export GITHUB_TOKENyour_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 次查询存在 N1 风险 - 建议将查询提出循环并批量抓取或为该列加索引需要说明的是该文件正文仅给出维度枚举具体输出格式由主代理根据模型与场景编排若需要固定模板可参考仓库中 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 Updated2026-08-04Claude Code Version2.1.220即文档撰写/验证所基于的 CLI 版本Compatible ModelsClaude 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.mdpre-review.js 钩子负责前置校验pre-review.jsGitHub MCP 负责供给 PR 数据github-config.json而它与 security-reviewer、test-checker 三个子代理并行产出、由主代理综合——这一“关注点分离 独立上下文 汇总报告”的结构正是理解插件级 AI 代码评审的最小可复用样板。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考