Работа агента на практике · · 15 мин чтения
Почему спящий Mac не отвечает агентом: проверяем всю доставку
Отделяем выключенный экран, сон системы, сохранение на relay, приём компьютером и начало работы агента до повторной отправки.
Вы отправили короткое продолжение с телефона, увидели сохранение сообщения и убрали iPhone. Mac находится в другом месте, его экран чёрный, ответа нет. Очень хочется сразу назвать причиной медленную модель, неисправный relay или сон компьютера. Но эти наблюдения не доказывают ни одну из версий. Выключенный дисплей, спящий Mac, потерянная сеть и недоступный сеанс провайдера могут выглядеть одинаково, хотя исправляются совершенно разными действиями. Повторная отправка текста обычно добавляет ещё одну неизвестную операцию вместо объяснения первой.
Этот практикум помогает разделить состояния и сохранить исходную корреляцию сообщения. Примеры относятся к обычному локальному coding-агенту и поддерживаемым представлениям доставки GrantTap. Они не являются обещанием разбудить любой Mac через телефон или доказательством, что сохранённый текст уже попал в модель. Для опытов выберите отдельную безопасную Task: например, чтение учебного файла. Не используйте настоящую публикацию приложения или отправку покупателю в качестве проверки связи. Задача опыта состоит в понимании доступности компьютера, а не в выполнении важной операции при заведомо непонятном состоянии исполнения.
Короткая проверка
Используйте отдельную тестовую Task и только разрешённую рабочую папку.
Сохраните исходную связь
Запишите Task, ID сообщения, время и последний подтверждённый этап. Не копируйте приватный prompt в диагностический лог.
Task: dedicated delivery test Message: original ID Relay stored: yes / no / unknown Computer received: yes / no / unknown Agent activity: yes / no / unknownСравните два состояния
Проверьте одно безопасное сообщение на бодрствующем компьютере, затем те же границы после управляемого сна и пробуждения.
Сначала восстановите исходную операцию
Выясните, получил ли провайдер работу и начал ли её. Восстановление не должно создавать случайный второй turn.
Составьте временную линию одной отправки
Начните с исходного сообщения и его идентификатора. Запишите время отправки, выбранную Task, компьютер назначения и самое сильное видимое подтверждение. Saved on relay относится к сохранению. Подтверждение компьютера относится к следующему этапу, активность агента — к другому наблюдению, а итоговый ответ — к ещё одному. Актуальные подписи разобраны в руководстве по доставке. Общая зелёная иконка связи не заменяет сведения конкретного сообщения: компьютер мог подключиться уже после того, как именно эта операция перестала продвигаться, либо связь могла восстановиться без восстановления сеанса провайдера.
Когда появится локальный доступ к Mac, добавьте три отдельные проверки: бодрствует ли система, работает ли нужный сетевой путь и доступен ли нужный нативный сеанс. Не меняйте все условия одновременно. Если сообщение появилось после открытия крышки и переподключения Wi-Fi, известно только, что совместное вмешательство помогло. Неизвестно, какая часть была необходима. Управляемая временная линия позволяет выбрать следующий небольшой опыт и не превращать правдоподобное объяснение в якобы установленную причину. Оставляйте непроверенные участки явно неизвестными даже тогда, когда ответ уже пришёл.
Учебная команда должна давать узнаваемый результат без значимых побочных действий. Например, попросите агента описать файл с коротким уникальным маркером в тестовом репозитории. Изменять файл для проверки связи необязательно: чтение проще отличить от выполнения второй операции. Проверяя статус, сохраняйте идентификатор исходного сообщения. Другой текстовый пузырь с почти таким же вопросом остаётся другим поручением, даже если интерфейс красиво объединяет похожие сообщения. Это различие пригодится позднее, когда вы будете сопоставлять полученный ответ, очередь и записи самого провайдера.
Чёрный экран ещё не доказывает сон системы
Дисплей может выключиться, пока компьютер продолжает исполнять программы. Сама система тоже может перейти в сон, а поведение ноутбука зависит от питания и других условий. Доступные настройки для конкретного Mac следует сверять с руководством Apple по батарее. Снимок чёрного экрана не является измерением состояния системы. В заметке об опыте укажите наблюдаемый факт и способ проверки процесса исполнения. Тогда коллега сможет понять разницу между «я не вижу изображение» и «компьютер перестал выполнять нужную работу».
Проведите два небольших опыта с одинаковой Task, провайдером и сетью. В первом оставьте компьютер бодрствовать и выключите только дисплей обычным поддерживаемым способом. Во втором используйте штатное действие сна системы. После возвращения локального доступа посмотрите, в каком опыте появился ответ и что произошло с первоначальным запросом. Для этого не нужно одновременно менять скрытые параметры питания и отключать все энергосберегающие функции. Цель состоит в нахождении конкретной границы, которая влияет на данный рабочий процесс на данном устройстве, а не в создании универсального рецепта для любого Mac.
Успех при выключенном дисплее даёт полезный, но ограниченный вывод: в проверенной конфигурации можно оставить экран тёмным, пока настроенный компьютер продолжает работу. Он ничего автоматически не говорит о ночном простое, разряде батареи, отключении питания и переходе в другую сеть. Сохраните условия: источник питания, длительность и использованное действие. Такое описание помогает повторить результат. Без него уверенная фраза «с закрытым ноутбуком всё работает» может означать совершенно другой сценарий, например внешний монитор, иной режим питания или сеанс, который завершился ещё до реального перехода в сон.
Разделяйте доступность Mac и готовность провайдера
Бодрствующий компьютер не обязательно располагает работающим сеансом Claude Code, Codex или другого выбранного провайдера. Программа могла завершиться, авторизация — истечь, а Task — указывать на уже недоступное исполнение. Перед созданием нового разговора проверьте провайдера и компьютер текущей Task. Если наблюдения Mac свежие, но запуск не происходит, полезнее получить реальный отказ провайдера или состояние его входа. Перезапуск relay не авторизует coding client. Очистка кэша телефона также не устанавливает отсутствующую локальную программу и не восстанавливает её собственный аккаунт.
В GrantTap используйте актуальные маршруты входа провайдера и управления компьютером. Installed, running и available являются разными наблюдениями. Номер версии подтверждает обнаружение программы, но не способность нужного аккаунта начать требуемую операцию. Если необходим вход, завершите поддерживаемый поток самого провайдера на выбранном компьютере. В диагностическую заметку не нужно копировать пароль или токен. Для её цели достаточно результата авторизации, названия клиента и указания, какое именно действие удалось либо не удалось выполнить после входа.
Для сравнения сначала запустите учебное чтение локально на бодрствующем Mac, затем выполните поддерживаемое продолжение с телефона в той же Task. Одинаковая ошибка в обоих случаях указывает на локальную предпосылку. Локальный успех без подтверждения получения мобильного сообщения помогает выделить маршрут и транспорт. Подтверждённое получение без последующей активности требует проверки допуска операции провайдером. Эти результаты сужают круг причин. Если заранее объяснять любое молчание сном компьютера, все три различия теряются и вы начинаете менять питание вместо исправления той части, которая действительно отказала.
Проверяйте нужный сетевой путь
Мобильный интернет на iPhone почти ничего не говорит о подключении Mac. Сеть отеля, новая точка Wi-Fi, captive portal или отключённый кабель влияют на компьютер исполнения независимо от телефона. Начинайте с маршрута сервиса, который использует конкретная конфигурация. Открытие постороннего сайта подтверждает лишь общую связность и не доказывает доступность relay с нужной авторизацией. Неуспешный ping тоже не является полным диагнозом прикладного соединения. Где возможно, используйте наблюдения самого приложения, относящиеся к нужному этапу доставки и выбранному компьютеру, а не случайный индикатор другого сетевого протокола.
Полезная последовательность опыта выглядит просто: установить рабочую базовую связь, отключить сеть тестового компьютера штатным средством и затем вернуть то же подключение. Наблюдайте исходное сообщение вместо отправки нового. Запишите последнее подтверждённое состояние Mac и момент появления свежего наблюдения после восстановления. Если выяснилось, что Task направлена на другой компьютер, остановите именно этот опыт и сначала исправьте выбор маршрута. Подключение Mac B не доказывает, что поручение для Mac A было принято. Совпадающее название проекта не отменяет различия между двумя компьютерами исполнения.
Смену сети самого телефона проверяйте отдельным опытом. Оставьте Mac бодрствовать и подключённым, отправьте безопасное чтение, затем переключите iPhone между обычными Wi-Fi и мобильной сетью. После возвращения посмотрите статус той же операции и историю ответа. Здесь проверяется переподключение контроллера, а не пробуждение компьютера. Такое разделение помогает сообщить точный дефект: например, устаревший экран доставки после восстановления сети телефона. Оно не позволяет ошибочно назвать исправно работающий Mac офлайн только потому, что мобильный интерфейс ещё не показал полученное им новое состояние.
Не приписывайте настройкам пробуждения лишние возможности
Некоторые Mac предлагают параметры пробуждения для сетевого доступа. Доступность и поведение зависят от устройства, питания и поддерживаемого сценария сервиса. Документация Apple описывает эти условия и не доказывает универсальное удалённое пробуждение для любого coding-агента. Перед тем как рассчитывать на конкретный продукт, найдите его явно описанный и проверенный механизм пробуждения. В работе с GrantTap сохранённое на relay сообщение и выбранная настройка питания остаются отдельными фактами. Ни один сам по себе не подтверждает, что спящий хост проснулся и запустил нужную операцию выбранного провайдера.
Для важной работы без присутствия рядом выбирайте конфигурацию доступности, которую можете проверить. Это может быть подходящим образом настроенный Mac с питанием или другой заранее разрешённый компьютер исполнения того же проекта. Выбор следует из требований рабочего процесса, а не из предположения по рекламному снимку. Если выбранный маршрут Task недоступен, сохраните этот факт и понятный способ восстановления. Нельзя незаметно перенаправить локальную рабочую папку на другую машину только потому, что она сейчас онлайн: доступность второго компьютера не означает наличия исходных файлов, контекста и необходимых полномочий.
Изменение режима питания само является отдельным эксплуатационным решением. Укажите период, на который нужна доступность, источник питания и ожидаемое поведение после завершения работы. Затем применяйте штатные поддерживаемые настройки, подходящие этому устройству. Этот практикум не требует держать каждый ноутбук постоянно бодрствующим. Короткая контролируемая проверка может показать достаточность выбранного режима для конкретного сеанса. Необъяснимое состояние «никогда не спать» создаёт дополнительную обязанность по обслуживанию и всё равно не подтверждает, что первоначальное сообщение дошло до нужного исполнителя. Подтверждение операции проверяется независимо от настройки системы.
Восстанавливайте исходную операцию после перерыва
Когда Mac вернулся, сначала обновите сведения о первоначальном поручении. Откройте видимый разговор Task и проверьте исходный идентификатор перед выбором Retry или ручного действия очереди. Ответ, пришедший во время отсутствия сети телефона, сильнее устаревшей подписи, которая осталась на контроллере. В руководстве по очереди описано различие ожидающей работы и операции, уже допущенной агентом. Проверка квитанции полезна именно тем, что позволяет выяснить состояние предыдущей отправки без создания ещё одного поручения. Наличие кнопки повторения не означает, что она нужна при каждом новом открытии экрана.
Если повтор действительно необходим, используйте определённое продуктом действие восстановления и прочитайте его смысл. Транспортная попытка с прежней идентичностью отличается от нового хода с таким же текстом. Нельзя честно обещать универсальное exactly-once исполнение между произвольными старыми клиентами, истёкшей историей и внешними побочными действиями. Практическая цель состоит в сохранении корреляции и проверке долговременных сведений в пределах поддерживаемого контракта восстановления. Решение создать новую инструкцию должно быть осознанным, с учётом исходной операции. Простое исчезновение предупреждения не доказывает, что неоднозначность исполнения разрешилась.
Особенно внимательно проверяйте операции с внешним результатом. Узнать, закончилась ли сборка, — чтение; опубликовать ещё одну сборку или отправить покупателю письмо — изменение состояния. После долгого неизвестного промежутка сначала посмотрите фактический результат во внешней системе. Нужен идентификатор артефакта, commit или запись сервиса, относящиеся к первоначальной попытке. Отсутствие финального сообщения в чате не доказывает, что действие не произошло. Такой принцип восстановления не делает каждое задержанное чтение опасным: он помогает выбрать глубину проверки, соответствующую последствиям конкретного повторения, и не создавать лишние внешние действия только ради более уверенной подписи интерфейса.
Сохраняйте работу при ремонте соединения
Восстановление связи не должно уничтожать рабочую папку, ради которой существовала Task. Перед очисткой различайте кэш истории на контроллере, репозиторий с незакоммиченными файлами и нативный сеанс провайдера. Области актуальных кнопок разобраны в руководстве по кэшу. Очистка данных может освободить место, но не заменяет сохранение исходников. Переустановка приложения тоже не является первым разумным опытом, когда известно только об отсутствии свежих наблюдений компьютера. Сначала определите, какие сведения вы собираетесь удалить, какой результат это должно изменить и чем после действия будет подтверждён успех.
Для практики создайте одно безопасное незакоммиченное изменение в отдельной тестовой копии. Проведите опыт с отключением сети, не удаляя эту папку, затем проверьте и историю сообщения, и локальную правку. Получается конкретный критерий приёмки: связь вернулась без незаметной замены working copy и потери изменения. Отдельный учебный репозиторий здесь полезнее важной release-ветки. Он позволяет проверить сохранность узнаваемых данных и восстановить эксперимент с нуля. Не нужно подвергать настоящую работу необязательной процедуре удаления только для того, чтобы выяснить, мог ли компьютер получить простое чтение.
Если исходный процесс провайдера завершился, запишите это отдельно от сохранённой Task. Стабильная идентичность работы помогает продолжить задачу, но следующее execution может стать другим нативным сеансом. Перед продолжением изучите доступную историю и контекст проекта. Нельзя предполагать сохранение оперативной памяти старого процесса. Небольшая передача должна назвать репозиторий, относящиеся к задаче файлы, последний подтверждённый результат и следующий шаг. Такой материал остаётся полезным даже тогда, когда восстановление исходного процесса уже невозможно. Он помогает продолжить работу осмысленно вместо имитации непрерывности, которой на уровне провайдера больше нет.
Измеряйте этап восстановления, а не всё время молчания
Ожидание в три минуты может включать сохранение relay, доступность компьютера, допуск провайдера, вычисление ответа и обновление контроллера. Для видимых событий нужны отдельные отметки, а для неизвестных этапов — явная неопределённость. Если Mac большую часть времени спал, этот промежуток не измеряет скорость модели. Если агент начал сразу и долго выполнял задачу, это не доказывает задержку relay. Разделение времени по событиям превращает эмоциональное сообщение о медленной работе в инженерный вопрос. Оно позволяет выбрать изменение, которое влияет на реально задержанный этап, а затем проверить именно его.
Повторяйте небольшой опыт тогда, когда он отвечает на вопрос. Базовый запуск на бодрствующем Mac, один опыт сна и одно отключение сети обычно полезнее десяти неконтролируемых отправок. Между опытами нужны разные идентификаторы сообщений; внутри восстановления каждого опыта идентификатор сохраняется. Сообщайте диапазон наблюдений и условия, а не самый быстрый результат как обещание постоянной скорости. Измерение одной сети и одного устройства полезно именно своим контекстом. Если убрать условия и назвать число универсальным, другой человек не сможет понять, почему его результат отличается и действительно ли возник новый дефект.
Учитывайте пределы наблюдателя. Запись экрана телефона показывает появление подписи, а журнал провайдера может показывать начало исполнения. У этих событий различаются значение и часы. Для данного практикума иногда достаточно порядка независимо подтверждённых фактов. Если требуются точные бюджеты задержки, синхронизацию времени и источники измерения стоит определить отдельно. Нельзя получать миллисекундную точность из снимка, на котором есть только время до минут и анимированный индикатор ожидания. Лучше честно отметить неизвестную длительность, чем построить красивый график с числами, которые не были измерены в соответствующих точках системы.
Заранее определите допустимый перерыв
У рабочего процесса обычно есть понятное требование ко времени доступности. Короткое учебное чтение можно продолжить после возвращения домой; срочная проверка выпуска может требовать доступного компьютера в определённое окно. Опишите это требование человеческими словами до выбора настройки питания. Тогда вы будете проверять достаточность конкретной конфигурации, а не пытаться доказать абстрактную вечную связь. Важно различать ожидаемое поведение продукта и собственный эксплуатационный план. Поддерживаемая очередь помогает сохранить поручение, но не превращает заведомо выключенный компьютер в готового исполнителя и не определяет за вас срок, когда результат ещё полезен.
Для теста выберите один небольшой допустимый промежуток и условия возвращения. Запишите, что должно остаться доступным после него: исходный текст, корреляция, видимая история и учебная правка. Отдельно укажите, какое действие допустимо выполнить автоматически, а где понадобится новая инструкция человека. Такие условия помогают проверить и успешное восстановление, и понятный отказ после превышения поддерживаемой границы. Не нужно искусственно увеличивать число повторных запусков ради прохождения опыта. Проверяемое свойство состоит в сохранении смысла операции и работы, а не в том, чтобы любой старый запрос рано или поздно исполнился любой ценой.
Если результат перестал быть нужен, отменяйте ожидающую работу доступным для её состояния способом и проверяйте подтверждение. Удаление локального уведомления, отмена очереди и остановка уже работающего агента не являются одним действием. Это различие особенно важно после длительного отсутствия сети: контроллер может ещё не знать о запуске. Сначала обновите доступные сведения, затем выбирайте подходящее действие. В учебном отчёте полезно записать, какой исход реально подтверждён. Так завершение опыта не оставляет непонятное поручение, которое неожиданно вернётся позже, когда все уже решили, что проверка закончена.
Составьте понятный план доступности
Итоговый план должен назвать компьютер, который владеет Task, ожидаемый период бодрствования, нужный сетевой маршрут и признак провайдера, которому требуется вход. Добавьте поддерживаемое действие восстановления неподтверждённого поручения и место проверки законченных артефактов. Это практическая договорённость для одного процесса, а не обещание постоянной доступности всего окружения. Коллеге должно быть понятно, когда подождать, какую предпосылку восстановить и где искать уже полученный результат. Несколько проверяемых предложений здесь полезнее большого списка настроек питания без объяснения того, какая из них отвечает за наблюдаемое поведение.
Повторяйте опыт после существенного изменения: другого режима питания, сети, runtime или компьютера исполнения. Используйте тот же небольшой пример, чтобы сохранялась узнаваемая базовая линия. После редактирования несвязанного исходного файла проверять весь маршрут сна заново обычно не требуется. Глубина проверки должна соответствовать изменению, которое могло затронуть доступность. Тогда заметка остаётся пригодной для обслуживания: видно, почему предыдущий результат ещё применим или какое предположение требует нового опыта. Такой подход экономит время и не превращает любое обновление продукта в дорогое повторение всех возможных сочетаний устройств и условий.
Успешное окончание конкретно: выбранный компьютер исполняет безопасную Task в описанных условиях, контроллер различает сохранение, получение, активность и ответ, а управляемый перерыв восстанавливается без второго поручения и потери тестовой папки. Оставшиеся ограничения пробуждения и фона названы явно. Чёрный экран после этого перестаёт быть загадочным универсальным объяснением любой задержки. Он становится одним наблюдением в системе, следующий полезный шаг которой можно определить по фактам. Если отдельное свойство пока не подтверждено, сохраните его открытым: незакрытый точный вопрос значительно полезнее неоправданной уверенности, которая исчезнет при следующем отключении сети.