Продолжение работы · · 11 мин чтения
Project Mesh: сохранять работу, чтобы не делать её дважды
Занятость ресурсов, память с правами доступа и постоянная Task помогают координации между моделями и компьютерами. Неудачная попытка сохранилась после перезапуска Engine.
Два coding агента могут работать быстро и при этом вместе тратить много лишнего времени. Один исследует ошибку, причину которой уже установили в другом чате. Оба меняют соседние части модуля, не замечая пересечения. Новая модель начинает с пустого диалога и заново восстанавливает историю проекта. Эти затраты на координацию постепенно превращаются в затраты токенов: исследование, объяснение и исправление проходят через контекст моделей. Project Mesh в GrantTap даёт таким фактам устойчивое место и понятный маршрут к следующему Execution. Продолжение работы меньше зависит от того, помнит ли человек, в каком именно чате осталось важное решение.
Mesh организован вокруг Project и Task. Task — стабильная единица работы, которую видит пользователь. Execution — конкретная сессия провайдера, выполняющая эту задачу на компьютере. Смена модели, провайдера или машины не требует создавать новую идентичность самой работы. В этом проходе мы проверили границы контекста, автоматически наблюдаемые claims на файлы, доставку событий, ограничения передачи задачи и долговременную память. Неудачный запуск дополнительно записали через настоящий Engine и прочитали после перезапуска daemon. Практическая цель проста: сделать факты пригодными для повторного использования, а координацию ограниченной по объёму, без отдельной модели, которая каждый раз сочиняет отчёт о происходящем.
Аккаунт связывает компьютеры, Project связывает работу
Защищённая область устройств аккаунта и Project Mesh отвечают на разные вопросы. Аккаунт определяет, какие компьютеры и контроллеры могут участвовать в пространстве пользователя. Машина с MCP runtime добавляет маршруты к своим Task и Execution. Project Mesh связывает работу с идентичностью репозиториев, зависимостями, политикой и памятью проекта. Несколько компьютеров могут работать над одним Project, а один компьютер может содержать несколько независимых проектов. Связь репозиториев не делает все их задачи взаимозаменяемыми. Принадлежность аккаунту также не отменяет ограничения видимости. Такое разделение позволяет собрать полезную активность в одном интерфейсе, сохранив маршрут к компьютеру, который способен выполнить конкретное действие.
Поэтому Task сохраняет свою привязку к маршруту компьютера. Список на телефоне может объединять работу нескольких машин, но подтверждение команды или продолжение задачи должно попасть в соответствующий локальный runtime. Координация Project допускает пересекающиеся репозитории, объявленные зависимости и самостоятельную работу. Repository bindings связывают логическую идентичность с доступным локальным checkout, вместо предположения, что одинаковое название папки означает одинаковый проект. Это важно и для экономии: агенту нужны соседние задачи своего Project, а не полная история всех доверенных устройств. Mesh способен передать небольшое представление, не превращая аккаунт в один бесконечный общий разговор обо всём.
Наблюдать работу без дополнительного отчёта
GrantTap получает часть полезных фактов из native активности, которую уже наблюдает. Поддерживаемые записи файлов формируют claims, связанные с Execution, Task, репозиторием, checkout и путём. Доставленный запуск попадает в журнал вместе с результатом, наблюдаемым числом вызовов инструментов и изменёнными файлами. Структурированные события отражают прогресс задачи. Это алгоритмы на компьютере. Агенту не требуется отдельная команда описать каждую запись файла, чтобы интерфейс узнал о затронутом пути. Наблюдения сохраняют attribution: можно проверить, какая сессия сообщила факт, когда он появился и в какой области проекта имеет смысл использовать его при следующем инженерном решении.
У наблюдения есть конкретная граница. Система не объявляет любую shell команду проверенной записью файла и не считает выбранную capability доказательством её использования. Количество инструментов из transcript остаётся наблюдаемым показателем с ограничениями источника. Утверждение модели сохраняет статус отчёта. Такая разница делает память полезнее: следующий Execution может отдельно рассматривать наблюдаемый путь, явное решение пользователя и вывод предыдущей модели. Экономия возникает благодаря устранению повторного механического сбора и сохранению уже известных фактов. При этом исходники, тесты и соответствующая проверка поведения по-прежнему нужны, чтобы установить корректность предложенной реализации, а не просто убедиться в наличии записи о ней.
Как посмотреть работу внутри чата
Кнопки Files и Agents находятся прямо над полем сообщения. Files открывает изменения текущего ответа: количество добавлений и удалений и раскрываемый diff, когда провайдер его передал. Вкладка All Files показывает известный checkout задачи деревом папок и позволяет постранично читать файлы. Уже полученное содержимое сохраняется приватно на устройстве и открывается без сети; чтение нового пути требует связи с его компьютером. Компьютер сам определяет допущенный checkout этой Task и отклоняет выход за его пределы, внешние символические ссылки и защищённые файлы учётных данных.
Agents открывает вложенные разговоры Execution и их известные сообщения. Делегированная работа видна внутри задачи. При этом интерфейс сохраняет происхождение изменений и сообщений: правки старых ответов не прибавляются к новому, а изменения дочернего агента не приписываются родителю. Человек может увидеть, где выполнена работа, прежде чем просить модель снова составить её текстовую сводку.
Claims помогают увидеть пересечение заранее
Claim отвечает на конкретный вопрос: работает ли другой Execution над этим ресурсом? Точное совпадение в одном репозитории и checkout отличается от одинаковых путей в независимых worktree. Логическое пересечение между checkout тоже важно для последующего объединения, а активность соседнего модуля может заслуживать предупреждения без доказанного прямого конфликта. Тесты наблюдаемых claims в GrantTap проверяют эти различия, вместо сравнения одних названий файлов. У claim есть владелец и срок действия. Поэтому вчерашняя запись не должна навсегда блокировать ресурс или создавать ложное впечатление, что давно простаивающий чат продолжает работать над ним прямо сейчас.
Представим две задачи, которые исследуют сбой подключения. Одна меняет привязку аккаунта в локальном runtime, другая исправляет отображение состояния на iPhone. Небольшое представление Mesh позволяет увидеть обе Task и их claims до чтения чужих длинных transcript. Если оба агента начинают менять один runtime файл, они могут уточнить ответственность, запросить передачу работы или дождаться конкретного результата. Такой механизм помогает избежать повторного исследования и двойного исправления. Его эффект зависит от задач, степени пересечения и использования координационных фактов перед действием. Поэтому мы описываем проверенную инженерную возможность, а не обещаем одинаковый процент экономии для любого проекта и любой пары моделей.
Память неудач рядом с результатами
Project memory сохраняет решения, результаты и попытки вместе с происхождением. Неудачный подход полезен следующему Execution: видно, что уже проверяли и почему этот путь не закрыл задачу. Обновлённая доставка автоматически добавляет структурированные признаки неуспешного запуска. Проекция в память создаёт запись attempt, а не успешный result или новое решение проекта. Идентификатор исходного события позволяет распознать ту же попытку при повторной синхронизации и не плодить одинаковые записи. Успешный промежуточный запуск также остаётся прогрессом: система не объявляет целую Task завершённой только потому, что один ответ агента вернулся без транспортной ошибки или очередная команда закончилась нормально.
Видимость является частью записи. Неудачный прогресс Task остаётся приватным для этой Task. Явно опубликованное завершение может открыть соответствующую попытку всему Project. Ответ модели сохраняет источник agent report, а решение пользователя имеет собственное происхождение. Исправление старой записи сохраняет связь supersedes, чтобы два противоречащих вывода не оставались одинаково активными. Во время проверки настоящего Engine мы записали причину неудачи, перезапустили daemon и получили ту же attempt из долговременной истории. Это подтверждает сохранность памяти. Польза для другой задачи зависит от разрешённой видимости и релевантности, а не от предположения, что любая ошибка автоматически становится инструкцией для всех остальных чатов аккаунта.
Компактное представление делает память доступной
Общая память потеряла бы смысл, если каждый prompt получал все накопленные события. GrantTap готовит ограниченный контекст со стабильными идентификаторами и ссылками на раскрытие. Компактное представление Project показывает окно событий, окно знаний, claims, идентичность Task и соседнюю активность. Полное чтение доступно для проверки конкретного источника. Известный курсор позволяет получить новые события после указанного идентификатора. Если курсор неизвестен, система возвращает компактное исходное состояние и явно указывает причину. Она не пытается угадать, какие обновления читатель уже видел, и не выдаёт неполную дельту за достоверное продолжение ранее полученной истории.
Интеграция prompt для Claude также предлагает ограниченные непрочитанные сводки запусков и Mesh brief при следующем поддерживаемом prompt. Такой brief может показать другие активные Task, близкие claims, зависимости и нерешённые координационные вопросы. Предложенная информация отделена от подтверждённого прочтения: доставка не означает, что агент понял сообщение или уже выполнил действие. У других провайдеров есть собственные реализованные ресурсы и hooks, поэтому покрытие рассматривается отдельно. Общий принцип — экономная доставка полезной координации. Она должна помогать следующему шагу работы, а не создавать ещё один обязательный длинный рассказ, который каждый агент сначала генерирует, а затем снова читает за счёт пользователя.
Передача другой модели с сохранением Task
Handoff capsule переносит факты для продолжения: цель и статус Task, исходного и целевого провайдера, компьютеры, репозиторий и revision, изменённые файлы, зависимости, claims, оставшуюся работу и важные решения. Пользователь может добавить комментарий с причиной передачи. Следующий Execution получает структурированную стартовую точку и открывает относящееся к задаче evidence. Ему не обязательно восстанавливать весь предыдущий разговор с нуля. Native сессии провайдеров остаются самостоятельными, а пользовательская Task продолжает существовать между ними. История работы сохраняет связь исполнений и позволяет понять, какую часть задачи выполняла предыдущая модель, какую передали и на каком компьютере ожидается результат.
Готовность получателя проверяется отдельно. Отключённая машина, приостановленный Execution, отсутствие права записи, нужного checkout или наличие конфликтующего claim не превращаются в готовое назначение только из-за выбора модели. Результаты доставки различают queued, blocked, offline и failed. Capsule также не обещает перенос произвольной файловой системы, установку провайдера или синхронизацию незакоммиченных изменений через текст сообщения. При работе между компьютерами настоящее состояние репозитория и worktree сохраняет значение. Такие проверки позволяют передаче экономить исследование, не создавая новую задачу по исправлению неподходящей среды, отсутствующего файла или локальной правки, которая осталась исключительно на исходной машине.
Координация не является разрешением
Сообщения Mesh направляют внимание агента к полезной работе и фактам проекта. Они могут сообщить владельца пути, изменение зависимости или неудачу предыдущей попытки. Они не разрешают обходить capability policy компьютера. Исходники и agent reports остаются данными даже внутри context packet. Такое разделение позволяет обмениваться полезной информацией, не превращая недоверенное сообщение в инструкцию выполнить shell команду, изменить глобальные approvals или опубликовать код. Предлагаемое действие оценивает локальный путь enforcement. Экономия повторной работы должна происходить внутри существующих полномочий Execution, а не благодаря незаметному расширению доступа, которое потом потребует дополнительного расследования или восстановления.
Это же правило полезно для архитектуры. Связь репозиториев бывает наблюдаемой или объявленной, и её provenance имеет значение. Граф направляет внимание к зависимости, но исходники и проверки поведения определяют настоящий эффект изменения. Запись Mesh может сохранить решение, не превращая задним числом предположение модели в проверенную истину. Следующей модели нужен пригодный для использования evidence trail, а не обязанность безусловно верить каждой прошлой фразе. Отказ от двойной работы не означает отказ от проверки. Он означает понимание, какая проверка уже выполнена, к какому revision относится, какие факты установила и по какой причине их ещё можно использовать после смены Execution.
Как оценивать устранённую работу
Полезная оценка начинается с повторного исследования или настоящего пересечения задач. Фиксируют установленные первым Execution факты, контекст получателя, повторно открытые файлы и достижение того же проверенного результата. Сравнивают полный обмен, а не только размер capsule. Короткая передача может потребовать большого восстановления, если не содержит решающего источника. Несколько дополнительных строк координации, наоборот, оправданы, когда предотвращают двойную правку модуля или повтор неудачного подхода. В измерение нужно включать работу, которая действительно привела к корректному результату: подготовку контекста, раскрытие источника, продолжение задачи и подходящую поведенческую проверку. Тогда экономия отражает полезность системы, а не только её способность выдавать меньше текста.
Этот проход подтвердил конкретные механизмы. Память другого приватного Task исключается из scoped context. Поддерживаемые native записи формируют scoped claims. Конфликтующие и устаревшие claims получают различимую обработку. Неуспешный доставленный запуск сохраняется как attempt после перезапуска Engine. Эти факты объясняют, как Mesh способен уменьшать потери работы. Они не задают универсальное сокращение счёта провайдера: парные платные сессии для всех моделей и нагрузок в этом эксперименте не выполнялись. GrantTap делает повторное использование evidence и координацию проверяемыми, позволяя проекту оценивать собственный результат, пока компьютер автоматически выполняет повторяемое управление состоянием, идентификаторами, видимостью и доставкой.
