Перейти до вмісту

Запускати агентів-рев’юерів

Цей посібник показує, як запускати агентів-рев’юерів для перевірки pull requests.

  1. Відкрийте PR і перейдіть на його вкладку Огляд
  2. Відкрийте меню переповнення ⋯ і виберіть Запитати AI

Це запускає вбудований конвеєр pr_review, який відкриває простір рев’ю цього PR і розгортає рев’юерів відповідно до рівня рев’ю робочого простору — типово трьох (вбудовані агенти qa, architect і engineer) — а тоді доручає головному агентові звести їхні результати. На цьому шляху ролі ви не вибираєте. Щоб контролювати, які ролі запускаються і на які файли дивиться кожна з них, скористайтеся інструментом MCP або кроком конвеєра нижче.

Викличте його з наявного простору рев’ю:

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

space_id, workspace_id і reviewers — усі обов’язкові. Кожна специфікація рев’юера приймає role, а також необов’язковий scope — glob-шаблон файлів — і 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, усе одно виконується. Вузли, розгалужені віялом і з’єднані з тим самим кроком вище за потоком, виконуються паралельно.

Щоб конвеєр рев’ю спрацьовував сам собою:

  1. Відкрийте шаблон у Налаштування → Робочий простір → Шаблони конвеєрів
  2. Перетягніть PR опубліковано або Відкрито зовнішній PR з розділу Тригери бібліотеки вузлів на полотно (або виберіть його з фантомної плитки Додати тригер)
  3. Виберіть новий вузол і увімкніть Увімкнено в його інспекторі, а тоді увімкніть шаблон

Тут важливі дві події, і вони не взаємозамінні:

Подія Спрацьовує, коли Ключі корисного навантаження
PullRequestPublished PR відкривають через Control Center — на поверхні створення PR або агентом, який викликає pr_lifecycle.publish pr_id, workspace_id, repo_owner, repo_name
ExternalPrDetected Служба опитування PR знаходить PR, відкритий безпосередньо на GitHub repo_owner, repo_name, pr_number, pr_title, author

PR, відкритий на github.com, ніколи не породжує PullRequestPublished, тож шаблон, з’єднаний лише з цією подією, його не побачить. Зверніть увагу також, що PullRequestPublished не несе pr_number — крок, чий скрипт або промпт посилається на {{pr_number}}, має отримувати дані від ExternalPrDetected або від ручного запуску, який його надає.

Контрольна точка: після ввімкнення відкрийте Конвеєри й переконайтеся, що для наступного відповідного PR з’являється запуск. Шаблон, залишений вимкненим, змушує свій тригер спрацьовувати в порожнечу — рушій відхиляє вимкнений шаблон і повертається, не почавши запуск.

dispatch_reviewers оцінює кожного агента в робочому просторі щодо кожної запитаної мітки ролі, без урахування регістру:

Збіг Бал
Навичка, що містить мітку ролі +3
Заголовок, що містить мітку ролі +2
Назва агента, що містить мітку ролі +1

Бали накопичуються, і перемагає найвища сума (за рівності — перший знайдений кандидат). Якщо жоден кандидат не набирає більше нуля, специфікація повертається у списку unmatched інструмента, а не запускається — тож роль, з якою ніхто не збігається, буде повідомлено, а не мовчки пропущено.

PR має рівно один простір рев’ю, а не по одному на кожного рев’юера. Його ідемпотентно створює pr.ensureSpace, пов’язує з PR через ReviewSpaceAssociation і готує відповідно до head ref PR. Кожен запущений рев’юер приєднується до цього простору й публікує там свої знахідки review_node — саме це робить знахідки порівнюваними й дає головному агентові досягти консенсусу між ними.

Кожен запущений рев’юер отримує власний AgentRunLog. Стежте за поступом у:

  • Простір рев’ю, куди знахідки надходять наживо
  • Вкладка Рев’ю цього PR, яка показує смугу стану рев’ю та вердикт
  • Спостережуваність → Наживо (/workspaces/:id/observability) — реєстр агентів зі статусом кожного запуску, часом, що минає наживо, шухлядою транскрипту та елементом керування зупинкою. Гарячої клавіші для неї немає — дістаньтеся її з нижньої частини бічної панелі.