Một học sinh năm thứ 3 và một nhân viên mới có một năm kinh nghiệm cùng mở một mô hình AI, cùng gõ một câu hỏi, thậm chí cùng dùng một prompt mẫu.

Kết quả vẫn có thể khác nhau một trời một vực.

Không nhất thiết vì người này “biết prompt” hơn người kia. Khác biệt lớn hơn thường nằm ở phần AI được nhìn thấy trước khi trả lời: mục tiêu, dữ liệu, lịch sử trao đổi, quy tắc, ví dụ, công cụ và giới hạn của công việc.

Phần đó gọi là context — ngữ cảnh.

Và việc chủ động quyết định thông tin nào cần được ghi lại, đưa vào, rút gọn hay tách riêng chính là context engineering — kỹ thuật thiết kế ngữ cảnh.

Đây là một thay đổi quan trọng trong cách doanh nghiệp nên nghĩ về AI. Một hệ thống AI tốt không chỉ là “model mạnh + prompt hay”. Nó là một môi trường làm việc được thiết kế đúng quanh model. Nếu muốn thấy tư duy này ở cấp độ kiến trúc, bạn có thể đọc thêm bản thiết kế bốn tầng biến Claude Code từ chatbot thành hệ thống làm việc.

Một phép thử rất đơn giản

Hãy tưởng tượng bạn tuyển một nhân sự rất thông minh vào công ty.

Ngày đầu tiên, bạn chỉ nói:

Hãy phân tích tình hình kinh doanh và đề xuất kế hoạch tốt nhất.

Người đó sẽ phải hỏi lại ngay:

• Phân tích đơn vị nào?

• Mục tiêu quý này là tăng doanh thu hay giữ biên lợi nhuận?

• Số liệu nào là bản mới nhất?

• Sản phẩm nào đang được ưu tiên?

• Những phương án nào đã thử và thất bại?

• Người nhận bản phân tích là CEO hay trưởng nhóm vận hành?

• Họ được phép đọc dữ liệu nào và hành động đến đâu?

Nếu không trả lời những câu hỏi này, ta không thể kết luận nhân sự “kém” chỉ vì bản kế hoạch chung chung.

Nhưng với AI, nhiều đội ngũ lại đang làm đúng như vậy: đưa một yêu cầu mơ hồ, không kèm bối cảnh, rồi đổi model hoặc sửa câu chữ của prompt khi kết quả không đạt.

Prompt là lời giao việc. Context là toàn bộ bàn làm việc.

Trên bàn đó có hồ sơ khách hàng, số liệu, quy trình, các quyết định trước đây, tiêu chuẩn đầu ra và những công cụ cần dùng. Lời giao việc có rõ đến đâu mà bàn làm việc trống trơn thì AI vẫn phải đoán.

Context đến từ đâu?

Trong một tác vụ thật, ngữ cảnh thường được ghép từ nhiều nguồn:

1. Chỉ dẫn của hệ thống: AI đóng vai trò gì, mục tiêu nào cần tối ưu, điều gì không được làm.

2. Yêu cầu hiện tại của người dùng: việc cụ thể cần hoàn thành trong phiên này.

3. Tri thức của tổ chức: sản phẩm, quy trình, chính sách, dữ liệu, cách gọi nội bộ.

4. Lịch sử làm việc: những gì hai bên đã thống nhất, phản hồi cũ, lỗi đã sửa.

5. Kết quả từ công cụ: dữ liệu lấy từ CRM, email, kho tài liệu, bảng tính hay phần mềm nội bộ.

6. Trạng thái hiện tại: hồ sơ nào đang mở, bước nào đã xong, việc gì còn chờ xác nhận.

Vấn đề là lượng thông tin này chỉ có tăng.

Một agent làm việc nhiều bước sẽ gọi công cụ, nhận kết quả, thử một hướng, gặp lỗi, sửa lại rồi tiếp tục. Tất cả đều có thể chảy vào cửa sổ ngữ cảnh. Nếu cứ chất mọi thứ vào, chi phí và độ trễ tăng lên, trong khi chất lượng chưa chắc tăng.

Thậm chí còn có thể giảm.

Ngữ cảnh quá dài và thiếu tổ chức tạo ra ba kiểu lỗi rất thực tế:

• Nhiễm độc ngữ cảnh: một kết luận sai lọt vào lịch sử rồi tiếp tục ảnh hưởng các bước sau.

• Nhiễu ngữ cảnh: thông tin không liên quan giành mất sự chú ý khỏi nhiệm vụ hiện tại.

• Xung đột ngữ cảnh: hai tài liệu hoặc hai chỉ dẫn nói những điều trái nhau mà không có quy tắc ưu tiên.

Vậy nên mục tiêu không phải là cho AI nhiều thông tin nhất. Mục tiêu là cho AI đúng thông tin, đúng lúc, đúng phạm vi.

Hai người dùng cùng một AI, hai kết quả khác nhau

Ví dụ 1: Một học sinh năm thứ 3

Minh là học sinh năm thứ 3 ngành kinh doanh. Tuần sau Minh phải thuyết trình đề án mở rộng cho một thương hiệu cà phê tưởng tượng.

Cách dùng AI đầu tiên của Minh là:

Viết cho tôi một kế hoạch mở rộng thương hiệu cà phê thật chuyên nghiệp.

AI trả về một bản kế hoạch nhìn rất “đúng bài”: nghiên cứu thị trường, xác định khách hàng mục tiêu, mở thêm cửa hàng, chạy quảng cáo mạng xã hội. Nhưng gần như nhóm nào trong lớp cũng có thể nhận được một câu trả lời tương tự.

Minh thử lại. Lần này, bạn tạo một gói ngữ cảnh ngắn gồm:

• yêu cầu chấm điểm của giảng viên;

• chân dung thương hiệu và mức giá;

• dữ liệu khảo sát 60 sinh viên;

• giới hạn ngân sách giả định;

• hai địa điểm nhóm đang cân nhắc;

• ba nhận xét giảng viên đã góp ý ở buổi trước;

• định dạng đầu ra: 8 slide, mỗi slide một luận điểm và một bằng chứng.

Prompt cuối cùng của Minh không hề “thần thánh”:

Dựa trên gói thông tin này, hãy đề xuất cấu trúc 8 slide. Nếu dữ liệu chưa đủ để kết luận, đánh dấu giả định thay vì tự bịa thêm.

Kết quả tốt hơn không phải vì AI bỗng thông minh hơn. Minh đã biến một yêu cầu chung chung thành một môi trường ra quyết định có dữ liệu, ranh giới và tiêu chuẩn.

Đó đã là context engineering, dù Minh không viết một dòng code nào.

Ví dụ 2: Một nhân viên mới có một năm kinh nghiệm

Lan làm ở bộ phận chăm sóc khách hàng được một năm. Công ty muốn dùng AI để soạn câu trả lời cho các khiếu nại giao hàng.

Ở bản thử nghiệm đầu, đội dự án đưa toàn bộ sổ tay vận hành, hàng trăm email cũ và mọi chính sách vào một cuộc hội thoại dài. Câu trả lời lúc đúng, lúc sai. Có lúc AI trích chính sách đã hết hiệu lực. Có lúc nó đề nghị hoàn tiền vượt quá thẩm quyền của Lan.

Lan không phải kỹ sư AI, nhưng bạn biết công việc thật diễn ra thế nào. Lan đề nghị tách bộ ngữ cảnh thành:

• chính sách hiện hành đã được duyệt;

• bảng quyền hạn theo vai trò;

• thông tin đơn hàng được truy xuất khi có mã;

• năm ví dụ trả lời tốt đã ẩn dữ liệu cá nhân;

• quy tắc bắt buộc chuyển cho con người nếu liên quan pháp lý, sức khỏe hoặc khoản điều chỉnh vượt hạn mức.

Mỗi khi có yêu cầu, hệ thống chỉ lấy phần liên quan đến loại khiếu nại đó. Lịch sử dài được tóm tắt thành vài quyết định quan trọng. Hồ sơ của khách hàng này không lẫn sang khách hàng khác.

Lan không “train model”. Bạn thiết kế đường đi của ngữ cảnh.

Đây cũng là lý do người hiểu nghiệp vụ có vai trò rất lớn trong dự án AI. Kỹ sư có thể xây đường ống, nhưng người làm việc thật mới biết dữ liệu nào đáng tin, ngoại lệ nào nguy hiểm và lúc nào phải dừng để hỏi con người.

Bốn động tác cốt lõi: Ghi, Chọn, Nén, Tách

Một cách dễ nhớ để thiết kế ngữ cảnh là dùng bốn động tác: Write, Select, Compress, Isolate.

1. Ghi lại: Điều gì cần tồn tại sau phiên chat này?

Không phải thông tin nào cũng nên biến mất khi đóng cửa sổ.

Một số thứ cần được lưu bền vững:

• kiến trúc và tiêu chuẩn của dự án;

• định nghĩa chỉ số;

• giọng văn thương hiệu;

• quy trình đã được phê duyệt;

• sở thích làm việc ổn định của người dùng;

• bài học từ những lỗi đã xảy ra.

Nhưng “ghi lại” không có nghĩa là chép toàn bộ cuộc trò chuyện vào một file khổng lồ. Bộ nhớ tốt cần có chủ sở hữu, ngày cập nhật, phạm vi áp dụng và quy tắc tránh trùng lặp.

Một nguyên tắc thực dụng:

Chỉ ghi vào bộ nhớ dài hạn những gì có khả năng thay đổi cách AI xử lý nhiều nhiệm vụ trong tương lai.

Một yêu cầu tạm thời cho báo cáo chiều nay không nên trở thành luật chung của cả công ty.

2. Chọn lọc: Tác vụ này thật sự cần biết gì?

Khi nhân viên xử lý một đơn hàng, họ không cần mở toàn bộ kho tài liệu của doanh nghiệp. AI cũng vậy.

Hệ thống nên lựa chọn ngữ cảnh theo:

• loại nhiệm vụ;

• vai trò của người yêu cầu;

• khách hàng hoặc dự án đang xử lý;

• công cụ sắp được dùng;

• mức độ mới và độ tin cậy của dữ liệu.

Ví dụ, trước khi sửa một file, coding agent cần xem cấu trúc code và quy ước liên quan. Trước khi chạy lệnh, nó cần biết đường dẫn có tồn tại không và dự án đã có script phù hợp chưa. Cùng một agent, nhưng mỗi hành động cần một gói ngữ cảnh khác.

Trong doanh nghiệp, lớp chọn lọc này thường quan trọng hơn việc nhồi thêm tài liệu. Cùng một nguyên tắc cũng xuất hiện trong thiết kế trải nghiệm số: context chỉ có ích khi giúp người dùng tìm đúng đường, không phải khi nó biến thành một kho thông tin không có thứ tự.

3. Nén gọn: Giữ quyết định, bỏ tiếng ồn

Sau 30 lượt trao đổi, không phải câu nào cũng còn giá trị như nhau.

Ta có thể nén lịch sử thành:

• mục tiêu hiện tại;

• các quyết định đã chốt;

• giả định đang dùng;

• dữ liệu nguồn quan trọng;

• việc đã thử nhưng thất bại;

• câu hỏi còn mở.

Nén không phải là cắt bớt ngẫu nhiên. Nếu bản tóm tắt làm mất một ràng buộc quan trọng, AI có thể lặp lại lỗi cũ. Vì vậy, doanh nghiệp nên xác định rõ loại thông tin nào bắt buộc phải sống sót qua quá trình tóm tắt.

4. Tách riêng: Đừng bắt một ngữ cảnh làm mọi việc

Một agent vừa nghiên cứu, vừa viết, vừa kiểm tra bảo mật, vừa duyệt chính sách trong cùng một lịch sử dài rất dễ bị lẫn vai trò.

Cách tốt hơn là chia thành các phạm vi:

• agent nghiên cứu chỉ thu thập và đánh giá nguồn;

• agent soạn thảo chỉ làm việc với brief đã duyệt;

• agent kiểm tra tập trung vào rủi ro và tiêu chuẩn;

• agent điều phối giữ trạng thái chung và chuyển giao kết quả cần thiết.

Mỗi phần có cửa sổ ngữ cảnh riêng. Chúng không cần thừa kế toàn bộ “hành lý” của nhau.

Tách riêng không đồng nghĩa với dựng 15 agent ngay ngày đầu. Nếu một quy trình với một agent còn chưa ổn định, nhân nó lên chỉ tạo ra 15 nguồn lỗi. Hãy bắt đầu bằng một tác vụ thật, đo kết quả, rồi chỉ tách khi phạm vi đã đủ rõ.

System prompt vẫn quan trọng — nhưng đừng biến nó thành kho chứa

Context engineering không làm system prompt mất giá trị.

System prompt vẫn là nơi xác định:

• danh tính và phạm vi của agent;

• mục tiêu ưu tiên;

• cách tiếp cận chung;

• ranh giới an toàn;

• điều kiện chuyển việc cho con người.

Sai lầm phổ biến nằm ở hai cực.

Ở cực thứ nhất, prompt quá chi tiết, cố viết sẵn mọi nhánh “nếu… thì…”. Agent bị đối xử như một cỗ máy trạng thái, quy tắc chồng chéo và trường hợp mới xuất hiện là hệ thống gãy.

Ở cực thứ hai, prompt quá mơ hồ:

Hãy hỗ trợ khách hàng đúng tinh thần thương hiệu và chuyển cho con người khi cần.

“Tinh thần thương hiệu” là gì? “Khi cần” là khi nào? AI không thể đọc suy nghĩ của tổ chức.

Vùng ở giữa hiệu quả hơn: nêu rõ vai trò, mục tiêu, một khung xử lý, các nguyên tắc ra quyết định và vài ranh giới không được vượt qua. Chẳng hạn:

1. Hiểu vấn đề cốt lõi.

2. Dùng công cụ để xác minh dữ liệu liên quan.

3. Đề xuất bước tiếp theo rõ ràng.

4. Xác nhận người dùng hiểu cách xử lý.

5. Chuyển cho con người nếu có rủi ro pháp lý, sức khỏe hoặc tài chính vượt thẩm quyền.

Đây là khung suy luận, không phải một sơ đồ cứng cho mọi tình huống.

Một “context brief” có thể dùng ngay

Trước khi giao một việc quan trọng cho AI, hãy chuẩn bị một brief ngắn theo mẫu sau:

1. Mục tiêu

Kết quả nào cần đạt? Ai sẽ dùng kết quả đó? Họ sẽ dùng để làm gì?

2. Dữ liệu được phép dùng

Tài liệu nào là nguồn chuẩn? Phiên bản nào mới nhất? Có dữ liệu nào không được đưa vào không?

3. Trạng thái hiện tại

Việc gì đã làm? Quyết định nào đã chốt? Điểm nào còn chưa chắc chắn?

4. Ràng buộc

Thời gian, ngân sách, thẩm quyền, định dạng, chính sách và các điều cấm.

5. Ví dụ

Một hoặc hai đầu ra tốt; nếu có, thêm một ví dụ sai và giải thích vì sao sai.

6. Công cụ

AI có thể đọc, tìm, tính toán hay cập nhật ở đâu? Công cụ nào chỉ được dùng sau khi con người xác nhận?

7. Tiêu chí hoàn thành

Điều gì phải được kiểm tra trước khi báo “xong”? Phần nào cần ghi rõ là giả định?

Brief này không cần dài. Với nhiều tác vụ, một trang được cập nhật cẩn thận tốt hơn 50 trang tài liệu ném vào cùng lúc.

Nếu đang triển khai AI trong doanh nghiệp, hãy bắt đầu ở đâu?

Đừng bắt đầu bằng câu hỏi: “Chúng ta nên dùng model nào?”

Hãy chọn một quy trình có đầu vào và đầu ra đủ rõ, rồi quan sát cách một nhân viên giỏi làm thật:

1. Họ mở những tài liệu nào?

2. Họ bỏ qua những tài liệu nào?

3. Họ kiểm tra dữ liệu ở đâu?

4. Họ dựa vào kinh nghiệm ngầm nào?

5. Khi nào họ dừng và hỏi người khác?

6. Họ biết công việc đã xong bằng cách nào?

Sau đó, thiết kế luồng ngữ cảnh quanh sáu câu trả lời ấy.

Phiên bản đầu tiên có thể rất nhỏ: một prompt rõ vai trò, một thư mục tài liệu đã duyệt, một bước lấy dữ liệu đúng lúc và một checklist kiểm tra đầu ra. Đo độ chính xác, thời gian xử lý, số lần phải làm lại và số trường hợp cần chuyển cho người. Khi bài toán bắt đầu phụ thuộc vào dữ liệu lớn và dự báo, hãy tách riêng câu hỏi “có dữ liệu gì” khỏi câu hỏi “AI có thể dự đoán điều gì xảy ra tiếp theo?”.

Khi quy trình chạy ổn, mới thêm bộ nhớ, tự động truy xuất, nén lịch sử hay các agent chuyên biệt.

Đó là cách biến AI từ màn trình diễn thành hạ tầng làm việc.

Điều cần nhớ

Model có thể ngày càng mạnh, nhưng nó vẫn không đọc được suy nghĩ của bạn.

Khi AI trả lời kém, đừng vội hỏi “prompt nào hay hơn?”. Hãy kiểm tra bốn việc:

• Có điều quan trọng nào chưa được ghi lại?

• Có thông tin nào cần chọn đúng lúc thay vì tải tất cả?

• Lịch sử đã đủ dài để cần nén chưa?

• Có nhiệm vụ hoặc dữ liệu nào cần tách sang phạm vi riêng không?

Ghi. Chọn. Nén. Tách.

Đó là bốn động tác đơn giản để bắt đầu context engineering.

Và có lẽ đây là khoảng cách thật sự giữa hai cách dùng AI: một bên liên tục nghĩ ra câu lệnh mới; bên còn lại xây một môi trường để AI có thể làm đúng việc, với đúng dữ liệu, trong đúng giới hạn.

Bạn đang có quy trình nào mà AI lúc làm đúng, lúc làm sai dù prompt gần như không đổi? Hãy thử nhìn lại “bàn làm việc” mà bạn đã đưa cho nó trước khi đổi model.

Hôm sau mở phiên mới, nó quên dự án dùng công nghệ gì. Tuần sau, code bắt đầu lệch chuẩn. Đến lúc sửa một lúc sáu file, nó nhớ phần cuối nhưng làm hỏng logic ở phần đầu.

Phản xạ phổ biến là đổi prompt. Viết dài hơn. Giải thích kỹ hơn. Hoặc đổi sang một model mạnh hơn.

Nhưng nếu vấn đề không nằm ở model thì sao?

Nếu bạn đang dùng một framework agent như một cửa sổ chat, prompt hay hơn chỉ giúp chiếc xe chạy nhanh hơn trong khi vẫn chưa có đường, biển báo và hàng rào an toàn.

Đây là điểm quan trọng nhất của bài này:

Claude Code không chỉ là nơi bạn “hỏi AI viết code”. Nó là một hệ thống có thể ghi nhớ quy ước, nạp chuyên môn, chia việc, kết nối công cụ và tự kiểm tra tại những điểm bắt buộc.

Một khi nhìn nó như một kiến trúc, cách dùng sẽ thay đổi hoàn toàn.

Claude Code giống một tảng băng: cửa sổ chat chỉ là phần nổi, hệ thống agent mới là phần quyết định

Phần nổi của tảng băng đang đánh lừa chúng ta

Phần dễ thấy nhất của một công cụ AI là ô nhập lệnh:

• Bạn mô tả yêu cầu.

• AI tạo code.

• Bạn chạy thử.

• Sai thì yêu cầu sửa.

Quy trình này hữu ích, nhưng vẫn gần với “làm việc thủ công có AI hỗ trợ”. Mỗi phiên mới, con người lại phải nạp bối cảnh. Mỗi lần review, con người lại nhắc tiêu chuẩn. Mỗi tác vụ lớn, một cuộc hội thoại phải gánh toàn bộ lịch sử.

Phần chìm mới tạo ra năng lực vận hành:

• Memory giữ lại điều AI cần biết về dự án.

• Skills đóng gói cách thực hiện một loại việc.

• Commands tạo lối vào chuẩn cho những quy trình lặp lại.

• Sub-agents tách một bài toán lớn thành các ngữ cảnh độc lập.

• Hooks buộc kiểm tra phải chạy tại đúng thời điểm.

• MCP nối agent với dữ liệu và công cụ bên ngoài.

• Headless mode đưa tác vụ vào pipeline không cần người ngồi canh.

• Agent SDK cho phép lập trình cả chuỗi hành động.

Khác biệt không nằm ở số tính năng bạn bật. Khác biệt nằm ở việc chuyển từ nhắc AI từng lần sang thiết kế hệ thống một lần rồi cải thiện dần.

Đó cũng là lý do một file hướng dẫn ngắn nhưng đúng thường giá trị hơn một prompt dài được viết lại mỗi ngày.

Bản đồ 4 tầng: đừng xây mái trước khi làm móng

Hãy hình dung hệ thống như một tòa nhà bốn tầng.

Mô hình bốn tầng của một hệ thống Claude Code: bộ nhớ, mở rộng, tích hợp và lập trình

Tầng 1 — Bộ nhớ: AI cần biết điều gì?

Đây là phần móng, thường được thể hiện qua CLAUDE.md và các tệp bối cảnh có phạm vi rõ ràng.

Nó không phải nơi đổ toàn bộ tài liệu công ty vào. Một bộ nhớ tốt chỉ nên giữ những điều ổn định và có ảnh hưởng trực tiếp đến quyết định:

• dự án dùng stack nào;

• lệnh build, test, lint là gì;

• chuẩn code bắt buộc;

• cấu trúc thư mục và quy ước đặt tên;

• những điều tuyệt đối không được làm;

• tiêu chí nào chứng minh một tác vụ đã hoàn tất.

Sai lầm phổ biến là biến CLAUDE.md thành kho chứa. File càng dài, tín hiệu quan trọng càng dễ chìm trong nhiễu.

Một phép thử đơn giản: nếu bỏ một dòng đi mà cách agent ra quyết định không đổi, dòng đó có thể không cần nằm trong bộ nhớ cốt lõi.

Nguyên tắc này cũng xuất hiện ở một bài toán rộng hơn: một hệ thống “có trí nhớ” chỉ hữu ích khi ký ức đó giúp người dùng bớt phải tìm kiếm và giải thích lại.

Tầng 2 — Mở rộng: AI phải làm việc như thế nào?

Tầng này gồm bốn cơ chế dễ bị gọi chung là “automation”, nhưng vai trò rất khác nhau.

Commands dành cho việc con người chủ động kích hoạt. Ví dụ: một lệnh review pull request theo checklist cố định.

Skills chứa tri thức và quy trình chuyên môn để agent nạp khi bài toán phù hợp. Ví dụ: cách đánh giá thiết kế API, cách kiểm tra một báo cáo tài chính, hoặc cách viết một bài theo giọng thương hiệu.

Sub-agents dành cho việc cần tách ngữ cảnh. Một agent chính có thể giao riêng phần kiểm tra bảo mật, kiểm tra test và rà soát tài liệu, sau đó chỉ nhận kết luận cô đọng.

Hooks là chốt chặn theo sự kiện. Dù ai thực hiện, đến bước đó kiểm tra vẫn phải chạy: phát hiện bí mật trước khi commit, lint sau khi sửa file, hoặc xác nhận trước một thao tác rủi ro.

Cách nhớ ngắn:

• Command: tôi bảo làm.

• Skill: gặp đúng việc thì biết cách làm.

• Sub-agent: chia cho người khác làm trong phòng riêng.

• Hook: đến cửa này thì bắt buộc kiểm tra.

Tầng 3 — Tích hợp: AI lấy dữ liệu và tác động ra bên ngoài bằng gì?

Một agent chỉ nằm trong cửa sổ chat sẽ nhanh chóng chạm trần.

Khi nối với kho mã, cơ sở dữ liệu, công cụ quản lý công việc hay API qua MCP, agent có thể làm trên dữ liệu thật. Khi chạy ở chế độ headless, nó có thể tham gia CI/CD hoặc một quy trình định kỳ.

Nhưng “kết nối được” không đồng nghĩa “nên cấp toàn quyền”.

Quyền truy cập nên đi từ hẹp đến rộng:

1. bắt đầu bằng dữ liệu thử nghiệm;

2. ưu tiên quyền chỉ đọc;

3. giới hạn thư mục, công cụ và phạm vi;

4. ghi log thao tác;

5. yêu cầu con người xác nhận với hành động khó hoàn tác.

Agent càng mạnh, thiết kế quyền càng phải chặt.

Tầng 4 — Lập trình: khi nào cần tự thiết kế một workflow?

Agent SDK nằm ở tầng trên cùng. Đây là lúc bạn không còn chỉ “dùng công cụ”, mà bắt đầu lập trình luồng điều phối:

1. nhận yêu cầu;

2. thu thập dữ liệu;

3. phân loại tác vụ;

4. giao cho agent chuyên trách;

5. đối chiếu kết quả;

6. yêu cầu sửa nếu chưa đạt;

7. chỉ xuất bản khi vượt qua tiêu chí.

Không phải ai cũng cần bắt đầu ở tầng này. Phần lớn workflow đầu tiên chỉ cần một bộ nhớ gọn, một skill tốt và một hook đúng chỗ.

Kiến trúc trưởng thành không phải kiến trúc dùng nhiều thành phần nhất. Đó là kiến trúc dùng thành phần đơn giản nhất đủ giải quyết rủi ro hiện tại.

Đằng sau sơ đồ kỹ thuật vẫn là một câu hỏi vận hành quen thuộc: làm sao biến một lời hứa thành các bước thực hiện, điểm bàn giao và cơ chế phối hợp cụ thể.

Hai ví dụ tưởng tượng: cùng một kiến trúc, hai điểm xuất phát

Hai tình huống dưới đây là ví dụ giả định, không phải case study thực tế. Mục đích là biến mô hình thành việc có thể làm ngay.

Một sinh viên năm ba và một nhân viên một năm kinh nghiệm cùng xây workflow agent có kiểm tra và cải thiện

Ví dụ 1: Minh, sinh viên năm thứ ba

Minh đang làm đồ án web cùng ba bạn. Mỗi người viết một kiểu. Một bạn dùng npm, bạn khác dùng pnpm. Có người tạo API mới mà không viết test. Cứ gần ngày demo, cả nhóm mất một buổi để sửa những lỗi lặp lại.

Minh chưa cần dựng “đội quân 15 agent”.

Bạn bắt đầu bằng ba việc:

Một: tạo bộ nhớ dự án ngắn.

Trong CLAUDE.md, Minh ghi stack, cấu trúc thư mục, lệnh chạy test, quy tắc đặt tên và định nghĩa “xong”: code chạy, test qua, không có secret, có hướng dẫn sử dụng.

Hai: tạo một command review trước khi nộp.

Command này kiểm tra đúng checklist giảng viên chấm: chức năng, test, xử lý lỗi, README.

Ba: thêm một hook phát hiện secret.

Nếu ai đó vô tình đưa API key vào thay đổi sắp commit, quy trình bị chặn.

Sau hai tuần, nếu nhóm nhận ra lỗi API cứ tái diễn, Minh mới đóng gói cách thiết kế và kiểm tra API thành một skill.

Điểm đáng học ở đây: Minh không “học AI” bằng cách đọc hết tên các model. Bạn biến một lỗi thật trong đồ án thành một cơ chế không phải nhắc lại.

Đó là năng lực có thể mang vào buổi phỏng vấn: không chỉ khoe code AI tạo ra, mà giải thích được mình đã thiết kế bối cảnh, kiểm soát chất lượng và giảm lỗi lặp như thế nào.

Ví dụ 2: Lan, nhân viên mới có một năm kinh nghiệm

Lan làm vận hành tại một công ty thương mại. Mỗi thứ Hai, bạn phải gom số liệu từ vài file, đọc ghi chú của các bộ phận và viết báo cáo ngắn cho quản lý.

Lan thử đưa tất cả vào một cuộc chat. Tuần đầu rất nhanh. Tuần sau, báo cáo dùng sai cách gọi chỉ số và bỏ mất một ngoại lệ mà người trong công ty ai cũng biết.

Thay vì kết luận “AI không hiểu nghiệp vụ”, Lan thiết kế lại:

Memory lưu định nghĩa chỉ số, kỳ báo cáo, quy tắc đặt tên và các ngoại lệ ổn định.

Skill mô tả quy trình: kiểm tra dữ liệu thiếu, so sánh với kỳ trước, đánh dấu biến động bất thường, nêu giả thuyết nhưng không biến giả thuyết thành sự thật.

Sub-agent thứ nhất kiểm tra chất lượng dữ liệu. Sub-agent thứ hai soát tính nhất quán giữa bảng số và phần nhận xét.

Hook yêu cầu loại bỏ thông tin nhạy cảm trước khi tạo bản chia sẻ rộng.

Ban đầu, Lan chỉ cho hệ thống đọc bản sao dữ liệu. Báo cáo cuối vẫn cần bạn duyệt. Sau vài vòng ổn định, bạn mới đề xuất tự động hóa bước tạo bản nháp.

Giá trị của Lan không nằm ở việc “bấm AI nhanh”. Nó nằm ở kiến thức ngầm: chỉ số nào hay bị hiểu sai, nguồn nào thường trễ, con số nào cần hỏi lại. AI nhân rộng quy trình; Lan chịu trách nhiệm biến kinh nghiệm đó thành quy tắc có thể kiểm tra.

Một request đi qua hệ thống như thế nào?

Giả sử bạn nhập:

Hãy review thay đổi trong module thanh toán và tìm rủi ro bảo mật.

Trong cách dùng kiểu chat, một model đọc mọi thứ rồi trả lời.

Trong cách dùng kiểu framework:

1. Memory nạp stack, kiến trúc và tiêu chuẩn của dự án.

2. Skill bảo mật cung cấp checklist đúng miền.

3. Sub-agent đọc riêng phần thay đổi để không làm loãng ngữ cảnh chính.

4. MCP hoặc công cụ cục bộ cung cấp diff, kết quả test và dữ liệu cần thiết.

5. Hook chặn thao tác nếu phát hiện secret hoặc kiểm tra bắt buộc chưa qua.

6. Agent chính nhận kết luận, đối chiếu bằng chứng và trình bày quyết định.

Mỗi thành phần chỉ có một trách nhiệm:

• Memory trả lời biết gì.

• Skill trả lời làm thế nào.

• Sub-agent trả lời ai xử lý.

• Hook trả lời điểm nào không được bỏ qua.

• MCP trả lời lấy dữ liệu và dùng công cụ ở đâu.

• SDK trả lời điều phối toàn bộ chuỗi ra sao.

Khi ranh giới rõ, hệ thống dễ sửa. Nếu kết quả sai vì thiếu quy ước, sửa memory. Nếu quy trình chuyên môn yếu, sửa skill. Nếu tác vụ quá lớn, tách ngữ cảnh. Nếu kiểm tra hay bị quên, dùng hook thay vì nhắc bằng lời.

Đừng tự động hóa một quy trình chưa hiểu

Có một cái bẫy hấp dẫn: vừa biết agent có thể chia việc là lập tức dựng nhiều agent; vừa biết hook là gắn chốt vào mọi thao tác; vừa biết MCP là nối tất cả dữ liệu.

Kết quả thường là một hệ thống trông rất hiện đại nhưng khó biết sai ở đâu.

Thứ tự thực tế hơn:

Bước 1: Chọn một việc lặp lại và có đầu ra rõ

Đừng bắt đầu bằng “tự động hóa công ty”. Hãy bắt đầu bằng “tạo bản nháp báo cáo tuần từ ba nguồn” hoặc “review PR theo checklist năm mục”.

Bước 2: Viết định nghĩa hoàn tất

Agent cần biết bằng chứng nào chứng minh công việc xong: test nào phải qua, trường nào không được trống, số liệu nào phải đối chiếu, ai cần phê duyệt.

Bước 3: Chạy thủ công để lộ lỗi

Ghi lại nơi agent hiểu sai. Mỗi lỗi lặp lại là ứng viên cho memory, skill hoặc hook.

Bước 4: Chỉ tách agent khi có lý do

Tách khi cần ngữ cảnh độc lập, chuyên môn khác biệt, xử lý song song hoặc phản biện chéo. Không tách chỉ để sơ đồ nhìn hoành tráng.

Bước 5: Mở quyền từng nấc

Đọc trước, viết sau. Môi trường thử trước, môi trường thật sau. Hành động thuận nghịch trước, hành động phá hủy sau cùng và có xác nhận.

Bước 6: Đo kết quả thay vì đếm tính năng

Theo dõi thời gian tiết kiệm, tỷ lệ phải làm lại, lỗi bị bắt trước khi giao và số lần con người phải can thiệp. Một workflow có một agent nhưng ổn định tốt hơn mười agent không ai kiểm soát.

Và hãy cẩn thận với chỉ số: đo sai thứ có thể khiến con người tối ưu con số thay vì tối ưu kết quả.

Năng lực quan trọng không còn là “prompt hay”

Prompt vẫn cần. Nhưng khi AI đi từ công cụ sang agent, lợi thế dịch chuyển.

Người tạo ra nhiều giá trị hơn sẽ biết:

• chọn đúng bối cảnh thay vì nhồi mọi thứ;

• biến kinh nghiệm ngầm thành tiêu chí rõ;

• chia bài toán theo ranh giới trách nhiệm;

• thiết kế quyền và điểm kiểm soát;

• bắt hệ thống đưa bằng chứng trước khi báo hoàn tất;

• biến mỗi lần thất bại thành một cải tiến có thể tái sử dụng.

Nói cách khác, kỹ năng quan trọng dần chuyển từ làm tốt một task sang thiết kế và tối ưu hệ thống làm task đó.

Bạn không cần đợi đến khi thành kỹ sư AI mới bắt đầu. Một sinh viên có thể áp dụng với đồ án. Một nhân viên mới có thể áp dụng với báo cáo tuần. Điều kiện duy nhất là bạn phải có một công việc thật, một tiêu chí thật và đủ kỷ luật để không trao quyền trước khi hệ thống chứng minh được độ tin cậy.

Việc nên làm trong tuần này

Chọn một workflow bạn đã làm ít nhất ba lần.

Viết ra bốn câu:

1. Agent cần nhớ điều gì?

2. Agent cần biết cách làm điều gì?

3. Phần nào cần tách riêng để tránh nhiễu?

4. Bước nào bắt buộc phải kiểm tra, dù ai thực hiện?

Sau đó chỉ triển khai một thay đổi nhỏ nhất.

Có thể đó là một CLAUDE.md gồm 20 dòng. Có thể là checklist review. Có thể là một hook chặn secret. Đừng bắt đầu bằng sơ đồ đẹp. Hãy bắt đầu bằng một lỗi bạn không muốn gặp lần thứ ba.

Vì khoảng cách giữa “AI trả lời rất hay” và “AI làm việc đáng tin cậy” không được lấp bằng thêm một câu prompt.

Nó được lấp bằng kiến trúc.