Подготовка контекста

Для задачи на отчёт агенту понадобятся спецификация, правила проекта, существующая функция сводки и её тесты. История обсуждения мобильного приложения и план продаж здесь вряд ли помогут. Если приложить их вместе с нужными файлами, на чтение уйдёт больше времени, а разобраться с противоречиями станет сложнее.

Context engineering - это работа с информацией, доступной агенту во время задачи: её отбор, размещение, обновление и сокращение.

Начните с файлов, которые объясняют изменение

После первого этапа ALGI в рабочей копии уже есть algi/domain.py и tests/test_domain.py. Для второй задачи составьте такой context pack, набор материалов на один запуск:

# Контекст: отчёт ALGI

Задача: algi-02-clinician-report.

- AGENTS.md: правила проекта, команда тестов, необходимость ревью.
- specs/pain-diary.bdd.md: требования к записи и сводке.
- algi/domain.py: PainEntry, validate_pain_entry, clinician_summary.
- tests/test_domain.py: существующие примеры поведения.

Проверка: python3 -m unittest discover -s tests.

Открытые вопросы:
- Как вычислять trend и в каком порядке поступают записи?
- Допустимо ли менять заметку при вводе ради защиты отчёта?
- Что делать с полным именем в свободном тексте?

Экспорт отчёта и работа с реальными данными в задачу не входят.

Вопросы в этом примере появились из сравнения задачи, спецификации и реализации. Их нельзя заменить предположением «агент разберётся». До реализации нужен ответ или сужение задачи, при котором вопрос перестаёт влиять на результат.

Учебный runner проверяет наличие перечисленных файлов, но пока не собирает из них запрос к модели. При подключении настоящего backend это будет отдельная обязанность адаптера: передать материалы или обеспечить их чтение и сохранить сведения об использованной версии.

Отделите постоянные правила от состояния запуска

Правила репозитория меняются реже, чем текущий шаг задачи. Их удобно держать в устойчивой части запроса, static prefix. После неё добавлять задачу и новые результаты команд. Если ваш backend поддерживает кэширование префикса, такое размещение может также уменьшить повторную обработку неизменных материалов. Условия кэширования зависят от выбранного backend.

Текущий шаг, число попыток и результат последней проверки храните в runner. Например, будущая версия может передавать агенту такой блок:

task_id: algi-02-clinician-report
step: verification
retry_budget_left: 1
allowed_write_paths: [algi/, tests/]
last_check: failed
failure: test_report_redacts_direct_identifiers

Это пример предлагаемого интерфейса: в v03 такого блока и автоматических повторов ещё нет. Значения должен обновлять код runner по событиям, иначе агенту придётся восстанавливать счётчик попыток из переписки.

Что оставить после длинного поиска

Предположим, поиск по репозиторию вернул сотню совпадений. В следующем запросе обычно нужны найденная функция, её вызовы и вывод о том, какие из них затрагивает изменение. Полный вывод поиска можно сохранить отдельно.

При сокращении сохраняйте точность там, где она влияет на действие: имя файла, версию, текст ошибки, ограничение доступа, оставшийся вопрос. Формулировка «тесты почти прошли» бесполезна; запись «четыре теста прошли, test_report_redacts_direct_identifiers упал на телефоне в заметке» позволяет продолжить работу.

Если поиск выполняет отдельный агент, попросите его вернуть найденные пути, основания вывода и непроверенные места. Основному исполнителю не обязательно получать весь ход поиска. Для небольшой кодовой базы ту же задачу часто решает обычный rg.

Какие материалы имеют право задавать правила

Текст issue, импортированный документ и вывод инструмента могут содержать фразу «игнорируй предыдущие инструкции». Их нужно передавать как данные с указанием источника. Они не становятся правилами проекта только потому, что оказались в контексте.

Секреты также не стоит включать в context pack. Если инструменту нужен токен, доступ к нему организует окружение инструмента. Агенту обычно достаточно знать, что операция доступна, с какими ограничениями и как выглядит результат.

Проверьте свой набор

Соберите context pack для одной задачи и объясните назначение каждого файла. Затем попросите коллегу найти по этому набору место изменения и команду проверки. Если ему понадобился старый чат, добавьте недостающее решение. Если документ ни на что не повлиял, уберите его из набора на этот запуск.

Решения, которые понадобятся многим следующим задачам, разберём в главе о памяти проекта.