随着 AI 编码助手在开发工作流中的普及，代码审查环节的自动化需求日益凸显。Cursor 团队在 2025 年 7 月发布的 Bugbot，作为专注于 Pull Request 审查的 AI 代理，经历了从原型到生产系统的完整演进。本文基于 Cursor 官方博客的技术披露，深入分析 Bugbot 架构的演进路径、工程实现细节以及指标驱动的优化策略。
从并行 Passes 到代理化架构的演进
Bugbot 的早期设计采用了相对保守但有效的并行处理架构。面对代码审查这一复杂任务，团队发现单一模型 pass 往往难以覆盖所有潜在问题。因此，他们设计了8 个并行 passes的系统，每个 pass 接收随机化排序的 diff 内容，以此引导模型从不同角度进行推理。
这种设计的核心优势在于多数投票机制：当多个独立的 passes 都标记出同一问题时，该问题的真实性概率显著提高。正如 Cursor 团队在博客中所述：“每个 pass 接收不同的 diff 排序，这促使模型采用不同的推理路径。当几个 pass 独立标记出同一问题时，我们将其视为更强的信号。”
然而，固定流程的并行架构存在固有局限。随着模型能力的提升，团队在 2025 年秋季转向了完全代理化设计。这一转变不仅仅是技术栈的升级，更是思维模式的根本改变。
在代理化架构中，Bugbot 不再遵循预设的审查步骤序列，而是能够自主推理 diff 内容、调用工具、决定深入挖掘的方向。这种灵活性带来了显著的性能提升，但也引入了新的挑战：代理变得过于谨慎。团队不得不调整 prompt 策略，从抑制假阳性转向鼓励代理积极调查每一个可疑模式。
工程基础设施的构建
从原型到生产系统的转变，要求 Bugbot 在工程基础设施层面进行系统性重构。Cursor 团队在这一过程中解决了几个关键问题：
Git 集成的性能优化
代码审查系统对仓库访问的延迟和可靠性极为敏感。Cursor 团队使用Rust 重写了 Git 集成层，显著提升了性能。通过最小化数据获取量，他们不仅减少了网络开销，还更好地适应了 GitHub 等平台的 API 限制。
速率限制与请求批处理
面对大规模部署需求，Bugbot 需要处理数百万个 PR 的审查。团队实现了智能的速率限制监控和请求批处理机制，确保系统在平台约束内稳定运行。代理基础设施的设计使得 Bugbot 能够在不同代码托管平台间无缝切换。
Bugbot 规则系统
实际部署中，不同团队需要检查代码库特定的不变性约束，如不安全的数据库迁移或内部 API 的误用。为此，Cursor 开发了Bugbot 规则系统，允许团队在不修改核心系统的情况下定义自定义检查规则。
指标驱动的质量提升
缺乏量化指标是早期 Bugbot 发展的主要瓶颈。Cursor 团队开发了解决率（Resolution Rate） 这一核心指标，使用 AI 在 PR 合并时判断哪些 bug 被作者实际修复。这一指标的引入改变了整个开发流程。
从 2025 年 7 月的 Version 1 到 2026 年 1 月的 Version 11，Bugbot 的解决率从 52% 提升到超过 70%，同时每个 PR 发现的平均 bug 数从 0.4 增加到 0.7。这意味着每个 PR 解决的 bug 数从约 0.2 增加到约 0.5，实现了超过一倍的性能提升。
团队还建立了BugBench 基准，这是一个包含真实代码 diff 和人工标注 bug 的精选数据集。通过在线（实际解决率）和离线（BugBench）的双重评估，团队能够科学地验证每个架构变更的效果。
动态上下文与工具设计
代理化架构的最大优势之一是动态上下文管理。与早期版本需要将所有相关信息预先加载到静态上下文不同，代理化 Bugbot 能够根据需要在运行时拉取额外上下文。
这种设计显著减少了初始上下文的大小，同时保持了审查的深度。正如博客中提到的：“模型持续拉取它需要的额外上下文，而不需要提前提供所有内容。”
工具设计成为影响代理行为的关键因素。由于模型的行为由其可调用的工具塑造，即使工具可用性的微小变化也会对结果产生不成比例的影响。Cursor 团队通过多轮迭代，不断调整和优化工具接口，直到模型的行为与预期一致。
未来发展方向
当前，Bugbot 每月为包括 Rippling、Discord、Samsara、Airtable 和 Sierra AI 在内的客户审查超过 200 万个 PR。Cursor 团队正在推进几个关键方向：
Bugbot Autofix
最新发布的 Beta 功能允许 Bugbot 在 PR 审查期间自动生成修复。当发现 bug 时，系统会启动Cloud Agent来实施修复，显著减少了人工干预的需求。
代码执行验证
未来的版本将允许 Bugbot运行代码来验证自己的 bug 报告。这不仅提高了报告的可信度，还能发现仅通过静态分析难以检测的运行时问题。
持续扫描模式
除了 PR 触发的审查，Cursor 正在实验始终在线的代码库扫描。这种模式能够在问题进入 PR 之前就发现潜在问题，实现更早的干预。
工程实践要点
基于 Bugbot 的演进经验，我们可以总结出几个关键的 AI 代码审查系统设计原则：
- 并行与多样性：早期采用多个独立 passes 并行处理，通过多数投票提高准确性
- 指标先行：建立量化指标（如解决率）来驱动系统优化，避免依赖主观感受
- 渐进式代理化：从固定流程逐步过渡到完全代理化设计，平衡灵活性与可控性
- 上下文动态化：减少静态上下文依赖，支持运行时按需获取信息
- 工具驱动行为：通过精心设计的工具集来引导和约束代理行为
技术挑战与应对策略
在 Bugbot 的发展过程中，团队遇到了几个典型的技术挑战：
假阳性平衡
早期版本需要抑制假阳性，而代理化版本则需要鼓励更积极的 bug 发现。解决方案是动态调整 prompt 策略，根据架构特点优化模型的冒险倾向。
协调复杂性
当系统扩展到处理数百万 PR 时，协调不同组件的工作成为挑战。团队通过优化的基础设施层和智能的请求调度来解决这一问题。
模型差异处理
不同模型提供商和自研模型各有优势和弱点。Bugbot 需要灵活的组合策略来利用不同模型的特长。
结论
Cursor Bugbot 的演进展示了 AI 代码审查系统从概念验证到生产部署的完整路径。通过从并行 Passes 架构到完全代理化设计的转变，Bugbot 不仅显著提升了审查质量，还建立了可扩展的工程基础。
关键的成功因素包括：早期采用简单但有效的并行架构、建立量化指标驱动优化、逐步引入代理化能力、以及持续的基础设施投资。这些经验为构建其他类型的 AI 辅助开发工具提供了有价值的参考。
随着 Bugbot Autofix 和持续扫描等新功能的推出，AI 在代码质量保障中的作用将进一步深化。对于工程团队而言，理解这些系统的架构演进和设计原则，将有助于更好地集成和利用 AI 工具，提升整体开发效率和质量。
资料来源：
- Cursor 官方博客：Building a better Bugbot (https://cursor.com/blog/building-bugbot)
- Hacker News 讨论：Building a better Bugbot (https://news.ycombinator.com/item?id=46643737)