Продолжение работы · · 12 мин чтения
Как передать Task другому агенту и не потерять работу
Task может продолжиться у другого агента или на другом компьютере. Незакоммиченные изменения теперь вызывают предупреждение, а не блокировку, локальный checkpoint может их сохранить, а компьютер назначения подтверждает передачу до открытия нового чата.
Работа над coding Task редко заканчивается там, где началась. Модель упирается в лимит посреди рефакторинга, ноутбук нужно закрыть на ночь, пока настольный компьютер остаётся включённым, или для оставшихся тестов лучше подходит другой агент. Новый чат с вставленным пересказом теряет структуру, которая делала продолжение безопасным: на каком commit стоит работа, какие файлы изменены, но не закоммичены, какие решения уже приняты и что ещё открыто. GrantTap сохраняет Task как стабильную единицу и позволяет передать её другому агенту или на другой компьютер, а факты, которые она переносит, и проверки, которые при этом выполняются, остаются видны на телефоне.
В этом руководстве одна передача разобрана с двух сторон: что видит и решает человек и что делает каждый компьютер. Оно также описывает изменение в GrantTap MCP 0.8.70. Незакоммиченные изменения больше не блокируют передачу. Они вызывают предупреждение, остаются на исходном компьютере, а при желании их можно сначала сохранить в локальной checkpoint-ветке. Затем компьютер назначения подтверждает подготовленную передачу, и только после этого открывается новый чат. Мы описываем то, что runtime делает сегодня, и прямо называем то, чего передача по-прежнему не делает.
Переходит Task, начинается новое Execution
В GrantTap Task — это цель, за которой вы следите, вместе с её видимой историей. Execution — одна native-сессия агента, которая работает над этой Task на одном компьютере у одного провайдера. Передача не переписывает старую сессию и не выдаёт себя за неё. Исходное Execution остаётся прежним; на стороне назначения запускается новая native-сессия в собственном worktree, а Task связывает их между собой. Разговор, который вы открываете после передачи, принадлежит той же Task, поэтому прежние сообщения, решения и изменённые файлы остаются на своих местах, а не расходятся по несвязанным чатам.
Компьютер и агента назначения вы выбираете на телефоне. Task можно передать Claude Code, Codex или Grok Build, если этот агент установлен и включён на компьютере назначения; телефон предлагает только тех агентов, которых этот компьютер включил. Grok Build может принять работу, но у него пока нет trusted caller hook, поэтому он не публикует собственные scoped-события Mesh так, как это делают Claude Code и Codex. Для Cursor GrantTap не заявляет удалённый запуск. Назначением может быть другой связанный компьютер или тот же самый: на том же компьютере Task продолжается с другим агентом в новом worktree от последнего commit, и push не нужен. Если компьютер назначения не может запустить нужного агента, передача останавливается с причиной, а не выбирает втихую другой инструмент.
Что передаётся, а что остаётся
Передачу описывает ограниченная Task Capsule, собранная из явных фактов, а не из пересказа модели. В ней указаны цель и статус Task, исходный и целевой компьютер и агент, репозиторий, ветка и commit, с которого нужно начать, изменённые файлы, зависимости и claims на ресурсы, оставшаяся работа и важные решения. Можно выбрать одну из моделей, которые объявляет компьютер назначения, и добавить короткую заметку о причине передачи. Обе вещи передаются внутри зашифрованной capsule; компьютер назначения включает заметку в первое сообщение новой сессии и запускает выбранную модель. Кроме того, назначение получает видимый разговор Task и доступные вложения, поэтому следующий агент читает то же, что могли прочитать в чате вы, а не пересказ.
То, что не передаётся, определено так же точно. Скрытые рассуждения и приватное состояние сессии провайдера остаются у провайдера, который их создал. Рабочее дерево тоже не копируется, и агент не устанавливается за вас. Компьютер назначения работает от commit, который он действительно может получить. Именно это ограничение делает остальную часть процесса честной: commit можно назвать, проверить и получить через fetch, а несохранённую правку на чужом диске — нельзя. Всё, что описано ниже, нужно для того, чтобы этот commit был правильным, и чтобы вы прямо узнавали, если часть работы в него не попала.
Незакоммиченные изменения — предупреждение, а не стена
Прежние версии runtime отказывали в передаче, если в checkout были незакоммиченные изменения. Это защищало работу, но мешало человеку, который знал, что правки — черновые файлы или брошенный эксперимент, и требовало ручного commit перед каждой передачей. Начиная с GrantTap MCP 0.8.70 проверка готовности показывает незакоммиченные изменения как предупреждение. На телефоне формулировка прямая: «This task has uncommitted changes. They stay on the source computer; the next agent starts from the last commit.» Решение остаётся за вами и принимается с этой информацией перед глазами, а не отнимается у вас.
Предупреждение не означает тихого сокращения работы. Capsule сообщает следующему агенту, какие изменения остались и на каком компьютере и что их нет в его стартовом commit, поэтому он может сказать об этом, а не считать, что получил всё. «Незакоммиченное» определяется по git status вместе с неотслеживаемыми файлами, потому что новый файл, который никто не добавил, — это работа, которую не перенесёт ни один commit. Если GrantTap вообще не может прочитать рабочее дерево, он сообщает, что незакоммиченные изменения могут остаться позади, и предупреждает об этом так же. Проверка без ответа никогда не считается чистой.
Checkpoint сохраняет изменения, не трогая вашу ветку
Если правки важны, запросите checkpoint с телефона. Исходный компьютер коммитит незакоммиченную работу, включая новые файлы, в локальную ветку, имя которой начинается с granttap/checkpoint/ и продолжается идентификатором Task, а capsule переносит этот commit вместо последнего. Commit собирается из временного индекса. HEAD, текущая ветка и рабочее дерево остаются ровно такими, какими их оставил агент, поэтому сессия, всё ещё открытая на исходном компьютере, не обнаружит, что её файлы проиндексированы, перемещены или сброшены.
Две защиты не дают checkpoint превратиться в утечку или путаницу. Файлы, имена которых указывают на секреты, например файл окружения или приватный ключ, не попадают в commit и записываются как исключённые, а checkpoint получает статус частичного, а не полного. Каждый checkpoint получает собственную ветку с отметкой времени, поэтому Task, переданная дважды, не сдвигает прежний checkpoint и не оставляет его commit недостижимым. Это обычная локальная ветка: её можно посмотреть через git log или git diff, позже слить нужное или удалить. Сам по себе checkpoint никуда не публикуется.
Push остаётся вашим решением
Другой компьютер может начать только с commit, который у него есть. Лист передачи говорит об этом одной фразой: другому компьютеру нужен commit, поэтому отправьте ветку или убедитесь, что он может её получить. GrantTap не выполняет push или fetch по собственной инициативе. Push происходит только тогда, когда вы включаете его для конкретной передачи; переключатель появляется лишь при передаче на другой компьютер, а ваш выбор не переносится на следующую передачу.
Если вы его включили, исходный компьютер публикует ветку, указанную в capsule, — checkpoint-ветку или текущую — в уже настроенный remote этого checkout до отправки capsule и никогда не делает это принудительно. Если push не удался, передача останавливается, а не отправляет capsule, указывающую на commit, до которого никто больше не доберётся. На принимающей стороне компьютер, у которого нет нужного commit, один раз выполняет fetch этой ветки, прежде чем отказать. Передаче в пределах одного компьютера push не нужен вовсе: commit уже есть в репозитории.
Компьютер назначения проверяет всё до открытия чата
Выбор назначения — это запрос, а не доказательство готовности. Сначала исходная сторона убеждается, что агент не находится посреди хода: вы ставите его на паузу или даёте ходу завершиться, чтобы одобряемое состояние не продолжало меняться. Затем компьютер назначения выполняет собственные проверки, когда получает capsule. Есть ли разрешённый локальный checkout этого проекта? Есть ли указанный commit? Включён ли целевой агент? Пересекаются ли claims из capsule с claims другого Execution, которое там работает? Если хотя бы один ответ неверный, он явно отказывает, и причина приходит на телефон вместо наполовину запущенной сессии.
Передача на другой компьютер также подтверждается только пока исходный checkout стоит на том же commit и с теми же незакоммиченными изменениями, что и в момент вашего согласия. После подтверждения компьютер назначения готовит Task: её стабильную идентичность и исходное название, изолированный worktree, выбранного агента и модель и видимый контекст. Если контекст отсутствует или слишком велик, подготовка отклоняется, а не молча теряет историю. Подготовка не вызывает агента. Ваше первое сообщение в новом чате запускает одну native-сессию, следующие сообщения продолжают её же. Запуск записывается до старта провайдера, поэтому прерванный первый запуск просит проверить компьютер назначения, а не создаёт втихую вторую сессию.
Что вы видите на телефоне
На iPhone передача начинается с Task. Лист передачи просит выбрать компьютер и агента назначения, объясняет checkpoint-ветку, предлагает переключатель push, если назначение — другой компьютер, и показывает проверки готовности с текущими ответами: репозиторий, рабочее дерево, пересечение claims на ресурсы и целевой агент. Строка с проблемой говорит, что именно найдено. Незакоммиченные изменения показываются как предупреждение с приведённой выше фразой и никогда не блокируют передачу, а рабочее дерево, которое не удалось прочитать, описывается так же, а не выдаётся за чистое.
После подготовки передачи телефон ждёт подтверждения от компьютера назначения. Новый чат открывается только после проверенного receipt и появления этого чата в списке назначения; если компьютеры не могут подтвердить доступ, телефон просит проверить их подключение и повторить попытку. Разговор Task записывает этот шаг как события между сообщениями старого и нового Execution: Handoff requested, затем Handoff accepted или Handoff failed с причиной. Если вы позже напишете в исходный чат, GrantTap предупредит, что продолжение там начинает параллельную ветку работы. Снимок в конце статьи показывает такой разговор на детерминированных тестовых данных.
Чего передача не обещает
Receipt говорит, что компьютер назначения принял конкретную capsule. Он не доказывает, что следующий агент понял каждое решение или что код проходит тесты. Считайте первый ответ новой сессии проверкой. В нём должны быть цель, commit, с которого агент начал, и упоминание изменений, оставшихся позади, если они были. Если этого нет, поправьте агента до того, как он начнёт что-то менять; исходная сессия и её файлы по-прежнему находятся на исходном компьютере.
Передача также не переносит учётные данные, входы в аккаунты провайдеров и локальные инструменты. На компьютере назначения должны быть репозиторий, установленный агент с выполненным входом и запущенный helper GrantTap. Ваши правила действуют там, куда пришла работа: запрет Governance на компьютере назначения распространяется на новую сессию независимо от того, кто запросил передачу. И передача — не слияние. Исходная и целевая сессии работают в разных worktree, поэтому объединение результатов остаётся обычным решением git, которое вы или агент принимаете осознанно. Передача работы — шаг координации, а не способ обойти границу.
Короткий список перед передачей
Перед передачей Task ещё раз прочитайте список готовности. Если появилось предупреждение о незакоммиченных изменениях, решите, относятся ли эти правки к Task. Если относятся, сохраните их в checkpoint. Если назначение — другой компьютер, включите push для этой передачи или убедитесь, что тот компьютер сам может получить ветку. Добавьте одну строку о том, почему работа переходит и что следующему агенту сделать первым; она станет частью его первого сообщения.
Затем прочитайте первый ответ нового чата, прежде чем оставить его без присмотра. Если он называет не тот commit, игнорирует заметку или приписывает себе работу, которая осталась позади, остановите его и уточните задание. На исходном компьютере остаются исходная сессия и, если вы не сделали checkpoint, незакоммиченные изменения. Преемственность держится на фактах, которые можно проверить на каждом шаге, а не на надежде, что пересказ был полным.
