# Умная эволюционная система EvoX и практика AI Native в научных исследованиях — материалы курса

Продолжительность занятия: 1 · Страниц презентации: 16

## Навигация по чтению

- [Занятие 6 | Тема: Системная непрерывная эволюция: Genesis и осаждение в мире программного обеспечения](#lecture-lesson-1)

---

<a id="lecture-lesson-1"></a>

## Занятие 6 | Тема: Системная непрерывная эволюция: Genesis и осаждение в мире программного обеспечения

<a id="lecture-page-1"></a>

### Системная непрерывная эволюция: Genesis и осаждение в мире программного обеспечения

*Страница 1*

> **Цель страницы:** Изучить, как Genesis через мультиагентное взаимодействие и строгие механизмы верификации позволяет коду проекта непрерывно накапливаться и эволюционировать на протяжении всего жизненного цикла.

> **Цель страницы**
>
> Как проект может не просто выполнить однократное написание кода, а обеспечить непрерывное накопление и эволюцию кода на протяжении всего жизненного цикла. Есть две ключевые линии: во-первых, инженерный паттерн, образованный мультиагентным взаимодействием и рекурсивной декомпозицией задач; во-вторых, механизм, посредством которого компиляция, тестирование и приёмка осаждают эффективные изменения в историю проекта.

**Ключевые тезисы**

- 1. Сначала обозначить смысл «непрерывной эволюции». Программное обеспечение — это не продукт, который застывает после написания, а сущность, которая со временем постоянно модифицируется, дополняется и рефакторится. Позиционирование Genesis как раз в том, чтобы предоставить работающий способ организации для такой долгосрочной эволюции, а не технику однократной генерации кода. 2. Мультиагентное взаимодействие решает вопрос «кто распределяет работу». Перед лицом реального проекта масштаб задач часто превышает возможности однократной обработки, поэтому необходимы ролевое разделение и процесс взаимодействия, чтобы обязанности на разных этапах были чёткими и отслеживаемыми. 3. Рекурсивная декомпозиция задач решает вопрос «как приступить». Крупная цель послойно разбивается на выполнимые малые задачи до тех пор, пока каждая подзадача не станет достаточно конкретной, чтобы её можно было independently выполнить и проверить. Это снижает сложность отдельного шага и позволяет оценивать результат каждого шага отдельно. 4. Строгая верификация решает вопрос «почему это засчитывается». Успешная компиляция, успешное тестирование, успешная приёмка — это три последовательно ужесточающихся барьера. Только изменения, прошедшие эти барьеры, имеют право быть записанными в историю проекта
- Не прошедшие изменения отбрасываются или отправляются на доработку. Взаимодействие и декомпозиция порождают множество кандидатных изменений, верификация отвечает за отбор, отобранные результаты осаждаются в историю проекта, а история проекта становится отправной точкой следующего раунда эволюции. Это и есть полный контур «системной непрерывной эволюции».

**Проверка понимания**

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

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

<a id="lecture-page-2"></a>

### Границы возможностей больших моделей и необходимость системной эволюции

*Страница 2*

> **Цель страницы:** Понять текущие границы возможностей больших моделей в разработке сложных систем и необходимость построения непрерывно развивающихся систем.

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

> **Порядок изложения**
>
> Большая модель — это мощный интеллектуальный компонент, но не самоподдерживающаяся система. Она уже обладает пригодными к использованию способностями в понимании, генерации, рассуждении и вызове инструментов и может выступать в качестве качественного генератора гипотез и производителя кода; однако ей не хватает состояния, целей и механизмов обратной связи, необходимых для непрерывной эволюции на протяжении жизненного цикла.
>
> Понимание, генерация, рассуждение, вызов инструментов — в итоге получается статический снимок, при завершении сессии состояние обнуляется. Справа большая модель встроена как малый модуль в системный эволюционный контур: предложение, оценка, выбор, осаждение. Большая модель отвечает за предложение; суррогатная модель используется для снижения стоимости оценки; этап выбора обрабатывает многокритериальные компромиссы; осаждение формирует межсессионную память; коллективный интеллект поддерживает разнообразие кандидатов и возвращается к следующему раунду предложения.
>
> Граница состояния — ограниченное контекстное окно, отсутствие межсессионной долговременной памяти, долгосрочный проект не может поддерживать себя; граница целей — реальные задачи часто включают многокритериальные конфликты и компромиссы предпочтений, модель не может самостоятельно дать обоснованные критерии выбора; граница обратной связи — отсутствие исполняемых механизмов оценки, выбора и отсева, сгенерированные решения не могут быть объективно проверены и итеративно сохранены.
>
> Рост возможностей модели не равен росту возможностей системы. Возможности — это снимок, среда — это процесс. Только встраивая большую модель в эволюционный контур «генерация — оценка — выбор — осаждение», поддерживая разнообразие коллективным интеллектом, сжимая стоимость оценки суррогатными моделями, сохраняя эффективный опыт через выбор и осаждение, интеллект может сохранять адаптивность в динамической среде. Это и есть точка опоры EvoX.

**Ключевые тезисы**

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

**Обработка упражнений**

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

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

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

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

**Проверка понимания**

Попросите студентов своими словами объяснить, «почему рост возможностей модели не равен росту возможностей системы», и назвать как минимум два из трёх типов границ: состояния, целей, обратной связи. Если студент может ясно объяснить связь от единичной возможности к эволюции через контур, можно переходить к следующей странице; если нет — вернуться к сравнительной схеме и заново разобрать два маршрута: левый и правый.

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

<a id="lecture-page-3"></a>

### Расширение границ эволюции от числовых параметров к программным системам

*Страница 3*

> **Цель страницы:** Освоить, как большие модели расширяют объект эволюции от традиционных числовых параметров к программам, структурам моделей и состояниям систем.

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

> **Порядок изложения**
>
> Объект обычно представляет собой низкоразмерный, предопределённый вектор числовых параметров, таких как гиперпараметры, веса, непрерывные переменные; пространство поиска ограничено вручную заданной структурой и способом кодирования.
>
> После расширения вычислительных масштабов и инженерной базы поиск высокоразмерных, дискретных, структурированных объектов из неосуществимого стал обрабатываемым, границы поиска расширяются синхронно с вычислительными мощностями и инструментальной цепочкой.
>
> Обладание способностями к пониманию кода, контекстному рассуждению и генерации кандидатов позволяет напрямую конструировать, модифицировать и оценивать объекты программного уровня, снижая зависимость от ручного проектирования кодирования и операторов мутации.
>
> Если метод генерации кандидатов по-прежнему фиксирован вручную, система будет лишь повторять заданный шаблон; включение самого метода генерации кандидатов в объект эволюции, например стратегии мутации и настройки параметров дифференциальной эволюции, как раз и является проявлением расширения границ.
>
> Снизу вверх: числовые параметры → структура модели → алгоритмический механизм → программное и программно-инженерное состояние; вверх по уровням размерность пространства поиска и семантическая сложность возрастают; справа — поддержка возможностей больших моделей; сверху — ограничения исполняемой верификации и инженерных затрат.
>
> Чем выше уровень, тем сильнее семантические ограничения, тем длиннее цепочка оценки, кандидаты должны быть исполняемыми и проверяемыми; оценка приспособленности превращается из скалярной функции в совместное суждение результатов выполнения и инженерных ограничений.
>
> Это не замена оптимизации параметров, а включение оптимизации параметров в более крупный цикл эволюции программ и систем, формируя непрерывный спектр от локальной настройки параметров до системного улучшения.

**Ключевые тезисы**

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

**Покрытие ключевых слов**

- Числовые параметры, структура модели, алгоритмический механизм, программное и программно-инженерное состояние, границы поиска, понимание кода, контекстное рассуждение, конструирование кандидатов, исполняемая верификация, инженерные затраты, оценка приспособленности, непрерывный спектр. Обработка упражнений и обратная связь: Большие модели расширяют объект эволюции от традиционных числовых параметров к программам, структурам моделей и состояниям систем. При отклонении — предложить вернуться к концептуальному предложению и попробовать снова. Большие модели способны понимать код и контекст выполнения и на этой основе конструировать и модифицировать сложные кандидаты программного уровня
- Ошибочные варианты часто ограничивают большие модели числовыми параметрами, кодируемыми вручную. Правильное направление упражнений 3, 4, 5 — не заучивание, не опора на ощущения и не одновременное изменение всех факторов, а умение объяснить соответствующие выводы доказательствами или примерами. В обратной связи можно подчеркнуть: только умение связать концепции страницы и обосновать ответ считается настоящим освоением. Команда сначала настраивает только числовые гиперпараметры: скорость обучения, размер батча, число слоёв сети
- Затем позволяет большой модели прочитать обучающий скрипт и журналы выполнения, напрямую переписать реализацию оптимизатора, конвейер данных и управляющий поток алгоритма, после чего передать кандидатов на исполнение во время выполнения и вернуть метрики для следующего раунда эволюции программного уровня. Можно спросить: в чём основная мысль? Каковы два условия, движущие расширение? Ключевые пункты ответа: традиционная эволюция использует в качестве объекта низкоразмерный вектор числовых параметров, пространство поиска ограничено ручными предустановками
- Расширение вычислительных мощностей и инженерной базы делает высокоразмерный, дискретный, структурированный поиск обрабатываемым
- Большие модели способны конструировать и переписывать объекты программного уровня, поэтому объект эволюции послойно расширяется до структур моделей, алгоритмических механизмов и программных или программно-инженерных состояний. Затем спросить: как большие модели участвуют в конструировании и оценке кандидатов программного уровня? Ключевые пункты ответа: читают скрипты и контекст выполнения, переписывают оптимизатор или управляющий поток, генерируя исполняемых кандидатов
- Во время выполнения проверяется, работает ли код, затем результат сравнивается с инженерными ограничениями по ресурсам и временному бюджету, а метрики возвращаются для управления следующей эволюцией.

**Проверка понимания**

Попросите студентов своими словами воспроизвести цепочку расширения уровней и дополнить её справа возможностями больших моделей, а сверху — ограничениями верификации и затрат. Можно задать дополнительный вопрос: «Почему чем выше уровень, тем больше оценка приспособленности похожа на совместное суждение результатов выполнения и инженерных ограничений?» Убедитесь, что студент может назвать причины: исполняемость, проверяемость, удлинение цепочки оценки.

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

<a id="lecture-page-4"></a>

### Сложные вызовы реального мира: многокритериальные компромиссы и поддержание разнообразия

*Страница 4*

> **Цель страницы:** Понять сложные взаимосвязанные цели в реальных задачах и важность сохранения разнообразных кандидатных решений.

**Ключевые тезисы**

- При многокритериальности нет естественного полного порядка. Видя набор кандидатов, сначала спросите «при каких предпочтениях сравниваем», а затем говорите о преимуществах и недостатках; иначе легко принять личные предпочтения за объективный вывод.
- Сохранение только текущего оптимума приводит к преждевременной сходимости популяции и коллапсу паттернов. Можно использовать механизмы crowding distance, нишинга, внешнего архива, чтобы кандидаты распределялись по разным областям фронта, покрывая больше интервалов компромиссов.
- Алгоритм отвечает за генерацию различающихся доступных вариантов, эксперты предметной области — за оценку и выбор на основе предпочтений и ограничений. Не следует смешивать «генерацию кандидатов» и «принятие решений за человека».

Цель страницы

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

Порядок изложения

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

Серые точки обозначают возможные решения, цветные точки — взаимно недоминируемые кандидаты, вместе они образуют фронт. На рисунке A смещён к прочности, B — сбалансированный, C — к эффективности, D — с крайне низким сопротивлением. Фронт Парето можно только приблизить, но нельзя устранить.

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

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

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

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

Ключевые тезисы

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

Обработка упражнений

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

Руководство по кейс-исследованию

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

Проверка понимания

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

Подсказка для перехода

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

<a id="lecture-page-5"></a>

### Тензоризованные вычисления и поддержка параллельного исследования в единой архитектуре

*Страница 5*

> **Цель страницы:** Понять, как EvoX использует пакетные тензорные вычисления для поддержки интенсивного параллельного эволюционного исследования.

> **Цель страницы**
>
> Понять, как EvoX использует пакетные тензорные вычисления для поддержки интенсивного параллельного эволюционного исследования, и усвоить две взаимно поддерживающие линии: тензоризованный вычислительный граф и открытая развязанная единая архитектура.
>
> Рекомендуемый порядок изложения:
>
> Когда популяция расширяется с десятков до тысяч и десятков тысяч, ключевая проблема эволюционных вычислений перестаёт быть «можно ли найти хорошее решение» и становится «можно ли за ограниченное время оценить достаточно много кандидатов». Разнообразие зависит от пропускной способности, поддержание разнообразия по сути является задачей вычислительной мощности.
>
> Тензоризованные вычисления отвечают за «быстро считать», единая архитектура — за «легко заменять».
>
> Традиционный последовательный цикл на CPU выполняет «оценку — запись — обновление» по особям, что порождает три типа издержек: высокие накладные расходы на планирование, фрагментация операторов, недостаточная загрузка GPU; тензоризованный подход организует поддержание популяции, пакетную оценку и обновление состояния целиком как пакетные тензорные операции, позволяя вычислять параллельно кандидатов одного или даже нескольких поколений. Например, при N кандидатных решениях последовательный подход — это цикл по одному, тензоризованный — это организация популяции в тензор, одновременное выполнение пакетной оценки и параллельного обновления состояния, что снижает накладные расходы на планирование и повышает загрузку GPU.
>
> Переписать только цикл недостаточно: если алгоритм, задача и логика планирования связаны, при смене алгоритма или задачи потребуется переписывание. Единая архитектура развязывает алгоритм, задачу, рабочий процесс, планирование Runtime и в сочетании с гетерогенным планированием вычислительных ресурсов обеспечивает пакетное управление задачами на уровне CPU/GPU, позволяя переиспользовать один и тот же механизм параллелизма в сценариях эволюции методов, таких как MetaDE, AutoPSO.
>
> Слева — традиционный последовательный цикл на CPU, поочерёдная обработка особей, низкая загрузка GPU; справа — пакетные тензорные вычисления на GPU: тензор популяции → пакетная оценка → параллельное обновление состояния; внизу — открытая развязанная единая основа, включающая алгоритм, задачу, рабочий процесс, планирование Runtime.

**Ключевые тезисы**

- EvoX не только решает задачи, но и включает сам метод генерации кандидатных решений в объект эволюции. В MetaDE внешний алгоритм эволюционирует конфигурацию и стратегии внутреннего алгоритма, AutoPSO и EvoGO дополнительно комбинируют компоненты и используют историческую обратную связь для изучения способов генерации кандидатов, переходя от «изменения параметров» к «изменению структуры алгоритма». Такая двухуровневая эволюция внутреннего и внешнего контуров естественно требует массовой пакетной оценки и обновления состояния внутренних задач. Она изменяет форму организации вычислений, превращая весь путь «популяция — оценка — обновление» в пакетные тензорные операции, а не заменяет какой-то оператор или способ кодирования. Если профилирование производительности показывает «слишком много мелких операторов, низкая загрузка GPU, высокая доля планирования CPU», это обычно означает, что система всё ещё работает в последовательном цикле по особям — это сигнал для внедрения тензоризованного вычислительного графа. Только тензоризация, при смене алгоритма или задачи потребуется переписывание
- Только единая архитектура без пакетного параллелизма всё равно не даст ускорения.

**Обработка упражнений**

Суть тензоризации — переписать поддержание популяции, пакетную оценку и обновление состояния как пакетные тензорные операции; основные издержки традиционного последовательного цикла на CPU — высокие накладные расходы на планирование, фрагментация операторов, недостаточная загрузка GPU; открытая развязка единой архитектуры нужна для переиспользования механизма параллелизма в разных алгоритмах и задачах; при N кандидатных решениях одного поколения ключевая выгода — одновременное выполнение пакетной оценки и параллельного обновления состояния; база, созданная GPU и большими моделями, поднимает пакетные вычисления с уровня локальной оптимизации до базовой способности системного эволюционного исследования. Обратная связь при ответах должна направлять студентов к двум ключевым словам: «пакетный параллелизм» и «развязанное переиспользование», избегая ошибочного выбора таких отвлекающих вариантов, как «сжатие популяции», «приближённая оценка», «фиксированный рабочий процесс».

Кейс-задание требует перенести дифференциальную эволюцию с однопоточной последовательной обработки на пакетную параллельную основу. Ключевые пункты ответа на вопрос 1: последовательная обработка по особям даёт высокие накладные расходы на планирование, фрагментацию операторов, недостаточную загрузку GPU; тензоризация смягчает это, организуя популяцию в тензор, объединяя пакетную оценку и обновление состояния, при этом семантика мутации, скрещивания и отбора остаётся неизменной. Ключевые пункты ответа на вопрос 2: единая архитектура разделяется на уровень алгоритма, уровень задачи, уровень рабочего процесса, уровень планирования Runtime;
уровень алгоритма описывает только семантику генерации и обновления кандидатов, уровень задачи инкапсулирует интерфейс пакетной оценки, уровень рабочего процесса организует внутренние и внешние задачи, уровень планирования Runtime отвечает за гетерогенное планирование вычислительных ресурсов и пакетное управление задачами, что позволяет переиспользовать одну основу в сценариях эволюции методов, таких как MetaDE, AutoPSO.

**Проверка понимания**

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

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

<a id="lecture-page-6"></a>

### Эволюция самого алгоритма: от решения задачи к улучшению метода

*Страница 6*

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

**Ключевые тезисы**

- Внутренний уровень ищет ответ, внешний уровень изменяет метод. Если видите, что «стратегии, параметры, операторы, компоненты помещены в поиск» — это эволюция метода; если видите, что «меняются только кандидатные решения, а правила генерации始终 неизменны» — это традиционный эволюционный алгоритм.
- Сигнал предпочтений сначала поступает в оценку ответа, затем проходит кросс-задачную агрегацию и проверку стабильности, и только после этого допускается к выбору метода. Пропустив этот шаг, внешний уровень будет гнаться за приятным, но невоспроизводимым результатом.
- Насколько велико пространство методов? Сколько раз за раунд нужно запускать внутренние задачи? На каком независимом наборе задач проверять, что улучшение внешнего уровня действительно обобщается? Если эти три вопроса не прояснить, двухуровневый поиск легко вырождается в более дорогую случайную настройку параметров.

Цель страницы

Традиционные эволюционные алгоритмы ищут в рамках фиксированного механизма генерации, оптимизируется всегда кандидатное решение; эволюция метода включает сам метод генерации кандидатных решений в объект поиска, завершая эволюцию от «решения задачи» к «улучшению метода».

Порядок изложения

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

2. Ввести определение эволюции метода и объяснить, что EvoX продвигается по этому пути, включая сам метод генерации кандидатов в объект эволюции.

Внутренний уровень ищет ответ, внешний уровень изменяет метод.

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

5. Привести MetaDE, AutoPSO и EvoGO как типичные формы.

6. Завершить выгодами и издержками, обработать упражнения и кейс.

Ключевые тезисы

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

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

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

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

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

MetaDE позволяет внешнему уровню эволюционировать стратегию мутации и параметры дифференциальной эволюции, внутренний уровень как обычно решает задачи; AutoPSO и EvoGO дополнительно комбинируют компоненты роя частиц, используют историческую обратную связь для изучения способов генерации кандидатов, осуществляя переход от «изменения параметров» к «изменению структуры алгоритма».

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

Подсказки к упражнениям и руководство по ответам

1. По сравнению с традиционным эволюционным алгоритмом, в чём самое существенное различие эволюции метода в «оптимизируемом объекте»? Правильное направление: включить в объект поиска сами стратегии, параметры и компоненты операторов, отвечающие за «как генерировать ответ». Если студент выбирает «больший размер популяции» или «отмену оценки приспособленности», предложите вернуться к смещению объекта оптимизации: оптимизируется уже не только ответ, а механизм, порождающий ответ.

Обратная связь от качества решений, сигналов предпочтений, стабильности или стоимости, поступающая от результатов внутренних задач. Если студент ошибочно выбирает «случайный шум» или «вручную заданный инженером», направьте его к вопросу: на каком основании внешний уровень судит, что одна стратегия лучше другой? Это «на каком основании» и есть сигнал обратной связи.

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

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

5. Что верно относительно MetaDE и AutoPSO? Правильное направление: MetaDE использует внешний уровень для эволюции стратегии мутации и параметров дифференциальной эволюции, внутренний уровень по-прежнему отвечает за решение кандидатов конкретных задач. AutoPSO и EvoGO идут дальше к комбинированию компонентов и улучшению на структурном уровне, направление — от изменения параметров к изменению структуры.

Обработка кейса

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

Вход внутреннего уровня — текущий метод (стратегия мутации и конфигурация параметров) и экземпляр конкретной задачи размещения, выход — кандидатное размещение и качество его решения. Вход внешнего уровня — агрегированная статистика результатов внутренних задач, выход — обновлённая стратегия и конфигурация параметров. Сигнал обратной связи должен агрегироваться кросс-задачно и кросс-повторно, например среднее по нескольким задачам, квантили или показатели стабильности, и не может браться из одного запуска. Причина в том, что качество отдельного решения сильно зависит от конкретного экземпляра и случайности; оно измеряет «хорош ли этот ответ», а не «хорош ли этот метод»; если напрямую управлять внешним уровнем по единичному результату, внешний уровень будет зависеть от различий экземпляров и шума.

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

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

Проверка понимания и переход

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

<a id="lecture-page-7"></a>

### MetaDE и AutoPSO: двухуровневая архитектура эволюции методов

*Страница 7*

> **Цель страницы:** Освоить, как MetaDE и AutoPSO через внутреннюю и внешнюю двухуровневую оптимизацию осуществляют автоматическую эволюцию вариантов алгоритмов и параметров.

> **Цель страницы**
>
> Понять, как MetaDE и AutoPSO через внутреннюю и внешнюю двухуровневую архитектуру оптимизации осуществляют автоматическую эволюцию конфигурации и структуры алгоритма, и освоить структуру издержек и инженерные компромиссы.

> **Порядок изложения**
>
> Алгоритм больше не просто ищет решение, он должен улучшать «то, как он сам ищет решение».
>
> 2. Показать общую абстракцию внутренней и внешней двухуровневой архитектуры, подчеркнув, что внешний уровень ищет в пространстве алгоритмов, внутренний решает целевую задачу, результаты внутреннего уровня возвращаются как сигнал приспособленности, формируя замкнутый контур.
>
> 3. Отдельно объяснить два пути реализации MetaDE и AutoPSO, указав, что первый управляет уровнем конфигурации, второй — уровнем структуры/компонентов.
>
> 4. Проанализировать мультипликативный эффект издержек двухуровневой оптимизации,引出 распределение бюджета, приближённую оценку, раннюю остановку, параллелизацию и другие инженерные компромиссы.
>
> Переход от ручного проектирования единого алгоритма к проектированию эволюционируемого пространства алгоритмов и механизма оценки.

**Ключевые тезисы**

- Эволюция метода (Meta-Evolution) делает «метод, порождающий кандидатов» самим объектом оптимизации. Внешний уровень ищет конфигурацию алгоритма, комбинацию компонентов или стратегию, а не решение задачи. Внешний уровень отвечает за поиск в пространстве алгоритмов (гиперпараметры, стратегии, комбинации компонентов — «определение алгоритма»)
- Внутренний уровень использует кандидатный алгоритм для реального решения целевой задачи, получая измеримый результат
- Результаты внутреннего уровня агрегируются в приспособленность и возвращаются внешнему уровню, внешний уровень отсеивает некачественные конфигурации, сохраняет и мутирует качественные, формируя контур непрерывного улучшения. Сохраняется дифференциальная эволюция как внутренний решатель, а собственная конфигурация DE передаётся внешнему поиску — стратегия мутации, вероятность скрещивания, масштабирующий фактор и т. д. адаптивно настраиваются в зависимости от задачи и этапа оптимизации. Это отвечает на вопрос «как настроить эту конфигурацию на текущем этапе задачи», относясь к эволюции метода на уровне конфигурации. Ключевые параметры и механизмы обучения PSO рассматриваются как комбинируемые компоненты — инерционный вес, коэффициенты обучения и различные сочетания механизмов индивидуального и группового обучения, автоматически ищутся и комбинируются внешним уровнем в варианты PSO, адаптированные к разным задачам. Это превращает «выбор алгоритма» в «поиск структуры алгоритма», осуществляя переход от адаптации параметров к самогенерации механизмов. MetaDE склоняется к автоматической настройке на уровне конфигурации и гиперпараметров, AutoPSO — к автоматической комбинации на уровне структуры и компонентов, вместе они покрывают диапазон эволюции от адаптации параметров до самогенерации механизмов. Ключевая издержка двухуровневой оптимизации — мультипликативный эффект: каждая оценка кандидатного алгоритма на внешнем уровне часто требует многократных внутренних запусков (повторная оценка из-за случайности, совместная проверка на нескольких задачах и т. д.), вычислительный бюджет значительно увеличивается. Фактический объём вычислений примерно равен «количество кандидатных алгоритмов внешнего уровня × число внутренних запусков на каждого кандидата». Распределение бюджета, приближённая оценка, ранняя остановка, параллелизация. Эффективное выполнение зависит от тензоризованного параллелизма, планирования Runtime и комбинируемости алгоритмов
- Параллелизация смягчает реальное время, но не уменьшает общий объём вычислений. Исследователь поставляет уже не фиксированный алгоритм, а набор правил поиска и обратной связи, позволяющий алгоритму непрерывно самосовершенствоваться.

**Проверка понимания**

Можно последовательно задать вопросы и дать ключевые пункты ответов:

1. Что является непосредственным объектом поиска внешнего уровня?

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

2. Какую группу объектов в основном эволюционирует внешний уровень в MetaDE?

Стратегию мутации, вероятность скрещивания и масштабирующий фактор дифференциальной эволюции. MetaDE позволяет конфигурации DE адаптивно настраиваться в зависимости от задачи и этапа, относясь к эволюции метода на уровне конфигурации/гиперпараметров, а не к структуре других алгоритмов.

3. Какое описание разделения труда между AutoPSO и MetaDE наиболее точно?

AutoPSO акцентирует автоматическую комбинацию параметров и механизмов обучения, превращая «выбор алгоритма» в «поиск структуры алгоритма»; MetaDE акцентирует эволюцию на уровне конфигурации. Они дополняют друг друга: MetaDE покрывает уровень конфигурации и гиперпараметров, AutoPSO — уровень структуры и компонентов, вместе они образуют диапазон эволюции от адаптации параметров до самогенерации механизмов, и оба должны проходить внутреннюю оценку.

4. Что верно относительно структуры издержек двухуровневой оптимизации?

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

5. Каково когнитивное преобразование роли исследователя после принятия двухуровневой архитектуры эволюции метода?

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

**Обработка упражнений**

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

Объясните, за что отвечают внутренний и внешний уровни и как движется сигнал.

Внешний уровень ищет кандидатные алгоритмы в пространстве алгоритмов — может эволюционировать стратегию мутации, вероятность скрещивания, масштабирующий фактор DE (путь MetaDE), а также автоматически комбинировать инерционный вес, коэффициенты обучения и механизмы обучения PSO (путь AutoPSO). Внутренний уровень запускает каждый кандидатный алгоритм на целевой задаче дня и оценивает его, выдавая сравнимый результат; результаты внутреннего уровня агрегируются в приспособленность и возвращаются внешнему уровню, внешний уровень на этой основе отсеивает некачественных кандидатов, сохраняет и мутирует качественные конфигурации, непрерывно итерируя, формируя контур «внешний уровень ищет пространство алгоритмов, внутренний решает целевую задачу, обратная связь по результатам управляет улучшением».

Перед лицом бюджетного давления «одна внешняя оценка требует многократных внутренних запусков» приведите как минимум две компромиссные меры и объясните издержки или риски.

① Распределение бюджета — установить вычислительные квоты отдельно для внешнего и внутреннего уровней и ограничить число внутренних повторов, издержка — рост дисперсии оценки, возможен ошибочный выбор; ② Приближённая оценка — оценивать приспособленность на подмножестве данных или коротких запусках, издержка — сильный шум сигнала, лучший кандидат может быть недооценён; ③ Ранняя остановка — досрочно прекращать внутренние запуски для явно некачественных кандидатов, издержка — возможное преждевременное отсеивание медленно раскрывающихся конфигураций с хорошими поздними результатами; ④ Тензоризованный параллелизм и планирование Runtime — пакетные параллельные внутренние запуски значительно смягчают реальное время, но не уменьшают общий объём вычислений и ограничены памятью и накладными расходами планирования. Ответ должен показать соответствие между каждой мерой и её издержкой или риском, а также отразить мультипликативную оценку «масштаб внешнего поиска × число внутренних запусков на каждого кандидата».

Язык обратной связи:

Правильно. Этот ответ связывает концепции страницы и обосновывает ответ.

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

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

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

<a id="lecture-page-8"></a>

### Практический кейс многокритериального проектирования сверхкритического профиля

*Страница 8*

> **Цель страницы:** Научиться использовать EvoX для работы со сложными инженерными ограничениями и генерации разнообразных компромиссных решений в проектировании профиля.

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

> **Порядок изложения**
>
> Проектирование сверхкритического профиля — это многокритериальная практика EvoX в реальной инженерии. Параметры формы профиля — кривизна, толщина, задняя кромка — взаимосвязаны, изменение формы одновременно влияет на несколько аэродинамических показателей.
>
> Улучшение одного показателя часто происходит за счёт другого, поэтому нельзя обрабатывать как однокритериальную оптимизацию, необходимы многокритериальные компромиссы.
>
> Требования к подъёмной силе, углу атаки, толщине и т. д. ограничивают допустимую область проектирования, поиск должен вестись при соблюдении ограничений, чтобы гарантировать инженерную пригодность кандидатных решений.
>
> EvoX генерирует набор разнообразных кандидатных решений, учитывающих различные показатели, а не единственное оптимальное решение; набор кандидатов позволяет экспертам предметной области сравнить различные выгоды и издержки и сделать выбор.
>
> Этот кейс превращает реальную сложную задачу в исследуемый и оцениваемый процесс, находя объяснимые компромиссные решения в условиях конфликта ограничений и целей.

**Ключевые тезисы**

- Изменение формы сверхкритического профиля влияет на несколько аэродинамических показателей, между целями часто существуют конфликты, необходимы многокритериальные компромиссы. Проект должен удовлетворять нескольким строгим ограничениям: подъёмная сила, угол атаки, толщина; поиск должен вестись в допустимой области проектирования. Генерация разнообразных кандидатных решений помогает экспертам оценить различные выгоды и издержки и сделать выбор. Сначала непрерывное исследование в пространстве параметров профиля (кривизна, толщина, задняя кромка), затем приближение к многокритериальному фронту компромиссов (показатель A и показатель B), в итоге формируется набор кандидатных решений. Сверхкритический профиль, многокритериальные компромиссы, допустимая область проектирования, набор кандидатных решений, EvoX.

> **Подсказки к упражнениям**
>
> - Корень многокритериальной задачи, роль ограничений, практический результат EvoX, значение разнообразных кандидатов, ценность метода. Правильное понимание должно сводиться к: параметры формы одновременно влияют на несколько показателей, вызывая конфликт целей
> - Ограничения задают допустимую область проектирования
> - Выход — набор разнообразных кандидатных решений
> - Разные кандидаты представляют разные выгоды и издержки
> - Ценность метода в превращении реальной сложной задачи в исследуемый и оцениваемый процесс.

**Обработка упражнений**

Если студент ошибочно выбирает «нужно оптимизировать только подъёмную силу» или «найти единственное оптимальное решение», напомните вернуться к взаимосвязи параметров формы и конфликту целей.

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

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

Правильно, этот ответ связывает концепции страницы и обосновывает ответ.

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

**Аудиторная активность**

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

**Проверка понимания**

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

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

<a id="lecture-page-9"></a>

### Вызовы跨 жизненного цикла: исчерпание контекста и проектное持久化

*Страница 9*

> **Цель страницы:** Понять противоречие между ограничениями контекста больших моделей и реальными инженерными проектами, длящимися месяцами или годами.

**Ключевые тезисы**

- Единичный контекст — это рабочий стол, репозиторий проекта — это долговременная память. Не оставляйте состояние популяции, неудачные конфигурации и обоснования решений только в окне сессии; перед закрытием сессии следует записывать их в проектные артефакты, а следующая сессия сначала читает их и продолжает.
- Наследуемая持久化 требует, чтобы артефакты были версионируемыми, доступными для поиска, объяснимыми: код, тесты, записи экспериментов, журналы решений, метрики оценки и выводы приёмки должны отвечать на вопросы, почему выбрано именно так, что уже провалилось, какие конфликты ещё остаются.
- Верхний Agent декомпозирует цели, нижний Agent реализует и тестирует. Перед завершением каждой сессии устанавливается контрольная точка: обновление журнала решений и метрик оценки; при запуске новой сессии сначала наследуется контрольная точка, затем определяются локальные действия, что позволяет пересекать несколько ограниченных жизненных циклов.

> **Цель страницы**
>
> Понять противоречие между ограничениями контекста Agent большой модели и реальными инженерными проектами, длящимися месяцами и даже годами, и обосновать необходимость проектного持久化. Ключевое суждение: контекстное окно одной сессии C最大 — ограниченный ресурс, жизненный цикл проекта Tпроект может длиться месяцами и даже годами, поэтому Tпроект ≫ C最大. Настоящая трудность не в недостатке способностей однократного рассуждения, а в том, что опыт не может пересекать жизненный цикл Agent.
>
> Порядок изложения
>
> Контекст одного Agent может вместить только текущую цель, локальные наблюдения и недавние рассуждения; после закрытия сессии состояние обнуляется, временные выводы и опыт становятся недоступны. При отсутствии持久化 последующие сессии могут только повторять исследование.
>
> Проектное持久化. Превратить неудачные конфигурации, процесс компромиссов, кандидатные решения и выводы приёмки во внешние непрерывно существующие проектные артефакты, включая код, тесты, записи экспериментов, журналы решений, метрики оценки и выводы приёмки. Последующие Agent не должны начинать с нуля, а читают предыдущий опыт, определяя, какие направления уже проверены, какие конфликты не решены, какие показатели уже достигнуты.
>
> Объект эволюции больше не только единичные числовые параметры или кандидатные решения, а непрерывно существующий, версионируемый, наследуемый мир программного обеспечения. Новые артефакты каждой сессии изменяют состояние этого мира, следующая сессия продолжает эволюцию в обновлённом мире, поэтому процесс оптимизации становится проектной непрерывной эволюцией.
>
> Несколько Agent с ограниченными жизненными циклами могут работать совместно: верхний исполнитель понимает цель и декомпозирует задачи, нижний исполнитель выполняет локальную реализацию и тестирование, при необходимости продолжает рекурсивную декомпозицию. Перед закрытием записывается ключевое состояние, после запуска нового Agent сначала читается проектная память, затем определяются локальные действия.
>
> Долгосрочные проекты часто имеют конфликты целей, например производительность, стоимость, робастность трудно оптимизировать одновременно; обратная связь также может быть разреженной, один эксперимент может требовать ожидания часов или даже дней.持久化 журналы решений и метрики оценки могут превратить разреженную обратную связь в наследуемый опыт, избегая повторения ошибок последующими Agent.
>
> Ключевые тезисы
>
> Единичный контекст — это рабочий стол, репозиторий проекта — это долговременная память. Не оставляйте состояние популяции, неудачные конфигурации и обоснования решений только в окне сессии; перед закрытием сессии следует записывать их в проектные артефакты, а следующая сессия сначала читает их и продолжает.
>
>持久化 — это не накопление логов. Наследуемая持久化 требует, чтобы артефакты были версионируемыми, доступными для поиска, объяснимыми: код, тесты, записи экспериментов, журналы решений, метрики оценки и выводы приёмки должны отвечать на вопросы, почему выбрано именно так, что уже провалилось, какие конфликты ещё остаются.
>
> Перед завершением каждой сессии обновлять журнал решений и метрики оценки; при запуске новой сессии сначала наследовать контрольную точку, затем определять локальные действия, что позволяет пересекать несколько ограниченных жизненных циклов.
>
> Проектная непрерывная эволюция — это перенос процесса генерации кандидатов, оценки кандидатов, записи компромиссов и выводов приёмки из контекста единичного Agent в проектные持久化 артефакты, что позволяет проекту непрерывно итерироваться через несколько жизненных циклов Agent.
>
> Подсказки к упражнениям
>
> Следует выбрать «контекстное окно ограничено, и после закрытия сессии состояние и опыт не могут быть использованы». В обратной связи подчеркнуть: жёсткая граница — в ограниченной длине и обнулении состояния после закрытия сессии, а не в размере параметров, степени параллелизма или целевой функции.
>
> Следует выбрать «код, тесты, записи экспериментов, журналы решений, метрики оценки и выводы приёмки». В обратной связи объяснить, что эти артефакты вместе образуют проектную память.
>
> Следует выбрать «расширение от единичных числовых параметров/кандидатных решений до непрерывно существующего, версионируемого, наследуемого мира программного обеспечения». В обратной связи различить изменение парадигмы обучения и изменение границ объекта эволюции.
>
> Следует выбрать «верхний уровень понимает цель и декомпозирует задачи, нижний выполняет локальную реализацию и тестирование, при необходимости рекурсивно декомпозирует». В обратной связи подчеркнуть, что непрерывность跨 жизненного цикла обеспечивается проектным持久化.
>
> Следует выбрать «после закрытия каждой сессии состояние популяции, неудачные конфигурации и обоснования решений теряются, последующие Agent повторяют исследование». В обратной связи объяснить, что отсутствие持久化 не решает автоматически конфликты целей и не расширяет контекст.
>
> При правильном ответе можно похвалить за «умение связать концепции страницы и обосновать ответ»; при ошибке попросить студента вернуться к изложению на этой странице, найти ключевые доказательства или примеры и затем судить.
>
> Обработка упражнений
>
> Цели включают аэродинамическую эффективность, прочность конструкции и стоимость производства, три из них конфликтуют, обратная связь моделирования разрежена, команда хочет, чтобы несколько Agent с коротким жизненным циклом работали последовательно. Первый вопрос требует объяснить, почему нельзя хранить проектную память только в единичном контексте, и перечислить как минимум три типа артефактов, подлежащих持久化. Ключевые пункты ответа: контекстное окно одной сессии ограничено и после закрытия сессии состояние обнуляется, а проект длится месяцами, Tпроект ≫ C最大; опора только на единичный контекст приведёт к потере состояния популяции, результатов моделирования, неудачных конфигураций, конфликтов показателей и обоснований решений; следует持久化 как минимум код и скрипты обучения суррогатных моделей, записи тестов и метрик оценки, записи экспериментов и неудачные конфигурации, журналы решений и обоснования компромиссов, кандидатные решения и выводы приёмки.
>
> При запуске сессии сначала читаются журнал решений, метрики оценки, записи экспериментов и кандидатные решения, восстанавливается состояние популяции и нерешённые конфликты; в ходе сессии записываются новые суррогатные модели, результаты моделирования, оценки кандидатов и анализ компромиссов; перед закрытием обновляется журнал решений, записываются неудачные конфигурации текущего раунда, конфликты показателей, причины отказа и рекомендации на следующий шаг, и всё это версионируется; последующие сессии через чтение этих артефактов наследуют неудачные конфигурации и обоснования решений, избегая повторного исследования.

**Проверка понимания**

Попросите студентов своими словами резюмировать, «почему проектную память нельзя хранить только в контексте единичного Agent», и назвать как минимум три типа проектных持久化 объектов. Подсказка для перехода: убедившись, что студент может назвать ключевое соотношение данной страницы — Tпроект ≫ C最大, проектное持久化 превращает опыт во внешний наследуемый мир программного обеспечения — переходите к следующей странице с примерами, применениями или итогами.

<a id="lecture-page-10"></a>

### Архитектура Genesis и парадигма осаждения в мире программного обеспечения

*Страница 10*

> **Цель страницы:** Освоить, как Genesis позволяет коду проекта непрерывно накапливаться и эволюционировать跨 жизненного цикла.

> **Цель страницы**
>
> Помочь студентам понять, как Genesis перепривязывает интеллект от изменчивого процесса сессии к накапливаемому миру программного обеспечения, позволяя коду проекта и инженерным результатам непрерывно накапливаться, эволюционировать и наследоваться跨 отдельного контекстного окна и отдельного жизненного цикла.

> **Порядок изложения**
>
> Сначала выдвинуть критерий «сессия изменчива, репозиторий — это долговременная память», затем последовательно развернуть сущностные различия парадигмы осаждения, разделение труда четырёх типов осаждаемых активов, предпосылку стабильности интерфейсов, контур осаждения и контроль приёмки, наследование跨 жизненного цикла, и в заключение одной фразой обозначить границу разделения труда между EvoX и Genesis.

**Ключевые тезисы**

- 1. Чтобы судить, обладает ли работа ценностью осаждения, задайте только один вопрос — может ли следующий человек воспроизвести её, не задавая вам ни одного вопроса? Если нет, она ещё не стала активом. Диалоговые рабочие процессы испаряются с окончанием контекста, результат остаётся в «этой сессии»
- Мир программного обеспечения использует репозитории, версии и артефакты как среду и естественно обладает накопительным свойством. Genesis как раз формализует эту среду в слой долговременной памяти эволюционной системы; он помнит не диалоги, а проверенные инженерные результаты. Код управляет «может ли работать», метод управляет «как выбирать», состояние управляет «где мы находимся», доказательства управляют «почему этому верить». Код несёт исполняемую способность, это непосредственно запускаемый и воспроизводимый процесс решения
- Метод несёт решения об алгоритмах и стратегиях, например выбор конфигурации двухуровневой эволюции и способ комбинации компонентов
- Состояние несёт проектный контекст и память выполнения, фиксируя текущий прогресс, ограничения и известные границы
- Доказательства несут записи экспериментов и выводы приёмки, отвечая, почему результату можно доверять. Без любого из четырёх осаждение становится невоспроизводимым или ненаследуемым: только код без доказательств — выводам нельзя доверять
- Только метод без состояния — наследник не знает, откуда продолжать. Поэтому четыре типа активов должны фиксироваться комплектно, а не разрозненно. 3. Предпосылка осаждения — стабильность интерфейсов. Только когда границы модулей и контракты относительно стабильны, новые результаты становятся активами
- Иначе каждое изменение затрагивает окружающие реализации, и осаждение быстро превращается в долг сопровождения. Это взаимно обусловлено с дизайном открытой развязанной основы Genesis: стабильные интерфейсы позволяют безопасно наследовать осаждение, развязка позволяет наследовать без переписывания истории. Зафиксировать контракты до осаждения часто ценнее, чем написать несколько дополнительных документов. Исследование → результат → строгая приёмка → фиксация как актив → непосредственное наследование в следующем раунде эволюции. Приёмка здесь — привратник осаждения: непроверенные результаты не входят в слой активов, что позволяет избежать фиксации шума, случайных явлений и ошибочных выводов как проектного «опыта». Без привратника осаждения репозиторий становится всё длиннее и всё менее заслуживающим доверия. 5. Ключ к наследованию跨 жизненного цикла — развязка активов от конкретных экземпляров выполнения, чтобы новые сессии, новые Agent, новые задачи могли восстанавливать проектное познание способом «чтения репозитория», не полагаясь на воспроизведение истории диалогов. Стоимость наследования снижается с «пересказа проекта заново» до «извлечения и загрузки», проектное познание больше не ограничено ёмкостью какого-либо контекстного окна. Genesis отвечает за «что осаждать, в какой форме осаждать, как наследовать»
- Мультиагентное взаимодействие и рекурсивная декомпозиция задач отвечают за «как производить результаты»
- Механизмы приёмки и наследования истории отвечают за «как результаты признаются достоверными». Только вместе эти три составляют полную способность проектной непрерывной эволюции — без любого звена проект может только повторяться на месте.

**Покрытие ключевых слов**

- Genesis, проектная непрерывная эволюция, системная архитектура EvoX, код/метод/состояние/доказательства, привратник приёмки, наследование跨 жизненного цикла. Данная страница организована вокруг «схемы трёхуровневой архитектуры Genesis и контура осаждения», слева сверху вниз: слой активов (код·метод·состояние·доказательства), механизм осаждения (версионирование·шлюз приёмки·поиск и наследование) и EvoX Runtime (тензоризованный параллелизм·гетерогенные вычисления·модули алгоритмов)
- Справа кольцевая диаграмма показывает контур: исследование, результат, приёмка, фиксация, переиспользование, повторная эволюция, с пометкой «активы утолщаются с ростом жизненного цикла». Страница также содержит три подсказки: не путайте сессию с памятью, четыре типа активов незаменимы, нестабильные интерфейсы превращают осаждение в долг. При объяснении можно с помощью этой схемы предложить студентам воспроизвести контур по стрелкам, затем указать, что приёмка находится после результата и до фиксации.

> **Подсказки к упражнениям**
>
> - Страница содержит пять вопросов с выбором и один кейс. Вопрос 1 указывает на накапливаемый мир программного обеспечения (репозитории, версии и артефакты); если студент ошибочно выбирает контекстное окно, напомните вернуться к отправной точке «после окончания сессии ничего не остаётся»
> - Вопрос 2 проверяет соответствие обязанностей четырёх типов активов, правильный вариант — код несёт исполняемую способность
> - Вопрос 3 проверяет границу между активами и долгом сопровождения, правильный вариант — «границы модулей и контракты относительно стабильны», нужно подчеркнуть, что ключ не в объёме результата или новизне инструментов
> - Вопрос 4 проверяет привратника в контуре, правильный вариант — строгая приёмка
> - Вопрос 5 проверяет наследование跨 жизненного цикла, правильный вариант — «активы развязаны от экземпляров выполнения, новая сессия может восстановить проектное познание чтением репозитория». При правильном ответе похвалить за умение связать концепции страницы и обосновать ответ, при ошибке попросить вернуться к изложению, найти ключевые доказательства или примеры и затем судить. После завершения многокритериального исследования сверхкритического профиля у команды остаются работающая двухуровневая конфигурация MetaDE и скрипты обучения суррогатных моделей, определения метрик оценки, промежуточное состояние, покрывающее интервалы параметров профиля и ограничения геометрических режимов, а также выводы приёмки текущего раунда. Первый вопрос требует систематизировать активы по четырём категориям: код, метод, состояние, доказательства, и объяснить роль приёмки как привратника — только результаты, прошедшие строгую приёмку, допускаются в слой активов, четыре типа активов должны фиксироваться комплектно, без любого из них осаждение невоспроизводимо или ненаследуемо. Второй вопрос требует сравнить «воспроизведение истории диалогов» и «чтение репозитория»: первый зависит от контекстного окна, стоимость растёт линейно с проектом, при усечении диалога познание теряется
> - второй снижает стоимость наследования до извлечения и загрузки, результаты версионируемы, воспроизводимы, аудируемы, и стоимость повторных проб текущего раунда осаждается как отправная точка переиспользования в следующем раунде.

**Аудиторная активность**

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

**Проверка понимания**

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

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

<a id="lecture-page-11"></a>

### Инженерный паттерн мультиагентного взаимодействия и рекурсивной декомпозиции задач

*Страница 11*

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

**Ключевые тезисы**

- При декомпозиции задач в первую очередь спросите «что проверяемое должен сдать этот уровень», а не «какому Agent это передать». Когда результаты (наборы данных, интерфейсы, контрольные точки, отчёты об оценке) определены чётко, границы ответственности и иерархия проявляются сами.
- Точка остановки рекурсивной декомпозиции — не «разбить до минимума», а «разбить до исполняемого, проверяемого, завершаемого в рамках одного контекста одного Agent». Слишком поверхностная декомпозиция превышает возможности нижнего уровня, слишком глубокая — создаёт дополнительные затраты на координацию и передачу.
- Перекрытие обязанностей заставляет несколько Agent повторно реализовывать одно и то же и выдавать конфликтующие результаты. Закрепите границы чёткими определениями интерфейсов и критериями приёмки, одновременно договоритесь, что нижний уровень может решать сам, а что должен передавать на решение родительской задачи.

Цель страницы

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

Порядок изложения

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

Ключевые тезисы

1. Трёхуровневая структура и обязанности каждого уровня. Верхний исполнитель ориентирован на общую цель, отвечает на вопрос «что делать», выдаёт делегируемые подзадачи, ограничения и критерии приёмки; средний исполнитель принимает всё ещё слишком крупные подзадачи и продолжает рекурсивную декомпозицию, сводя рыхлую большую цель к стабильной иерархии задач; нижний исполнитель в границах ответственности выполняет локальную реализацию и тестирование, выдаёт проверяемые результаты и передаёт их вверх, формируя локальный контур. На схеме верхний Agent выделяет модули задач A, B, C, модуль B из-за чрезмерной тяжести продолжает разбиваться на подзадачи B1, B2, четыре листовых узла в итоге попадают к локальной реализации и тестированию нижних Agent.

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

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

Дерево задач и двусторонняя передача. Родительские и дочерние задачи образуют рекурсивное дерево задач. Вниз движется делегирование задач — цели, граничные ограничения и критерии приёмки; вверх движется сбор результатов — артефакты, доказательства верификации и нерешённые проблемы. Состоится ли взаимодействие, зависит от трёх вещей: чёткость иерархии задач, взаимная исключительность границ ответственности, явная договорённость о продуктах передачи (определения интерфейсов, наборы данных, тестовые примеры, контрольные точки). Без любого из них несколько исполнителей выродятся в повторный труд и конфликтующие результаты.

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

5. Инженерные подсказки. Условие остановки рекурсивной декомпозиции — не «разбить до минимума», а «разбить до исполняемого, проверяемого, завершаемого в рамках одного контекста одного исполнителя». Слишком поверхностная декомпозиция превышает возможности нижнего уровня, слишком глубокая — создаёт大量 затрат на координацию и потери при передаче. Можно сначала определить результаты, затем решить, кто их выполняет; нечёткие границы часто являются наибольшей издержкой взаимодействия.

Обработка упражнений

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

Правильный ответ — «понимать общую цель и декомпозировать её на делегируемые подзадачи и критерии приёмки». Если студент ошибается, напомните вернуться к позиционированию корневого узла — он выдаёт задачи и критерии приёмки, а не сам код.

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

Что будет, если есть только выдача задач? Что будет, если есть только сбор результатов? Объясните, что взаимодействие должно быть двусторонним.

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

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

Аудиторная активность

Кейс-исследование «Совместная поставка системы контроля качества интеллектуальной службы поддержки» подходит как групповое задание. Сначала попросите студентов нарисовать рекурсивное дерево задач: корневой узел отвечает за понимание общей цели и выдаёт три подзадачи A, B, C и критерии приёмки; модуль B средним уровнем продолжает разбиваться на B1, B2 с явным указанием интерфейсов между ними; листовые узлы — четыре типа рабочих единиц A, B1, B2, C. Затем попросите группы перечислить продукты передачи в обоих направлениях — вниз и вверх, например спецификации интерфейсов данных и очищенный набор диалоговых данных, словарь признаков и спецификации разметки, контрольные точки модели и отчёты о верификации, метрики оценки и конфигурации развёртывания, и объяснить, почему листовые узлы уже удовлетворяют условию остановки.

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

Проверка понимания

За что отвечает верхний уровень, при каких условиях продолжается рекурсия, какую информацию передают два направления — вниз и вверх. Если студент может одновременно назвать условие остановки и «сначала определить результаты, потом распределить труд», можно считать страницу освоенной.

Подсказка для перехода

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

<a id="lecture-page-12"></a>

### Строгая приёмка и механизм наследования истории

*Страница 12*

> **Цель страницы:** Освоить, как через компиляцию, тестирование и шлюз приёмки осаждать эффективные изменения в историю проекта.

> **Порядок изложения**
>
> Сначала одной фразой обозначить: «видя любую систему "автоматической генерации и автоматического улучшения", задайте три вопроса: каков по умолчанию статус продукта Agent (кандидат?), какие проверки нужно пройти для принятия (приёмка?), чьей основой он становится после принятия (базовая версия?). Разделив эти три вещи, общая логика механизма не запутается», затем в сочетании с примерами, схемами или ключевыми словами на странице объяснить, почему это важно.

**Ключевые тезисы**

- Каков по умолчанию статус продукта Agent (кандидат?), какие проверки нужно пройти для принятия (приёмка?), чьей основой он становится после принятия (базовая версия?). Разделив эти три вещи, общая логика механизма не запутается.
- Компиляция → тестирование → проверка поведения → приёмка верхнего уровня — это «спуск по возрастанию стоимости»: чем дешевле, тем раньше; чем дороже, тем позже. Запомните «дешёвое отсеивается первым, дорогое проверяется последним», и вы не будете тратить ресурсы верхнего ревью на массу мусорных кандидатов.
- Прохождение приёмки не равно тому, что стало действительно лучше. При недостаточном покрытии тестами или отсутствии проверки поведения шлюз пропустит вредные изменения. Выработайте две привычки: дополнить регрессионные примеры и определения допусков для ключевого поведения
- всегда сохранять наблюдаемые метрики и выборочную ручную проверку как последнюю линию защиты при неполноте стандартов.

Строгая приёмка и механизм наследования истории

11

AI999

Genesis и осаждение в мире программного обеспечения

На каком основании автоматически сгенерированные Agent изменения могут быть записаны в основную ветку проекта? Строгая приёмка и механизм наследования истории полностью развязывают генерацию и принятие — любой код, представленный Agent, является лишь кандидатным изменением (candidate patch) и должен сначала пройти набор шлюзов верификации, чтобы получить право считаться частью истории проекта.

Кандидатные изменения → четыре уровня шлюзов приёмки → разделение на основную ветку / отклонение. Очередь кандидатных изменений. Представлено Agent · по умолчанию не заслуживает доверия. Кандидат A ожидает проверки. Кандидат B ожидает проверки. Кандидат C ожидает проверки. Кандидат D ожидает проверки. ① Шлюз компиляции. Синтаксис и интерфейсы собираемы · наименьшая стоимость,最快ее отсеивание. ② Шлюз тестирования. Модульные/интеграционные тесты полностью зелёные · покрывают существующие контракты. ③ Шлюз проверки поведения. Семантическая согласованность · числовые допуски и эквивалентность. ④ Приёмка верхнего уровня. Производительность · ускорение · сопровождаемость. Отклонение · архив неудач · сохраняется как негативные образцы и диагностический материал · изолированное хранение, не загрязняет основную ветку · само отклонение является фильтрацией шума · избегает повторного исследования одного тупика. История основной ветки (монотонное накопление). Базовая версия v3 · наследуемая, прослеживаемая. Базовая версия v2. Базовая версия v1. Обратная связь наследования истории: принятая базовая версия становится отправной точкой для последующих Agent. Принцип кандидатности по умолчанию. Выход Agent по умолчанию рассматривается как недоверенный вход: по правам, хранению и ссылкам он строго изолирован от принятых версий, не может напрямую читать или записывать основную ветку и не может использоваться другими модулями как стабильная зависимость.

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

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

В сценариях с сильными ограничениями корректности, таких как рефакторинг компилятора и обновление научного ПО, этот механизм демонстрирует极高 надёжность и приносит значительное ускорение выполнения. Границы отказа. Полнота самих критериев приёмки становится новым узким местом: при недостаточном покрытии тестами или отсутствии проверки поведения шлюз пропустит изменения, «прошедшие приёмку, но фактически вредные». Поэтому необходимы наблюдаемые метрики и выборочная ручная проверка как страховка, а также непрерывное усиление регрессионных примеров и определений допусков.

В механизме строгой приёмки какой статус по умолчанию имеет код, представленный Agent?

Готовый продукт, самостоятельно признанный提交 сторона пригодным к использованию

Официальная версия, которую можно сразу слить в основную ветку

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

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

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

Непроверенный выход не должен иметь тот же статус, что и принятая версия.

Правильно. Этот ответ связывает концепции страницы и обосновывает ответ.

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

В каком порядке расположены четыре уровня шлюзов приёмки и каков замысел их дизайна?

По убыванию стоимости, приоритетное вложение ресурсов в самое дорогое верхнее ревью

По времени представления кандидатов, кто раньше, тот и проверяется

В случайном порядке для повышения разнообразия верификации

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

Дешёвые шлюзы отвечают за массовое отсеивание, дорогие шлюзы имеют дело лишь с небольшим числом качественных кандидатов.

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

От какого типа проблем в основном защищает проверка поведения (третий уровень шлюза)?

Недостаточное количество написанных модульных тестов

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

Синтаксические ошибки кода, из-за которых компиляция вообще невозможна

Чрезмерный объём хранилища, занимаемый историей основной ветки

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

Уровень компиляции отвечает за «можно ли собрать», уровень тестирования — за «удовлетворены ли контракты», проверка поведения关注ет более скрытый семантический дрейф.

Как следует понимать ценность кандидатных изменений, отклонённых шлюзом?

Следует полностью удалить, чтобы не занимать хранилище и не мешать последующим решениям

Следует напрямую записать в основную ветку как негативный контроль

Можно сохранить как архив неудач / негативные образцы для диагностики, дедупликации и предотвращения повторного исследования

Следует без изменений повторно提交ть до автоматического прохождения

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

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

Какая из следующих ситуаций наиболее вероятно позволит шлюзу приёмки пропустить изменение, «прошедшее приёмку, но фактически вредное»?

Недостаточное покрытие тестами или отсутствие проверки поведения, делающие сами критерии приёмки неполными

Приёмка верхнего уровня одновременно оценивает производительность, ускорение и сопровождаемость

В очереди кандидатных изменений одновременно присутствуют提交ы нескольких разных Agent

Архив неудач долго сохраняется для диагностики

Шлюз может остановить только то, что способен обнаружить; при неполноте критериев приёмки необходима страховка в виде наблюдаемых метрик и выборочной ручной проверки.

Риск часто исходит не от提交 стороны, а от слепых зон покрытия самих критериев приёмки.

Приёмка патча переписывания ядра компилятора

Прочитайте сценарий и ответьте на два следующих вопроса.

Некая команда с помощью мультиагентного взаимодействия рефакторит ядро компилятора. Agent X представил версию патча переписывания ядра, утверждая, что он может ускорить работу некоторого бенчмарка примерно в 1,4 раза. Система обрабатывает этот патч согласно «строгой приёмке и механизму наследования истории»: патч сначала попадает в очередь кандидатных изменений, затем последовательно проходит компиляцию, тестирование, проверку поведения и приёмку верхнего уровня; при прохождении записывается в основную ветку и становится отправной точкой для следующего поколения Agent, при неудаче попадает в изолированный архив неудач.

1. Опишите по порядку, какие проверки должен последовательно пройти этот патч, и объясните, почему приёмка верхнего уровня стоит последней.

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

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

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

Кандидат, приёмка, базовая версия

Каков по умолчанию статус продукта Agent (кандидат?), какие проверки нужно пройти для принятия (приёмка?), чьей основой он становится после принятия (базовая версия?). Разделив эти три вещи, общая логика механизма не запутается.

Порядок шлюзов запоминается как спуск

Компиляция → тестирование → проверка поведения → приёмка верхнего уровня — это «спуск по возрастанию стоимости»: чем дешевле, тем раньше; чем дороже, тем позже. Запомните «дешёвое отсеивается первым, дорогое проверяется последним», и вы не будете тратить ресурсы верхнего ревью на массу мусорных кандидатов.

Шлюз может остановить только то, что способен обнаружить

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

Шаг 1

Освоить, как через компиляцию, тестирование и шлюз приёмки осаждать эффективные изменения в историю проекта.

урок_6

урок_6_слайд_11

Из черновика EvoClass

> **Цель страницы**
>
> Освоить механизм осаждения эффективных изменений в историю проекта через компиляцию, тестирование и приёмку

**Ключевые тезисы**

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

**Ключевые тезисы**

- Строгая приёмка и механизм наследования истории
- Код, представленный Agent, является лишь кандидатным изменением и должен пройти компиляцию, тестирование, проверку поведения и приёмку верхнего уровня, прежде чем попасть в принятую версию проекта. Неудачные попытки могут быть отклонены, а прошедшие верификацию результаты становятся исторической основой для последующих исполнителей. В рефакторинге компилятора и обновлении научного ПО этот механизм демонстрирует极高 надёжность и ускорение выполнения. Строгая приёмка и механизм наследования истории
- Код, представленный Agent, является лишь кандидатным изменением и должен пройти компиляцию, тестирование, проверку поведения и приёмку верхнего уровня, прежде чем попасть в принятую версию проекта. lesson_id_distribution 86818163433546df25555ab4cb1c2d59fc1effedc37a25c4e84b74b7d294e704

**Источники материалов**

Из черновика EvoClass

> **Подсказки к материалам**
>
> - Освоить механизм осаждения эффективных изменений в историю проекта через компиляцию, тестирование и приёмку
> - Строгая приёмка и механизм наследования истории
> - Код, представленный Agent, является лишь кандидатным изменением и должен пройти компиляцию, тестирование, проверку поведения и приёмку верхнего уровня, прежде чем попасть в принятую версию проекта. Неудачные попытки могут быть отклонены, а прошедшие верификацию результаты становятся исторической основой для последующих исполнителей. В рефакторинге компилятора и обновлении научного ПО этот механизм демонстрирует极高 надёжность и ускорение выполнения.
> - Код, представленный Agent, является лишь кандидатным изменением и должен пройти компиляцию, тестирование, проверку поведения и приёмку верхнего уровня, прежде чем попасть в принятую версию проекта.

**Аудиторная активность**

Попросите студентов пересказать содержание этой страницы на примере, близком к их опыту, и объяснить связь этого примера с «видя любую систему "автоматической генерации и автоматического улучшения", задайте три вопроса: каков по умолчанию статус продукта Agent (кандидат?), какие проверки нужно пройти для принятия (приёмка?), чьей основой он становится после принятия (базовая версия?). Разделив эти три вещи, общая логика механизма не запутается».

> **Соответствующие цели**
>
> - Понять инженерный паттерн мультиагентного взаимодействия и рекурсивной декомпозиции задач
> - Освоить механизм осаждения эффективных изменений в историю проекта через компиляцию, тестирование и приёмку

**Проверка понимания**

Случайно выберите одного студента и попросите его своими словами резюмировать ключевые моменты страницы; преподаватель дополняет пропущенные ключевые слова по ответу.

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

<a id="lecture-page-13"></a>

### Аудиторная активность: имитация мультиагентного взаимодействия и автоматического шлюза приёмки

*Страница 13*

> **Цель страницы:** Углубить понимание мультиагентной совместной разработки и механизма автоматической приёмки через имитационное упражнение.

> **Цель страницы**
>
> Через однократное аудиторное имитационное упражнение понять разделение задач в мультиагентной совместной разработке, слияние кандидатных изменений и то, как автоматический шлюз приёмки перехватывает несоответствующие изменения;重点 — пройти инженерный контур «совместная разработка — автоматическая приёмка — наследование истории», а не позволить Agent обсудить между собой правильный ответ.

> **Порядок изложения**
>
> Разделите аудиторные группы на Agent планирования/декомпозиции, Agent реализации, Agent генерации тестов, Agent ревью/координации. Одна задача может породить несколько кандидатных изменений, которые затем единообразно рассматриваются шлюзом приёмки.
>
> Декомпозиция задач, параллельная реализация, автоматическая приёмка, наследование истории. Декомпозиция задач должна разбить цель на независимо проверяемые подзадачи, например «проверка интерфейса — исправление алгоритма — регрессионное тестирование»; на этапе параллельной реализации несколько Agent реализации提交ают кандидатные патчи, Agent тестирования генерирует граничные примеры; на этапе автоматической приёмки запускаются автоматические тесты, статические проверки и проверки контрактов, и шлюз выносит решение по исполняемым критериям; на этапе наследования истории прошедшие изменения сливаются в историческую базовую версию, отклонённые сохраняют причину неудачи и информацию для воспроизведения для повторной попытки.
>
> Слева — рекурсивная декомпозиция задач, в центре — кандидатные изменения нескольких Agent, справа — автоматические тесты и шлюз приёмки. Кандидаты сливаются и попадают в шлюз, при прохождении сливаются в историческую базовую версию, при отклонении возвращаются с воспроизводимой обратной связью, которая затем возвращается на этапы реализации и тестирования.
>
> Критерии должны быть исполняемыми и не могут оставаться на уровне «выглядит правильно».重点 — перехватывать изменения, не удовлетворяющие интерфейсным соглашениям, вносящие регрессии, не покрывающие граничные условия или нарушающие ограничения качества. Полезная обратная связь должна содержать как минимум неудачный пример, логи, шаги воспроизведения, ожидаемое поведение и соответствующие ограничения.
>
> После попадания прошедших изменений в базовую версию последующие Agent не должны начинать с нуля; отклонённые изменения становятся доступными для поиска негативными примерами, предотвращая повторение ошибок. При оценке следует关注ть, воспроизводимы ли правила приёмки, действенна ли обратная связь, а также различные риски ложного и пропущенного перехвата.
>
> Если шлюз отсутствует или стандарты размыты, мультиагентное взаимодействие не обязательно эффективнее, а может стать хаотичным из-за отсутствия единого решения; ценность автоматического контроля в том, что он заменяет субъективное утверждение воспроизводимыми доказательствами.

**Ключевые тезисы**

- Перед приёмкой сначала написать работающие тесты, контрактные утверждения и граничные примеры
- Если правило невоспроизводимо, оно не может стабильно перехватывать. Отклонённые кандидаты должны сопровождаться логами неудач, командами воспроизведения, ожидаемым поведением и соответствующими ограничениями, чтобы следующий Agent мог непосредственно локализовать и исправить. Слишком мелкая granularité декомпозиции повышает стоимость слияния и приёмки, слишком грубая — позволяет кандидатным изменениям перекрывать друг друга
- Предпочтительна декомпозиция на подзадачи, которые можно отдельно тестировать и принимать.

> **Подсказки к материалам**
>
> - Рекурсивная декомпозиция задач, кандидатные изменения нескольких Agent, автоматические тесты и шлюз приёмки. На схеме также обозначены «слияние кандидатов», «возврат обратной связи», «прохождение входит в базовую версию, отклонение возвращает воспроизводимую обратную связь», что подходит для объяснения контура с указанием на схему. Можно предложить студентам на примере «служба платежей падает при вводе отрицательного числа или слишком длинной строки» разработать набор исполняемых правил шлюза приёмки, покрывающих как минимум интерфейс, регрессию, границы и ограничения качества. Ориентир: на уровне интерфейса требовать отклонения отрицательных сумм и слишком длинных строк в поле суммы, возврата единого кода ошибки и контрактных утверждений
> - на уровне регрессии требовать прохождения всех существующих用例 успешного платежа, возврата и сверки без новых неудач
> - на уровне границ включить用例 с 0, отрицательным числом, максимально допустимой суммой, слишком длинной строкой, пустой строкой и специальными символами, утверждая отсутствие падения и объяснимость ошибки
> - ограничения качества включают прохождение статических проверок, покрытие ключевых путей не ниже согласованного порога, отсутствие高危-предупреждений. Все правила должны быть выражены в виде работающих тестов или скриптов и воспроизводиться в непрерывной интеграции.

> **Подсказки к упражнениям**
>
> - Ложный перехват тратит работу над правильными кандидатами и снижает эффективность взаимодействия, а также может подтолкнуть команду ослабить стандарты
> - Пропущенный перехват позволяет дефектам попасть в историческую базовую версию, последующие Agent продолжают работу на ошибочной базовой версии, усиливая риск регрессии. Способы снижения включают сохранение доказательств неудач, выборочную перепроверку результатов перехвата, осаждение новых неудачных用例 в регрессионный набор и комбинированный контроль рисков с помощью граничных用例, проверок контрактов и канареечной валидации.

**Проверка понимания**

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

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

<a id="lecture-page-14"></a>

### Рабочий подход AI Native и удобный вход

*Страница 14*

> **Цель страницы:** Узнать, как через лаконичный вход и конфигурацию быстро запускать эксперименты EvoX в AI-инструментах.

**Ключевые тезисы**

- Запомните эту линию разделения труда: вход AI Native отвечает за установку, базовую конфигурацию и проверку среды; вы отвечаете за определение задачи, выбор направления и критерии оценки. Вложите сэкономленное время в последнее, и выгода действительно попадёт в исследование, иначе вы просто перенесёте ожидание с этапа конфигурации на этап доработки.
- Ценность однофразовой команды в том, чтобы быстро войти в эксперимент, а не пропустить проверку. После установки активно подтвердите версию, зависимости и видимость GPU, воспринимайте сообщаемый инструментом статус как线索, а не как вывод, тогда последующие эксперименты будут иметь надёжную точку отсчёта.
- Перед воспроизведением на другой машине проверьте по пунктам: совпадают ли список зависимостей и версий, совпадают ли модель GPU и число доступных устройств, зафиксированы ли случайные seed и ключевые гиперпараметры. После прохождения трёх пунктов увеличивайте масштаб эксперимента, это позволит избежать ситуации, когда стоимость поздней диагностики намного превышает стоимость ранней конфигурации.

Цель страницы**

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

Ключевые тезисы**

1. Смещение входа — это определяющая характеристика. Традиционный путь — «изучить документацию → установить зависимости → настроить среду → написать каркас → только затем первый эксперимент», каждое звено может дать сбой, и при каждом переключении приходится заново выстраивать контекст. Путь AI Native — «однофразовая команда → инструмент берёт на себя установку и конфигурацию → проверка среды пройдена → вход в эксперимент». Меняется способ, которым человек начинает работу, а не сам объект оптимизации.

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

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

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

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

Подсказки к материалам**

Верхний ряд серым — четыре шага традиционного пути, внизу пометка «трение сосредоточено»; средний ряд синим — четыре шага пути AI Native, где «однофразовая команда» выделена, внизу пометка «трение перенесено»; нижний оранжевый блок — «границы позиционирования». При объяснении можно сразу спросить: какой отрезок убран на схеме, а какой оставлен? Подвести обучающихся к открытию — перенесены установка, базовая конфигурация и проверка среды, сохранены задача, направление и критерии оценки.

Обработка упражнений**

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

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

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

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

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

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

Аудиторная активность**

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

Проверка понимания**

«Если установка полностью передана инструменту, что вам нужно проверить вручную на следующий день?» Умение назвать проверку версии, зависимостей и видимости GPU считается освоением.

Подсказка для перехода**

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

<a id="lecture-page-15"></a>

### Ключевой вкус исследователя: разделение труда человек-машина и критическое мышление

*Страница 15*

> **Цель страницы:** Понять незаменимый научный вкус и критическое суждение исследователя в процессе эволюции с поддержкой AI.

> **Цель страницы**
>
> Понять незаменимый научный вкус и критическое суждение исследователя в процессе эволюции с поддержкой AI. Ключевой вопрос: когда AI значительно снижает стоимость «реализации ответа», куда смещается научная ценность?

**Ключевые тезисы**

- AI / EvoX могут быстро выполнить реализацию кода, пакетный запуск экспериментов, генерацию кандидатов, поиск параметров и запись обратной связи, инженерная стоимость больше не является ключевым узким местом. Исследователь решает, какая проблема заслуживает изучения, какой результат значим, каких доказательств достаточно для вывода. AI расширяет пространство реализации и поиска
- Исследователь контролирует определение задачи, конфликты целей, границы ограничений и критерии приёмки. Рассматривать выход AI как гипотезу, подлежащую проверке, проверять, состоятельна ли гипотеза, достаточны ли доказательства, учтены ли граничные условия, не проигнорированы ли негативные результаты, избегая введения в заблуждение гладкими, но непроверенными ответами. В условиях открытого исследования и разреженной обратной связи выбор направления нельзя передать AI
- Окончательное суждение и научная ответственность остаются за исследователем. Слева — AI / EvoX, соответствует генерации кандидатов, выполнению экспериментов, пространству поиска, записи обратной связи
- Справа — исследователь, соответствует постановке вопросов, оценке доказательств, взвешиванию компромиссов, рефлексии направления
- В центре — «Code is cheap. Taste matters». Внизу подпись «контур обратной связи: точки критической проверки», указывающая, что это не односторонний процесс, а цикл: AI выдаёт обратную связь человеку, человек переопределяет задачу и стандарты. В многокритериальных задачах оптимизации EvoX AI быстро генерирует大量 кандидатных решений и экспериментальный код. Исследователю нужно судить: отражает ли целевая функция реальные потребности? Справедлив ли baseline? Не упускают ли метрики ключевые ограничения? Если смотреть только на показатели, можно выбрать решение, кажущееся оптимальным, но не соответствующее реальным потребностям. Здесь «Code is cheap. Taste matters» проявляется так: AI отвечает за быструю реализацию и поиск, исследователь анализирует определение задачи и стандарты доказательств, судит, какие результаты действительно значимы.

**Обработка упражнений**

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

**Проверка понимания**

Попросите студентов своими словами различить «стоимость реализации» и «ценность суждения» и привести по одному этапу, который можно передать AI, и одному, который обязательно остаётся за исследователем. Если студент может ясно объяснить их связь, переходите к следующей странице.

<a id="lecture-page-16"></a>

### Итоги курса: построение инфраструктуры непрерывно эволюционирующего мира программного обеспечения

*Страница 16*

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

**Ключевые тезисы**

- Кандидатные решения, метод генерации кандидатов (например, внутренняя и внешняя конфигурация MetaDE), проектные активы — это три разных уровня. Перед проектированием или ответом сначала уточните фразу «какой уровень я сейчас оптимизирую», это поможет избежать смешения эволюции метода и проектной непрерывной эволюции.
- Только продукты, прошедшие строгую приёмку, допускаются в библиотеку опыта и наследуются. Как только непроверенный результат наследуется последующей задачей, ошибка усиливается вдоль цепочки наследования, и источник трудно локализовать.
- В начале каждой новой задачи спросите себя: какие проверенные продукты и записи опыта предыдущего раунда я непосредственно переиспользовал в этом раунде? Если ответ пуст, текущий процесс остаётся единичной задачей, а не непрерывно эволюционирующей инфраструктурой.

Цель страницы

Поднять «интеллектуальную эволюцию» с уровня однократного поиска, однократной оптимизации до инфраструктуры программного обеспечения, ориентированной на реальный мир.重点 не во введении нового алгоритма, а в том, чтобы студенты увидели, как система跨 отдельной задачи, отдельного Agent, опираясь на контур «задача — исследование — приёмка — наследование — повторная эволюция», остаётся открытой, надёжной и непрерывно связанной с реальными проблемами.

Ключевые тезисы

1. Обновление объекта эволюции. Genesis расширяет объект эволюции от кандидатных решений единичной задачи до проектной непрерывной эволюции跨 Agent и跨 циклов задач. Окончание одного запуска больше не обнуляет состояние, окончание задачи становится отправной точкой следующего раунда.

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

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