# Hệ thống tiến hóa thông minh EvoX và thực hành nghiên cứu khoa học AI Native - Giáo trình bài giảng

Thời lượng: 1 · Số trang bài giảng: 16

## Điều hướng đọc

- [Bài 6｜Chủ đề: Tiến hóa liên tục cấp hệ thống: Genesis và sự lắng đọng của thế giới phần mềm](#lecture-lesson-1)

---

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

## Bài 6｜Chủ đề: Tiến hóa liên tục cấp hệ thống: Genesis và sự lắng đọng của thế giới phần mềm

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

### Tiến hóa liên tục cấp hệ thống: Genesis và sự lắng đọng của thế giới phần mềm

*Trang 1*

> **Mục tiêu trang:** Tìm hiểu cách Genesis thông qua hợp tác đa Agent và cơ chế xác minh nghiêm ngặt, giúp mã nguồn dự án tích lũy và tiến hóa liên tục qua vòng đời.

> **Mục tiêu trang**
>
> Một dự án làm thế nào để không chỉ hoàn thành việc viết mã một lần, mà còn để mã nguồn tích lũy và tiến hóa liên tục trong suốt vòng đời. Có hai manh mối cốt lõi: một là mô hình kỹ thuật được cấu thành từ hợp tác đa Agent và phân rã nhiệm vụ đệ quy, hai là cơ chế biên dịch, kiểm thử và nghiệm thu để lắng đọng các thay đổi hiệu quả thành lịch sử dự án.

**Điểm giảng dạy chính**

- 1. Trước tiên chỉ ra ý nghĩa của "tiến hóa liên tục". Phần mềm không phải là sản phẩm viết xong là cố định, mà là thực thể được liên tục sửa đổi, bổ sung và tái cấu trúc theo thời gian. Định vị của Genesis chính là cung cấp một cách tổ chức có thể vận hành cho sự tiến hóa lâu dài này, chứ không phải là kỹ thuật sinh mã một lần. 2. Hợp tác đa Agent giải quyết vấn đề "ai phân công". Đối mặt với một dự án thực tế, quy mô nhiệm vụ thường vượt quá khả năng xử lý một lần, do đó cần có phân công vai trò, có quy trình hợp tác, để trách nhiệm của các khâu khác nhau rõ ràng và có thể truy vết. 3. Phân rã nhiệm vụ đệ quy giải quyết vấn đề "bắt đầu từ đâu". Chia mục tiêu lớn hơn thành các nhiệm vụ nhỏ có thể thực thi từng lớp, cho đến khi mỗi nhiệm vụ con đủ cụ thể, có thể được hoàn thành và kiểm tra độc lập. Điều này vừa giảm độ khó của từng bước, vừa cho phép đánh giá riêng kết quả của mỗi bước. 4. Xác minh nghiêm ngặt giải quyết vấn đề "dựa vào đâu để được tính là đúng". Biên dịch thành công, kiểm thử thành công, nghiệm thu thành công, là ba cửa ải siết chặt từng lớp. Chỉ những thay đổi vượt qua các cửa ải này mới có tư cách được ghi vào lịch sử dự án
- Những thay đổi không vượt qua sẽ bị loại bỏ hoặc làm lại. Hợp tác và phân rã tạo ra một lượng lớn thay đổi ứng viên, xác minh chịu trách nhiệm sàng lọc, kết quả sau sàng lọc lắng đọng thành lịch sử dự án, và lịch sử dự án lại trở thành điểm khởi đầu cho vòng tiến hóa tiếp theo. Đây chính là vòng tuần hoàn hoàn chỉnh của "tiến hóa liên tục cấp hệ thống".

**Kiểm tra hiểu biết**

Yêu cầu học sinh dùng lời của mình nói ra mối quan hệ thứ tự của ba yếu tố "phân rã—xác minh—lắng đọng", và trả lời: nếu một thay đổi vượt qua biên dịch nhưng không vượt qua kiểm thử, nó sẽ ở trạng thái nào trong cơ chế được mô tả ở trang này? Giáo viên dựa vào đó xác nhận liệu học sinh có thực sự hiểu vai trò của cửa ải xác minh, chứ không chỉ ghi nhớ thuật ngữ.

> **Gợi ý chuyển tiếp**
>
> Trang này thiết lập khung tổng thể, nội dung tiếp theo sẽ đi vào các phương pháp và ví dụ cụ thể hơn. Sau khi xác nhận học sinh có thể thuật lại vòng tuần hoàn này, hãy tiếp tục đi sâu vào các khâu cụ thể.

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

### Ranh giới năng lực của mô hình lớn và sự cần thiết của tiến hóa cấp hệ thống

*Trang 2*

> **Mục tiêu trang:** Hiểu ranh giới năng lực của mô hình lớn hiện tại trong phát triển hệ thống phức tạp và sự cần thiết của việc xây dựng hệ thống phát triển liên tục.

> **Mục tiêu trang**
>
> Hiểu ranh giới năng lực của mô hình lớn trong phát triển hệ thống phức tạp, và tại sao nhất thiết phải nhúng các thành phần thông minh vào vòng tuần hoàn hệ thống có thể tiến hóa liên tục qua vòng đời.

> **Trình tự giảng giải**
>
> Mô hình lớn là thành phần thông minh mạnh mẽ, nhưng không phải là hệ thống có thể tự duy trì. Nó đã có năng lực khả dụng trong hiểu, sinh, suy luận và gọi công cụ, có thể đóng vai trò người đề xuất giả thuyết và người sản xuất mã chất lượng cao; nhưng nó thiếu trạng thái, mục tiêu và cơ chế phản hồi cần thiết để tiến hóa liên tục qua vòng đời.
>
> Hiểu, sinh, suy luận, gọi công cụ, cuối cùng thu được ảnh chụp tĩnh, trạng thái trở về không sau khi phiên kết thúc. Phía bên phải là nhúng mô hình lớn như một mô-đun nhỏ vào vòng tuần hoàn tiến hóa cấp hệ thống: đề xuất, đánh giá, lựa chọn, lắng đọng. Mô hình lớn chịu trách nhiệm đề xuất; mô hình đại diện dùng để giảm chi phí đánh giá; khâu lựa chọn xử lý cân bằng đa mục tiêu; lắng đọng tạo thành ký ức xuyên phiên; trí tuệ bầy đàn duy trì tính đa dạng ứng viên, và quay lại vòng đề xuất tiếp theo.
>
> Ranh giới trạng thái—cửa sổ ngữ cảnh hữu hạn, thiếu ký ức bền vững xuyên phiên, dự án dài hạn không thể tự duy trì; ranh giới mục tiêu—vấn đề thực tế thường liên quan đến xung đột đa mục tiêu và cân bằng sở thích, mô hình khó tự đưa ra tiêu chí đánh đổi có thể biện hộ; ranh giới phản hồi—thiếu cơ chế đánh giá, lựa chọn và loại bỏ có thể thực thi, phương án được sinh ra không thể được xác minh khách quan và giữ lại qua lặp lại.
>
> Nâng cao năng lực mô hình không đồng nghĩa với nâng cao năng lực hệ thống. Năng lực là ảnh chụp, môi trường là quá trình. Chỉ khi nhúng mô hình lớn vào vòng tuần hoàn tiến hóa "sinh—đánh giá—lựa chọn—lắng đọng", duy trì đa dạng bằng trí tuệ bầy đàn, nén chi phí đánh giá bằng mô hình đại diện, giữ lại kinh nghiệm hiệu quả bằng lựa chọn và lắng đọng, thì trí tuệ mới có thể duy trì khả năng thích ứng trong môi trường động. Đây cũng là điểm tựa của EvoX.

**Điểm giảng dạy chính**

- Mô hình lớn có năng lực hiểu và sinh mạnh mẽ, nhưng không thể tiến hóa hệ thống một cách độc lập. Hệ thống phức tạp trong thế giới thực cần năng lực tiến hóa liên tục qua vòng đời, ảnh chụp tĩnh không đủ để ứng phó với thay đổi môi trường. Thành phần thông minh cần phối hợp với cơ chế tiến hóa mới có thể thích ứng với môi trường động, các cơ chế then chốt bao gồm vòng tuần hoàn tiến hóa, trí tuệ bầy đàn và mô hình đại diện. Ranh giới trạng thái, ranh giới mục tiêu, ranh giới phản hồi.

**Xử lý bài tập**

Câu hỏi khái niệm cốt lõi nên chọn "Hiểu ranh giới năng lực của mô hình lớn hiện tại trong phát triển hệ thống phức tạp và sự cần thiết của việc xây dựng hệ thống phát triển liên tục".

Các câu hỏi đúng/sai còn lại nên ưu tiên chọn phương án "có thể giải thích bằng bằng chứng hoặc ví dụ"; chỉ dựa vào cảm giác, bỏ qua tài liệu để học thuộc, hoặc đồng thời thay đổi tất cả các yếu tố để so sánh, đều không đáp ứng yêu cầu của trang này.

Khi trả lời đúng, có thể khẳng định học sinh có thể liên hệ với khái niệm trang này và giải thích căn cứ; khi trả lời sai, gợi ý quay lại phần giảng giải để tìm bằng chứng hoặc ví dụ then chốt, tập trung ôn lại ba loại ranh giới và vòng tuần hoàn "đề xuất—đánh giá—lựa chọn—lắng đọng".

Trước tiên giải thích ý chính là "mô hình lớn có năng lực hiểu và sinh mạnh mẽ nhưng không thể tiến hóa hệ thống một cách độc lập", sau đó lấy ví dụ giải thích tại sao hệ thống phức tạp cần năng lực tiến hóa liên tục qua vòng đời.

**Kiểm tra hiểu biết**

Yêu cầu học sinh dùng lời của mình giải thích "tại sao nâng cao năng lực mô hình không đồng nghĩa với nâng cao năng lực hệ thống", và chỉ ra ít nhất hai trong ba loại ranh giới: trạng thái, mục tiêu, phản hồi. Nếu học sinh có thể nói rõ mối quan hệ từ năng lực đơn thể đến tiến hóa vòng tuần hoàn, có thể chuyển sang trang tiếp theo; nếu không, quay lại sơ đồ so sánh để sắp xếp lại hai tuyến đường trái phải.

> **Gợi ý chuyển tiếp**
>
> Sau khi xác nhận học sinh có thể nói ra mối quan hệ cốt lõi "mô hình lớn là thành phần, vòng tuần hoàn tiến hóa mới là hệ thống", hãy tiếp tục đi vào nội dung về tiến hóa liên tục cấp hệ thống, Genesis và sự lắng đọng của thế giới phần mềm.

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

### Mở rộng ranh giới tiến hóa từ tham số số trị đến hệ thống chương trình

*Trang 3*

> **Mục tiêu trang:** Nắm vững cách mô hình lớn mở rộng đối tượng tiến hóa từ tham số số trị truyền thống sang chương trình, cấu trúc mô hình và trạng thái hệ thống.

> **Mục tiêu trang**
>
> Nắm vững cách mô hình lớn mở rộng đối tượng tiến hóa từ tham số số trị truyền thống sang chương trình, cấu trúc mô hình và trạng thái hệ thống, và hiểu điều kiện thúc đẩy cùng sự thay đổi đánh giá của việc mở rộng ranh giới này.

> **Trình tự giảng giải**
>
> Đối tượng thường là vector tham số số trị thấp chiều, được định nghĩa trước, như siêu tham số, trọng số, biến liên tục; không gian tìm kiếm được giới hạn bởi cấu trúc và cách mã hóa do con người đặt trước.
>
> Sau khi quy mô tính toán và nền tảng kỹ thuật mở rộng, việc tìm kiếm đối tượng đa chiều, rời rạc, có cấu trúc từ không khả thi trở thành có thể xử lý, ranh giới tìm kiếm mở rộng đồng bộ với năng lực tính toán và chuỗi công cụ.
>
> Có năng lực hiểu mã, suy luận ngữ cảnh và sinh ứng viên, có thể trực tiếp xây dựng, sửa đổi và đánh giá đối tượng cấp chương trình, giảm sự phụ thuộc vào toán tử mã hóa và đột biến do thiết kế thủ công.
>
> Nếu phương pháp sinh ứng viên vẫn do con người cố định, hệ thống chỉ lặp lại lối mòn đã định; đưa chính phương pháp sinh ứng viên vào đối tượng tiến hóa, ví dụ chiến lược đột biến và thiết lập tham số của tiến hóa vi phân, chính là biểu hiện của mở rộng ranh giới.
>
> Từ dưới lên trên là tham số số trị→cấu trúc mô hình→cơ chế thuật toán→trạng thái chương trình và kỹ thuật phần mềm; chiều không gian tìm kiếm và độ phức tạp ngữ nghĩa tăng dần lên trên; bên phải là năng lực mô hình lớn hỗ trợ; phía trên là ràng buộc xác minh có thể thực thi và chi phí kỹ thuật.
>
> Cấp càng cao, ràng buộc ngữ nghĩa càng mạnh, chuỗi đánh giá càng dài, ứng viên phải có thể thực thi và xác minh được; đánh giá độ thích nghi từ hàm vô hướng chuyển thành phán đoán kết hợp giữa kết quả vận hành và ràng buộc kỹ thuật.
>
> Đây không phải là thay thế tối ưu tham số, mà là đưa tối ưu tham số vào vòng tuần hoàn tiến hóa chương trình và hệ thống lớn hơn, hình thành phổ liên tục từ điều chỉnh tham số cục bộ đến cải tiến cấp hệ thống.

**Điểm giảng dạy chính**

- Quy mô tính toán mở rộng mang lại ranh giới tìm kiếm rộng hơn. Mô hình lớn có thể hiểu mã và ngữ cảnh và xây dựng ứng viên phức tạp. Đối tượng tiến hóa mở rộng từ tham số số trị sang trạng thái chương trình và kỹ thuật phần mềm, ở giữa đi qua cấu trúc mô hình và cơ chế thuật toán. Một là năng lực tính toán và nền tảng kỹ thuật mở rộng, hai là mô hình lớn có năng lực hiểu mã, suy luận ngữ cảnh và sinh ứng viên.

**Phạm vi từ khóa**

- Tham số số trị, cấu trúc mô hình, cơ chế thuật toán, trạng thái chương trình và kỹ thuật phần mềm, ranh giới tìm kiếm, hiểu mã, suy luận ngữ cảnh, xây dựng ứng viên, xác minh có thể thực thi, chi phí kỹ thuật, đánh giá độ thích nghi, phổ liên tục. Xử lý bài tập và phản hồi: Mô hình lớn mở rộng đối tượng tiến hóa từ tham số số trị truyền thống sang chương trình, cấu trúc mô hình và trạng thái hệ thống. Nếu trả lời lệch, gợi ý quay lại câu khái niệm rồi thử lại. Mô hình lớn có thể hiểu mã và ngữ cảnh vận hành, và dựa vào đó xây dựng, sửa đổi ứng viên phức tạp cấp chương trình
- Phương án sai thường giới hạn mô hình lớn trong tham số số trị được mã hóa thủ công. Hướng đúng của bài tập 3, 4, 5 không phải là học thuộc, dựa vào cảm giác hoặc đồng thời thay đổi tất cả các yếu tố, mà là có thể giải thích kết luận liên quan bằng bằng chứng hoặc ví dụ. Phản hồi có thể nhấn mạnh: có thể liên hệ với khái niệm trang này và giải thích căn cứ, mới được coi là thực sự nắm vững. Nhóm trước tiên chỉ điều chỉnh các siêu tham số số trị như tốc độ học, kích thước batch, số lớp mạng
- Sau đó để mô hình lớn đọc script huấn luyện và log vận hành, trực tiếp viết lại triển khai optimizer, pipeline dữ liệu và luồng điều khiển thuật toán, rồi đưa ứng viên cho runtime thực thi và trả về chỉ số, dùng cho vòng tiến hóa cấp chương trình tiếp theo. Có thể đặt câu hỏi: Ý chính là gì? Hai điều kiện thúc đẩy mở rộng là gì? Điểm trả lời chính: Tiến hóa truyền thống lấy vector tham số số trị thấp chiều làm đối tượng, không gian tìm kiếm bị giới hạn bởi đặt trước thủ công
- Năng lực tính toán và nền tảng kỹ thuật mở rộng, khiến tìm kiếm đa chiều, rời rạc, có cấu trúc có thể xử lý
- Mô hình lớn có thể xây dựng và viết lại đối tượng cấp chương trình, do đó đối tượng tiến hóa mở rộng từng lớp đến cấu trúc mô hình, cơ chế thuật toán và trạng thái chương trình hoặc kỹ thuật phần mềm. Hỏi tiếp: Mô hình lớn tham gia vào việc xây dựng và đánh giá ứng viên cấp chương trình như thế nào? Điểm trả lời chính: Đọc script và ngữ cảnh vận hành, viết lại optimizer hoặc luồng điều khiển để sinh ứng viên có thể thực thi
- Runtime thực thi và kiểm tra xem có thể chạy được không, rồi so sánh với các ràng buộc kỹ thuật như tài nguyên, ngân sách thời gian, chỉ số trả về thúc đẩy vòng tiến hóa tiếp theo.

**Kiểm tra hiểu biết**

Cho học sinh dùng lời của mình thuật lại chuỗi mở rộng phân cấp, và bổ sung năng lực mô hình lớn ở bên phải cùng ràng buộc xác minh và chi phí ở phía trên. Có thể hỏi thêm: "Tại sao cấp càng cao, đánh giá độ thích nghi càng giống phán đoán kết hợp giữa kết quả vận hành và ràng buộc kỹ thuật?" Xác nhận học sinh có thể nói ra lý do như có thể thực thi, có thể xác minh, chuỗi đánh giá dài hơn.

> **Gợi ý chuyển tiếp**
>
> Sau khi xác nhận học sinh có thể phân biệt mối quan hệ giữa tối ưu tham số và tiến hóa cấp chương trình hoặc hệ thống, hãy tiếp tục đi vào nội dung trang tiếp theo về hợp tác đa Agent và lắng đọng xác minh.

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

### Thách thức phức tạp trong thế giới thực: Cân bằng đa mục tiêu và duy trì đa dạng

*Trang 4*

> **Mục tiêu trang:** Hiểu tầm quan trọng của các mục tiêu phức tạp ràng buộc lẫn nhau trong vấn đề thế giới thực và việc giữ lại các phương án ứng viên đa dạng.

**Điểm giảng dạy chính**

- Dưới đa mục tiêu không có thứ tự toàn phần tự nhiên. Khi thấy một nhóm ứng viên, trước tiên hỏi "so sánh dưới sở thích nào", rồi mới bàn đến ưu liệt; nếu không dễ nhầm sở thích cá nhân thành kết luận khách quan.
- Chỉ giữ lại tối ưu hiện tại sẽ khiến quần thể hội tụ sớm, sụp đổ mô thức. Có thể dùng các cơ chế như khoảng cách chen chúc, ổ sinh thái nhỏ, lưu trữ ngoài, để ứng viên phân tán ở các vùng khác nhau trên biên, bao phủ nhiều khoảng cân bằng hơn.
- Thuật toán chịu trách nhiệm sinh ra các lựa chọn khả dụng có khác biệt, chuyên gia lĩnh vực chịu trách nhiệm hoàn thành đánh giá và đánh đổi dựa trên sở thích và ràng buộc. Không nên nhầm lẫn "sinh ứng viên" với "thay người ra quyết định".

Mục tiêu trang

Hiểu bản chất ràng buộc lẫn nhau của các mục tiêu trong vấn đề thế giới thực, và giải thích tại sao hệ thống nên giữ lại một nhóm phương án ứng viên có khác biệt, thay vì hội tụ về một "đáp án tối ưu" duy nhất.

Trình tự giảng giải

Vấn đề thực tế hiếm khi tồn tại nghiệm tối ưu duy nhất. Nhiều mục tiêu ràng buộc lẫn nhau, cải thiện một chỉ số thường phải trả giá bằng sự suy giảm của chỉ số khác. Do đó, hệ thống nên giữ lại một nhóm phương án ứng viên không bị chi phối có khác biệt, để mối quan hệ cân bằng hiển thị rõ ràng, để quyết định được giữ trong phán đoán của con người.

Điểm xám đại diện cho phương án khả thi, điểm màu đại diện cho ứng viên không chi phối lẫn nhau, chúng cùng tạo thành biên. Trong hình, A thiên về cường độ, B cân bằng, C thiên về hiệu quả, D cực thấp lực cản. Biên Pareto chỉ có thể được tiệm cận, không thể bị loại bỏ.

3. Triển khai bốn nhận thức then chốt. Thứ nhất, xung đột mục tiêu là mang tính cấu trúc, không phải vấn đề điều chỉnh tham số: giữa các mục tiêu như tỷ lệ lực nâng/lực cản, cường độ cấu trúc, chi phí, khả năng sản xuất không tồn tại đồng thời tối ưu. Thứ hai, dưới đa mục tiêu không có thứ tự toàn phần: hai phương án bất kỳ có thể không chi phối lẫn nhau, "tốt nhất" phải kèm theo hướng sở thích mới có thể định nghĩa; khi thấy một nhóm ứng viên, trước tiên hỏi "so sánh dưới sở thích nào", rồi mới bàn đến ưu liệt. Thứ ba, phản hồi thưa thớt là bình thường: đánh giá kỹ thuật thực tế phụ thuộc vào mô phỏng hoặc đo lường chi phí cao, phản hồi ít, nhiễu lớn, gradient không khả dụng, tìm kiếm leo đồi điểm đơn khó tiến triển hiệu quả; thuật toán tiến hóa thông qua duy trì quần thể, đồng thời khám phá nhiều hướng dưới ít đánh giá.

Chỉ theo đuổi tối ưu hiện tại sẽ khiến quần thể hội tụ sớm, sụp đổ mô thức, cuối cùng mất toàn bộ khoảng cân bằng chưa được khám phá; có thể dùng các cơ chế như khoảng cách chen chúc, ổ sinh thái nhỏ, lưu trữ ngoài, để ứng viên phân tán ở các vùng khác nhau trên biên.

Thuật toán chịu trách nhiệm "sinh ra một nhóm lựa chọn khả dụng có khác biệt", chuyên gia lĩnh vực chịu trách nhiệm "hoàn thành đánh giá và đánh đổi dựa trên sở thích và ràng buộc". Nhóm phương án ứng viên không phải là thay người đưa ra quyết định, mà là đặt các lựa chọn có thể so sánh lên bàn.

Trong thiết kế cánh siêu tới hạn, hiệu quả khí động, đặc tính phân kỳ lực cản, cường độ cấu trúc và chi phí sản xuất ràng buộc lẫn nhau. Giá trị của EvoX không nằm ở việc đưa ra "cánh tối ưu" duy nhất, mà ở việc xuất ra họ cánh ứng viên bao phủ các khoảng cân bằng khác nhau, để kỹ sư lựa chọn theo điều kiện bay cụ thể và ràng buộc công nghệ.

Điểm giảng dạy chính

Dùng hướng sở thích để định nghĩa "tốt nhất"; chủ động duy trì đa dạng; phân biệt sinh và đánh đổi. Dưới đa mục tiêu không có thứ tự toàn phần tự nhiên, chỉ giữ lại tối ưu hiện tại sẽ dẫn đến sụp đổ quần thể; thuật toán sinh ra ứng viên có khác biệt, chuyên gia hoàn thành phán đoán cuối cùng dựa trên sở thích và ràng buộc. Hai hình nhỏ bên phải trong hình đã trực quan trình bày sự khác biệt giữa hội tụ điểm đơn và phân bố đa dạng: cái trước sụp đổ thành một cụm, cái sau trải rộng thành biên.

Xử lý bài tập

Không có thứ tự toàn phần có nghĩa là hướng sở thích phải tham gia định nghĩa; phản hồi thưa thớt khiến tìm kiếm điểm đơn khó tiến triển vì đánh giá tốn kém, nhiễu lớn, gradient không khả dụng; giá trị của phân tán ứng viên là để lại quyền lựa chọn và kiến thức lĩnh vực cho chuyên gia; chỉ theo đuổi tối ưu hiện tại sẽ dẫn đến hội tụ sớm và sụp đổ mô thức; trong thiết kế cánh siêu tới hạn, định vị của EvoX là xuất ra họ cánh ứng viên bao phủ các khoảng cân bằng khác nhau. Khi phản hồi nếu học sinh chọn sai, có thể hướng dẫn quay lại ba từ khóa "hướng sở thích", "phản hồi thưa thớt", "đa dạng là tài sản".

Hướng dẫn nghiên cứu tình huống

Trong kịch bản taxi hàng không đô thị, có thể nhận diện xung đột giữa tầm bay và tải trọng hữu ích, xung đột giữa tiếng ồn và hiệu quả khí động, xung đột giữa dự phòng an toàn và chi phí sản xuất. Các mục tiêu này ràng buộc lẫn nhau, do đó không tồn tại thiết kế đơn nhất đồng thời tối ưu, chỉ tồn tại biên Pareto không chi phối lẫn nhau. EvoX có thể lấy tầm bay, tải trọng hữu ích, tiếng ồn, dự phòng an toàn, chi phí làm đa mục tiêu, chạy tìm kiếm quần thể, xuất ra các phương án ứng viên phân bố ở các vùng khác nhau trên biên, không chi phối lẫn nhau; chuyên gia lĩnh vực lại dựa trên kịch bản vận hành, ràng buộc pháp quy và điều kiện công nghệ, thực hiện mô phỏng độ trung thực cao hoặc đo lường thực tế trên các phương án ứng viên, hoàn thành đánh giá và đánh đổi cuối cùng dựa trên hướng sở thích.

Kiểm tra hiểu biết

Yêu cầu học sinh dùng lời của mình lấy một ví dụ đa mục tiêu hàng ngày, ví dụ cân bằng giữa hiệu năng, giá cả, trọng lượng và thời lượng pin khi mua laptop, và trả lời "so sánh dưới sở thích nào". Nếu học sinh có thể giải thích cùng một nhóm ứng viên sẽ cho ra các lựa chọn hợp lý khác nhau dưới sở thích khác nhau, thì cho thấy đã hiểu cốt lõi trang này.

Gợi ý chuyển tiếp

Sau khi xác nhận học sinh có thể phân biệt "sinh ứng viên" và "thay người ra quyết định", hãy tiếp tục đi vào nội dung trang tiếp theo về cải tiến phương pháp tính toán hoặc cải tiến phương pháp. Trang này trả lời "tại sao cần cân bằng đa mục tiêu và ứng viên đa dạng", nội dung tiếp theo sẽ lần lượt trả lời "làm thế nào tính nhanh hơn" và "làm thế nào cải tiến chính phương pháp".

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

### Hỗ trợ khám phá song song của tính toán tensor hóa và kiến trúc thống nhất

*Trang 5*

> **Mục tiêu trang:** Hiểu cách EvoX sử dụng tính toán tensor theo lô để hỗ trợ khám phá tiến hóa song song cường độ cao.

> **Mục tiêu trang**
>
> Hiểu cách EvoX sử dụng tính toán tensor theo lô để hỗ trợ khám phá tiến hóa song song cường độ cao, và nắm bắt hai tuyến chính hỗ trợ lẫn nhau: đồ thị tính toán tensor hóa và kiến trúc thống nhất mở, tách rời.
>
> Gợi ý trình tự giảng giải:
>
> Khi quần thể mở rộng từ vài chục đến hàng nghìn hàng vạn, vấn đề cốt lõi của tính toán tiến hóa không còn là "có thể tìm được nghiệm tốt hay không", mà là "có thể đánh giá đủ nhiều ứng viên trong thời gian hữu hạn hay không". Đa dạng phụ thuộc vào thông lượng, duy trì đa dạng về bản chất là một bài toán năng lực tính toán.
>
> Tính toán tensor hóa chịu trách nhiệm "chạy nhanh", kiến trúc thống nhất chịu trách nhiệm "thay đổi được".
>
> Vòng lặp CPU tuần tự truyền thống thực thi "đánh giá—ghi nhận—cập nhật" theo từng cá thể, sẽ tạo ra ba loại chi phí: chi phí điều phối cao, toán tử phân mảnh, tỷ lệ sử dụng GPU không đủ; cách làm tensor hóa là tổ chức toàn bộ việc duy trì quần thể, đánh giá theo lô và cập nhật trạng thái thành thao tác tensor theo lô, để cùng một thế hệ hoặc thậm chí nhiều thế hệ ứng viên tính toán song song. Ví dụ với N nghiệm ứng viên, tuần tự là lặp từng cái, tensor hóa là tổ chức quần thể thành một tensor, hoàn thành đánh giá theo lô và cập nhật trạng thái song song một lần, từ đó giảm chi phí điều phối, nâng cao tỷ lệ sử dụng GPU.
>
> Chỉ viết lại vòng lặp vẫn chưa đủ, nếu thuật toán, vấn đề và logic điều phối bị ghép chặt, đổi thuật toán hoặc đổi nhiệm vụ phải viết lại. Kiến trúc thống nhất tách rời thuật toán, vấn đề, workflow, điều phối Runtime, và phối hợp với điều phối năng lực tính toán không đồng nhất để quản lý CPU/GPU ở cấp nhiệm vụ theo lô, khiến cùng một bộ cơ chế song song có thể tái sử dụng cho các kịch bản tiến hóa phương pháp như MetaDE, AutoPSO.
>
> Bên trái là vòng lặp CPU tuần tự truyền thống, tuần tự từng cá thể, tỷ lệ sử dụng GPU thấp; bên phải là tính toán tensor theo lô trên GPU, tensor quần thể→đánh giá theo lô→cập nhật trạng thái song song, phía dưới là nền tảng thống nhất mở, tách rời, bao gồm thuật toán, vấn đề, workflow, điều phối Runtime.

**Điểm giảng dạy chính**

- EvoX không chỉ giải quyết vấn đề, mà còn đưa chính phương pháp sinh nghiệm ứng viên vào đối tượng tiến hóa. Trong MetaDE, thuật toán lớp ngoài tiến hóa cấu hình và chiến lược của thuật toán lớp trong, AutoPSO, EvoGO tiếp tục kết hợp thành phần, sử dụng phản hồi lịch sử để học cách sinh ứng viên, từ "đổi tham số" tiến đến "đổi cấu trúc thuật toán". Loại tiến hóa hai lớp trong ngoài này tự nhiên yêu cầu một lượng lớn nhiệm vụ lớp trong được đánh giá theo lô và cập nhật trạng thái. Nó thay đổi hình thức tổ chức tính toán, chuyển toàn bộ đường "quần thể—đánh giá—cập nhật" thành thao tác tensor theo lô, chứ không phải thay thế một toán tử nào đó hoặc thay đổi cách mã hóa. Nếu phân tích hiệu năng xuất hiện "quá nhiều toán tử nhỏ, tỷ lệ sử dụng GPU thấp, tỷ lệ điều phối CPU cao", thường cho thấy hệ thống vẫn đang lặp tuần tự từng cá thể, đây là tín hiệu đầu vào để đưa vào đồ thị tính toán tensor hóa. Chỉ làm tensor hóa, đổi thuật toán hoặc đổi nhiệm vụ phải viết lại
- Chỉ làm kiến trúc thống nhất, thiếu song song theo lô vẫn không nhanh được.

**Xử lý bài tập**

Chuyển biến cốt lõi của tensor hóa là viết lại việc duy trì quần thể, đánh giá theo lô và cập nhật trạng thái thành thao tác tensor theo lô; chi phí chính của vòng lặp CPU tuần tự truyền thống là chi phí điều phối cao, toán tử phân mảnh, tỷ lệ sử dụng GPU không đủ; kiến trúc thống nhất mở, tách rời là để cơ chế song song có thể tái sử dụng cho các thuật toán và nhiệm vụ khác nhau; với cùng một thế hệ N nghiệm ứng viên, lợi ích then chốt là hoàn thành đánh giá theo lô và cập nhật trạng thái song song một lần; nền tảng do GPU và mô hình lớn mang lại khiến tính toán theo lô từ tối ưu cục bộ nâng lên thành năng lực cơ bản của khám phá tiến hóa cấp hệ thống. Phản hồi bài tập nên hướng dẫn học sinh quay lại hai từ khóa "song song theo lô" và "tách rời tái sử dụng", tránh chọn nhầm các phương án gây nhiễu như "nén quần thể", "đánh giá gần đúng", "workflow cố định".

Câu hỏi tình huống yêu cầu chuyển tiến hóa vi phân từ tuần tự đơn máy sang nền tảng song song theo lô. Điểm trả lời chính câu 1: tuần tự từng cá thể mang lại chi phí điều phối cao, toán tử phân mảnh, tỷ lệ sử dụng GPU không đủ; tensor hóa thông qua tổ chức quần thể thành tensor, hợp nhất đánh giá theo lô và cập nhật trạng thái để giảm nhẹ, đồng thời giữ nguyên ngữ nghĩa đột biến, lai ghép, chọn lọc. Điểm trả lời chính câu 2: kiến trúc thống nhất tách rời và giải ghép theo lớp thuật toán, lớp vấn đề, lớp workflow, lớp điều phối Runtime;
lớp thuật toán chỉ mô tả ngữ nghĩa sinh ứng viên và cập nhật, lớp vấn đề đóng gói giao diện đánh giá theo lô, lớp workflow điều phối nhiệm vụ trong ngoài, lớp điều phối Runtime chịu trách nhiệm điều phối năng lực tính toán không đồng nhất và quản lý cấp nhiệm vụ theo lô, từ đó khiến cùng một nền tảng tái sử dụng cho các kịch bản tiến hóa phương pháp như MetaDE, AutoPSO.

**Kiểm tra hiểu biết**

Có thể cho học sinh dùng lời của mình giải thích "đồ thị tính toán tensor hóa giải quyết vấn đề gì, kiến trúc thống nhất giải quyết vấn đề gì", và lấy ví dụ giải thích tại sao hai cái phải phối hợp.

> **Gợi ý chuyển tiếp**
>
> Sau khi xác nhận học sinh có thể phân biệt "chạy nhanh" và "thay đổi được", hãy tiếp tục đi vào nội dung trang tiếp theo về ví dụ cụ thể hoặc cơ chế kỹ thuật của tiến hóa liên tục cấp hệ thống.

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

### Sự tiến hóa của chính thuật toán: Từ giải đáp án đến cải tiến phương pháp

*Trang 6*

> **Mục tiêu trang:** Hiểu nguyên lý cơ bản của việc đưa chính phương pháp sinh ứng viên vào đối tượng tối ưu để thực hiện tiến hóa tự thân của thuật toán.

**Điểm giảng dạy chính**

- Lớp trong tìm đáp án, lớp ngoài đổi phương pháp. Thấy "chiến lược, tham số, toán tử, thành phần được đưa vào tìm kiếm" là tiến hóa phương pháp; thấy "chỉ có nghiệm ứng viên thay đổi, quy tắc sinh luôn không đổi" là thuật toán tiến hóa truyền thống.
- Tín hiệu sở thích trước tiên đi vào đánh giá đáp án, sau đó qua tổng hợp xuyên nhiệm vụ và kiểm tra ổn định, mới được phép đi vào lựa chọn phương pháp. Bỏ qua bước này, lớp ngoài sẽ đuổi theo một kết quả dễ chịu nhưng không thể tái lập.
- Không gian phương pháp lớn đến mức nào? Mỗi vòng cần chạy bao nhiêu lần nhiệm vụ lớp trong? Dùng tập nhiệm vụ độc lập nào để xác minh cải tiến lớp ngoài thực sự tổng quát hóa? Ba khoản này không tính rõ, tìm kiếm hai lớp dễ thoái hóa thành điều chỉnh tham số ngẫu nhiên đắt đỏ hơn.

Mục tiêu trang

Thuật toán tiến hóa truyền thống tìm kiếm dưới cơ chế sinh cố định, đối tượng được tối ưu luôn là nghiệm ứng viên; tiến hóa phương pháp đưa chính phương pháp sinh nghiệm ứng viên vào đối tượng tìm kiếm, hoàn thành tiến hóa từ "giải đáp án" đến "cải tiến phương pháp".

Trình tự giảng giải

1. Trước tiên so sánh sự khác biệt giữa thuật toán tiến hóa truyền thống và tiến hóa phương pháp, chỉ ra "đối tượng được tối ưu" đã dịch chuyển.

2. Dẫn ra định nghĩa tiến hóa phương pháp, và giải thích EvoX tiến theo tuyến này, đưa chính phương pháp sinh ứng viên vào đối tượng tiến hóa.

Lớp trong tìm đáp án, lớp ngoài đổi phương pháp.

4. Định vị tối ưu sở thích nên đặt ở lớp nào, nhấn mạnh hai loại mục tiêu không thể nhầm lẫn.

5. Lấy MetaDE, AutoPSO và EvoGO làm hình thái điển hình.

6. Kết lại thành lợi ích và chi phí, và xử lý bài tập và tình huống.

Điểm giảng dạy chính

Các quy tắc "làm thế nào sinh đáp án" như chọn lọc, lai ghép, đột biến được con người viết trước, tìm kiếm chỉ di chuyển trong không gian đáp án. Sau khi quy mô tính toán mở ra, cơ chế sinh cố định lại trở thành trần nhà.

Thuật toán không chỉ xuất ra đáp án tốt hơn, mà còn thông qua tìm kiếm lớp ngoài liên tục cải tiến chiến lược, tham số và thành phần sinh ra đáp án. EvoX là công trình trên tuyến này, ví dụ đưa chiến lược đột biến và thiết lập tham số của tiến hóa vi phân vào đối tượng tiến hóa.

Lớp trong dùng phương pháp hiện tại giải quyết vấn đề cụ thể, sinh ra nghiệm ứng viên; lớp ngoài dựa trên phản hồi như chất lượng nghiệm, tín hiệu sở thích, độ ổn định hoặc chi phí, so sánh, lựa chọn, cập nhật phương pháp dùng cho vòng tiếp theo. Đối tượng được nâng lên không gian tìm kiếm không phải là một nghiệm nào đó, mà là chính cơ chế sinh ứng viên, do đó nó trở thành đối tượng có thể đánh giá, có thể lựa chọn, có thể cập nhật.

Lớp trên là "phương pháp tiến hóa sinh nghiệm ứng viên", bao gồm chiến lược/tham số/thành phần toán tử, tìm kiếm tiến hóa lớp ngoài, phương pháp sinh đã cải tiến; lớp dưới là "giải quyết vấn đề cụ thể", bao gồm phương pháp hiện tại, nghiệm ứng viên, đánh giá chất lượng nghiệm. Hai vòng tuần hoàn lần lượt biểu thị kết quả lớp ngoài chảy ngược vào lớp trong, chất lượng nghiệm/sở thích/chi phí phản hồi thúc đẩy hai lớp. Khi viết bảng có thể vẽ hai lớp trên dưới trước, rồi dùng mũi tên đánh dấu "cập nhật phương pháp sinh" và "tín hiệu phản hồi".

Có thể tham gia phản hồi lớp trên, nhưng phải tách "đánh giá đáp án hiện tại" và "cải tiến phương pháp sinh đáp án". Đọc trực tiếp "nghiệm này dễ chịu hơn" thành "chiến lược này tốt hơn", chính là dùng sở thích đáp án giả mạo ưu liệt phương pháp, lớp ngoài sẽ bị nhiễu của kết quả đơn lần dắt đi. Tín hiệu sở thích trước tiên đi vào đánh giá đáp án, sau đó qua tổng hợp xuyên nhiệm vụ và kiểm tra ổn định, mới được phép đi vào lựa chọn phương pháp.

MetaDE để lớp ngoài tiến hóa chiến lược đột biến và tham số của tiến hóa vi phân, lớp trong giải quyết nhiệm vụ như thường; AutoPSO và EvoGO tiếp tục kết hợp thành phần bầy đàn hạt, sử dụng phản hồi lịch sử để học cách sinh ứng viên, thực hiện bước nhảy từ "đổi tham số" đến "đổi cấu trúc thuật toán".

Lợi ích là đẩy thiết kế thuật toán từ điều chỉnh tham số thủ công một lần sang thích ứng bền vững. Chi phí có ba: không gian tìm kiếm phình to, không gian phương pháp lớn hơn nhiều so với không gian nghiệm; chi phí đánh giá tăng lên, mỗi bộ phương pháp ứng viên đều phải chạy nhiệm vụ lớp trong, thường phụ thuộc vào đánh giá theo lô song song GPU để san sẻ; độ phức tạp xác minh tăng lên, cải tiến lớp ngoài có thực sự tổng quát hóa hay không, cần thiết kế xác minh độc lập.

Gợi ý bài tập và hướng dẫn đáp án

1. So với thuật toán tiến hóa truyền thống, sự khác biệt bản chất nhất của tiến hóa phương pháp ở "đối tượng được tối ưu" là gì? Hướng đúng là: đưa chính chiến lược, tham số và thành phần toán tử "làm thế nào sinh đáp án" vào đối tượng tìm kiếm. Nếu học sinh chọn "quần thể lớn hơn" hoặc "hủy đánh giá độ thích nghi", gợi ý họ quay lại sự dịch chuyển đối tượng tối ưu: đối tượng được tối ưu không còn chỉ là đáp án, mà là cơ chế sinh ra đáp án.

Phản hồi như chất lượng nghiệm, tín hiệu sở thích, độ ổn định hoặc chi phí đến từ biểu hiện nhiệm vụ lớp trong. Nếu học sinh chọn nhầm "nhiễu ngẫu nhiên" hoặc "kỹ sư chỉ định thủ công", hướng dẫn họ hỏi tiếp: Lớp ngoài dựa vào đâu để phán đoán một bộ chiến lược tốt hơn bộ khác? Cái "dựa vào đâu" này chính là tín hiệu phản hồi.

Cho tín hiệu sở thích tham gia phản hồi lớp trên, nhưng xử lý riêng "đánh giá đáp án hiện tại" và "cải tiến phương pháp sinh" như hai loại mục tiêu. Nếu học sinh lấy sở thích đáp án trực tiếp làm ưu liệt phương pháp, nhắc họ: sở thích phải qua tổng hợp xuyên nhiệm vụ và kiểm tra ổn định, mới có thể nâng cấp từ "sở thích đáp án" thành "tiêu chí phương pháp".

Không gian phương pháp phình to, mỗi bộ phương pháp đều phải trả chi phí đánh giá lớp trong, và độ khó xác minh tăng lên. Có thể tổng kết thành ba áp lực: không gian, năng lực tính toán, xác minh; tiến hóa phương pháp nâng đối tượng tìm kiếm lên một lớp, chi phí cũng dịch chuyển theo.

5. Về MetaDE và AutoPSO, mục nào chính xác? Hướng đúng là: MetaDE dùng lớp ngoài tiến hóa chiến lược đột biến và tham số của tiến hóa vi phân, lớp trong vẫn chịu trách nhiệm giải nghiệm ứng viên cho nhiệm vụ cụ thể. AutoPSO và EvoGO tiến xa hơn đến kết hợp thành phần và cải tiến cấp cấu trúc, hướng là từ đổi tham số đến đổi cấu trúc.

Xử lý tình huống

Kịch bản là nhóm tối ưu bố cục chip trên cụm GPU, đã có bộ giải tiến hóa vi phân, nhưng chiến lược đột biến và tham số phụ thuộc vào kinh nghiệm thủ công, hiệu năng biến động rõ rệt, dự định đưa vào tối ưu hai lớp kiểu MetaDE, và dùng sở thích người dùng dẫn dắt tìm kiếm.

Đầu vào lớp trong là phương pháp hiện tại (chiến lược đột biến và cấu hình tham số) và một thể hiện bài toán bố cục cụ thể, đầu ra là bố cục ứng viên và chất lượng nghiệm của nó. Đầu vào lớp ngoài là thống kê tổng hợp biểu hiện nhiệm vụ lớp trong, đầu ra là chiến lược và cấu hình tham số đã cập nhật. Tín hiệu phản hồi phải tổng hợp xuyên nhiệm vụ, xuyên lần chạy lặp lại, ví dụ giá trị trung bình đa nhiệm vụ, phân vị hoặc chỉ số ổn định, không thể lấy từ một lần chạy nào đó. Lý do là chất lượng của một nghiệm đơn lẻ phụ thuộc cao vào thể hiện cụ thể và tính ngẫu nhiên, nó đo lường "đáp án lần này tốt hay không", chứ không phải "phương pháp này tốt hay không"; nếu dùng trực tiếp kết quả đơn lần để dẫn dắt lớp ngoài, lớp ngoài sẽ bị khác biệt thể hiện và nhiễu chi phối.

Lớp trong có thể dùng hàm đánh giá có trọng số sở thích để sàng lọc bố cục ứng viên; lớp ngoài trước tiên phải chuyển thành tiêu chí so sánh ổn định xuyên nhiệm vụ, ví dụ điểm có trọng số của chỉ số chiều dài đường dây và tắc nghẽn và phương sai của nó, rồi dùng để chọn cấu hình phương pháp, tránh lấy sở thích đáp án một lần trực tiếp làm ưu liệt phương pháp.

Không gian tìm kiếm phình to có thể dùng phân nhóm tham số, tìm kiếm phân lớp, thô trước tinh sau để kiểm soát quy mô; chi phí đánh giá tăng lên có thể dùng đánh giá theo lô song song GPU, đánh giá đại diện mẫu ít và cơ chế dừng sớm để giảm chi phí; độ phức tạp xác minh tăng lên thì phải giữ tập nhiệm vụ xác minh độc lập và chạy lặp lại, kiểm tra cải tiến lớp ngoài có thực sự tổng quát hóa hay không.

Kiểm tra hiểu biết và chuyển tiếp

Lớp trong tìm đáp án, lớp ngoài đổi phương pháp. Thấy "chiến lược, tham số, toán tử, thành phần được đưa vào tìm kiếm" là tiến hóa phương pháp; thấy "chỉ có nghiệm ứng viên thay đổi, quy tắc sinh luôn không đổi" là thuật toán tiến hóa truyền thống. Sau khi xác nhận học sinh có thể giải thích "đối tượng được tối ưu đã thay đổi" và "sở thích không thể trực tiếp giả mạo ưu liệt phương pháp", hãy tiếp tục đi vào ví dụ, ứng dụng hoặc tổng kết ở trang tiếp theo.

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

### MetaDE và AutoPSO: Kiến trúc hai lớp của tiến hóa phương pháp

*Trang 7*

> **Mục tiêu trang:** Nắm vững cách MetaDE và AutoPSO thực hiện tiến hóa tự động biến thể thuật toán và tham số thông qua tối ưu hai lớp trong ngoài.

> **Mục tiêu trang**
>
> Hiểu cách MetaDE và AutoPSO thực hiện tiến hóa tự động cấu hình thuật toán và cấu trúc thông qua kiến trúc tối ưu hai lớp trong ngoài, và nắm vững cấu trúc chi phí và đánh đổi kỹ thuật của nó.

> **Trình tự giảng giải**
>
> Thuật toán không còn chỉ tìm nghiệm, mà còn cải tiến "bản thân tìm nghiệm như thế nào".
>
> 2. Trình bày trừu tượng chung của kiến trúc hai lớp trong ngoài, nhấn mạnh lớp ngoài tìm kiếm không gian thuật toán, lớp trong giải quyết nhiệm vụ mục tiêu, biểu hiện lớp trong truyền về thành tín hiệu độ thích nghi tạo thành vòng tuần hoàn kín.
>
> 3. Lần lượt giảng giải hai tuyến triển khai MetaDE và AutoPSO, giải thích cái trước quản lý lớp cấu hình, cái sau quản lý lớp cấu trúc/thành phần.
>
> 4. Phân tích hiệu ứng nhân chi phí của tối ưu hai lớp, dẫn ra các đánh đổi kỹ thuật như phân bổ ngân sách, đánh giá gần đúng, dừng sớm, song song hóa.
>
> Từ thiết kế thủ công thuật toán đơn nhất chuyển sang thiết kế không gian thuật toán có thể tiến hóa và cơ chế đánh giá.

**Điểm giảng dạy chính**

- Tiến hóa phương pháp (Meta-Evolution) lấy chính "phương pháp sinh ứng viên" làm đối tượng tối ưu. Lớp ngoài tìm kiếm cấu hình thuật toán, tổ hợp thành phần hoặc chiến lược, chứ không phải nghiệm nhiệm vụ. Lớp ngoài chịu trách nhiệm tìm kiếm không gian thuật toán (siêu tham số, chiến lược, tổ hợp thành phần và các "định nghĩa thuật toán" khác)
- Lớp trong dùng thuật toán ứng viên thực sự giải quyết nhiệm vụ mục tiêu, thu được biểu hiện có thể đo lường
- Biểu hiện lớp trong được tổng hợp thành độ thích nghi truyền về lớp ngoài, lớp ngoài loại bỏ cấu hình kém chất lượng, giữ lại và đột biến cấu hình chất lượng cao, tạo thành vòng tuần hoàn cải tiến liên tục. Giữ lại tiến hóa vi phân làm bộ giải lớp trong, đưa cấu hình của chính DE cho lớp ngoài tìm kiếm—chiến lược đột biến, tỷ lệ lai ghép, hệ số tỷ lệ và các tham số khác thích ứng theo vấn đề và giai đoạn tối ưu. Nó trả lời "cấu hình này nên đặt như thế nào ở giai đoạn nhiệm vụ hiện tại", thuộc tiến hóa phương pháp cấp cấu hình. Xem tham số cốt lõi và cơ chế học của PSO như thành phần có thể tổ hợp—trọng số quán tính, hệ số học và các cách kết hợp khác nhau của cơ chế học cá thể và quần thể, do lớp ngoài tự động tìm kiếm và tổ hợp thành biến thể PSO phù hợp với các vấn đề khác nhau. Nó chuyển "chọn thuật toán" thành "tìm cấu trúc thuật toán", thực hiện bước nhảy từ thích ứng tham số đến tự sinh cơ chế. MetaDE thiên về tự động điều chỉnh cấp cấu hình và siêu tham số, AutoPSO thiên về tự động tổ hợp cấp cấu trúc và thành phần, cùng bao phủ phạm vi tiến hóa từ thích ứng tham số đến tự sinh cơ chế. Chi phí then chốt của tối ưu hai lớp nằm ở hiệu ứng nhân—mỗi lần lớp ngoài đánh giá một thuật toán ứng viên, thường cần nhiều lần chạy lớp trong (đánh giá lặp lại tính ngẫu nhiên, xác minh kết hợp đa nhiệm vụ, v.v.), ngân sách tính toán bị phóng đại đáng kể. Lượng tính toán thực tế xấp xỉ bằng "số lượng thuật toán ứng viên lớp ngoài × số lần chạy lớp trong của mỗi ứng viên". Phân bổ ngân sách, đánh giá gần đúng, dừng sớm, song song hóa. Thực thi hiệu quả phụ thuộc vào song song tensor hóa, điều phối Runtime và khả năng tổ hợp thuật toán
- Song song hóa có thể giảm nhẹ thời gian đồng hồ tường, nhưng không giảm tổng lượng tính toán. Nhà nghiên cứu bàn giao không còn là một thuật toán cố định, mà là một không gian tìm kiếm và quy tắc phản hồi cho phép thuật toán tự cải tiến liên tục.

**Kiểm tra hiểu biết**

Có thể lần lượt đặt câu hỏi và đưa ra điểm trả lời chính:

1. Đối tượng trực tiếp mà lớp ngoài tìm kiếm là gì?

Cấu hình, cấu trúc và tổ hợp thành phần của chính thuật toán. Bản chất của tiến hóa phương pháp là lấy chính thuật toán làm đối tượng được tối ưu, lớp ngoài tìm kiếm cấu hình và cấu trúc trong không gian thuật toán, chứ không trực tiếp tìm kiếm nghiệm nhiệm vụ. Chú ý phân biệt hai lớp: tìm nghiệm trực tiếp là lớp trong; lớp ngoài tìm kiếm là "dùng thuật toán gì, cấu hình thuật toán như thế nào".

2. Trong MetaDE, lớp ngoài chủ yếu tiến hóa nhóm đối tượng nào?

Chiến lược đột biến, tỷ lệ lai ghép và hệ số tỷ lệ của tiến hóa vi phân. MetaDE để cấu hình của DE thích ứng theo vấn đề và giai đoạn, thuộc tiến hóa phương pháp cấp cấu hình/siêu tham số, chứ không phải cấu trúc của thuật toán khác.

3. Về phân công giữa AutoPSO và MetaDE, mô tả nào chính xác nhất?

AutoPSO thiên về tự động tổ hợp tham số và cơ chế học, chuyển "chọn thuật toán" thành "tìm cấu trúc thuật toán"; MetaDE thiên về tiến hóa cấp cấu hình. Hai cái bổ sung cho nhau: MetaDE bao phủ cấp cấu hình và siêu tham số, AutoPSO bao phủ cấp cấu trúc và thành phần, cùng tạo thành phạm vi tiến hóa từ thích ứng tham số đến tự sinh cơ chế, và đều phải qua đánh giá lớp trong.

4. Về cấu trúc chi phí của tối ưu hai lớp, mục nào đúng?

Mỗi lần lớp ngoài đánh giá một thuật toán ứng viên thường cần nhiều lần chạy lớp trong, ngân sách bị phóng đại đáng kể, cần phân bổ ngân sách, đánh giá gần đúng hoặc dừng sớm. Chi phí chính của kiến trúc hai lớp là hiệu ứng nhân, song song hóa chỉ có thể giảm nhẹ, không thể loại bỏ tổng chi phí.

5. Sau khi áp dụng kiến trúc hai lớp tiến hóa phương pháp, chuyển đổi nhận thức về vai trò của nhà nghiên cứu là gì?

Từ thiết kế thủ công thuật toán đơn nhất, chuyển sang thiết kế không gian thuật toán có thể tiến hóa và cơ chế đánh giá. Bàn giao không còn là thuật toán cố định, mà là "không gian thuật toán có thể tiến hóa + quy tắc đánh giá độ thích nghi", tìm kiếm lớp ngoài và giải quyết lớp trong từ đó tạo thành vòng tuần hoàn cải tiến liên tục. Mặc dù không còn cố định thủ công thuật toán đơn nhất, nhưng công việc cốt lõi trở thành thiết kế không gian tìm kiếm và cơ chế đánh giá, trách nhiệm ngược lại càng nặng hơn.

**Xử lý bài tập**

Tình huống "xây dựng dịch vụ tiến hóa hai lớp cho nhiệm vụ thay đổi liên tục" có thể dùng sau khi giảng giải xong kiến trúc và chi phí, để học sinh trả lời độc lập trước, rồi thảo luận tập thể.

Hãy giải thích lớp trong và lớp ngoài mỗi cái chịu trách nhiệm gì, và tín hiệu lưu chuyển như thế nào.

Lớp ngoài tìm kiếm thuật toán ứng viên trong không gian thuật toán—có thể tiến hóa chiến lược đột biến, tỷ lệ lai ghép, hệ số tỷ lệ của DE (tuyến MetaDE), cũng có thể tự động tổ hợp các thành phần như trọng số quán tính, hệ số học và cơ chế học của PSO (tuyến AutoPSO). Lớp trong dùng mỗi thuật toán ứng viên chạy và đánh giá trên nhiệm vụ mục tiêu trong ngày, xuất ra biểu hiện có thể so sánh; biểu hiện lớp trong được tổng hợp thành độ thích nghi và truyền về lớp ngoài, lớp ngoài dựa vào đó loại bỏ ứng viên kém chất lượng, giữ lại và đột biến cấu hình chất lượng cao, liên tục lặp lại, tạo thành vòng tuần hoàn kín "lớp ngoài tìm kiếm không gian thuật toán, lớp trong giải quyết nhiệm vụ mục tiêu, phản hồi biểu hiện thúc đẩy cải tiến".

Đối mặt với áp lực ngân sách "lớp ngoài đánh giá một lần cần nhiều lần chạy lớp trong", đưa ra ít nhất hai biện pháp đánh đổi và giải thích chi phí hoặc rủi ro.

① Phân bổ ngân sách—đặt hạn mức tính toán riêng cho lớp ngoài và lớp trong và giới hạn số lần lặp lớp trong, chi phí là phương sai đánh giá tăng, có thể chọn nhầm; ② Đánh giá gần đúng—dùng tập con dữ liệu hoặc chạy ngắn để ước lượng độ thích nghi, chi phí là tín hiệu nhiễu lớn, ứng viên tối ưu có thể bị đánh giá thấp; ③ Dừng sớm—dừng sớm chạy lớp trong đối với ứng viên rõ ràng kém chất lượng, chi phí là có thể loại sớm cấu hình khởi động chậm nhưng biểu hiện tốt về sau; ④ Song song tensor hóa và điều phối Runtime—chạy lớp trong đồng thời theo lô, có thể giảm nhẹ đáng kể thời gian đồng hồ tường, nhưng không giảm tổng lượng tính toán, và bị giới hạn bởi bộ nhớ hiển thị và chi phí điều phối. Trả lời cần giải thích mối tương ứng giữa mỗi biện pháp và chi phí hoặc rủi ro của nó, và thể hiện ước lượng nhân "quy mô tìm kiếm lớp ngoài × số lần chạy lớp trong mỗi lần".

Ngôn ngữ phản hồi:

Đúng. Câu trả lời này có thể liên hệ với khái niệm trang này, và giải thích căn cứ.

Hãy quay lại phần giảng giải trang này, tìm bằng chứng hoặc ví dụ then chốt rồi phán đoán.

Chú ý phân biệt "lớp"—tìm nghiệm trực tiếp là lớp trong, lớp ngoài tìm kiếm là "dùng thuật toán gì, cấu hình thuật toán như thế nào"; đối tượng của MetaDE là cấu hình của chính tiến hóa vi phân, chứ không phải cấu trúc của thuật toán khác; chi phí chính của kiến trúc hai lớp là hiệu ứng nhân, song song hóa chỉ có thể giảm nhẹ, không thể loại bỏ tổng chi phí; mặc dù không còn cố định thủ công thuật toán đơn nhất, nhưng công việc cốt lõi của nhà nghiên cứu trở thành thiết kế không gian tìm kiếm và cơ chế đánh giá, trách nhiệm ngược lại càng nặng hơn.

> **Gợi ý chuyển tiếp**
>
> Sau khi xác nhận học sinh có thể dùng lời của mình phân biệt "tiến hóa cấp cấu hình" và "tiến hóa cấp cấu trúc/thành phần", và có thể nói ra vòng tín hiệu lớp trong lớp ngoài và hiệu ứng nhân ngân sách, hãy tiếp tục đi vào ví dụ, ứng dụng hoặc tổng kết ở trang tiếp theo.

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

### Nghiên cứu tình huống thực hành đa mục tiêu trong thiết kế cánh siêu tới hạn

*Trang 8*

> **Mục tiêu trang:** Học cách sử dụng EvoX để xử lý ràng buộc kỹ thuật phức tạp và sinh ra phương án cân bằng đa dạng trong thiết kế cánh.

> **Mục tiêu trang**
>
> Hiểu tại sao thiết kế cánh siêu tới hạn là vấn đề đa mục tiêu, và nắm vững cách sử dụng EvoX để sinh ra phương án cân bằng đa dạng dưới ràng buộc kỹ thuật nghiêm ngặt.

> **Trình tự giảng giải**
>
> Thiết kế cánh siêu tới hạn là thực hành đa mục tiêu của EvoX trong kỹ thuật thực tế. Các tham số hình dạng như độ cong, độ dày, mép sau của cánh ghép chặt lẫn nhau, thay đổi hình dạng sẽ đồng thời ảnh hưởng đến nhiều chỉ số khí động.
>
> Cải thiện một chỉ số thường phải trả giá bằng một chỉ số khác, do đó không thể xử lý theo tối ưu đơn mục tiêu, cần cân bằng đa mục tiêu.
>
> Các yêu cầu như lực nâng, góc tấn, độ dày giới hạn miền thiết kế khả thi, tìm kiếm phải triển khai dưới tiền đề thỏa mãn ràng buộc, mới có thể đảm bảo phương án ứng viên khả dụng trong kỹ thuật.
>
> EvoX sinh ra nhóm phương án ứng viên đa dạng cân nhắc các chỉ số, chứ không phải nghiệm tối ưu duy nhất; nhóm ứng viên để chuyên gia lĩnh vực so sánh các lợi ích và chi phí khác nhau, và đưa ra đánh đổi.
>
> Tình huống này chuyển vấn đề phức tạp thực tế thành quá trình có thể khám phá, có thể đánh giá, tìm phương án cân bằng có thể giải thích trong xung đột giữa ràng buộc và mục tiêu.

**Điểm giảng dạy chính**

- Thay đổi hình dạng cánh siêu tới hạn ảnh hưởng đến nhiều chỉ số khí động, giữa các mục tiêu thường tồn tại xung đột, cần cân bằng đa mục tiêu. Thiết kế cần thỏa mãn nhiều ràng buộc nghiêm ngặt như lực nâng, góc tấn và độ dày, tìm kiếm nên triển khai trong miền thiết kế khả thi. Sinh ra phương án ứng viên đa dạng, giúp chuyên gia đánh giá các lợi ích và chi phí khác nhau và đưa ra đánh đổi. Trước tiên khám phá liên tục trong không gian tham số cánh (độ cong, độ dày, mép sau), rồi tiệm cận biên cân bằng đa mục tiêu (chỉ số A và chỉ số B), cuối cùng hình thành nhóm phương án ứng viên. Cánh siêu tới hạn, cân bằng đa mục tiêu, miền thiết kế khả thi, nhóm phương án ứng viên, EvoX.

> **Gợi ý bài tập**
>
> - Nguyên nhân gốc rễ của vấn đề đa mục tiêu, vai trò của ràng buộc, đầu ra thực hành của EvoX, ý nghĩa của ứng viên đa dạng, giá trị phương pháp. Hiểu đúng nên nằm ở: tham số hình dạng đồng thời ảnh hưởng đến nhiều chỉ số dẫn đến xung đột mục tiêu
> - Ràng buộc giới hạn miền thiết kế khả thi
> - Đầu ra là nhóm phương án ứng viên đa dạng
> - Các ứng viên khác nhau đại diện cho lợi ích và chi phí khác nhau
> - Giá trị phương pháp nằm ở việc chuyển vấn đề phức tạp thực tế thành quá trình có thể khám phá, có thể đánh giá.

**Xử lý bài tập**

Nếu học sinh chọn nhầm "chỉ cần tối ưu lực nâng" "tìm nghiệm tối ưu duy nhất", gợi ý quay lại ghép chặt tham số hình dạng và xung đột mục tiêu.

Nếu học sinh chọn nhầm "ràng buộc có thể nới lỏng tùy ý" hoặc "không liên quan đến khả dụng kỹ thuật", gợi ý ràng buộc định nghĩa miền thiết kế khả thi, không thể nới lỏng tùy ý.

Nếu học sinh chọn nhầm "cánh tối ưu đơn nhất" hoặc "hình dạng ngẫu nhiên", gợi ý đầu ra nên là nhóm phương án ứng viên đa dạng cân nhắc các chỉ số.

Đúng, câu trả lời này có thể liên hệ với khái niệm trang này và giải thích căn cứ.

Hãy quay lại phần giảng giải trang này, tìm bằng chứng hoặc ví dụ then chốt rồi phán đoán.

**Hoạt động trên lớp**

Vì thay đổi tham số hình dạng sẽ đồng thời ảnh hưởng đến nhiều chỉ số khí động, cải thiện một cái thường phải trả giá bằng cái khác, cần cân bằng đa mục tiêu; ràng buộc giới hạn miền thiết kế khả thi, đảm bảo phương án ứng viên khả dụng trong kỹ thuật.

**Kiểm tra hiểu biết**

EvoX trong thiết kế cánh siêu tới hạn, làm thế nào sinh ra nhóm phương án ứng viên đa dạng dưới ràng buộc nghiêm ngặt, để chuyên gia đánh giá lợi ích và chi phí. Giáo viên dựa vào trả lời bổ sung các từ khóa còn thiếu: xung đột mục tiêu, miền thiết kế khả thi, nhóm phương án ứng viên, cân bằng đa mục tiêu.

> **Gợi ý chuyển tiếp**
>
> Sau khi xác nhận học sinh có thể phân biệt tối ưu đơn mục tiêu và cân bằng đa mục tiêu, và có thể giải thích mục đích của nhóm phương án ứng viên, hãy tiếp tục đi vào ví dụ, ứng dụng hoặc tổng kết ở trang tiếp theo.

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

### Thách thức xuyên vòng đời: Cạn kiệt ngữ cảnh và bền vững cấp dự án

*Trang 9*

> **Mục tiêu trang:** Hiểu mâu thuẫn giữa giới hạn ngữ cảnh của mô hình lớn và dự án kỹ thuật thực tế kéo dài hàng tháng hoặc hàng năm.

**Điểm giảng dạy chính**

- Ngữ cảnh đơn lần là bàn làm việc, kho dự án mới là ký ức dài hạn. Không nên chỉ để trạng thái quần thể, cấu hình thất bại và lý do quyết định trong cửa sổ phiên; trước khi đóng phiên nên ghi vào artifact cấp dự án, phiên tiếp theo đọc trước rồi tiếp tục.
- Bền vững có thể kế thừa yêu cầu artifact có thể đánh phiên bản, có thể truy xuất, có thể giải thích: mã, kiểm thử, ghi chép thí nghiệm, nhật ký quyết định, chỉ số đánh giá và kết luận nghiệm thu phải có thể trả lời tại sao chọn như vậy, những gì đã thất bại, những xung đột nào vẫn còn.
- Agent lớp trên phân rã mục tiêu, Agent lớp dưới triển khai và kiểm thử. Trước khi mỗi phiên kết thúc đặt điểm kiểm tra: cập nhật nhật ký quyết định và chỉ số đánh giá; khi phiên mới khởi động trước tiên kế thừa điểm kiểm tra, rồi quyết định hành động cục bộ, từ đó vượt qua nhiều vòng đời hữu hạn.

> **Mục tiêu trang**
>
> Hiểu mâu thuẫn giữa giới hạn ngữ cảnh của Agent mô hình lớn và dự án kỹ thuật thực tế kéo dài hàng tháng thậm chí hàng năm, thiết lập sự cần thiết của bền vững cấp dự án. Phán đoán cốt lõi: cửa sổ ngữ cảnh đơn lần C最大 là tài nguyên hữu hạn, vòng đời dự án T项目 có thể kéo dài hàng tháng thậm chí hàng năm, do đó T项目 ≫ C最大. Khó khăn thực sự không phải là năng lực suy luận đơn lần không đủ, mà là kinh nghiệm không thể vượt qua vòng đời Agent.
>
> Trình tự giảng giải
>
> Ngữ cảnh Agent đơn lần chỉ có thể chứa mục tiêu hiện tại, quan sát cục bộ và suy luận gần đây; sau khi phiên đóng trạng thái trở về không, kết luận tạm thời và kinh nghiệm không còn khả dụng. Nếu thiếu bền vững, các phiên sau chỉ có thể khám phá lặp lại.
>
> Bền vững cấp dự án. Ngoại hóa cấu hình thất bại, quá trình cân bằng, phương án ứng viên và kết luận nghiệm thu thành artifact cấp dự án tồn tại liên tục, bao gồm mã, kiểm thử, ghi chép thí nghiệm, nhật ký quyết định, chỉ số đánh giá và kết luận nghiệm thu. Agent sau không cần bắt đầu từ số không, mà đọc kinh nghiệm trước đó, phán đoán hướng nào đã được xác minh, xung đột nào chưa giải quyết, chỉ số nào đã đạt.
>
> Đối tượng tiến hóa không còn chỉ là tham số số trị đơn lần hoặc nghiệm ứng viên, mà là thế giới phần mềm tồn tại liên tục, có thể đánh phiên bản, có thể kế thừa. Artifact mới mỗi phiên sinh ra thay đổi trạng thái của thế giới này, phiên tiếp theo tiếp tục tiến hóa trên thế giới đã cập nhật, do đó quá trình tối ưu trở thành tiến hóa liên tục cấp dự án.
>
> Nhiều Agent có vòng đời hữu hạn có thể hợp tác làm việc, người thực thi lớp trên hiểu mục tiêu và phân rã nhiệm vụ, người thực thi lớp dưới hoàn thành triển khai cục bộ và kiểm thử, khi cần tiếp tục phân rã đệ quy. Trước khi đóng ghi trạng thái then chốt, sau khi Agent mới khởi động trước tiên đọc ký ức dự án, rồi quyết định hành động cục bộ.
>
> Dự án dài hạn thường có xung đột mục tiêu, ví dụ hiệu năng, chi phí, độ bền khó đồng thời tối ưu; phản hồi cũng có thể thưa thớt, một thí nghiệm phải đợi hàng giờ thậm chí hàng ngày. Nhật ký quyết định và chỉ số đánh giá bền vững có thể chuyển phản hồi thưa thớt thành kinh nghiệm có thể kế thừa, tránh Agent sau lặp lại vết xe đổ.
>
> Điểm giảng dạy chính
>
> Ngữ cảnh đơn lần là bàn làm việc, kho dự án mới là ký ức dài hạn. Không nên chỉ để trạng thái quần thể, cấu hình thất bại và lý do quyết định trong cửa sổ phiên; trước khi đóng phiên nên ghi vào artifact cấp dự án, phiên tiếp theo đọc trước rồi tiếp tục.
>
> Bền vững không phải là chồng chất log. Bền vững có thể kế thừa yêu cầu artifact có thể đánh phiên bản, có thể truy xuất, có thể giải thích: mã, kiểm thử, ghi chép thí nghiệm, nhật ký quyết định, chỉ số đánh giá và kết luận nghiệm thu phải có thể trả lời tại sao chọn như vậy, những gì đã thất bại, những xung đột nào vẫn còn.
>
> Trước khi mỗi phiên kết thúc cập nhật nhật ký quyết định và chỉ số đánh giá; khi phiên mới khởi động trước tiên kế thừa điểm kiểm tra, rồi quyết định hành động cục bộ, từ đó vượt qua nhiều vòng đời hữu hạn.
>
> Tiến hóa liên tục cấp dự án, tức là chuyển quá trình sinh ứng viên, đánh giá ứng viên, ghi nhận cân bằng và kết luận nghiệm thu, từ ngữ cảnh Agent đơn lần sang artifact bền vững cấp dự án, khiến dự án lặp lại liên tục qua nhiều vòng đời Agent.
>
> Gợi ý bài tập
>
> Nên chọn "cửa sổ ngữ cảnh hữu hạn, và trạng thái và kinh nghiệm sau khi phiên đóng không thể phụ thuộc". Khi phản hồi nhấn mạnh: ranh giới cứng nằm ở độ dài hữu hạn và trạng thái trở về không sau khi phiên đóng, không phải quy mô tham số, mức độ song song hoặc hàm mục tiêu.
>
> Nên chọn "mã, kiểm thử, ghi chép thí nghiệm, nhật ký quyết định, chỉ số đánh giá và kết luận nghiệm thu". Khi phản hồi giải thích các artifact này cùng tạo thành ký ức dự án.
>
> Nên chọn "từ tham số số trị/nghiệm ứng viên đơn lần mở rộng thành thế giới phần mềm tồn tại liên tục, có thể đánh phiên bản, có thể kế thừa". Khi phản hồi phân biệt thay đổi mô hình huấn luyện và thay đổi ranh giới đối tượng tiến hóa.
>
> Nên chọn "lớp trên hiểu mục tiêu và phân rã nhiệm vụ, lớp dưới hoàn thành triển khai cục bộ và kiểm thử, khi cần phân rã đệ quy". Khi phản hồi nhấn mạnh tính liên tục xuyên vòng đời được đảm bảo bởi bền vững cấp dự án.
>
> Nên chọn "sau khi mỗi phiên đóng, trạng thái quần thể, cấu hình thất bại và lý do quyết định bị mất, Agent sau khám phá lặp lại". Khi phản hồi giải thích thiếu bền vững sẽ không tự động giải quyết xung đột mục tiêu hoặc mở rộng ngữ cảnh.
>
> Khi đúng có thể khẳng định "có thể liên hệ với khái niệm trang này và giải thích căn cứ"; khi sai yêu cầu học sinh quay lại phần giảng giải trang này, tìm bằng chứng hoặc ví dụ then chốt rồi phán đoán.
>
> Xử lý bài tập
>
> Mục tiêu bao gồm hiệu quả khí động, cường độ cấu trúc và chi phí sản xuất, ba cái xung đột, phản hồi mô phỏng thưa thớt, nhóm hy vọng nhiều Agent vòng đời ngắn hợp tác liên tục. Câu 1 yêu cầu giải thích tại sao không thể chỉ để ký ức dự án trong ngữ cảnh đơn lần, và liệt kê ít nhất ba loại artifact nên bền vững. Điểm trả lời chính: cửa sổ ngữ cảnh đơn lần hữu hạn và trạng thái trở về không sau khi phiên đóng, mà dự án kéo dài nhiều tháng, T项目 ≫ C最大; chỉ phụ thuộc vào ngữ cảnh đơn lần sẽ mất trạng thái quần thể, kết quả mô phỏng, cấu hình thất bại, xung đột chỉ số và lý do quyết định; nên bền vững ít nhất bao gồm mã và script huấn luyện mô hình đại diện, ghi chép kiểm thử và chỉ số đánh giá, ghi chép thí nghiệm và cấu hình thất bại, nhật ký quyết định và lý do cân bằng, phương án ứng viên và kết luận nghiệm thu.
>
> Phiên khởi động trước tiên đọc nhật ký quyết định, chỉ số đánh giá, ghi chép thí nghiệm và phương án ứng viên, khôi phục trạng thái quần thể và xung đột chưa giải quyết; trong phiên ghi mô hình đại diện mới, kết quả mô phỏng, đánh giá ứng viên và phân tích cân bằng; trước khi đóng cập nhật nhật ký quyết định, ghi lại cấu hình thất bại vòng này, xung đột chỉ số, lý do loại bỏ và đề xuất bước tiếp theo và đánh phiên bản; phiên sau thông qua đọc các artifact này kế thừa cấu hình thất bại và lý do quyết định, tránh khám phá lặp lại.

**Kiểm tra hiểu biết**

Yêu cầu học sinh dùng lời của mình tổng kết "tại sao ký ức dự án không thể chỉ lưu trong ngữ cảnh Agent đơn lần", và nói ra ít nhất ba loại đối tượng bền vững cấp dự án. Gợi ý chuyển tiếp: xác nhận học sinh có thể nói ra mối quan hệ cốt lõi trang này—T项目 ≫ C最大, bền vững cấp dự án ngoại hóa kinh nghiệm thành thế giới phần mềm có thể kế thừa—rồi tiếp tục đi vào ví dụ, ứng dụng hoặc tổng kết ở trang tiếp theo.

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

### Kiến trúc Genesis và mô thức lắng đọng của thế giới phần mềm

*Trang 10*

> **Mục tiêu trang:** Nắm vững cách Genesis để mã dự án tích lũy và tiến hóa liên tục qua vòng đời.

> **Mục tiêu trang**
>
> Giúp học sinh hiểu cách Genesis neo lại trí tuệ từ quá trình phiên dễ mất vào thế giới phần mềm có thể tích lũy, khiến mã dự án và kết quả kỹ thuật có thể tích lũy, tiến hóa và kế thừa liên tục qua cửa sổ ngữ cảnh đơn lần và vòng đời đơn lần.

> **Trình tự giảng giải**
>
> Trước tiên đưa ra tiêu chuẩn phán đoán "phiên là dễ mất, kho mới là ký ức dài hạn", rồi lần lượt triển khai sự khác biệt bản chất của mô thức lắng đọng, phân công của bốn loại tài sản có thể lắng đọng, tiền đề giao diện ổn định, vòng tuần hoàn lắng đọng và gác cổng nghiệm thu, kế thừa xuyên vòng đời, cuối cùng dùng một câu chỉ ra ranh giới phân công giữa EvoX và Genesis.

**Điểm giảng dạy chính**

- 1. Phán đoán một lần làm việc có giá trị lắng đọng hay không, chỉ hỏi một câu—người tiếp theo có thể tái lập nó mà không cần đến hỏi bất kỳ câu nào không? Nếu không, nó chưa trở thành tài sản. Workflow đối thoại bốc hơi khi ngữ cảnh kết thúc, đầu ra dừng lại ở "phiên lần này"
- Thế giới phần mềm lấy kho, phiên bản và artifact làm phương tiện, tự nhiên có tính tích lũy. Genesis chính là chính thức hóa phương tiện này thành lớp ký ức dài hạn của hệ thống tiến hóa, nó nhớ không phải là đối thoại, mà là kết quả kỹ thuật đã được xác minh. Mã quản "có chạy được", phương pháp quản "chọn như thế nào", trạng thái quản "đến đâu rồi", bằng chứng quản "dựa vào đâu để tin". Mã mang năng lực có thể thực thi, là quá trình giải có thể được chạy trực tiếp, tái lập
- Phương pháp mang quyết định thuật toán và chiến lược, ví dụ lựa chọn cấu hình và cách tổ hợp thành phần của tiến hóa hai lớp
- Trạng thái mang ngữ cảnh dự án và ký ức vận hành, ghi lại tiến độ hiện tại, ràng buộc và ranh giới đã biết
- Bằng chứng mang ghi chép thí nghiệm và kết luận nghiệm thu, trả lời tại sao kết quả đáng tin. Bốn cái thiếu một, lắng đọng tức là không thể tái lập hoặc không thể kế thừa: chỉ có mã mà không có bằng chứng, kết luận không thể được tin
- Chỉ có phương pháp mà không có trạng thái, người kế thừa không biết tiếp tục từ đâu. Do đó bốn loại tài sản phải được cố định thành bộ, chứ không phải rải rác mỗi nơi. 3. Tiền đề của lắng đọng là giao diện ổn định. Chỉ khi ranh giới mô-đun và hợp đồng tương đối ổn định, đầu ra mới là tài sản
- Nếu không mỗi lần thay đổi sẽ ảnh hưởng đến triển khai xung quanh, lắng đọng sẽ nhanh chóng chuyển thành nợ bảo trì. Điều này互为 điều kiện với thiết kế nền tảng mở, tách rời của Genesis: giao diện ổn định khiến lắng đọng có thể được kế thừa an toàn, tách rời khiến kế thừa không cần viết lại lịch sử. Trước khi lắng đọng cố định hợp đồng trước, thường có giá trị hơn viết thêm vài tài liệu. Khám phá → đầu ra → nghiệm thu nghiêm ngặt → cố định thành tài sản → vòng tiến hóa tiếp theo kế thừa trực tiếp. Trong đó nghiệm thu là người gác cổng của lắng đọng—đầu ra chưa được kiểm tra không đi vào lớp tài sản, từ đó tránh cố định nhiễu, hiện tượng ngẫu nhiên và kết luận sai thành "kinh nghiệm" dự án. Lắng đọng không có người gác cổng, kho sẽ càng dài càng không đáng tin. 5. Điểm then chốt của kế thừa xuyên vòng đời nằm ở việc tài sản tách rời khỏi thể hiện vận hành cụ thể, khiến phiên mới, Agent mới, nhiệm vụ mới đều có thể khôi phục nhận thức cấp dự án bằng cách "đọc kho", mà không phụ thuộc vào phát lại đối thoại lịch sử. Chi phí kế thừa từ "kể lại dự án một lần nữa" giảm xuống "checkout và tải", nhận thức dự án cũng không còn bị giới hạn bởi dung lượng của một cửa sổ ngữ cảnh nào đó. Genesis chịu trách nhiệm "lắng đọng cái gì, lắng đọng dưới hình thức nào, được kế thừa như thế nào"
- Hợp tác đa Agent và phân rã nhiệm vụ đệ quy chịu trách nhiệm "làm thế nào sản xuất đầu ra"
- Cơ chế nghiệm thu và kế thừa lịch sử chịu trách nhiệm "đầu ra được phán đoán là đáng tin như thế nào". Ba cái chồng lên nhau, mới tạo thành năng lực tiến hóa liên tục cấp dự án hoàn chỉnh—thiếu bất kỳ khâu nào, dự án chỉ có thể lặp lại tại chỗ.

**Phạm vi từ khóa**

- Genesis, tiến hóa liên tục cấp dự án, kiến trúc hệ thống EvoX, mã/phương pháp/trạng thái/bằng chứng, người gác cổng nghiệm thu, kế thừa xuyên vòng đời. Trang này tổ chức nội dung theo "sơ đồ kiến trúc ba lớp Genesis và vòng tuần hoàn lắng đọng", bên trái từ trên xuống lần lượt là lớp tài sản (mã·phương pháp·trạng thái·bằng chứng), cơ chế lắng đọng (đánh phiên bản·cổng nghiệm thu·truy xuất và kế thừa) và EvoX Runtime (song song tensor hóa·năng lực tính toán không đồng nhất·mô-đun thuật toán)
- Sơ đồ vòng tròn bên phải trình bày vòng tuần hoàn khám phá, đầu ra, nghiệm thu, cố định, tái sử dụng, tái tiến hóa, và đánh dấu "tài sản dày lên theo vòng đời tăng". Trang còn kèm ba gợi ý: đừng coi phiên là ký ức, bốn loại tài sản thiếu một không được, giao diện không ổn định lắng đọng biến thành nợ. Khi giảng giải có thể dựa vào hình này hướng dẫn học sinh thuật lại vòng tuần hoàn theo mũi tên, rồi chỉ ra nghiệm thu nằm sau đầu ra, trước cố định.

> **Gợi ý bài tập**
>
> - Trang có năm câu hỏi trắc nghiệm và một tình huống. Câu 1 chỉ vào thế giới phần mềm có thể tích lũy (kho, phiên bản và artifact), nếu học sinh chọn nhầm cửa sổ ngữ cảnh, gợi ý quay lại điểm khởi đầu "phiên kết thúc không để lại gì"
> - Câu 2 kiểm tra tương ứng trách nhiệm bốn loại tài sản, phương án đúng là mã mang năng lực có thể thực thi
> - Câu 3 kiểm tra ranh giới giữa tài sản và nợ bảo trì, phương án đúng là "ranh giới mô-đun và hợp đồng tương đối ổn định", cần nhấn mạnh điểm then chốt không nằm ở sản xuất bao nhiêu hoặc công cụ mới đến đâu
> - Câu 4 kiểm tra người gác cổng trong vòng tuần hoàn, phương án đúng là nghiệm thu nghiêm ngặt
> - Câu 5 kiểm tra kế thừa xuyên vòng đời, phương án đúng là "tài sản tách rời khỏi thể hiện vận hành, phiên mới có thể khôi phục nhận thức dự án bằng cách đọc kho". Khi đúng khẳng định học sinh có thể liên hệ với khái niệm trang này và giải thích căn cứ, khi sai yêu cầu quay lại phần giảng giải tìm bằng chứng hoặc ví dụ then chốt rồi phán đoán. Sau khi khám phá đa mục tiêu cánh siêu tới hạn kết thúc, nhóm để lại cấu hình hai lớp MetaDE có thể chạy và script huấn luyện mô hình đại diện, định nghĩa chỉ số đánh giá, trạng thái trung gian bao phủ khoảng tham số cánh và ràng buộc điều kiện hình học, và kết luận nghiệm thu vòng này. Câu 1 yêu cầu sắp xếp tài sản theo bốn loại mã, phương pháp, trạng thái, bằng chứng, và giải thích vai trò gác cổng của nghiệm thu—chỉ đầu ra qua nghiệm thu nghiêm ngặt mới được phép vào lớp tài sản, bốn loại tài sản phải được cố định thành bộ, thiếu một là không thể tái lập hoặc không thể kế thừa. Câu 2 yêu cầu so sánh "phát lại đối thoại lịch sử" và "đọc kho": cái trước phụ thuộc vào cửa sổ ngữ cảnh, chi phí tăng tuyến tính theo dự án, một khi đối thoại bị cắt nhận thức tức là mất
> - cái sau giảm chi phí kế thừa xuống checkout và tải, kết quả có thể đánh phiên bản, có thể tái lập, có thể kiểm toán, chi phí thử sai lặp lại vòng này từ đó lắng đọng thành điểm khởi đầu tái sử dụng vòng sau.

**Hoạt động trên lớp**

Yêu cầu học sinh dùng một ví dụ gần với kinh nghiệm của bản thân thuật lại nội dung trang này, và giải thích mối quan hệ giữa ví dụ đó với tiêu chuẩn phán đoán "người tiếp theo có thể tái lập nó mà không cần đến hỏi bạn không".

**Kiểm tra hiểu biết**

Ngẫu nhiên chọn một học sinh dùng lời của mình tổng kết trọng điểm trang này, giáo viên dựa vào trả lời bổ sung từ khóa còn thiếu, trọng tâm xác nhận học sinh có thể đồng thời nói ra hai điểm "phân công bốn loại tài sản" và "nghiệm thu là người gác cổng của lắng đọng".

> **Gợi ý chuyển tiếp**
>
> Sau khi xác nhận học sinh có thể nói ra mối quan hệ cốt lõi trang này—lắng đọng xảy ra trên hợp đồng ổn định, được nghiệm thu gác cổng, cuối cùng được kế thừa bằng cách đọc kho—rồi tiếp tục đi vào ứng dụng hoặc tổng kết ở trang tiếp theo.

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

### Mô hình kỹ thuật hợp tác đa Agent và phân rã nhiệm vụ đệ quy

*Trang 11*

> **Mục tiêu trang:** Hiểu cách nhiều Agent có vòng đời hữu hạn hợp tác hoàn thành phát triển dự án phức tạp và phân rã nhiệm vụ.

**Điểm giảng dạy chính**

- Khi phân rã nhiệm vụ, ưu tiên hỏi "lớp này phải giao ra cái gì có thể xác minh", chứ không phải trước tiên nghĩ "giao cho Agent nào". Sau khi交付物 (tập dữ liệu, giao diện, điểm kiểm tra, báo cáo đánh giá) được định nghĩa rõ ràng, ranh giới trách nhiệm và phân chia cấp bậc tự nhiên sẽ nổi lên.
- Điểm dừng của phân rã đệ quy không phải là "phân rã đến nhỏ nhất", mà là "phân rã đến có thể thực thi, có thể xác minh, có thể hoàn thành vòng tuần hoàn kín trong một ngữ cảnh của Agent đơn lẻ". Phân rã quá nông sẽ vượt quá năng lực lớp dưới, phân rã quá sâu sẽ mang lại chi phí phối hợp và bàn giao thêm.
- Chồng chéo trách nhiệm sẽ khiến nhiều Agent lặp lại triển khai cùng một việc, và sản xuất kết quả xung đột lẫn nhau. Dùng định nghĩa giao diện rõ ràng và tiêu chuẩn nghiệm thu cố định ranh giới, đồng thời thỏa thuận nội dung nào cho phép lớp dưới tự quyết, nội dung nào phải báo cáo nhiệm vụ cha phán quyết.

Mục tiêu trang

Khi dung lượng ngữ cảnh và năng lực xử lý của người thực thi đơn lẻ không đủ để承载 toàn bộ mục tiêu kỹ thuật, làm thế nào phân giải một vấn đề lớn thành một nhóm vấn đề nhỏ có thể bàn giao, và khiến kết quả hợp tác của các lớp có thể xác minh, có thể thu hồi.

Trình tự giảng giải

Trước tiên dùng "một vấn đề lớn phân giải thành một nhóm vấn đề nhỏ có thể bàn giao" để điểm đề, rồi triển khai theo cấu trúc ba lớp, sau đó giải thích động lực và điều kiện kết thúc của phân rã đệ quy, cuối cùng kết lại ở quan hệ bàn giao hai chiều của cây nhiệm vụ và ba gợi ý kỹ thuật. Khi giảng giải có thể phối hợp sơ đồ chỉ từng lớp xuống dưới chỉ định nút, giúp học sinh tương ứng phân công trừu tượng với cây nhiệm vụ cụ thể.

Điểm giảng dạy chính

1. Cấu trúc ba lớp và trách nhiệm của mỗi lớp. Người thực thi lớp trên hướng đến mục tiêu tổng thể, trả lời "cần làm gì", xuất ra nhiệm vụ con có thể ủy thác, điều kiện ràng buộc và tiêu chuẩn nghiệm thu; người thực thi lớp giữa tiếp nhận nhiệm vụ con vẫn còn quá lớn để tiếp tục phân rã đệ quy, thu gọn mục tiêu lớn lỏng lẻo thành cấp bậc nhiệm vụ ổn định; người thực thi lớp dưới hoàn thành triển khai cục bộ và kiểm thử trong ranh giới trách nhiệm, xuất ra kết quả có thể xác minh và bàn giao lên trên, tạo thành vòng tuần hoàn kín cục bộ. Trong sơ đồ, Agent lớp trên chia ra mô-đun nhiệm vụ A, B, C, mô-đun B vì vẫn còn quá nặng được tiếp tục chia thành nhiệm vụ con B1, B2, bốn nút lá cuối cùng mỗi cái rơi vào triển khai cục bộ và kiểm thử của Agent lớp dưới.

Lớp trên đứng ở nút gốc, đầu ra là nhiệm vụ có thể ủy thác và tiêu chuẩn nghiệm thu, chứ không phải tự mình hoàn thành triển khai.

2. Tại sao phải phân rã đệ quy. Cửa sổ ngữ cảnh, công cụ có thể gọi và quy mô nhiệm vụ có thể xử lý một lần của người thực thi đều hữu hạn. Nếu để người thực thi đơn lẻ giữ toàn bộ ngữ cảnh của cả dự án lâu dài, chi phí sẽ tăng theo quy mô, và dễ xuất hiện trôi dạt mục tiêu, ô nhiễm trạng thái và thông tin then chốt bị pha loãng. Phân rã đệ quy phân tán áp lực này đến các lớp: mỗi người thực thi chỉ cần hiểu mục tiêu và ràng buộc của lớp mình, mục tiêu phức tạp được phân giải từng lớp thành đơn vị công việc có thể thực thi, có thể bàn giao, tính nhất quán tổng thể được đảm bảo bởi cấp bậc nhiệm vụ.

Cây nhiệm vụ và bàn giao hai chiều. Nhiệm vụ cha và nhiệm vụ con tạo thành một cây nhiệm vụ đệ quy. Chảy xuống là ủy thác nhiệm vụ—mục tiêu, ràng buộc ranh giới và tiêu chuẩn nghiệm thu; chảy lên là thu hồi kết quả—đầu ra, bằng chứng xác minh và vấn đề chưa giải quyết. Hợp tác có thực sự thành lập hay không, phụ thuộc vào ba việc: cấp bậc nhiệm vụ có rõ ràng không, ranh giới trách nhiệm có loại trừ lẫn nhau không, sản phẩm bàn giao (định nghĩa giao diện, tập dữ liệu, ca kiểm thử, điểm kiểm tra) có được thỏa thuận rõ ràng không. Thiếu bất kỳ một cái nào, nhiều người thực thi sẽ thoái hóa thành lao động lặp lại và kết quả xung đột lẫn nhau.

Độ sâu phân rã, độ hạt ủy thác và chiến lược thu hồi kết quả, cũng có thể được liên tục đánh giá và điều chỉnh. Khi phản hồi như một nhiệm vụ con làm lại nhiều lần ảnh hưởng ngược lại đến cách phân rã lần sau, quy trình hợp tác này đã đi vào vòng tuần hoàn tự cải tiến.

5. Gợi ý kỹ thuật. Điều kiện dừng của phân rã đệ quy không phải là "phân rã đến nhỏ nhất", mà là "phân rã đến có thể thực thi, có thể xác minh, có thể hoàn thành vòng tuần hoàn kín trong một ngữ cảnh của người thực thi đơn lẻ". Phân rã quá nông sẽ vượt quá năng lực xử lý lớp dưới, phân rã quá sâu sẽ mang lại chi phí phối hợp và bàn giao lớn. Có thể định交付物 trước, rồi quyết định ai làm; ranh giới không rõ thường là chi phí hợp tác lớn nhất.

Xử lý bài tập

Trang này có một nhóm câu hỏi phán đoán khái niệm, đề nghị sau khi học sinh trả lời yêu cầu chỉ ra căn cứ, chứ không chỉ nói ra phương án.

Câu trả lời đúng là "hiểu mục tiêu tổng thể, và phân rã nó thành nhiệm vụ con có thể ủy thác và tiêu chuẩn nghiệm thu". Nếu học sinh chọn sai, gợi ý quay lại định vị nút gốc—đầu ra là nhiệm vụ và tiêu chuẩn nghiệm thu, chứ không phải mã本身.

Câu trả lời đúng là "khi nhiệm vụ con vẫn còn quá phức tạp, vượt quá phạm vi xử lý đơn lẻ". Cần nhấn mạnh đệ quy không phải hành động vô điều kiện, điều kiện kích hoạt là nhiệm vụ con vẫn còn quá lớn, không thể hoàn thành và xác minh trong một lần xử lý.

Nếu chỉ có gửi nhiệm vụ xuống sẽ thế nào? Nếu chỉ có thu hồi kết quả lại thế nào? Từ đó giải thích hợp tác phải hai chiều.

Câu trả lời đúng là "phân tán ngữ cảnh và áp lực xử lý đến các lớp, giảm gánh nặng ngữ cảnh điểm đơn và rủi ro trôi dạt mục tiêu". Từ cốt lõi là "phân tán", chứ không phải "đảm bảo thành công một lần".

Câu trả lời đúng là "giữ cho nút lá giữ đơn vị công việc có thể thực thi, có thể bàn giao, và làm rõ giao diện và đầu ra kiểm thử". Có thể nhân đây ôn lại: ranh giới mờ hoặc hủy cấp bậc, đều dẫn đến triển khai lặp lại và xung đột kết quả.

Hoạt động trên lớp

Nghiên cứu tình huống "bàn giao hợp tác hệ thống kiểm tra chất lượng chăm sóc khách hàng thông minh" phù hợp làm hoạt động nhóm. Trước tiên cho học sinh vẽ cây nhiệm vụ đệ quy: nút gốc chịu trách nhiệm hiểu mục tiêu tổng thể và xuất ra ba nhiệm vụ con A, B, C và tiêu chuẩn nghiệm thu; mô-đun B do lớp giữa tiếp tục chia thành B1, B2, và làm rõ giao diện hai cái; nút lá là bốn loại đơn vị công việc A, B1, B2, C. Rồi yêu cầu mỗi nhóm liệt kê sản phẩm bàn giao hai hướng xuống và lên, ví dụ đặc tả giao diện dữ liệu và tập dữ liệu đối thoại đã làm sạch, từ điển đặc trưng và đặc tả gán nhãn, điểm kiểm tra mô hình và báo cáo xác minh, chỉ số đánh giá và cấu hình triển khai, và giải thích tại sao nút lá đã thỏa mãn điều kiện dừng.

Đối với câu hỏi truy vấn B1 phát hiện "đặc tả gán nhãn" và "chỉ số đánh giá" xung đột, có thể hướng dẫn học sinh tổng kết nguyên tắc xử lý: xung đột thăng cấp phán quyết, không tự sửa tiêu chuẩn nghiệm thu; giao diện và tiêu chuẩn giữ nguồn đơn nhất, do lớp trên thống nhất duy trì; trước khi phán quyết vẫn giữ vòng tuần hoàn kín cục bộ có thể xác minh; kết quả phán quyết cập nhật ngược lại cây nhiệm vụ và đầu vào nhiệm vụ con liên quan; ghi lại toàn bộ xung đột, căn cứ phán quyết và tiêu chuẩn cuối cùng để truy vết.

Kiểm tra hiểu biết

Lớp trên chịu trách nhiệm gì, đệ quy tiếp tục trong điều kiện nào, hai hướng trên dưới mỗi cái truyền thông tin gì. Nếu có thể đồng thời nói ra điều kiện dừng và "định交付物 trước rồi định phân công", có thể coi là nắm vững trang này.

Gợi ý chuyển tiếp

Sau khi xác nhận học sinh có thể phân biệt "phân rã nhiệm vụ" và "tự mình triển khai", và có thể nói rõ bàn giao hai chiều của cây nhiệm vụ, hãy tiếp tục đi vào thảo luận trang tiếp theo về cơ chế xác minh và lắng đọng, để kết nối mô hình phân công trang này với các khâu biên dịch, kiểm thử, nghiệm thu tiếp theo.

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

### Cơ chế nghiệm thu nghiêm ngặt và kế thừa lịch sử

*Trang 12*

> **Mục tiêu trang:** Nắm vững cách thông qua biên dịch, kiểm thử và cổng nghiệm thu để lắng đọng các thay đổi hiệu quả thành lịch sử dự án.

> **Trình tự giảng giải**
>
> Trước tiên dùng một câu chỉ ra "khi thấy bất kỳ hệ thống 'tự động sinh và tự động cải tiến' nào, hỏi trước ba câu: đầu ra của Agent mặc định có thân phận gì (ứng viên?), phải qua những xác minh nào mới được chấp nhận (nghiệm thu?), sau khi chấp nhận trở thành nền tảng của ai (đường cơ sở?). Tách ba việc này ra, logic tổng thể của cơ chế sẽ không rối.", rồi phối hợp với ví dụ, sơ đồ hoặc từ khóa trên trang giải thích tại sao nó quan trọng.

**Điểm giảng dạy chính**

- Đầu ra của Agent mặc định có thân phận gì (ứng viên?), phải qua những xác minh nào mới được chấp nhận (nghiệm thu?), sau khi chấp nhận trở thành nền tảng của ai (đường cơ sở?). Tách ba việc này ra, logic tổng thể của cơ chế sẽ không rối.
- Biên dịch → kiểm thử → kiểm tra hành vi → nghiệm thu lớp trên, là con đường xuống dốc "chi phí từ thấp đến cao": càng rẻ càng ở trước, càng đắt càng ở sau. Nhớ "rẻ thì sàng trước, quý thì xét sau", sẽ không lãng phí đánh giá lớp trên vào lượng lớn ứng viên rác.
- Nghiệm thu đạt không đồng nghĩa với thực sự tốt hơn. Khi độ phủ kiểm thử không đủ hoặc kiểm tra hành vi thiếu, cổng sẽ cho qua thay đổi có hại. Nuôi hai thói quen: bổ sung ca kiểm thử hồi quy và định nghĩa dung sai cho hành vi then chốt
- luôn giữ chỉ số có thể quan sát và lấy mẫu thủ công, làm phòng tuyến cuối cùng khi tiêu chuẩn không hoàn chỉnh.

Cơ chế nghiệm thu nghiêm ngặt và kế thừa lịch sử

11

AI999

Genesis và sự lắng đọng của thế giới phần mềm

Các thay đổi do Agent tự động sinh ra, dựa vào đâu có thể được ghi vào nhánh chính dự án? Cơ chế nghiệm thu nghiêm ngặt và kế thừa lịch sử tách rời hoàn toàn sinh và chấp nhận—bất kỳ mã nào Agent gửi đều chỉ là thay đổi ứng viên (candidate patch), phải qua một nhóm cổng xác minh trước, mới có tư cách được công nhận là một phần lịch sử dự án.

Thay đổi ứng viên → bốn lớp cổng nghiệm thu → nhánh chính / từ chối phân luồng hàng đợi thay đổi ứng viên Agent gửi · mặc định không đáng tin ứng viên A chờ xác minh ứng viên B chờ xác minh ứng viên C chờ xác minh ứng viên D chờ xác minh ① Cổng biên dịch cú pháp và giao diện có thể xây dựng · chi phí thấp nhất, loại bỏ nhanh nhất ② Cổng kiểm thử kiểm thử đơn vị/tích hợp toàn xanh · bao phủ hợp đồng hiện có ③ Cổng kiểm tra hành vi ngữ nghĩa nhất quán · dung sai số trị và tương đương ④ Nghiệm thu lớp trên hiệu năng · tỷ lệ tăng tốc · khả năng bảo trì từ chối · khu hồ sơ thất bại · giữ làm mẫu âm và tài liệu chẩn đoán · cách ly lưu trữ, không ô nhiễm nhánh chính · từ chối tự nó là lọc nhiễu · tránh khám phá lặp lại cùng một đường chết lịch sử phiên bản nhánh chính (tích lũy đơn điệu) đường cơ sở v3 · có thể kế thừa, có thể truy vết đường cơ sở v2 đường cơ sở v1 phản hồi kế thừa lịch sử: đường cơ sở đã được chấp nhận trở thành điểm khởi đầu thực thi của Agent sau nguyên tắc mặc định ứng viên đầu ra của Agent mặc định được coi là đầu vào không đáng tin: nó cách ly nghiêm ngặt với phiên bản đã được chấp nhận về quyền hạn, lưu trữ và tham chiếu, không thể trực tiếp đọc ghi nhánh chính, cũng không thể được các mô-đun khác coi là phụ thuộc ổn định.

Mục đích duy nhất của nguyên tắc này, chính là chặn đứng "sinh là nhập kho". Chỉ sau khi qua toàn bộ cổng, thay đổi ứng viên mới có được địa vị ngang với nhánh chính. Bốn lớp lọc tiến dần: chi phí tăng dần, thất bại càng sớm càng tốt biên dịch: cấp cú pháp và giao diện có thể xây dựng. Chi phí thấp nhất, loại bỏ nhanh nhất, trước tiên chặn những thay đổi rõ ràng không thành lập ngoài cửa. Kiểm thử: kiểm thử đơn vị và tích hợp đạt, bao phủ hợp đồng hiện có. Kiểm tra hành vi: ngữ nghĩa và hành vi nhất quán, bao gồm dung sai số trị, tương đương và so sánh hồi quy, chuyên phòng ngừa "kiểm thử đạt nhưng hành vi trôi dạt". Nghiệm thu lớp trên: phán quyết cuối cùng hướng đến mục tiêu nhiệm vụ và ràng buộc kỹ thuật, bao gồm phán đoán hiệu năng, tỷ lệ tăng tốc, khả năng bảo trì.

Cổng được sắp xếp theo chi phí từ thấp đến cao, khiến phần lớn thay đổi vô hiệu bị cắt ở giai đoạn rẻ, để lại đánh giá lớp trên đắt đỏ cho số ít ứng viên chất lượng cao—đây chính là kinh tế học của "thất bại càng sớm càng tốt". Giá trị của từ chối và kế thừa lịch sử những thử nghiệm không vượt qua không đi vào nhánh chính, nhưng có thể giữ làm hồ sơ thất bại/mẫu âm, dùng cho chẩn đoán, khử trùng lặp và ngăn ngừa khám phá lặp lại—từ chối tự nó là một lần lọc nhiễu. Còn thay đổi qua nghiệm thu trở thành phiên bản đường cơ sở mới, người thực thi sau tiếp tục tiến hóa trên cơ sở này, tạo thành chuỗi tiến hóa tích lũy đơn điệu, chứ không phải mỗi vòng bắt đầu lại từ số không. Là quy tắc hợp nhất và hợp đồng chất lượng của hợp tác đa Agent và phân rã nhiệm vụ đệ quy, cổng nghiệm thu định nghĩa "ai có thể viết vào lịch sử", từ đó quyết định kết quả hợp tác là hội tụ hay tăng熵.

Trong các kịch bản ràng buộc tính đúng đắn mạnh như tái cấu trúc trình biên dịch và nâng cấp phần mềm khoa học, cơ chế này thể hiện độ tin cậy cực cao, và mang lại tỷ lệ tăng tốc vận hành đáng kể. Ranh giới thất bại tính hoàn chỉnh của tiêu chuẩn nghiệm thu tự nó sẽ trở thành nút thắt mới: khi độ phủ kiểm thử không đủ hoặc kiểm tra hành vi thiếu, cổng sẽ cho qua thay đổi "qua nghiệm thu nhưng thực tế có hại". Do đó cần dùng chỉ số có thể quan sát và lấy mẫu thủ công để đỡ, và liên tục tăng cường ca kiểm thử hồi quy và định nghĩa dung sai.

Trong cơ chế nghiệm thu nghiêm ngặt, mã Agent gửi mặc định ở địa vị gì?

Thành phẩm do bên gửi tự phán đoán có khả dụng hay không

Phiên bản chính thức có thể hợp nhất trực tiếp vào nhánh chính

Thay đổi ứng viên chờ xác minh, cách ly nghiêm ngặt với phiên bản đã được chấp nhận về quyền hạn, lưu trữ và tham chiếu

Sản phẩm phụ chỉ dùng để ghi log, không tham gia bất kỳ quy trình nào

Mặc định ứng viên coi đầu ra của Agent là đầu vào không đáng tin, cách ly nghiêm ngặt với nhánh chính, từ chế độ tránh "sinh là nhập kho".

Đầu ra chưa được xác minh không nên có địa vị ngang với phiên bản đã được chấp nhận.

Đúng. Câu trả lời này có thể liên hệ với khái niệm trang này, và giải thích căn cứ.

Hãy quay lại phần giảng giải trang này, tìm bằng chứng hoặc ví dụ then chốt rồi phán đoán.

Bốn lớp cổng nghiệm thu được sắp xếp theo thứ tự nào, ý đồ thiết kế là gì?

Theo chi phí từ cao đến thấp, ưu tiên đầu tư tài nguyên vào đánh giá lớp trên đắt đỏ nhất

Theo thời gian gửi ứng viên, đến trước xác minh trước

Theo thứ tự ngẫu nhiên, để tăng tính đa dạng xác minh

Biên dịch → kiểm thử → kiểm tra hành vi → nghiệm thu lớp trên, khiến phần lớn thay đổi vô hiệu bị cắt ở giai đoạn rẻ

Cổng rẻ chịu trách nhiệm loại bỏ quy mô lớn, cổng đắt chỉ đối mặt với số ít ứng viên chất lượng cao.

Nghĩ xem lớp nào đắt nhất, lớp nào nhanh nhất. Thứ tự cổng nên khiến đánh giá đắt đỏ ít gặp ứng viên rác nhất có thể.

Kiểm tra hành vi (lớp cổng thứ ba) chủ yếu phòng ngừa loại vấn đề nào?

Số lượng ca kiểm thử đơn vị viết không đủ nhiều

"Kiểm thử đạt nhưng hành vi trôi dạt", tức là triển khai mới cũ không nhất quán về ngữ nghĩa hoặc đầu ra số trị

Lỗi cú pháp mã khiến hoàn toàn không thể biên dịch

Lịch sử phiên bản nhánh chính chiếm quá nhiều dung lượng lưu trữ

Kiểm tra hành vi dùng dung sai số trị, tương đương và so sánh hồi quy để đối chiếu nhất quán ngữ nghĩa, chặn hành vi trôi dạt mà độ phủ kiểm thử không chạm tới.

Lớp biên dịch quản "có thể xây dựng hay không", lớp kiểm thử quản "hợp đồng có được thỏa mãn hay không", kiểm tra hành vi quan tâm đến trôi dạt ngữ ngh