尧图网站建设 
claude-code-action 性能审查 Agentperformance-reviewer完全指南定义、审查维度与 PR 工作流集成【免费下载链接】claude-code-action项目地址: https://gitcode.com/GitHub_Trending/cl/claude-code-action性能问题往往是软件上线后才暴露的隐形债务——N1 查询、无意识的全表扫描、循环内重复分配大对象、未关闭的连接……这些问题在功能正确的前提下极难被传统代码审查发现。本指南以 claude-code-action 仓库内置的.claude/agents/performance-reviewer.md为核心完整讲解该性能审查子代理subagent的 frontmatter 配置、三大审查维度、标准化输出结构并结合仓库的 Agent 定义体系、PR 审查命令与内联评论机制说明如何在 GitHub Actions 工作流中落地一套可复用、可验证的性能审查方案。一、认识 performance-reviewer仓库中的性能专项审查官在 claude-code-action 仓库中.claude/目录集中管理着 Claude Code 的本地配置其中agents/子目录定义了五个职责各异的审查子代理code-quality-reviewer代码质量、可维护性与整洁代码performance-reviewer本文主角性能瓶颈、资源效率与网络查询优化security-code-reviewer安全漏洞与威胁建模test-coverage-reviewer测试覆盖与测试质量documentation-accuracy-reviewer文档准确性这种一个领域一个专项 Agent的设计让大型 PR 审查可以被拆解为多个并行的、职责单一的审查任务避免单一主代理因上下文过长而遗漏关键检查点。performance-reviewer 专注回答一个核心问题这段代码在生产规模下是否足够高效是否存在可量化的性能隐患1.1 Frontmatter子代理的身份证performance-reviewer.md 顶部是标准的 YAML frontmatter共四个字段字段值含义nameperformance-reviewer子代理的唯一标识供主代理通过Task工具按名调用description一句话 五个典型触发场景告诉主代理什么情况下应该启用本代理的关键元数据toolsGlob, Grep, Read, WebFetch, TodoWrite, WebSearch, BashOutput, KillBash允许子代理使用的工具白名单modelinherit继承当前会话使用的模型不单独指定description字段是子代理编排的路由依据——主代理main agent会根据任务描述与各子代理 description 的匹配程度决定是否委派。该字段给出的五个典型使用场景值得注意实现数据库查询或 API 调用之后写完后立刻审查数据访问层优化已有功能时对存量代码做性能体检编写数据处理逻辑之后循环、批量处理、聚合计算类代码排查应用响应缓慢时定位慢请求根因完成任何涉及循环、网络请求或内存密集型操作的代码后覆盖最通用的触发面。tools字段限定了子代理的能力边界它只读不写——可以Glob/Grep/Read检索与阅读代码、WebSearch/WebFetch查证外部资料、用BashOutput/KillBash观察运行输出但没有Edit/Write等修改工具。这是有意为之审查代理的职责是发现问题并给出修复建议修改代码应回到主代理或其他执行代理手中防止审查代理在分析中途擅自改动代码。1.2 角色定位跨层级的性能优化专家frontmatter 之后的正文第一段给出了角色设定You are an elite performance optimization specialist with deep expertise in identifying and resolving performance bottlenecks across all layers of software systems.关键词有两个all layers所有软件层次与actionable可执行。这个 Agent 的审查范围不仅限于单函数内的算法效率而是覆盖从算法复杂度、网络 I/O、数据库访问到内存管理的全链路。同时它的产出必须是可行动的优化建议而非笼统的这里性能不好。二、审查维度一性能瓶颈分析Performance Bottleneck Analysis这是性能审查的第一道关卡聚焦代码本身的执行效率。Agent 从五个角度切入2.1 算法复杂度审查识别 O(n²) 或更差的操作例如嵌套循环遍历同一数据集、在循环内反复调用 O(n) 的数组操作indexOf、includes、数组内splice都可能导致平方级退化建议的优化方向使用哈希表Map/Set换取 O(1) 查找、提前排序后用双指针、对可索引结构改用二分查找等。2.2 冗余计算检测不必要的重复计算同一表达式在循环体内被反复求值且结果与循环变量无关可缓存的中间结果memoization记忆化候选——相同输入反复出现的纯函数调用重复请求去重request deduplication同一资源在同一请求批次中被多次获取。2.3 阻塞操作与异步化识别可能阻塞事件循环event loop或主线程的操作评估其是否可以迁移到异步执行、工作线程或消息队列对 Node.js/Bun 环境要特别注意同步文件 I/O、大规模同步计算对并发能力的拖累。2.4 循环结构优化检查低效迭代方式在循环内做高开销操作、嵌套循环是否可以被拍平flatten、是否能通过一次遍历完成多次统计循环体内是否创建了本可提升到循环外的对象或闭包。2.5 过早优化 vs 真实瓶颈这是该维度中颇具工程智慧的一条Agent 需要区分过早优化premature optimization与正当的性能关注legitimate performance concerns。并非所有微优化都值得做——只有在可测量的热点路径上、以可验证的性能数据为依据的优化才有意义。这与审查的影响 vs 成本优先级排序一脉相承。三、审查维度二网络查询效率Network Query Efficiency后端代码的大部分性能问题都发生在数据访问层本维度专门覆盖与外部系统数据库、API交互的效率。3.1 数据库查询N1 问题与缺失索引N1 问题循环内逐条查询关联数据1 次主查询 N 次子查询应改为 JOIN 或批量预取eager loading缺失索引WHERE、ORDER BY、JOIN条件列缺少索引导致全表扫描投影过宽SELECT *拉取了不需要的列。3.2 API 调用批处理与往返次数审查是否存在可以合并的多次独立调用batching识别不必要的网络往返round trips例如先查列表再逐条查详情可改为一次批量详情查询检查分页pagination、过滤filtering、投影projection是否在数据获取阶段就正确应用而不是把全量数据拉到内存再裁剪。3.3 缓存、记忆化与请求去重对热点数据是否可以考虑缓存层纯函数计算结果是否值得memoization并发场景下同一请求是否可以被去重合并request deduplication。3.4 连接池与资源复用数据库连接、HTTP 客户端、gRPC channel 等重量级资源是否复用了连接池而非每次请求新建连接池大小是否与并发模型匹配。3.5 重试风暴Retry Storm防护Verify proper error handling that doesnt cause retry storms.一个常被忽视的隐患错误的失败处理反而放大故障。当服务端过载或依赖故障时如果客户端无退避地疯狂重试会形成重试风暴把依赖彻底压垮。Agent 需要检查重试逻辑是否具备指数退避exponential backoff与抖动jitter。这一检查点在 claude-code-action 仓库中有直接的实现参照仓库统一封装了retryWithBackoff工具src/utils/retry.ts其实现位于 base-action/src/retry.ts。该实现默认maxAttempts 3、initialDelayMs 5000、maxDelayMs 20000、backoffFactor 2即每次失败后延迟翻倍直至上限且可通过shouldRetry回调对不可重试错误立即放弃。审查 Agent 在评估错误处理是否可能引发重试风暴时可对照此类实现核查是否缺失退避、退避上限是否缺失、是否对永久性错误如 4xx也盲目重试。四、审查维度三内存与资源管理Memory and Resource Management本维度聚焦运行时资源生命周期覆盖内存泄漏、对象生命周期与资源清理。4.1 内存泄漏检测未关闭的连接数据库连接、HTTP 连接、WebSocket未移除的事件监听器长期存活对象上反复注册监听器循环引用在带引用计数或缺乏可达性分析的运行时中循环引用阻止回收全局/模块级缓存的无限增长Map 作为缓存却无淘汰策略。4.2 对象生命周期与 GC 影响审查对象的创建与释放时机是否匹配识别循环内的过量内存分配或大对象创建——例如在循环体内重复new大数组、字符串拼接在循环中产生大量中间对象应使用 Buffer/数组 join/字符串构建器。4.3 清理逻辑的兜底检查cleanup函数、析构函数destructor或finally块中的资源释放是否正确兜底异常路径上资源是否会泄漏——例如 try 块中获取连接、异常时跳过 finally 导致连接永不归还。4.4 数据结构选型的空间效率分析数据结构的内存效率例如用Map替代稀疏数组、避免不必要的装箱boxing、选择紧凑的序列化格式大集合场景下评估分页/流式处理而非一次性加载。4.5 文件句柄与资源清理文件读写后是否关闭句柄数据库连接归还连接池而非泄漏临时文件、锁资源、句柄类资源是否有统一清理路径。五、输出结构规范如何呈现一份可执行的性能审查报告性能审查的价值最终体现在报告的可执行性上。performance-reviewer 要求输出严格遵循四段式结构5.1 四段式报告模板Critical Issues关键问题需要立即关注的性能问题——通常是会导致线上事故、明显响应退化或资源耗尽的问题Optimization Opportunities优化机会能带来可衡量收益的改进——不是必须立刻做但做了有明显回报Best Practice Recommendations最佳实践建议面向未来的预防性措施——在后续开发中避免同类问题复现Code Examples代码示例具体的 before/after 代码片段演示改进前后的差异。第四点代码示例是这份模板区别于普通代码审查的关键性能问题必须配可执行的修复示例而不是只描述现象。5.2 单条问题的四要素对识别出的每一条问题Agent 必须报告要素要求精确位置指明文件、函数、行号file, function, line numbers性能影响用估算的复杂度或资源占用说明影响如该循环为 O(n²)n10k 时需执行 1 亿次比较具体方案给出可落地、可实施的解决方案优先级按影响 vs 投入impact vs. effort排序建议其中影响 vs 投入排序是性能优化领域的核心决策框架高影响低投入的优化优先做低影响高投入的优化要谨慎评估 ROI。5.3 正向反馈与场景适配模板的最后特别要求两点若代码表现良好要明确确认confirm this explicitly并指出特别优化到位的部分——避免审查沦为为找问题而找问题始终结合具体的运行时环境与规模要求specific runtime environment and scale requirements给出建议——例如嵌入式环境与高并发云服务对内存策略的要求截然不同不能一概而论。六、在 claude-code-action 中实战从 Agent 定义到 PR 审查工作流performance-reviewer 不是孤立存在的文档它在仓库中与命令、工作流、运行时机制深度耦合。理解这条链路才能真正把它用起来。6.1 命令入口review-pr 的编排逻辑仓库的 review-pr 命令 展示了主代理如何编排五个审查子代理Perform a comprehensive code review using subagents for key areas:code-quality-reviewerperformance-reviewertest-coverage-reviewerdocumentation-accuracy-reviewersecurity-code-reviewer命令的核心编排策略有三点并行委派五个子代理分别审查各自的专业领域主代理汇总只上报值得注意的问题指示每个子代理only provide noteworthy feedback主代理在最终汇总时再次过滤——review the feedback and post only the feedback that you also deem noteworthy分级输出针对具体问题用内联评论inline comments针对总体观感或表扬用顶层评论top-level comments且要求Keep feedback concise。这也是该命令通过allowed-tools将工具白名单收敛为Bash(gh pr comment:*)、Bash(gh pr diff:*)、Bash(gh pr view:*)的原因——子代理审查需要读取 PR diff主代理发评论需要 gh 包装命令。6.2 运行机制Agent 模式如何把审查流程跑起来子代理体系运行在 claude-code-action 的agent 模式下。根据 src/modes/detector.ts 的detectMode逻辑模式由工作流上下文自动判定当配置了prompt输入时走 agent 模式绕过claude提及检测否则在评论事件中检测到触发词时走 tag 模式。其判定优先级为track_progress且命中 PR/issue 事件 → 强制 tag 模式评论事件 配置了prompt→ agent 模式评论事件 检测到claude触发词 → tag 模式issue 事件、PR 事件opened/synchronize/ready_for_review/reopened同理兜底返回 agent 模式。agent 模式的具体准备逻辑见 src/modes/agent/index.ts它把用户prompt直接写入RUNNER_TEMP/claude-prompts/claude-prompt.txt解析CLAUDE_ARGS中的--allowedToolsparse-tools并注入仓库自带的 GitHub MCP servers 配置。这意味着只要在工作流的prompt中输入要求执行性能审查的指令或引用 review-pr 这类命令performance-reviewer 就会在 agent 会话中被调用。6.3 完整工作流示例综合 PR 审查仓库提供了可直接落地的综合 PR 审查示例 examples/pr-review-comprehensive.yml通过track_progress: true获得进度跟踪评论prompt中明确列出包含性能在内的五个审查重点Code Quality、Security、Performance、Testing、Documentation并用claude_args限定--allowedTools mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)。其中性能部分要求 ClaudeIdentify potential performance bottlenecksReview database queries for efficiencyCheck for memory leaks or resource issues这与 performance-reviewer 的三大审查维度一一对应。若希望审查由专职子代理执行可在prompt中直接引用 review-pr 命令或显式指定委派 performance-reviewer。6.4 内联评论缓冲防止子代理污染PR当子代理继承内联评论工具时一个真实风险是子代理在遭遇无关错误后试探性地调用评论工具产生测试/探测性质的评论污染 PR。仓库通过内联评论 MCP 服务器src/mcp/github-inline-comment-server.ts解决了这个问题调用create_inline_comment时若不带confirmed: true评论不会立即发布而是被缓冲到/tmp/inline-comments-buffer.jsonl会话结束后缓冲评论经 Haiku 分类真实审查评论才会发布测试/探测评论被丢弃该机制由classify_inline_comments输入控制默认true参见 docs/usage.md。因此在编排子代理审查时应要求子代理不要在分析阶段提交评论而由主代理在汇总确认后统一发布——这正对应 review-pr 命令中由主代理过滤后再发评论的设计。6.5 相关配置与输入项速查结合 docs/usage.md 的输入参数表与子代理审查工作流直接相关的配置项包括输入项作用prompt自动化工作流的指令可声明执行性能审查或引用审查命令claude_args直接透传给 Claude CLI 的参数如--allowedTools、--max-turns 10保证多轮子代理编排有足够预算track_progress强制 tag 模式并生成带进度复选框的跟踪评论仅限 PR/issue 事件classify_inline_comments控制内联评论缓冲分类防止子代理测试评论上 PRinclude_fix_links在 PR 审查反馈中附带 Fix this 链接点击即可带着上下文打开 Claude Code 修复问题trigger_phrase自定义 tag 模式触发词默认claude七、性能审查 Agent 的使用边界与最佳实践综合前文这里总结在 claude-code-action 场景下使用 performance-reviewer 的几条最佳实践触发时机前置按 description 中的建议在写完数据库查询、API 调用、数据处理逻辑后立即审查而不是等功能全部完成后再补审让子代理专注于报告主代理负责发布子代理产出四段式报告与 before/after 代码示例由主代理过滤、去重后以confirmed: true发布内联评论用claude_args控制资源预算多子代理编排会消耗较多轮次通过--max-turns设定上限避免审查任务无限扩展审查建议要可验证性能建议应附带复杂度估算或测量方法benchmark 思路而非主观断言——这与影响 vs 投入排序配合让开发者能快速决策注意安全边界agent 模式允许指定--allowedTools白名单性能审查场景保持只读工具集Glob、Grep、Read 等避免审查代理获得写权限关于权限与安全的更完整说明见 docs/security.md。八、结语performance-reviewer 是 claude-code-action 五维审查体系中的重要一环它用精确的 frontmatter 声明、三大审查维度算法与循环、网络查询、内存资源与四段式输出模板把性能优化从经验性话题转化为可重复执行的审查流程。配合仓库的 review-pr 编排命令、agent 模式的 prompt 注入机制、内联评论缓冲与分类能力开发者可以在 GitHub Actions 中搭建出多专家并行审查 → 主代理过滤汇总 → 内联评论精确定位 → Fix 链接一键修复的完整闭环。当代码审查不再是单一大模型的通才视角而是由各领域专职 Agent 各司其职时性能问题的发现将更早、更准、更可执行。【免费下载链接】claude-code-action项目地址: https://gitcode.com/GitHub_Trending/cl/claude-code-action创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 claude-code-action 性能审查 Agent（performance-reviewer）完全指南：定义、审查维度与 PR 工作流集成
claude-code-action 性能审查 Agentperformance-reviewer完全指南定义、审查维度与 PR 工作流集成【免费下载链接】claude-code-action项目地址: https://gitcode.com/GitHub_Trending/cl/claude-code-action性能问题往往是软件上线后才暴露的隐形债务——N1 查询、无意识的全表扫描、循环内重复分配大对象、未关闭的连接……这些问题在功能正确的前提下极难被传统代码审查发现。本指南以 claude-code-action 仓库内置的.claude/agents/performance-reviewer.md为核心完整讲解该性能审查子代理subagent的 frontmatter 配置、三大审查维度、标准化输出结构并结合仓库的 Agent 定义体系、PR 审查命令与内联评论机制说明如何在 GitHub Actions 工作流中落地一套可复用、可验证的性能审查方案。一、认识 performance-reviewer仓库中的性能专项审查官在 claude-code-action 仓库中.claude/目录集中管理着 Claude Code 的本地配置其中agents/子目录定义了五个职责各异的审查子代理code-quality-reviewer代码质量、可维护性与整洁代码performance-reviewer本文主角性能瓶颈、资源效率与网络查询优化security-code-reviewer安全漏洞与威胁建模test-coverage-reviewer测试覆盖与测试质量documentation-accuracy-reviewer文档准确性这种一个领域一个专项 Agent的设计让大型 PR 审查可以被拆解为多个并行的、职责单一的审查任务避免单一主代理因上下文过长而遗漏关键检查点。performance-reviewer 专注回答一个核心问题这段代码在生产规模下是否足够高效是否存在可量化的性能隐患1.1 Frontmatter子代理的身份证performance-reviewer.md 顶部是标准的 YAML frontmatter共四个字段字段值含义nameperformance-reviewer子代理的唯一标识供主代理通过Task工具按名调用description一句话 五个典型触发场景告诉主代理什么情况下应该启用本代理的关键元数据toolsGlob, Grep, Read, WebFetch, TodoWrite, WebSearch, BashOutput, KillBash允许子代理使用的工具白名单modelinherit继承当前会话使用的模型不单独指定description字段是子代理编排的路由依据——主代理main agent会根据任务描述与各子代理 description 的匹配程度决定是否委派。该字段给出的五个典型使用场景值得注意实现数据库查询或 API 调用之后写完后立刻审查数据访问层优化已有功能时对存量代码做性能体检编写数据处理逻辑之后循环、批量处理、聚合计算类代码排查应用响应缓慢时定位慢请求根因完成任何涉及循环、网络请求或内存密集型操作的代码后覆盖最通用的触发面。tools字段限定了子代理的能力边界它只读不写——可以Glob/Grep/Read检索与阅读代码、WebSearch/WebFetch查证外部资料、用BashOutput/KillBash观察运行输出但没有Edit/Write等修改工具。这是有意为之审查代理的职责是发现问题并给出修复建议修改代码应回到主代理或其他执行代理手中防止审查代理在分析中途擅自改动代码。1.2 角色定位跨层级的性能优化专家frontmatter 之后的正文第一段给出了角色设定You are an elite performance optimization specialist with deep expertise in identifying and resolving performance bottlenecks across all layers of software systems.关键词有两个all layers所有软件层次与actionable可执行。这个 Agent 的审查范围不仅限于单函数内的算法效率而是覆盖从算法复杂度、网络 I/O、数据库访问到内存管理的全链路。同时它的产出必须是可行动的优化建议而非笼统的这里性能不好。二、审查维度一性能瓶颈分析Performance Bottleneck Analysis这是性能审查的第一道关卡聚焦代码本身的执行效率。Agent 从五个角度切入2.1 算法复杂度审查识别 O(n²) 或更差的操作例如嵌套循环遍历同一数据集、在循环内反复调用 O(n) 的数组操作indexOf、includes、数组内splice都可能导致平方级退化建议的优化方向使用哈希表Map/Set换取 O(1) 查找、提前排序后用双指针、对可索引结构改用二分查找等。2.2 冗余计算检测不必要的重复计算同一表达式在循环体内被反复求值且结果与循环变量无关可缓存的中间结果memoization记忆化候选——相同输入反复出现的纯函数调用重复请求去重request deduplication同一资源在同一请求批次中被多次获取。2.3 阻塞操作与异步化识别可能阻塞事件循环event loop或主线程的操作评估其是否可以迁移到异步执行、工作线程或消息队列对 Node.js/Bun 环境要特别注意同步文件 I/O、大规模同步计算对并发能力的拖累。2.4 循环结构优化检查低效迭代方式在循环内做高开销操作、嵌套循环是否可以被拍平flatten、是否能通过一次遍历完成多次统计循环体内是否创建了本可提升到循环外的对象或闭包。2.5 过早优化 vs 真实瓶颈这是该维度中颇具工程智慧的一条Agent 需要区分过早优化premature optimization与正当的性能关注legitimate performance concerns。并非所有微优化都值得做——只有在可测量的热点路径上、以可验证的性能数据为依据的优化才有意义。这与审查的影响 vs 成本优先级排序一脉相承。三、审查维度二网络查询效率Network Query Efficiency后端代码的大部分性能问题都发生在数据访问层本维度专门覆盖与外部系统数据库、API交互的效率。3.1 数据库查询N1 问题与缺失索引N1 问题循环内逐条查询关联数据1 次主查询 N 次子查询应改为 JOIN 或批量预取eager loading缺失索引WHERE、ORDER BY、JOIN条件列缺少索引导致全表扫描投影过宽SELECT *拉取了不需要的列。3.2 API 调用批处理与往返次数审查是否存在可以合并的多次独立调用batching识别不必要的网络往返round trips例如先查列表再逐条查详情可改为一次批量详情查询检查分页pagination、过滤filtering、投影projection是否在数据获取阶段就正确应用而不是把全量数据拉到内存再裁剪。3.3 缓存、记忆化与请求去重对热点数据是否可以考虑缓存层纯函数计算结果是否值得memoization并发场景下同一请求是否可以被去重合并request deduplication。3.4 连接池与资源复用数据库连接、HTTP 客户端、gRPC channel 等重量级资源是否复用了连接池而非每次请求新建连接池大小是否与并发模型匹配。3.5 重试风暴Retry Storm防护Verify proper error handling that doesnt cause retry storms.一个常被忽视的隐患错误的失败处理反而放大故障。当服务端过载或依赖故障时如果客户端无退避地疯狂重试会形成重试风暴把依赖彻底压垮。Agent 需要检查重试逻辑是否具备指数退避exponential backoff与抖动jitter。这一检查点在 claude-code-action 仓库中有直接的实现参照仓库统一封装了retryWithBackoff工具src/utils/retry.ts其实现位于 base-action/src/retry.ts。该实现默认maxAttempts 3、initialDelayMs 5000、maxDelayMs 20000、backoffFactor 2即每次失败后延迟翻倍直至上限且可通过shouldRetry回调对不可重试错误立即放弃。审查 Agent 在评估错误处理是否可能引发重试风暴时可对照此类实现核查是否缺失退避、退避上限是否缺失、是否对永久性错误如 4xx也盲目重试。四、审查维度三内存与资源管理Memory and Resource Management本维度聚焦运行时资源生命周期覆盖内存泄漏、对象生命周期与资源清理。4.1 内存泄漏检测未关闭的连接数据库连接、HTTP 连接、WebSocket未移除的事件监听器长期存活对象上反复注册监听器循环引用在带引用计数或缺乏可达性分析的运行时中循环引用阻止回收全局/模块级缓存的无限增长Map 作为缓存却无淘汰策略。4.2 对象生命周期与 GC 影响审查对象的创建与释放时机是否匹配识别循环内的过量内存分配或大对象创建——例如在循环体内重复new大数组、字符串拼接在循环中产生大量中间对象应使用 Buffer/数组 join/字符串构建器。4.3 清理逻辑的兜底检查cleanup函数、析构函数destructor或finally块中的资源释放是否正确兜底异常路径上资源是否会泄漏——例如 try 块中获取连接、异常时跳过 finally 导致连接永不归还。4.4 数据结构选型的空间效率分析数据结构的内存效率例如用Map替代稀疏数组、避免不必要的装箱boxing、选择紧凑的序列化格式大集合场景下评估分页/流式处理而非一次性加载。4.5 文件句柄与资源清理文件读写后是否关闭句柄数据库连接归还连接池而非泄漏临时文件、锁资源、句柄类资源是否有统一清理路径。五、输出结构规范如何呈现一份可执行的性能审查报告性能审查的价值最终体现在报告的可执行性上。performance-reviewer 要求输出严格遵循四段式结构5.1 四段式报告模板Critical Issues关键问题需要立即关注的性能问题——通常是会导致线上事故、明显响应退化或资源耗尽的问题Optimization Opportunities优化机会能带来可衡量收益的改进——不是必须立刻做但做了有明显回报Best Practice Recommendations最佳实践建议面向未来的预防性措施——在后续开发中避免同类问题复现Code Examples代码示例具体的 before/after 代码片段演示改进前后的差异。第四点代码示例是这份模板区别于普通代码审查的关键性能问题必须配可执行的修复示例而不是只描述现象。5.2 单条问题的四要素对识别出的每一条问题Agent 必须报告要素要求精确位置指明文件、函数、行号file, function, line numbers性能影响用估算的复杂度或资源占用说明影响如该循环为 O(n²)n10k 时需执行 1 亿次比较具体方案给出可落地、可实施的解决方案优先级按影响 vs 投入impact vs. effort排序建议其中影响 vs 投入排序是性能优化领域的核心决策框架高影响低投入的优化优先做低影响高投入的优化要谨慎评估 ROI。5.3 正向反馈与场景适配模板的最后特别要求两点若代码表现良好要明确确认confirm this explicitly并指出特别优化到位的部分——避免审查沦为为找问题而找问题始终结合具体的运行时环境与规模要求specific runtime environment and scale requirements给出建议——例如嵌入式环境与高并发云服务对内存策略的要求截然不同不能一概而论。六、在 claude-code-action 中实战从 Agent 定义到 PR 审查工作流performance-reviewer 不是孤立存在的文档它在仓库中与命令、工作流、运行时机制深度耦合。理解这条链路才能真正把它用起来。6.1 命令入口review-pr 的编排逻辑仓库的 review-pr 命令 展示了主代理如何编排五个审查子代理Perform a comprehensive code review using subagents for key areas:code-quality-reviewerperformance-reviewertest-coverage-reviewerdocumentation-accuracy-reviewersecurity-code-reviewer命令的核心编排策略有三点并行委派五个子代理分别审查各自的专业领域主代理汇总只上报值得注意的问题指示每个子代理only provide noteworthy feedback主代理在最终汇总时再次过滤——review the feedback and post only the feedback that you also deem noteworthy分级输出针对具体问题用内联评论inline comments针对总体观感或表扬用顶层评论top-level comments且要求Keep feedback concise。这也是该命令通过allowed-tools将工具白名单收敛为Bash(gh pr comment:*)、Bash(gh pr diff:*)、Bash(gh pr view:*)的原因——子代理审查需要读取 PR diff主代理发评论需要 gh 包装命令。6.2 运行机制Agent 模式如何把审查流程跑起来子代理体系运行在 claude-code-action 的agent 模式下。根据 src/modes/detector.ts 的detectMode逻辑模式由工作流上下文自动判定当配置了prompt输入时走 agent 模式绕过claude提及检测否则在评论事件中检测到触发词时走 tag 模式。其判定优先级为track_progress且命中 PR/issue 事件 → 强制 tag 模式评论事件 配置了prompt→ agent 模式评论事件 检测到claude触发词 → tag 模式issue 事件、PR 事件opened/synchronize/ready_for_review/reopened同理兜底返回 agent 模式。agent 模式的具体准备逻辑见 src/modes/agent/index.ts它把用户prompt直接写入RUNNER_TEMP/claude-prompts/claude-prompt.txt解析CLAUDE_ARGS中的--allowedToolsparse-tools并注入仓库自带的 GitHub MCP servers 配置。这意味着只要在工作流的prompt中输入要求执行性能审查的指令或引用 review-pr 这类命令performance-reviewer 就会在 agent 会话中被调用。6.3 完整工作流示例综合 PR 审查仓库提供了可直接落地的综合 PR 审查示例 examples/pr-review-comprehensive.yml通过track_progress: true获得进度跟踪评论prompt中明确列出包含性能在内的五个审查重点Code Quality、Security、Performance、Testing、Documentation并用claude_args限定--allowedTools mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)。其中性能部分要求 ClaudeIdentify potential performance bottlenecksReview database queries for efficiencyCheck for memory leaks or resource issues这与 performance-reviewer 的三大审查维度一一对应。若希望审查由专职子代理执行可在prompt中直接引用 review-pr 命令或显式指定委派 performance-reviewer。6.4 内联评论缓冲防止子代理污染PR当子代理继承内联评论工具时一个真实风险是子代理在遭遇无关错误后试探性地调用评论工具产生测试/探测性质的评论污染 PR。仓库通过内联评论 MCP 服务器src/mcp/github-inline-comment-server.ts解决了这个问题调用create_inline_comment时若不带confirmed: true评论不会立即发布而是被缓冲到/tmp/inline-comments-buffer.jsonl会话结束后缓冲评论经 Haiku 分类真实审查评论才会发布测试/探测评论被丢弃该机制由classify_inline_comments输入控制默认true参见 docs/usage.md。因此在编排子代理审查时应要求子代理不要在分析阶段提交评论而由主代理在汇总确认后统一发布——这正对应 review-pr 命令中由主代理过滤后再发评论的设计。6.5 相关配置与输入项速查结合 docs/usage.md 的输入参数表与子代理审查工作流直接相关的配置项包括输入项作用prompt自动化工作流的指令可声明执行性能审查或引用审查命令claude_args直接透传给 Claude CLI 的参数如--allowedTools、--max-turns 10保证多轮子代理编排有足够预算track_progress强制 tag 模式并生成带进度复选框的跟踪评论仅限 PR/issue 事件classify_inline_comments控制内联评论缓冲分类防止子代理测试评论上 PRinclude_fix_links在 PR 审查反馈中附带 Fix this 链接点击即可带着上下文打开 Claude Code 修复问题trigger_phrase自定义 tag 模式触发词默认claude七、性能审查 Agent 的使用边界与最佳实践综合前文这里总结在 claude-code-action 场景下使用 performance-reviewer 的几条最佳实践触发时机前置按 description 中的建议在写完数据库查询、API 调用、数据处理逻辑后立即审查而不是等功能全部完成后再补审让子代理专注于报告主代理负责发布子代理产出四段式报告与 before/after 代码示例由主代理过滤、去重后以confirmed: true发布内联评论用claude_args控制资源预算多子代理编排会消耗较多轮次通过--max-turns设定上限避免审查任务无限扩展审查建议要可验证性能建议应附带复杂度估算或测量方法benchmark 思路而非主观断言——这与影响 vs 投入排序配合让开发者能快速决策注意安全边界agent 模式允许指定--allowedTools白名单性能审查场景保持只读工具集Glob、Grep、Read 等避免审查代理获得写权限关于权限与安全的更完整说明见 docs/security.md。八、结语performance-reviewer 是 claude-code-action 五维审查体系中的重要一环它用精确的 frontmatter 声明、三大审查维度算法与循环、网络查询、内存资源与四段式输出模板把性能优化从经验性话题转化为可重复执行的审查流程。配合仓库的 review-pr 编排命令、agent 模式的 prompt 注入机制、内联评论缓冲与分类能力开发者可以在 GitHub Actions 中搭建出多专家并行审查 → 主代理过滤汇总 → 内联评论精确定位 → Fix 链接一键修复的完整闭环。当代码审查不再是单一大模型的通才视角而是由各领域专职 Agent 各司其职时性能问题的发现将更早、更准、更可执行。【免费下载链接】claude-code-action项目地址: https://gitcode.com/GitHub_Trending/cl/claude-code-action创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考