Link bài viết gốc： https://mp.weixin.qq.com/s/mUA-UziZPe0L1...
Tencent Programmer · Official Account · Kỹ thuật Công nghệ Tencent · 2026-10-12 17:36
Bài viết này được chia sẻ lại, bản quyền thuộc về tác giả gốc, toàn văn căn cứ theo link bài gốc
Tác giả: robinji
Bài viết này cố gắng trả lời hai câu hỏi: một là mối quan hệ giữa năm khái niệm Agent, Skill, MCP, CLI, Model rốt cuộc là gì, cái nào gọi cái nào; hai là các hệ thống cũ đã vận hành nhiều năm trong doanh nghiệp nên bắt đầu từ đâu để có thể thực sự ứng dụng được AI. Nội dung bao gồm sơ đồ tổng quan mối quan hệ của năm khái niệm, quy trình tiếp sức trọn vẹn của một lượt gọi công cụ, ba lộ trình tích hợp hệ thống cũ (đóng gói API, bọc CLI, dùng RPA làm phương án dự phòng), phân loại đầy đủ các hình thức triển khai MCP, cùng các case study thực chiến trên hai kiến trúc BS và CS.
1. Khởi nguồn câu chuyện
Khách hàng là đội ngũ IT thuộc viện nghiên cứu của một tập đoàn sản xuất ô tô lớn trong nước. Ban lãnh đạo tập đoàn giao cho họ một đề tài: "Đưa AI đi sâu vào các hệ thống nghiệp vụ cũ". Cách diễn đạt này hoàn toàn không nói đến việc "triển khai một hệ thống AI mới". Hai cách nói này khác biệt rất lớn, những ai từng làm IT doanh nghiệp đều hiểu: triển khai hệ thống mới là bài toán mua sắm, còn đi sâu vào hệ thống cũ là bài toán kỹ thuật. Ban lãnh đạo đã chỉ đích danh, đề bài này không thể né tránh.
Điểm khiến anh em IT đau đầu trước hết nằm ở tầng khái niệm. Agent, Skill, MCP, CLI, Model - những thuật ngữ này hiện đang ngập tràn khắp nơi. Rốt cuộc quan hệ giữa chúng là gì, cái nào gọi cái nào, các tiêu chuẩn và công cụ gồm những gì, bình thường chưa có ai phân tích một cách có hệ thống.
Vấn đề thực tế hơn là, với những hệ thống cũ đã chạy 8 đến 10 năm trong tay - như hệ thống nghỉ phép/hủy phép, PLM, các loại nền tảng nội bộ - rốt cuộc phải "ra tay" từ đâu thì mới dùng được AI. Nhu cầu của khách hàng rất mộc mạc: giải thích cho rõ ràng trước, rồi mới bàn cách sửa đổi. Vì thế buổi trao đổi này và bản PPT dài 42 trang đã ra đời.
2. Năm khái niệm tạo thành một đội ngũ
Câu hỏi đầu tiên của khách hàng là: các khái niệm này rốt cuộc có mối quan hệ như thế nào. Cách tiếp cận của chúng tôi là dùng phép ẩn dụ. Đừng học vẹt các thuật ngữ kỹ thuật, hãy tưởng tượng toàn bộ hệ thống AI như một đội ngũ số hóa mới gia nhập công ty.
| khái niệm | Vai trò trong đội ngũ | Làm gì |
|---|---|---|
| Model (mô hình lớn (LLM)) | Não | Chịu trách nhiệm suy nghĩ, là engine suy luận và tạo sinh |
| Tác nhân | Nhân viên kỹ thuật số | Chịu trách nhiệm thực thi, là thực thể khép kín vận hành theo mục tiêu, tự chủ lập kế hoạch và gọi công cụ |
| Kỹ năng | Sổ tay kỹ năng vị trí | Chịu trách nhiệm về năng lực, đóng gói quy trình và kinh nghiệm thành các gói kỹ năng mà Agent có thể tải nạp |
| MCP | Đầu chuyển đổi vạn năng | Chịu trách nhiệm kết nối, là giao thức tiêu chuẩn mở kết nối AI với các hệ thống bên ngoài |
| CLI | Bộ đàm | Chịu trách nhiệm truyền đạt, là kênh tương tác có chỉ lệnh rõ ràng, phản hồi minh bạch và ghi nhận được nhật ký |
Dưới đây sẽ đi vào phân tích chi tiết từng khái niệm.
- Model là bộ não. Nó có các thuộc tính như số lượng tham số, context window, đa phương thức (multimodal), nhưng bộ não dù thông minh đến đâu mà không có tay chân thì cũng chẳng làm được việc, bản thân model không thể chạm tới dù chỉ một dòng dữ liệu trong cơ sở dữ liệu của bạn.
- Agent là nhân viên kỹ thuật số. Bạn giao cho nó một mục tiêu, nó sẽ tự chia nhỏ nhiệm vụ, tìm công cụ, thực thi, xem kết quả, rồi điều chỉnh tiếp; nhận thức, lập kế hoạch, hành động, quan sát, rồi tái lập kế hoạch - đây là một vòng khép kín. Điểm dễ gây nhầm lẫn nhất cần làm rõ trước: Agent là cả một hệ thống, còn Model chỉ là một thành phần trong đó.
- Skill là sổ tay vị trí. Khi nhân viên mới vào công ty được phát một cuốn sổ tay, một nhân viên phổ thông sẽ trở thành người thạo việc trong lĩnh vực đó. Skill chính là làm điều này: điều kiện kích hoạt cộng với quy trình thao tác, tri thức nghiệp vụ và danh sách công cụ, là tài sản quy trình đã được kỹ thuật hóa và có thể quản lý phiên bản. Nó khác với prompt: prompt chỉ là một câu dặn dò tùy tiện, còn Skill là SOP đã được ghi vào sổ tay nhân viên.
- MCP là đầu chuyển đổi vạn năng, cũng là trọng tâm của toàn bộ bài chia sẻ. Tên chính thức là Model Context Protocol, một giao thức tiêu chuẩn mở. Một bên là Agent, một bên là bất kỳ hệ thống nào - cơ sở dữ liệu, API, tệp tin, thiết bị - dù là loại chân cắm nào thì cũng quy về một chuẩn giao diện thống nhất.
- CLI là bộ đàm, tức giao diện dòng lệnh. Nó mang thân phận kép: đối với kỹ sư thì là công cụ thao tác hiệu quả cao, còn đối với Agent thì là kênh gọi có cấu trúc.
Trình bày xong năm khái niệm, vẫn còn một mối quan hệ rất dễ bị bỏ qua: MCP và CLI có thể lồng ghép vào nhau. Việc triển khai bên trong một MCP Server thường chính là đóng gói một CLI. Ví dụ nhỏ nhất là đóng gói git bash thành MCP Server, Agent thông qua giao thức MCP để gọi gián tiếp lệnh git. Đối với Agent, nó chỉ nhìn thấy lớp vỏ tiêu chuẩn MCP, còn đằng sau là CLI, API hay script thì nó không cần biết. Nói thẳng thắn hơn, CLI quản lý cách công cụ thực thi, còn MCP quản lý cách phơi bày công cụ một cách chuẩn hóa cho AI. Hãy ghi nhớ mối quan hệ lồng ghép này, phần sau nói về cải tạo hệ thống cũ sẽ liên tục nhắc lại.
3. Chúng phối hợp với nhau như thế nào
Sau khi làm rõ khái niệm, câu hỏi thứ hai đến rất tự nhiên: Khi người dùng nói một câu, đằng sau rốt cuộc đã diễn ra những gì? Lấy câu "Tra giúp tôi lịch sử nghỉ phép tuần trước" làm ví dụ, khi câu này được đưa vào, phía sau là cả một cuộc chạy tiếp sức.
Người dùng nhập câu nói này trong CLI hoặc bất kỳ cổng hội thoại nào. Agent tiếp nhận mục tiêu, giao nhiệm vụ cho Model lập kế hoạch. Model nhận định việc này cần tra cứu hệ thống HR, trong sổ tay nhân viên đã có quy trình chuẩn. Agent tải nạp Skill tương ứng, lần theo quy trình để tìm công cụ cần gọi, rồi thông qua giao thức MCP gửi yêu cầu gọi đến MCP Server nghỉ phép/hủy phép. MCP server sau đó mới đi gọi REST API của hệ thống cũ. Kết quả lần lượt trả về theo đường cũ qua từng tầng, Agent dùng ngôn ngữ tự nhiên thông báo cho người dùng: tuần trước bạn đã xin nghỉ phép năm 2 ngày, hạn mức còn lại là 8,5 ngày.
Ở đây chúng tôi cũng thử đối chiếu giữa các khái niệm phần mềm truyền thống và thế giới AI để bạn dễ hình dung hơn.
| Thế giới phần mềm truyền thống | Thế giới AI |
|---|---|
| Microservice | Tác nhân |
| OpenAPI / REST | MCP |
| Wiki nội bộ / SOP | Kỹ năng |
| SDK / Dòng lệnh | CLI |
Hiểu rõ bảng này, cái gọi là kiến trúc AI sẽ không còn là thuật ngữ khó hiểu nữa. Nó chính là sơ đồ kiến trúc mà bạn đã vẽ suốt mười mấy năm qua, chỉ có điều nội dung bên trên đã được thay bằng một lớp mới mà thôi.
4. Cải tạo hệ thống cũ như thế nào
Đây là phần khách hàng quan tâm nhất, và cũng là cốt lõi trong đề tài của ban lãnh đạo.
Lời khuyên đầu tiên của chúng tôi có thể hơi gây hụt hẫng: không có viên đạn bạc nào cả. Phương án hoàn toàn phụ thuộc vào kết quả "khám sức khỏe" hệ thống.
Đợt kiểm tra sẽ đánh giá qua 4 chiều: mức độ mở của API, độ hoàn thiện của tài liệu, hệ thống xác thực/phân quyền, và mức độ chịu rủi ro khi thay đổi. Sau khi kiểm tra xong sẽ đi theo cây quyết định, tổng cộng có ba lộ trình.
- Lộ trình 1: Đóng gói API thành MCP, ưu tiên số một. Hệ thống có sẵn API mở, chỉ cần thêm một lớp đóng gói mỏng MCP Server phía trước. Mức độ thay đổi nhỏ nhất, ổn định nhất, có thể chạy canary. Kỷ luật chỉ có một: tầng đóng gói chỉ làm nhiệm vụ chuyển đổi giao thức, tuyệt đối không can thiệp vào logic nghiệp vụ.
- Lộ trình 2: Bọc CLI, lựa chọn thứ hai. Không có API nhưng có dòng lệnh, có script vận hành bảo trì; ta đóng gói script thành CLI có cấu trúc, rồi bọc thêm một lớp MCP bên ngoài. Ví dụ về git bash ở trên chính là hình mẫu tối thiểu của con đường này. Yêu cầu kỹ thuật là đầu ra của CLI phải có cấu trúc, tốt nhất là JSON thì Agent mới có thể xử lý được.
- Lộ trình 3: Tự động hóa trình duyệt hoặc RPA, phương án dự phòng cuối cùng. Khi hệ thống chỉ còn trơ trọi giao diện web, thậm chí không có script, ta dùng tự động hóa trình duyệt để mô phỏng thao tác của con người. Dùng được, nhưng rất mong manh, chỉ cần trang web đổi giao diện là hỏng ngay. Đây là giải pháp quá độ, đừng coi là đích đến cuối cùng.
Mức độ ưu tiên của ba lộ trình giảm dần từ trên xuống dưới, mức độ can thiệp cải tạo giảm dần, nhưng độ mong manh lại tăng dần.
Sau đó, cần phải tạt một gáo nước lạnh về vấn đề bảo mật. Xác thực và bảo mật phải đánh giá theo từng trường hợp cụ thể. Khi Agent thay con người thao tác hệ thống: danh tính truyền từ người dùng sang Agent rồi sang hệ thống thế nào, quyền hạn thu hẹp tối thiểu ra sao, thao tác audit thế nào, các hành động nhạy cảm có cần người xác nhận không - ngành hiện chưa có giải pháp tiêu chuẩn phổ quát, từng hệ thống đều phải thẩm định riêng biệt. Ai dám cam đoan với bạn rằng đã có sẵn giải pháp, người đó chắc chắn chưa từng làm triển khai thực tế cấp doanh nghiệp.
Cuối cùng là cách sắp xếp thứ tự ưu tiên. Hãy vẽ một biểu đồ 4 góc phần tư "Tần suất sử dụng - Giá trị nghiệp vụ", bắt đầu từ những hệ thống có tần suất cao, rủi ro thấp và có sẵn API trước. Lý do rất thực tế: Trận đánh đầu tiên bắt buộc phải thắng, và còn phải thắng với chi phí rẻ.
5. Các hình thức triển khai MCP
Trước buổi trao đổi, khách hàng đã tìm hiểu trước và hỏi chúng tôi có phải MCP có 3 hình thức triển khai là stdio, HTTP và SSE hay không. Đúng, nhưng chưa hoàn toàn chính xác.
Ở đây có một sự thật mà ngay cả nhiều bài viết kỹ thuật cũng nhầm lẫn: Trong đặc tả kỹ thuật chính thức của MCP chỉ có hai phương thức truyền tải tiêu chuẩn là stdio và Streamable HTTP. SSE đã bị thay thế từ tháng 3 năm 2025 và là phương án lịch sử.
Bức tranh toàn cảnh chia thành 4 nhóm. Tiêu chuẩn chính thức có hai loại: stdio và Streamable HTTP, đây là các tùy chọn mặc định. Tồn dư lịch sử có một loại: HTTP kết hợp SSE, chỉ dùng cho việc migrate hệ thống cũ, không dựng mới. Mở rộng từ cộng đồng có một loạt: WebSocket, WebRTC, RPC nội tiến trình - đây là những thứ do hệ sinh thái phát triển thêm ngoài tiêu chuẩn, dùng tùy theo nhu cầu.
Còn một nhóm nữa rất dễ gây nhầm lẫn: MCP Gateway, Proxy, MCP được quản lý - chúng thuộc về kiến trúc triển khai chứ không liên quan đến giao thức mới, nhưng lại rất hay bị đánh đồng với phương thức truyền tải. Cần xác lập trước một nhận thức: MCP độc lập với tầng truyền tải, logic giao thức không đổi, thứ thay đổi chỉ là cách thức tin nhắn được luân chuyển mà thôi.
Dưới đây xin tóm tắt ngắn gọn từng hình thức.
- stdio: Chương trình host khởi tạo trực tiếp tiến trình con cục bộ, giao tiếp qua stdin/stdout tiêu chuẩn. Đây là cách thức chuẩn mực cho phát triển local và Agent trên desktop; hạn chế là chỉ chạy trên một máy với một client, quan hệ tin cậy chỉ dừng ở cấp tiến trình.
- Streamable HTTP: Một endpoint HTTP duy nhất, dùng POST để gửi request, dùng GET để tạo stream nhận push, hỗ trợ duy trì session và khôi phục khi mất kết nối, kết hợp OAuth 2.0. Phù hợp triển khai tập trung trong doanh nghiệp, chia sẻ đa nhóm; đây là phương thức từ xa duy nhất được khuyến nghị chính thức.
- SSE: Giải pháp đời đầu với hai endpoint; hễ gặp nó thì chỉ có một hành động duy nhất: lên kế hoạch migration.
- WebSocket: Song công toàn phần, độ trễ thấp; kịch bản điển hình là cầu nối trình duyệt, ví dụ Agent kết nối extension Chrome để làm tự động hóa trình duyệt. Đánh đổi lại là load balancing phải xử lý sticky session, và tường lửa doanh nghiệp có thể chặn bắt tay nâng cấp.
Việc lựa chọn giải pháp có thể đúc kết trong 4 câu: Phát triển local dùng stdio; chia sẻ trong doanh nghiệp dùng Streamable HTTP kết hợp OAuth; SSE chỉ dùng để migrate hệ thống cũ; WebSocket dành cho các kịch bản thời gian thực và trình duyệt.
6. Hai case study thực tế
Chỉ nói phương pháp luận khách hàng sẽ không phục, phải có thực chiến. Chúng tôi chọn hai trường hợp: một theo kiến trúc BS, một theo kiến trúc CS.
Trường hợp 1: Hệ thống nghỉ phép/hủy phép của một hãng xe hơi hàng đầu, kiến trúc BS, đi theo lộ trình 1. Hệ thống Java Web, có sẵn REST API, là kịch bản tần suất cao của HR. Điểm đau rất cụ thể: nhân viên muốn tra cứu số ngày phép còn lại phải đăng nhập hệ thống và bấm qua 5 bước, HR hàng tháng vẫn phải đối soát thủ công. Cách cải tạo rất trực diện: thêm một MCP Server phía trước REST API, triển khai tập trung qua Streamable HTTP, xác thực tích hợp với SSO doanh nghiệp, hệ thống cũ không cần sửa một dòng code nào. Sau khi cải tạo, nhân viên chỉ cần gõ vào cửa sổ chat: "Xin nghỉ phép năm giúp tôi chiều mai nửa ngày", 5 bước rút gọn thành 1 câu nói.
Trường hợp 2: Hệ thống PLM của một hãng xe thương mại châu Âu, kiến trúc CS, đi theo lộ trình 2. Desktop client truyền thống, không có REST API mở, nhưng client có sẵn API và SDK. Điểm đau là tình trạng cô lập dữ liệu, kỹ sư phải chuyển dữ liệu BOM và bản vẽ thủ công giữa các hệ thống. Khi cải tạo, một service đóng gói cục bộ được triển khai ngay cạnh client PLM, bọc API của client thành các interface có cấu trúc, sau đó bọc thêm một lớp MCP bên ngoài; session và quyền hạn kế thừa trực tiếp trạng thái đăng nhập sẵn có của client.
Đối chiếu hai trường hợp này với nhau, có 3 bài học kinh nghiệm có thể tái sử dụng: Hãy "khám sức khỏe" hệ thống trước rồi mới chọn lộ trình, đừng cầm búa đi tìm đinh. Tầng đóng gói phải mỏng, không can thiệp logic nghiệp vụ, tầng đóng gói càng mỏng thì dự án càng khó thất bại. Xác thực/phân quyền phải đánh giá riêng theo từng trường hợp, hãy đưa nó vào kế hoạch dự án, đừng coi như một sự cố bất ngờ.
7. Hiệu quả
Sau buổi trao đổi, khách hàng đã đánh giá rất cao. Theo lời họ, buổi chia sẻ này đã làm sáng tỏ mối quan hệ giữa các thuật ngữ như Agent, MCP, và cây quyết định với 3 lộ trình có thể áp dụng trực tiếp ngay vào hệ thống hiện có của họ.
Tự chúng tôi review lại, một buổi trao đổi kỹ thuật với khách hàng đạt được mức này coi như là đạt yêu cầu. Tiêu chuẩn chỉ có một: sau khi nghe xong, đối phương cảm thấy "việc này tự chúng tôi cũng làm được".
Học tương tác với AI (NotebookLM)
Ngoài đọc , bạn có thể nghe , xem và xem hoạ thông tin ở đầu bài. Bài này còn có bộ công cụ tương tác do AI tạo: Bài kiểm tra trắc nghiệm, Thẻ ghi nhớ, Sơ đồ tư duy, Bản trình bày và Báo cáo chuyên sâu.
Mở không gian học tương tác