Агенты самосовершенствования: исцеление, обучение и контролируемые изменения

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

Люди объединяют эти вопросы под термином «цикл обратной связи агента», но этот термин вводит в заблуждение. Приведённая ниже архитектура сочетает LangGraph с MongoDB, Gemini в Vertex AI и Arize Phoenix, обеспечивая восстановление во время работы, обучение на опыте, непрерывную оценку и контролируемое улучшение.

Почему наивный цикл опасен

Простая версия цикла обратной связи выглядит так:

Agent produces answer
        ↓
LLM reflects on answer
        ↓
Agent learns

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

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

Конкретный пример: агент рекомендует коды для начисления или вычета заработной платы. В одной из попыток он выбирает неверный код, поскольку так и не получил информацию о политике начисления заработной платы, специфичной для текущего состояния. Наивный путь обучения выглядит следующим образом:

Agent made mistake
        ↓
Agent reflects
        ↓
"Always retrieve state policy"
        ↓
Write lesson to memory
        ↓
Future agents use lesson

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

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

Production failure
        ↓
Capture evidence
        ↓
Evaluate the run
        ↓
Identify recurring failure
        ↓
Generate lesson candidate
        ↓
Gather supporting and contradicting evidence
        ↓
Validate
        ↓
Canary test
        ↓
Activate

Это изменение незаметно. Агент не постоянно переписывает себя. Платформа, окружающая его, постоянно оценивает и совершенствует агента.

Три уровня с разным уровнем полномочий

Полезно представить себе три взаимосвязанных уровня.

+------------------------------------------------+
|                RUNTIME PLANE                   |
|                                                |
| plan -> act -> validate -> repair -> respond   |
+-----------------------+------------------------+
                        |
                        v
+------------------------------------------------+
|                LEARNING PLANE                  |
|                                                |
| evaluate -> diagnose -> cluster -> learn       |
+-----------------------+------------------------+
                        |
                        v
+------------------------------------------------+
|                CONTROL PLANE                   |
|                                                |
| test -> approve -> canary -> rollout -> rollback|
+------------------------------------------------+

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

1. Автономное восстановление во время выполнения

Начнем с непосредственной проблемы: запрос к инструменту завершился неудачей. Простая реализация просто пытается выполнить запрос снова.

Tool failed
   ↓
Retry
   ↓
Retry
   ↓
Retry

Однако повторная попытка не является способом самовосстановления. Для восстановления необходимо знать, что пошло не так, и выбрать подходящую стратегию восстановления. Более эффективный рабочий процесс LangGraph ближе к этому подходу:

User Request
     |
     v
Clarification Gate
     |
     v
Retrieve Context
     |
     v
Plan
     |
     v
Proposed Action
     |
     v
Action Guard
     |
     v
Execute Tool
     |
     v
Sanitize Tool Result
     |
     v
Validate Tool Result
     |
     v
Reason
     |
     v
Validate Answer
     |
     +------ uncertain ------> Critic
     |                           |
     |                           v
     |                      Policy Router
     |                     /    |    |    \
     |                  PASS REPAIR HUMAN FAIL
     |                           |
     +---------------------------+
     |
     v
Response

Несколько моментов, показанных на этом графике, заслуживают внимания.

Проверка перед действием

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

Это меняет подход к проверке. Вопрос перестаёт быть «было ли действие правильным?» и становится гораздо более безопасным: «имеем ли мы достаточно доказательств и полномочий, чтобы разрешить это?»

Результаты работы инструмента также считаются ненадёжными

Ещё один риск остаётся незамеченным. Агенты считывают контент с веб-сайтов, документов, API, поисковых систем, баз данных и других агентов, и этот материал попадает в контекст LLM. Следовательно, результаты работы инструментов представляют собой ещё один путь для внедрения вводимого текста, поэтому между выполнением инструмента и процессом рассуждения необходим механизм очистки результатов инструментов, обеспечивающий детерминированность.

External Tool
     |
     v
Tool Result
     |
     v
Sanitizer
     |
     v
Validator
     |
     v
LLM

Типичные задачи санитайзера включают контроль типа и длины выводимого текста, отклонение некорректных структур, экранирование текста, похожего на инструкции, и выявление вероятных попыток внедрения кода. Одно ограничение строгое: нельзя использовать ЯИИ для анализа текста, который может быть адверсарским.

Разделяйте модуль проверки от модуля оценки

Распространённый подход — задавать ЯИИ на каждый запрос вопрос «Правильен ли этот ответ?». Это увеличивает задержку и затраты, к тому же предоставляет модели чрезмерные полномочия. Сначала должна происходить детерминистическая проверка, например:

Schema correct?
Required fields present?
Allowed value?
Business invariant satisfied?
Evidence exists?
Policy satisfied?
Known contradiction detected?

Если программное обеспечение может доказать, что ответ неверен, нет причин обращаться к другой модели. Только истинная семантическая неоднозначность доходит до критика, и даже тогда критик не управляет рабочим процессом. Его роль заключается в диагностике, в следующем ключе:

{
  "correctness": 0.61,
  "groundedness": 0.92,
  "uncertainty": 0.73,
  "defects": [
    "missing_authoritative_evidence"
  ]
}

Затем маршрутизатор с детерминистской политикой выбирает один из четырех возможных исходов:

PASS
REPAIR
HUMAN REVIEW
SAFE FAIL

Разделение четкое: большие языковые модели предоставляют доказательства и оценки, в то время как политика программного обеспечения обладает полномочиями.

Для устранения проблемы следует изменить стратегию

Повторная попытка имеет смысл только тогда, когда что-то изменилось. Возьмем агента, который выполняет такую действие:

Search policy
    ↓
Generate recommendation
    ↓
Fail validation

Если ремонт повторяет приведённую ниже последовательность с теми же запросами, теми же доказательствами и тем же подходом к анализу, это не восстановление. Это просто повторение.

Search policy
    ↓
Generate recommendation

Надежный агент отслеживает несколько полей.

failure signature
strategy fingerprint
attempt ID
repair strategy
remaining budget
quality delta

Затем применяется простое правило.

same failure
+
same strategy
+
same evidence
=
do not retry

Каждый раз, когда та же проблема возникает при применении той же стратегии во второй раз, агент должен сменить стратегию, передать задачу человеку или обеспечить безопасную остановку работы. Простой retry_count не покрывает таких ситуаций, поэтому для автономного восстановления в производственных условиях требуются бюджеты на ремонт. Они могут ограничивать количество вызовов больших языковых моделей, инструментов, продолжительность выполнения задач, затрачиваемые ресурсы и количество попыток семантического восстановления. Цель не в том, чтобы настойчиво пытаться что-то сделать до тех пор, пока это не сработает; цель — использовать ограниченное количество ресурсов на стратегии восстановления, которые действительно отличаются друг от друга.

Проверка эффективности ремонта

Даже разные попытки могут не привести к желаемому результату. Предположим, оценщик присваивает баллы первоначальному результату:

quality score = 0.54

После первого ремонта:

quality score = 0.55

После второго:

quality score = 0.56

На бумаге это улучшение, но на практике это застой. Ремонтный дельта-шлюз справляется с этой проблемой.

delta = score_after_repair - score_before_repair

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

small delta
+
small delta
=
human review or safe failure

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

Проверка человеком — это способ принятия решений

Проверка человеком не должна считаться сбоем. Для некоторых задач это просто наилучшее окончательное решение. Кроме того, понятие «проверка человеком» охватывает несколько различных исходов.

Human
                   |
       +-----------+-----------+
       |           |           |
    Approve       Edit       Reject
       |           |           |
     Continue    Validate    Safe Fail

              Request Repair
                    |
                    v
                  Repair

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

2. Обучение на основе опыта из предыдущих запусков

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

run_completed
      |
      v
Evaluation worker
      |
      v
Gather feedback
      |
      v
Reflection
      |
      v
Candidate lesson

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

Отзывы — не истина

Сигналы поступают из разных источников: пользователь ставит оценку «низкая», эксперт исправляет ответ, внутренний API отклоняет транзакцию, а аудит соответствия обнаруживает ошибку спустя две недели. Все эти сигналы не равноценны. Рассмотрим первые пары случаев, когда равенство нарушается:

thumbs up != correct

thumbs down != incorrectuser correction != authoritative rule

Поэтому отзывы следует сохранять в качестве первоначальных доказательств и ранжировать по надежности примерно следующим образом:

Authoritative business outcome
          >
Expert human label
          >
Deterministic rule
          >
Calibrated evaluator
          >
User feedback
          >
Agent self-confidence

Это предотвращает путаницу между эмоциональными оценками и объективной правдой.

Лучшие отзывы часто поступают позже

Агенты часто запускают рабочие процессы, успех которых невозможно сразу оценить.

Agent recommends payroll code
        |
        v
Payroll system accepts
        |
        v
Two weeks later
        |
        v
Audit rejects transaction

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

Память требует регулирования

Как только агенты учатся в ходе нескольких запусков, память становится одновременно мощной и опасной. Стоит разделять три типа памяти.

• Профильная память хранит предпочтения пользователя или сущности, например предпочтение к кратким объяснениям.
• Эпизодическая память фиксирует события, произошедшие в процессе работы, например то, что запуск 182 провалился из-за отсутствия загрузки правил состояния.

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

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

Observation
     ↓
Candidate lesson
     ↓
Supporting evidence
     +
Counterexamples
     ↓
Validation
     ↓
Active lesson

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

Закрепленная в памяти информация не может превзойти авторитетные знания

Агенты извлекают два вида информации. Авторитетные знания включают политики, правила, конфигурации, справочные данные и договорные бизнес-правила. Закрепленные в памяти знания включают предпочтения, опыт, ранее применявшиеся стратегии, наблюдения и уроки. Они должны оставаться логически разделенными с четким порядком приоритетов:

Authoritative policy
        >
Tenant configuration
        >
Approved procedural lesson
        >
Episodic example
        >
User preference
        >
Unverified claim
        >
LLM reflection

В противном случае хорошо запомненный урок может тихо заменить собой действующую политику.

Уроки устаревают

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

candidate
   ↓
validated
   ↓
active
   ↓
pending revalidation
   ↓
deprecated
   ↓
retired

Укажите для каждого урока время подтверждения, а при необходимости — срок действия или правила повторной проверки. Изменение правил может стимулировать повторную оценку всех уроков, построенных на этих правилах, тем самым превращая «память» в упорядоченные знания, а не в набор постоянно растущих эмбеддингов.

3. Офлайн-режим обучения

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

Runs
+
User Feedback
+
Human Reviews
+
Downstream Outcomes
+
Evaluation Scores
        |
        v
Failure Classification
        |
        v
Failure Clustering

Предположим, что неделя пробежек показала такое распределение:

missing state policy        178
wrong tool selected          63
bad tool argument            52
unsupported inference        41
output schema failure        11

Теперь платформа может определять, какие проблемы носят системный характер. Это не то же самое, что просить отдельного неудачного агента проанализировать конкретную неудачную операцию. Механизм обучения выявляет закономерности.

Не каждая неудача связана с проблемой промпта

Инжиниринг промптов не всегда является решением. Если агент постоянно забывает загружать авторитетную политику перед тем, как что-то рекомендовать, добавление строки в системный промпт с просьбой запомнить это может помочь. Более эффективным решением может стать структурное правило:

Graph rule:
Policy retrieval must occur before this decision.

Другие частые сбои могут потребовать изменений в этих областях:

retrieval
tool schema
validator rule
routing
memory policy
clarification logic
action guard
model configuration

Зрелый двигатель улучшений предлагает несколько возможных вариантов исправлений и не переписывает запрос автоматически.

Оценка находится в центре

Если система может генерировать улучшения, но не может определить, являются ли они лучше, то отсутствует цикл обучения — есть только цикл мутаций. Оценка является основой этой архитектуры.

Correctness
Groundedness
Retrieval relevance
Completeness
Tool selection
Tool arguments
Trajectory efficiency
Repair effectiveness
Safety
Latency
Cost
Business outcome

Оценка должна включать итоговый ответ, а также путь, пройденный для его получения. Два агента могут дать одинаковый ответ. Агент А делает это следующим образом:

Agent A
search -> answer

пока Агент B делает это:

Agent B
search
-> wrong tool
-> retry
-> timeout
-> second search
-> repair
-> answer

Если судить только по окончательному ответу, они эквивалентны. Однако оценка траектории развития ответа показывает, что это явно не так.

Одного судьи в виде большой языковой модели недостаточно

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

Deterministic checks
+
Business outcomes
+
Human labels
+
Multiple evaluator rubrics
+
LLM judges

Оценщиков LLM также следует время от времени сравнивать с примерами, помеченными людьми. Это позволяет понять, в какой степени можно доверять оценщику, прежде чем его результаты повлияют на выбор тех уроков, которые будут рекомендованы.

Возможность наблюдения — часть процесса обучения

Традиционный мониторинг проверяет, работает ли сервис. Однако при оценке агента необходимо также выяснять, почему агент принял тот или иной решение. Хорошая производственная среда записывает весь ход выполнения LangGraph.

Agent Run
 |
 +-- Retrieve Context
 |
 +-- Planner
 |
 +-- Tool Call
 |
 +-- Tool Result Validator
 |
 +-- Repair
 |
 +-- Critic
 |
 +-- Final Answer

Каждая запись также должна иметь стабильный идентификатор, связывающий несколько записей воедино.

LangGraph execution
MongoDB events
Vertex AI calls
Evaluation results
Human feedback
Downstream outcomes

Эта корреляция является сырьем для цикла. Возможность наблюдения перестаёт быть лишь инструментом отладки и становится частью системы обучения.

Почему события с возможностью только добавления помогают

Желательно поместить всю траекторию выполнения в один документ операций MongoDB. Сначала это работает, но при масштабировании возникают проблемы. Лучше сохранять документ компактным.

run_id
agent
release
outcome
latency
tool count
repair count
cost

Затем записывайте выполнение в виде событий с возможностью только добавления данных.

run.started
retrieval.completed
tool.called
validation.failed
repair.started
human_review.requested
run.completed

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

Для воспроизводимости требуется нечто большее, чем просто версия промпта

Поведение агента зависит не только от его системного промпта.

model
generation settings
graph version
tool definitions
validator rules
critic rubric
retrieval configuration
memory rules
security rules

Поэтому каждая серия производства должна использовать неизменную версию агента. Концептуально:

agent_release_43
    |
    +-- graph v12
    +-- prompt v43
    +-- Gemini configuration
    +-- tools v17
    +-- validator v11
    +-- retrieval config v9
    +-- memory policy v5
    +-- evaluation suite v8

Неудачную попытку запуска можно затем воспроизвести позже. Без этого отладка сводится к вопросу о том, какая версия привела к определенному результату, после чего наступает молчание.

Плоскость управления: улучшения открывают доступ к производственной среде

В конечном итоге система анализа выявляет повторяющиеся сбои и разрабатывает способы их устранения. Самый плохой вариант — сразу же внедрять эти улучшения. Лучше сначала пройти через процедуры проверки:

Candidate Improvement
        |
        v
Historical Replay
        |
        v
Regression Evaluation
        |
        v
Shadow Production
        |
        v
Canary
        |
        v
Progressive Rollout
        |
        v
Production

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

Для уроков тоже нужны «канарейки»

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

Historical replay
     ↓
5% canary
     ↓
Measure outcome
     ↓
25%
     ↓
Measure
     ↓
100%

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

Итоговая архитектура

В совокупности платформа адаптивных агентов выглядит примерно так:

USER
                          |
                          v
+------------------------------------------------------+
|                    RUNTIME                           |
|                                                      |
| clarify -> retrieve -> plan -> action guard          |
|                            |                         |
|                            v                         |
|                           tool                       |
|                            |                         |
|                       sanitize                       |
|                            |                         |
|                      validate                        |
|                            |                         |
|                         reason                       |
|                            |                         |
|                    answer validate                   |
|                            |                         |
|                   critic if needed                   |
|                            |                         |
|                    policy router                     |
|                 /       |       \                    |
|              repair   human     pass                 |
+--------------------------+---------------------------+
                           |
                      agent events
                           |
                           v
+------------------------------------------------------+
|                    LEARNING                          |
|                                                      |
| traces + feedback + outcomes                         |
|            |                                         |
|            v                                         |
|         evaluate                                     |
|            |                                         |
|     classify failures                                |
|            |                                         |
|         cluster                                      |
|        /       \                                     |
|    lessons    improvement candidates                 |
+--------+----------------------+----------------------+
         |                      |
         v                      v
+------------------------------------------------------+
|                    CONTROL                           |
|                                                      |
| validate -> replay -> shadow -> canary -> rollout    |
|                                |                     |
|                              monitor                 |
|                                |                     |
|                             rollback                 |
+------------------------------------------------------+

Границы ответственности намеренно четко определены. Агент во время выполнения исправляет ошибки. Система обучения формирует гипотезы. Управляющий слой решает, какое поведение считать надежным.

Переосмысление понятия «самосовершенствующегося»

Услышав термин «агент, способный к самосовершенствованию», многие представляют себе ИИ, который переписывает свои системные инструкции или обновляется после каждого разговора. Для производственных систем это неверная картина. Лучше рассматривать процесс как цикл:

Observe
   ↓
Measure
   ↓
Diagnose
   ↓
Propose
   ↓
Test
   ↓
Promote
   ↓
Monitor

Интеллект здесь не ограничивается только LLM. Его распространяют различные компоненты системы:

• Граф LangGraph определяет порядок выполнения.
• Валидаторы обычного кода обеспечивают соблюдение уже известных правил.
• LLM решает все неоднозначные ситуации.
• MongoDB хранит состояние и накопленный опыт.
• Система трейсинга собирает необходимые доказательства.
• Оценщики определяют качество результата.
• Люди принимают решение, когда риск высок и ответ неясен.
• Плоскость управления контролирует любые изменения в поведении системы.

Такое распределение превращает агента в адаптивную систему агентов.

Разумный порядок создания

Никому не нужно создавать всю циклическую структуру сразу. Эффективная последовательность работы начинается с надежной реализации и отслеживания каждого запуска. Кроме того, используются механизмы контроля действий, проверка результатов и ответов, ограниченные способы устранения ошибок и человеческий аудит. Затем следует оценка качества: анализ записей, оценка и классификация сбоев, а также наличие набора данных для обнаружения регрессии. Опыт обучения вступает в игру только тогда, когда качество можно оценивать с уверенностью, что позволяет использовать кандидатов на улучшения, ограниченную память, агрегацию доказательств, механизмы контроля устаревания данных и отложенную обратную связь. Заключительным этапом является контролируемое улучшение, включающее группировку сбоев, генерацию кандидатов на изменения, оценку повторных запусков, имитацию трафика и поэтапное внедрение обновлений.

Порядок имеет значение:

Reliability
   ↓
Observability
   ↓
Evaluation
   ↓
Learning
   ↓
Controlled adaptation

Переход к концепции «самообучения» до проведения оценки обычно приводит к системе, которая меняется быстрее, чем инженеры могут за ней следить.

Цель

Никто не должен стремиться к агенту, способному самостоятельно вносить изменения. Лучшей целью является платформа, способная показать, когда агенту следует измениться. Одних лишь воспоминаний о предыдущих разговорах недостаточно, чтобы цикл заслуживал доверия. Для этого необходима строгая последовательность действий между этими этапами:

production behavior
        ↓
evidence
        ↓
evaluation
        ↓
learning
        ↓
experimentation
        ↓
controlled production change

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