当代码仓库、团队和 Pull Request 数量增长到一定规模，代码评审就不再只是“找一个人看 diff”。完全依赖人工会受到吞吐量和上下文切换的限制，而把现成的 AI Reviewer 直接接到 GitHub，也容易产生误报、低信号评论和脱离组织规范的建议。
LinkedIn 的实践方向是构建一个面向组织内部的多智能体 AI Code Review 平台：让不同智能体承担不同的分析任务，把企业代码上下文纳入判断，并把代码评审当作需要监控、治理和持续优化的生产基础设施。
为什么单一 AI Reviewer 不够
一个通用模型可以理解常见的代码模式，但它通常不知道以下信息：
- 某个服务是否允许使用特定数据库调用。
- 某个团队对日志、异常处理和 API 兼容性的约定。
- 某个目录中的代码是否属于高风险基础组件。
- 某条规则是否已经被静态检查器覆盖。
- 某个变更是否与当前仓库的架构边界冲突。
因此，直接让模型阅读整个 Pull Request，往往会把“看起来可疑”误认为“确实需要修复”。在大规模代码库中，错误评论的成本并不只是模型调用费用，还包括开发者阅读、验证和关闭评论的时间。低质量反馈积累后，团队会逐渐忽略真正重要的告警。
可以把高质量评审目标写成一个简单的约束：
有效评论 = 真实问题 × 与当前变更相关 × 开发者可以采取行动
只要其中一项接近零，评论就不应该进入 Pull Request 的主反馈流。
多智能体如何拆分评审任务
多智能体架构的重点不是同时启动更多模型，而是把代码评审拆成边界清晰、可以独立验证的任务。例如可以这样设计：
- 变更理解智能体：识别修改了哪些模块、调用链和公开接口。
- 规范检查智能体：结合团队规则、仓库配置和历史约定检查编码规范。
- 安全分析智能体：关注权限、输入校验、敏感数据和危险 API。
- 测试分析智能体：判断变更是否需要新增或调整测试，以及现有测试是否覆盖关键路径。
- 结果裁决智能体：合并各个分析结果，去重、排序并过滤低置信度评论。
每个智能体都应该有明确的输入、输出和证据要求。比如安全分析智能体不能只返回“这里可能有安全问题”，而应该指出触发风险的代码位置、数据流以及建议的修复方向。
一个适合落地的中间结果格式可以是 JSON：
{
"agent": "security",
"file": "services/user.py",
"line": 42,
"severity": "high",
"confidence": 0.93,
"finding": "User-controlled redirect target is passed without allowlist validation.",
"evidence": [
"redirect_url comes from the request query parameter",
"redirect() is called without domain validation"
],
"suggested_action": "Validate the target against an approved host allowlist."
}
这里的 confidence 不能被当作绝对真值，但可以帮助裁决层设置发布阈值。高风险且高置信度的问题可以直接评论；低置信度的问题则可以进入内部报告，等待人工确认。
组织上下文决定反馈质量
企业代码评审最难的部分通常不是解释语法，而是理解上下文。平台需要把上下文作为受控数据源提供给智能体，而不是让模型凭空猜测。
可以这样实践一个最小化的上下文装载流程：
#!/usr/bin/env bash
set -euo pipefail
PR_NUMBER="${1:?usage: ./collect-context.sh <pr-number> <repo> <base-sha> <head-sha>}"
REPO="${2:?missing repository, for example org/service}"
BASE_SHA="${3:?missing base sha}"
HEAD_SHA="${4:?missing head sha}"
mkdir -p review-context
git diff --no-ext-diff --unified=80 "$BASE_SHA" "$HEAD_SHA" > review-context/patch.diff
git diff --name-only "$BASE_SHA" "$HEAD_SHA" > review-context/changed-files.txt
gh pr view "$PR_NUMBER" --repo "$REPO" \
--json title,body,author,labels,baseRefName,headRefName \
> review-context/pr.json
find . -maxdepth 3 -type f \( \
-name 'CONTRIBUTING.md' -o \
-name 'CODEOWNERS' -o \
-name 'review-policy.yml' \
\) -print > review-context/policy-files.txt
printf 'Context collected in review-context/\n'
运行前需要安装并登录 GitHub CLI，并把仓库的基准提交和当前提交替换为真实值：
chmod +x collect-context.sh
./collect-context.sh 1234 linkedin/service abc123 def456
生产平台还可以加入以下上下文来源：
- 仓库级和团队级评审规则。
- 代码所有者和服务目录信息。
- 相关模块的历史变更和已确认缺陷。
- 静态分析、单元测试和构建流水线结果。
- 已被团队接受或拒绝的历史 AI 评论。
上下文并不是越多越好。应按变更文件和调用关系筛选，避免把无关文档、完整仓库或大量历史记录全部塞给模型。过多噪声会增加成本，也会降低模型对关键证据的注意力。
把 Code Review 当作生产系统运营
当 AI 评审进入日常开发流程，它就需要具备生产系统的治理能力。仅仅记录模型是否返回结果是不够的，平台至少应该跟踪：
- 每个 Pull Request 的评审延迟。
- 每个智能体的调用成功率和超时率。
- 评论被开发者采纳、修改或关闭的比例。
- 按规则、仓库和严重级别统计的误报率。
- 模型、提示词和上下文版本变化后的结果差异。
评论发布也应该有明确的策略。例如：
review_policy:
publish:
min_confidence: 0.85
allowed_severities:
- critical
- high
report_only:
min_confidence: 0.60
suppress:
duplicate_similarity: 0.90
max_comments_per_file: 3
这份配置只是可改造的示例，不代表某个组织的固定规则。它表达了一个重要边界：AI 不应该因为发现很多可能的问题，就把所有内容全部推送给开发者。评论数量、置信度和严重级别都需要受到控制。
采用时需要保留的边界
多智能体并不能自动消除幻觉。它只是提供了更好的任务分工和验证位置。平台仍然需要让模型引用具体代码证据，并在无法确认时选择不评论。
比较稳妥的引入顺序是：
- 先以报告模式运行，只记录结果，不阻塞合并。
- 用人工反馈建立误报和高价值案例集。
- 只对高置信度、高严重级别问题发布评论。
- 为不同语言、仓库和团队维护明确的上下文边界。
- 持续评估评论采纳率、误报率和开发者耗时。
真正值得投入的指标不是“模型生成了多少条评论”，而是它是否帮助团队更快发现真实缺陷，同时没有制造新的审查负担。对大规模组织而言，AI Code Review 的核心竞争力也不只是模型本身，而是上下文管理、智能体协作、反馈闭环和生产治理能力。