派發審查代理

本指南說明如何派發審查代理來審查 pull request。

從 PR 檢視畫面

1. 開啟該 PR，前往它的總覽分頁
2. 開啟 ⋯ 溢位選單，然後選擇詢問 AI

這會啟動預置的 pr_review 管線，它會開啟該 PR 的審查空間，並按工作區的檢閱等級 派出審查者 —— 預設三個（預置的 qa、architect 和 engineer 代理）—— 然後由主導代理匯總。在這條路徑上，你無法選擇角色。若要控制由哪些角色執行，以及 每個角色檢視哪些檔案，請使用下面的 MCP 工具或管線步驟。

透過 dispatch_reviewers MCP 工具

在既有的審查空間內部呼叫它：

dispatch_reviewers(
  space_id: "...",
  workspace_id: "...",
  reviewers: [
    {role: "reviewer"},
    {role: "security", scope: "src/auth/**"}
  ]
)

space_id、workspace_id 和 reviewers 全部皆為必填。每個審查者規格接受一個 role，以及可選的檔案 glob scope 和一個會取代預設任務簡述的 prompt_override。 可選的 concurrency（1–8）會限制並行派發的數量；省略時，會套用工作區的 review_concurrency 設定（預設 3，在 設定 → 工作區 → 一般 設定）。

該工具會立即傳回 dispatched 和 unmatched 兩份清單。每個已派發的審查者都會以 參與者身分加入該空間，並會以一條系統訊息公告，然後帶著自己的任務簡述被派發。發現項 會以 review_node 訊息的形式落到該空間中。

從管線步驟

開啟 設定 → 工作區 → 管線範本，開啟一個範本，然後：

1. 從節點庫新增一個 Reviewer (prompt) 節點
2. 選擇要派發的代理並撰寫審查者提示詞，使用 {{key}} 佔位符引用上游輸出 （例如 {{repo_local_path}}、{{pr_number}}）
3. 設定輸出鍵（預設 reviewer_findings），讓下游步驟可以讀取發現項

該步驟會派發代理並暫停，直到那次執行結束。接著引擎會把該次執行的 submit_output 載荷收集到管線狀態中，存放在該節點的輸出鍵之下。（節點庫中的說明仍然說該步驟會 等待一次 complete_task 呼叫 —— 該工具並不存在；請忽略這段文字。）

把多個審查者節點接到同一個上游步驟即可實現扇出，然後用一個 Consolidate (join) 節點匯總它們的輸出。

編輯器會把隱藏的終端重新接到每一個可達的匯點，因此你在預置的 Step 之後新增的 節點仍會執行。接到同一個上游步驟的扇出節點會並行執行。

在新 PR 上自動派發

要讓一條審查管線自行觸發：

1. 在 設定 → 工作區 → 管線範本 開啟該範本
2. 從節點庫的觸發器區域，把 PR 已發佈 或 外部 PR 已開啟 拖到畫布上 （或從 新增觸發器 佔位磚中選取它）
3. 選取新增的節點，在其檢查器中開啟 已啟用，然後啟用該範本

這裏有兩個事件很重要，而它們不能互換：

事件	觸發時機	載荷鍵
PullRequestPublished	某個 PR 透過 Control Center 開啟時 —— 撰寫介面，或代理呼叫 pr_lifecycle.publish	pr_id、workspace_id、repo_owner、repo_name
ExternalPrDetected	PR 輪詢服務發現某個 PR 直接在 GitHub 上開啟時	repo_owner、repo_name、pr_number、pr_title、author

在 github.com 上開啟的 PR 絕不會觸發 PullRequestPublished，因此只接了該事件的 範本不會看到它。還要注意，PullRequestPublished 不帶 pr_number —— 腳本或提示詞 中引用 {{pr_number}} 的步驟，必須由 ExternalPrDetected 提供該值，或由一次手動 執行提供。

檢查點：啟用之後，開啟 管線，確認下一個相符的 PR 會出現一次執行。範本若一直 處於停用狀態，它的觸發器觸發後將毫無作用 —— 引擎會拒絕已停用的範本並直接傳回， 不會啟動任何執行。

角色如何匹配到代理

dispatch_reviewers 會把工作區中的每個代理與每個要求的角色標籤逐一評分比對， 不區分大小寫：

匹配方式	分數
技能中包含該角色標籤	+3
標題中包含該角色標籤	+2
代理名稱中包含該角色標籤	+1

分數會累加，總分最高者勝出（分數相同時，取最先找到的候選者）。如果沒有任何候選者 得分高於零，該規格會出現在工具的 unmatched 清單中，而不會被派發 —— 因此沒有人 匹配的角色會被報告出來，絕不會被悄悄略過。

審查空間

一個 PR 恰好有一個審查空間，而不是每個審查者一個。它由 pr.ensureSpace 以冪等 方式建立，透過 ReviewSpaceAssociation 與該 PR 連結，並針對該 PR 的 head ref 完成 佈建。每個已派發的審查者都會加入該空間，並把自己的 review_node 發現項發佈在 那裏 —— 正是這一點讓各項發現項可以互相比較，並讓主導代理能夠在它們之間達成共識。

監察派發

每個已派發的審查者都有自己的 AgentRunLog。可在以下位置跟進進度：

• 審查空間，發現項會即時流入
• PR 的檢閱分頁，其中會顯示檢閱狀態列與判定
• 可觀測性 → 即時（/workspaces/:id/observability），即代理名冊，包含每次 執行的狀態、即時已用時間、轉錄抽屜和終止控制項。它沒有鍵盤快捷鍵 —— 從側邊欄 頁腳進入。

相關指南

• 使用 AI 輔助審查
• 審查並合併 PR
• 設定管線觸發器

相關概念

• AI 審查
• 管線與自動化