Vận hành AI Agent: tiêu chí dừng thêm tính năng mới

TL;DR: Khi vận hành AI Agent, một tính năng mới cần được đánh giá bằng trách nhiệm và công bảo trì mà nó tạo ra. Dừng mở rộng là quyết định có cơ sở khi nền tảng hiện tại chưa thể kiểm chứng hoặc bàn giao.

Tôi không muốn đo tiến độ xây hệ thống chỉ bằng số khả năng mới được thêm vào. Nếu một tính năng khiến người vận hành phải ghi nhớ thêm ngoại lệ, theo dõi thêm kênh và sửa thêm đầu ra, nó đã tạo một khoản nợ trước khi chứng minh giá trị. Câu chuyện dọn dữ liệu trước khi xây AI Agent đặt nền cho cách nghĩ này: cấu trúc gọn và hiểu được quan trọng hơn vẻ ngoài đầy đủ. Bài viết này là tiêu chí tôi đề xuất cho quyết định mở rộng, không phải báo cáo về một đợt đóng băng tính năng đã diễn ra.

Khi nào một tính năng mới làm hệ thống kém hữu ích?

Tính năng làm hệ thống kém hữu ích khi công kiểm soát mới lớn hơn lợi ích đã xác nhận, hoặc khi nó làm suy yếu một ranh giới đang rõ. Khả năng kỹ thuật thực hiện được chưa đủ để đưa vào vận hành.

Tôi nhìn mỗi đề xuất như một cam kết dài hạn. Sau khi nối thêm một nguồn dữ liệu, ai nhận thông báo khi nguồn thay đổi? Sau khi cho Agent gọi thêm một công cụ, ai quyết định hành động đó có đúng phạm vi? Nếu câu trả lời vẫn là “Founder sẽ tự biết”, hệ thống chưa giải phóng được người xây.

Một dấu hiệu đáng chú ý là ngoại lệ được giải quyết bằng trí nhớ. Người vận hành biết một tác vụ phải chạy lại vào ngày nào, biết một kết quả cần sửa bằng tay và biết một cảnh báo thường không quan trọng. Những điều ấy chưa nằm trong runbook nên người khác không thể tiếp nhận.

Trong tình trạng này, thêm khả năng mới dễ làm tăng khoảng cách giữa sơ đồ đẹp và công việc thật. Tôi sẽ ưu tiên làm rõ khoảng cách đó trước.

Cần bằng chứng gì để quyết định giữ hoặc hoãn?

Cần biết vấn đề nào đang xảy ra, ai gặp vấn đề, tác động ra sao và tính năng đề xuất sẽ được nghiệm thu bằng cách nào. Nếu chưa có những bằng chứng này, hoãn là một lựa chọn hợp lý.

Một lỗi trong báo cáo nội dung có thể minh họa ý nghĩa của việc kiểm tra nền. Đợt đối chiếu kho ngày 27/09 ghi nhận báo cáo nói có bốn bài dự trữ, nhưng file có ngày tương lai chỉ có hai bài VI. Đây là chênh lệch trong checkout được kiểm tra, không phải kết luận về mọi nơi lưu bản thảo.

Từ tình huống đó, tôi sẽ ưu tiên sửa cách phân biệt ý tưởng với bài hoàn tất trước khi thêm khả năng tự tạo thêm chủ đề. Sinh nhiều hơn không xử lý được một báo cáo đang đếm sai trạng thái.

Đổi thời gian xây mới lấy việc gì?

Đổi thời gian xây mới lấy việc làm rõ tiêu chuẩn đạt, trách nhiệm xử lý lỗi và cách phục hồi. Kết quả cần là hệ thống dễ nghiệm thu hơn, không chỉ thêm tài liệu.

Tôi đề xuất bắt đầu từ một workflow có người sử dụng thật. Theo dõi một tác vụ đi từ đầu vào đến lúc được chấp nhận. Mọi bước con người phải nhớ, sửa hoặc xác nhận đều cần được ghi lại với lý do tồn tại.

Sau đó, phân loại phần việc:

• Quy tắc ổn định có thể chuyển thành kiểm tra rõ ràng.
• Quyết định phụ thuộc bối cảnh cần giữ người chịu trách nhiệm.
• Ngoại lệ hiếm cần có cách đưa về hàng đợi, không ép tự động hóa.
• Khả năng không có người dùng hoặc kết quả nghiệm thu cần xem lại.

Một nhật ký quyết định ngắn giúp việc hoãn không trở thành trì hoãn vô thời hạn:

Đề xuất → vấn đề được quan sát → bằng chứng còn thiếu
→ quyết định giữ/hoãn/bỏ → người chịu trách nhiệm
→ điều kiện xem lại

Tôi không dùng số tính năng bị bỏ làm thành tích. Giá trị của việc dừng là tạo thời gian cho những bước giúp một người khác hiểu và vận hành hệ thống.

Khi nào có thể mở rộng trở lại?

Có thể mở rộng khi phần hiện tại có tiêu chí nghiệm thu, đường phục hồi và người tiếp nhận rõ, đồng thời đề xuất mới giải một vấn đề đã được ghi nhận. Điều kiện nên được xác định trước khi viết phần mới.

Tôi sẽ yêu cầu người đề xuất giải thích một tác vụ cụ thể được cải thiện ra sao. “Hệ thống chuyên nghiệp hơn” là mô tả cảm giác; “người duyệt tìm được các tác vụ chưa hoàn tất” là hành vi có thể kiểm tra.

Phạm vi thử nghiệm cũng cần nhỏ đủ để đảo ngược. Chạy ở một nhóm tác vụ, theo dõi lỗi và giữ khả năng quay lại. Không cần trao thêm quyền ra bên ngoài chỉ để chứng minh model có thể làm nhiều hơn.

Điều kiện mở lại không nhất thiết là mọi lỗi biến mất. Nó là việc những lỗi còn lại đã được hiểu, có người nhận và có cách xử lý. Sự chắc chắn tuyệt đối khó đạt; trách nhiệm rõ ràng thì có thể thiết kế.

Kết luận

Tôi muốn một hệ thống AI có thể được giải thích trước khi nó được mở rộng. Việc dừng thêm tính năng giúp bảo vệ thời gian và khả năng chịu trách nhiệm của Founder, nếu quyết định dừng đi kèm bằng chứng và điều kiện xem lại.

Khi xác định phần nào cần giữ sự tham gia của con người, bạn có thể dùng khung giám sát vận hành AI Workflow. Nếu tuần này không thêm tính năng nào, nền tảng nào sẽ trở nên đáng tin hơn?