TL;DR
Исследование показывает, что успех агента зависит не только от модели, но и от интерфейса, через который он работает с программой. Авторы взяли разные релизы одних и тех же приложений (QGIS, Blender, Inkscape, FreeCAD, Writer, Impress) и дали агенту одинаковые задачи. Новые версии стабильно побеждали старые: в QGIS успех вырос с 33% до 65%. Затем авторы собрали ANIS, генератор интерфейса из атомарных команд (маленьких операций с единым описанием) и целевых команд (готовых цепочек под типовую цель).
Главная находка: агент ломается на трёх вещах. Первое: он не может быстро найти, что программа умеет, и тратит на поиск от четверти до трети входных токенов. Второе: ему приходится собирать цель из десятков мелких вызовов, и каждый вызов — ещё одна точка отказа. В одном примере агент 33 хода и 662 тысячи токенов пытался собрать карту из низкоуровневых вызовов и провалился. С готовой операцией «разбей на интервалы» он справился за 11 ходов и 36 тысяч токенов. Третье: агент не может проверить результат. В 581 запуске он доложил «готово», а файл не прошёл проверку. Причина в том, что у многих операций «записать» нет парной операции «прочитать».
Суть метода: ANIS один раз превращает возможности программы в атомарные команды с одинаковым описанием, сгруппированные по объектам. К каждой записи он добавляет команду чтения. Потом повторяющиеся цепочки команд упаковываются в целевые команды. Команда выпускается, только если её повтор на чистом файле даёт то же сохранённое состояние. Для вас практический вынос — три принципа для описаний инструментов и правил агенту: находимость, крупные операции под цель, обязательное чтение результата.
Схема метода
СБОРКА ИНТЕРФЕЙСА (один раз, код):
ШАГ 1: Найти в запущенном приложении все операции и свойства → широкий список-кандидат (с запасом)
ШАГ 2: Оставить только те, чей эффект можно проверить → допущенные возможности
ШАГ 3: Превратить каждую в атомарную команду → единое описание + реализация + наблюдаемый эффект
• сгруппировать по объектам (документ, слайд, слой…)
• сначала короткая сводка, полное описание — по запросу
• к каждому записываемому свойству — команда чтения
РАБОТА (по ходу использования):
ШАГ 4: Заметить повторяющиеся цепочки атомарных команд → кандидат в целевую команду
ШАГ 5: Проверить: повтор цепочки на свежем файле даёт то же сохранённое состояние? → да: выпустить команду
Это не один промпт. Метод реализуется кодом. Сами три свойства (находимость, укрупнение, читаемость результата) переносятся в инструкции агенту.
Пример применения
Задача: Вы продакт в e-commerce на Wildberries и Ozon. Агент в Claude Code каждое утро собирает отчёт по карточкам товаров через API кабинета. Агент работает через сырой API: десятки мелких методов, сам разбирается, какие вызывать. Он то зацикливается на поиске нужного метода, то пишет «обновил цены на 40 карточек», а в кабинете обновились 28. Нужно поправить это через AGENTS.md.
Промпт (фрагмент файла инструкций агента):
## Правила работы с API кабинета маркетплейса
### 1. Находимость
- Перед первым действием прочитай файл tools/INDEX.md: там список команд, сгруппированных по объектам (карточка, цена, остаток, отзыв), по одной строке на команду.
- Полное описание команды открывай только когда выбрал её.
- Не угадывай названия методов. Нет подходящей команды в индексе — остановись и спроси меня.
### 2. Укрупнение
- Если в tools/GOALS.md есть команда под мою цель (например, "обновить цены по списку"), используй её вместо ручной цепочки из мелких вызовов.
- Если одна и та же цепочка из 3+ вызовов повторилась дважды, предложи мне оформить её как новую команду в GOALS.md. Не добавляй её сам.
### 3. Читаемость результата
- После каждого изменения (цена, остаток, описание) вызови парную команду чтения и сравни фактическое значение с ожидаемым.
- Если парной команды чтения нет, прямо напиши: "Результат проверить не могу: нет команды чтения для X".
- В отчёте разделяй: "Выполнено и проверено чтением", "Выполнено, не проверено", "Не выполнено".
- Слово "готово" допустимо только для первого пункта.
Результат: Агент перестанет перебирать методы наугад и будет открывать описание только выбранной команды. На типовые цели он станет использовать готовые составные команды. В отчёте появятся три раздела, и непроверенные изменения не будут выдаваться за выполненные. Если для какой-то операции нет чтения, агент так и скажет, и вы увидите дыру в инструментах.
Почему это работает
Слабость LLM: агент не видит программу глазами и не знает, что она умеет, пока не спросит или не попробует. Каждая попытка стоит ходов и токенов. Длинная цепочка мелких вызовов умножает риск ошибки: промах в одном параметре ломает всё, а размытое описание мешает ошибку заметить и починить. Кроме того, модель склонна считать работу сделанной, если вызов не вернул ошибку, хотя результат может быть неверным.
Сильная сторона LLM: модель хорошо выбирает из короткого списка с понятными описаниями и хорошо следует чёткому порядку действий. Если предложить ей одну операцию под цель вместо цепочки из тридцати, она применит её правильно. Если требовать чтение после записи, она сверит значение с ожидаемым.
Как метод это использует: три свойства снимают три источника ошибок. Находимость сокращает поиск: сводка сначала, детали потом. Укрупнение сокращает цепочку, а значит и число мест, где можно ошибиться. Читаемость результата заменяет «мне кажется, получилось» сверкой фактического состояния.
Рычаги управления: - Порог укрупнения («3+ вызова, повтор дважды») → снизь, чтобы чаще получать готовые команды. Подними, чтобы не плодить лишнее. - Строгость слова «готово» → оставь жёсткое разделение «проверено / не проверено» для денег и данных. Для черновых задач ослабь. - Допуск новой команды → в оригинале команда выпускается только после воспроизведения на чистом файле. Вы можете требовать такой прогон вручную или в отдельном тестовом запуске. - Размер индекса → одна строка на команду. Чем длиннее строки, тем больше токенов уходит на старте.
Шаблон промпта
В статье нет готовых промптов. Это шаблон, собранный из трёх свойств, которые авторы вывели из результатов. Он не воспроизводит ANIS (это код). Он переносит его принципы в инструкцию агенту.
## Правила работы с инструментом {название_инструмента}
### 1. Находимость
- Начни с файла {путь_к_индексу}: список команд по объектам, по одной строке на команду.
- Полное описание открывай только у выбранной команды.
- Не угадывай команды. Если нужной нет — остановись и спроси.
### 2. Укрупнение
- Для цели из {файл_готовых_команд} используй готовую команду, а не цепочку мелких.
- Если цепочка из {N}+ вызовов повторилась {M} раза, предложи оформить её как команду. Сам не добавляй.
### 3. Читаемость результата
- После каждого изменения вызови команду чтения и сравни факт с ожидаемым.
- Нет команды чтения — напиши: "Проверить не могу: нет чтения для {объект}".
- В итоге раздели: "Выполнено и проверено" / "Выполнено, не проверено" / "Не выполнено".
- "Готово" — только для первого раздела.
### Контекст задачи
{описание_задачи}
Что подставлять: {название_инструмента} — API, CRM, программа или скрипты. {путь_к_индексу} — файл со списком команд. {файл_готовых_команд} — ваши заготовки под типовые цели. {N} и {M} — пороги укрупнения, например 3 и 2.
🚀 Быстрый старт — вставь в чат:
Вот шаблон правил для агента, работающего с инструментом. Адаптируй под мою задачу: [твоя задача и инструмент].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, с каким инструментом ты работаешь, какие у него есть операции записи и чтения, какие цели повторяются чаще всего, что считается «проверенным». Это нужно, чтобы подобрать парные команды «записать / прочитать» и выделить цепочки, которые стоит укрупнить. Затем она возьмёт паттерн из шаблона и соберёт правила под твой инструмент.
Ограничения
⚠️ Основной метод требует кода: ANIS генерирует интерфейс программно, читатель без разработки его не воспроизведёт. Из статьи в чате или
AGENTS.mdпереносятся принципы, а не сама система.
⚠️ Перенос на инструкции не проверялся: авторы не тестировали, повышает ли успех правило «читай результат после записи» в промпте. Это экстраполяция принципов, а не измеренный приём.
⚠️ Эффект атомарного интерфейса скромный: по сравнению с прямым использованием SDK прирост составил около 3–4 процентных пункта. Основная экономия — токены. Главное улучшение дают целевые команды, но и оно умеренное.
⚠️ Проверка чтением не гарантирует результат: почти у трёх четвертей «ложных готово» агент всё же что-то проверял, но артефакт не прошёл верификацию. Чтение состояния помогает, но не заменяет внешнюю проверку.
⚠️ Узкий домен проверки: задачи шли на десктопных приложениях через программный интерфейс. Облачные сервисы, веб и чисто текстовые задачи не тестировались.
⚠️ Документация не спасает: по ссылке авторов на приложение, просто приложить документацию не помогает. Для агента важна структура и находимость, а не объём текста.
⚠️ Модели небольшие: тестировали Claude Haiku 4.5 и DeepSeek V4 Flash. Как ведут себя крупные модели, статья не показывает.
Как исследовали
Идея была простой: эволюция программ — готовый естественный эксперимент. Из версии в версию функции приложения остаются теми же, а интерфейс меняется под давлением реальных пользователей. Если зафиксировать агента, задачи и проверку, а менять только релиз, можно приписать разницу в результатах изменениям интерфейса. Так появился DeskIF-Bench: 255 задач на шести приложениях из пяти областей (офис, 2D, 3D, ГИС, САПР). Затем его расширили до 368 задач на восьми приложениях. Задачи проверялись скриптами по сохранённому файлу, не LLM-судьёй: проверки детерминированы и воспроизводимы. Часть задач взяли из OSWorld и OpenComputer, остальные синтезировал агент-автор, у которого были «привилегии»: навыки и библиотеки, недоступные решающему агенту. Так задачи оказались сложнее самого решателя.
Результат: новейший релиз выиграл у старейшего во всех 12 парах «модель × приложение», но разброс большой: до ~30 пунктов в QGIS, ~19 в Impress. Разбор траекторий показал причины: сравнение версий выявило находимость и укрупнение, а в аудите ошибок обнаружилась читаемость результата. Эту проблему ни одна версия не решила: операции записи без парного чтения остались во всех релизах. Агенты тратили 24–36% входных токенов на поиск возможностей. Затем на расширенном бенчмарке атомарный интерфейс ANIS дал 72,3% против 68,5% у прямого SDK и 17,4% у CLI-Anything. Целевые команды подняли результат до 74,5% и 67,4% для двух моделей.
Удивило, что «готовый для людей» интерфейс сам по себе помогает агенту: ПО улучшается и для ИИ, хотя его так не проектировали. Для практики вытекает: когда агент буксует, смотри не на модель, а на то, что ему дали в руки.
Адаптации и экстраполяции
🔧 Техника: добавить «аудит дыр» → увидеть, где агент слеп
Попроси агента не выполнять задачу, а пройтись по инструментам и составить таблицу:
Не выполняй задачу. Пройдись по доступным инструментам и составь таблицу:
операция записи | есть ли парная операция чтения | как проверить результат без неё.
В конце перечисли 3 самые опасные "слепые" операции.
Это превращает принцип «читаемость результата» в диагностику. Ты увидишь, какие действия агент выполняет без возможности проверки, и решишь, где ему нужен внешний контроль или ручная проверка. Идея основана на наблюдении авторов о записях без чтения. Сам приём в статье не проверялся.
Экстраполяция: отчёт-расписка в конце работы агента
Закончив работу, выдай расписку по каждому изменению:
- что менял
- ожидаемое значение
- фактическое значение после чтения
- вердикт: совпало / не совпало / не проверено
Если хоть одно "не совпало" или "не проверено" — не пиши "готово".
Это переносит идею «наблюдаемого эффекта» в формат отчёта, который можно быстро просмотреть глазами.
Ресурсы
- A Decade in a Day: Synthesizing Agent-Native Interfaces from Human-Oriented Software Evolution — Alan Wu (Independent Researcher; работа выполнена во время стажировки в LIGHTSPEED), Wei Tao (LIGHTSPEED), Yiwen Guo (Independent Researcher), 2026.
- Код: github.com/co-evolve-lab/ANIS
- Данные: huggingface.co/datasets/SimAlan/DeskIF-Bench
- Связанные работы из статьи: OSWorld, Windows Agent Arena, OpenCode, Model Context Protocol (MCP), CLI-Anything.