Формирование контекста для агентов по написанию кода

Формирование контекста — это процесс определения того, какие данные будут доступны агенту по написанию кода, прежде чем он начнет работу. Это самый мощный рычаг влияния на получаемые от агента результаты, потому что качество работы даже самой способной модели зависит от предоставленных ей данных.

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

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

• Дайте агенту цель, а не только запрос. Составляйте задачи Jira, как если бы это были спецификации с критериями приемки, по которым будет оцениваться работа агента.

• Позвольте Teamwork Graph расширить контекст. Используя задачу в качестве отправной точки для выполнения запроса, этот инструмент дополняет ее документами, решениями и сопутствующим контекстом, связанным с задачей.

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

• Предоставляйте всем агентам одни и те же данные. Все агенты по написанию кода, такие как Claude Code, Cursor, Codex, GitHub Copilot, Jira Coding Agent и другие, должны опираться на один и тот же организационный контекст.

Что такое формирование контекста?

В ходе этого процесса вы определяете, какая информация будет доступна модели на каждом шаге, чтобы у агента по написанию кода было все необходимое для корректного выполнения задачи. Эта информация — больше, чем просто запрос. В нее входит база кода, ваши стандарты, зависимости, история Git, список инструментов, цели и критерии приемки. Составление и корректировка этого набора для каждой задачи — это новый, отдельный вид работы.

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

Важно отметить, что большой объем контекста — это не всегда хорошо.

• Есть важный контекст — это сведения, которые действительно помогают в выполнении текущей задачи.

• И есть не важный контекст — это устаревшая, нерелевантная или дублирующаяся информация, которую модель тем не менее усваивает.

Чем больше в контекстном окне нерелевантных маркеров, тем медленнее работает модель и тем менее точными становятся ее ответы, хотя модель используется та же самая. Такое ухудшение называется деградацией контекста. Это постепенное снижение качества вывода по мере того, как контекстное окно заполняется устаревшими, малоинформативными или противоречивыми маркерами. Так, успешное формирование контекста заключается не только в добавлении актуальной информации, но и в удалении устаревшей.

Почему контекстное окно представляет ограничение для агентов по написанию кода?

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

Когда сбор контекста оставляют на усмотрение агента, повторяются одни и те же ошибки:

• Агент сбивается с курса при выполнении многоэтапной задачи, потому что решение, принятое им на раннем этапе, вытесняется из контекстного окна по мере его заполнения новыми, менее значимыми маркерами.

• Система извлекает избыточные данные, загружает в окно гораздо больше информации, чем использует, и расходует лимиты маркеров на информационный шум.

• Агент упускает из виду стандарты, которые вы ему предоставили, и создает код, противоречащий шаблону, которому следуют все остальные участники команды.

• Агент отлично работает в одиночку, но не имеет представления о том, что делает в той же области остальная команда или другие агенты.

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

Как формировать контекст для агентов по написанию кода в Jira?

В Jira вы делаете контекстом сами задачи: намерение содержится в задаче, связанные с ней знания передаются через Teamwork Graph, а базовые стандарты и решения подтягиваются из Confluence и Loom, причем все агенты и все участники команды берут информацию из одного источника. Jira выходит за рамки локальных файлов на одном компьютере — к ним добавляются цели, текущие решения и обсуждения, а также история всех ваших задач. Эта информация доступна всей команде, поэтому контекст, которым пользуется агент, является структурированным, актуальным и единообразным для всех участников.

Есть три главных принципа формирования контекста:

1. Выбрать правильную информацию.

2. Сохранять ее структуру.

3. Обеспечить персистентность.

1. Выбор и извлечение: составьте задачу в виде спецификации

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

• Как это работает в Jira. В поле описания укажите цель, а критерии приемки добавьте в виде списка задач. Это даст агенту информацию о намерении и критериях оценки в удобном для него формате. Затем назначьте задачу подключенному агенту. В качестве отправной точки он будет использовать задачу и связанный с ней контекст, а не всю базу кода. Частью работы также будут дебаты с агентом для уточнения спецификации: так он может быстро считать большие объемы информации и помочь вам найти пробелы еще до начала выполнения задачи.

• Скоро. Планировщик Jira превращает идеи в планы и задачи, адаптированные для агентов, с уже прикрепленным контекстом. Присоединиться к списку ожидания.

2. Общий контекст: прикрепляйте ссылки на задачи, а не вставляйте их содержимое

В этой работе очень важны структура и формат: формируйте контекст так, чтобы агент мог в нем ориентироваться, и поддерживайте связи, вместо того чтобы копировать текст. А Teamwork Graph делает окружающий контекст доступным, избавляя вас от необходимости каждый раз собирать его вручную.

• Как это работает в Jira. Свяжите задачу с другими задачами, кодом и страницами Confluence, на которых хранятся спецификации, запросы комментариев и протоколы решений. Агент принимает во внимание контекст, связанный с задачей, а не только текст запроса. Видеоинструкция в Loom тоже подойдет: если у вас есть запись воспроизведения бага или обоснования дизайна, ее расшифровка и описание попадают в Teamwork Graph, поэтому объяснение, которое вы дали участнику команды, становится контекстом, доступным для агента. Это позволяет извлекать нужные факты из реальной работы, а не создавать отдельное векторное хранилище, которое нужно было бы еще и обслуживать.

3. Персистентность: сохраняйте стандарты и решения, которые приносят совокупный эффект

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

• Как это работает в Jira. Соглашения, архитектурные решения и предпочтительные шаблоны хранятся в общем разделе Confluence. Все участники команды и агенты получают данные из одного источника через Teamwork Graph, а не пользуются локальными копиями документов, которые не видит никто другой. По мере прохождения задач через систему информация в Teamwork Graph дополняется, и у следующего агента появляется больше данных для анализа. Контекст накапливается по мере выполнения задач. Разработчикам для этого не требуется выполнять никаких дополнительных действий вручную.

Эффективную работу этой структуры для всех участников команды обеспечивают два фактора: единый слой контекста, доступный каждому агенту, и правильное управление, которое делает его надежным и допустимым.

Один слой контекста для всех агентов

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

• Как это работает в Jira. В этой системе есть два способа предоставить всем агентам по написанию кода одинаковый организационный контекст. Интерфейс командной строки Teamwork Graph дает агентам по написанию кода прямой доступ к контексту и его инструментам через терминал. Настройте его один раз, и ваш агент сможет запрашивать данные из Teamwork Graph в процессе работы. Atlassian Rovo MCP Server выполняет ту же функцию для клиентов MCP, таких как Claude, Cursor, Codex и GitHub Copilot. Однако в любом случае все сводится к Teamwork Graph: это слой, объединяющий задачи, решения, документы и код и позволяющий обращаться к ним. Вы создаете контекст один раз и используете его с любой моделью, которая выполняет задачи.

Управление: следите за надежностью и допустимостью контекста

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

• Как это работает в Jira. Агенты получают те же права, что и ваша команда, поэтому агент видит только ту информацию, которая доступна пользователю, стоящему за ним. При этом можно ограничить область действия агентов с помощью специальных правил. Подробнее о том, как связаны доступ, подтверждение и аудит, в статье Защитные механизмы и средства обеспечения безопасности при использовании ИИ-агентов в Jira.

Как Jira сочетается с остальными инструментами в вашем контекстном стеке?

Сегодня большая часть контекста агента по написанию кода находится на одном компьютере: открытый репозиторий, несколько локальных файлов и все, что разработчик ввел в запрос. Это подходит для индивидуальной работы, но при этом информация разрознена, привязана к конкретным людям и со временем забывается. Jira и Teamwork Graph собирают важный контекст, объединяя его в общем слое — актуальном, управляемом и доступном для всей команды и ее агентов.

Все это не заменяет агентов для написания кода, IDE или локальную конфигурацию. Они по-прежнему отвечают за детализацию по каждому репозиторию и за сам код. Jira служит общим слоем над этими инструментами, поэтому контекст, с которым они работают, структурирован, актуален и одинаков для всей команды.

Как предоставить первому агенту реальный контекст в Jira

Построение контекста заключается в том, чтобы предоставить агенту инструменты и информацию, необходимые для самостоятельного поиска. Jira и Teamwork Graph — это общий контекстный слой, к которому агент подключается через MCP или CLI, поэтому основная задача заключается в том, чтобы поддерживать точность и целостность этого слоя.

Начните с одной правильно составленной задачи, чтобы увидеть разницу между агентом, который действует наугад, и агентом, которому поставлена четкая цель.

1. Задайте для агента планку, по которой его будут оценивать. Выберите одну ограниченную задачу с низким уровнем риска, которую легко отменить, например автономную рефакторизацию или исправление мелкого бага, и пропишите цель в описании, а критерии приемки — в контрольном списке.

2. Позвольте агенту получить контекст автоматически, вместо того чтобы вставлять его вручную. Свяжите задачу с ее кодом, указав ключ задачи в ветке, коммите или запросе pull, и прикрепите соответствующий документ или решение. Агент собирает связанный контекст по задаче, а не только текст заявки.

3. Укажите общий стандарт. Привяжите соглашение, которому нужно следовать, к странице Confluence, чтобы следующий агент и участник команды использовали тот же источник.

4. Назначьте задачу агенту. Агент начинает с задачи и ее связанного контекста — это более фиксированная отправная точка, чем вся база кода или пустой запрос.

5. Проверьте результат по критериям, которые были заложены в задаче. Сверьте запрос pull с критериями приемки, которые вы указали в задаче, чтобы итоговый результат оценивался по тем же критериям, которые вы задали агенту.

6. Поручите агенту завершить цикл. Попросите агента по завершении обновить задачу: добавить описание сеанса, ключевые решения и компромиссы, а также связанный запрос pull. Тогда следующий участник команды или агент сможет продолжить с того места, где он остановился, с помощью Teamwork Graph.

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

Часто задаваемые вопросы о построении контекста

В чем разница между построением контекста и разработкой запросов?

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

Как агенты ИИ для написания кода получают контекст из Jira?

Агенты получают контекст из задачи, ее описания и критериев приемки, а также из Teamwork Graph, который связывает соответствующие задачи, документы и код. Таким образом, агент действует на основе реальной цели, а не пустого запроса.

Почему агенты выдают неверный код даже при правильно составленном запросе?

Запрос редко содержит информацию о ваших соглашениях, архитектуре или обосновании задачи. Большинство сбоев в работе агента связано с контекстом, а не с моделью, поэтому лучше добавить контекст, чем поменять формулировку.

Нужен ли контекст, если у агента есть доступ к моему репозиторию?

Да. Репозиторий передает агенту данные о коде без объяснений, почему он был создан именно так, каким стандартам нужно следовать и что еще происходит в команде. Остальная информация предоставляется при построении контекста.

Деградация контекста

Деградация контекста — это постепенное ухудшение вывода агента по мере того, как его контекстное окно заполняется устаревшими, нерелевантными или противоречивыми маркерами. Ответы становятся менее быстрыми и точными, хотя модель не изменилась.