Sub-agent, skill hay MCP server: đặt quy trình của khách vào đâu cho đúng

Thử hình dung bạn đang ở tuần thứ hai tại một công ty bảo hiểm sức khỏe. Chị trưởng phòng bồi thường vừa mất ba tiếng giải thích cách đội chị thẩm định một hồ sơ.

Trước hết phải kiểm tra hợp đồng còn hiệu lực hay không. Sau đó đối chiếu hóa đơn bệnh viện, tra bảng mã loại trừ, và nếu hồ sơ vượt một ngưỡng nhất định thì chuyển lên cấp trên.

Giờ bạn có một cuốn sổ kín ghi chú và một agent cần học hết những điều đó. Trước khi viết dòng code đầu tiên, bạn phải trả lời một câu: mỗi mẩu tri thức này nên nằm ở đâu?

Nghe thì đơn giản, nhưng đặt sai chỗ thì agent tốn context, khó sửa mỗi khi khách đổi quy trình, và có thể đọc được dữ liệu mà lẽ ra nó không được đụng tới. Một FDE giỏi phân biệt được ba chỗ chứa: MCP server, agent skill và sub-agent.

Ba chỗ chứa trả lời ba câu hỏi khác nhau

MCP (Model Context Protocol) là một chuẩn mở dùng để kết nối ứng dụng AI với hệ thống bên ngoài như nguồn dữ liệu, tool và workflow. Tài liệu chính thức ví MCP như một cổng USB-C cho ứng dụng AI.

Bạn viết kết nối một lần, rồi ứng dụng nào hỗ trợ chuẩn này cũng cắm vào được. MCP trả lời câu hỏi: agent chạm được vào hệ thống nào?

Theo định nghĩa của Anthropic, Agent Skill là những thư mục có tổ chức, chứa hướng dẫn, script và tài nguyên mà agent tự tìm và nạp khi cần. Skill trả lời câu hỏi: agent làm việc này theo cách nào? Anthropic coi skill là thứ bổ sung cho MCP: MCP mở quyền truy cập, còn skill dạy agent những workflow phức tạp hơn.

Sub-agent là một trợ lý chuyên biệt. Nó chạy trong context window riêng, có system prompt riêng, bộ tool riêng và quyền hạn độc lập. Sub-agent trả lời câu hỏi thứ ba: việc này nên làm ở đâu, và với quyền gì?

Mổ xẻ một hồ sơ bồi thường

Quay lại cuốn sổ ghi chú ở công ty bảo hiểm giả định ấy và phân loại từng mẩu một.

Hệ thống quản lý hợp đồng và kho hóa đơn là hạ tầng của khách, nên thuộc về MCP server, với những tool như tra cứu hợp đồng theo số hiệu hay lấy hóa đơn theo mã hồ sơ. Nếu mai khách muốn chuyển sang agent khác hay IDE khác, kết nối này vẫn dùng lại được.

Bảy bước thẩm định, bảng mã loại trừ và công thức tính mức chi trả là tri thức quy trình, nên thuộc về một skill. Thư mục có thể trông như sau:

tham-dinh-boi-thuong/
├── SKILL.md            # các bước, ngưỡng chuyển cấp
├── ma-loai-tru.md      # bảng tra cứu dài, chỉ đọc khi cần
└── tinh_chi_tra.py     # script tính toán, không để model tự nhẩm

Phần đầu file SKILL.md chỉ cần ngắn gọn:

---
name: tham-dinh-boi-thuong
description: Dùng khi thẩm định hồ sơ bồi thường y tế, kiểm tra
  hiệu lực hợp đồng, đối chiếu hóa đơn và quyết định chuyển cấp duyệt.
---
1. Gọi tool tra cứu hợp đồng, dừng nếu hợp đồng hết hiệu lực.
2. ...

Dòng đáng chú ý nhất là description. Trong Claude Code, chỉ phần mô tả của skill nằm sẵn trong context để agent biết mình có những skill nào, còn toàn bộ nội dung chỉ được nạp khi skill được gọi. Anthropic gọi cách này là progressive disclosure (chỉ nạp thứ cần, vào lúc cần) và coi đó là nguyên tắc thiết kế cốt lõi của skill.

Việc cuối cùng là rà vài trăm hóa đơn scan để tìm hóa đơn trùng. Việc này rất ồn: nó đổ ra hàng loạt nội dung file mà agent chính sẽ không bao giờ đọc lại, nên hợp với một sub-agent:

---
name: doi-chieu-hoa-don
description: Rà kho hóa đơn của một hồ sơ, trả về danh sách hóa đơn trùng hoặc bất thường.
tools: Read, Grep, Glob
---
Chỉ đọc. Không sửa, không xóa file. Kết quả trả về dạng bảng ngắn.

Trường tools hoạt động như một allowlist, còn disallowedTools dùng làm denylist. Với dữ liệu y tế của khách, đây là chỗ bạn vạch ranh giới quyền bằng cấu hình, thay vì trông chờ model tự giữ kỷ luật.

Hai lớp này nối được với nhau. Khi một skill khai báo context: fork, Claude Code khởi động một sub-agent thuộc loại ghi ở trường agent và lấy nội dung skill làm prompt cho nó:

---
name: ra-hoa-don-trung
description: Dùng khi cần rà toàn bộ hóa đơn của một hồ sơ để tìm hóa đơn trùng.
context: fork
agent: doi-chieu-hoa-don
---
Lấy danh sách hóa đơn theo mã hồ sơ, so số tiền và ngày khám,
trả về bảng các cặp nghi trùng.

Cách rà hóa đơn trùng được viết trong skill, nhưng việc thực thi diễn ra bên trong sub-agent chỉ có quyền Read, Grep, Glob. Khi khách đổi tiêu chí thế nào là trùng, bạn sửa skill. Khi đội bảo mật muốn siết quyền, bạn sửa sub-agent. Hai việc không đụng nhau.

Context là ngân sách, phải tiêu cho đúng

Cách chia này xuất phát từ một thực tế: context có giá. Tài liệu Claude Code nói rõ rằng khác với nội dung trong CLAUDE.md, phần thân của skill chỉ được nạp khi dùng, nên tài liệu tham khảo dài gần như không tốn gì cho tới lúc thật sự cần.

Một bảng mã loại trừ dài mười trang đặt trong CLAUDE.md sẽ ăn context ở mọi lượt hội thoại. Đặt trong skill, nó chỉ chiếm chỗ đúng lúc agent đang thẩm định hồ sơ.

MCP cũng có cái giá riêng: nạp trước định nghĩa của quá nhiều tool sẽ tốn context. Anthropic đã thử cho agent viết code để gọi tool thay vì nạp hết định nghĩa ngay từ đầu, và trong một ví dụ, lượng token giảm từ 150.000 xuống 2.000. Một MCP server có năm mươi tool mỏng, tool nào cũng kèm mô tả dài, là một khoản nợ.

Sub-agent là lựa chọn đắt nhất. Anthropic ghi nhận hệ thống multi-agent nghiên cứu của họ dùng khoảng 15 lần token so với chat thông thường, và kiểu kiến trúc này kém phù hợp với những việc coding ít chỗ để chạy song song.

Con số đó đo cả một hệ thống nhiều agent chứ không phải một lần gọi sub-agent, nhưng hướng đi thì rõ: mỗi context tách riêng là thêm một khoản token phải trả.

Vì thế, chỉ dùng sub-agent khi việc phụ sẽ làm ngập cuộc hội thoại chính bằng kết quả tìm kiếm, log hay nội dung file không bao giờ đọc lại, hoặc khi bạn cần một ranh giới quyền.

Làm tại chỗ khách theo trình tự nào?

Sau buổi discovery, đừng mở editor ngay. Chép mọi điều khách nói thành từng dòng riêng, rồi lần lượt hỏi mỗi dòng ba câu: cần truy cập hệ thống nào, cần làm theo cách nào, có cần không gian và quyền riêng không. Dòng nào không trả lời “có” cho câu thứ ba thì mặc định không phải sub-agent.

Tiếp theo, dựng MCP server với ít tool, mỗi tool rõ nghĩa, và không viết quy trình vào mô tả tool. Sau đó mới viết skill. Hãy dồn công nhiều nhất cho dòng description, vì đó là thứ duy nhất agent nhìn thấy khi quyết định có gọi skill hay không. Viết nó bằng chính những từ người dùng bên khách hay nói, đừng dùng thuật ngữ của bạn.

Cuối cùng, lấy những câu hỏi thật của người dùng bên khách để kiểm tra agent có gọi đúng skill, đúng tool không. Khi khách đổi ngưỡng duyệt mà bạn chỉ phải sửa một file markdown, đó là dấu hiệu bạn đã đóng gói đúng.

Bốn lỗi hay gặp

Lỗi phổ biến nhất là nhét cả quy trình vào CLAUDE.md hoặc system prompt. Bản demo vẫn chạy, nhưng mỗi quy trình mới lại chiếm thêm context ở mọi lượt, và đến tháng thứ ba thì không ai dám sửa file đó nữa.

Lỗi thứ hai là viết logic nghiệp vụ vào MCP server, chẳng hạn gói một tool kiểu “thẩm định toàn bộ hồ sơ” với hàng chục nhánh if-else. Quy trình khi đó bị khóa trong code của server, đội nghiệp vụ không đọc được và cũng không sửa được. Hãy giữ MCP thật mỏng và để skill gánh phần quy trình.

Lỗi thứ ba là việc gì cũng tách sub-agent cho có vẻ kiến trúc. Mỗi context tách riêng là thêm token phải trả, và khách sẽ thấy hóa đơn trước khi thấy giá trị. Lỗi thứ tư thì ngược lại: có tạo sub-agent nhưng để nó kế thừa mọi tool, tức là đánh mất đúng lợi ích lớn nhất của nó là ranh giới quyền.

Viết vào CV thế nào cho người tuyển hiểu?

Ví dụ bồi thường ở trên có thể thành một dòng CV cụ thể.

Thay vì viết “xây agent cho công ty bảo hiểm”, hãy viết đại ý: “Tách quy trình thẩm định bồi thường thành một skill gồm SKILL.md, bảng mã loại trừ và script tính chi trả; MCP server chỉ đọc hợp đồng và hóa đơn; sub-agent rà hóa đơn trùng chỉ được cấp quyền Read, Grep, Glob.”

Dòng đó cho người đọc thấy bạn biết đặt quy trình, kết nối và quyền hạn vào ba chỗ khác nhau, và biết lý do. Nếu được hỏi trong phỏng vấn, hãy kể tiếp phần khách đổi ngưỡng duyệt và bạn chỉ phải sửa một file.

Model sẽ còn thay đổi nhiều lần trong những năm tới. Thứ ở lại với khách là cách bạn sắp xếp tri thức của họ: quy trình đọc được, kết nối dùng lại được, và quyền hạn được viết rõ ra giấy.