Контекст агента как инженерный артефакт

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

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

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

Что такое контекст в рабочем смысле

В операционном смысле контекст — это не «всё, что важно», а только то, что влияет на решение в данной задаче. Полезный контекст отвечает минимум на пять вопросов:

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

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

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

Для агента действует тот же принцип. Контекст должен позволять:

1. понять границы задачи;
2. не трогать лишнее;
3. выбрать правильный порядок действий;
4. отчитаться в тех же терминах, в которых задача была поставлена.

Из чего должен состоять контекстный пакет

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

Самая частая ошибка — давать цель без границ. Например: «проверь договор» или «подготовь аналитическую записку». Для человека ещё можно уточнить устно, а агент без границ начнёт либо слишком широко, либо слишком узко. В первом случае он растянет объём, во втором — упустит существенные элементы.

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

Как собирать контекст, чтобы агент не гадал

Контекст нужно писать не как повествование, а как рабочую инструкцию. Для этого полезен простой порядок.

1. Сначала цель в одном предложении.
Не «проанализировать ситуацию», а «выявить расхождения между текущей процедурой и требованиями из документа X». Не «улучшить текст», а «сократить текст до версии для согласования с юридическим отделом».

2. Затем границы.
Что именно агент должен затрагивать, а что — нет. Например: «не менять терминологию без указания», «не предлагать новые процессы», «не использовать внешние источники», «работать только с приложенными данными».

3. Потом входы.
Список материалов, их роль и приоритет. Если есть несколько версий, это нужно явно обозначить: «источник истины — документ A, документ B только для контекста». Иначе агент начнёт компилировать противоречия.

4. Далее критерий результата.
Не «сделать хорошо», а «сформировать список из 5 рисков с указанием причины и влияния», «подготовить таблицу соответствий», «выдать план изменений в 3 шага».

5. В конце — правила при неопределённости.
Это критично. Если данных не хватает, агент должен понимать, что делать: задавать вопрос, остановиться и обозначить пробел, принять временное допущение или предложить два сценария с пометкой о риске.

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

Что нельзя оставлять в контексте размытым

Есть несколько областей, где расплывчатость почти всегда приводит к сбою.

Неясный приоритет.
Если в пакете одновременно есть «срочно», «аккуратно» и «не более одной страницы», агент не поймёт, что важнее. Приоритеты надо ранжировать: сначала точность, потом скорость, потом компактность — или наоборот, если это действительно так.

Неопределённый адресат результата.
Текст для руководителя, для инженера и для клиента — это три разных артефакта, даже если исходная тема одна. Если адресат не указан, агент выберет усреднённый тон, который обычно не подходит никому.

Смешение фактов и предположений.
Если в контексте не отделить подтверждённое от предполагаемого, агент будет считать всё равнозначным. Полезно помечать: «факт», «гипотеза», «вероятно», «нужно проверить».

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

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

Как выглядит хороший контекст на практике

Ниже — не шаблон ради шаблона, а минимально рабочая форма. Её можно адаптировать под любые внутренние задачи.

Пример структуры:

• Цель: подготовить краткий план исправления процесса согласования документов.
• Источник истины: регламент версии 4.2 и список замечаний из последнего аудита.
• Границы: не менять сам регламент, не предлагать новые роли, не использовать внешние практики.
• Результат: 1) проблемные места, 2) предлагаемое действие, 3) ожидаемый эффект, 4) риск при откладывании.
• Формат: таблица и затем 5 коротких выводов.
• Если данных не хватает: отметить пробел и не заполнять его догадкой.

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

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

Рабочая процедура: как внедрять контекст в командный процесс

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

1. Формулировщик задачи пишет цель и границы.
2. Сборщик контекста прикладывает только релевантные источники.
3. Владелец процесса проверяет, есть ли критерий готовности.
4. Агент выполняет задачу и отдельно помечает допущения.
5. Проверяющий сравнивает результат не с ожиданием «в целом», а с заданным критерием.

Такой цикл дисциплинирует не только модель, но и людей. Обычно именно на человеческой стороне возникают сбои: задачу формулируют широко, материалы кладут без статуса, а потом удивляются, почему агент «не угадал».

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

Короткий рабочий чек-лист

Перед отправкой задачи агенту проверьте:

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

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

Вывод: контекст — это не текст вокруг задачи, а её инженерная форма

Полезный агент работает не потому, что «понял смысл», а потому, что получил достаточный контекст для выполнения. Чем точнее собран контекстный пакет, тем меньше у модели пространства для догадок и тем устойчивее процесс.

В практической работе это означает простую вещь: не пытаться «объяснить задачу красиво», а оформить её как артефакт передачи. Цель, границы, входы, ограничения, критерий готовности, правила при неопределённости — этого обычно достаточно, чтобы агент перестал ломать процесс и начал работать по делу.

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