TL;DR
Reply Requirements — это короткое сообщение, которое вы добавляете в момент, когда агент пишет финальный ответ. Оно не просит «писать понятнее». Оно перечисляет, что в ответе должно быть: ответ на ваш последний вопрос первым, что сделано, результат, следующий шаг, где проверить, определение каждого названия, которого вы не видели. Второй вариант: отдать черновик другой модели в новом чате. Она переписывает ответ по тем же требованиям, видя только то, что видели вы.
Главная находка: больше половины ответов агентов вы просто не сможете прочитать. Агент пишет «результат по crn_hierbm25_L, см. R07, ключ reader_size: 70B». Вы этих названий не видели. Он придумал их сам по ходу работы или взял из своих заметок и файлов памяти. Задача выполнена и факты верны, но ответ непригоден. Чем дольше агент работал с инструментами, тем хуже ответ. Просто сообщить модели «пользователь не видел твоей работы» почти не помогает. Помогает конкретный список того, что должно быть в тексте.
Метод в два варианта. Вариант 1: перед финальным ответом добавить сообщение с шестью пунктами требований. Вариант 2: дать готовый ответ и журнал работы второй модели с теми же требованиями, и она перепишет. Второй вариант в исследовании дал лучший результат.
Схема метода
ВАРИАНТ 1 (один чат, дёшево):
Агент закончил работу → вы добавляете сообщение с требованиями
→ агент пишет ответ по 6 пунктам
ВАРИАНТ 2 (два прохода, сильнее):
ШАГ 1: Агент пишет ответ как обычно → черновик
ШАГ 2: Новый чат: вашa переписка + журнал работы + черновик + требования
→ переписанный ответ
ШАГ 3: Сверка с журналом: ничего ли не потеряно и не придумано
6 пунктов требований: ответ на последнее сообщение → что сделано → результат → следующий шаг → где проверить → определения всех незнакомых названий.
Пример применения
Задача: Владелец магазина на Ozon просит Claude Code разобрать выгрузку заказов за квартал: почему просела конверсия в карточках электроники. Агент час ходил по файлам, запускал скрипты и вёл заметки. Вернулся с текстом вроде «по сегменту seg_B2 эффект в варианте v3_cut, см. таблицу из run_14». Что такое seg_B2, v3_cut и run_14, вы не знаете. Вы добавляете сообщение-требования.
Промпт (отправляется после того, как агент закончил работу, перед его финальным ответом):
Напиши итоговый ответ мне. Учти: я видел только свои сообщения и твои
прошлые ответы. Твоих файлов, заметок, вывода скриптов и названий,
которые ты придумал по ходу работы, я не видел.
В ответе должно быть, в таком порядке:
1. Прямой ответ на мой последний вопрос: почему просела конверсия
в карточках электроники.
2. Что ты сделал (2–4 пункта, без внутренних названий).
3. Результат: главные цифры и вывод.
4. Следующий шаг: что я должен решить или сделать.
5. Где проверить: в каком файле, листе или отчёте лежат подтверждающие
данные. Укажи путь и что искать.
6. Определение каждого названия, ярлыка, номера или сокращения,
которое я не видел. Лучше замени его описанием словами.
Пиши на русском.
Результат: Агент начнёт с прямого ответа на вопрос, а не с хода работы. Вместо «seg_B2» будет описание вроде «покупатели, пришедшие с рекламы». Внутренние идентификаторы либо заменены словами, либо расшифрованы. В конце будет указано, где лежат данные для проверки. В исследовании такой приём снижал долю непригодных ответов примерно с 52% до 43%, а ошибок и пропусков в ответах становилось меньше.
Почему это работает
Слабость модели. Агент пишет ответ внутри своего рабочего контекста. Там лежат его заметки, названия запусков, номера источников, выводы скриптов. Для него всё это «общеизвестное». Модель не отличает «я это знаю» от «пользователь это знает». Поэтому она продолжает говорить на своём рабочем языке. Больше половины придуманных ярлыков агент записал в свои файлы и память ещё до ответа. Каждая новая сессия подтягивает старые ярлыки заново.
Сильная сторона модели. Она хорошо выполняет конкретный список пунктов. Пункт «определи каждое название, которое я не видел» — это проверяемое действие: пройти по тексту и расшифровать. Совет «учитывай читателя» такого действия не задаёт. Поэтому уведомление «пользователь видел только свои сообщения» дало почти нулевой эффект, а то же уведомление плюс шесть пунктов дало заметный.
Как метод использует это. Требования стоят в конце, прямо перед ответом, и каждый пункт закрывает конкретный тип провала. «Ответ на последний вопрос первым» лечит ответы мимо запроса. «Определения» лечат придуманные ярлыки и непонятные термины. «Где проверить» заменяет ссылку «см. R07» на путь, который вы откроете сами. Второй проход в новом чате работает ещё лучше: переписчик не тащит рабочий жаргон, потому что видит только то, что видели вы.
Рычаги управления: - Список пунктов → добавьте свои под задачу («риски», «что осталось неизвестным»). Убирайте лишнее, если ответ должен быть коротким. - Место сообщения → ставьте его в конец, прямо перед ответом. В статье рабочим было именно сообщение в точке ответа. - Второй проход → включайте для длинных задач с большим числом вызовов инструментов, там провалов больше всего. - Журнал работы → всегда давайте переписчику, иначе он может придумать детали. Потом сверяйте текст с журналом.
Шаблон промпта
Вариант 1. Сообщение-требования (в тот же чат/сессию агента, перед финальным ответом):
Напиши итоговый ответ мне. Учти: я видел только свои сообщения
и твои прошлые ответы. Твоих файлов, заметок, памяти проекта, вывода
инструментов и названий, которые ты ввёл сам во время работы, я не видел.
В ответе должно быть, в таком порядке:
1. Прямой ответ на моё последнее сообщение: {мой_последний_вопрос}.
2. Что ты сделал.
3. Результат.
4. Следующий шаг.
5. Где проверить: путь к файлу, лист, раздел или команда, где лежат
подтверждающие данные.
6. Определение каждого названия, ярлыка, идентификатора или сокращения,
которого я не видел. Лучше замени его описанием словами.
Пиши на {язык}.
Вариант 2. Переписчик (новый чат, вторая модель или та же):
Ты переписываешь итоговый ответ агента для заказчика.
Заказчик видел только:
<переписка>
{мои_сообщения_и_прошлые_ответы_агента}
Заказчик НЕ видел журнал работы агента:
<журнал_работы>
{вызовы_инструментов_выводы_заметки_файлы}
Черновик ответа агента:
<черновик>
{черновик_ответа}
Перепиши ответ так, чтобы заказчик понял его из переписки и самого
текста. В ответе должно быть, в таком порядке:
1. Прямой ответ на последнее сообщение заказчика.
2. Что было сделано.
3. Результат.
4. Следующий шаг.
5. Где проверить подтверждающие данные.
6. Определение каждого названия, номера или сокращения, которых заказчик
не видел. Или замени их описанием.
Правила: не добавляй фактов, которых нет в журнале. Не теряй ключевые
результаты из журнала. Язык ответа: {язык}.
Что подставлять: {мой_последний_вопрос} — ваша последняя реплика. {язык} — язык, на котором вы читаете. В варианте 2 подставляйте переписку, журнал (выгрузку шагов агента или его заметки) и черновик.
🚀 Быстрый старт — вставь в чат:
Вот шаблон требований к ответу агента. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, что вы просили агента сделать, на каком языке читаете и что вам нужно проверять в результате. Эти данные нужны, чтобы шесть пунктов совпали с вашими реальными провалами. Она возьмёт структуру из шаблона и подгонит под вашу задачу.
Ограничения
⚠️ Эффект умеренный: Требования снижают долю непригодных ответов с 0.52 до 0.43. Это лучше, но около сорока процентов ответов всё ещё остаются непонятными. Метод не решает проблему полностью.
⚠️ «Предупреждение о читателе» не работает: Если в системном промпте написать «пользователь не видит твою работу», ответы почти не меняются. Нужен конкретный список содержимого, и он должен стоять в момент ответа.
⚠️ Переписывание может исказить факты: Исследователи сверяли каждый переписанный ответ с журналом работы. Переписчик без журнала рискует потерять результаты или добавить лишнее. Переписывать нужно с журналом и потом сверять.
⚠️ Нужна доступность журнала: Второй проход требует вытащить из агента лог работы или заметки. В чате без инструментов это просто, в готовом агенте приходится копировать вручную.
⚠️ Лабораторные условия: Заказчика играл скрипт с короткими директивами. Читателя заменяла модель-ридер, проверенная на людях с согласием на уровне отдельного аннотатора. Реальный заказчик с другим контекстом может видеть провалы иначе.
⚠️ Неполные детали: В доступном тексте нет дословных промптов приложения, поэтому шаблоны собраны по описанию статьи.
Как исследовали
Идея была простой: агент отчитывается человеку, который не видел его работу, и тот должен понять отчёт. Исследователи взяли 8 моделей из 7 семейств. Каждая прошла четыре проекта: два исследовательских и два бизнесовых, например изменение цены подписки и редизайн онбординга. Получилось 32 длинных сессии и 480 ответов. Заказчика играл сценарий: 15 коротких сообщений в трёх сессиях, между сессиями агент сохранял заметки в «память проекта».
Читать ответы поручили модели-ридеру. Она встаёт на место заказчика, задаёт вопросы к непонятным местам и ищет ответы в тексте ответа и в видимой переписке. Нет ответа — значит информационная дыра. Ридера проверили на 300 ответах: пять людей разметили их независимо, и согласие ридера с большинством (κ = 0,60) оказалось на уровне согласия самих людей (0,63).
Результат: 54% ответов непригодны, лучшая модель ошибается в 30%, худшая в 82%. Удивило, что худший результат у Claude Opus 5, а лучший у GPT-5.6 Sol: у GPT вообще не нашлось придуманных ярлыков. После трёх и более ходов с инструментами провалов 70%, а без вызовов 48%. Более 53% придуманных ярлыков агент записал в свои файлы или в память ещё до ответа. Отсюда вывод: ответ говорит на рабочем языке агента, потому что этот язык уже лежит в его контексте.
Затем на 256 точках ответа сравнили шесть способов написать ответ заново. Простое «пользователь видел только свои сообщения» дало 0.50 против 0.52 (разница в пределах шума). Сообщение с требованиями дало 0.43, а новый чат с требованиями 0.42. Новый чат без требований дал лишь 0.47. Вторая модель, переписывающая ответ по требованиям, снизила долю до 0.36, и слепое сравнение людей это подтвердило. Практический вывод: важны конкретные пункты требований, а не отдельный проход как таковой.
Оригинал из исследования
Полные промпты вынесены в приложение (в доступном тексте их нет). Описание требований из основного текста:
The requirements condition appends a message at the point of the reply
that repeats this statement and specifies what the reply must contain:
an answer to the latest message first, what was done, the result,
the next step, where the evidence can be checked, and a definition
of every name the user has not seen.
Notice condition: adds to the system prompt a statement that the user
has seen only their own messages and the agent's earlier replies.
Контекст: Так исследователи сформулировали две инструкции. Работала вторая («requirements» в конце), а первая («notice» в системном промпте) не дала значимого эффекта.
Адаптации и экстраполяции
💡 Адаптация для CLAUDE.md / AGENTS.md: вынесите шесть пунктов в постоянную инструкцию агенту. Связь с выводом статьи косвенная: в исследовании требования добавляли в точке ответа, не в файле инструкций, поэтому проверьте, что агент выполняет их и в конце длинных задач.
## Финальный ответ пользователю
Пользователь не видит твои файлы, заметки, вывод инструментов
и названия, которые ты придумал сам. Каждый финальный ответ содержит
по порядку: прямой ответ на последний вопрос; что сделано; результат;
следующий шаг; где проверить (путь к файлу или команда); определение
каждого названия, которого пользователь не видел.
Не используй внутренние идентификаторы (run_14, R07, seg_B2) без расшифровки.
🔧 Техника: переименование ярлыков при записи → меньше жаргона в памяти. Из данных статьи следует, что часть ярлыков приходит из файлов и памяти. Можно добавить в инструкцию: «Когда записываешь заметки в файл, рядом с каждым ярлыком пиши расшифровку обычными словами». Это моя экстраполяция, статья такого вмешательства не проверяла.
Ресурсы
Название работы: Measuring and Reducing Unusable Replies of LLM Agents Авторы: Yilin Jiang, Fei Tan, Xuanyu Yin, Guanchu Wang, Xia Hu, Yutao Yue Организации: East China Normal University; The Hong Kong University of Science and Technology (Guangzhou); Shanghai Artificial Intelligence Laboratory; Institute of Deep Perception Technology, JITRI Связанные идеи из статьи: декontextуализация (Choi et al., 2021; Newman et al., 2023), общая основа понимания в диалоге (Clark & Brennan, 1991; Shaikh et al., 2024).