Практика GrantTap · · 12 мин чтения
Контекст, с которым агент может работать: свежие основания вместо длинного чата
Отбирайте контекст под решение, привязывайте выводы к revision, раскрывайте источники и сохраняйте ограничения после compaction. Проверяйте полноту до оценки экономии токенов.
У coding-агента может быть длинная история разговора, но отсутствовать один решающий факт: в каком checkout находится исправление, почему отвергли прежний подход или запускался ли последний тест после последнего изменения. Дополнительный текст не всегда закрывает этот пробел. Полезный контекст представляет собой отобранное актуальное описание работы с возможностью вернуться к свидетельствам, на которых основаны важные выводы. Его качество определяется следующей задачей, а не количеством накопленных сообщений в окне разговора или объёмом перечитанных файлов.
В GrantTap этот вопрос возникает, когда Task продолжается после паузы, переходит между исполнениями или проверяется с другого устройства. Телефону нужен краткий материал для человеческого решения. Компьютеру и агенту нужны достаточные основания для следующего действия. Здесь предложен практический способ подготовки такого контекста. Он развивает идеи руководства по Cortex Loom, однако не приравнивает уменьшение запроса к улучшению результата. Даже очень компактный пакет бесполезен, если он потерял ограничение пользователя или скрывает отсутствие необходимого теста.
Начинайте со следующего решения
Представим исследование задержанного разрешения. В репозитории есть интерфейс, relay, адаптеры провайдеров, прежние скриншоты, отчёты сборок и несколько предыдущих попыток исправления. Загрузка всего этого создаёт внушительное окно контекста, но не уточняет первый вопрос. Полезнее спросить: получил ли компьютер решение именно для того запроса, который остаётся открытым на телефоне? От ответа зависит, какую часть системы проверять дальше. Пока такая граница не установлена, широкое чтение исходников способно только увеличить число правдоподобных предположений.
Следующее решение может касаться релиза, падения теста или смены хоста. Каждому нужен свой набор сведений. Для релиза важны происхождение артефакта и проверки кандидата. Для передачи работы нужны цель, checkout, ограничения и незавершённые действия. Для ошибки входа требуется свежее наблюдение готовности провайдера. Репозиторий содержит источники ответов, однако всё его содержимое не является единицей, которую обязательно целиком передать человеку или модели. Отбор начинается с конкретной задачи, а не с желания заранее сохранить максимум доступных данных.
Сформулируйте вопрос до сбора материала. Назовите ожидаемое решение и условия, при которых оно изменится. Тогда у отбора контекста появится правило остановки. Когда свидетельства отвечают на вопрос, агент может действовать либо точно назвать оставшийся пробел. Без такого правила чтение становится самостоятельной деятельностью: файлов всё больше, задача пересказывается всё труднее, а старые предположения сохраняются просто потому, что занимают значительную часть истории. Человеку на телефоне особенно сложно заметить эту подмену полезного продвижения объёмом активности.
Отделяйте цель от свидетельств
Устойчивая цель описывает результат, который нужен пользователю. Свидетельства описывают наблюдения, полученные к текущему моменту. Эти части должны находиться рядом, не превращаясь друг в друга. Фраза о необходимости восстановить доставку сообщений является целью. Одна native-запись пользователя для определённого запроса является наблюдением. Утверждение, что модель поняла просьбу, остаётся интерпретацией, пока доступные данные не подтверждают его непосредственно. Такое разделение мешает убедительному пересказу незаметно повышать степень уверенности в выводах после каждой новой передачи контекста.
Компактная запись задачи может различать цель, текущее состояние, принятые решения, открытые вопросы и следующую проверку. Это дисциплина подготовки материала, а не обещание наличия именно таких полей во всех интерфейсах. Она нужна, чтобы предположение не стало требованием только из-за удобного пересказа. Если интерпретация необходима, назовите её прямо и укажите наблюдение, способное подтвердить или опровергнуть вывод. Тогда следующий инженер или агент получает возможность продолжить исследование, не принимая весь прежний рассказ на веру и не повторяя его ошибки.
Различие особенно важно между провайдерами. Новый агент не наследует приватные рассуждения прежней модели. Ему можно передать явную цель и относящиеся к ней свидетельства. При хорошей подготовке этого достаточно для продолжения полезной работы. Восстанавливать скрытый ход мысли не требуется. Гораздо проверяемее сохранить решения, версии исходников, результаты и оставшиеся неизвестные факты, которые понадобились бы обычному разработчику. Такой пакет легче обсуждать с человеком и проще исправить, когда новая проверка обнаружит ошибку в прежнем объяснении.
Привязывайте выводы о коде к revision
Описание функции актуально настолько, насколько актуален исследованный исходник. Один путь может содержать разный код в двух worktrees. Ветка способна продвинуться, пока кто-то читает отчёт. Поэтому ссылка только на имя файла иногда неоднозначна. Для решений, связанных с кодом, полезны идентичность репозитория и revision. Если вывод касается незакоммиченного состояния, укажите это явно. Тогда получатель понимает, какой именно материал описан, где его искать и почему ссылка на одноимённый файл из другой рабочей копии может оказаться неверной.
Допустим, отчёт утверждает, что очередь освобождает владение после видимого ответа модели. До изменения поведения проверьте текущий путь кода и вызывающие места. Реализация могла уже поменяться, либо прежний отчёт описывал только слой отображения. Привязка к revision позволяет задать точный дополнительный вопрос вместо обращения с устаревшим объяснением как с действующим архитектурным контрактом. Это экономит время и снижает риск вернуть уже исправленную ошибку из-за контекста, который убедительно описывает более старое состояние проекта.
Свежесть не означает постоянное перечитывание каждого файла. Она означает понимание, какие изменения делают вывод недействительным. Переименование способно сломать ссылку. Изменение адаптера провайдера может изменить допущение об исполнении. Редакторская правка текста обычно не затрагивает транспортный результат. Хороший контекст содержит достаточно сведений о происхождении, чтобы различать эти случаи. Тогда можно адресно обновить небольшой фрагмент свидетельств вместо повторного построения большого рассказа с нуля после каждого коммита, даже когда изменённый компонент никак не связан с текущей задачей.
Оставляйте путь от пересказа к источнику
Полезное краткое объяснение быстро ориентирует читателя и одновременно допускает раскрытие деталей. Если в нём сказано, что callback способен попасть в устаревший запрос, читателю нужен способ изучить проверку идентичности и тест соответствующей гонки. Без такого пути сокращение может удалить именно сведения, позволяющие оспорить вывод. Короткий пакет тогда выглядит авторитетнее, хотя становится менее проверяемым. Задача контекста состоит в снижении лишнего чтения, а не в создании нового слоя утверждений, которые невозможно сопоставить с исходными наблюдениями.
Ссылки могут вести на участок кода, результат теста, manifest артефакта или документированный внешний контракт. Их не обязательно целиком копировать в первоначальный пакет. Важно, чтобы получатель мог запросить лежащий за ними материал, когда он понадобится, в пределах тех же прав доступа. Начальный рассказ остаётся компактным, но сохраняет глубину для реализации и review. Для больших проектов это особенно полезно: полный репозиторий не помещается в рабочую память человека, однако точная ссылка помогает быстро проверить конкретное основание решения.
Сломанные ссылки следует считать настоящими пробелами. Отсутствующий лог не становится пройденным тестом из-за того, что краткая запись помнит успех. Недоступный репозиторий не становится общим только благодаря упоминанию в Mesh. Если свидетельство нельзя получить, ослабьте утверждение либо повторите соответствующее наблюдение. Качество контекста растёт, когда неопределённость остаётся видимой, а не исчезает при литературной обработке пересказа. Это позволяет следующему агенту выбрать осмысленный первый шаг вместо продолжения работы на основании недоказанного, но красиво сформулированного вывода.
Понимайте, что может потеряться при compaction
Материал Anthropic о context engineering рассматривает контекст как ограниченный ресурс и обсуждает длительную работу, в том числе сокращение истории и структурированные заметки. Для конкретного проекта следующий инженерный вопрос практичен: какие сведения обязаны пережить сокращение разговора и как обнаружить, что важное ограничение исчезло? Общая техника полезна, но сама по себе не определяет приоритеты именно вашей Task, не восстанавливает недостающий тест и не заменяет явную запись пользовательского решения.
Для Task в GrantTap важными примерами являются разрешённое назначение, допустимость публикации, запрет останавливать активную работу и точная незавершённая проверка. Пересказ может отлично сохранить реализацию, но потерять эти границы, после чего следующий агент начнёт действовать неверно. Сохраняйте операционные ограничения рядом с целью. Это часть состояния задачи, которую нельзя автоматически считать второстепенной только потому, что она занимает мало строк. Несколько слов об авторизации способны влиять на правильность следующего действия сильнее, чем подробное описание устройства уже исправленного компонента.
После заметного сокращения или перезапуска попросите коротко восстановить следующий шаг и его основания. Сравните ответ с устойчивой записью. Это полезнее неопределённого вопроса, помнит ли агент всё. Он должен назвать текущий checkout, оставшуюся работу, применимые ограничения и способ проверки. Несовпадение превращается в конкретное исправление контекста до запуска новых команд. Такой приём не требует повторного чтения всей истории, однако помогает обнаружить потерю значимой границы до того, как ошибка повлияет на файлы, публикацию или активный процесс.
Сохраняйте причины отказа от важных подходов
Задача теряет много времени, если каждое новое исполнение заново открывает уже проверенный неудачный подход. Полезно оставлять короткую запись значимых отвергнутых вариантов и свидетельств, которые их исключили. Например, изменение parser не поможет запросу, не достигшему компьютера. Перезапуск транспорта может быть нежелателен, пока провайдер владеет сборкой. Причина помогает следующему агенту не возвращаться к идее только потому, что первоначальное обсуждение сократилось и от него осталось одно смутное воспоминание о потенциально простом исправлении.
Такая запись должна оставаться избирательной. Каждая неудачная формулировка текста не заслуживает постоянной памяти. Сохраняйте решения, влияющие на архитектуру, безопасность работы, совместимость или вероятный следующий этап исследования. Укажите, что проверяли и при каких условиях. Неудача эксперимента на одной версии провайдера не становится вечным универсальным запретом. После изменения соответствующего окружения основания иногда требуется пересмотреть. Важно сохранить проверяемую причину, а не превратить прежний вывод в правило, которое никто не может обоснованно поставить под сомнение.
Удобный формат — решение с областью применимости. Назовите вариант, причину отказа и условие для повторного рассмотрения. Это защищает память от превращения в догму. Человек, просматривающий Task с телефона, понимает, почему очевидное на первый взгляд исправление не выбрали. Ему не нужен полный replay терминала или доступ к приватному ходу мысли модели. Следующий агент также получает ясный критерий: какие новые данные действительно оправдывают возвращение к прежней идее, а какие просто повторяют уже пройденный круг рассуждений.
Повторное использование контекста требует прав доступа
Повторное использование материала одновременно является решением о доступе к данным. Два связанных репозитория могут относиться к одному продукту, но иметь разных участников и grants. Краткое описание приватного исходника всё равно способно раскрыть его содержание. Уменьшение размера не отменяет авторизацию. Получатель должен иметь право на сведения внутри пакета, а не только видеть название похожей задачи. Это особенно важно при передаче контекста между командами, аккаунтами, компьютерами и провайдерами с разными договорённостями об обработке информации.
Правило относится к логам, скриншотам и операционным заметкам так же, как к коду. Отчёт развёртывания может содержать имена хостов. Снимок экрана может включать приватный разговор. Ошибка входа провоцирует вставить секрет в запись, которая позднее поедет на другое устройство. Делайте повторно используемые свидетельства минимальными и ограниченными задачей. Если чувствительный материал действительно необходим, сохраняйте подходящую границу доступа вместо копирования в широко распространяемый пересказ. Иногда правильнее передать ссылку с требованием доступа, чем включить сам фрагмент в общую заметку.
Материалы GrantTap о Mesh и governance различают связь и полномочия. Применяйте это различие при подготовке контекста. Привязка репозитория сообщает, где находится работа, а grant определяет, кто может получить защищённые данные или выполнить действие. Если назначению handoff не хватает доступа, пакет должен назвать отсутствующее условие. Обход ограничения путём вставки приватного содержимого в безобидную заметку задачи меняет сам смысл защиты. Сокращённый контекст остаётся данными и должен подчиняться тем же правилам, которые действуют для его исходных материалов.
Проверяйте полноту до празднования экономии токенов
Меньший пакет ценен, когда продолжает обеспечивать нужную работу. Сравните запрос задачи, выбранные свидетельства и то, что фактически получил агент. Учитывайте пропущенные обязательные элементы и недоступные ссылки, а не только байты или оценочные токены. Пакет, который резко сократил вход за счёт удаления воспроизведения ошибки, способен прекрасно выглядеть в benchmark и одновременно увеличить число неудачных реализаций. Для пользователя важен завершённый сценарий, поэтому метрика должна учитывать сохранённую полезность, а не вознаграждать краткость независимо от результата.
Используйте небольшой список требований для конкретной задачи. Для ошибки разрешения это могут быть идентичность запроса, путь исполнения, условия отказа и воспроизводимый тест. Для релиза — commit, идентичность артефакта, выполненные проверки и оставшаяся проверка устройства. Оцените результат агента по этому списку. Так вы проверяете, помог ли контекст принять решение. Универсальный большой список обычно хуже: он снова заставляет переносить сведения, не относящиеся к текущей работе, и скрывает действительно обязательные элементы среди привычного общего описания проекта.
Отделяйте оценки от биллинга и производительности. Приблизительный подсчёт токенов по символам помогает сравнить представления, но не является счётом провайдера. Сокращение контекста также не гарантирует пропорционального ускорения: инструменты, сеть и сама модель добавляют другие затраты. Указывайте среду, метод и итог вместе. Самый полезный результат — меньший полный обмен, который сохраняет возможность проверить вывод. Если после оптимизации получателю приходится снова запрашивать всё исходное содержимое, выигрыш первого пакета ещё не показывает экономию всего сценария выполнения задачи.
Соберите пакет для настоящего продолжения
Представим, что вы уходите от компьютера, пока исправление проверяется. Полезная запись продолжения называет пользовательскую проблему, текущий репозиторий и revision, внесённое изменение и точные выполненные проверки. Затем она выделяет оставшийся тест и действие, разрешённое после его успешного завершения. Добавьте ссылки на основания. Если провайдер ещё владеет фоновым процессом, сохраните этот факт: новое исполнение не должно случайно конкурировать с ним. Такая запись помогает продолжить работу с телефона без догадок о том, что именно происходило перед уходом.
Перед передачей перечитайте материал глазами получателя. Найдёт ли он рабочую копию? Отличит ли запланированный тест от выполненного? Поймёт ли, разрешены ли push, выпуск или перезапуск? Увидит ли наблюдение, которое завершает задачу? Эти вопросы надёжнее выявляют пробелы, чем удлинение пересказа или общая просьба быть внимательным. Если на вопрос нет ответа, добавьте конкретное недостающее условие. Не требуется переписывать всю историю: достаточно устранить пробел, который мешает получателю безопасно и результативно сделать следующий осмысленный шаг.
После следующего шага обновите запись его итогом и изменившимися предположениями. Так возникает живая цепочка свидетельств вместо бесконечно растущего transcript. В мобильном сценарии она даёт телефону полезную поверхность для решения, а компьютеру — ограниченный контекст исполнения. Работа остаётся понятной после смены сессии, модели или устройства. Главное преимущество такого подхода состоит в сохранении проверяемой преемственности: новый участник знает не только направление движения, но и основания текущего состояния, границы разрешённых действий и критерий, по которому можно уверенно закончить задачу.