Модель зрелости агентов: надзор человека, инженерия инструментов, оркестрация.
Пять уровней зрелости агентов, проверенных в реальных условиях: надзор человека, инженерия инструментов, оркестрация множества агентов и проблемы, которые до сих пор не решены.
Источники: Agentic Architectures — Article 15: The Maturity Model Revisited
Модель зрелости агента легко нарисовать, но трудно реализовать на практике. На бумаге она выглядит идеально: лестница, начинающаяся с простых инструментов для вызова функций и заканчивающаяся самосовершенствующимися производственными системами. Фреймворки всегда кажутся аккуратными до тех пор, пока кто-то не попытается запустить их в реальных условиях с высокой нагрузкой. Как только за ними оказывается реальный код, та же самая модель воспринимается иначе. В ней не было ошибок, но знание чего-то в теории и знание этого в производственной среде — это разные виды знаний. Карта не может показать, каково это, когда в три часа ночи предохранитель не закрывается, а на дежурстве оказываешься ты сам.
Это обзор данной модели после того, как были созданы все лежащие в её основе слои: как уровни соотносятся с инженерной работой, какие предположения не выдержали проверки в реальных условиях производства, как выглядит иерархическая архитектура справочных решений и что остаётся нерешённым. Код здесь минимален. Цель — взглянуть на всю структуру целиком.
Пять уровней, каждый из которых основан на предыдущем
Модель зрелости описывает пять уровней способностей агента. Каждый уровень — это не просто усиленная версия предыдущего, поскольку он также зависит от всего, что находится ниже. Пропустить этапы невозможно. Агент не может быть достоверно автономным без инфраструктуры для оценки, а также не может совершенствоваться без памяти. Уровни накапливаются друг в друга.
Вот как инженерные аспекты соотносятся с этими уровнями:
+---------+---------------------+------------------------------------------+
| Level | Capability | Articles That Build It |
+---------+---------------------+------------------------------------------+
| Level 1 | Reactive | Article 4: Protocols (MCP, A2A) |
| | Responds to inputs, | Basic tool use, standard interfaces |
| | calls tools | |
+---------+---------------------+------------------------------------------+
| Level 2 | Assisted | Article 5: Harness Engineering |
| | Shaped behavior, | Article 13: Human-in-the-Loop |
| | human oversight | |
+---------+---------------------+------------------------------------------+
| Level 3 | Supervised | Article 6: Multi-Agent Orchestration |
| | Coordinated, | Article 8: Evaluation Pipelines |
| | evaluated, secured | Article 9: Security and Red-Teaming |
+---------+---------------------+------------------------------------------+
| Level 4 | Autonomous | Article 7: Memory Architectures |
| | Operates | Article 10: Cost Optimization |
| | independently at | Article 11: Deployment Patterns |
| | scale | Article 14: Goal-Directed Loops |
+---------+---------------------+------------------------------------------+
| Level 5 | Self-Improving | Articles 7 + 8 combined |
| | Learns from its own | Article 12: The frontier (not yet here) |
| | operation | |
+---------+---------------------+------------------------------------------+
Форма важнее, чем сопоставление. Уровень 5, самосовершенствование, не имеет отдельного компонента, поскольку это не то, что можно создать напрямую. Он возникает тогда, когда память и оценка работают вместе, но даже тогда эта сфера ещё не полностью сформирована. Верхняя часть модели по-прежнему отчасти остаётся амбициозной целью. Самосовершенствование сегодня можно лишь приблизительно реализовать, но полностью достичь его невозможно.
Это не было очевидно при первоначальном наброске модели. Уровень 5 казался целью, к которой можно добраться, собрав нужные элементы. На практике же он ведёт себя скорее как горизонт, который удаляется по мере приближения к нему.
Убеждения, скорректированные процессом разработки, от участия человека до оркестрации
Это то, что документ с описанием фреймворка никогда не сможет полностью отразить, поскольку оно возникает только в процессе создания. Несколько первоначальных предположений оказались неверными или, по крайней мере, неполными.
Память сильно недооценивалась. В первом эскизе память рассматривалась как простой функциональный элемент, способствующий более плавной работе агентов. Однако при её разработке стало ясно, что память представляет собой инфраструктуру в полном смысле этого слова — с всеми сопутствующими аспектами: проектированием схем, качеством поиска информации, механизмами устаревания данных и изоляцией пользователей. Затем последовал ещё более неприятный вывод: даже та инфраструктура, которую мы умеем создавать, не является идеальной абстракцией. Команды вынуждены использовать базы данных, разработанные для других целей, поскольку специально созданных решений не существует. Память оказалась наиболее недооцененным элементом в первоначальной модели.
Цель — предсказуемость, а автономия имеет второстепенное значение. Это самое глубокое изменение. В начальный период прогресс оценивался по тому, насколько агент мог действовать без участия человека, поэтому любое увеличение степени независимости воспринималось как прогресс. Однако агент, действующий самостоятельно, но непредсказуемо, причиняет вред раньше. Оказалось, что надежность под наблюдением важнее чистой автономии в любых серьезных задачах. Один из примеров неудачи связан с агентом, который автономно создал десятки дублирующихся заявок. Производственным системам нужна оптимальная степень автономии: ограниченная, подлежащая аудиту и предсказуемая, при этом люди должны принимать решения, стоимость которых требует их внимания. Один из читателей утверждал, что оркестрация должна стремиться к предсказуемости, а не к автономии, и пришлось долго соглашаться с этим утверждением.
Безопасность является свойством каждого уровня. Изначальный план рассматривал безопасность как вопрос, который решается ближе к концу, как что-то, что добавляется после того, как система начнёт работать. Внедрение механизмов против внедрения кода исправляет эту ситуацию. Цели таких механизмов находятся в других местах: в момент вызова инструментов, при записи данных в память, при изменении целей и во взаимодействии между агентами. Каждый компонент имеет аспект безопасности. Аутентификация на границе использования инструментов, изоляция данных в памяти и контроль за изменением целей — всё это элементы безопасности, распространённые по всей системе, а не сосредоточенные в одном месте.
Цикл имеет более высокий приоритет, чем промпт. Этот урок был рассмотрен в конце, хотя ему следовало уделить внимание раньше. Большая часть усилий в этой области направлена на разработку промптов и поиск идеальных формулировок. Однако агент — это не промпт; это цикл, достигающий цели поэтапно. Идеальный промпт внутри несовершенного цикла приводит к созданию красноречивого агента, который так и не достигает цели. Как только вы начнёте мыслить в терминах циклов, многие проблемы, которые казались ограничениями модели, оказываются ошибками в проектировании циклов.
Наличие человека в процессе не является недостатком, который можно устранить с помощью инженерных решений. Легко предположить, что участие человека — это временная подпорка, которую следует убрать по мере совершенствования технологий. Лучшие системы автоматизированных агентов — это не самые автономные. Они применяют человеческое суждение именно там, где оно необходимо, и нигде больше. Человеческий надзор — это не этап, который нужно пройти, чтобы продвинуться дальше. Это целенаправленная и постоянная черта любой системы, ошибки в которой имеют реальные последствия.
Вся структура в одном изображении
Если объединить всё вышеописанное, зрелая система автоматизированных агентов будет выглядеть так:
+==========================================================================+
| HUMAN OVERSIGHT LAYER |
| Approval gates, escalation, audit trail (Article 13) |
+==========================================================================+
| | |
+==========================================================================+
| GOAL & LOOP LAYER |
| ReAct / Plan-Execute / Reflexion, goal revision (Article 14) |
+==========================================================================+
| | |
+==========================================================================+
| ORCHESTRATION LAYER |
| Supervisor-worker, pipeline, fan-out, debate (Article 6) |
+==========================================================================+
| | |
+==========================================================================+
| HARNESS LAYER |
| Self-verification, loop detection, reasoning routing (Article 5) |
+==========================================================================+
| | |
+--------------------------------------------------------------------------+
| MODEL LAYER |
| AWS Bedrock: Claude 3.7 / 3.5 / Haiku |
+--------------------------------------------------------------------------+
CROSS-CUTTING CONCERNS (touch every layer above):
+----------------+ +----------------+ +----------------+ +----------------+
| MEMORY | | EVALUATION | | SECURITY | | COST |
| Article 7 | | Article 8 | | Article 9 | | Article 10 |
| episodic, | | offline+online | | injection def, | | model routing, |
| semantic, | | LLM judge, | | guardrails, | | caching, |
| procedural | | regression | | red-teaming | | batch, budget |
+----------------+ +----------------+ +----------------+ +----------------+
+--------------------------------------------------------------------------+
| DEPLOYMENT LAYER (Article 11) |
| Blue-green, canary, state migration, model pinning, IaC |
+--------------------------------------------------------------------------+
Вертикальные слои формируют путь запроса. Задача поступает под контролем человека, формируется под влиянием целей и циклов, координируется между различными агентами, совершенствуется с помощью соответствующих механизмов и в конечном итоге выполняется с использованием модели. Проблемы, касающиеся всей структуры, влияют на каждый слой. Память обеспечивает функционирование как циклов, так и соответствующих механизмов. Безопасность защищает границы инструмента и процесс корректировки целей. Стоимость определяет выбор маршрута модели на каждом этапе. Развертывание объединяет всё это воедино.
Пошаговый взгляд скрывает степень тесной взаимосвязи всех компонентов. Изменение в одном элементе влияет на остальные. Невозможно оптимизировать затраты, не понимая принципов работы циклов, поскольку дорогостоящие операции часто связаны с циклами, которые не прекращаются. Для обеспечения безопасности также необходимо учитывать особенности памяти, поскольку поврежденные данные могут продолжать влиять на работу системы долгое время после своего создания. Следует рассматривать слои как единую взаимосвязанную структуру, а не как набор отдельных модулей.
Что до сих пор никто не решил
Возможно, это самый полезный раздел, поскольку всё, что было сказано выше, описывает то, что уже можно создать, а здесь говорится о том, что пока нельзя. Честная карта границ ценнее, чем идеально отретушированная.
Память, специально разработанная для агентов, не существует. Современные системы памяти формируются на основе баз данных и векторных хранилищ, созданных для других целей. По некоторым оценкам, настоящая система, специально разработанная для агентов, которая отслеживает время, выполняет поиск по ассоциациям, умышленно забывает информацию и позволяет агенту самому решать, что сохранять, появится только через несколько лет. То, что существует сейчас, функционирует, но это не то, что нужно.
Агенты не могут надёжно определить, когда их знания применимы. Это более глубокая форма проблемы устаревших данных. Агент может извлечь соответствующую процедуру и с уверенностью применить её в ситуации, где она не подходит, поскольку трудно определить момент, когда тот или иной фрагмент знаний перестаёт быть действительным, а проверить это ещё сложнее при извлечении информации. Процедура, которая работает в одной юрисдикции, может быть неправильно применена в другой, причём ни агент, ни, как правило, пользователь этого не замечают. Это фундаментальное ограничение, а не просто технический недостаток.
Самооценка ненадежна. Логика усиления действий и система оценки уверенности зависят от точного определения агентом собственной уверенности. Иногда ему удается это сделать, а иногда он ошибается, казалось бы, будучи уверенным, что является наиболее опасным случаем, поскольку это сводит на нет все меры защиты, основанные на осознании агентом собственных ограничений. Пока еще не существует надежного способа калибровки самооценки.
Инструменты не переносятся между моделями. Каждый инструмент настраивается под поведение конкретной модели. При смене модели необходимо заново настраивать подсказки, пороги обнаружения циклов и критерии проверки. В принципе это не должно быть так, но пока никто не создал абстракции инструментов, способной функционировать после смены модели без корректировок. Обновление модели по-прежнему остается проектом, а не просто изменением конфигурации.
Настоящего непрерывного обучения не существует. Процедурная память имитирует процесс обучения: успешные решения сохраняются и повторно используются. Однако веса не меняются, и агент не развивает новых способностей благодаря опыту. Он создает библиотеку прошлых решений и черпает из неё информацию. Агент, который действительно улучшает свои результаты в определённом классе задач благодаря опыту, — это то, чего современные производственные системы пока не могут достичь.
Затраты на грани диапазона остаются непредсказуемыми. Существуют инструменты для управления затратами, и они действительно работают, но крайние значения распределения остаются сложными для прогнозирования. Небольшая доля запусков, в ходе которых возникают патологические циклы или необычные крайние случаи, всё равно потребляет чрезмерные ресурсы способами, которые трудно предвидеть. Эти расходы можно ограничить, но полностью предсказать их невозможно.
Ничто из этого не является причиной для сдержанности. Это границы текущей карты, и знание их местоположения — вот что отличает инженерный подход от мечтаний.
С чего начать: с разработки инструментов перед оркестрацией агентов
Если вы создаете систему агентов, не рассматривайте эти элементы как порядок сборки. Они группируются по концепциям, а не по последовательности создания. Если строить всё в таком порядке, вы создадите механизмы хранения данных раньше, чем у вас появятся средства для их использования, и начнёте оценку раньше, чем будет что-то оценивать.
Начните с того уровня зрелости, на котором находится ваша система.
- У агента для вызова инструментов с базовыми функциями, но ненадёжного, следует сначала разработать инструментальную базу, именно здесь и кроются большинство проблем с надёжностью.
- У надёжного одиночного агента, достигшего своего потолка в развитии, уже можно переходить к оркестрации нескольких агентов.
Инструменты можно заменять, но идеи — нет
Примеры, приведённые в ходе этого обсуждения, были созданы на базе AWS Bedrock, LangGraph и LangChain. Это были практичные варианты, выбранные потому, что именно они используются в производстве, но они не являются единственно правильными. Большинство важных аспектов не связаны с ними. Аутентификация должна реализовываться на уровне инструмента в любых облаках. В любой платформе более важна логика работы цикла, чем текст запроса. Уровни памяти, схемы координации нескольких агентов, категории атак и матрица соотношения обратимости и затрат для человеческого контроля могут быть применены и в других технологических стеках.
Именно поэтому стоит иметь локальную альтернативу с Ollama и Docker. Это позволяет запускать соответствующие шаблоны без необходимости платить за облачные сервисы и демонстрирует, что концепции можно отделить от их реализации. Если архитектура памяти работает с локальной моделью и локальным векторным хранилищем, то такой дизайн изначально ничем не обязан Bedrock. Была выявлена основная проблема, которая выглядит одинаково на любой платформе. То же самое касается шаблонов оркестрации: замена LangGraph на другую фреймворк-среду меняет синтаксис циклов, но не способы их сбоя, с которыми им приходится справляться. То же самое верно и для инструментов оценки, которые могут использоваться с любой моделью, находящейся за ними.
Что выяснилось при записи
Четкое и последовательное объяснение темы человеку, который не присутствовал при её изучении, помогает выявить пробелы в собственном понимании. Многие темы кажутся полностью освоенными до тех пор, пока вы не пытаетесь их описать словами.
Честная картина ситуации в этой области заключается в том, что она одновременно и увлекательна, и незрела. Сейчас возможны вещи, которые были невозможны два года назад, и легко обмануть себя, поскольку уверенное изложение кажется более совершенным, чем на самом деле. Разница между агентом, который хорошо демонстрирует свои возможности в тестовых условиях, и тем, который надежно работает в реальных условиях, огромна, и большая часть сложностей инженерной реализации заключается именно в этой разнице.
Если есть одно сообщение, которое стоит отправить обратно в исходную точку, то это то, что настоящая работа заключается не в том, чтобы сделать агентов более мощными. Модели и так уже мощны и продолжают совершенствоваться по графику, который вы не контролируете. Настоящая задача — сделать эти мощные модели надежными, предсказуемыми, безопасными и достаточно доступными, чтобы можно было доверять им при принятии реальных решений. Это инженерия, а не магия: использование механизмов, циклов, памяти, методов оценки и всей той неприметной инфраструктуры, которая превращает способную модель в нечто, на что можно положиться.
Интеллект заимствуется у модели. Архитектуру же приходится создавать самостоятельно.
Связанные материалы
- Практические заметки: Агентные архитектуры, Статья 12: Готовы ли мы к: Подробное руководство по Практическим заметкам: Агентные архитектуры, Статья 12: Готовы ли мы к — контракты, проверки и готовые блоки кода для команд, использующих эту модель.
- Участие человека в работе ИИ-агентов: контрольные точки, эскалация, журналы аудита: В ситуациях, когда агенту требуется одобрение человека, описаны четыре подхода (контрольные точки, эскалация, совместная редактирование, выборка примеров), возможности паузы и возобновления работы с помощью LangGraph, таймауты, журналы аудита и распространенные ошибки.