# Управление обоснованием, доверием и утверждением для проблем
Настройте и управляйте обоснованием, доверием и утверждениями для проблем, которые обрабатываются Автоматизация.
Логика и уверенность не требуют дополнительной настройки.
АвтоматизацияКогда агент изменяет поддерживаемый атрибут проблемы, он автоматически присоединяет обоснование и уровень достоверности. Независимо от того, применяется ли это изменение непосредственно или ожидает проверки, зависит от уровня автоматизации репозитория или от явного запроса, чтобы предложить, а не применить это изменение.
## Настройка уровня автоматизации репозитория
> \[!NOTE]
> Настройка уровня автоматизации постепенно развертывается и может быть недоступна в репозитории.
Уровень автоматизации репозитория задает порог доверия, используемый для маршрутизации каждого поддерживаемого изменения. Изменения, оцененные ниже порогового значения, хранятся в виде предложений; изменения, внесенные в или выше, применяются автоматически. Уровень по умолчанию является **осторожным**, поэтому только изменения высокой достоверности применяются автоматически, пока не измените его.
1. На GitHubперейдите на главную страницу репозитория.
2. Под именем репозитория щелкните ** Settings**. Если вкладка "Параметры" не отображается, выберите **раскрывающееся меню ** и нажмите кнопку **"Параметры**".
3. В разделе "Планирование" боковой панели щелкните **предложения агента по проблемам**.
4. В разделе "Уровень автоматизации" выберите уровень, соответствующий вашему репозиторию:
* **Полный контроль: каждое** изменение проводится для проверки. Ничего не применяется автоматически.
* **Осторожные** (по умолчанию): автоматически применяются только изменения высокой достоверности. Все остальное проводится для вашего обзора.
* **Сбалансированный: подпрограмма**, четкое сокращение изменений применяются автоматически. Все, что имеет неоднозначность, проводится для рассмотрения.
* **Полная автоматизация: каждое** изменение применяется автоматически. Агент сохраняет изменения только в том случае, если он помечен как неопределенный.
5. Нажмите кнопку **Сохранить**.
## С Copilot облачный агент
1. Автоматизация Создайте проблемы, которые возникают после [Создание автоматизаций с помощью облачного агента Copilot](/ru/copilot/how-tos/use-copilot-agents/cloud-agent/create-automations). Используйте триггер **создания проблемы** или запустите Автоматизация его по расписанию.
2. Автоматизация Предоставьте средства проблемы для атрибутов, которые требуется изменить, например обновление меток, задание типа, редактирование полей, назначение пользователей или закрытие проблем.
3. В запросе опишите задачу триажа, например: `Triage this issue by setting a type, labels, and priority, and explain your reasoning for each.` вам не нужно явно указывать обоснование, уверенность или предложения. Чтобы сохранить определенные изменения для проверки независимо от достоверности, попросите агента предложить эти изменения, а не применить их.
4. Сохраните Автоматизация. Когда он выполняется, его изменения несут обоснование и уровень достоверности. Изменения под уровнем автоматизации репозитория и любые изменения, которые вы попросили агент предложить, подождите на панели утверждений по этой проблеме.
## С GitHub агентические рабочие процессы
Намерения проблем, метаданные логики и достоверности, присоединенные к изменениям проблем рабочего процесса, являются необязательными и включены по умолчанию. Существующие рабочие процессы продолжают работать без изменений.
1. Обновите до последней GitHub агентические рабочие процессы версии расширения, выполнив команду `gh aw upgrade`.
2. Добавьте рабочий процесс, который выдает проблемы в каталог репозитория `.github/workflows` . Вы можете начать с примера или разработки проблемы самостоятельно. См. [GitHub агентические рабочие процессы](https://gh.io/gh-aw) документацию.
3. Предоставьте рабочему процессу выходные данные для атрибутов, которые нужно изменить, перечислив их `safe-outputs` в интерфейсном элементе рабочего процесса. Например, `add-labels` чтобы применить метки, задать тип проблемы, `set-issue-field``set-issue-type` изменить поля `assign-to-user` или `assign-to-agent` назначить проблемы и `close-issue` закрыть их. Добавление этих выходных данных достаточно для рабочего процесса, чтобы внести соответствующие изменения в проблему с обоснованием и уровнем достоверности.
4. При необходимости укажите, требуется ли для безопасного вывода метаданные намерения проблемы, задав `issue-intent` для него следующие параметры:
```yaml
safe-outputs:
add-labels:
issue-intent: true
```
* Опустить `issue-intent`или оставить его неустановленным, чтобы сохранить его необязательным: агент рекомендуется обеспечить рационализатор и уровень достоверности, но выходные данные по-прежнему работают без них.
* Задайте `issue-intent: true` для этого выходные данные с обоснованием и уровнем достоверности. Рабочий процесс завершается ошибкой, если агент игнорирует их.
* Установка `issue-intent: false` полностью отказаться: выходные данные никогда не несут обоснование или метаданные достоверности.
5. В командной строке рабочего процесса опишите задачу триажа. Чтобы сохранить определенные изменения для проверки независимо от достоверности, попросите агента предложить эти изменения, а не применить их.
6. Скомпилируйте рабочий процесс, зафиксируйте `gh aw compile`файл рабочего процесса и созданный файл блокировки.
7. Когда рабочий процесс выполняется, его изменения несут обоснование и уровень достоверности (если вы не отказались). Изменения ниже уровня автоматизации репозитория и любые изменения, предложенные агентом, подождите на панели утверждений по этой проблеме.
## С помощью REST или API GraphQL
Если вы создаете собственную интеграцию вместо использования Автоматизация, вы можете использовать те же интерфейсы REST и GraphQL API для включения рационального и доверия с изменением или пометить изменение как предложение, чтобы провести его для проверки. Изменение направляется так же, как изменение из Автоматизация рабочего процесса или GitHub агентические рабочие процессы рабочего процесса: при условии уровня автоматизации репозитория или проверки, если вы помечаете его как предложение.
## Поиск проблем с ожидающих предложений
Чтобы найти проблемы с предложениями, ожидающими проверки, выполните поиск с помощью `has:suggestions` квалификатора, например `is:issue is:open has:suggestions`.
## Просмотр предложений на панели утверждений
Когда изменение проводится для рассмотрения, оно ожидает в группе утверждений по этому вопросу вместо вступления в силу. Используйте панель, чтобы проверить каждое предложение и решить, что следует применить.
1. Откройте проблему. Предлагаемые изменения отображаются на панели утверждений.
2. Проверьте каждое предложение. В нем показаны предлагаемые изменения, такие как метка, тип, поле, назначаемый элемент или закрытие, а также уровень достоверности.
3. Действовать по предложениям:
* Нажмите **кнопку "Принять"** , чтобы применить предложение или **отклонить** его.
* Нажмите **кнопку "Принять все" или "Отклонить все** ", чтобы выполнить **все** ожидающие предложения одновременно.
Принятые изменения вступили в силу немедленно. Отклоненные предложения отклоняются, не изменяя проблему.
Готовы поставить это на практике? См. [раздел AUTOTITLE](/ru/copilot/how-tos/use-copilot-agents/cloud-agent/create-automations) , чтобы создать Автоматизация проблемы, связанные с этим.