多智能体并行代码审查

为什么需要分维度的审查

单次对话里让模型「顺便看看代码」，往往会在安全、性能与测试之间浅尝辄止，或者把风格问题与安全漏洞混在同一优先级里。团队真正需要的是：同一批变更上，架构边界、威胁面、热点路径、可读性与测试缺口能被分开审视，最后再合并成一份可执行的清单。

技能如何工作

技能把审查流程固定为四段式编排，由主编 Agent 负责调度，而不是让一个角色包办全部结论。

1. Phase 1 任务分析：识别语言与框架，决定加载哪份语言指南（如 TypeScript、Python、Go），并把工作拆给各专业审查 Agent。
2. Phase 2 并行审查：同时启动五类专职 Agent，各自写入独立报告文件：

- Architecture Reviewer → architecture-review.md（模块设计、依赖、架构模式）
- Security Reviewer → security-review.md（漏洞、注入、认证授权）
- Performance Reviewer → performance-review.md（热点、复杂度、N+1）
- Code Quality Reviewer → quality-review.md（风格、可读性、实践）
- Testing Reviewer → testing-review.md（覆盖、边界、Mock）

1. Phase 3 报告汇总：收集各 Agent 输出，生成结构化总结。
2. Phase 4 严重性标注：用统一标签分级，例如 🔴 [blocking]、🟡 [important]、🟢 [nit]、💡 [suggestion]、📚 [learning]、🎉 [praise]。

默认输出 Markdown；若明确要求 HTML，则生成带内联 CSS、严重性配色、代码高亮与响应式布局的自包含页面，便于邮件或内嵌系统。

适用边界

语言规则来自按需加载的 references/languages/*.md，未覆盖的语言仍可做通用审查，但细粒度规范会弱于已维护指南。并行多 Agent 意味着上下文与调用成本更高，适合 PR、发布前或高风险模块，而不是每一行 diff 都走全套五路审查。