一个功能分支写完以后，真正让人不放心的往往不是代码能不能编译，而是另外一些更隐蔽的问题。测试是不是只覆盖了 happy path，异常是不是被某个catch悄悄吃掉了，新增加的类型是不是允许出现非法状态，几个月前写下的注释是不是已经和实现发生偏离，某段看起来运行正常的代码是不是已经复杂到下一次修改时很容易出错。传统的 Code Review 通常把这些事情全部交给同一个 Reviewer。Reviewer 一边理解业务逻辑，一边检查异常处理，一边思考测试覆盖率，还要盯着编码规范、命名、注释和可维护性。人的注意力会不断在不同维度之间切换，很容易出现一种熟悉的情况，业务逻辑认真看了，测试没仔细看，测试看完以后异常路径又被忽略。Anthropic 官方提供的pr-review-toolkit走了另一条路线。它没有试图做一个无所不包的超级 Reviewer，而是把 Pull Request Review 拆成多个相对独立的问题，再交给 6 个拥有不同审查职责的 Agent。官方插件目录对它的定位非常明确，它关注代码注释、测试覆盖、错误处理、类型设计、通用代码质量以及代码简化，并提供review-pr作为综合审查入口。当前官方仓库中包含的 6 个 Agent 分别是comment-analyzer、pr-test-analyzer、silent-failure-hunter、type-design-analyzer、code-reviewer和code-simplifier。
一个功能分支写完以后，真正让人不放心的往往不是代码能不能编译，而是另外一些更隐蔽的问题。测试是不是只覆盖了 happy path，异常是不是被某个catch悄悄吃掉了，新增加的类型是不是允许出现非法状态，几个月前写下的注释是不是已经和实现发生偏离，某段看起来运行正常的代码是不是已经复杂到下一次修改时很容易出错。传统的 Code Review 通常把这些事情全部交给同一个 Reviewer。Reviewer 一边理解业务逻辑，一边检查异常处理，一边思考测试覆盖率，还要盯着编码规范、命名、注释和可维护性。人的注意力会不断在不同维度之间切换，很容易出现一种熟悉的情况，业务逻辑认真看了，测试没仔细看，测试看完以后异常路径又被忽略。Anthropic 官方提供的pr-review-toolkit走了另一条路线。它没有试图做一个无所不包的超级 Reviewer，而是把 Pull Request Review 拆成多个相对独立的问题，再交给 6 个拥有不同审查职责的 Agent。官方插件目录对它的定位非常明确，它关注代码注释、测试覆盖、错误处理、类型设计、通用代码质量以及代码简化，并提供review-pr作为综合审查入口。当前官方仓库中包含的 6 个 Agent 分别是comment-analyzer、pr-test-analyzer、silent-failure-hunter、type-design-analyzer、code-reviewer和code-simplifier。
