# Передача AI-агента: как контролировать активные сессии ночью Передача AI-агента проходит плохо, когда уходящий инженер передает историю вместо ответственности. Фраза «агент все еще занимается деплоем» почти ничего не говорит следующему человеку. Ему нужно знать, какой процесс сохраняет полномочия, к чему он может обращаться, какой запрос ждет человека, где находятся свидетельства и как остановить или восстановить работу. Сложность в том, что агент может действовать, пока никто не смотрит на терминал. У него может оставаться активное SSH-соединение, долговечная фоновая задача, токен в окружении, запрос согласования на ноутбуке или частичное удаленное изменение, которое станет заметно только позже. Хорошая передача превращает все это в ограниченное и понятное рабочее состояние. Плохая передает неопределенность и называет ее непрерывностью. ## Для передачи нужна запись об ответственности, а не сводка из чата Полезная запись о передаче отдельно фиксирует полномочия и состояние, потому что сбои у них разные. Состояние показывает, что агент уже сделал и планирует сделать. Полномочия показывают, что он все еще может сделать. Команды часто описывают первое и забывают второе. Так безобидное продолжение превращается в непроверенную запись в production. Составляйте запись, пока уходящий инженер еще может проверить машину и объяснить решения. Не восстанавливайте ее по памяти после того, как кого-то разбудит оповещение. Короткий документ с точными идентификаторами полезнее длинного рассказа, переполненного уверенностью. Для каждого активного запуска зафиксируйте: - идентификатор процесса агента, идентификатор сессии, рабочую директорию и время запуска; - уходящего владельца, принимающего владельца и время смены ответственности; - поставленную задачу, последнее завершенное внешнее действие и следующее предлагаемое внешнее действие; - все доступные цели, например алиас хоста, базовый URL API, репозиторий, тикет или окружение деплоя; - команду остановки, команду восстановления и расположение свидетельств. Не пишите «есть доступ к staging», если можете указать: «процесс 4182 может обращаться к API деплоя staging через одобренную сессию S-204». Широкие обозначения скрывают детали, от которых зависит безопасность продолжения работы. В записи об ответственности также должно быть четкое решение по каждому запуску: продолжить, приостановить, отменить или сначала проверить. «Наблюдать» не подходит. Это заставляет следующего инженера самому решать, может ли он вмешиваться. Передача завершена только тогда, когда принимающий инженер подтвердил запись и сам нашел работающий процесс. Сообщение в перегруженном канале означает доставку, а не передачу ответственности. Если никто не принимает ответственность, уходящий инженер должен приостановить работу или отозвать внешние полномочия, если это возможно. ## Найдите действующие полномочия до смены владельца Нельзя передать управление сессией, которую вы не нашли. Начните с локального дерева процессов, затем проверьте соединения, доступность окружения и задачи, созданные за пределами текущего терминала. Интерфейс агента может сообщать, что задача завершена, хотя дочерний процесс, панель мультиплексора оболочки или главное SSH-соединение все еще работают. В macOS или Linux начните с простых команд и сохраните их вывод в материалах передачи. Замените примеры настоящим идентификатором процесса агента или учетной записи. ```sh ps -axo pid,ppid,user,lstart,command | grep -E '[a]gent|[c]laude|[m]cp' pgrep -P 4182 -alf lsof -nP -p 4182 ``` Первая команда выдает строку процесса примерно такого вида: ```text 4182 901 alex Tue Mar 18 22:14:07 2025 agent-runner --task deploy-api ``` Вторая показывает дочерние процессы. Третья, открытые файлы и сетевые конечные точки. Ищите унаследованные оболочки, открытые Unix-сокеты, TCP-соединения, локальные файлы с учетными данными и каналы к помощникам согласования. Не вставляйте вывод команд с секретами в тикет. Сохраните его в разрешенной записи об инциденте или скройте чувствительное значение, оставив путь к файлу и сведения о соединении. SSH нужно проверять отдельно, потому что его соединение может пережить одну команду. В руководстве OpenSSH `ssh_config` сказано, что `ControlPersist` может сохранять главное соединение после завершения исходного клиента. При повторных командах это экономит время. При передаче смены это означает, что «команда завершилась» еще не доказывает окончание удаленного доступа. Проверьте главные сокеты и процессы перенаправления: ```sh ps -axo pid,ppid,command | grep '[s]sh' find ~/.ssh -type s -name '*control*' -print lsof -nP -iTCP -sTCP:ESTABLISHED | grep '[s]sh' ``` Затем задайте более важный вопрос, чем «соединение открыто?»: что удаленная сторона все еще может выполнять? Удаленная сборка может продолжаться после исчезновения локального клиента. Команда деплоя могла применить одно изменение и завершиться с ошибкой до сообщения о следующем. Прежде чем решать, возобновлять ли работу, зафиксируйте идентификатор удаленной задачи, запись о деплое или состояние сервиса. Не считайте открытый порт признаком вредоносной активности. Но каждое необъяснимое открытое соединение рассматривайте как неурегулированные полномочия. Принимающий инженер должен либо понять его, либо закрыть, либо передать вопрос на следующий уровень. ## У ожидающих согласований должны быть решение и срок действия Ожидающее согласование, это предложение выполнить действие, а не бронь, оставленная уходящим инженером. Человек, принимающий смену, не должен получать запрос с единственной инструкцией: «нажми, если появится». Такая фраза предлагает одобрить решение без контекста. Для каждого ожидающего запроса укажите пять вещей: 1. Точное действие, включая метод и цель. «Обновить сервис» недостаточно. «Выполнить POST к конечной точке деплоя production-api» дает отправную точку. 2. Причину действия и условие, из-за которого оно понадобилось. 3. Ожидаемый результат и наблюдаемое свидетельство, которое его подтвердит. 4. Срок, после которого запрос должен истечь и быть сформирован заново. 5. Имя человека, которому разрешено его одобрить или отклонить. Согласование без этих данных должно истечь. Повторно создать запрос дешевле, чем восстанавливать систему после незрячей записи. В спокойную смену это правило кажется излишне строгим. После того как карточка согласования переживет блокировку ноутбука, переподключение и изменение масштаба инцидента, его смысл становится очевидным. Не используйте передачу смены, чтобы расширить полномочия на согласование. Если уходящий инженер мог одобрить изменение в staging, это не значит, что принимающий инженер может одобрить его вариант для production. Пока запрос ждал, область действия могла измениться. Перед действием человека заново проверьте цель, данные запроса и текущее состояние инцидента. Есть и вопрос времени. Если инструмент может запросить действие спустя долгое время после формирования запроса агентом, срок действия нужно заложить в сам запрос. Просроченное согласование может воздействовать на систему, которая уже восстановилась, перешла на резервную схему или была изменена вручную. В запросе может быть описана технически допустимая операция, которая больше не является правильным решением. Я предпочитаю короткую заметку о согласовании длинной расшифровке. Следующий инженер должен менее чем за минуту ответить на три вопроса: что произойдет, где это произойдет и почему это все еще нужно сделать сейчас? Если ответить нельзя, отклоните запрос и попросите агента проверить текущее состояние перед новым предложением. ## Владелец сессии и владелец секрета должны оставаться разными Человеку, который контролирует сессию, не нужна копия всех учетных данных, доступных сессии. Смешение этих ролей создает знакомую и дорогую проблему: кто-то экспортирует токен в профиль оболочки «только для передачи», а потом токен переживает инцидент, полномочия инженера и память о том, зачем он вообще появился. Правильная передача меняет того, кто может контролировать, одобрять, приостанавливать или отзывать действие. Она не передает API-токены, закрытые SSH-ключи, cookies браузера или временные облачные учетные данные через чат, заметки или промпт агента. Новый владелец получает ссылку на сессию и свидетельства, необходимые для работы. Исполнитель действия сохраняет секрет. Это особенно важно, когда уходящий инженер оставляет терминал открытым. Разблокированная оболочка не является способом передачи ответственности. Она отдает следующему человеку набор унаследованных состояний: экспортированные переменные, историю команд, сохраненные учетные данные, функции оболочки, перенаправления портов и незавершенные команды. Некоторые из них могут пригодиться. Но ясной ответственности среди них нет. Используйте один из двух подходов: - Продолжайте существующую сессию только тогда, когда активная операция понятна, ее область ограничена, принимающий инженер ее принял, а остановка создала бы больший операционный риск. - Остановите старую сессию и запустите новую под ответственностью принимающего инженера, если задача носит исследовательский характер, полномочия широки, важна история промптов или агент бездействует. Второй подход обычно безопаснее, чем принято считать. Команды сопротивляются ему, потому что боятся потерять контекст. Сохраните контекст в пакете передачи, а не внутри непроверенного процесса. Новый процесс получает чистую границу согласований, а ответственность нового владельца становится очевидной. Для команд, использующих Sallyport, агент может выполнять HTTP- и SSH-действия, не получая исходные секреты. Поэтому при смене смены можно передать контроль, а не материалы с учетными данными. Блокировка шлюза хранилища запрещает действия, пока хранилище закрыто, и дает новому инженеру осознанную паузу перед разрешением продолжения. Не принимайте это разделение за защиту от всех проблем. Если новый владелец может одобрять действия в сессии, ему все равно нужны дисциплина, ограничение области и свидетельства. Исключение секрета из промпта предотвращает один класс сбоев. Оно не делает небезопасный запрос безопасным. ## Восстановление должно начинаться с сдерживания, а не с продолжения Если запуск агента замолчал или уходящий инженер стал недоступен, принимающий инженер сначала должен предотвратить новые внешние изменения. Не стоит десять минут пытаться восстановить точный разговорный контекст, пока фоновый процесс продолжает записывать данные. У восстановления два направления: сохранить свидетельства и установить текущее состояние. Если есть вероятность исчезновения процесса или хоста, выполняйте их именно в таком порядке. Скопируйте идентификаторы сессии, вывод терминала, определения задач, согласования, списки процессов и ссылки на аудит в запись об инциденте. Затем остановите, отзовите или заблокируйте путь к действию согласно обычным мерам контроля системы. После сдерживания проверьте целевую систему. Заявление агента о том, что вызов завершился ошибкой, слабее записи на стороне цели. Тайм-аут HTTP может означать, что сервер отклонил запрос, принял его один раз или принял его, но потерял ответ. Повтор без механизма идемпотентности может продублировать действие. Используйте естественные для цели свидетельства: - Для записи через API проверьте объект, запись об изменении, идентификатор запроса или запись об идемпотентности. - Для работы через SSH проверьте удаленный процесс, состояние сервиса, историю менеджера пакетов или маркер деплоя. - Для изменения кода отдельно проверьте diff репозитория, коммит, запуск CI и состояние деплоя. - Для операции в очереди проверьте очередь и состояние обработчика до отправки новой задачи. Важно различать повтор запроса и восстановление операции. Повтор снова пытается передать запрос. Восстановление сначала устанавливает, изменилось ли исходное состояние, и только потом выбирает следующий шаг. Команды смешивают эти понятия, когда агент представляет тайм-аут как приглашение нажать «запустить снова». Это не так. В заметке о восстановлении указывайте последнее надежное наблюдение, а не последнюю фразу агента. Например: «После запроса деплоя D42 агент получил тайм-аут. Сервис деплоя сообщает, что D42 выполняется на двух экземплярах. Новые отправки приостановлены в 02:17». Это дает следующему оператору фактическую точку для продолжения. Если установить состояние нельзя, поднимите уровень инцидента и сохраняйте ограниченные полномочия. Застрявший деплой часто можно переждать. Повторная миграция схемы, дублированный платеж или случайное удаление в production могут стать серьезной проблемой. ## Перед принятием записи сопоставьте ее со свидетельствами Документ о передаче, это интерпретация оператора. Аудиторская запись, это свидетельство того, что зафиксировала система. Нужны оба, но считать их взаимозаменяемыми нельзя. Прежде чем принимать активную сессию, сравните запись об ответственности со свидетельствами, которые уходящий инженер не редактировал вручную. Проверьте время запуска и завершения сессии, имена целей, последовательность действий и указанное решение по согласованию. Несоответствия нужно изучить до продолжения запуска. Цепочка хешей помогает заметить удаление и перестановку записей. Она не доказывает намерение, правильность или разумность согласования. Это ограничение полезно обозначать прямо. Криптографическая целостность отвечает на вопрос «осталась ли записанная последовательность неизменной?». Она не отвечает на вопрос «нужно ли было отправлять этот запрос?» В Sallyport команды могут проверить зашифрованную цепочку аудита офлайн такой командой: ```sh sp audit verify ``` Сохраните результат проверки рядом с записью о передаче, указав время запуска и просмотренный диапазон журнала. Для проверки не нужен доступ к хранилищу. Это удобно, когда новому инженеру нужно проверить целостность до разблокировки полномочий на действия. Не приучайте команду копировать большие фрагменты аудита в чат. Даже без секретов журналы часто содержат чувствительные операционные данные. Храните ссылку на разрешенную запись, цитируйте только небольшой фрагмент, нужный для объяснения передачи, и предоставляйте доступ через обычный путь инцидента. Проверка аудита также обнаруживает простую, но серьезную проблему: инженер мог запустить двух агентов с похожими задачами и забыть об одном. Список процессов показывает, что работает сейчас. Последовательность аудита показывает, что уже пытался сделать каждый запуск. Перед принятием ответственности прочитайте оба источника. ## Пакет передачи должен работать, даже если никто не помнит инцидент Хороший пакет позволяет инженеру, которого разбудили пять минут назад, принять безопасное решение. Он не должен требовать прокрутки сотен сообщений в чате или повторного открытия бесконечной истории промптов. Храните пакет рядом с записью об инциденте, каждый раз используйте один и тот же порядок полей и обновляйте его при изменении полномочий. Используйте этот шаблон как отправную точку: ```text Инцидент или изменение: Уходящий владелец / принимающий владелец / время передачи: Запуск агента: - Идентификатор сессии и локальный PID: - Рабочая область и ссылка на задачу: - Текущее состояние: continue | pause | cancel | inspect - Последнее подтвержденное внешнее действие: - Следующее предлагаемое действие: Полномочия: - Цели, доступные этому запуску: - Состояние согласования и срок действия: - Способ отзыва или остановки сессии: - У кого остаются учетные данные: Свидетельства: - Ссылка на запись активности или аудита: - Проверенные свидетельства на стороне цели: - Снимок процессов и соединений: Восстановление: - Известное частичное состояние: - Безопасное первое действие для принимающего владельца: - Ответственный за эскалацию и условие: ``` Строка «безопасное первое действие» занимает место не зря. Запишите действие, которое собирает данные, не увеличивая воздействие: например, проверку записи о деплое, чтение размера очереди или сравнение версии сервиса. Не пишите «продолжить исследование». У этой фразы нет операционной границы. В пакете также укажите, что изменилось после запуска агента. Мог начаться запрет на релизы, увеличиться отставание реплики базы данных, появиться сообщение клиента о проблеме или другой инженер мог внести ручное исправление. Агент действует на основании полученного контекста. Человеку, принимающему смену, нужен и контекст, появившийся после начала промпта. Пишите фактами. Фраза «агент, кажется, запутался» советует преемнику не доверять ему, но не дает ничего для проверки. Формулировка «агент повторно предложил тот же POST после того, как сервис показал запрос с идентификатором 7f3 как принятый» указывает на риск дублирования и подсказывает правильную следующую проверку. ## При смене смены возникает разрыв полномочий, если не учитывать время Разрыв появляется, когда уходящий инженер уже мысленно закончил смену, но его сессия все еще может действовать. Он увеличивается, если принимающий инженер еще не принял ответственность, не видит состояние согласований или считает, что агент лишь читает данные. В этот момент процесс обладает полномочиями, но за их использование не отвечает внимательный человек. Типичная ошибка выглядит так. В конце смены инженер просит агента исправить неудачный деплой. Агент открывает SSH-соединение, редактирует файл конфигурации и ждет согласования перезапуска сервиса. Инженер пишет в чате «перезапуск ожидает, все должно быть нормально» и уходит. Следующий инженер видит запрос через час. За это время ручное исправление изменило топологию сервиса. Теперь ожидающий перезапуск затрагивает узел, который обслуживает трафик и о котором предыдущий инженер не знал. Само согласование по-прежнему описывает допустимую команду, но обстоятельства, оправдывавшие ее, изменились. Для такой ошибки не нужны скомпрометированный инструмент или небрежный человек. Она возникает, когда полномочия считают постоянными, хотя операционный контекст меняется. Согласование должно быть связано с краткоживущим запросом и текущим владельцем. Когда нет ни того ни другого, сессия должна потерять полномочия. Задайте явный срок передачи. Если принимающий инженер не принял сессию к этому времени, приостановите агента и аннулируйте все ожидающие согласования. Если задачу нельзя безопасно приостановить, заранее укажите это в инструкции, определите, кто может ее принять, и настройте прямой путь эскалации. Не выясняйте исключение во время смены. Иногда команды сохраняют все сессии активными, потому что перезапуск агентов занимает время. Такой совет популярен: он сохраняет локальный контекст и избавляет от повторного объяснения задачи. Для широких или неясных полномочий он ошибочен. Несколько минут на запуск чистой сессии дешевле, чем попытки объяснить, почему оставленный процесс изменил систему после ухода владельца. ## Принимающий инженер должен принимать ответственность в установленном порядке Принимающему инженеру нужен повторяемый порядок действий, потому что передачи происходят при рассеянном внимании. Это не бюрократия ради спокойного дня. Такой порядок не дает человеку, которого разбудило оповещение, одобрить действие до выяснения, какие полномочия все еще действуют. Используйте такой порядок: 1. Прочитайте текущее состояние инцидента и запись об ответственности, затем подтвердите уходящего инженера и время передачи. 2. Найдите указанный процесс или сессию и проверьте активные соединения, дочерние процессы и ожидающие запросы. 3. Сопоставьте запись с аудиторскими свидетельствами и состоянием на стороне цели. 4. Выберите продолжение, приостановку или отмену. Отклоните каждое ожидающее согласование, для которого больше нет ясного и актуального обоснования. 5. Зафиксируйте принятие ответственности, первое безопасное действие и время следующей проверки. Порядок важен. Если сначала одобрить, а потом проверить, самый большой риск уже принят. Если сначала проверить цель, не сохранив запись сессии, можно потерять свидетельства при завершении процесса или перезапуске машины. Фиксированный порядок защищает от естественного желания «просто запустить все». У уходящего инженера тоже есть четкая обязанность: оставаться доступным, пока преемник не примет ответственность или сессия не остановится. Если покрытие заканчивается раньше, передайте вопрос на следующий уровень, а не оставляйте работающего агента без объяснений. График дежурств назначает человека, а не расплывчатую надежду, что кто-то заметит запрос. Встройте эти правила в практику работы с инцидентами до того, как ночной сбой заставит вас заняться ими. Начните с добавления полей ответственности в одну существующую запись о передаче и требуйте решения по каждому запуску агента. Когда вы впервые найдете необъяснимое SSH-соединение или согласование без владельца, это будет реальный пробел, а не теоретическая проблема.