Hacker News Digest

В области контекст-инжиниринга для LLM существует ключевое противоречие: модели должны получать доступ ко всему ценному контексту, но только тогда, когда он актуален для текущей задачи. Автор статьи утверждает, что гиперссылки — это недооцененный инструмент для решения этой проблемы, особенно по сравнению с популярными подходами вроде RAG, сабагентов и get_* инструментов.

Человек, изучая новую тему, следует по ссылкам после первоначального поиска, постепенно собирая релевантную информацию. Аналогично LLM могут использовать гиперссылки для навигации по данным. Концепция HATEOAS (Hypertext as the Engine of Application State) из мира HTTP API обретает новое значение в эпоху агентов — "Hypertext as the Engine of Agent State". Реализация такой системы может быть предельно простой: достаточно инструмента для чтения URI и точки входа в контекст. Кодовый пример демонстрирует, как создать систему, где LLM может динамически запрашивать и обрабатывать связанные ресурсы по URI, эффективно управляя контекстом без перегрузки.

• Обсуждение подтвердило, что Claude Code и другие инструменты уже используют встроенные веб-ссылки и не требуют MCP, что делает концепцию MCP устаревшей.
• Участники отметили, что вместо MCP-архитектуры достаточно иметь инструмент, который может читать веб-страницы в Markdown и предоставлять ссылки на них.
• Была поднята тема, что модели могут обходить блокировки чтения веб-страниц, если пользователь указывает им ссылку.
• Обсуждение также затронуло, что вместо сложных и ненадежных MCP-конфигураций, можно использовать простые инструменты чтения веб-страниц, что делает MCP-конфигурации неактуальными.
• Участники также обсудили, что вместо того, чтобы модели обучались использовать MCP, они могли бы просто читать веб-страницы по URL-ссылкам, что делает MCP-конфигурации неактуальной.

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

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

• Обсуждение ограничений и инженерных подходов к работе с малыми окнами контекста (4K у Apple) по сравнению с большими окнами других моделей.
• Критика отсутствия удобных инструментов для визуализации и управления контекстом, а также предложения по улучшению (DSPy, OpenTelemetry, структурированный вывод).
• Стратегии работы с ограниченным контекстом: уточнение задачи и файлов в первом сообщении, создание новых сессий, структурирование вывода через JSON schema.
• Дебаты о том, являются ли эффективные методы инженерного контекста коммерческой тайной, и скептицизм по этому поводу.
• Прогнозы, что удешевление и увеличение контекста LLM могут сделать проблему менее актуальной в долгосрочной перспективе.

Контекстная инженерия для AI-агентов — это ключевой подход, позволяющий быстро итеративно улучшать производительность без переобучения моделей. Опыт разработки Manus показал, что вместо обучения end-to-end модели эффективнее использовать способность современных LLM к обучению в контексте, что сокращает цикл улучшений с недель до часов и делает продукт независимым от прогресса базовых моделей.

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

• Предлагается использовать файловую систему как память для агентов через директорию .agent/ для хранения задач, планов и других данных.
• Проводятся параллели между лучшими практиками для AI-агентов и управления кодом: избегать раздувания, не удалять плохие коммиты, не рефакторить слишком часто.
• Отмечается разница в стимулах для кеширования: на фиксированных тарифах выгодно провайдеру, на поминутных — пользователю.
• Рекомендуется простота в инструментарии, согласующаяся с подходом OpenAI Codex, например, использование update_plan для отслеживания прогресса.

Метод FCA (Function Calling Abstraction) предлагает новый подход к инженерии контекста для ИИ-агентов, работающих с кодом. Вместо передачи полного кода функции в контекст, он использует абстрактные описания её поведения, что значительно сокращает объём передаваемых данных. Это позволяет агентам точнее понимать предназначение функций без перегрузки контекста избыточной информацией.

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

• Участники обсуждают эффективность подхода "исследование -> план -> реализация" для работы с ИИ в больших кодовых базах, отмечая рост производительности, но и сложности управления контекстом.
• Поднимаются вопросы о надежности ИИ: необходимость почти идеальной точности генерации кода, проблемы с галлюцинациями и сложность верификации поведения без чтения каждой строки.
• Критикуется масштабируемость подхода: управление контекстом становится сложным при больших объемах, а стоимость использования мощных моделей (например, Opus) может быть высокой.
• Отмечается сдвиг роли инженера: от написания кода к определению спецификаций и верификации поведения, что требует новых навыков и вызывает сопротивление у некоторых разработчиков.
• Обсуждаются технические детали и инструменты: важность компрессии контекста, использования AST для анализа кода, необходимость ведения логов промптов и стилистического единообразия кода.

Не создавайте мульти-агентов

Фреймворки для LLM-агентов разочаровывают. Ниже — выжимка из нашего опыта и почему популярные идеи работают плохо.

Принципы контекст-инжиниринга

1. Делитесь контекстом целиком
2. Действия несут скрытые решения

Пока в мире LLM мы как в 1993-м с HTML: нет стандарта. Библиотеки вроде OpenAI Swarm и Microsoft Autogen продвигают мульти-агентов, но это, по нашему опыту, ошибка.

Почему мульти-агенты хрупки

Классическая схема:

• разбить задачу на подзадачи,
• запустить под-агентов,
• собрать результат.

Проблема: каждый уровень теряет детали. Пример: «сделай Flappy Bird» → под-агенты делают фон Mario и птицу, не похожую на оригинал. Сводить такие части — головная боль.

Принцип 1
Передавайте не сообщения, а полные трейсы агента.

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

• Пользователи обсуждают, что «агенты» — это просто разные промпты к одному и тому же API, а не отдельные сущности.
• Основная проблема — «размывание» контекста: при ~50 k токенов агенты теряют цель, поэтому многие отказались от сложных мульти-агентных схем в пользу одного агента + умного управления контекстом.
• Предложено строить «компиляторы контекста» вместо ручной курирования и использовать фиксированные pipeline-ы вместо свободно общающихся агентов.
• Некоторые сравнивают подход с супервизорами Erlang, но большинство считает это переизобретением старых идей.
• Общий вывод: пока нет надёжности, мульти-агентные системы неэффективны; начинать стоит с простейших блоков и адаптировать под свою задачу.