Azure 两种部署版本如何接入 AI 审查

在 Azure Repos 上接入 AI 代码审查，第一步是确认自己用的是 Azure DevOps Services 还是 Server。原文的核心判断很明确：两个版本可走的路线不同，工具写着「支持 Azure DevOps」，也不足以证明它支持 Server。

比接通模型更容易出问题的，是审查器到底读取哪份团队规范。规则文件放在哪里、从哪条分支读取、权限是否足够，都会决定一次接入能否真正生效。这篇值得读的地方，就是把这些容易漏掉的条件拆开了。

Copilot 接入较短，但自动审查和规则生效都有条件

按原文引用的微软文档，Copilot code review 只面向 Azure DevOps Services，仍处于 limited preview：没有服务等级协议（SLA），功能可能调整或移除。前提是拥有 Azure DevOps organization、Azure Repos 中的 Git 仓库，以及关联到组织的 Azure subscription；不支持 TFVC。费用通过 Azure Cost Management 结算，不按席位收费。

开启功能涉及多个层级：Project Collection Administrator 在组织层启用，Project Administrator 控制项目范围，项目允许覆盖时，仓库所有者还能按仓库设置。除非管理员已为所有人开启预览，个人也需要在 Preview features 中选择加入。

开启功能不等于开启自动审查。

要让 Copilot 自动检查 PR，必须在目标分支配置 branch policy。否则，每个 PR 都得手动添加 Copilot 为 reviewer。项目或仓库层还能设置默认 review effort；更高的 effort 消耗更多 token，因此它也是成本配置。

规则来源同样分层。组织和项目规则放在 Azure DevOps 设置中，仓库规则放在根目录的 .github/copilot-instructions.md 或 .azuredevops/copilot-instructions.md。针对特定路径的规则，则放进 .github/instructions/ 或 .azuredevops/instructions/，文件名采用 *.instructions.md，并在 YAML front matter 中填写 applyTo。

少了 applyTo，对应文件会被跳过，而且不会报错。看到文件已经提交、审查也正常运行，并不能证明规则被读取。

更关键的是，仓库级和路径级规则都只从 PR 的目标分支读取。如果一个 PR 同时新增规范和修改业务代码，Copilot 不会按这份新规范检查它。推广规范时，需要先把规则合入目标分支，再让后续 PR 使用。

多个层级的适用规则会共同参与审查，但文档没有承诺冲突时的优先级。不要假设仓库规则一定覆盖组织规则。

Server 能自己接，但每条路线承担的工作不同

Azure DevOps Server 没有对应的微软原生审查器。原文讨论的路线包括流水线任务、Service Hooks 接入，以及自托管服务。

PR-Agent 的支持矩阵列出了 Azure DevOps 和 Azure DevOps pipeline。Server 团队可以把它放进流水线，也可以通过 webhook 触发。它由社区维护，采用 MIT 许可证，审查类别和提示词保存在团队掌握的配置文件中，矩阵还列出了 AGENTS.md 等仓库上下文文件。

需要记住一个版本限制：/help_docs 自 v0.36.1 起因凭据暴露问题被禁用，等待修复。选择这条路线，也就接下了流水线、模型密钥和 webhook 端点的维护工作。

Alibaba 的 Open Code Review 则以 npm 工具 ocr 的形式提供，输入可以是 git diff、commit range 或完整文件，依赖 LLM endpoint，不强制依赖代码托管平台集成。对于受防火墙限制的 Server 环境，这种方式便于安排执行位置，但工具不会自行把结果发成 PR 评论，需要另外连接这一环。

它公布的基准来自项目自身：基于 50 个仓库、200 个 PR，以及工程师标注的问题。在相同模型下，项目报告其准确率高于通用 agent，token 消耗约为后者的九分之一，代价是召回率更低。也就是报告的问题更准，但可能漏掉更多问题。这不是第三方测评。

Kodus 更接近需要持续运维的产品。它为 Azure DevOps 记录的认证方式是 Personal Access Token（PAT），没有记录该提供方的 OAuth 路线。文档列出的权限包括 Analytics Read、Code Read & Write、Graph Read、Identities and Groups Read、Project and Team Read，以及 User Profile Read。其中，Code 写权限用于发布评论。连接成功却没有评论时，排查页首先让用户检查 PAT scopes。

自托管还有具体的接入条件：Azure Repos webhook URL 必须携带加密后的 token 查询参数，用 CODE_MANAGEMENT_SECRET 对 CODE_MANAGEMENT_WEBHOOK_TOKEN 做 AES-256-CBC 加密得到。缺少它会返回 403。请求还必须到达端口 3332 的 webhooks service，或由反向代理把对应路径转发过去。

规则兼容也有差异。Kody 会读取 .github/copilot-instructions.md 和 .github/instructions/**/*.instructions.md 等文件，原文引用的列表没有列出 .azuredevops/ 路径。沿用 Azure 风格目录的团队，不能默认所有审查器都看得到。

厂商写了 Azure DevOps，也要继续核对版本

原文对 CodeRabbit 和 Qodo 的结论很克制：它们的相关页面都不足以确立 Azure DevOps Server 支持。

CodeRabbit 记录了 PAT 或 Microsoft Entra service principal 两种接入方式，需要 Project Administrator 或 Project Collection Administrator 权限，还需要 Service Hooks 的 Edit Subscriptions 权限来安装 webhook。文档指出，该权限目前不能通过 UI 授予，而且按项目授予。项目多时，这会成为实际的管理成本。但页面没有区分 Services 和 Server。

Qodo 的 on-premises 指南容易让人误读。它要求注册 Microsoft Entra 应用，把服务账号以 Basic access 和 Project Administrators 身份加入组织，再订阅 PR Created、PR Updated、PR Commented、PR Merged 四种 Service Hooks 事件。

这些步骤依赖 dev.azure.com 和 Entra ID，指向 Azure DevOps Services。其部署矩阵又单独把 Azure DevOps Cloud 的 on-prem 标为不支持。原文将这些信息合起来理解为：指南描述的是把 Qodo 部署在本地，再连接云端 Services，并未记录 Azure DevOps Server 的安装接入。

审查器部署在本地，与它支持本地版代码平台，是两件事。

我的判断

这篇最有用的部分，是把「能连接」「能触发」「能读取规则」「能发表评论」拆开验证。它们分别受版本、策略、文件位置和权限约束。只看产品支持列表，很容易高估接入完成度。

不过，这不是审查质量排行榜。原文没有提供各工具在同一批 Azure PR 上的误报率、漏报率、耗时或费用对照。Copilot 路线较短、PR-Agent 投入承诺较低，都是基于接入方式的判断，不能推导为审查效果更好。Open Code Review 的数字也应保留项目自测的限定。

目标分支读取规则有明确取舍：规范更新不能立即用于同一个 PR，但提交者也无法仅靠在当前 PR 修改规则来改变此次审查依据。团队应按治理需求选择，不能只把它当成缺陷。

我也不会仅凭文档没有写 Server，就断言厂商一定不支持。合理结论是支持范围尚未被这些页面证明，正式投入前需要补证据。

能拿来做什么

• 接入前先写清 Services 或 Server、代码能否发送到外部 LLM endpoint，以及结果是否必须回写 PR，再筛工具，避免在部署条件上返工。
• 在试用仓库中放入一条明确规则，创建一个故意违反它的 PR，检查是否触发、是否读到规则、是否成功评论。测试 Copilot 时，先把规则合入目标分支。
• 对前端或 Node 仓库的路径规范，检查 *.instructions.md 的 applyTo。多工具共用时，可优先评估 .github/copilot-instructions.md；若同时维护 .azuredevops/，要保证内容同步。
• Server 团队可先用 PR-Agent 流水线，或把 ocr 接到现有 diff 检查步骤中验证价值。确实需要规则管理 UI 和长期指标后，再评估自托管产品的维护成本。