Bạn từng nhờ Claude “sửa lại đoạn copy này” rồi tự tay làm tiếp các bước còn lại chưa? Nếu có, bạn đã dùng Claude ở mức task — bạn nghĩ, Claude làm. Nhưng nếu bạn từng nói kiểu “rà soát lại toàn bộ giao diện này theo đúng design system rồi liệt kê chỗ nào lệch”, và Claude tự đọc file, tự so sánh, tự quyết định kiểm tra gì trước, gì sau — đó là lúc bạn đang dùng một agent. Bài này giải thích rõ ranh giới đó, và chỉ bạn cách dựng Claude Agents đầu tiên mà không cần biết dòng lệnh nào.
Ý tưởng cốt lõi: ai là người quyết định các bước
Cứ hình dung như giao việc cho một nhân viên. Task là bạn đã nghĩ sẵn cách làm, chỉ cần Claude thực thi một bước. Agent là bạn chỉ đưa mục tiêu và luật chơi, còn việc chia nhỏ thành bao nhiêu bước, làm theo thứ tự nào — Claude tự quyết.
Khác biệt duy nhất này giải thích được cả chủ đề “agent” đang được nhắc tới khắp nơi. Nếu bạn viết được một bản mô tả công việc rõ ràng, bạn viết được một agent.
| Cấp độ | Ai quyết định các bước | Ví dụ |
|---|---|---|
| Task (chat bình thường) | Bạn | “Viết lại dòng thông báo trống này” |
| Workflow | Bạn | “Gom nhóm các ghi chú, rồi vẽ sơ đồ, rồi tóm tắt” |
| Agent | Claude | “Soát màn hình này theo design system và báo lỗi” |
Vậy chat với Claude có phải là “dùng agent” không? Thường thì không, đó vẫn là task. Nó chỉ trở thành agent khi Claude bắt đầu lặp: dùng công cụ, tự đọc kết quả của chính mình, rồi tự chọn bước tiếp theo để đạt mục tiêu bạn đặt ra.
“Công cụ” (tools) thực chất là gì
Công cụ là tay và mắt của agent — những gì nó được phép nhìn và làm. Có ba nhóm:
- Có sẵn trong Claude Code: đọc file, tìm kiếm trong file, tìm file theo tên, sửa file, hoặc chạy lệnh hệ thống (ví dụ chụp màn hình, chạy test).
- Kết nối qua MCP: đọc một khung hình trong Figma, cập nhật trang Notion, soạn email Gmail, truy vấn cơ sở dữ liệu, chụp màn hình một trang đang chạy.
- Tùy chỉnh: bất kỳ hàm nào bạn tự định nghĩa, như tạo ticket hay đăng bài lên CMS.
Công cụ bạn giao cho agent là một quyết định thiết kế, không phải chi tiết kỹ thuật. Một agent chỉ để “soát lỗi” thì nên chỉ có quyền đọc, không có quyền sửa file — để nó nhìn ra vấn đề nhưng không bao giờ tự ý chỉnh sửa.
Cách thiết kế một Claude Agents tốt
Coi việc này như hướng dẫn việc cho người mới, không phải viết một câu lệnh.
Mỗi agent một việc. Mục tiêu mơ hồ thì agent làm việc mơ hồ.
Ít công cụ nhưng đúng, và mô tả rõ. Không phải cho nhiều công cụ là tốt. Viết mô tả từng công cụ như hướng dẫn cho một bạn junior, để Claude biết chính xác khi nào nên dùng.
Cho nó “sự thật nền” để tự kiểm tra. Cho nó đọc lại kết quả của chính mình — ảnh chụp màn hình, kết quả test, bản diff — để nó tự sửa sai. Đây là phiên bản “phản hồi người dùng thực tế” dành cho agent.
Giới hạn phạm vi và đặt điểm dừng. Chỉ cho quyền đọc khi việc của nó chỉ là đánh giá. Đặt số lần thử tối đa để nó không chạy vô tận.
Giữ đơn giản và minh bạch. Yêu cầu nó trình bày kế hoạch trước, để bạn hiểu vì sao nó làm vậy.
Khi nào nên dùng agent, khi nào không cần
| Nên dùng agent khi | Dùng cách đơn giản hơn khi |
|---|---|
| Không thể liệt kê trước các bước | Chỉ một yêu cầu — cứ prompt trực tiếp (task) |
| Kết quả đầu ra có thể kiểm tra được | Có thể liệt kê sẵn các bước — dựng workflow |
| Đáng bỏ thêm thời gian và chi phí token | Tốc độ và tính ổn định là ưu tiên số một |
Nguyên tắc chung: tìm cách đơn giản nhất có thể chạy được, chỉ thêm quyền tự quyết khi nó thật sự cải thiện kết quả. Không phải việc gì cũng cần một agent.
Những mặt trái cần biết
- Chậm và tốn hơn. Agent phải khám phá, mà khám phá thì tốn token.
- Kém ổn định. Cùng một đầu vào nhưng chạy hai lần có thể ra kết quả khác nhau, khó debug hơn.
- Lỗi cộng dồn. Mỗi bước trong vòng lặp nhân thêm rủi ro sai của mắt xích yếu nhất, nên việc quan trọng mà khó phát hiện lỗi thì càng tự động càng rủi ro.
Cách giảm thiểu: giữ quyền chỉ-đọc khi có thể, đặt người kiểm tra ở các điểm mốc, thử trong môi trường Staging/sanbox an toàn trước, và luôn có giới hạn số lần thử.
Tám Claude Agents thực tế bạn có thể dựng ngay
Mỗi cái dưới đây là agent tốt vì việc cần sự phán đoán, nhưng kết quả vẫn kiểm tra được:
- Agent tra soát thiết kế — so màn hình đã dựng với design system và bản gốc, báo chỗ lệch. Công cụ: đọc file, tìm kiếm, chạy lệnh (không có quyền sửa).
- Agent kiểm tra khả năng tiếp cận (accessibility) — kiểm tra độ tương phản, kích thước vùng chạm, thứ tự focus, alt text.
- Agent tổng hợp nghiên cứu — biến ghi chú phỏng vấn thành các chủ đề, mẫu hình, trích dẫn minh họa.
- Agent kiểm tra văn phong — quét các dòng chữ trong giao diện, so với bộ quy chuẩn giọng văn, báo chỗ lệch tông.
- Agent kiểm tra dùng đúng component — tìm chỗ dùng giá trị “cứng” hoặc component tự chế thay vì dùng hệ thống có sẵn.
- Agent phân tích đối thủ — cho một luồng thao tác, agent tìm cách các sản phẩm khác giải quyết và tóm tắt mẫu hình chung.
- Agent tự dựng màn hình — dựng giao diện từ bản đặc tả và ảnh tham chiếu, rồi tự chụp ảnh, so sánh, sửa tới khi khớp. Việc này có quyền sửa file nên cần người theo dõi.
- Agent soát luồng — đi qua một luồng thao tác thực tế, đối chiếu với bản đặc tả, báo trạng thái còn thiếu (trống, đang tải, lỗi, thành công).
Ví dụ đầy đủ: dựng agent kiểm soát thiết kế từ A đến Z
Phần khó hình dung nhất không phải là ý tưởng, mà là cách nối agent với các công cụ bạn đang dùng hằng ngày. Nên hãy dựng thử một cái để thấy khuôn mẫu, rồi áp dụng cho bảy cái còn lại.
Hai loại công cụ bạn giao cho nó
Nhóm đầu tiên có sẵn trong Claude Code, không đụng tới internet: đọc file code của màn hình, file mô tả design system, bản đặc tả, ảnh tham chiếu; tìm trong toàn bộ code những giá trị màu hoặc khoảng cách viết “cứng” thay vì dùng token; tìm mọi file màn hình hoặc component liên quan; chạy lệnh để chụp ảnh giao diện đang chạy hoặc xem chính xác phần code nào vừa thay đổi.
Nhóm thứ hai là các kết nối qua MCP — đây là phần hay bị coi là phức tạp, nhưng thực chất chỉ là công tắc bật/tắt: kết nối Figma để lấy khung hình gốc, biến số thiết kế thật, và ảnh chụp — để so sánh bản dựng với đúng nguồn Figma thay vì một tài liệu có thể đã lỗi thời; kết nối Notion để đọc bản đặc tả hoặc ghi lại kết quả kiểm tra; kết nối Linear/Jira để tự tạo ticket cho mỗi lỗi tìm thấy; kết nối Slack để đăng tóm tắt kết quả lên kênh của nhóm.
Một điều cần nhớ: kết nối chỉ trở thành công cụ Claude dùng được sau khi bạn bật nó lên trong phần cài đặt. Sau đó bạn giao nó cho agent y như giao quyền đọc file.
Bước 1: nhờ Claude viết agent giúp bạn
Bạn không cần tự viết file cấu hình. Cứ mô tả công việc như đang giao việc cho người mới, Claude sẽ tự viết file agent. Dán đại loại thế này vào một dự án:
Tạo một subagent tên là design-reviewer, lưu vào
.claude/agents/design-reviewer.md. Việc của nó: soát một màn hình đã dựng và báo chỗ lệch so với thiết kế gốc. Cho nó quyền đọc file, tìm kiếm trong file, tìm file theo tên, chạy lệnh, và kết nối Figma — không cho quyền sửa file. Nó phải kiểm tra mọi giá trị màu, khoảng cách, kiểu chữ có khớp với token trong file thiết kế không, layout có khớp khung Figma tôi chỉ định không, và vùng chạm có tối thiểu 44×44 không. Chỉ báo cáo lỗi thực sự, kèm tên file và dòng. Không nêu ý kiến cá nhân về gu thẩm mỹ.
Bản brief này hiệu quả nhờ hai điều: bạn nêu rõ công cụ nào được cấp (và công cụ nào bị chặn — ở đây là quyền sửa file), và bạn định nghĩa chính xác thế nào là “đạt”.
Bước 2: nhờ Claude dùng nó
Sau khi file đã có, chỉ cần gọi tên agent và chỉ nó việc cần soát:
Dùng subagent design-reviewer để soát màn hình thanh toán. So với file thiết kế và khung Figma này: [dán link Figma]. Cho tôi biết chỗ nào lệch và ở đâu.
Vậy là xong cả vòng lặp. Bạn mô tả một lần, dùng lại mãi mãi.
Bước 3: biến agent này thành năm agent khác nhau
Đây là phần đáng nhớ nhất, vì đây là cách một agent âm thầm sinh ra năm cái. Mỗi việc mới chỉ là thêm một câu vào bản mô tả, cộng với bật đúng kết nối tương ứng: thêm câu “so sánh bản dựng với khung Figma này, báo chỗ hai bên không khớp” (bật Figma) để nó phát hiện lúc file thiết kế gốc đã lỗi thời; thêm câu “sau mỗi lần soát, ghi một dòng vào cơ sở dữ liệu Notion gồm tên màn hình, lỗi, ngày” (bật Notion) để có bản ghi chung thay vì một bình luận rồi trôi mất; thêm câu “tạo một ticket Linear cho mỗi lỗi tìm thấy” (bật Linear) để nợ thiết kế trở thành việc được theo dõi thay vì ghi chú rời rạc; thêm câu “đăng tóm tắt ba dòng lên kênh khi xong” (bật Slack) để cả nhóm biết màn hình đã đạt hay còn vướng gì.
Lưu ý về giới hạn của kết nối Figma
Việc lấy khung hình Figma trực tiếp rất tốt để đối chiếu với nguồn gốc thật, nhưng có giới hạn số lần đọc, và không phải ai cũng biết. Theo tài liệu chính thức của Figma: tài khoản Starter, hoặc View/Collab seat trên các gói trả phí, chỉ được tối đa 6 lượt đọc mỗi tháng — chỉ đủ để demo. Nếu bạn có Dev hoặc Full seat trên gói Professional, Organization, hay Enterprise, giới hạn chuyển sang tính theo phút (khoảng 10–20 lượt/phút tùy gói), đủ dùng hằng ngày.
Một điểm dễ nhầm: giới hạn tính theo team sở hữu file, không phải theo tài khoản cá nhân của bạn. Nếu file nằm trong mục Drafts cá nhân hoặc một team đang dùng gói miễn phí, nó vẫn bị giới hạn 6 lượt/tháng dù bạn có seat trả phí. Nếu liên tục bị chặn, thử chuyển file sang team đang dùng gói trả phí. Riêng việc ghi ngược dữ liệu vào Figma thì không bị tính vào giới hạn này.
Cách xử lý thực tế: trích xuất design system ra một file mô tả riêng, để agent đọc bản đó ở mỗi lần soát (nhanh, miễn phí, không tốn quota). Chỉ lấy khung Figma trực tiếp khi cần một đợt kiểm tra sâu định kỳ, đừng gọi ở mọi lần soát nhỏ.
Agent giúp cả nhóm bớt làm việc rời rạc
Khi agent soát thiết kế (hay bất kỳ agent nào) sống trong dự án chung thay vì trong lịch sử chat riêng của một người, vài điều thay đổi: tiêu chuẩn của nhóm không còn nằm trong đầu một người giỏi nhất, mà được viết ra, versioned, áp dụng như nhau cho mọi người; phán đoán của một người trở thành tài sản dùng lại được thay vì kiến thức truyền miệng chỉ xuất hiện khi người đó có mặt; agent nối các công cụ khác nhau — đọc Figma, kiểm tra bản dựng, ghi vào Notion, tạo ticket Linear — nên bàn giao giữa các bộ phận không còn là dịch tay; một lượt soát sơ bộ có thể diễn ra bất cứ lúc nào, không cần chờ đúng người rảnh; và người mới thừa hưởng luôn các agent của nhóm, làm đúng chuẩn ngay từ ngày đầu thay vì mất vài tuần dò dẫm.
Nhưng cần nói thẳng: agent chỉ nối công việc lại, không thay thế việc trao đổi giữa người với người. Dùng sai cách, ai cũng cắm đầu vào AI riêng của mình thì lại càng rời rạc hơn. Cái được thực sự là làm rõ tiêu chuẩn, tự động hóa khâu bàn giao, để thời gian con người dành cho trao đổi thật sự thay vì soát lỗi thủ công.
Bạn dựng agent này ở đâu
Phần lớn việc này làm được ngay trong các ứng dụng bạn đã có, không cần dòng lệnh nào:
- Claude Code (tab Code trong app Claude desktop) — phù hợp để dựng hoặc soát màn hình thật trong một thư mục dự án. Agent sống dưới dạng file markdown trong thư mục
.claude/agents/(dấu chấm đầu chỉ để ẩn thư mục đi) — bạn không cần tự tạo, chỉ cần bảo Claude lưu giúp. - Claude Cowork (tab Cowork) — hợp cho việc nhiều bước không liên quan tới code, như tổng hợp nghiên cứu hay xử lý cả đống file.
- Claude.ai kèm connector (ngay trên trình duyệt, không cài gì) — cách nhẹ nhàng nhất. Vào phần cài đặt, bật các kết nối bạn cần (Figma, Notion, Gmail, Drive), rồi cứ hỏi bình thường trong chat.
- Claude Agent SDK — dành cho kỹ sư khi muốn đóng gói agent chạy ổn định cho người khác dùng, dạng sản phẩm. Không phải điểm bắt đầu cho người không rành code, nhưng đáng biết để bàn giao khi cần.
Mẫu copy-paste: agent soát thiết kế
Dán đoạn này vào một dự án trong Claude Code, kèm câu “lưu file này thành .claude/agents/design-reviewer.md“:
---
name: design-reviewer
description: Soát một màn hình đã dựng so với bản đặc tả, file thiết kế, và khung tham chiếu. Dùng sau khi màn hình có thay đổi.
tools: Read, Grep, Glob, Bash
---
Bạn là một designer sản phẩm cấp cao đang soát một màn hình trong bản mẫu di động.
Chỉ kiểm tra đúng những điều sau:
- Bản đặc tả: màn hình phải có đủ các trạng thái được liệt kê (trống, đang tải, lỗi, thành công). Báo trạng thái nào còn thiếu.
- File thiết kế: mọi giá trị màu, khoảng cách, bo góc, kiểu chữ phải là token lấy từ đó. Báo giá trị nào viết "cứng" hoặc tự bịa.
- Ảnh tham chiếu: layout và cảm giác tổng thể phải khớp.
- Vùng chạm tối thiểu 44x44.
Chỉ báo những lỗi thực sự sai so với đặc tả, kèm tên file và dòng nếu có thể. Không nêu ý kiến cá nhân về gu thẩm mỹ, không đề xuất tính năng thêm. Nếu mọi thứ ổn, cứ nói vậy rồi dừng.
Bạn không cần hiểu hết mọi thuật ngữ để bắt đầu. Cứ mô tả rõ một việc, giao đúng công cụ, đặt giới hạn — vậy là bạn đã có một agent thật sự dùng được, không phải chỉ nói cho vui. Thử dựng cái đầu tiên hôm nay, rồi cho mình biết nó soát ra được gì nhé!
Để lại một bình luận