Marico's space
最近在 Azure Repos Git 上部署 PR-Agent，踩了几个坑，这篇把问题说清楚。 Azure Repos Git 不会因为 YAML 里写了 pr: 块就触发流水线，这和 GitHub 完全不同。PR 验证走的是分支策略（Branch Policies），所以如果你直接把 GitHub 工作流的配置抄过来，在 PR 创建时啥都不会发生——除非有人在目标分支上手动加了一个 Build Validation 策略。PR-Agent 官方文档其实写得明白，Microsoft 的流水线文档也是这个意思：想验证 PR？去配置 Build Validation 策略。 这个差异决定了后续整套方案的走向——触发方式、认证身份、能不能回复评论，全都是从这里分叉的。
分支策略的位置在 Project Settings → Repositories → Branches。找到目标分支，打开 Branch Policies，把 PR-Agent 流水线加进去，标记为 Required。然后把 azure-pipelines.yml 里的 pr: 段删掉，因为 Azure Repos Git 会直接忽略它。
有两个细节容易漏。第一，你需要是拥有这个仓库的项目管理员，才能配置验证构建。第二，草稿状态的 PR 不会触发流水线，哪怕分支策略配好了也白搭——所以习惯开草稿 PR 的团队，在 PR 标记 Ready 之前根本看不到任何 review。
构建的产物也有区别。验证流水线跑的是源分支和目标分支的合并提交（merge commit）。如果源分支的某个 commit 消息里写了 [skip ci]，那个分支上的流水线会被跳过，但 Build Validation 流水线在合并提交上依然会跑。想用 [skip ci] 控制 CI 成本，这条路走不通。
流水线本身很简洁。用 pragent/pr-agent:latest 镜像跑容器，清空 entrypoint，用 Azure Pipelines 注入的变量拼出 PR URL（System.CollectionUri、System.TeamProject、Build.Repository.Name、System.PullRequest.PullRequestId），设置 config__git_provider=azure，然后调三次 CLI 分别执行 describe、review 和 improve。PAT 和模型 key 从变量组（variable group）里取，流水线需要显式授权才能读那个组，否则 job 会因为 secret 为空而失败。
Azure Pipelines 不支持从 PR 评论触发工作流，PR-Agent 文档里写得很直白。纯流水线模式下，PR-Agent 会在每个新 PR 创建时自动 review，但没法响应线程里输入的 /review 命令。这和自托管 GitLab 的情况一样——pipeline 模式自动触发，评论命令需要 webhook server 来处理。
Azure Repos 上 webhook 路由靠手动配置的服务钩子（service hook）。在 Project Settings → Service hooks 里创建，触发条件选 Pull request created for a review 或 Pull request commented on for a supported slash command，API 版本要选 v2.0（评论事件需要这个版本）。钩子以 Basic Auth 方式把 username 和 password 发到 PR-Agent 端点，所以端点必须是 HTTPS。
所以分工很清楚：想要 describe、review、improve 自动触发、又不爱折腾服务，就走流水线；想让团队从评论里驱动 review，就得配 webhook。
Azure DevOps provider 支持两种认证方式：个人访问令牌（PAT）或者 DefaultAzureCredential。PAT 创建快，有过期日期，API 调用以创建者的身份执行。DefaultAzureCredential 用托管标识（managed identity）或服务主体（service principal），会在 Microsoft Entra ID 下创建独立的 Azure DevOps 身份。
不管用哪种，.secrets.toml 里 [azure_devops] 下都要设置 org。用 PAT 的话，token 也放这个文件。用 DefaultAzureCredential 的话，提供 AZURE_CLIENT_SECRET，或者依赖托管标识（本地调试可以用 Azure CLI）。服务主体这条路的好处是 reviewer 的身份和某个人的账号解绑了——那人离职或者 token 过期都不会影响 bot。
PR-Agent 在线程里发过评论之后，后续回复会跟着同一线程走。它判断哪些是自己发的，是通过读取之前的评论。普通的 @ 提及比如 hi agent 不会触发响应。在 PR 第一次发帖之前，或者 Azure DevOps 身份变了的时候，需要在 [azure_devops_server] 段里设置一个稳定的身份标识，用 GUID 或者唯一名字都行。身份迁移期间这个设置支持传一个列表。
这个段名本身就是个坑。azure_devops_server 配置的是 agent 身份和 webhook 凭证，但不管是 hosted 服务还是 server 版都用这个段——所以在 dev.azure.com 上跑的同学，打开配置文件看到的却是一个写着"server"的段。
部署之前值得把支持平台矩阵读一遍，别到时候给团队承诺了实现不了的功能。Describe、Review、Improve、Ask、Add Docs 和 Help 在 Azure DevOps 上都支持。Generate Labels 会以评论形式发布（因为 provider 能设标签）。Update CHANGELOG 也是发评论而不是直接推文件（provider 没有文件推送权限）。Ask on code lines、Similar Issues 和 tagging bot 在 Azure DevOps 上完全不支持。
PR-Agent 不是唯一的选择，关键看工具用哪个身份认证、 webhook 怎么做安全校验。
Kodus 通过 PAT 连接 Azure DevOps，PAT 有个固定的权限范围：Analytics Read、Code Read & Write、Graph Read、Identities and Groups Read、Project and Team Read、User Profile Read。其中 Code Write 是发 review 评论的关键——没有这个权限，连接看起来健康，但 PR 上就是不出评论。自托管部署的话，Azure Repos webhook 需要一个带签名的 token 查询参数，是用 CODE_MANAGEMENT_SECRET 和 CODE_MANAGEMENT_WEBHOOK_TOKEN 生成的 AES-256-CBC 值，没有这个参数直接 403。GitHub、GitLab、Bitbucket、Forgejo 的连接都不需要这个步骤，这是 Azure Repos 自托管特有的麻烦。Kodus 订阅四个事件：PR 创建、更新、合并尝试、评论。
| PR-Agent | Kodus | |
|---|---|---|
| 触发方式 | Build Validation 策略，或手动 Azure service hook | Azure service hook（集成创建或手动注册） |
| 认证方式 | PAT，或通过托管标识/服务主体的 DefaultAzureCredential | 带固定权限范围的 PAT |
| 评论命令 | 仅 webhook 路由，需要 API v2.0 | Pull request commented 事件 |
| 自托管 | 流水线里跑 Docker 镜像，或 webhook server | 支持自托管部署 |
| Webhook 安全 | Basic Auth 用户名密码 | 签名 token 查询参数，无则 403 |
说到底，Azure DevOps Services 和 Azure DevOps Server 不是一回事。哪些 AI review 路线在各个版本上真正能跑，这决定了托管式 reviewer 到底在不在考虑范围内——因为厂商文档里写 PAT 和 service hook、指着 dev.azure.com 的，都是在说托管服务。Server 团队照着这些页面配，会在权限配置上绕很久，因为 Server 里的权限结构和托管服务不完全一样。
各个自托管 reviewer 在三个主流代码托管平台上的完整对比，可以看 PR-Agent on GitLab, Azure DevOps and Bitbucket 这篇。
Azure DevOps 页面上没写流水线路由的每 PR 成本，也没说 webhook 路由在物理隔离的 Server 环境里能不能跑。这两个问题在规划阶段都会遇到，厂商页面上都没有数据可查。文档能指引的方向是通用配置参考，以及 issue tracker 里关于评论触发支持的讨论——对于这两个具体问题，暂时只能去那边找答案。