К содержанию
Содействиебиблиотека
XСравнение исследованийX03-0203 · Раздел 03

Сопоставление отчетов волны октября 2026 с материалами NotebookLM и легаси (часть 5)

Обновлён
10.11.2026
Редактор
gemini-3.8
Источников
1
Утверждений
54
Объём
14 920 из 15 000 знаков
На странице
  1. Сопоставление отчетов волны октября 2026 с материалами NotebookLM и легаси — часть 5 из 11
  2. Утверждения темы
  3. Фрагменты корпуса темы
  4. [LG-193-F026] — LG-193, фрагмент 03, строки 7-38, тема «assistant»
  5. assistant
  6. [LG-193-F029] — LG-193, фрагмент 03, строки 47-148, тема «assistant»
  7. assistant
  8. [LG-193-F037] — LG-193, фрагмент 04, строки 127-132, тема «user»
  9. user
  10. [LG-193-F038] — LG-193, фрагмент 04, строки 133-168, тема «assistant»
  11. assistant
  12. [LG-193-F040] — LG-193, фрагмент 05, строки 54-57, тема «user»
  13. user
  14. [LG-193-F042] — LG-193, фрагмент 05, строки 89-92, тема «user»
  15. user
  16. [LG-193-F044] — LG-193, фрагмент 05, строки 137-140, тема «user»
  17. user
  18. [LG-193-F047] — LG-193, фрагмент 05, строки 178-181, тема «assistant»
  19. assistant
  20. [LG-193-F052] — LG-193, фрагмент 06, строки 89-92, тема «user»
  21. user

Сопоставление отчетов волны октября 2026 с материалами NotebookLM и легаси — часть 5 из 11

Назначение и границы: Документ входит в блок X библиотеки материалов «Содействие» (Гомель). Тематический охват: Сопоставление отчетов волны октября 2026 с материалами NotebookLM и легаси. Ответственная линия: корпус. Статус материала: есть проверенные пруфы — фрагментов 102, утверждений 539, проверенных 13.

Утверждения темы

Фрагменты корпуса темы

[LG-193-F026] — LG-193, фрагмент 03, строки 7-38, тема «assistant»

assistant

Тогда я меняю рекомендацию: тебе нужен порядок в проектах и удобная смена инструментов, а обязательная многоагентная оркестрация не нужна. Раньше я слишком быстро начал предлагать тебе координаторов, доски и ручную приёмку PR.

Разберём термины:

НазваниеЧто этоЗачем тебе
GitИстория кода, коммиты, веткиСохранять работу и объединять изменения
GitHub CLI — ghУправление GitHub из терминалаАгент и Orca могут сами работать с задачами, PR и проверками
CIАвтоматический запуск сборки и тестов после отправки кодаЛовить конкретные поломки без твоего участия
CDПодготовка выпуска или автоматическое развёртываниеМожно добавить позже, отдельно от CI
GitHub ProjectsДоска задачПока можно вообще не использовать

Orca использует gh как технический способ общения с GitHub: получать Issues, состояние PR и результаты проверок. Это обычная программа, она сама не расходует токены модели. У GitHub есть отдельные ограничения на число запросов. Документация Orca.

С токенами важно различать автоматизацию и размышления агента. Запуск тестов, перемещение карточки правилом или получение статуса не требуют LLM. Токены расходуются, когда агент читает результаты, пишет отчёты, обсуждает задания или проверяет работу другого агента. Поэтому постоянные переклички и повторные ревью действительно добавляют расходы. Обычный CI расходует вычислительные ресурсы, а не токены модели. GitHub Actions.

GitHub Projects агенты могут обслуживать автоматически, через API и команды; часть обновлений умеет делать сама доска. Но сейчас я бы её не вводил. Она нужна, когда тебе полезно видеть общий список работ, а не потому, что агентам положено иметь доску. Автоматизация Projects.

То, что ты видел у Claude, скорее всего, — Claude Code GitHub Actions: пишешь @claude в Issue или PR, запускается Claude, читает задание, может менять код и отвечать комментариями. Это ещё один способ запускать агента. Для твоего привычного общения в приложении он необязателен. Документация Claude.

Тебе я предлагаю такой режим:

  1. Ты ставишь задачу в удобном приложении — Claude, Codex, Orca или веб.
  2. Один основной агент ведёт её до результата: делает, проверяет, исправляет, сохраняет в Git и отправляет на GitHub.
  3. Отдельные ветки используются для параллельной работы, экспериментов и передачи между средами.
  4. Если нужен PR, агент сам его оформляет и, при заранее разрешённом порядке и успешных проверках, объединяет. PR не обязывает тебя лично читать код и нажимать Approve.
  5. Ты оцениваешь результат продукта. К тебе возвращаются с вопросами о смысле, объёме и действительно существенных действиях.

Минимальный старт: чистый репозиторий + понятные инструкции + коммиты и push + несколько полезных автоматических проверок. Без Projects, обязательного второго проверяющего и цепочки «планировщик → исполнитель → аудитор». Orca — удобное место для терминалов; привычную успешную работу с одним агентом сохраняем.

[LG-193-F029] — LG-193, фрагмент 03, строки 47-148, тема «assistant»

assistant

Я бы использовал GitHub как общую историю кода и место автоматических проверок. Деплой пока оставил бы через наш Portainer, а работу — в привычном режиме с одним агентом. Это даст пользу без новой оркестрационной системы.

Зачем Orca GitHub CLI

Есть две разные программы:

  • git работает с файлами и историей: коммиты, ветки, получение и отправка кода.
  • gh — GitHub CLI работает с возможностями сайта GitHub: задачи, PR, результаты проверок, выпуски.

Orca вызывает gh, чтобы показывать эти данные в своих панелях. Агент тоже может пользоваться им: узнать, прошли ли проверки, прочитать ошибку, открыть или объединить PR. Для обычного сохранения и отправки кода достаточно git; для интеграции Orca с GitHub нужен gh. Документация Orca.

Что такое тесты, сборка и деплой

На примере Obsync:

ДействиеКакой вопрос решает
Проверка типов и кодаНет ли очевидных ошибок вроде неверных аргументов или сломанных импортов?
ТестыСохранилось ли конкретное поведение: например, повторное уведомление об оплате не начисляет тариф дважды?
СборкаМожно ли из исходников получить запускаемое приложение?
Проверка в браузереМожно ли действительно пройти нужный сценарий и правильно ли выглядит экран?
ДеплойУстановлена ли выбранная версия на TEST или production?

Успешная сборка не означает, что продукт работает правильно. А тест полезен настолько, насколько полезен проверяемый сценарий. Сто тестов «функция существует» могут быть слабее одного теста реального сбоя оплаты.

Что добавляет GitHub Actions

Это сохранённая в репозитории инструкция: когда произошло событие — выполнить заданные команды. Например, после отправки изменений:

Агент отправил коммит
        ↓
GitHub запускает чистую рабочую машину
        ↓
Получает код → устанавливает зависимости
        ↓
Проверяет типы → запускает тесты → собирает приложение
        ↓
Сохраняет результат и журнал ошибок

Такая инструкция называется workflow и обычно лежит в .github/workflows/. Она может запускаться после push, при создании PR, по расписанию или вручную. PR для Actions не обязателен. Как устроены GitHub Actions.

Там выполняются обычные команды проекта — условно npm ci, npm test, npm run build. Их названия и состав мы выбираем по реальному проекту.

Для управления агент может использовать:

КомандаЧто делает
gh run listПоказывает последние запуски
gh run watch <ID>Ждёт завершения выбранной проверки
gh run view <ID> --log-failedПоказывает журнал упавших шагов
gh run rerun <ID> --failedПовторяет неудачные задания

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

Чем это полезно именно тебе

Ты хочешь работать через несколько приложений и веб-сервисов. У них разные окружения:

  • у локального агента уже установлены зависимости;
  • у веб-агента может не быть базы или возможности собрать весь проект;
  • один агент мог случайно забыть добавить нужный файл в Git.

Actions проверяет именно отправленный код в воспроизводимом окружении. Это помогает обнаружить ситуацию «на моём компьютере работает только благодаря файлам, которых нет в репозитории».

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

Нужен ли автоматический деплой

Пока — не обязательно. Можно независимо включить:

  • CI: автоматические проверки.
  • CD: подготовку выпуска или его развёртывание.

Для нас первый разумный вариант:

Агент сделал и проверил работу
          ↓
Коммит и push → проверки GitHub
          ↓
Тот же агент разворачивает выбранный коммит
через существующий Portainer
          ↓
Проверяет результат на TEST

Позже Actions может собирать Docker-образ с меткой конкретного коммита, а Portainer — запускать именно этот образ. Но сначала нужно решить доступ к серверу и хранение настроек. GitHub-машина не получает доступ к твоему локальному Docker автоматически. Можно поставить собственный исполнитель Actions — self-hosted runner, но это уже дополнительная служба, которую придётся обслуживать. Собственные исполнители.

Что выбрать сейчас

ВариантМоя оценка для тебя
Только Git как резервное сохранениеПросто, но изменения из разных сред некому автоматически проверить
Git + несколько полезных Actions-проверокОптимальный следующий шаг
Автодеплой, доски, ревью-боты, много агентовДобавлять только под конкретную пользу

Начал бы с проверки типов, сборки и небольшого набора тестов критических сценариев. GitHub Projects и обязательное ручное одобрение каждого PR для этого не нужны. Обычные проверки не расходуют токены моделей — расходуются вычислительные ресурсы; токены понадобятся агенту для разбора ошибок.

[LG-193-F037] — LG-193, фрагмент 04, строки 127-132, тема «user»

user

не понятно мне, ну точней понятно но не до конца, разберем две ситуации

  1. сейчас у меня ( на примере obsync ) есть папка в доками ( drive... ) и папка с кодом (code/project) , все агенты работают в одной ветке пишут в папку, пушать в гит бекап кучей, я выкладываю в один контейнер в портейнере - далее пушу в прод
  2. как это должно работать в нормальной схеме ? которую мы сейчас обсуждаем ?

[LG-193-F038] — LG-193, фрагмент 04, строки 133-168, тема «assistant»

assistant

В твоём случае нормальная схема может почти полностью сохранить привычный процесс. Мы объединяем код и документы, обозначаем проверенную версию и отделяем параллельные задачи, когда они действительно есть.

1. Как сейчас — по твоему описанию

Документы в drive/...  +  код в /work/code/obsync
                              ↓
               Агенты меняют одну общую папку
                              ↓
                  Коммит и пуш общей пачкой
                              ↓
                 Тестовый контейнер Portainer
                              ↓
                            Прод

Это рабочая схема, особенно если агенты работают по очереди.

Её слабое место: когда несколько агентов одновременно меняют общую папку, результаты смешиваются ещё до коммита. Один агент может сохранить или выложить чужую незавершённую работу. Потом сложно отделить «исправили форму» от «начали переделывать главную».

2. Предлагаемая схема — обычная работа с одним агентом

Есть одна основная папка Obsync с кодом и документами, один приватный репозиторий на GitHub:

obsync/
├── исходники приложения
├── docs/
├── AGENTS.md
└── README.md

Ты открываешь её в удобном приложении и даёшь задачу. Процесс такой:

[LG-193-F040] — LG-193, фрагмент 05, строки 54-57, тема «user»

user

если три агента внесли в свои ветки изменения - как все в кучу собрать ? кто это делает ? какойто гитхаб екшен или вручную мой\агентом ?

[LG-193-F042] — LG-193, фрагмент 05, строки 89-92, тема «user»

user

локальный гит привязывается к папке ? или как ? вот я хочу сейчас взять obsync - и перенести и разложить его в новом проекте , с чистой историей . как лучше сделать ? и например старые репо в github - там можно чистить историю или проще создать новый ?

[LG-193-F044] — LG-193, фрагмент 05, строки 137-140, тема «user»

user

если у меня два аккаунта гитхаба агент может пушить одновремено в оба ? или это плохая практика ? или например у меня есть гитхаб и на моем впс гитлаб или гитея ?

[LG-193-F047] — LG-193, фрагмент 05, строки 178-181, тема «assistant»

assistant

Уточню по документации GitHub, как Projects связан с ветками и агентами, и разложу твой пример по шагам.

[LG-193-F052] — LG-193, фрагмент 06, строки 89-92, тема «user»

user

а как вообще агенты с этим работают должны работать ?