Human-in-the-loop trong AI Agent: con người kiểm soát ở những điểm nào?

Human-in-the-loop trong AI Agent là cách thiết kế workflow để con người vẫn giữ quyền kiểm tra hoặc quyết định tại những điểm quan trọng thay vì để agent tự chạy toàn bộ. Các checkpoint thường cần xem xét gồm dữ liệu đầu vào, quyền truy cập, chất lượng kết quả, quyết định chạy lại và hành động bàn giao ra bên ngoài.

Trong OpenAI Agents SDK, human-in-the-loop có thể được triển khai bằng cách tạm dừng quá trình chạy trước một tool call nhạy cảm, đưa yêu cầu đó cho con người approve hoặc reject rồi mới tiếp tục. Trạng thái đang dừng có thể được lưu và resume sau khi có quyết định.

Tư duy này cũng xuất hiện rõ trong PD P2.1 Brain Engineer – Non-IT Track của FUNiX: assistant có thể hỗ trợ xử lý công việc, nhưng con người vẫn kiểm tra chất lượng, privacy, bảo mật, chi phí và phê duyệt cuối cùng. Workflow lặp lại còn cần input, procedure/skill, output, evidence và human approval rõ ràng.

Điểm quan trọng là human-in-the-loop không có nghĩa con người phải duyệt mọi bước. Nếu mọi hành động nhỏ đều dừng để xin phép, workflow mất phần lớn giá trị tự động hóa.

Thiết kế tốt hơn là xác định:

việc nào agent được tự làm → việc nào cần kiểm tra tự động → việc nào bắt buộc phải dừng để con người quyết định.

Human-in-the-loop là gì?

Có thể hiểu human-in-the-loop, thường viết tắt là HITL, là mô hình trong đó con người được đưa vào vòng xử lý của hệ thống AI tại những điểm đã định trước.

Với AI Agent, điều này đặc biệt quan trọng vì agent không chỉ tạo văn bản. Agent có thể được cấp tool để:

• Đọc file.
• Tra cứu dữ liệu.
• Gọi API.
• Chỉnh sửa nội dung.
• Chạy lệnh.
• Gửi thông tin.
• Thực hiện thay đổi trên hệ thống.

OpenAI hiện mô tả agent là ứng dụng có khả năng lập kế hoạch, gọi tool, phối hợp qua các specialist và giữ state để hoàn thành công việc nhiều bước. Tài liệu cũng tách riêng guardrails and human review cho những workflow cần chặn hoặc tạm dừng trước khi công việc rủi ro tiếp tục.

Vì vậy, khi agent có khả năng hành động thay mặt con người, câu hỏi an toàn không chỉ là:

AI trả lời có đúng không?

Mà còn là:

AI được phép truy cập gì, làm gì và hành động nào cần một người chịu trách nhiệm xác nhận?

Human approval khác guardrail như thế nào?

Hai khái niệm thường được dùng cùng nhau nhưng không giống nhau.

Guardrail là kiểm tra theo quy tắc

Guardrail có thể kiểm tra:

• Input có hợp lệ không.
• Output có vi phạm yêu cầu không.
• Tool call có dữ liệu bất thường không.
• Nội dung có vượt phạm vi agent không.

OpenAI Agents SDK hiện hỗ trợ input guardrails, output guardrails và tool guardrails. Input guardrail có thể chạy trước agent; output guardrail kiểm tra kết quả cuối; tool guardrail có thể kiểm tra trước hoặc sau từng custom tool call. 

Ví dụ:

Nếu file đầu vào chứa loại dữ liệu không được phép xử lý → block.

Đây có thể là kiểm tra tự động.

Human approval là quyết định của con người

Ví dụ:

Agent đã soạn email gửi 2.000 khách hàng. Có được gửi không?

Đây không chỉ là câu hỏi format hay validation.

Nó là quyết định có hậu quả thực tế.

Trong HITL của OpenAI Agents SDK, tool có thể được đánh dấu là cần approval; khi agent gọi tool đó, run dừng và chờ quyết định approve hoặc reject. 

Có thể hình dung đơn giản:

Guardrail: “Hành động này có vượt quy tắc không?”

Human approval: “Ngay cả khi hợp lệ, chúng ta có muốn cho phép hành động này xảy ra không?”

Một hệ thống tốt có thể dùng cả hai.

Vì sao AI Agent cần human-in-the-loop?

PD P2.1 Brain Engineer đặt “con người luôn giữ quyền kiểm soát” như một mindset cốt lõi. Chương trình yêu cầu workflow có bước kiểm tra chất lượng, privacy, bảo mật, chi phí và phê duyệt cuối cùng của con người.

Có bốn lý do thực tế.

Agent có thể đúng về kỹ thuật nhưng sai về nghiệp vụ

Ví dụ, agent được yêu cầu:

Gửi báo cáo tháng cho quản lý.

Nó có thể:

• Tạo đúng file.
• Đính kèm đúng file.
• Gọi đúng API email.

Nhưng danh sách người nhận lại bao gồm một địa chỉ không nên nhận dữ liệu đó.

Tool call “hoạt động” không có nghĩa quyết định nghiệp vụ là đúng.

Agent có thể xử lý dữ liệu mà nó không nên thấy

Một assistant làm research có thể chỉ cần đọc nguồn công khai.

Nếu được cấp quyền vào toàn bộ ổ đĩa hoặc CRM, phạm vi truy cập đã lớn hơn nhu cầu.

OpenAI mô tả việc triển khai agent an toàn theo nguyên tắc đặt agent trong các technical boundaries, kiểm soát những gì agent có thể truy cập và yêu cầu review với hành động rủi ro hơn.

Output tốt vẫn có thể cần người chịu trách nhiệm cuối

Ví dụ:

• Báo cáo nhân sự.
• Nội dung công khai.
• Email gửi khách hàng.
• Quyết định thay đổi dữ liệu.
• Recommendation có ảnh hưởng đến người khác.

Agent có thể chuẩn bị.

Con người vẫn cần quyết định liệu kết quả đó có được sử dụng hay không.

Khi agent lỗi, cần biết có nên chạy lại

Không phải lỗi nào cũng nên tự động retry.

Nếu timeout khi đọc một website, retry có thể hợp lý.

Nếu agent chuẩn bị xóa nhầm dữ liệu, “retry” lại chính hành động đó sẽ không giải quyết vấn đề.

Vì vậy, human control không chỉ nằm ở đầu hoặc cuối workflow. Nó còn xuất hiện tại nhánh xử lý lỗi và phục hồi.

5 cổng kiểm soát human-in-the-loop trong AI Agent

Khung dưới đây map tư duy của PD P2.1 về dữ liệu, chất lượng, quyền truy cập, xử lý lỗi và human approval thành năm checkpoint thực hành.

Cổng 1: Duyệt dữ liệu — agent được phép xử lý thông tin nào?

Human-in-the-loop nên bắt đầu trước khi agent xử lý dữ liệu, không chỉ ở cuối workflow.

Hãy hỏi:

• File này có chứa dữ liệu nhạy cảm không?
• Agent có thực sự cần toàn bộ file không?
• Có thể dùng bản đã loại thông tin nhạy cảm không?
• Nguồn dữ liệu này được phép đưa vào workflow không?
• Agent có cần lưu dữ liệu sau khi xử lý không?

Trong PD P2.1, privacy, bảo mật và quyền truy cập là một phần của kiểm soát an toàn, đồng thời học viên phải chịu trách nhiệm với dữ liệu và kết quả bàn giao.

Ví dụ: Assistant tóm tắt biên bản họp

Một người dùng đưa cho assistant file:

hop-nhan-su-quy-3.docx

File gồm:

• Agenda.
• Kế hoạch tuyển dụng.
• Mức lương của từng nhân viên.
• Thông tin đánh giá hiệu suất cá nhân.

Nếu mục tiêu chỉ là:

Tóm tắt các đầu việc sau cuộc họp.

agent có thể không cần toàn bộ dữ liệu chi tiết về lương.

Một checkpoint hợp lý là:

File chứa dữ liệu nhân sự nhạy cảm. Bạn muốn tiếp tục với file đầy đủ hay dùng bản đã loại các trường thông tin cá nhân?

Human approval ở đây xảy ra trước processing.

Khi nào có thể tự động?

Nếu workflow chỉ xử lý:

• Tài liệu công khai.
• File đã được phân loại là không nhạy cảm.
• Dữ liệu từ một nguồn đã được policy cho phép.

thì không nhất thiết phải hỏi người dùng mỗi lần.

Human-in-the-loop hiệu quả hơn khi approval được đặt theo mức rủi ro, thay vì mọi input đều cần duyệt.

Cổng 2: Duyệt quyền truy cập và hành động — agent được phép làm đến đâu?

Đây là checkpoint dễ thấy nhất của agentic AI.

Một agent có thể có tool như:

• read_calendar
• create_event
• delete_event
• draft_email
• send_email
• read_crm
• update_crm

Các tool không có mức rủi ro như nhau.

Read và write nên được phân biệt

Ví dụ:

Rủi ro thấp hơn

Đọc lịch ngày mai.

Rủi ro cao hơn

Xóa một cuộc họp khỏi lịch của cả nhóm.

Không nên mặc định vì agent có quyền đọc lịch thì nó cũng cần quyền sửa lịch.

Trong bài viết về vận hành Codex an toàn, OpenAI mô tả sandbox như ranh giới xác định agent có thể ghi ở đâu, có được truy cập mạng hay không và những đường dẫn nào được bảo vệ; approval policy xác định khi nào agent phải hỏi trước một hành động vượt ranh giới. 

Ví dụ: Email Assistant

Agent có thể tự động:

1. Đọc email cần trả lời.
2. Tìm reference liên quan.
3. Tạo draft.
4. Kiểm tra format.

Nhưng tool:

send_email

được đặt:

needs approval = true

Khi agent muốn gửi, workflow tạm dừng.

Người dùng thấy:

• Người nhận.
• Tiêu đề.
• Nội dung.
• File đính kèm.

Sau đó chọn:

Approve

hoặc

Reject.

OpenAI Agents SDK hỗ trợ chính mô hình pause → approve/reject → resume này với những tool được đánh dấu cần approval.

Không nên chỉ dựa vào instruction

Một prompt:

Không gửi email nếu chưa hỏi tôi.

là hữu ích.

Nhưng nếu hậu quả của thao tác đủ lớn, tốt hơn nên kiểm soát ở execution layer, tức tool thực sự không chạy trước approval.

Nguyên tắc này giúp giảm phụ thuộc vào việc model có tuân thủ đúng instruction trong từng lượt hay không.

Cổng 3: Duyệt kết quả — output có đủ tốt để sử dụng không?

Human approval không chỉ dành cho tool call.

Một agent có thể không thực hiện hành động bên ngoài nhưng vẫn tạo output sẽ được dùng để ra quyết định.

Ví dụ:

• Báo cáo đối thủ.
• Tóm tắt tài liệu pháp lý.
• Nội dung tuyển dụng.
• Báo cáo bán hàng.
• Brief cho cuộc họp lãnh đạo.

Trong P2.1, workflow phải có evidence và Quality & Safety Checklist; học viên cũng phải phản biện với kết quả AI tạo ra.

Vì vậy, trước khi output được chấp nhận, con người có thể review theo tiêu chí.

Correctness

• Số liệu có khớp input?
• Nguồn có hỗ trợ kết luận?
• Có hallucination không?

Completeness

• Có thiếu phần bắt buộc không?
• Đã xử lý đủ dữ liệu chưa?

Relevance

• Kết quả có đúng yêu cầu ban đầu không?
• Có lan sang nội dung ngoài scope không?

Safety

• Có dữ liệu không nên xuất hiện trong output không?
• Có thông tin cần ẩn trước khi chia sẻ không?

Ví dụ: Research Agent

Agent kết luận:

Đối thủ A đang chuyển chiến lược sang phân khúc doanh nghiệp.

Reviewer cần hỏi:

Evidence nào hỗ trợ cho kết luận “chuyển chiến lược”?

Nếu agent chỉ có một bài đăng sản phẩm, có thể sửa thành:

Đối thủ A vừa công bố một tính năng hướng tới khách hàng doanh nghiệp.

Human review biến một kết luận quá mức thành một phát hiện bám evidence hơn.

Human review không thay thế output guardrail

OpenAI Agents SDK cho phép output guardrail kiểm tra output cuối sau khi agent hoàn thành. 

Do đó có thể thiết kế hai tầng:

Tầng tự động: kiểm tra format, trường bắt buộc, dữ liệu cấm.

Tầng con người: đánh giá tính hợp lý, bối cảnh và quyết định sử dụng.

Cổng 4: Duyệt chạy lại — khi agent lỗi, ai quyết định retry?

Một workflow agent thực tế sẽ gặp lỗi.

Ví dụ:

• Website không truy cập được.
• API timeout.
• File sai định dạng.
• Không tìm thấy nguồn.
• Hai nguồn mâu thuẫn.
• Output fail quality check.
• Agent vượt quá phạm vi.

Sai lầm là áp dụng cùng một quy tắc:

Nếu lỗi thì chạy lại.

Lỗi kỹ thuật có thể retry tự động

Ví dụ:

API timeout một lần.

Workflow có thể:

1. Chờ 10 giây.
2. Retry.
3. Nếu vẫn lỗi → báo người dùng.

Lỗi nghiệp vụ cần quyết định

Ví dụ:

Không tìm được evidence cho một nhận định.

Retry cùng prompt ba lần không đảm bảo sẽ tạo ra evidence thật.

Workflow nên dừng:

Không có đủ nguồn để xác minh. Bạn muốn:

• bỏ mục này;
• mở rộng phạm vi nguồn;
• đổi khoảng thời gian?

Lỗi liên quan quyền hạn phải fail closed

Nếu tool cần approval nhưng thông tin của tool call không thể được kiểm tra an toàn, OpenAI Agents SDK hiện có hành vi yêu cầu manual approval thay vì tự động thực hiện trong một số trường hợp tham số không thể kiểm tra an toàn. 

Đây là nguyên tắc hữu ích:

không chắc về quyền → dừng, không tự mở rộng quyền.

Quyết định chạy lại nên ghi rõ trong workflow

Một workflow có thể quy định:

Retry tự động: tối đa 2 lần cho lỗi mạng.

Dừng và hỏi: khi input thiếu.

Escalate: khi dữ liệu mâu thuẫn.

Không retry: khi người dùng đã reject hành động.

Như vậy, human-in-the-loop không chỉ là nút Approve ở cuối mà còn là quyền quyết định đường đi tiếp theo khi workflow không còn ở trạng thái bình thường.

Cổng 5: Duyệt bàn giao — kết quả có được đi ra bên ngoài không?

Đây thường là checkpoint quan trọng nhất.

“Bàn giao” có thể là:

• Gửi email.
• Publish bài viết.
• Gửi báo cáo.
• Tạo ticket.
• Cập nhật CRM.
• Đẩy dữ liệu sang hệ thống khác.
• Chia sẻ file.
• Tạo thay đổi có tác động lâu dài.

Một output có thể hoàn hảo nhưng người dùng vẫn chưa muốn gửi nó ngay.

Ví dụ: Agent chuẩn bị báo cáo tuần

Agent thực hiện:

Đọc dữ liệu

↓

Phân tích

↓

Viết báo cáo

↓

Quality check

↓

Human approval

↓

Gửi cho lãnh đạo

Phê duyệt nằm trước hành động bàn giao, không nhất thiết phải xen vào mọi bước phân tích.

P2.1 mô tả Human Approval như việc con người kiểm soát dữ liệu, phê duyệt kết quả và quyết định chạy lại/cải tiến; đồng thời output cuối vẫn nằm dưới sự kiểm soát của chính học viên.

Vì sao bàn giao cần được tách khỏi tạo output?

Nếu agent có tool:

generate_report_and_send

thì việc tạo và gửi bị gộp thành một hành động.

Khó kiểm soát hơn mô hình:

generate_report

↓

review

↓

send_report

Tách prepare và execute tạo ra một approval boundary rõ ràng.

Ví dụ đầy đủ: Human-in-the-loop cho Research Assistant

Giả sử Marketing Manager có một agent chạy research đối thủ mỗi tuần.

Bước 1: Nhận input

Input:

• Danh sách 5 đối thủ.
• Khoảng thời gian 7 ngày.
• Chủ đề: sản phẩm và pricing.

Cổng dữ liệu

Kiểm tra:

• Có dữ liệu nội bộ không?
• File reference nào agent được đọc?

Nếu dữ liệu phù hợp → tiếp tục.

Bước 2: Research

Agent tự:

• Tìm nguồn công khai.
• Đọc trang sản phẩm.
• Tìm thông báo.
• Lưu evidence.

Không cần human approval cho từng website nếu toàn bộ nguồn đã nằm trong policy được phép.

Bước 3: Tạo report

Agent tạo:

• Summary.
• Bảng thay đổi.
• Evidence.
• Các điểm chưa xác minh.

Bước 4: Quality check

Guardrail hoặc một bước review tự động kiểm tra:

• Có nguồn không?
• Có phần bắt buộc không?
• Có dữ liệu ngoài scope không?

Nếu fail → agent sửa một lần.

Bước 5: Human review

Marketing Manager kiểm tra:

• Kết luận có hợp lý không?
• Evidence có đủ không?
• Có điểm nào cần viết lại không?

Cổng kết quả.

Bước 6: Agent đề xuất gửi

Agent chuẩn bị:

• Recipient.
• Subject.
• Attachment.

Workflow dừng.

Cổng bàn giao.

Marketing Manager chọn:

• Approve.
• Edit.
• Reject.

Chỉ sau đó email mới được gửi.

Đây là human-in-the-loop có chọn lọc: con người xuất hiện ở điểm có giá trị quyết định cao, không phải click approve sau mỗi lần agent đọc một trang web.

Approval nên đặt ở đâu theo mức rủi ro?

Không phải mọi tool đều cần hỏi.

Một khung đơn giản:

OpenAI mô tả nguyên tắc vận hành agent an toàn tương tự ở mức hệ thống: để các hành động rủi ro thấp diễn ra thuận tiện trong môi trường có ranh giới, còn hành động rủi ro cao hơn phải dừng để review.

Điều này giúp tránh hai cực đoan:

Quá ít kiểm soát: agent có quyền quá rộng.

Quá nhiều kiểm soát: workflow liên tục dừng và không còn giá trị tự động hóa.

Human-in-the-loop có phải lúc nào cũng là một nút Approve?

Không.

Human control có thể xuất hiện ở nhiều hình thức.

Approve / Reject

Ví dụ:

Có gửi email này không?

Edit trước khi tiếp tục

Ví dụ:

Sửa danh sách người nhận rồi gửi.

Chọn giữa các phương án

Ví dụ:

Không tìm thấy dữ liệu. Bạn muốn mở rộng thời gian hay bỏ phần này?

Cung cấp input còn thiếu

Ví dụ:

Chưa có danh sách đối thủ.

Escalation

Ví dụ:

Workflow không thể xác định quyền truy cập phù hợp. Chuyển cho quản trị viên.

Quyết định chạy lại

Ví dụ:

Report fail quality check lần thứ hai. Chạy lại hay dừng?

Vì thế, “human approval” nên được hiểu rộng hơn một checkbox. Nó là quyền kiểm soát hướng đi của workflow.

Human-in-the-loop khác human-on-the-loop như thế nào?

Hai cách gọi đôi khi được dùng để mô tả mức tham gia khác nhau của con người.

Trong phạm vi bài này:

Human-in-the-loop được dùng cho trường hợp workflow có checkpoint nơi hệ thống dừng hoặc yêu cầu con người đưa quyết định trước khi tiếp tục.

Một mô hình giám sát nhẹ hơn có thể cho agent tự thực hiện trong ranh giới nhưng để con người quan sát, audit và can thiệp khi cần.

OpenAI Agents SDK có tracing tích hợp để ghi nhận các sự kiện trong một run như model generations, tool calls, handoffs và guardrails, giúp workflow có thể được debug và monitor. 

Điều đó cho thấy kiểm soát agent không chỉ là approval.

Một hệ thống trưởng thành thường kết hợp:

boundary + guardrail + approval + monitoring + audit.

Vì sao logging và tracing vẫn cần nếu đã có human approval?

Người duyệt cần context để đưa quyết định.

Nếu màn hình chỉ hỏi:

Approve this action?

thì approval có rất ít giá trị.

Một approval hữu ích nên hiển thị:

• Agent đang định làm gì?
• Tool nào?
• Input nào?
• Dữ liệu nào bị ảnh hưởng?
• Kết quả dự kiến là gì?
• Tại sao hành động này xuất hiện?

OpenAI nhấn mạnh telemetry và audit trail là phần quan trọng khi triển khai coding agents, vì tổ chức cần biết agent đã làm gì và có khả năng giải thích hoạt động đó. 

Trong Agents SDK, tracing có thể ghi model turn, tool call, guardrail và handoff trong toàn bộ workflow. 

Vì vậy:

Approval không có context → người duyệt dễ bấm theo thói quen.

Approval có evidence và trace → người duyệt có cơ sở để quyết định.

7 lỗi thường gặp khi thiết kế human-in-the-loop

Lỗi 1: Duyệt mọi thứ

Nếu agent cần xin phép để:

• Đọc từng file.
• Tìm từng URL.
• Tạo từng đoạn text.
• Chạy từng phép tính.

người dùng sẽ nhanh chóng bỏ qua nội dung approval và bấm đồng ý theo phản xạ.

Approval nên tập trung vào hành động có rủi ro hoặc hậu quả đáng kể.

Lỗi 2: Chỉ có approval ở cuối

Nếu agent đã:

• gửi dữ liệu nhạy cảm ra ngoài;
• sửa hệ thống;
• xóa file;

rồi mới hỏi:

Kết quả có ổn không?

thì approval đã quá muộn.

HITL phải xuất hiện trước điểm không dễ hoàn tác.

Lỗi 3: Nút Approve không giải thích agent sắp làm gì

Người dùng cần thấy ít nhất:

• Action.
• Target.
• Data.
• Consequence.

Không nên bắt người duyệt đoán.

Lỗi 4: Agent tự mở rộng quyền khi gặp lỗi

Ví dụ:

Không đọc được file A nên agent tìm toàn bộ thư mục.

Đó là mở rộng scope.

Khi quyền không đủ, workflow nên yêu cầu permission hoặc báo lỗi.

Lỗi 5: Reject nhưng agent thử lại cùng hành động

Reject là một quyết định.

Nếu agent nhận reject rồi tiếp tục gọi lại tool y hệt, human control trở nên vô nghĩa.

Workflow phải định nghĩa rõ behavior sau reject.

Lỗi 6: Không lưu evidence cho bước phê duyệt

Sau này cần trả lời:

• Ai duyệt?
• Duyệt gì?
• Khi nào?
• Input lúc đó là gì?

Nếu workflow có ảnh hưởng thực tế, trace và lịch sử approval rất hữu ích cho debug và audit. 

Lỗi 7: Xem human approval là biện pháp an toàn duy nhất

Con người cũng có thể:

• đọc sót;
• hiểu sai;
• click quá nhanh;
• không có đủ context.

Do đó, approval nên kết hợp với:

• Access boundaries.
• Guardrails.
• Structured input/output.
• Logging.
• Testing.
• Clear policy.

Cách thiết kế human-in-the-loop cho một workflow mới

Bước 1: Vẽ workflow không có approval trước

Ví dụ:

Input → Research → Draft → Send

Bước 2: Đánh dấu mọi hành động có side effect

Ở ví dụ trên:

Send tạo tác động bên ngoài.

→ ứng viên rõ cho human approval.

Bước 3: Đánh dấu dữ liệu nhạy cảm

Nếu Input chứa dữ liệu nội bộ:

→ thêm data gate trước Research.

Bước 4: Xác định tiêu chuẩn output

Draft có thể cần:

• evidence;
• completeness;
• no sensitive data.

→ thêm quality gate.

Bước 5: Xác định failure path

Research thất bại thì:

• Retry bao nhiêu lần?
• Khi nào hỏi người dùng?
• Khi nào dừng?

→ thêm retry/escalation gate.

Bước 6: Tách chuẩn bị khỏi thực thi

Thay:

Draft and Send

bằng:

Draft → Review → Send

Bước 7: Ghi rõ quyết định sau từng gate

Ví dụ:

Approve → tiếp tục

Reject → dừng

Edit → quay lại draft

Need more data → quay lại input

Workflow lúc này không còn là một đường thẳng mà là một hệ thống có điểm kiểm soát rõ.

Mẫu Human Approval Map có thể dùng ngay

Mỗi workflow không nhất thiết cần đủ cả năm.

Một task đơn giản như:

Tóm tắt tài liệu công khai để tôi đọc.

có thể không cần approval nào giữa chừng.

Một workflow:

Đọc dữ liệu khách hàng → đề xuất email → gửi email hàng loạt.

cần nhiều kiểm soát hơn.

Checklist kiểm soát AI Agent trước khi đưa vào workflow thật

Trước khi vận hành, hãy kiểm tra:

1. Agent được phép dùng những dữ liệu nào?
2. Có loại dữ liệu nào phải hỏi trước khi đọc không?
3. Agent có quyền read, write và execute nào?
4. Quyền nào đang rộng hơn nhu cầu?
5. Tool nào tạo side effect?
6. Tool nào bắt buộc human approval?
7. Output được kiểm tra theo tiêu chí nào?
8. Có evidence để con người review không?
9. Agent làm gì khi input thiếu?
10. Agent retry tối đa bao nhiêu lần?
11. Reject một action thì workflow đi đâu?
12. Hành động cuối có thể hoàn tác không?
13. Trước bàn giao, người dùng nhìn thấy những thông tin gì?
14. Có lưu trace hoặc lịch sử hành động không?
15. Người chịu trách nhiệm cuối cùng là ai?

Nếu câu trả lời cho câu 15 là:

AI Agent.

thì ranh giới trách nhiệm của workflow vẫn chưa đủ rõ.

Human-in-the-loop có làm AI Agent kém tự động hơn không?

Có, theo nghĩa agent không được tự quyết định mọi thứ.

Nhưng đó không nhất thiết là nhược điểm.

Mục tiêu của automation trong môi trường thật không phải là:

loại con người khỏi mọi bước.

Mục tiêu phù hợp hơn là:

để máy tự xử lý những phần lặp lại và ít rủi ro, còn con người tập trung vào những quyết định có hậu quả, bối cảnh hoặc trách nhiệm cao.

OpenAI mô tả cách tiếp cận an toàn cho agent theo hướng giữ công việc rủi ro thấp thuận tiện trong ranh giới được kiểm soát, đồng thời làm các hành động rủi ro cao trở nên rõ ràng và dừng để review khi cần. 

Đó cũng là logic của PD P2.1 Brain Engineer: assistant hỗ trợ theo bối cảnh cá nhân, nhưng chất lượng, dữ liệu và quyết định cuối vẫn dưới sự kiểm soát của học viên.

Kết luận

Human-in-the-loop trong AI Agent là thiết kế các điểm kiểm soát để con người vẫn giữ quyền quyết định ở những phần quan trọng của workflow, thay vì để agent tự động hóa toàn bộ từ input đến hành động cuối.

Một khung thực hành có thể map thành năm cổng:

dữ liệu → quyền truy cập/hành động → kết quả → chạy lại/xử lý lỗi → bàn giao.

Không phải cổng nào cũng cần approval thủ công. Các bước có thể được bảo vệ bằng access boundaries, guardrails hoặc policy tự động; human approval nên ưu tiên cho những quyết định có rủi ro, tác động bên ngoài hoặc khó hoàn tác. OpenAI Agents SDK hiện hỗ trợ trực tiếp việc pause run trước sensitive tool calls, approve/reject rồi resume, đồng thời cung cấp guardrails và tracing cho các lớp kiểm soát bổ sung. (

Với cách tiếp cận của P2.1 Brain Engineer, câu hỏi cốt lõi khi thiết kế workflow không phải là “AI có thể tự làm hết không?”, mà là “phần nào nên tự động, phần nào cần kiểm tra và điểm nào con người bắt buộc phải giữ quyền quyết định?”