Командная совместная работа

Исходный файл на GitHub

AWR позволяет нескольким людям — и агентам, с которыми они работают, — координироваться в одном общем проекте: все видят одни и те же задачи, захватывают работу, которую выполняют, сообщают о прогрессе по ходу дела и передают завершённую работу независимому проверяющему. Вы управляете всем этим из обычного диалога с агентом; вам не нужно копировать ID задач в браузере.

Доступность: эта статья описывает Team-сервис, который всё ещё находится в разработке. Он не входит в опубликованный персональный MCP-сервер 0.5.0. Описанные ниже возможности относятся к командному проекту, размещённому у вашего администратора проекта, а не к личной локальной установке.

Об основных идеях (элементы работы, контракты, свидетельства, сессии) сначала прочитайте Концепции. О ежедневном цикле для одного человека см. Ваш ежедневный рабочий процесс.

Модель совместной работы одним взглядом

Вся модель держится на четырёх идеях:

  • Рабочие потоки и общая работа. Удалённый проект — общий авторитет по работе: единственное место, где живут задачи, зависимости, прогресс и результаты. Ваш локальный checkout — только для кода и тестов; не инициализируйте второй локальный реестр задач взамен удалённого проекта.
  • Захват. Прежде чем агент начинает исполнительную работу, он берёт живой захват на задачу под своей сессией. Живой захват другого человека нельзя заменить, поэтому два агента не могут незаметно работать над одним и тем же.
  • Проверка. Доставка и приёмка — отдельные факты. Уполномоченный, независимый человек проверяет представленную работу до её принятия. Второй агент, принадлежащий вам, — не независимый проверяющий.
  • Передача. Сессии долговременны: они переживают переподключения MCP, несут контрольные точки и состояние восстановления и могут быть подхвачены снова — вами после перерыва или проинспектированы коллегой — без потери контекста.

Подключитесь один раз

Попросите у администратора проекта URL проекта MCP и ваши индивидуальные учётные данные. Каждый участник использует свои собственные учётные данные, а разрешения репозитория остаются отдельными от разрешений AWR — присоединение к проекту AWR не даёт доступа к Git, и наоборот.

За кулисами уполномоченный администратор открывает Members в Inspector, добавляет вас, выбирает вашу роль в проекте и рабочие потоки и копирует одноразовую персональную инструкцию по подключению, содержащую конечную точку и ваши учётные данные. Вы получаете её по закрытому каналу. Администратор не может получить её открытый текст после очистки панели выдачи; если вы потеряете учётные данные, их можно явно заменить.

Добавьте удалённый MCP-сервер в любом клиенте агента, поддерживающем удалённый MCP через Streamable HTTP с Bearer-аутентификацией:

НастройкаЗначение
ТранспортStreamable HTTP
URL сервераКонечная точка вашего проекта, например https://team.example/v1/projects/example/mcp
АутентификацияBearer-токен в HTTP-заголовке Authorization
Учётные данныеВаши персональные учётные данные, выданные администратором

Это настройки подключения, а не формат файла конфигурации или команда оболочки; у каждого клиента свои настройки и требования к версии. Если ваш клиент поддерживает только локальный stdio MCP, этот URL нельзя использовать напрямую — используйте версию клиента или интеграцию, поддерживающую удалённый транспорт.

Несколько правил безопасности для учётных данных:

  • Используйте поддерживаемые клиентом настройки секретов или доверенный закрытый ввод агента.
  • Никогда не помещайте учётные данные в URL, общий диалог или репозиторий.
  • Переподключитесь после изменения конфигурации, затем откройте ваш локальный checkout кода в агенте.

Дайте вашему агенту результат

Вы работаете в том же диалоге, который используете для разработки. Опишите результат и позвольте агенту координировать, например:

Используй подключённый проект AWR Team, чтобы реализовать issue API. Обнови текущие задачи и возобнови мою существующую работу или захвати подходящую задачу под этот запрос. Прочитай контракт, зависимости и последнюю контрольную точку перед редактированием. Веди прогресс и свидетельства в AWR, отправь протестированное изменение как PR и запроси независимую проверку.

Агент читает общую работу, захватывает подходящую задачу и держит проект в актуальном состоянии, пока разрабатывает локально. Если он упирается в реальный конфликт разрешений, зависимостей или владения, он сообщает об этом вам вместо того, чтобы обходить его.

Что агент делает для вас

Агент общается с Team-сервисом через два обнаруженных MCP-инструмента: awr_team_query для чтения и awr_team_command для записи. Каждый запрос и каждая команда перепроверяют ваши текущие разрешения, поэтому изменение роли вступает в силу без редактирования локальной конфигурации.

Типичная сессия протекает так:

  1. Старт или переподключение. Агент запрашивает capabilities, чтобы подтвердить свою идентичность и разрешения, затем work.next, чтобы возобновить ваши собственные сессии или обнаружить видимую незавершённую работу, следуя возвращённому next_query. (На старых серверах без work.next он откатывается к workstreams.list и ограниченным по области work.list / work.search.)
  2. Подготовка. Для выбранной задачи work.prepare возвращает текущий контракт, требуемые спецификации, зависимости, состояние восстановления и хеш контекста — один снимок, который агент должен реально потребить перед редактированием. work.prepare и work.observe могут также вернуть один короткий элемент guidance (его условие, фактическую основу, следующее действие и триггер переоценки); это совет, а не права на выполнение.
  3. Захват. Агент инспектирует существующие захваты через claim.inspect, затем получает или продлевает живой захват под своей сессией.
  4. Выполнение. С execution.prepare и свежим ответом execution.start, несущим execution_authorized=true, агент может выполнить одно выполнение в заявленной области. Код и инструменты выполняет ваша машина — сервис сам никогда ничего не выполняет. Один лишь захват не является допуском к выполнению.
  5. Отчёт о прогрессе. Агент отправляет session.checkpoint с потреблённым хешем контекста, следующим действием, открытыми петлями и краткой сводкой progress, группируя обновления, когда завершается фаза или тест, меняется блокировка, нужен ваш ввод или готова доставка, — а не на каждый вызов инструмента. Помните, что сводки контрольных точек доступны уполномоченным читателям работы, поэтому необработанные чувствительные журналы в них не место.
  6. Завершение или остановка. execution.report записывает терминальный исход с привязанными к версии свидетельствами. Захваты освобождаются и сессии завершаются только после того, как урегулированы активная работа и неопределённые исходы.

Проверка и приёмка

Когда работа готова, агент отправляет свидетельства и запрашивает проверку через delivery.submit_and_request_review или review.open. Уполномоченный, независимый человек проверяет доставку, а уполномоченная финализация следует политике приёмки проекта.

Держите эти факты раздельными: реализация, верификация, слияние в GitHub и приёмка AWR. Слияние PR — не то же самое, что принятие задачи в AWR, и ваш собственный второй агент не считается независимым проверяющим.

Передача и восстановление

Передача работает, потому что сессии и контрольные точки живут в общем проекте, а не в истории чата одного человека:

  • Переподключение MCP не завершает долговременную рабочую сессию и не продлевает её аренду.
  • Состояние восстановления и зарегистрированные доставки имеют приоритет над старыми инструкциями контрольных точек, поэтому возвращающийся агент доверяет тому, что действительно произошло.
  • Если запись завершается по тайм-ауту, агент инспектирует результат исходной команды перед точным повтором; воспроизведённые квитанции — исторические факты, а не разрешение выполнить эффекты снова.
  • Если эффекты выполнения неизвестны (прерывание посреди задачи), они требуют инспекции и уполномоченного согласования. Создание новой сессии не обходит это требование.

Два практических ограничения, которые стоит знать: AWR не может разбудить простаивающего агента (продление аренды использует планирование вашего хоста, отдельно от контрольных точек), а заблокированная или ожидающая фаза — это отчёт: она сама по себе не создаёт элемент ожидания и не продлевает захват.

Inspector: необязательное представление рабочей области

Inspector — веб-представление поверх того же проекта. Вход на сайт или захват через веб-сайт не является предварительным условием ни для чего из описанного выше — агент остаётся поверхностью координации. Используйте Inspector, когда хотите:

  • Инспектировать связи задач, владение, прогресс и записанные результаты.
  • Копировать нейтральные к клиенту настройки MCP и инструкцию проекта из Connect Agent или бриф по отдельной задаче (копирование текста не создаёт ни сессии, ни захвата).
  • Как администратор — управлять участниками и учётными данными уровня проекта в Members.
  • Просматривать Activity, которое отделяет записи аутентифицированного доступа от зафиксированной истории разработки. Обычные участники видят свою собственную авторизованную активность; аудиторы проекта могут фильтровать по участнику или задаче. Записи аудита исключают значения учётных данных, диалоги и произвольный ввод/вывод инструментов, а метаданные запросов имеют ограниченный срок хранения — это не постоянный архив соответствия.

Разрешения администратора и проверки обеспечиваются центральным сервисом независимо от того, какой клиент вы используете, поэтому правила действуют, работает ли кто-то через агента, Inspector или и то, и другое.

Следующие шаги