AI-агент равен AI-модели плюс крепление: что делает крепление и почему.
Агент — это модель плюс крепление. Узнайте, как крепления добавляют инструменты, память, циклы и ограничения, в чем разница между агентами с открытым весом и с открытым исходным кодом, и почему важна оценка.
Источники: AI Agent Is Nothing but an AI Model with a Harness
Некоторое время история прогресса в области ИИ рассказывалась через выпуск новых моделей: каждые несколько месяцев появлялись все более крупные и мощные базовые модели. Однако этот образ не полон. Языковая модель, будь она крупной или маленькой, обеспечивает первичный уровень интеллекта, но степень его доходчивости для пользователя зависит от программного обеспечения, которое её окружает. Это программное обеспечение называется интерфейсом управления, и все больше исследований показывают, что оно может играть такую же важную роль, как и сама модель. Недавние исследования по адаптации таких интерфейсов к более мелким моделям показывают, что тщательно настроенный интерфейс может позволить компактной модели достичь значительно высоких результатов в бизнес-задачах, сопоставимых с результатами передовых моделей, при значительно меньших затратах. Точные цифры приведены в оригинальных статьях, но общая тенденция совпадает с тем, что наблюдают практики: самая мощная модель не всегда обеспечивает наиболее эффективную систему.
Поэтому соревнование всё больше сводится к тому, кто создаст лучший «пояс» для модели, а не только к тому, кто построит самую крупную модель.
Почему у умной модели всё равно нужен «пояс»
Языковая модель может сгенерировать ответ. Однако она сама по себе не может просматривать папки, выбирать инструменты, сохранять рабочую память между вызовами, проверять написанное, восстанавливаться после ошибок или двигаться к цели. Именно эти пробелы и предназначены для устранения агенты. В агенте «пояс» окружает модель и преобразует её интеллект в структурированные, повторяемые действия, направленные на достижение цели.
Модель против агента
Модель принимает входные данные и генерирует выходные, после чего её работа завершается. Агент продолжает работать после первого ответа: он читает файлы, использует инструменты, выполняет команды, запоминает предыдущие результаты, принимает решения и продолжает выполнять несколько шагов до завершения задачи.
Как это может произойти, если модель создана только для прогнозирования следующего результата? Благодаря инженерной системе, окружающей модель. Она определяет, какой контекст поступает в модель, какие инструменты доступны, как выполняются вызовы инструментов, что сохраняется, когда модель снова вызывается, и какие действия отклоняются или требуют одобрения.
Эта система также создает рабочий цикл:
Цикл работает следующим образом: модель читает содержимое своего контекста, выбирает действие, вызывает инструмент, анализирует полученный результат, включает его в свой контекст и снова начинает цикл.
Именно этот цикл отличает процесс ответа от выполнения задачи. Он также может быть связан с планировщиком или внешним триггером, так что агент может начать работу сам по себе в определенное время или при наступлении какого-либо события.
Уравнение: агент = модель + система управления
Модель — это та часть, которая делает прогнозы. Получив любой предоставленный ей контекст, она генерирует наиболее полезный следующий результат или действие. «Оснастка» — это программное обеспечение, окружающее её и преобразующее эту первичную способность в управляемое, многократное поведение.
Посмотрите, что происходит, когда одну и ту же модель встраивают в разные «оснастки»:
- С обычной чат-оснасткой она становится ассистентом для общения.
- Добавив возможности веб-поиска, извлечения информации, оценки источников и проверки цитат, она превращается в исследовательского агента.
- Предоставив ей хранилище, редактор, терминал и инструменты для проверки результатов, она становится агентом для программирования.
- Подключив её к данным клиентов, бизнес-правилам, инструментам обмена сообщениями, триггерам и этапам утверждения, вы получаете агента для управления операциями.
Сама модель никогда не менялась. Менялся лишь фреймворк. Это также объясняет, почему два продукта, основанные на одной и той же базовой модели, могут вести себя совершенно по-разному. Один из них находит правильные доказательства, выбирает подходящий инструмент, восстанавливается после неудачных попыток, поддерживает порядок в контексте и проверяет результат. Другой теряет ключевую информацию, продолжает использовать неправильный инструмент или объявляет о победе без проверки. Способности продукта нельзя оценивать только по его модели: модель определяет, что может понимать система, а фреймворк — что она может выполнить.
Различие между слоями
Люди часто используют термины «модель», «агент» и «фреймворк» как синонимы, хотя это разные слои.
Codex и Claude Code наглядно демонстрируют эту модель среди инструментов для программирования. Каждый из них сочетает собственные модели разработчика с фреймворком, обеспечивающим управление контекстом репозитория, доступом к файлам, инструментами, командами оболочки, памятью, процессом выполнения, отзывами о тестах и циклами повторения. OpenCode, Goose, Pi, Letta и AutoGPT следуют той же модели, что и среды выполнения или фреймворки; они отличаются по поддерживаемым моделям, наборам инструментов, конструкциям памяти и степени открытости.
Агент представляет собой полную систему, модель обеспечивает интеллектуальные возможности, а фреймворк регулирует способ взаимодействия этих возможностей с внешним миром.
Открытые веса и открытый исходный код — это разные вещи
Такие продукты, как Codex и Claude Code, представляют собой готовые агенты, в которых модель и инструментарий разрабатываются и настраиваются одной компанией. Агент с открытыми весами, напротив, сочетает загружаемую модель с существующим или пользовательским инструментарием. Это даёт разработчикам больший контроль над процессом развертывания, используемыми инструментами, объёмом памяти, конфиденциальностью, затратами и поведением агента. Веса модели могут работать на собственной инфраструктуре, и при наличии соответствующей лицензии их можно доработать. Типичными примерами являются сочетание Goose с моделью открытого типа, такой как gpt-oss-120b, или OpenCode с моделями Qwen или Gemma.
Агент с открытым исходным кодом — это нечто другое: код инструментария является общедоступным. Любой может прочитать его и изменить способ формулировки запросов к модели, список предлагаемых инструментов, методы хранения памяти, работу циклов, интеграцию с другими сервисами, а также правила обработки разрешений и контекста. OpenCode, Goose и AutoGPT являются примерами таких открытых инструментариев.
Эти два аспекта являются независимыми:
- Инструмент на основе открытого кода всё равно может вызывать проприетарную модель через API. OpenCode способен управлять моделями GPT или Claude, поэтому его интерфейс, логика управления и выполнение инструментов являются открытыми, в то время как сама модель остается закрытой.
- Модель с открытыми весами сама по себе не является агентом. Модель вроде gpt-oss-20b может предсказывать и принимать решения, но она не может просматривать папки, запускать инструменты, сохранять состояние задачи или завершать рабочий процесс до тех пор, пока её не окружит такой инструмент, как Goose, OpenCode или пользовательская фреймворк-среда.
Кратко говоря: агент на основе открытого кода — это инструмент с открытым исходным кодом плюс любая совместимая модель, а агент с открытыми весами — это такой же инструмент плюс загружаемые веса модели.
Почему важны открытые экосистемы
В настоящее время несколько лабораторий выпускают доступные по цене модели с открытым весом вместе с инструментарием на основе открытого кода, создавая гибридные открытые экосистемы. Такие релизы сделали открытые решения серьезными конкурентами проприетарных кодирующих агентов в определенных тестах, хотя и не всегда превосходят их во всех аспектах. Собственные оценки поставщиков часто показывают, что проприетарные передовые модели остаются лучше в ряде тестов на кодирование. Важно не то, что одна модель превосходит все остальные, а то, что доступная по цене модель с открытым весом, сочетаемая с тщательно спроектированным инструментарием, может конкурировать с дорогими закрытыми системами.
Что включает в себя хороший инструментарий
Эффективность достигается за счет сочетания модели и инструментария, причем инструментарий состоит из нескольких компонентов:
- Выбор контекста. Выбор того, что будет передано при каждом вызове модели, чтобы был доступен соответствующий файл, запись или документ, а шум — нет.
Выборы при проектировании, формирующие структуру
Каждый фреймворк принимает решения, которые незаметно ограничивают возможности агента, и некоторые из них требуют внимания с самого начала.
Сколько инструментов и как они описаны. Предоставление модели двадцати перекрывающихся инструментов обычно вредит больше, чем пять четко определенных. Названия, описания и структура аргументов фактически являются подсказками, поэтому нечеткие определения инструментов приводят к неправильным действиям.
Сколько информации нужно запоминать. Длинные истории вытесняют полезный контекст. Фреймворки обычно сокращают информацию, делают ее кратким изложением или хранят примечания вне подсказок, вызывая их при необходимости. То, что сохраняется и на какой срок, сильно влияет на способность агента сохранять целостность выполнения длительной задачи.
Где разместить человека. Некоторые действия, такие как чтение файла, можно безопасно автоматизировать. Другие, например удаление данных или отправка денег, требуют этапа утверждения. Определение таких правил — это решение разработчика, а не модели.
Что считается завершённым. Циклу необходимо условие остановки, такое как прохождение тестов, проверенный ответ или лимит шагов. Без него агент либо прекращает работу раньше времени, либо продолжает её без ограничений.
Практический способ начала
Если вы разрабатываете агента, начните с самой простой структуры, способной выполнить одну реальную задачу от начала до конца: одна модель, два-три инструмента, цикл с ограничением по количеству шагов и письменное определение успеха. Затем соберите от десяти до двадцати реальных задач, запустите их, изучите результаты выполнения и сначала устраните наиболее частые ошибки. Замена модели будет произведена позже, когда вы убедитесь, что структура не является ограничивающим фактором. Такой порядок действий поможет вам не винить модель в проблемах, которые на самом деле связаны с используемыми инструментами.
Как работает доступ к файлам
Модель не может напрямую обращаться к файлам на компьютере. Инструментальный фреймворк предоставляет контролируемые средства для перечисления каталогов, поиска имен файлов, загрузки соответствующего контента, открытия и редактирования файлов, выполнения кода и сохранения результатов. Модель сама выбирает, какую информацию или действие ей нужно выполнить дальше. Фреймворк проверяет и выполняет этот запрос, возвращает результат и добавляет его в контекст. Этот процесс повторяется до тех пор, пока модель не решит, что задача завершена:
Модель запрашивает действие, фреймворк его выполняет, возвращается результат, и модель выбирает следующее действие.
Например, при запросе на устранение сбоя в тесте модель может попросить список каталогов, затем открыть файл теста и модуль, который проверяется, предложить изменения и запросить запуск теста. На каждом этапе фреймворк определяет, разрешено ли действие, выполняет его и сообщает о результатах.
Инструментарий оценки имеет такое же важное значение
Создание инструментария для агента — это лишь половина работы. Вторая половина — это инструментарий оценки, который показывает, работает ли агент. Он тестирует в условиях, максимально приближенных к реальным, способность всей системы выбирать правильные инструменты, восстанавливаться после сбоев, контролировать затраты, соблюдать правила безопасности и стабильно выполнять задачи. Это гораздо больше, чем просто пройти отдельный тест-кейс.
Инструментарий агента состоит из множества взаимодействующих компонентов, и в каждом из них может скрываться регрессия: подсказки, правила контекста, инструменты, политики памяти, циклы планирования, процедуры верификации, разрешения и механизмы восстановления. Без набора для оценки команда не сможет понять, помогло ли изменение одного из этих компонентов или оно тайно привело к новым сбоям. Поэтому эти два инструментария образуют цикл обратной связи:
- Соберите типичные задачи, включая реалистичные рабочие процессы, сложные случаи и ранее встречавшиеся сбои.
- Запустите полную систему вместе с текущей моделью и инструментальным комплексом.
- Проверьте результаты: успех выполнения, логи действий, вызовы инструментов, ошибки, затраты и время отклика.
- Измените один компонент — будь то промпт, инструмент, модель, политика работы с памятью, цикл или правило маршрутизации.
- Снова проведите оценку на задачах, не использовавшихся ранее, и в случаях регрессии.
- Оставьте только те изменения, которые действительно улучшают необходимый баланс между точностью, надежностью, безопасностью, скоростью и затратами.
Кратко: создайте, оцените, выявите сбои, улучшите инструментальный комплекс, снова оцените.
Чтение логов
Оценка проходит наиболее легко, когда можно увидеть, что именно сделал агент. Полезный отчет фиксирует каждый вызов модели, запрашиваемый инструмент, аргументы, возвращенный результат, использованные токены и затраченное время. Когда задача не выполняется, нужно искать в отчете первый неправильный шаг, а не последний. Часто корень проблемы находится раньше: отсутствующий файл в контексте, нечеткое описание инструмента или неверное предположение, которое переносится на все последующие шаги. Исправление этой одной проблемы обычно решает целую группу сбоев, поэтому анализ отчетов является одной из самых эффективных практик, которые может внедрить команда.
Важна ли все еще модель?
Да. Более новые модели постоянно совершенствуют свои навыки рассуждения, программирования, выполнения инструкций, точности вызова инструментов, объема обработки контекста, скорости работы, экономичности и мультимодальных способностей, и интеграционные средства не могут надежно создать те функции, которых у модели нет. Однако сама модель уже не является полным продуктом.
Когда несколько моделей одинаково подходят для выполнения задачи, интеграционные средства могут компенсировать большую часть оставшихся различий между продуктами. Механизмы поиска подходящих файлов, инструменты с очевидными действиями, системы управления состоянием, запоминающие завершенную работу, проверки, выявляющие ошибочные изменения, права доступа, предотвращающие опасные действия, и механизмы восстановления после сбоев — все это в совокупности влияет на качество продукта.
Это указывает на простое разделение труда, которое также служит удобным чек-листом для анализа любого проекта агента. Спросите, что модель может разумно делать, что необходимо добавить с помощью инструментов, чтобы эта способность проявлялась надежно, и какие доказательства предоставляют оценки того, что это действительно произошло.
- Модель определяет внешние границы того, что может делать система.
- Инструменты преобразуют эти границы в надежные, воспроизводимые результаты.
- Оценки подтверждают, действительно ли готовая система выполнила поставленные задачи, что — отдельный вопрос от того, умна ли модель.
Именно поэтому сейчас столько внимания уделяется инженерии приложений, связанной с такими инструментами и процедурами оценки. Именно в этих инструментах команда создает устойчивое преимущество благодаря закрытому контексту, более безопасным инструментам, рабочим процессам для конкретной области, механизмам хранения данных, восстановлению от ошибок и улучшенному пользовательскому опыту.
Ответ на центральный вопрос
Может ли модель стать настоящим, функциональным агентом без вспомогательной системы? Нет. Одна лишь модель не имеет среды для выполнения действий, подключения к внешним системам, запоминания выполненных шагов, наблюдения за последствиями своих решений и продолжения работы над целью. Модель — это мозг и механизм рассуждений. Вспомогательная система представляет собой «тело», инструменты, память, циклы обратной связи, разрешения и ограничения, которые превращают прогнозы в контролируемые действия.
Или одной фразой: ИИ-агент — это ИИ-модель плюс вспомогательная система.