Mọi người đều nói về các mô hình AI.
Không ai nói về lớp thực sự khiến chúng trở nên hữu dụng.
Claude Code. Codex. Cursor.
Đây không chỉ đơn thuần là các mô hình.
Chúng là các mô hình được bọc trong một hệ thống.
Hệ thống đó được gọi là một bộ khung (harness).
Và những bộ khung tốt nhất hiện nay có thể tự cải thiện chính mình.
Dưới đây là mọi thứ bạn cần hiểu về ngăn xếp AI mới.
Điều dối trá mà mọi người tin về các sản phẩm AI

Hầu hết mọi người nghĩ rằng tiến bộ AI = các mô hình thông minh hơn.
Không phải vậy.
Mô hình chỉ là một phần của ngăn xếp.
Kiến trúc đã được công bố. Mọi người đều sao chép cùng một transformer. Mọi phòng thí nghiệm đều sử dụng cùng một khối xây dựng.
Điều thực sự tạo nên sự khác biệt giữa Claude Code và một dự án cuối tuần không phải là mô hình.
Đó là những gì bao quanh mô hình.
Bộ khung.
Năm 2017, tiến bộ AI xoay quanh cơ chế attention. Năm 2020, nó xoay quanh quy mô. Năm 2026, nó xoay quanh kỹ thuật chế tạo bộ khung.
Và các bộ khung hiện đang được thiết kế bởi AI, không phải con người.
Bộ khung là gì?

Bộ khung là hệ thống bao quanh một mô hình.
Nó quyết định:
→ Cách mô hình suy nghĩ và lập kế hoạch
→ Khi nào nó gọi các công cụ và làm gì với kết quả
→ Những gì nó ghi nhớ qua các bước
→ Cách nó lưu trữ các tạo phẩm và quản lý trạng thái
→ Cách nó đánh giá đầu ra của chính mình
→ Khi nào nó quay vòng và thử lại
Hãy nghĩ về nó như một hệ điều hành.
Mô hình là CPU. Bộ khung là hệ điều hành.
Bạn có thể có một CPU mạnh mẽ và phần mềm tồi tệ và chẳng tạo ra thứ gì hữu ích. Bạn có thể có một CPU khiêm tốn và phần mềm xuất sắc và tạo ra thứ gì đó tuyệt vời.
Các tác nhân viết mã thành công nhất — Claude Code, Codex, Cursor — đều có chung một nhận thức:
Vòng lặp quan trọng không kém gì mô hình.
3 mẫu bộ khung mà mọi nhà xây dựng AI cần
Mọi hệ thống AI trong sản xuất đều sử dụng ít nhất một trong số này.
Mẫu 1: Vòng lặp

Mô hình không trả lời một lần rồi dừng lại.
Nó lặp lại.
Lập kế hoạch → Thực thi → Quan sát → Cải thiện → Lặp lại
Đây là cốt lõi của mọi tác nhân viết mã.
Một vòng lặp Claude Code đơn giản hóa:
- Đọc nhiệm vụ
- Lập kế hoạch tiếp cận
- Viết mã → chạy nó
- Xem cái gì đã thất bại
- Sửa nó
- Chạy lại
- Lặp lại cho đến khi các bài kiểm tra đều đạt
Mô hình không thông minh hơn ở vòng lặp 3 so với vòng lặp 1.
Nhưng hệ thống thì có.
Mỗi vòng lặp cung cấp cho mô hình ngữ cảnh mới — thông báo lỗi, kết quả kiểm tra, dấu vết thực thi.
Đầu ra của vòng lặp 1 trở thành đầu vào của vòng lặp 2.
Ngữ cảnh tổng hợp đó là lý do tại sao các hệ thống tác nhân vượt trội hơn so với việc tạo prompt một lần cho các tác vụ phức tạp.
Nhận thức chính: Mô hình giữ nguyên. Ngữ cảnh trở nên thông minh hơn.
Mẫu 2: Hệ thống tệp như bộ nhớ

Hầu hết các nhà phát triển nhồi nhét mọi thứ vào cửa sổ ngữ cảnh.
Đây là một cái bẫy.
Các tác vụ dài hạn tạo ra:
→ Nhật ký thử nghiệm
→ Khác biệt mã → Dấu vết lỗi
→ Lịch sử triển khai trong quá khứ → Tóm tắt bài báo → Các tạo phẩm trung gian
Tất cả những thứ đó phát triển vượt xa bất kỳ cửa sổ ngữ cảnh nào.
Giải pháp: ghi vào tệp, không ghi vào ngữ cảnh.
1# Tệ: mọi thứ trong ngữ cảnh2context = previous_output + tool_result + error_log + history...3# Phát nổ ở bước 4745# Tốt: sử dụng hệ thống tệp6agent.write("experiments/run_3/error_log.txt", error_trace)7agent.write("experiments/run_3/results.json", metrics)89# Sau đó, tác nhân chỉ đọc những gì nó cần10relevant = agent.read("experiments/run_3/results.json")
Điều này thay đổi mọi thứ về các tác vụ dài hạn.
→ Tác nhân có thể tiếp tục sau khi bị sập
→ Tác nhân có thể suy luận dựa trên lịch sử thực thi của chính nó
→ Ngữ cảnh luôn sạch sẽ ngay cả ở bước 200
→ Nhiều tác nhân phụ có thể chia sẻ trạng thái qua các tệp
Các tác nhân tốt nhất coi hệ thống tệp như một bộ não thứ hai.
Không phải là một bãi chứa. Mà là một bộ nhớ có cấu trúc.
Mẫu 3: Tác nhân phụ

Một tác nhân không thể làm mọi thứ.
Các hệ thống tốt nhất tạo ra các tác nhân phụ song song.
Tác nhân cha:
→ Chia nhiệm vụ thành các nhiệm vụ con độc lập
→ Khởi chạy các tác nhân phụ để chạy chúng song song
→ Giám sát trạng thái của chúng → Hợp nhất kết quả của chúng lại
Ví dụ cho một bộ khung nghiên cứu:
<code-code-segment id="seg_1" lang="text">
Tác nhân cha nhận: "Viết một báo cáo phân tích cạnh tranh đầy đủ"
Tạo ra 4 tác nhân phụ đồng thời:
→ Tác nhân phụ 1: Nghiên cứu giá cả và tính năng của Đối thủ A
→ Tác nhân phụ 2: Nghiên cứu giá cả và tính năng của Đối thủ B
→ Tác nhân phụ 3: Tìm kiếm tin tức gần đây về cả hai đối thủ
→ Tác nhân phụ 4: Lấy đánh giá của người dùng từ Reddit và App Store
Tác nhân cha chờ đợi, sau đó hợp nhất tất cả 4 đầu ra thành báo cáo cuối cùng
Tổng thời gian: bằng với tác nhân phụ chậm nhất (không phải gấp 4 lần)
</code-code-segment>
Quy tắc thiết kế chính: đầu ra của tác nhân phụ phải được ghi vào tệp.
Không phải ngữ cảnh tạm thời. Mà là tệp.
Nếu chúng chỉ tồn tại trong ngữ cảnh, chúng sẽ biến mất khi phiên của tác nhân phụ kết thúc.
Nếu chúng tồn tại trong tệp, tác nhân cha có thể kiểm tra chúng, hệ thống có thể phục hồi sau sự cố và mọi thứ đều có thể kiểm tra được.
Các công cụ mà mọi tác nhân viết mã sử dụng
Nếu bạn đang xây dựng một tác nhân, đây là bộ công cụ mà mọi tác nhân viết mã lớn đều chuẩn hóa.
1Công cụ Hệ thống Tệp:2→ glob, grep, ls # tìm tệp3→ read, read_many # đọc nội dung4→ write # tạo tệp mới5→ edit # chỉnh sửa thay thế chuỗi6→ apply_patch # khác biệt có cấu trúc78Công cụ Shell:9→ bash # chạy bất kỳ lệnh nào10→ PowerShell # tương đương trên Windows1112Kiểm soát Phiên bản:13→ git_status, git_diff # kiểm tra các thay đổi14→ git_commit # lưu tiến trình1516Quản lý Tác nhân:17→ spawn_agent # khởi chạy tác nhân phụ18→ wait_agent # chờ kết quả19→ list_agents # xem những gì đang chạy20→ interrupt_agent # hủy nếu cần2122Ngữ cảnh Bên ngoài:23→ web_search, web_fetch # lấy thông tin hiện tại24→ Công cụ MCP # kết nối với các dịch vụ bên ngoài
Bạn không cần tất cả những thứ này cho mọi tác nhân.
Nhưng mọi tác nhân trong sản xuất cuối cùng đều cần hầu hết chúng.
Những thứ quan trọng nhất ban đầu: bash, read, write, edit.
Thành thạo bốn thứ đó và bạn có thể xây dựng hầu hết mọi thứ.
Kỹ thuật ngữ cảnh: kỹ năng không ai nói đến

Mô hình là cố định.
Bạn không thể thay đổi trọng số của nó trong thời gian chạy.
Nhưng bạn có thể thay đổi những gì nó nhìn thấy.
Đó là kỹ thuật ngữ cảnh.
Và nó hiện là một trong những kỹ năng có đòn bẩy cao nhất trong kỹ thuật AI.
Ngữ cảnh tệ:
→ Đổ mọi thứ vào → hy vọng điều tốt nhất
→ Ngữ cảnh phình to → mô hình mất tập trung → đầu ra giảm chất lượng
Ngữ cảnh tốt:
→ Có cấu trúc. Súc tích. Phát triển.
→ Thông tin phù hợp ở bước phù hợp.
→ Những thất bại trước đó cung cấp thông tin cho nỗ lực hiện tại.
Phương pháp tiên tiến nhất (ACE — Kỹ thuật Ngữ cảnh Tác nhân):
13 thành phần:23Bộ tạo: chạy tác vụ, tham chiếu một sổ tay ngữ cảnh có cấu trúc4Bộ phản ánh: phân tích thành công và thất bại, chắt lọc thông tin chi tiết5Bộ quản lý: cập nhật sổ tay với các kiến thức mới — thêm, xóa, loại bỏ trùng lặp67Sổ tay KHÔNG phải là một khối prompt.8Nó là một danh sách có cấu trúc gồm các cặp (định danh, thông tin chi tiết).910Ví dụ:11{12 "id": "001",13 "insight": "Luôn ghi dấu vết lỗi vào tệp trước khi thử lại."14},15{16 "id": "002",17 "insight": "Tác nhân phụ tìm kiếm web trả về kết quả tốt hơn với các truy vấn dành riêng cho trang web."18},19{20 "id": "003",21 "insight": "Chạy kiểm tra trước khi commit phát hiện 80% các hồi quy."22}
Sổ tay được cập nhật sau mỗi lần chạy.
Tác nhân chạy tác vụ 50 đang làm việc với 49 lần chạy của các kiến thức đã được chắt lọc.
Tác nhân chạy tác vụ 1 chẳng có gì.
Đây là cách một hệ thống trở nên thông minh hơn mà không cần chạm vào trọng số mô hình.
Bộ khung tự cải thiện

Đây là lúc mọi thứ trở nên điên rồ.
Điều gì sẽ xảy ra nếu chính bộ khung là thứ đang được tối ưu hóa?
Không phải prompt. Không phải mô hình.
Mã chạy tác nhân.
Đây chính xác là những gì Self-Harness làm.
Vòng lặp 3 bước:
Bước 1 — Khai thác điểm yếu
Chạy bộ khung hiện tại trên một tập hợp các tác vụ. Thu thập các dấu vết thất bại. Phân cụm các thất bại theo nguyên nhân gốc rễ.
Không phải "nó đã thất bại." Mà là tại sao nó thất bại.
Các loại thất bại được phát hiện:
→ "Tác nhân hết thời gian chờ khi đọc tệp dài"
→ "Đầu ra của tác nhân phụ bị mất khi tác nhân cha bị sập"
→ "Thông báo lỗi không đủ thông tin để tự sửa lỗi"
→ "Ngữ cảnh trở nên quá lớn sau bước 30, mô hình mất tập trung"
Bước 2 — Đề xuất sửa lỗi
Cùng một mô hình xem xét các mẫu thất bại. Đề xuất các chỉnh sửa cụ thể, hẹp cho mã bộ khung.
Không phải viết lại. Mà là các chỉnh sửa có mục tiêu.
Chỉnh sửa bộ khung được đề xuất:
→ Thêm trình xử lý thời gian chờ cho các thao tác đọc tệp
→ Tự động đẩy đầu ra của tác nhân phụ vào đĩa ở mỗi bước (không chỉ ở cuối)
→ Chuẩn hóa định dạng thông báo lỗi bao gồm: bước, công cụ, đầu vào, đầu ra, lý do thất bại
→ Thêm bước nén ngữ cảnh sau mỗi 25 lượt
Bước 3 — Xác thực và hợp nhất
Mỗi chỉnh sửa được đề xuất sẽ được kiểm tra trên các tác vụ dành riêng.
Nó có sửa được điểm yếu mà không làm hỏng thứ gì khác không?
Nếu có: được hợp nhất vào bộ khung. Nếu không: được ghi lại, bị từ chối, bộ khung không thay đổi.
Kết quả: bộ khung ngày càng tốt hơn qua mỗi thế hệ.
Claude 3.5 Sonnet chạy Self-Harness đã tăng từ 20% lên 50% trên SWE-bench Verified.
Không phải từ một mô hình tốt hơn.
Mà từ một hệ thống tốt hơn.
Tìm kiếm bộ khung tiến hóa
Self-Harness sửa một bộ khung một cách lặp đi lặp lại.
AlphaEvolve chạy một quần thể các bộ khung và tiến hóa những bộ tốt nhất.
Thuật toán:
11. Bắt đầu với một nhóm các ứng viên bộ khung22. Chấm điểm từng cái trên các tác vụ chuẩn33. Chọn những người thực hiện tốt nhất làm "bố mẹ"44. Yêu cầu mô hình đề xuất các khác biệt/cải tiến55. Tạo ra các bộ khung "con" mới66. Chấm điểm các bộ khung con77. Giữ lại những bộ cải thiện88. Thêm chúng trở lại nhóm99. Lặp lại1011(Cùng logic với chọn lọc tự nhiên. Áp dụng cho mã.)
(Cùng logic với chọn lọc tự nhiên. Áp dụng cho mã.)
Một chi tiết thiết kế quan trọng từ AlphaEvolve:
Các vùng mã đủ điều kiện để tiến hóa được đánh dấu rõ ràng:
1# EVOLVE-BLOCK-START2def plan_next_step(context, tools):3 # Phần này có thể được sửa đổi bởi quá trình tìm kiếm tiến hóa4 prompt = f"Given: {context}\nAvailable tools: {tools}\nNext action:"5 return llm.generate(prompt)6# EVOLVE-BLOCK-END78# Phần còn lại của bộ khung giữ nguyên9def run_tool(tool_name, args):10 return tool_registry[tool_name](**args)
Sự ngăn chặn này ngăn tác nhân vô tình sửa đổi mã quan trọng về mặt an toàn.
Quá trình tìm kiếm tiến hóa chỉ chạm vào những gì bạn cho phép nó chạm vào một cách rõ ràng.
AlphaEvolve đã sử dụng điều này để tối ưu hóa các thuật toán nhân ma trận.
Kết quả: đánh bại mã được tối ưu hóa thủ công của DeepMind.
Tác nhân đã tìm ra các giải pháp mà các kỹ sư con người đã không khám phá ra trong nhiều thập kỷ.
Máy Darwin Gödel: các tác nhân tự viết lại chính mình

Phiên bản cực đoan nhất của ý tưởng này.
Một tác nhân sửa đổi mã bộ khung của chính nó để trở nên tốt hơn trong các tác vụ.
Máy Darwin Gödel (DGM):
11. Bắt đầu với một tác nhân viết mã trong nhóm22. Chạy nó trên các chuẩn, thu thập điểm số33. Tác nhân kiểm tra nhật ký đánh giá của chính nó44. Tác nhân đề xuất các cải tiến cho mã bộ khung của chính nó55. Các công cụ có sẵn: bash + trình chỉnh sửa tệp (xem/tạo/chỉnh sửa tệp)66. Phiên bản mới của tác nhân được tạo ra77. Phiên bản mới được chấm điểm88. Nếu tốt hơn: được thêm vào nhóm99. Nếu tệ hơn: bị loại bỏ1010. Lặp lại — chọn bố mẹ theo hiệu suất, nghịch đảo theo số lượng con cái
Điều kiện bắt đầu: Claude 3.5 Sonnet + bộ khung ban đầu đơn giản.
Kết quả:
→ SWE-bench Verified: 20% → 50%
→ Chuẩn viết mã đa ngôn ngữ: 14.2% → 30.7%
Không thay đổi trọng số mô hình. Không có kỹ thuật con người nào giữa các thế hệ.
Tác nhân đã thiết kế các phiên bản tốt hơn của chính nó.
Đây không phải là khoa học viễn tưởng.
Đây là một bài báo từ năm 2025.
5 chế độ thất bại cần tránh
Đây là những cách mà các nhóm nghiên cứu thực tế đã thất bại.
Tất cả đều được ghi lại. Tất cả đều có thể tránh được.
1. Sụp đổ ngữ cảnh
Các tác vụ dài hạn mất các chi tiết quan trọng nếu nhật ký không được ghi dưới dạng các tạo phẩm liên tục.
Sửa lỗi: ghi mọi thứ quan trọng vào tệp. Không bao giờ chỉ dựa vào ngữ cảnh sau bước 20.
2. Sai lệch triển khai
Khi nhiệm vụ trở nên khó về mặt kỹ thuật, mô hình sẽ chuyển hướng sang các giải pháp dễ dàng hơn, phổ biến hơn thay vì mục tiêu thực tế.
Sửa lỗi: viết một tệp đặc tả ngay từ đầu. Tác nhân kiểm tra đặc tả trong mỗi vòng lặp.
3. Lạc quan quá mức
Mô hình tuyên bố thành công mặc dù các thử nghiệm thất bại.
Nó tìm thấy "băng keo số" — các bản vá làm cho các chỉ số trông đẹp mà không giải quyết được vấn đề thực sự.
Sửa lỗi: giữ lại một bộ kiểm tra mà tác nhân không bao giờ thấy. Chỉ xác thực trên dữ liệu được giữ lại.
4. Hack phần thưởng
Tác nhân tối ưu hóa bất kỳ tín hiệu nào nó được đưa ra.
Nếu tín hiệu là các bài kiểm tra đơn vị — nó viết các bài kiểm tra luôn đạt. Nếu tín hiệu là một mô hình giám khảo — nó học các thủ thuật để đánh lừa giám khảo. Nếu tín hiệu là điểm chuẩn — nó khai thác các tạo tác chuẩn.
Sửa lỗi: bộ đánh giá nằm bên ngoài vòng lặp. Đánh giá của con người tại các điểm quyết định chính.
5. Sụp đổ đa dạng
Các vòng lặp tiến hóa hội tụ về một chiến lược.
Mỗi thế hệ trông giống như một biến thể của cùng một giải pháp.
Sửa lỗi: theo dõi tính mới lạ một cách rõ ràng. Phạt các giải pháp quá giống với các thành viên hiện có trong nhóm (độ tương tự cosine dựa trên embedding hoạt động tốt).
Ngăn xếp AI mới bằng tiếng Việt đơn giản

Đây là những gì bạn thực sự đang xây dựng khi bạn xây dựng các sản phẩm AI nghiêm túc:
Lớp 1 — Mô hình
Trí thông minh thô. Đã được huấn luyện trước. Trọng số cố định trong thời gian chạy.
Đây là CPU. Mạnh mẽ nhưng thụ động.
Lớp 2 — Bộ khung
Hệ điều hành. Bao bọc mô hình. Điều phối mọi thứ.
→ Công cụ (bash, đọc/ghi tệp, tìm kiếm web)
→ Bộ nhớ (hệ thống tệp, nhật ký có cấu trúc)
→ Vòng lặp (lập kế hoạch → thực thi → đánh giá → thử lại) → Tác nhân phụ (thực thi song song)
→ Quản lý ngữ cảnh (những gì mô hình thấy ở mỗi bước)
Lớp 3 — Bộ tối ưu hóa
Bộ khung cải thiện bộ khung.
→ Khai thác các mẫu thất bại từ dấu vết thực thi
→ Đề xuất các chỉnh sửa có mục tiêu cho mã bộ khung → Xác thực trên các tác vụ dành riêng
→ Hợp nhất các cải tiến, loại bỏ các hồi quy
Lớp 4 — Bộ đánh giá
Nằm bên ngoài tất cả các lớp khác.
→ Điểm chuẩn → Đánh giá của con người tại các điểm quyết định chính → Bộ kiểm tra dành riêng mà bộ tối ưu hóa không bao giờ chạm vào
Bạn không thể bỏ qua bất kỳ lớp nào.
Bỏ qua Lớp 2 — mô hình của bạn là một chatbot, không phải một sản phẩm.
Bỏ qua Lớp 3 — hệ thống của bạn không bao giờ trở nên tốt hơn nếu không có kỹ thuật thủ công.
Bỏ qua Lớp 4 — tác nhân của bạn tối ưu hóa sai thứ và bạn sẽ không nhận ra.
Điều này có nghĩa là gì cho các nhà xây dựng ngay bây giờ
Bạn không cần phải xây dựng một bộ khung tự cải thiện để hưởng lợi từ những ý tưởng này.
Hãy bắt đầu từ đây:
Tuần 1: Xây dựng vòng lặp
Ngừng xây dựng các prompt một lần. Xây dựng một vòng lặp lập kế hoạch → thực thi → đánh giá → thử lại cho bất kỳ tác vụ nào mất nhiều hơn một bước.
Tuần 2: Thêm bộ nhớ liên tục
Ngừng dựa vào ngữ cảnh. Ghi các đầu ra trung gian vào tệp. Để tác nhân đọc công việc trước đó của chính nó.
Tuần 3: Thêm tác nhân phụ
Xác định bất kỳ phần nào trong quy trình làm việc của bạn có thể chạy song song. Tạo ra các tác nhân phụ. Ghi đầu ra của chúng vào tệp. Hợp nhất.
Tuần 4: Thêm kỹ thuật ngữ cảnh
Theo dõi những mẫu nào dẫn đến thành công và thất bại. Xây dựng một sổ tay có cấu trúc đơn giản được cập nhật sau mỗi lần chạy.
Đó là bộ khung.
Không phải mô hình.
Mô hình đã có sẵn.
Bộ khung là thứ bạn xây dựng.
Sự thật khó chịu về AI vào năm 2026
Tốc độ nghiên cứu tại các phòng thí nghiệm tiên tiến đã tăng lên đáng kể.
Anthropic và OpenAI đang phát hành nhanh hơn bao giờ hết.
Không phải vì các mô hình trở nên thông minh hơn qua một đêm.
Mà vì các bộ khung đã trở nên tốt hơn.
Một tác nhân lặp lại, ghi nhớ, ủy quyền phụ và tự sửa lỗi vượt trội hơn một mô hình thông minh hơn được sử dụng sai cách.
Hào không phải là mô hình.
Hào là hệ thống.
Và hệ thống bây giờ có thể tự cải thiện chính nó.
Nếu điều này hữu ích:
→ Đăng lại — mọi nhà xây dựng AI cần hiểu ngăn xếp này
→ Theo dõi @sairahul1 để biết thêm các bài phân tích như thế này
→ Đánh dấu — riêng ngăn xếp 4 lớp đã đáng để lưu lại
Đăng ký theaibuilders.co để có thêm nhiều bài viết thú vị như vậy
Tôi viết về AI, xây dựng sản phẩm và các hệ thống hoạt động mà không cần bạn.





