AI 代码审查的架构设计：事件驱动、插件化与策略热更新
一、为什么 AI 代码审查需要架构化，而非单点脚本
AI 代码审查工具在团队中的落地，最常见的失败模式是"单点脚本"。一段 Python 脚本调用 LLM API，传入 diff 文本，返回审查意见，挂到 CI pipeline 上。短期内跑得通，但三个问题会在规模扩大后暴露。
第一，审查策略无法快速迭代。业务规则变更、新安全策略上线时，修改脚本意味着重新部署整个 CI 流程。审批链路长，回滚成本高。
第二，审查结果的消费方式单一。脚本输出 JSON 或 Markdown，下游消费方（IDE 插件、Slack 通知、合规报表）各自解析，格式一旦调整，所有消费端都要适配。
第三，模型调用与规则引擎耦合。当需要从 GPT-4 切换到本地部署的 CodeLlama，或对特定文件类型走不同模型路由时，改动侵入核心逻辑。
这三个问题的根源：缺乏架构层面的抽象。代码审查本质上是一个事件驱动的数据处理流程——代码变更触发事件，事件经过一系列策略插件处理，最终产出结构化审查结果。将这个流程建模为事件驱动 + 插件化的架构，才能解耦策略定义、模型调用和结果消费。
二、事件驱动的审查流水线：从 Git Hook 到消息队列
代码审查的触发源不止 CI pipeline。Git push、MR 创建、定时全量扫描、人工触发——这些都是事件源。用事件驱动架构统一接入，比硬编码 trigger 更灵活。
flowchart LR
A[Git Push Hook] –> E[Event Bus]
B[MR Webhook] –> E
C[定时扫描 Cron] –> E
D[手动触发 API] –> E
E –> F1[Event: code_diff]
E –> F2[Event: full_scan]
F1 –> G[审查引擎]
F2 –> G
G –> H1[IDE 插件通知]
G –> H2[Slack/飞书告警]
G –> H3[合规报表存储]
核心设计：Event Bus 作为唯一事件入口。所有事件源只负责将结构化事件推入 Bus，不直接调用审查引擎。Event 的 payload 包含 repo、分支、diff 内容、触发者、时间戳等元数据。
// 事件定义：结构化的审查触发事件
interface ReviewEvent {
type: 'code_diff' | 'full_scan' | 'manual_trigger';
repo: string;
branch: string;
// diff 内容或全量文件列表
payload: DiffPayload | FullScanPayload;
triggeredBy: string;
timestamp: number;
// 事件优先级，影响排队顺序
priority: 'critical' | 'normal' | 'low';
}
// 事件总线：负责事件的接收、过滤与分发
class ReviewEventBus {
private queue: PriorityQueue<ReviewEvent>;
private handlers: Map<string, EventHandler[]>;
/**
* 发布事件到总线
* 事件经过过滤器后进入优先级队列
*/
async publish(event: ReviewEvent): Promise<void> {
// 过滤规则：忽略大于 5000 行的 diff，避免模型 token 超限
if (event.type === 'code_diff') {
const diffLines = (event.payload as DiffPayload).diffText.split('\\n').length;
if (diffLines > 5000) {
await this.emitSkipped(event, 'diff_exceeds_limit');
return;
}
}
await this.queue.enqueue(event, event.priority);
await this.dispatch(event);
}
/**
* 注册事件处理器
* 支持多个处理器并行消费同一事件
*/
subscribe(eventType: string, handler: EventHandler): void {
const existing = this.handlers.get(eventType) ?? [];
this.handlers.set(eventType, […existing, handler]);
}
private async dispatch(event: ReviewEvent): Promise<void> {
const handlers = this.handlers.get(event.type) ?? [];
// 并行执行所有处理器，但捕获单个失败不影响其他
const results = await Promise.allSettled(
handlers.map(handler => handler.process(event))
);
const failures = results.filter(r => r.status === 'rejected');
if (failures.length > 0) {
await this.logHandlerFailures(event, failures);
}
}
}
事件驱动的好处显而易见：新增触发源只需实现一个 publisher，不需要修改引擎代码。事件过滤在 Bus 层集中处理，避免下游重复判断。
三、插件化的策略引擎：规则、模型与后处理的三层解耦
审查策略不是一个 monolith。它至少包含三层：规则筛选层（决定哪些 diff 需要审查）、模型调用层（选择合适的 AI 模型执行分析）、后处理层（对模型输出做结构化、过滤、打标签）。三层各自独立演进，通过插件接口组合。
// 插件接口定义：所有审查策略插件必须实现
interface ReviewPlugin {
name: string;
// 插件执行阶段：filter | analyze | postprocess
phase: 'filter' | 'analyze' | 'postprocess';
// 插件优先级，同阶段内按优先级排序执行
order: number;
// 核心处理方法
process(context: ReviewContext): Promise<ReviewContext>;
}
// 审查上下文：在插件链中流转的共享状态
interface ReviewContext {
event: ReviewEvent;
// 经过 filter 阶段后保留的 diff 片段
filteredDiffs: DiffChunk[];
// 经过 analyze 阶段后的模型原始输出
rawResults: ModelOutput[];
// 经过 postprocess 阶段后的结构化结果
finalResults: ReviewResult[];
// 插件间共享的元数据
metadata: Record<string, unknown>;
}
// 策略引擎：按阶段组织插件链式执行
class StrategyEngine {
private plugins: Map<string, ReviewPlugin[]> = new Map();
/**
* 注册插件到对应阶段
* 同阶段插件按 order 排序
*/
register(plugin: ReviewPlugin): void {
const phasePlugins = this.plugins.get(plugin.phase) ?? [];
phasePlugins.push(plugin);
phasePlugins.sort((a, b) => a.order – b.order);
this.plugins.set(plugin.phase, […phasePlugins]);
}
/**
* 执行审查流水线
* 依次执行 filter → analyze → postprocess 三阶段
*/
async execute(context: ReviewContext): Promise<ReviewContext> {
const phases: string[] = ['filter', 'analyze', 'postprocess'];
for (const phase of phases) {
const plugins = this.plugins.get(phase) ?? [];
for (const plugin of plugins) {
try {
context = await plugin.process(context);
} catch (error) {
// 单个插件失败不中断整个流水线
await this.handlePluginError(plugin, error as Error);
}
}
}
return context;
}
}
插件化使得策略组合成为声明式的。以下是一个具体的插件示例——基于文件类型的模型路由插件：
// 模型路由插件：根据文件类型选择不同 AI 模型
const modelRouterPlugin: ReviewPlugin = {
name: 'model-router',
phase: 'analyze',
order: 10,
async process(context: ReviewContext): Promise<ReviewContext> {
const modelAssignments: ModelAssignment[] = [];
for (const diff of context.filteredDiffs) {
// 根据文件扩展名选择模型
const ext = diff.filePath.split('.').pop() ?? '';
const model = selectModelByFileType(ext);
// 调用模型并记录原始输出
const output = await callModel(model, diff.content);
modelAssignments.push({
diffId: diff.id,
model: model.name,
output,
latency: output.latencyMs,
});
}
context.rawResults = modelAssignments;
return context;
},
};
// 模型选择策略：安全类文件走本地模型，其余走云端
function selectModelByFileType(ext: string): AIModel {
const securityFiles = ['env', 'conf', 'yaml', 'yml'];
if (securityFiles.includes(ext)) {
return { name: 'local-codemodel', endpoint: 'http://localhost:8080/v1' };
}
return { name: 'gpt-4', endpoint: 'https://api.openai.com/v1' };
}
四、策略热更新：不停机、不重部署的规则迭代
生产环境中，审查策略需要频繁调整：新增安全规则、调整误报阈值、切换模型版本。如果每次变更都需要重新部署 CI runner 或重启审查服务，运维成本会吞噬工程收益。
策略热更新的实现路径：将策略配置从代码中抽离，存入可外部更新的配置中心（Git 仓库、数据库或配置服务），引擎在运行时动态加载。
flowchart TB
A[策略配置仓库] –> B[配置监听服务]
B –> C[变更事件]
C –> D[Strategy Engine]
D –> E[插件注册表更新]
E –> F[新策略生效]
E –> G[旧策略卸载]
H[模型版本切换] –> B
I[阈值调整] –> B
J[新规则添加] –> B
// 策略配置结构：可热更新的规则定义
interface StrategyConfig {
version: string;
rules: RuleDefinition[];
modelRouting: ModelRoutingConfig;
thresholds: ThresholdConfig;
// 插件开关：可动态启用/禁用插件
pluginSwitches: Record<string, boolean>;
}
// 策略热更新服务：监听配置变更并实时生效
class StrategyHotReload {
private currentConfig: StrategyConfig;
private engine: StrategyEngine;
private configWatcher: ConfigWatcher;
constructor(engine: StrategyEngine, configSource: ConfigSource) {
this.engine = engine;
this.configWatcher = new ConfigWatcher(configSource);
this.configWatcher.on('change', this.handleConfigChange.bind(this));
}
/**
* 处理配置变更事件
* 对比新旧配置，增量更新插件注册表
*/
private async handleConfigChange(newConfig: StrategyConfig): Promise<void> {
const diff = this.computeConfigDiff(this.currentConfig, newConfig);
// 禁用被关闭的插件
for (const pluginName of diff.disabledPlugins) {
await this.engine.unregister(pluginName);
}
// 启用新开放的插件
for (const pluginName of diff.enabledPlugins) {
const plugin = await this.loadPlugin(pluginName, newConfig);
await this.engine.register(plugin);
}
// 更新阈值和模型路由（运行时参数，无需重启）
this.updateRuntimeParams(newConfig.thresholds, newConfig.modelRouting);
this.currentConfig = newConfig;
await this.logConfigUpdate(diff);
}
/**
* 计算配置增量差异
* 只返回变化部分，避免全量重建
*/
private computeConfigDiff(
oldConfig: StrategyConfig,
newConfig: StrategyConfig
): ConfigDiff {
const disabledPlugins = Object.entries(newConfig.pluginSwitches)
.filter(([name, enabled]) => !enabled && oldConfig.pluginSwitches[name])
.map(([name]) => name);
const enabledPlugins = Object.entries(newConfig.pluginSwitches)
.filter(([name, enabled]) => enabled && !oldConfig.pluginSwitches[name])
.map(([name]) => name);
return { disabledPlugins, enabledPlugins };
}
}
热更新有一个关键前提：插件卸载必须是安全的。正在执行的插件不能被暴力中断，需要等待当前任务完成后再卸载。这要求引擎维护插件的生命周期状态（idle / running），卸载操作只对 idle 状态的插件生效。
五、总结
AI 代码审查从"脚本"走向"系统"，核心转变是三个架构决策。
第一，事件驱动。所有触发源统一建模为事件，Bus 层集中过滤和分发。新增触发源不需要修改引擎，消费端独立演进。
第二，插件化策略引擎。规则筛选、模型路由、后处理三层各自插件化，组合而非耦合。新模型上线只需注册一个 analyze 插件，新安全规则只需注册一个 filter 插件。
第三，策略热更新。配置从代码中抽离，监听变更、增量生效。插件卸载遵循生命周期安全约束，确保运行中任务不中断。
这三个决策的组合，让 AI 代码审查系统具备三个能力：触发源可扩展、策略可组合、规则可热更新。这不是过度设计——当一个审查系统服务 50 个仓库、对接 3 个模型、每周变更 2 次策略时，架构化是维持系统可控性的唯一路径。
