Bạn mở AI lên, giao một việc, nhận về vài trăm dòng code rất nhanh.
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:
bắt đầu bằng dữ liệu thử nghiệm;
ưu tiên quyền chỉ đọc;
giới hạn thư mục, công cụ và phạm vi;
ghi log thao tác;
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:
nhận yêu cầu;
thu thập dữ liệu;
phân loại tác vụ;
giao cho agent chuyên trách;
đối chiếu kết quả;
yêu cầu sửa nếu chưa đạt;
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:
Memory nạp stack, kiến trúc và tiêu chuẩn của dự án.
Skill bảo mật cung cấp checklist đúng miền.
Sub-agent đọc riêng phần thay đổi để không làm loãng ngữ cảnh chính.
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.
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.
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:
Agent cần nhớ điều gì?
Agent cần biết cách làm điều gì?
Phần nào cần tách riêng để tránh nhiễu?
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.