Xây dựng AI Agent quy mô lớn bằng kỹ thuật chuyển đổi prompt dạng module

16 THÁNG 7, 2026

Khi bạn mới bắt đầu xây dựng một AI agent, một system prompt đơn khối (monolithic) thường là đủ dùng. Bạn chỉ có vài chỉ dẫn, có thể thêm một hoặc hai định nghĩa công cụ, và mọi thứ nằm gọn trong một tệp tin dễ đọc.

Tuy nhiên, khi bắt đầu đưa chúng vào môi trường production, định dạng đó sẽ trở nên bất cập. Các đội ngũ bắt đầu thêm vào các lớp chính sách an toàn, quy tắc chuyên biệt cho từng lĩnh vực, yêu cầu định dạng và hành vi leo thang (escalation behaviors). Đột nhiên, toàn bộ mặt phẳng điều khiển (control plane) của agent nằm trong một tệp chỉ dẫn duy nhất, và đó chính là nơi rắc rối bắt đầu.

Đây là vấn đề kinh điển về khả năng mở rộng trong kỹ thuật phần mềm. Khi bạn dồn mọi mối quan tâm vào một tệp duy nhất, bạn mất đi khả năng suy luận về hệ thống. Việc cộng tác trở thành một cơn ác mộng, kiểm thử trở nên khó khăn, và một thay đổi nhỏ nhằm cải thiện quy trình này có thể âm thầm làm hỏng quy trình khác.

Ở quy mô production, khả năng bảo trì prompt chính là độ tin cậy của agent.

Tại sao các prompt đơn khối lại thất bại

Chúng ta thường thấy ba kiểu lỗi chính khi các prompt vượt quá một kích thước nhất định:

Các template là một khởi đầu tốt, nhưng chưa đủ. Các hệ thống production đòi hỏi các bản build có tính xác định (deterministic), kiểm chứng tĩnh (static validation) và tích hợp CI/CD.

Hãy coi prompt như các thành phần phần mềm (software artifacts)

Giải pháp ở đây là coi các prompt như các thành phần build thay vì chỉ là văn bản tĩnh.

Thay vì duy trì một tệp prompt đơn khối, bạn có thể tạo ra các tệp kỹ năng (skill files) dạng mô-đun. Điều này cho phép bạn thu hẹp phạm vi của từng tệp và đóng gói các hành vi cụ thể, giúp các đội ngũ tách biệt các mối quan tâm và lặp lại (iterate) trên từng thành phần riêng lẻ.

Một template prompt cho agent ở cấp cao nhất có thể trông như thế này:

Văn bản thuần (Plain text)

Đã sao chép (Copied)

Cách này mang lại lợi ích từ cả hai phía. Lớp tạo template cho phép bạn soạn thảo các chỉ dẫn dùng chung, chèn các giá trị đặc thù của môi trường và sử dụng các macro. Nhưng đối với hệ thống build, mỗi lệnh include là một phụ thuộc (dependency), và mỗi biến là một yêu cầu. Kết quả là một thành phần đã được render hoàn chỉnh, có tính xác định, mà bạn có thể kiểm thử, kiểm toán và so sánh (diff) trước khi nó đến tay mô hình. Sau đó, chúng ta có thể sử dụng một trình biên dịch (transpiler) để giải quyết các import trong template, tạo ra một tệp sẵn sàng để agent tiếp nhận.

Ví dụ, nếu environment = production và allow_remediation = true, thành phần sau khi transpiled sẽ trông như thế này:

Văn bản thuần (Plain text)

Đã sao chép (Copied)

Một pipeline transpilation cấp cao sẽ trông như thế này:

Kiểm chứng tại thời điểm build là bắt buộc

Một trình transpiler cấp độ production cần phải phát hiện được lỗi trước khi runtime.

Chúng ta nên thực hiện các kiểm tra xác thực cho các import bị thiếu, các biến chưa được định nghĩa và các phụ thuộc vòng (circular dependencies) trong quá trình build. Các đồ thị phụ thuộc (dependency graphs) cực kỳ hữu ích ở đây, củng cố nhu cầu về một công cụ template mạnh mẽ. Nếu bạn coi mỗi đoạn prompt là một nút trong một đồ thị có hướng, bạn có thể dễ dàng phát hiện các import đệ quy vốn có thể gây ra lỗi ngầm trong production.

Điều này cũng cho phép kiểm tra sự sai lệch (drift checking). Bạn có thể thiết lập các pipeline CI để tái tạo prompt đã transpiled từ nguồn (được gọi là tệp golden) và so sánh nó với thành phần hiện đang được commit. Nếu kết quả đầu ra khác nhau, quá trình build sẽ thất bại. Điều này đảm bảo rằng mã trong repo của bạn chính xác là những gì đang chạy trong production, loại bỏ khoảng cách giữa tệp nguồn và các thành phần đã triển khai.

Các kỹ năng động và cập nhật do agent tự thực hiện

Khi thư viện kỹ năng gồm các đoạn prompt mô-đun của bạn phát triển, bạn không nhất thiết muốn mọi agent phải tải mọi kỹ năng mỗi lần. Làm như vậy sẽ tiêu tốn token và tạo ra nhiễu, có thể cản trở hiệu suất thực hiện nhiệm vụ cụ thể của agent.

Một mô hình kiến trúc tốt hơn là tận dụng cơ chế tiết lộ lũy tiến (progressive disclosure). Đây là cách chúng ta tách biệt mặt phẳng điều khiển ổn định khỏi ngữ cảnh cụ thể của nhiệm vụ. Prompt cơ sở đã biên dịch nên thực thi các hành vi không thể thương lượng như định danh và ranh giới an toàn. Sau đó, tại runtime, agent có thể sử dụng một công cụ để truy xuất động chỉ các mô-đun kỹ năng cần thiết cho nhiệm vụ hiện tại; điều này giúp giảm tình trạng cạn kiệt ngữ cảnh và giữ cho agent tập trung vào nhiệm vụ của mình.

Một khi đã có hệ thống mô-đun này, bạn sẽ mở khóa được một quy trình mạnh mẽ: các agent có thể hỗ trợ duy trì lớp chỉ dẫn của chính chúng, giúp tạo ra một hệ thống agent tự duy trì. Khi một agent giải quyết một loại sự cố mới, về lý thuyết, nó có thể soạn thảo một mô-đun kỹ năng mới, cập nhật các import liên quan và mở một pull request.

Agent không tự thay đổi chỉ dẫn của chính nó trong thời gian thực; nó đang đề xuất một thay đổi mã. Sau đó, trình transpiler sẽ đưa đề xuất đó qua cùng các quy trình xác thực và đánh giá nghiêm ngặt như bất kỳ thay đổi mã nào khác. Một người đánh giá có thể kiểm tra PR, chạy các bài đánh giá (evals) và hợp nhất thay đổi đó.

Kết luận

Một trình transpiler prompt cấp độ production định hình lại kỹ thuật prompt như một vấn đề của hệ thống build.

Khi xây dựng các tệp kỹ năng mô-đun, chúng ta có thể giải quyết các phụ thuộc, xác thực import và thực thi kiểm tra sai lệch giống như cách chúng ta làm với cơ sở hạ tầng phần mềm tiêu chuẩn. Các agent trở nên có khả năng đề xuất cải tiến cho logic của chính chúng, với điều kiện các thay đổi đó phải vượt qua các quy trình xác thực và đánh giá hiện có của chúng ta.

Khi các AI agent được tích hợp sâu vào các quy trình quan trọng, các lớp chỉ dẫn của chúng cần các tiêu chuẩn độ tin cậy tương tự như những gì chúng ta yêu cầu đối với phần mềm của mình. Prompt không nên chỉ được chỉnh sửa, chúng cần được xây dựng, xác thực, quản lý phiên bản và triển khai.

Trước

Tiếp theo