Quy trình làm việc (workflow) đầu tiên của agent bắt đầu với một prompt và một vài công cụ. Nó trả lời các câu hỏi. Nó tra cứu trạng thái đơn hàng. Nó hoạt động tốt, vì vậy bạn cho ra mắt nó.

Sau đó, sản phẩm phát triển. Bộ phận Kinh doanh yêu cầu một trình cập nhật CRM để đồng bộ hóa ghi chú cuộc họp. Bộ phận Hỗ trợ cần một quy trình hoàn tiền tác động đến ba hệ thống nội bộ. Bộ phận Kỹ thuật thêm các hành động trình duyệt để điền vào biểu mẫu của nhà cung cấp. Mỗi yêu cầu có vẻ nhỏ nhặt. Mỗi yêu cầu lại có một tệp prompt riêng, một luồng Slack riêng, một "bản sửa lỗi nhanh" riêng. Sáu tháng sau, agent của bạn không còn là một hệ thống duy nhất nữa. Nó trở thành một đống hỗn độn gồm các prompt được sao chép, các quy tắc kinh doanh bị ẩn đi và các quyết định được đưa ra trong các luồng chat cũ mà không ai có thể tìm thấy. Đó chính là sự tràn lan prompt (prompt sprawl). Nó khiến sản phẩm AI của bạn khó kiểm thử, khó đánh giá và không thể khôi phục (roll back) một cách tự tin.

Giải pháp là một danh mục kỹ năng cho AI agent (AI agent skill registry).

Bản chất thực sự của một Kỹ năng (Skill) là gì

Một kỹ năng không phải là một prompt được lưu vào một thư mục. Nó là một gói (package) có phiên bản, có thể kiểm thử, định nghĩa những gì agent thực hiện, những công cụ nào nó có thể gọi và những gì nó tuyệt đối không được làm. Hãy coi nó như một bản hợp đồng giữa đội ngũ của bạn và máy móc. Khi một agent tải một kỹ năng, nó phải biết chính xác ranh giới của mình ở đâu và thế nào là thành công.

Nếu không có cấu trúc này, mỗi prompt sẽ trở thành một hệ thống vận hành nhỏ, không được khai báo. Nó mang theo các quyền ẩn, các quy tắc kinh doanh được nhúng sẵn và các tác động về chi phí mà không ai theo dõi. Nó dần xa rời sản phẩm thực tế vì lộ trình sản phẩm (product roadmap) đã tiến lên phía trước trong khi prompt vẫn dậm chân tại chỗ. Tệ nhất là, nó bị sao chép. Ai đó fork nó để làm demo, hoặc dán nó vào một microservice mới, và giờ đây bạn có hai nguồn sự thật (sources of truth) đang dần khác biệt mà không ai hay biết.

Tại sao chỉ dùng Prompt là không đủ

Prompt trông giống như văn bản, vì vậy các đội ngũ thường coi chúng như các cấu hình. Trên thực tế, chúng gần với mã nguồn (code) hơn bất kỳ ai thừa nhận. Một prompt dùng trong vận hành thường mã hóa các logic về trình tự, định dạng, xử lý lỗi và kiểm soát truy cập. Khi logic đó chỉ tồn tại dưới dạng ngôn ngữ tự nhiên, bạn sẽ gặp phải sự mơ hồ. Liệu agent có quyền cập nhật CRM hay prompt chỉ đơn thuần là gợi ý điều đó? Nếu API thanh toán bị lỗi, liệu prompt có biết cách xử lý lỗi an toàn hay nó sẽ "ảo giác" (hallucinate) ra một thông báo thành công?

Chi phí là một "kẻ sát nhân thầm lặng" khác. Một prompt yêu cầu agent "suy nghĩ từng bước và tìm kiếm kỹ lưỡng" có thể tiêu tốn rất nhiều token trong mỗi lần chạy. Khi prompt đó được sao chép vào một luồng hỗ trợ có lưu lượng truy cập cao, hóa đơn suy luận (inference bill) hàng tháng của bạn sẽ tăng gấp đôi mà không ai biết lý do tại sao.

Sự sai lệch (drift) xảy ra khi các quy định kinh doanh thay đổi nhưng văn bản thì không. Chính sách hoàn tiền của bạn hiện yêu cầu sự phê duyệt của quản lý khi vượt quá một ngưỡng nhất định. Nếu quy tắc đó nằm trong một prompt thay vì một lớp chính sách (policy layer), bạn sẽ phải lùng sục qua mọi bản triển khai để tìm các bản sao cần cập nhật. Chỉ cần sót một bản, bạn sẽ có những agent đang tự ý chi tiền mà chúng không được phép.

Cấu trúc của một Kỹ năng Vận hành (Production Skill)

Nếu bạn muốn thoát khỏi mớ hỗn độn này, hãy đối xử với mỗi kỹ năng như một thành phần phần mềm (software artifact). Một kỹ năng vận hành hữu ích bao gồm nhiều thứ hơn là chỉ văn bản. Nó cần:

  • Tên và mục đích. Không phải là "prompt_v3_final", mà là "process_standard_refund" với mô tả rõ ràng về mục tiêu kinh doanh.
  • Schema đầu vào và ngữ cảnh bắt buộc. Xác định chính xác các trường mà kỹ năng mong đợi. Nó có cần ID người dùng, lịch sử trò chuyện, hay mã định danh tenant không? Việc định nghĩa kiểu dữ liệu chặt chẽ (strong typing) ở đây sẽ ngăn agent đưa ra các giả định sai lầm.
  • Quyền sử dụng công cụ và giới hạn an toàn. Liệt kê rõ ràng những công cụ mà kỹ năng có thể gọi. Thiết lập các rào chắn (guardrails) về số lần thử lại, giới hạn chi tiêu và giới hạn tốc độ (rate caps). Nếu kỹ năng không được phép chạm vào API xóa người dùng, hãy quy định điều đó bằng mã nguồn, chứ không chỉ bằng văn bản mô tả.
  • Tiêu chí thành công và các trường hợp kiểm thử (test cases). Một kỹ năng không được coi là "hoạt động" chỉ vì nó chạy được. Hãy xác định đầu ra phải chứa những gì. Đối với kỹ năng hoàn tiền, thành công có thể có nghĩa là một bản ghi giao dịch đã được xác thực, một email xác nhận đã được gửi và một mục nhật ký kiểm tra (audit log) đã được tạo.
  • Lịch sử phiên bản và người phụ trách. Cần có người chịu trách nhiệm cho việc này. Một nhật ký thay đổi (changelog) nên giải thích lý do tại sao có phiên bản v2.3 và điều gì đã bị lỗi ở phiên bản v2.2.

Chia tách các lớp của bạn

Sai lầm lớn nhất mà các đội ngũ thường mắc phải là nhồi nhét mọi thứ vào một prompt duy nhất. Họ trộn lẫn các hướng dẫn thân thiện, tài liệu công cụ, chính sách bảo mật và xử lý lỗi thành một khối văn bản khổng lồ. Điều đó là không thể bảo trì được.

Hãy chia nhỏ nó ra:

  • Instructions là các chỉ dẫn dành cho agent. Chúng giải thích về tông giọng, định dạng và cách tiếp cận chung.
  • Tool Rules cho agent biết những công cụ nào đang tồn tại và chức năng của chúng. Đây là bước khám phá, không phải là cấp quyền.
  • Policy được thực thi bằng mã nguồn, không phải bằng niềm hy vọng. Nếu một khoản hoàn tiền trên 500 USD cần có người kiểm tra lại, quy trình kiểm tra đó phải nằm trong một hàm xác thực chạy trước khi công cụ được gọi.
  • Evals là các bài kiểm tra chứng minh rằng skill vẫn hoạt động tốt sau bất kỳ thay đổi nào.

Ví dụ, đừng viết: "Làm ơn đừng bao giờ tiết lộ toàn bộ số thẻ tín dụng của khách hàng." Thay vào đó, hãy xây dựng một bộ định dạng dữ liệu để che đi số PAN trước khi agent nhìn thấy chúng. Chính sách nên nằm trong mã nguồn vì mã nguồn không thể bị thuyết phục từ bỏ nhiệm vụ bởi một đầu vào thông minh từ người dùng.

Đừng trỏ môi trường Production vào bản "Latest"

Không gì phá hỏng một tối thứ Sáu bằng một bản cập nhật prompt âm thầm. Nếu agent trên môi trường production của bạn luôn lấy phiên bản "latest" của một skill, thì mỗi lần merge vào main đều là một sự cố tiềm ẩn trên thực tế. Bạn cần các bí danh (alias) như dev, staging, và prod. Hãy đẩy một phiên bản đã được kiểm chứng qua các giai đoạn này. Khi prod trỏ đến v2.1.4, bạn có thể theo dõi nó chạy, đo lường hành vi và ngủ ngon giấc. Nếu có gì đó sai sót, bạn chỉ cần chuyển bí danh về phiên bản cũ. Bạn không cần phải debug ngôn ngữ tự nhiên vào lúc nửa đêm dưới áp lực lớn.

Kỷ luật này cũng buộc đội ngũ của bạn phải suy nghĩ về khả năng tương thích ngược (backwards compatibility). Liệu v2.2 có xử lý cùng một cấu trúc đầu vào như v2.1 không? Nếu không, quá trình đẩy phiên bản sẽ thất bại ở staging, và bạn sẽ phát hiện ra trước khi khách hàng gặp phải.

Bảo mật bắt đầu từ bên trong Package

Một registry chứa đầy các prompt chưa được kiểm duyệt là một lỗ hổng chực chờ xảy ra. Bạn cần quét các skill của mình để tìm những rủi ro tương tự như khi quét mã nguồn.

Hãy tìm các bí mật (secrets) hoặc API key được mã hóa cứng (hardcoded) ẩn trong các prompt template. Kiểm tra các webhook bên ngoài hoặc các lệnh shell có khả năng làm rò rỉ dữ liệu. Cảnh giác với các nỗ lực ghi đè chính sách hệ thống, chẳng hạn như các prompt chứa câu "ignore previous instructions" hoặc yêu cầu agent tiết lộ cấu hình của chính nó. Đây không chỉ là lý thuyết. Chúng là các mẫu phổ biến trong các cuộc tấn công prompt-injection, và chúng nguy hiểm vì thường đi kèm với các đoạn văn bản được sao chép mà không ai kiểm duyệt.

Hãy chạy các skill package của bạn qua phân tích tĩnh (static analysis). Nếu một file skill chứa một URL không nằm trong danh sách cho phép (allowlist), hãy làm cho quá trình build thất bại. Nếu nó tham chiếu đến một công cụ không có trong danh sách phê duyệt (approved manifest), hãy từ chối nó.

Nếu không thể kiểm thử, bạn không thể tin tưởng

Một registry không có các bản đánh giá (evaluations) thì chỉ là một thư mục chứa các prompt. Mỗi skill cần một bộ kiểm thử để chạy qua các trường hợp lý tưởng (happy path), các trường hợp biên (edge cases) và các chế độ lỗi (failure modes). Đối với các skill có rủi ro cao, bạn cần nhiều hơn là các bài kiểm tra chức năng. Bạn cần thăm dò các ranh giới quyền hạn để đảm bảo agent không thể xem dữ liệu của người dùng khác. Bạn cần kiểm tra hành vi từ chối để xác nhận rằng nó sẽ nói "không" khi chính sách ngăn chặn một hành động. Bạn cần các bài kiểm tra khả năng chống prompt-injection để xác minh rằng các đầu vào đối nghịch không thể vượt qua các lớp bảo vệ ở cấp độ mã nguồn.

Hãy đặt tên cho các bài kiểm tra một cách rõ ràng. Một bài kiểm tra có tên "refund_skill_rejects_negative_amount" sẽ cho kỹ sư tiếp theo biết chính xác hành vi nào đang được bảo vệ. Khi một bài kiểm tra thất bại trong quá trình đẩy phiên bản, bạn sẽ có bằng chứng xác thực rằng bản build ứng viên đó là không an toàn.

Mục tiêu thực sự là sự kiểm soát

Tái sử dụng thì tốt, nhưng sự kiểm soát mới là thứ giúp bạn giữ được việc làm. Một skill registry cho phép đội ngũ của bạn khẳng định một cách chắc chắn: đây là quy trình làm việc đã được phê duyệt. Đây là phiên bản đang chạy trên production. Đây là các công cụ mà nó có thể sử dụng. Và đây chính xác là cách chúng ta thực hiện rollback.

Sự rõ ràng đó giúp bạn chuyển từ việc tung ra các bản demo thông minh sang việc vận hành các phần mềm đáng tin cậy. Các bản demo gây ấn tượng với các bên liên quan trong mười phút. Phần mềm đáng tin cậy sẽ chạy vào lúc ba giờ sáng, xử lý các ngoại lệ một cách mượt mà và không thay đổi hành vi chỉ vì ai đó vừa merge một pull request vào chiều thứ Ba.

Hãy xây dựng registry của bạn. Hãy đánh số phiên bản cho các skill. Hãy thực thi các chính sách bằng mã nguồn. Hãy kiểm thử như thể lịch trình ngủ của bạn phụ thuộc vào nó. Bản thân bạn trong tương lai sẽ cảm ơn bạn.