"如果现代 LLM 能处理 200k tokens，为什么不直接发送 diff 加上相关上下文让模型自己搞定？所有这些智能体复杂性有什么意义？"
提示词只能看到你发送的内容。对于有意义的代码审查，你需要整个代码库的上下文——导入、依赖、相关文件、测试、约定。
研究证明往 LLM 里塞更多上下文 实际上损害性能。这叫做「上下文稀释」。
10-20%
文档过多导致的性能下降
U 形曲线
中间的信息会「丢失」
60-80%
上下文堆砌工具的误报率
智能体不只是「更好地阅读提示词」。它们 主动调查 你的代码库：
按需获取相关文件，而不是预先堆砌所有内容
"我怀疑有类型不匹配" → 搜索调用者 → 用静态分析确认
跨文件追踪线索，发现可疑时深入挖掘
运行 linter、类型检查器和分析器用真实数据验证发现
提示词只能看到你给它的内容。
智能体 找到它需要的内容。
有用审查和噪音的区别不在于你有多少上下文——而在于有 正确的 上下文
审查开始前，我们构建文件连接方式的映射——导入、导出、类型定义和调用链
每个智能体只收到与其任务相关的上下文——安全智能体获取认证流程，而不是 UI 样式
智能体只在需要时获取额外上下文——追踪线索而不预先过载
核心上下文（diff、类型）常驻；周围上下文（调用者、测试）按需加载
200k tokens 的一切——diff、完整文件、随机依赖...
聚焦块——diff + 直接依赖 + 相关模式
单次 LLM 调用审查代码有根本限制
限于你提供的 diff
无迭代或验证
对依赖和上下文视而不见
无法验证声明
注意力分散在所有关注点上
"确保调用者已更新"
导航整个项目
追踪线索，深入挖掘
理解导入和依赖
运行静态分析器确认
每个智能体专注一个领域
"3 个调用点在第 45、89、112 行有类型不匹配"
区别在于 猜测 和 调查。
智能体是能够思考、行动和验证的 AI 系统
读取文件、搜索代码、运行静态分析器
根据发现选择调查什么
追踪线索、验证假设、深入挖掘
根据真实数据验证推理
当 diffray 审查你的 PR 时，智能体不只是"看看 diff"
追踪导入以理解更改的代码如何影响整个系统
检查测试、配置和文档以获取上下文
运行静态分析确认怀疑的问题实际存在
查找类型定义、API 契约和约定
考虑 PR 中的函数签名更改：
"这改变了返回类型，确保调用者已更新"
通用建议。无具体内容。
→ "发现 3 个破坏性更改：src/api/users.ts:45、src/hooks/useAuth.ts:89、src/utils/validate.ts:112"
要真正理解更改，你需要看它们如何融入整个代码库
添加了新函数 formatUserName()
语法上看起来正确
这 20 行没有明显 Bug
结论："LGTM"——但完全错过了大局
此函数与 utils/names.ts:formatName() 重复
现有函数处理了这个遗漏的边缘情况
其他 3 个文件已经使用现有工具函数
这违反了 /docs/CONVENTIONS.md 中的命名约定
结论："考虑使用 utils/names.ts 中现有的 formatName()"
开发者是否在重新发明轮子？代码库中是否已存在类似解决方案？
这些更改是否遵循已建立的模式？还是引入了冲突的方法？
这些更改如何影响系统的其余部分？什么依赖于修改的代码？
是否遵循了团队约定和文档化的标准？
Diff 显示 什么改变了。 全代码库上下文显示 是否应该改变。
实现真正多智能体协作的强大基础
每次审查都经过多阶段流水线，每个阶段都为其目的优化
克隆
获取仓库并检出 PR
数据准备
构建依赖图
总结
LLM 总结更改
分类
将文件路由到智能体
规则
加载和过滤规则
审查
并行智能体分析
去重
合并和重新评分
验证
验证和重新评分
报告
生成 PR 评论
克隆
获取仓库并检出 PR
数据准备
构建依赖图
总结
LLM 总结更改
分类
将文件路由到智能体
规则
加载和过滤规则
审查
并行智能体分析
去重
合并和重新评分
验证
验证和重新评分
报告
生成 PR 评论
结果
一个将 AI 推理与具体代码分析相结合的多智能体系统——提供 准确、经过验证的发现 而不是猜测。