AI agent dùng trong ứng dụng web đang bước qua giai đoạn chỉ cần một mô hình và vài prompt. Những chủ đề nổi lên gần đây—kỹ năng có thể tái sử dụng, bộ nhớ dạng tệp, MCP, đánh giá hành vi và harness thực thi—đều hướng đến cùng một vấn đề: làm thế nào để kiểm soát agent sau khi đưa vào production.

Đây không phải bằng chứng rằng một kiến trúc duy nhất đã trở thành tiêu chuẩn. Tuy nhiên, các nguồn cho thấy đội ngũ kỹ thuật đang dần tách logic vận hành khỏi prompt, biến nó thành những thành phần có thể quản lý, kiểm thử và thay thế độc lập.

Vì sao prompt không thể đóng vai trò control plane?

Prompt có thể hướng dẫn mô hình, nhưng không tự xác định agent được phép dùng công cụ nào, thông tin nào phải được lưu, cách phát hiện hành vi suy giảm hay điều gì xảy ra khi một thao tác thất bại. Khi agent bắt đầu đọc dữ liệu, gọi dịch vụ hoặc thay đổi trạng thái của hệ thống web, những câu hỏi này trở thành vấn đề kiến trúc thay vì kỹ thuật viết câu lệnh.

Ý tưởng ghi lại hành vi lặp lại của agent để làm tiêu chuẩn đánh giá minh họa cho sự dịch chuyển đó. Thay vì chỉ chấm một câu trả lời cuối, đội ngũ có thể mô tả những hành vi mong đợi và dùng chúng làm cơ sở phát hiện thay đổi qua các lần cập nhật mô hình, công cụ hoặc ngữ cảnh.

Một harness cũng giúp tách mô hình khỏi vòng đời thực thi. Dự án TrueForge được giới thiệu như một harness mã nguồn mở để chạy LLM dưới dạng agent, cho thấy lớp điều phối đang trở thành một đơn vị kỹ thuật riêng. Về mặt thiết kế, lớp này là vị trí hợp lý để đặt giới hạn vòng lặp, chính sách công cụ, xử lý lỗi và ghi nhận kết quả, dù mỗi sản phẩm sẽ triển khai khác nhau.

Các lớp kiểm soát production đang hình thành như thế nào?

Có thể nhóm các chủ đề hiện tại thành bốn lớp. Chúng không thay thế nhau; mỗi lớp kiểm soát một loại bất định khác nhau trong quá trình agent thực hiện nhiệm vụ.

Đối với kỹ năng, hướng dẫn về AI SDLC và quá trình xây dựng agent skills đặt kỹ năng vào một vòng đời phát triển thay vì xem chúng như prompt dùng một lần. Bài viết về sự suy giảm kỹ năng agent còn nhấn mạnh vai trò của thực hành lặp lại, một tín hiệu rằng kỹ năng cần được theo dõi và cải tiến liên tục.

Với bộ nhớ, đề xuất rằng agent memory nên là một định dạng tệp thay vì pipeline gợi mở một lợi ích quan trọng: trạng thái có thể trở thành artifact rõ ràng. Một định dạng ổn định có khả năng giúp việc kiểm tra, phiên bản hóa và di chuyển dễ hiểu hơn so với việc giấu toàn bộ logic trong chuỗi xử lý riêng, nhưng nguồn được cung cấp chưa đủ để kết luận định dạng nào sẽ thắng thế.

MCP giải quyết phần nào và không giải quyết phần nào?

Model Context Protocol tập trung vào giao diện giữa agent với công cụ hoặc nguồn ngữ cảnh. Sự tồn tại của một lộ trình MCP gồm năm lĩnh vực trọng tâm và tài liệu về xây dựng, bảo mật và phục vụ MCP server cho thấy mối quan tâm đã vượt khỏi thử nghiệm kết nối đơn giản để tiến tới vận hành hạ tầng.

Tuy nhiên, giao thức không tự giải quyết toàn bộ bài toán quản trị. Một MCP server có thể chuẩn hóa cách mô tả và gọi công cụ, nhưng nhóm triển khai vẫn phải quyết định danh tính nào được truy cập, credential được cấp và thu hồi ra sao, đối số nào phải xác thực, dữ liệu nào được phép trả về và mỗi thao tác cần được ghi nhận như thế nào.

Điểm phân tách này rất quan trọng với ứng dụng web. Lớp giao thức tạo ra khả năng tương tác; lớp control plane áp dụng chính sách của tổ chức. Cách tiếp cận tương tự cũng xuất hiện trong thiết kế control plane có quản trị cho hệ thống tự động hóa: kết nối thực thi phải đi cùng quyền hạn, chính sách và khả năng theo dõi.

Đội ngũ web nên thử nghiệm theo trình tự nào?

Không nên bắt đầu bằng cách cho agent quyền truy cập rộng vào hệ thống production. Một thử nghiệm hữu ích nên chọn quy trình có phạm vi hẹp, đầu ra có thể kiểm chứng và hậu quả có thể đảo ngược, sau đó bổ sung từng lớp kiểm soát trước khi mở rộng quyền.

1. Viết hợp đồng nhiệm vụ: xác định đầu vào, đầu ra, điều kiện hoàn thành và các hành động bị cấm.
2. Tách kỹ năng khỏi prompt gốc: lưu hướng dẫn và tệp ngữ cảnh như artifact có phiên bản để có thể review thay đổi.
3. Giới hạn công cụ: chỉ cung cấp thao tác cần thiết, ưu tiên quyền chỉ đọc và credential ngắn hạn nếu hạ tầng hỗ trợ.
4. Ghi lại dấu vết thực thi: lưu lệnh gọi công cụ, kết quả, lỗi và quyết định quan trọng mà không để lộ bí mật.
5. Xây bộ đánh giá hành vi: kiểm thử cả kết quả cuối lẫn chuỗi hành động trên các tình huống thành công, dữ liệu thiếu và lỗi công cụ.

Nếu cần khảo sát cách MCP có thể phối hợp nhiều vai trò phát triển, ví dụ Nova MCP biến AI thành một đội ngũ sản phẩm cung cấp thêm một góc nhìn. Dù vậy, quyết định production nên dựa trên thử nghiệm với dữ liệu, quyền truy cập và chế độ lỗi thực tế của chính hệ thống.

Kết luận

• Prompt chỉ là một phần của agent; production cần thêm lớp thực thi, quyền hạn, bộ nhớ và đánh giá.
• Kỹ năng và tệp ngữ cảnh nên được quản lý như artifact có phiên bản, không phải văn bản dùng một lần.
• MCP giúp chuẩn hóa kết nối nhưng không thay thế xác thực, chính sách truy cập hay audit.
• Nên thử nghiệm trên quy trình hẹp và có thể đảo ngược trước khi cấp quyền production.

Bài viết liên quan

• Ventura React: thư viện component nhẹ còn phù hợp cho dự án mới?
• Nova MCP: Biến AI trong Cursor và Claude thành đội ngũ sản phẩm
• Ansible Automation Orchestrator: thiết kế control plane có quản trị

Nguồn tham khảo

• Agent Behavior - AI 에이전트의 반복 행동을 문서화해 평가 기준으로 삼는 표준
• Claude로 커머스 에이전트 구축하기
• 에이전틱 스킬 감쇠 : 숙련은 여전히 반복에서 나온다
• 에이전트 메모리는 파이프라인이 아니라 파일 형식이어야 한다
• TrueForge - LLM을 실제 에이전트로 실행하는 오픈소스 하네스
• Learn the AI SDLC – The Complete Guide to Building Agent Skills
• MCP in practice: building, securing, and serving Model Context Protocol servers
• 새로운 MCP 로드맵 - 앞으로 집중할 5가지 영역