Cursor Bugbot 官方文档：Composer 2.5、/review 与 Background Agent 治理

Cursor 6 月的 Bugbot 更新正在吸引一类很明确的搜索：官方 Bugbot docs、background agents，以及治理控制。它重要不是只因为 Bugbot——Cursor 的自动化 PR 评审 agent——现在跑在自研 Composer 2.5 上，而是因为它同时支持推送前 /review，并且仍然尊重团队 model block list。表层数据是真实的：平均评审耗时从约五分钟降到九十秒，单次运行成本下降约 22%，每次评审发现的 bug 数从 0.56 上升到 0.62。但真正的问题不是“Bugbot 是否更快”，而是你的 Cursor 文档、background-agent 工作流和模型政策是否在描述同一条代码评审路径。

发生了什么

Cursor 2026 年 6 月的 Bugbot 更新带来三个值得注意的变化：

• Composer 2.5 站上关键路径。 Bugbot 此前用多家前沿 provider 的模型组合做评审，现在主要跑在 Composer 2.5 上——这是 Cursor 自研的前沿 coding 模型，也驱动编辑器内 agent 循环。Changelog 把速度、成本与召回率提升全部归因于 Composer 2.5 的持续训练。
• 推送前 /review。 开发者可在打开 PR 之前从 agent 中按需触发 Bugbot 和 Security Review，并支持 /review-bugbot、/review-security 快捷入口。预提交评审会与 GitHub/GitLab 上 PR 触发的 Bugbot check 同步——同样的 diff 会被识别并跳过重复评审。Cursor 表示这条路径可在 Cursor 3.7+ 和 cursor.com/agents 使用，CLI 支持即将到来。
• Incremental review 可配置。 团队可以配置 Bugbot 只评审"自上次评审以来"的增量，而不是每次 push 都重新扫描整条 diff。

更新文里明写："速度和性能会因你的配置而异。" 这句话加上 block list 那一行，承担了实际的语义重量：它承认确实会有一部分 fleet 主动选择把 Bugbot 从 Composer 2.5 上挡掉。如果你的团队正在查 Cursor docs 里 Bugbot 的 background-agent 行为，就不要只把它当使用说明；那也是政策表面：docs 告诉开发者如何触发评审，block list 决定哪个模型能读这条 diff。

这件事对工程团队意味着什么

Bugbot 这次更新落在工程组织过去分开管理的三件事的交点上：代码评审、coding agent、provider/模型治理。Composer 2.5 把它们压成了一个决策。

• 代码评审现在是一个 model routing 决策。 在这次发布前，"哪个模型在审我们的 PR"对多数团队来说不是一个被认真讨论过的问题，厂商默认就够用了。Cursor 把自家模型放上这条路径，又显式地说 block list 可以覆盖默认值，这个选择就回到了团队手里，并且直接影响成本、延迟和 IP 风险。
• 自研模型正在出现在关键路径上。 Cursor 是最显眼的一例，但同样的模式还能在 Replit Code Assist、Codeium Cascade、GitHub Copilot 的一方模型、以及多家优先路由到自研模型的国内 coding agent 上看到。对 routing 运维来说，这意味着：碰你 PR diff 的那个模型，可能并不在你 gateway 的可观测、计费或审计范围内。
• PR diff 是敏感载荷。 一次 Bugbot 评审能看到整条 diff、周边文件、以及 .cursor/BUGBOT.md 里的项目规则——处理这条流量的模型对你的代码库会有非常高保真的视角。如果你们有代码数据驻留要求、客户源码限制、或合同里明确写了哪些 provider 不能看源码，那 Composer 2.5 的数据处理细节必须与现有政策对齐——Bugbot 的 block list 就是用来强制执行结论的那根杠杆。

Router/operator 视角

把 Composer 2.5 放上 Bugbot 是一个不错的契机，让团队在已有的"coding agent 模型"政策旁边，再正式定义一条"代码评审模型"政策。下面几条做法在不同工具厂商和 gateway 配置间都可以通用：

1. 把代码评审模型当成独立的 routing 类别。 "我们允许什么模型来写代码"和"我们允许什么模型把所有 diff 一次性读完"是两个不同的治理问题。后者应该有自己的 allow-list、自己的数据保留、驻留和审计设置，而不是悄悄继承编辑器默认值。
2. 决定 Bugbot block list 嵌进哪条现有控制链。 Cursor 的 block list 是 per-team 的，在 Bugbot 看板里配置。如果你们已经有了一份中央认可 provider 列表——在 AI gateway 里、在内部政策文档里、或两者都有——Bugbot block list 应该从那份源头派生，而不是由另一个管理员在另一个 UI 里独立维护。挑一个 canonical 源，把列表向下传。
3. 想清楚 Composer 2.5 被 block 之后会发生什么。 Changelog 里那句"速度和性能会因配置而异"就是暗示：如果你的 block list 排除 Composer 2.5，Bugbot 会回退到别的模型，延迟、成本和召回率都会变。在一份有代表性的 diff 样本上，分别测一遍开启和关闭 Composer 2.5 时的评审耗时和 bug 命中率，把权衡前置，而不是事后在事故复盘里发现。
4. 审计数据路径，而不只是模型名。 Composer 2.5 由 Cursor 自己 host，不是由你们采购流程主要针对的那些前沿 API provider。为"我们用 OpenAI 和 Anthropic 处理代码"写的安全审查不再覆盖全部表面。DPA、训练数据 opt-out、推理区域约束都需要对齐更新。
5. 盯住 Bugbot 在 CI 里的姿态。 Bugbot 会发布 Cursor Bugbot 这条 GitHub check，结论可以是 success、neutral 或 failure。默认情况下，有发现也只是 neutral，所以绿灯并不等于 Bugbot 放行，只是说发现并不阻塞合并。如果你们想借这次更快的评审窗口收紧评审政策，就要明确：Bugbot 发现是必须解决才能 merge，还是仅供参考。

更大的信号是：工具厂商越来越愿意把自家模型放上关键路径，与客户之间的契约也在从"我们封装前沿 API"逐步变成"我们跑自家模型，你可以选择不用"。block list 就是新的 opt-out 接口，应该被当作一等公民的 routing primitive 来对待。

TheRouter 用户值得关注什么

如果你的组织在跑一个多 IDE fleet——有的团队用 Cursor，有的用 Claude Code 或 OpenAI Codex，还有 PR 侧的 Bugbot 或 CodeRabbit 这类自动化——那真正集中性的问题是：那份 canonical 的"获批模型清单"究竟住在哪里？AI gateway 是放这份清单的天然位置，因为它正好坐在编辑器、CLI 和 PR bot 之间，可以按工具和开发者维度归集用量。随着 Composer 2.5（以及其他厂商的同类模型）把越来越多的工作负载从前沿 API 上搬走，gateway 的职责正在从"路由每一次调用"转向"对每一次调用执行政策，路由那些经过 gateway 的调用，并审计那些没经过的"。第二类才是下一步该埋点的地方。