Автор эссе: «очеловечивание» ответов ИИ-агентов, ошибка проектирования

Автор эссе замечает набирающий популярность тренд: в файлы инструкций для ИИ-агентов (вроде AGENTS.md) добавляют «скиллы» вида «пиши так, будто у меня СДВГ» или требуют ответов на упрощённом техническом английском стандарта ASD-STE100. Идея понятна, многим не нравится многословность и специфические обороты вывода языковых моделей. Но автор считает такое решение неверным по уровню применения.

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

ASD-STE100, показательный пример, потому что звучит разумно: стандарт создавался, чтобы сделать документацию однозначной для людей. Но агент, не человек-технический писатель, и необработанное, «сырое» состояние часто оказывается самым информационно плотным представлением из всех доступных.

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

Главный тезис, очеловечивание скрывает сбои. Агенты ошибаются по-своему полезно и некрасиво: противоречивые данные, незакрытые ветки рассуждений, трассировки стека, неуверенные допущения. Человеческая проза отлично умеет сглаживать всё это до нейтральных фраз вроде «здесь есть несколько моментов, которые стоит учесть». Звучит приятнее, но автор предпочёл бы узнать, что его агент галлюцинирует или упирается в лимит контекстного окна, чем получить успокаивающий, но пустой ответ.

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

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

По мысли автора, фраза «говори со мной, как будто у меня СДВГ» отлично работает как настройка отображения (рендерера), но плохо годится как рабочая инструкция для самого агента. Устойчивый вариант архитектуры, агенты, чей «родной язык», точное, машиночитаемое состояние, а тёплая и краткая версия для человека генерируется только на границе взаимодействия. В этом смысле вирусные «человечные» инструкции и скиллы, не конечная точка развития, а, по сути, баг-репорт: сигнал о нерешённой задаче на более низком уровне стека.

Ключевые факты

Тренд: в инструкции для ИИ-агентов (AGENTS.md и подобные) добавляют требования писать «как для человека с СДВГ» или упрощённым техническим английским ASD-STE100.
Автор считает это ошибкой уровня: стилевые правила смешиваются с самой задачей, и агент вынужден непрерывно сжимать вывод с потерей информации, которую читатель не замечает.
На примере цепочки субагентов: вместо сглаженной сводки («большинство тестов прошло») автор хочет видеть сырые результаты всех тестов, очеловечивание скрывает именно те сбои (противоречия, трассировки стека, неуверенные допущения), которые важно увидеть.
Параллель с базами данных, компиляторами и API: везде максимально точное представление хранится как можно дольше и переводится в удобный вид только на границе с человеком; ИИ-инструменты, по мнению автора, часто делают наоборот.
Предложение автора: агенты и субагенты обмениваются между собой точным, машиночитаемым состоянием (схемы, диффы, ошибки, уверенность), а «человечный» и сжатый вывод генерируется только в самом конце, для пользователя.

Почему это важно

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

Кому это важно

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

Как это применить

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

Можно ли доверять

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

Риски и подводные камни

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

«Вирусные репозитории, это не конечная точка развития, а, по сути, баг-репорт.»

— автор эссе