Работа: Can Agents Design Libraries for Agents?
Авторы: Gabriel Orlanski, Alex L. Zhang, Avi Trost, Vincent Sunn Chen, Frederic Sala, Aws Albarghouthi, Ludwig Schmidt
Ссылки: arXiv · HTML · PDF · Код бенчмарка · Задания

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

Как то так работают кодинг-агенты

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

Основные моменты из статьи

1. Могут ли агенты проектировать хорошие и переиспользуемые агентами библиотеки? - Могут. Лучший в рамках тестирования проектировщик Claude Opus 5.5 обошел на 4.9% в бенчмарке устоявшиеся библиотеки, написанные людьми (48.9 баллов против 46.6). При этом в 11 из 15 задач агенты самостоятельно воспроизвели архитектурные решения людей (например, повторив паттерн Строитель из библиотеки Rust - clap). Но есть и нюансы - в Haskell в 70% случаев библиотеки, созданные агентами, сделали код только хуже, чем вовсе без библиотеки.

2. Какие трудности испытывают агенты при работе с библиотеками, написанными другими агентами? - Аудит показал что в 64% случаев избыточный код, написанный агентами-исполнителями, не использовал возможности библиотеки потому, что интерфейсы библиотеки были жесткими или неудобными в использовании и лишь 14% случаев - реальное отсутствие нужной функциональности. Отдельно стоит сказать что 41% строк самописного агентом-исполнителем кода - полное дублирование того, что в библиотеке уже было. Выяснилось, что LLM ищут методы через grep команды по названиям, которые получают в рамках своего претрейна: если метод назван необычно, его не находят.

3. Как можно заставить агентов-исполнителей использовать библиотеку? - Прежде всего это директивный промпт ("Используй только библиотеку. Пиши тонкий адаптер"). Он увеличивает лаконичность кода на 23%. И следом - увеличение усилий рассуждений (reasoning effort). Это повышает корректность прохождения тестов на 63% (модель начинает внимательнее вычитывать больше файлов).

4. Работает ли проектирование в стиле "agent-first"? - Да, с умеренной полезностью. Авторы тестировали отдельный подход: проектировщика обязывали сначала набросать эскизы вызовов кода, приложить запускаемые примеры и протестировать библиотеку через субагентов. Как итог Astra от OpenAI подняла результат с 44.1 до 46.4 баллов, приблизившись к человеческим библиотекам.

Таблица 1. Общие результаты по конфигурациям библиотек и моделям-проектировщикам

Все результаты усреднены по одному и тому же набору исполнителей. Проектировщики работают в среде mini-SWE-agent, если в скобках не указан иной агентный каркас (CC — Claude Code). «Промышленная библиотека» и «Без библиотеки» — контрольные условия, в которых исполнителю предоставляется готовая библиотека человека либо не предоставляется никакой библиотеки вовсе.

• Стоимость библиотеки (\$) — средние затраты (USD) на генерацию одной библиотеки.
• Стоимость задачи (\$) — средние затраты исполнителя на решение одной тестовой проблемы.
• % тестов — средняя доля пройденных тестов (а не процент полностью решенных задач).
• Для Итогового балла указаны 95%-ные доверительные интервалы; для остальных метрик — кластеризованные стандартные ошибки. Полужирным выделен лучший результат в столбце.

Модель проектировщика (Среда)	Итоговый балл ( ↑ )	% тестов ( ↑ )	Простота ( ↑ )	Стоимость библ. ($) ( ↓ )	Стоимость задачи ($) ( ↓ )
Opus 5.5	48.9 [48.0, 49.9]	86.6 ± 1.4	64.5 ± 1.8	$9.62 ± 1.03	$0.174 ± 0.011
Fable 5.1	47.5 [46.4, 48.5]	86.1 ± 1.6	62.7 ± 1.8	$14.81 ± 1.37	$0.198 ± 0.013
Промышленная библиотека (человек)	46.6 [46.1, 47.2]	85.4 ± 1.0	61.5 ± 0.9	—	$0.240 ± 0.020
GPT-6 Astra	45.1 [44.3, 45.8]	85.7 ± 1.7	58.7 ± 1.5	$3.63 ± 0.24	$0.155 ± 0.008
GPT-6 Astra (Codex)	44.1 [43.4, 44.9]	85.4 ± 1.9	58.5 ± 1.6	$4.51 ± 0.40	$0.194 ± 0.012
Kimi K3	44.0 [43.0, 45.0]	86.0 ± 1.5	58.6 ± 1.7	$8.70 ± 1.47	$0.176 ± 0.010
GLM 5.3	41.8 [40.8, 42.9]	84.1 ± 1.7	57.1 ± 1.7	$21.06 ± 1.89	$0.234 ± 0.013
Fable 5.1 (CC)	39.9 [37.4, 42.4]	84.9 ± 1.6	58.3 ± 2.5	$14.39 ± 2.23	$0.211 ± 0.014
Grok 4.6	39.7 [38.6, 40.7]	84.6 ± 1.6	54.1 ± 1.6	$2.63 ± 0.23	$0.225 ± 0.012
GPT-5.6 Sol (Codex)	39.5 [38.4, 40.5]	84.1 ± 2.1	52.9 ± 1.2	$2.14 ± 0.20	$0.199 ± 0.011
GPT-6 Sol	38.5 [37.8, 39.2]	85.2 ± 1.9	51.6 ± 1.3	$0.30 ± 0.02	$0.150 ± 0.007
Без библиотеки (baseline)	34.4 [33.9, 34.9]	86.4 ± 1.0	46.3 ± 1.1	—	$0.098 ± 0.006
DeepSeek V4 Pro	31.2 [30.4, 32.1]	84.9 ± 1.7	42.0 ± 1.1	$0.31 ± 0.02	$0.175 ± 0.008

Таблица 3. Результаты GPT-5.6 Luna (Codex) при различных усилиях рассуждений и промптах

Строки усилий (Effort) используют стандартный промпт (Default); строки промптов используют высокий уровень усилий (High).

Фактор влияния	Настройка	Балл ( ↑ )	% тестов ( ↑ )	Простота ( ↑ )	Стоимость задачи ($) ( ↓ )
Усилие рассуждений (Effort)	Низкое (Low)	27.8	51.4	83.2	$0.023
	Среднее (Med.)	38.9	69.6	72.5	$0.055
	Высокое (High) [Default]	45.5	84.5	60.4	$0.149
Предписательность промпта (Prompt)	Минимальная (Min.)	37.0	85.9	48.7	$0.082
	Низкая (Low)	36.5	87.3	46.4	$0.105
	Средняя (Med.)	44.3	85.7	57.3	$0.111
	Стандартная (Default) [High]	45.5	84.5	60.4	$0.149

Какие можно сделать выводы

Что я вижу тут практически полезного? Прежде всего сам бенчмарк и формулирование задачи. Научить агентов писать переиспользуемый лаконичный код и самое главное потом его переиспользовать - крайне важно, т.к. кодовые базы с агентами растут просто безбожно быстро. Практические советы, которые можно почерпнуть из исследования - человеку-разработчику уделять больше времени архитектуре, уточняя и расширяя промпт-спецификацию при постановке задачи агенту (или стараясь учитывать это в навыках/системных md инструкциях) с акцентом как на гибкости и переиспользовании как уже существующих решений, так и закладывании этого в создаваемое решение. Сами авторы приводят вполне себе эффективные практики:

• Consumer-first. Чётко определяем в спецификации агента-проектировщика о необходимости сначала подготовить и описать примеры вызова кода, а не сразу писать реализацию.
• Нейминг из претрейна. Называть методы максимально предсказуемо и стандартно для легкого и предсказуемого поиска агентами-исполнителями.
• Валидация субагентами. Прогонять созданные библиотеки независимыми субагентами-тестировщиками перед публикацией.

Краткое содержимое от LLM

Статья Can Agents Design Libraries for Agents? исследует, умеет ли ИИ-агент написать программную библиотеку так, чтобы другим агентам было удобно ею пользоваться. Авторы предложили для этого тест LibraryDesignBench: один агент создаёт библиотеку, а затем три других решают с её помощью практические задачи. Оценивают и работу программы, и то, сколько дополнительного кода пришлось написать. В исследовании — 15 задач на проектирование библиотек и 242 задачи для их пользователей на четырёх языках. Методика исследования

Главный вывод: агенты уже способны создавать полезные библиотеки, но другие агенты часто используют их возможности не полностью. Лучший результат библиотеки, написанной агентом, составил 48,9 балла против 46,6 у готовой библиотеки, написанной людьми, и 34,4 без библиотеки. Это баллы составной метрики авторов, а не процент решённых задач. Разница в баллах в основном связана с объёмом и сложностью кода, который пришлось дописать пользователям библиотеки. Результаты, таблица 1

Пересказ простым языком

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

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

Выяснилось, что проблема часто возникает на стыке библиотеки и её пользователя. В проверенной авторами выборке случаев лишнего кода 64% связали с негибким или неудобным интерфейсом библиотеки, а 14% — с отсутствием нужной возможности. То есть нужная «деталь» нередко есть, но применить её к конкретной задаче трудно, и агент пишет обходной код. Разбор ошибок

При этом часть ответственности лежит на агенте-пользователе. В одном из экспериментов с краткой инструкцией 24% запусков вообще не открывали код библиотеки. Более подробное указание изучить библиотеку и опираться на неё помогало писать более компактные решения. Исследование использования библиотек

Авторы также попробовали иной способ проектирования: сначала продумать примеры того, как будущие агенты будут вызывать библиотеку, добавить исполняемые примеры и дать другим агентам её опробовать. Для одной проверенной модели это подняло результат с 44,1 до 46,4 балла. Но эксперимент объединял несколько изменений сразу, поэтому статья не показывает, какое из них помогло больше. Эксперимент с рекомендациями