Thiết kế quy trình AI agent đáng tin cậy

AI agent hữu ích nhất khi chịu trách nhiệm cho một kết quả có phạm vi rõ ràng, không phải khi được trao quyền vô hạn. Workflow đáng tin cậy phải chỉ ra mục tiêu, context, hành động được phép, bằng chứng và điểm phê duyệt của con người trước khi bắt đầu.

Nhìn nhanh toàn bộ quy trình

flowchart LR
    A[Yêu cầu công việc] --> B[Định nghĩa kết quả]
    B --> C[Thu thập context tối thiểu]
    C --> D[Lập kế hoạch giới hạn]
    D --> E[Thực hiện một bước]
    E --> F[Lưu bằng chứng]
    F --> G{Cần phê duyệt?}
    G -->|Có| H[Con người review]
    H -->|Cần sửa| D
    H -->|Duyệt| I[Ghi nhận kết quả]
    G -->|Không| J{Đã xong?}
    J -->|Chưa| E
    J -->|Rồi| I

Ý chính là mọi hành động đều dẫn tới bằng chứng quan sát được. Agent không thể tự kết luận công việc hoàn tất chỉ vì nó đã tạo ra một câu trả lời.

Điều kiện cần

• Một workflow lặp lại được, rủi ro thấp và có owner rõ ràng.
• Một system of record như issue tracker, repository hoặc hàng đợi phê duyệt.
• Cách xem thay đổi trước khi chúng ảnh hưởng tới khách hàng hay hệ thống ngoài.

Kết quả học tập

Sau bài này, bạn có thể:

• định nghĩa task của agent bằng kết quả và bằng chứng;
• tách công việc read-only khỏi hành động cần phê duyệt;
• thiết kế retry limit và stopping condition;
• thử nghiệm automation mà vẫn giữ được trách nhiệm giải trình.

Thiết kế contract trước khi viết prompt

Prompt mô tả yêu cầu tức thời. Workflow contract định nghĩa giới hạn vận hành cho nhiều yêu cầu khác nhau.

Trường	Câu hỏi cần trả lời	Ví dụ
Kết quả	Điều gì phải đúng khi kết thúc?	Có bản nháp release note đã review
Bằng chứng	Kiểm tra bằng cách nào?	Link change đã merge và check đã pass
Hành động	Agent được thay đổi gì?	File nháp trên một branch
Phê duyệt	Việc gì cần con người?	Publish hoặc liên hệ khách hàng
Retry limit	Khi nào automation phải dừng?	Dừng sau hai lần gọi API thất bại
Owner	Ai xử lý điểm chưa rõ?	Release manager

Nếu thiếu contract, “hoàn thành task” có thể mang ba nghĩa khác nhau với người dùng, agent và hệ thống nhận kết quả.

Chủ động giảm context

Nhiều context hơn chưa chắc tốt hơn. Chỉ cung cấp phần làm thay đổi quyết định: mục tiêu, file hoặc record liên quan, constraint và acceptance criteria. Loại bỏ lịch sử không liên quan và dữ liệu nhạy cảm.

Trước khi đính kèm thông tin, hãy hỏi:

1. Thông tin này có thay đổi việc agent nên làm không?
2. Đây có phải phiên bản authoritative không?
3. Agent có được phép nhìn thấy nó không?

Đặt approval tại ranh giới rủi ro

Discovery read-only và bản nháp có thể hoàn tác thường có thể chạy tự động. Cần review rõ ràng trước hành động khó đảo ngược, công khai, tài chính, phá huỷ hoặc đại diện cho danh tính của người dùng.

flowchart TD
    A[Hành động được đề xuất] --> B{Công khai hoặc khó hoàn tác?}
    B -->|Có| C[Yêu cầu con người phê duyệt]
    B -->|Không| D{Thay đổi shared state?}
    D -->|Có| E[Preview và lưu diff]
    D -->|Không| F[Cho phép thực thi có giới hạn]

Thực hành: thiết kế agent viết release note

Mục tiêu: tạo workflow an toàn để viết release note từ pull request đã merge.

1. Viết outcome: “Tạo một bản nháp Markdown cho release v1.4; không publish.”
2. Giới hạn input ở pull request đã merge và có release-note label.
3. Định nghĩa evidence: mỗi note có link pull request và tên feature bị ảnh hưởng.
4. Chỉ cho phép đọc pull request và ghi vào một draft branch.
5. Yêu cầu release manager duyệt trước khi publish.
6. Dừng và báo cáo khi pull request có label mâu thuẫn hoặc thiếu mô tả hữu ích.

Checkpoint: một người khác phải chỉ ra được agent được đọc gì, thay đổi gì, khi nào phải dừng và bằng chứng nào xác nhận thành công.

Các lỗi thường gặp

• Hoàn thành mơ hồ: thay “xử lý release” bằng artifact quan sát được.
• Retry im lặng: giới hạn số lần và trả lại lỗi cuối cùng kèm context.
• Approval mọi nơi: chỉ đặt review tại ranh giới rủi ro thực sự.
• Không có audit trail: lưu input, quyết định, diff và người duyệt trong system of record.
• Bắt đầu quá lớn: thử một workflow nội bộ có thể hoàn tác trước.

Definition of done

• Outcome và bằng chứng kiểm tra đã rõ ràng.
• Input và permission tuân theo least privilege.
• Approval point tương ứng với rủi ro hành động.
• Retry limit và stopping condition đã được ghi lại.
• Owner có thể kiểm tra và rollback kết quả.

Ghi chú nguồn

Bài viết được tổng hợp từ A Practical AI Agent Workflow For Companies In 2027 (Guide) [8rVQuZlRaqo].en.srt, được biểu diễn trong web-content bằng cặp bài English/Vietnamese cho đoạn 00:00:00–00:19:22. Bảng contract, mô hình ranh giới rủi ro và bài tập release note là phần biên tập bổ sung.