派送審查代理

本指南說明如何派送審查代理來審查 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 審查
• 管線