Danh mục công cụ AI Agent được phép dùng (tool registry) nên quản lý thế nào?

Một AI Agent làm được việc thật là nhờ công cụ: hàm tra đơn hàng, hàm tạo phiếu hỗ trợ, hàm gửi email, hàm đọc tồn kho. Ở dự án đầu tiên, danh sách công cụ thường nằm trong mã của chính agent và chỉ người viết biết rõ từng hàm làm gì. Sang dự án thứ ba, thứ tư, mỗi đội viết thêm vài công cụ, có hàm trùng chức năng nhưng khác quyền, có hàm đã hết dùng nhưng vẫn gọi được, và không ai trả lời nhanh được câu hỏi: hôm nay agent của chúng ta có thể làm những gì trên hệ thống nào.

Tool registry là danh mục chính thức của mọi công cụ mà agent được phép gọi, kèm thông tin để quản trị từng công cụ. Bài viết này đi qua các trường nên có trong registry, cách đặt registry làm cổng bắt buộc ở lớp thực thi, và quy trình thêm hay ngừng một công cụ. Việc ai được dùng agent và dữ liệu nào nằm trong phạm vi của từng vai trò đã có ở bài phân quyền AI Agent; việc hành động nào phải xin người duyệt có ở bài quy trình phê duyệt AI Agent. Registry là chỗ hai lớp đó được gắn vào từng công cụ cụ thể.

1. Registry là hợp đồng giữa mô hình, lớp thực thi và người quản trị

Mỗi công cụ trong một agent có ba nhóm người đọc khác nhau. Mô hình đọc tên, mô tả và schema tham số để quyết định khi nào gọi và truyền gì. Lớp thực thi, tức đoạn mã nhận yêu cầu gọi công cụ từ mô hình rồi thực sự chạy nó, cần biết công cụ có còn hiệu lực không, dùng khóa nào, có cần chờ người duyệt không, đã chạm giới hạn tần suất chưa. Người quản trị cần biết ai chịu trách nhiệm, công cụ chạm vào hệ thống nào, mức rủi ro ra sao và lần thay đổi gần nhất là khi nào. Nếu ba nhóm thông tin này nằm ở ba nơi, chúng sẽ lệch nhau rất nhanh.

Registry gom cả ba vào một bản khai cho mỗi công cụ. Điểm quan trọng là registry phải được lớp thực thi đọc và tuân theo, chứ không chỉ là tài liệu tham khảo. Một bảng tính đẹp nhưng agent vẫn gọi được công cụ không có trong bảng thì không kiểm soát được gì. Ngược lại, khi lớp thực thi từ chối mọi công cụ không có bản khai hợp lệ, registry trở thành nguồn sự thật duy nhất về khả năng của agent.

Registry mô tả mọi công cụ tồn tại trong doanh nghiệp, còn từng agent chỉ được gán một tập con; danh sách cho phép theo từng tình huống để chống chỉ dẫn độc hại là lớp hẹp hơn, xem bài prompt injection.

2. Các trường cần có trong một bản khai công cụ

1. Tên và mô tả viết cho mô hình

Tên công cụ nên là động từ cộng đối tượng, ngắn và không mơ hồ, chẳng hạn tra_trang_thai_don hay tao_phieu_ho_tro, thay vì xu_ly hay api_moi. Mô tả là thứ mô hình dựa vào để chọn công cụ, nên phải nói rõ công cụ dùng khi nào, không dùng khi nào và trả về gì. Một mô tả như “lấy thông tin đơn” khiến mô hình gọi công cụ cả khi khách hỏi chính sách đổi trả. Mô tả tốt hơn là “tra trạng thái giao hàng của một đơn đã tồn tại theo mã đơn; không dùng để tra chính sách hay tạo đơn”.

Mô tả cho mô hình cũng là bề mặt có thể bị lợi dụng. Không đặt hướng dẫn nghiệp vụ dài, không ghi tên máy chủ nội bộ hay thông tin nhạy cảm vào đây, vì mô hình có thể lặp lại nguyên văn cho người dùng. Mỗi lần sửa mô tả nên được coi là một thay đổi có phiên bản, vì chỉ đổi vài chữ cũng làm thay đổi cách agent chọn công cụ.

2. Schema tham số và quy tắc kiểm tra

Schema mô tả từng tham số: kiểu dữ liệu, bắt buộc hay không, giá trị cho phép, định dạng. Mã đơn có mẫu cố định thì khai rõ mẫu đó; số lượng phải là số nguyên dương thì khai giới hạn dưới và giới hạn trên. Lớp thực thi kiểm tra tham số theo schema trước khi chạy, và trả lỗi có cấu trúc cho mô hình nếu sai, thay vì để hệ thống đích tự xử lý một yêu cầu lạ.

Schema chặt chặn cả lỗi vô tình lẫn tham số bị chèn từ nội dung độc hại: công cụ gửi email chỉ nhận người nhận thuộc danh sách khách trong CRM thì không thể bị dẫn dụ gửi ra địa chỉ lạ.

3. Phân loại đọc, ghi và gửi ra ngoài

Mỗi công cụ được gắn một trong ba loại hành động. Đọc là chỉ lấy dữ liệu, không thay đổi gì. Ghi là tạo, sửa hoặc xóa bản ghi trong hệ thống nội bộ. Gửi ra ngoài là hành động mà hậu quả rời khỏi tầm kiểm soát của doanh nghiệp: email, tin nhắn cho khách, gọi webhook của đối tác, đăng nội dung. Ba loại này có mức kiểm soát khác nhau, và người quản trị thường muốn lọc registry theo loại để rà soát.

Một công cụ không nên vừa đọc vừa ghi. Hàm “tra và cập nhật địa chỉ giao hàng” nên tách thành hai, để agent tra cứu có thể được gán hàm đọc mà không vô tình có quyền sửa. Việc tách này cũng giúp nhật ký rõ hơn khi điều tra.

4. Mức rủi ro và yêu cầu người duyệt

Mức rủi ro được chấm theo hai trục: ảnh hưởng nếu công cụ chạy sai và khả năng hoàn tác. Tra lịch hẹn là rủi ro thấp. Đổi lịch hẹn của khách là rủi ro vừa, hoàn tác được. Hoàn tiền, hủy hợp đồng, gửi thông báo hàng loạt là rủi ro cao vì khó hoặc không thể quay lại. Từ mức rủi ro, registry ghi rõ công cụ có cần người duyệt trước khi chạy không, ai duyệt, và có hạn mức nào không, ví dụ chỉ tự chạy khi giá trị dưới ngưỡng do bộ phận tài chính đặt.

Trường này không thay cho quy trình phê duyệt mà là chỗ quy trình đó được tham chiếu. Lớp thực thi đọc cờ cần duyệt, tạo yêu cầu duyệt và chỉ chạy khi có quyết định. Nếu cờ này chỉ nằm trong tài liệu thiết kế, sớm muộn sẽ có một agent mới gọi công cụ mà bỏ qua bước duyệt.

5. Chủ sở hữu công cụ và hệ thống đích

Mỗi công cụ cần hai tên người: chủ sở hữu kỹ thuật, người chịu trách nhiệm mã và sửa lỗi; và chủ sở hữu hệ thống đích, thường là trưởng bộ phận đang dùng CRM, ERP hay phần mềm kho mà công cụ chạm vào. Khi hệ thống đích đổi API, đổi quy trình hoặc chuẩn bị nâng cấp, chủ sở hữu hệ thống đích là người báo trước. Khi công cụ lỗi lúc nửa đêm, chủ sở hữu kỹ thuật là người được gọi. Nên ghi tên nhóm có kênh liên lạc thật thay vì tên cá nhân; công cụ không còn chủ sở hữu nào đang làm việc thì đưa vào danh sách xem xét ngừng dùng.

6. Phạm vi thông tin xác thực

Registry không chứa khóa, mà ghi công cụ dùng loại thông tin xác thực nào và phạm vi của nó: tài khoản dịch vụ riêng cho công cụ, chỉ có quyền đọc bảng đơn hàng; hoặc dùng quyền của chính người dùng đang trò chuyện thông qua ủy quyền. Hai cách cho kết quả rất khác: tài khoản dịch vụ chung nhìn thấy mọi đơn, còn quyền của người dùng chỉ thấy những gì người đó được thấy.

Ghi rõ phạm vi giúp người rà soát phát hiện công cụ dùng khóa quá rộng, chẳng hạn công cụ chỉ cần đọc nhưng đang dùng khóa quản trị. Cách lưu, cấp phát và xoay vòng chính các khóa đó nằm ở bài quản lý secret cho AI Agent.

7. Giới hạn tần suất và hạn mức nghiệp vụ

Có hai loại giới hạn cần khai. Giới hạn kỹ thuật là số lượt gọi tối đa trong một khoảng thời gian, xuất phát từ hạn mức của API đích; cách điều tiết và xếp hàng khi chạm hạn mức có ở bài xử lý API rate limit. Giới hạn nghiệp vụ là số lần một công cụ được gọi trong một hội thoại hoặc cho một khách: ví dụ công cụ gửi mã giảm giá chỉ được gọi một lần mỗi khách mỗi chương trình, công cụ tạo phiếu hỗ trợ không được gọi quá vài lần trong cùng hội thoại.

Giới hạn nghiệp vụ là lưới an toàn cho tình huống agent rơi vào vòng lặp hoặc bị dẫn dụ gọi lặp lại. Không có nó, một lỗi suy luận nhỏ có thể tạo hàng chục phiếu trùng hoặc gửi cùng một tin nhắn nhiều lần cho khách.

8. Phiên bản, trạng thái và vòng đời

Mỗi bản khai có số phiên bản và trạng thái. Các trạng thái thường dùng là đề xuất, đang thử, được dùng, hạn chế, ngừng dùng. Đang thử nghĩa là chỉ gọi được trong môi trường thử hoặc với nhóm người dùng nội bộ. Hạn chế là trạng thái tạm thời khi công cụ có sự cố: chỉ đọc vẫn chạy, ghi bị chặn. Ngừng dùng thì lớp thực thi từ chối mọi lượt gọi nhưng bản ghi vẫn giữ để đọc lại nhật ký cũ.

Thay đổi schema theo cách không tương thích, như đổi tên tham số hay đổi ý nghĩa giá trị trả về, nên tạo phiên bản mới chạy song song một thời gian thay vì sửa đè. Các agent đang dùng bản cũ được chuyển dần, và bản cũ chỉ ngừng khi không còn agent nào tham chiếu.

Bảng dưới đây tóm tắt một bản khai mẫu cho công cụ đổi lịch hẹn, để thấy các trường đi cùng nhau thế nào.

3. Quy trình đưa registry vào vận hành

Bước 1: Kiểm kê công cụ các agent đang gọi thực tế

Đừng bắt đầu từ tài liệu thiết kế, vì tài liệu thường thiếu những hàm được thêm vội. Hãy đọc mã của từng agent và nhật ký gọi công cụ trong một khoảng thời gian gần đây để lập danh sách công cụ thực sự tồn tại và thực sự được gọi. Với mỗi công cụ, ghi lại agent nào dùng, gọi tới hệ thống nào, dùng khóa nào. Bước này thường phát hiện công cụ trùng chức năng, công cụ không ai nhận là của mình, và khóa dùng chung giữa nhiều công cụ.

Bước 2: Chuẩn hóa bản khai và chấm rủi ro

Với từng công cụ trong danh sách, điền đủ các trường: tên chuẩn, mô tả viết lại cho rõ, schema chặt, loại hành động, mức rủi ro, chủ sở hữu, phạm vi xác thực, giới hạn và trạng thái. Việc chấm rủi ro nên làm theo nhóm có chủ nghiệp vụ và người phụ trách an toàn thông tin cùng ngồi, vì đội kỹ thuật hay đánh giá thấp hậu quả nghiệp vụ, còn bộ phận nghiệp vụ hay không biết công cụ thực sự chạm tới bao nhiêu dữ liệu. Công cụ trùng thì gộp, công cụ không còn ai cần thì chuyển sang ngừng dùng.

Bước 3: Đặt registry làm cổng bắt buộc ở lớp thực thi

Sửa lớp thực thi để mọi lượt gọi công cụ đều đi qua bước tra registry: công cụ có tồn tại không, có ở trạng thái cho phép với môi trường hiện tại không, agent này có được gán công cụ này không, tham số có đúng schema không, có cần người duyệt không, đã chạm giới hạn chưa. Chỉ khi qua hết mới lấy khóa và chạy. Mọi lượt từ chối được ghi vào nhật ký kèm lý do, để đội vận hành phân biệt lỗi của mô hình với lỗi cấu hình. Các trường nên ghi cho mỗi lượt gọi có ở bài nhật ký AI Agent. Danh sách công cụ đưa cho mô hình ở mỗi phiên cũng nên sinh ra từ registry thay vì viết tay trong mã, để công cụ đã ngừng dùng biến mất khỏi cả hai phía.

Bước 4: Vận hành quy trình đề xuất, xét duyệt và ngừng công cụ

Thêm công cụ mới đi theo một luồng cố định: đội phát triển nộp bản khai ở trạng thái đề xuất; chủ sở hữu hệ thống đích đồng ý cho công cụ chạm vào hệ thống của mình; người phụ trách an toàn thông tin xem mức rủi ro và phạm vi khóa; công cụ chạy ở trạng thái đang thử với bộ ca thử; sau đó mới chuyển sang được dùng. Công cụ chỉ đọc, rủi ro thấp có thể đi luồng rút gọn, còn công cụ gửi ra ngoài phải đi đủ các bước.

Ngừng công cụ cũng cần luồng riêng: xác định agent nào còn tham chiếu, thông báo cho đội phụ trách, chuyển sang hạn chế một thời gian để bắt các lượt gọi sót, rồi mới chuyển sang ngừng dùng. Mỗi quý, người giữ registry rà danh sách công cụ không được gọi trong thời gian dài và hỏi chủ sở hữu có còn cần không.

4. Ví dụ giả định

Một chuỗi phòng khám nha khoa có ba agent: agent đặt lịch trên website, agent trả lời tin nhắn mạng xã hội và agent nội bộ cho lễ tân. Khi kiểm kê, đội vận hành thấy có hai hàm tạo lịch hẹn do hai đội viết, một hàm dùng tài khoản quản trị của phần mềm phòng khám, hàm kia dùng tài khoản chỉ được tạo lịch. Ngoài ra còn một hàm gửi tin nhắn nhắc lịch được viết cho đợt khuyến mãi cũ, không ai nhận là chủ nhưng vẫn gọi được từ agent mạng xã hội.

Chuỗi phòng khám gộp hai hàm tạo lịch thành một, dùng tài khoản hẹp, gắn giới hạn mỗi khách chỉ được giữ một số lịch chờ nhất định. Hàm nhắc lịch cũ chuyển sang ngừng dùng. Công cụ đổi lịch được gắn yêu cầu khách xác nhận lại giờ mới trong hội thoại trước khi chạy. Lớp thực thi được sửa để đọc registry, nên khi phòng khám tạm ngừng nhận lịch online ở một chi nhánh, quản trị viên chỉ cần chuyển công cụ tạo lịch của chi nhánh đó sang hạn chế thay vì sửa mã ba agent. Ví dụ này là giả định để minh họa cách áp dụng registry.

5. Rủi ro và giới hạn

• Registry chỉ là tài liệu, lớp thực thi không đọc, nên công cụ ngoài danh sách vẫn chạy được
• Mô tả công cụ bị sửa tùy tiện, làm agent đổi cách chọn công cụ mà không ai kiểm thử lại
• Khóa dùng chung giữa nhiều công cụ khiến phạm vi xác thực ghi trong registry không phản ánh quyền thật
• Quy trình xét duyệt quá nặng, các đội lách bằng cách nhét nhiều chức năng vào một công cụ đã được duyệt

Registry không làm công cụ an toàn hơn nếu bản thân công cụ được viết sai. Một hàm có lỗi kiểm tra quyền bên trong vẫn sẽ lộ dữ liệu dù bản khai đầy đủ. Registry giúp biết công cụ nào tồn tại, ai chịu trách nhiệm và kiểm soát nào được áp, còn chất lượng từng công cụ vẫn cần kiểm thử và rà mã như mọi phần mềm khác.

6. Phân chia trách nhiệm vận hành

Người giữ registry, thường thuộc đội nền tảng AI hoặc đội vận hành agent, sở hữu cấu trúc bản khai, quy trình thêm và ngừng công cụ, và buổi rà soát định kỳ. Đội phát triển sở hữu mã, schema và mô tả của công cụ mình viết, chịu trách nhiệm kiểm thử khi thay đổi. Chủ sở hữu hệ thống đích quyết định công cụ nào được chạm vào hệ thống của họ, với phạm vi nào và giới hạn nghiệp vụ nào. Người phụ trách an toàn thông tin duyệt mức rủi ro, phạm vi khóa và có quyền chuyển bất kỳ công cụ nào sang hạn chế khi có dấu hiệu sự cố.

Quyền chuyển trạng thái nên được phân rõ: ai được đưa công cụ từ đề xuất sang đang thử, ai được đưa sang được dùng, ai được hạ xuống hạn chế trong tình huống khẩn. Hạ cấp nên dễ, nâng cấp nên có kiểm soát.

7. Chỉ số nên theo dõi

• Số công cụ theo trạng thái và theo loại hành động, cùng số công cụ chưa có chủ sở hữu còn làm việc
• Số lượt gọi bị lớp thực thi từ chối, tách theo lý do: không có trong registry, sai schema, chưa được gán, chạm giới hạn
• Số công cụ dùng khóa có phạm vi rộng hơn mức khai báo, phát hiện qua rà soát
• Thời gian từ lúc đề xuất đến lúc công cụ được dùng, tách theo mức rủi ro

Lượt gọi bị từ chối vì sai schema tăng lên sau một lần đổi mô tả thường là dấu hiệu mô hình đang hiểu sai công cụ. Thời gian xét duyệt quá dài với công cụ rủi ro thấp là dấu hiệu quy trình đang đẩy các đội đi đường vòng.

8. Checklist trước khi vận hành

• Mọi công cụ đang được gọi đều có bản khai với chủ sở hữu, loại hành động và mức rủi ro
• Lớp thực thi từ chối công cụ không có trong registry hoặc không ở trạng thái cho phép
• Danh sách công cụ đưa cho mô hình được sinh từ registry theo từng agent
• Công cụ ghi và gửi ra ngoài có schema chặt, giới hạn nghiệp vụ và cờ cần duyệt khi cần
• Mỗi công cụ dùng thông tin xác thực riêng với phạm vi đúng như khai báo
• Quy trình thêm, hạ cấp và ngừng công cụ đã viết rõ người có quyền ở từng bước

9. Câu hỏi thường gặp

Tool registry khác gì danh sách công cụ khai báo trong mã của agent? Danh sách trong mã chỉ cho mô hình biết có những công cụ nào. Registry là nguồn quản trị: mỗi công cụ có chủ sở hữu, mức rủi ro, phạm vi khóa, giới hạn tần suất, trạng thái và lịch sử phiên bản. Lớp thực thi đọc registry để quyết định có cho gọi hay không, nên công cụ không có trong registry thì không chạy được dù mã có khai báo.

Doanh nghiệp chỉ có một hai agent có cần tool registry không? Không cần một hệ thống riêng. Một bảng có đủ các trường chính, được một người giữ và rà lại khi thêm công cụ, đã đủ cho giai đoạn đầu. Khi số agent và số đội cùng viết công cụ tăng lên, bảng đó nên chuyển thành cấu hình mà lớp thực thi đọc trực tiếp.

Ai được quyền thêm một công cụ mới vào registry? Đội phát triển đề xuất, nhưng việc đưa sang trạng thái được dùng cần chủ sở hữu hệ thống đích đồng ý và người phụ trách an toàn thông tin xem mức rủi ro. Với công cụ ghi dữ liệu hoặc gửi ra ngoài, nên có thêm một vòng thử trong môi trường thử trước khi bật cho người dùng thật.

Ngừng một công cụ thì có cần xóa khỏi registry không? Không nên xóa. Công cụ chuyển sang trạng thái ngừng dùng, lớp thực thi từ chối mọi lượt gọi, nhưng bản ghi vẫn giữ để đọc lại nhật ký cũ và điều tra sự cố. Xóa hẳn khiến những lượt gọi trong quá khứ không còn được giải thích.

Kết luận

Tool registry biến câu hỏi “agent của chúng ta làm được gì” từ chuyện phải đọc mã thành một danh mục có chủ, có mức rủi ro, có phạm vi khóa và có vòng đời. Giá trị của nó chỉ thành hiện thực khi lớp thực thi coi registry là cổng bắt buộc: không có bản khai hợp lệ thì không chạy. Bắt đầu bằng kiểm kê những gì đang thực sự được gọi, chuẩn hóa bản khai, rồi giữ một quy trình thêm và ngừng công cụ đủ nhẹ để các đội không phải đi đường vòng.

Trao đổi với Naventic để kiểm kê và dựng tool registry cho các AI Agent đang vận hành. Đọc thêm: AI Workflow Automation.