8. Vòng Lặp Nâng Cấp Tự Động (Harness Flywheel) & Phòng Chống Suy Thoái (Harness Decay)

Đội ngũ kỹ thuật non trẻ chỉ chăm chăm sửa lại kết quả đầu ra bị sai của một lần chạy. Đội ngũ kỹ thuật đẳng cấp sửa chính cái hệ thống đã cho phép lỗi đó xuất hiện. Mỗi lần thất bại phải để lại một lớp hạ tầng bảo vệ, tạo nên bánh đà hoàn thiện liên tục (Harness Flywheel).

🪜 Thang Chỉ Dẫn (Instruction Ladder)

Nếu một quy tắc quan trọng xuất hiện nhiều lần, hãy di chuyển nó xuống tầng sâu hơn trong ngăn xếp kỹ thuật:

[Tầng 1: Prompt mềm]         -> Dễ bị quên khi context dài (Dùng cho phán đoán linh hoạt)
│
▼
[Tầng 2: Local Rules/SOP]    -> File chỉ dẫn cấu trúc (như AGENTS.md, SOUL.md, SKILL.md)
│
▼
[Tầng 3: Tool Validator]     -> Kiểm tra kiểu dữ liệu trong mã nguồn Python/TypeScript
│
▼
[Tầng 4: CI/CD & Gatekeeper] -> Lệnh test tự động chặn không cho commit (Hạ tầng cứng 100%)

Prompt giải thích phán đoán (Judgment). Harness thực thi các điều kiện bất biến (Invariants).

🧾 Biên Lai Thay Đổi Sau Mỗi Lần Chạy (Change Receipt)

Đọc một transcript hội thoại 50 trang của Agent là cực hình đối với người quản lý. Kết thúc mỗi phiên làm việc, Harness phải tự động lập một Biên lai thay đổi (Change Receipt):

• Không tóm tắt những gì mô hình đã nói.
• Chỉ tóm tắt những gì hệ thống có thể chứng minh bằng dữ liệu thực tế.

# CHANGE RECEIPT - SES-2026-09-08
- Target Outcome: Tích hợp bài giảng 36 vào Cổng Doanh Nghiệp.
- Files Modified:
* [NEW] scripts/add_harness_engineering_course.py (+480 lines)
* [MODIFY] app.py (+1 entry in group_specs)
- Deterministic Checks:
* pytest: 20/20 PASSED
* audit_gatekeeper: 54/54 PASSED
* static_build: 430 pages generated, 0 broken links
- Remaining Risks / Human Attention Needed: Không có. Sản phẩm sẵn sàng triển khai.

🔄 Bánh Đà Tiến Hóa & Phòng Chống Suy Thoái (Harness Decay)

Một Harness xuất sắc không phải là một bộ máy cồng kềnh đầy rẫy rào chắn cũ kỹ. Khi mô hình LLM ngày càng thông minh hơn, những rào chắn viết cho model ngày hôm qua có thể trở thành lực cản kìm hãm model của ngày hôm nay.


Nguyên lý 'Build to Delete' (Xây dựng để sẵn sàng đào thải):

Định kỳ đo lường từng bộ router, bộ lọc ngữ cảnh, lớp retry xem nó còn mang lại giá trị gia tăng (Lift) hay không:

• Rào chắn này đang ngăn chặn loại lỗi nào?
• Lỗi đó còn xảy ra với model thế hệ mới không?
• Nó làm tăng thêm bao nhiêu độ trễ và độ phức tạp?
• Chuyện gì xảy ra nếu chúng ta xóa bỏ nó?

Thước đo hiệu quả tối thượng:

Đừng đo số lượng token hay số lần chạy task. Thước đo thực chất của hệ thống Agent là:

$$\text{Hiệu quả} = \frac{\text{Số đầu việc hoàn thành được nghiệm thu (Accepted Work)}}{\text{Thời lượng chú ý của con người cần can thiệp (Human Attention)}}$$