Human-in-the-Loop: Khi Nào AI Agent Cần Hỏi Con Người

Posted on: 5/25/2026 2:06:26 PM

Một AI agent có thể đọc cả nghìn dòng log, vạch ra phương án, rồi tự tin nhấn nút "xoá toàn bộ production database" — chỉ vì nó "khá chắc" rằng đó là cách dọn dẹp tốt nhất. Năm 2026, khi agent đã đủ thông minh để hành động thật chứ không chỉ gợi ý, câu hỏi quan trọng nhất không còn là "agent có làm được không" mà là "khi nào thì con người phải đứng giữa agent và nút bấm đó". Human-in-the-Loop (HITL) chính là kiến trúc trả lời câu hỏi này: biến sự giám sát của con người từ một cái phanh tay vội vã thành một quyết định thiết kế có chủ đích.

1. Vì sao "tự chủ hoàn toàn" là một cái bẫy

Làn sóng agent 2024–2025 bị ám ảnh bởi mức độ tự chủ: agent càng ít cần con người càng "xịn". Nhưng đến 2026, các đội triển khai thực tế đã rút ra một bài học đắt giá: tự chủ không phải là mục tiêu, mà là một thanh trượt cần được điều chỉnh theo rủi ro. Những deployment thành công nhất không loại bỏ con người — họ đặt con người vào đúng chỗ.

Vấn đề cốt lõi nằm ở chỗ LLM tự tin một cách đồng đều: nó nói "tôi chắc chắn" với cùng giọng điệu dù đang trả lời đúng hay đang ảo giác (hallucinate). Một agent có thể đúng 95% số lần, nhưng nếu 5% còn lại rơi vào hành động không thể hoàn tác — chuyển tiền, xoá dữ liệu, gửi email cho toàn bộ khách hàng, merge một pull request lên main — thì kỳ vọng toán học của thiệt hại có thể vượt xa toàn bộ giá trị 95% kia mang lại.

2. In-the-loop, On-the-loop và Out-of-the-loop

"Human-in-the-loop" thường bị dùng như một thuật ngữ chung chung. Thực tế có ba mô hình giám sát khác biệt rõ rệt, và chọn sai mô hình cho một ngữ cảnh là nguồn gốc của hầu hết các sự cố.

Cách hữu ích để định khung là mượn thang đo mức độ tự chủ của ngành xe tự lái: không có hệ thống nào "tự chủ" tuyệt đối, chỉ có các mức tự chủ theo từng loại hành động.

3. Bốn chiều rủi ro: khi nào cần con người?

Câu hỏi "hành động này có cần phê duyệt không?" nên được trả lời bằng một hàm rõ ràng trên bốn chiều rủi ro, thay vì cảm tính của lập trình viên:

• Tính bất khả hồi (irreversibility): Có hoàn tác được không? Xoá file có backup khác với DROP DATABASE.
• Bán kính ảnh hưởng (blast radius): Tác động tới bao nhiêu người/bản ghi? Sửa 1 dòng khác với gửi email cho 2 triệu user.
• Phơi nhiễm tuân thủ (compliance exposure): Hành động có tạo nghĩa vụ pháp lý/quy định không? (GDPR, hợp đồng, tài chính)
• Độ tự tin (confidence): Agent chắc chắn tới mức nào về tính đúng đắn?

flowchart TD
    A[Agent đề xuất hành động] --> B{Bất khả hồi?}
    B -- Không --> C{Blast radius lớn?}
    B -- Có --> G[Bắt buộc phê duyệt]
    C -- Không --> D{Liên quan tuân thủ?}
    C -- Có --> G
    D -- Có --> G
    D -- Không --> E{Confidence >= ngưỡng?}
    E -- Có --> F[Tự động thực thi]
    E -- Không --> H[Escalate cho con người]
    G --> I[Hàng đợi phê duyệt]
    H --> I
    style G fill:#e94560,stroke:#fff,color:#fff
    style F fill:#4CAF50,stroke:#fff,color:#fff
    style I fill:#2c3e50,stroke:#fff,color:#fff

4. Ngưỡng confidence và bài toán hiệu chỉnh

Confidence là chiều "rẻ" nhất để tự động hoá, nhưng cũng nguy hiểm nhất nếu dùng sai. Một thực hành tốt năm 2026 là đặt ngưỡng theo chi phí lỗi của từng loại hành động, không phải một ngưỡng chung:

Cạm bẫy lớn nhất: điểm confidence do chính LLM tự báo cáo thường không được hiệu chỉnh (uncalibrated). Một mô hình có thể nói "0.95" cho cả câu trả lời đúng lẫn sai. Vì vậy đừng tin con số thô — hãy đo ECE trên dữ liệu thật, hoặc dùng tín hiệu gián tiếp (self-consistency giữa nhiều lần sinh, độ phân tán của ensemble, verifier model) thay cho lời tự khai của model.

5. Kiến trúc một cổng phê duyệt (approval gate)

Một cổng phê duyệt production cần đủ bốn thành phần — thiếu bất kỳ phần nào đều dẫn tới lỗi:

sequenceDiagram
    participant Ag as Agent
    participant Gate as Cổng phê duyệt
    participant Q as Hàng đợi + State Store
    participant H as Người phê duyệt
    Ag->>Gate: Đề xuất hành động + lý do
    Gate->>Q: Tạm dừng & lưu trạng thái (checkpoint)
    Q->>H: Thông báo (Slack/email/UI)
    Note over H: Có thể mất vài phút
tới vài ngày
    H->>Q: Duyệt / Từ chối / Chỉnh sửa
    Q->>Gate: Khôi phục từ checkpoint
    Gate->>Ag: Tiếp tục hoặc huỷ

1. Cơ chế tạm dừng (interrupt): dừng agent trước hành động bị gắn cờ, mà không mất ngữ cảnh.
2. Hệ thống thông báo: đẩy yêu cầu tới đúng người (định tuyến theo loại/rủi ro).
3. Giao diện review: hiển thị hành động đề xuất kèm lý do (reasoning) của agent — người duyệt cần đủ ngữ cảnh để không "bấm bừa".
4. Cơ chế khôi phục (resume): tiếp tục, sửa đổi rồi tiếp tục, hoặc huỷ — từ đúng điểm đã dừng.

6. Cài đặt kỹ thuật: tạm dừng bền vững và khôi phục

Thử thách kỹ thuật cốt lõi: agent có thể phải chờ phê duyệt hàng giờ, hàng ngày. Bạn không thể giữ một process sống và một context window mở suốt thời gian đó. Lời giải là state persistence + durable execution.

LangGraph: interrupt() và checkpointer

Trong LangGraph — nền tảng phổ biến cho agentic workflow 2026 — HITL được hiện thực bằng interrupt(): hàm này tạm dừng đồ thị tại một node, lưu toàn bộ state vào checkpointer, và chỉ khôi phục khi nhận được phản hồi của con người. Quan trọng: nó không cần khởi động lại workflow — đồ thị tiếp tục từ đúng checkpoint đã dừng.

from langgraph.types import interrupt, Command

def approval_node(state: State):
    # Agent dừng tại đây, state được lưu vào checkpointer
    decision = interrupt({
        "action": "transfer_funds",
        "amount": state["amount"],
        "to": state["recipient"],
        "reasoning": state["agent_reasoning"],  # ngữ cảnh cho người duyệt
    })
    if decision["approved"]:
        return Command(goto="execute")
    return Command(goto="cancel")

# Khi con người trả lời (có thể vài ngày sau), khôi phục từ checkpoint:
graph.invoke(
    Command(resume={"approved": True}),
    config={"configurable": {"thread_id": "txn-9821"}},
)

Vì state nằm ở checkpointer (Postgres/Redis...), bạn còn được thêm một khả năng mạnh: time-travel — tua ngược về một bước chẩn đoán trước đó để agent thử một giả thuyết khác, mà không mất lịch sử hội thoại.

Temporal: phê duyệt bằng signal, chờ vô hạn không tốn compute

Với workflow chạy lâu, Temporal (và Semantic Kernel) dùng mô hình signal-based. Workflow có thể wait_condition chờ phê duyệt hàng giờ, hàng ngày, hoặc vô thời hạn — mà không tiêu tốn tài nguyên compute trong lúc chờ, vì trạng thái được durable hoá và "đánh thức" khi có signal.

@workflow.defn
class AgentWorkflow:
    def __init__(self):
        self._approved: bool | None = None

    @workflow.signal
    def approve(self, decision: bool):
        self._approved = decision

    @workflow.run
    async def run(self, action: Action):
        plan = await workflow.execute_activity(plan_action, action,
                                               start_to_close_timeout=TIMEOUT)
        if plan.risk == "high":
            # Chờ con người -- có thể vài ngày, không tốn compute
            await workflow.wait_condition(lambda: self._approved is not None)
            if not self._approved:
                return "cancelled"
        return await workflow.execute_activity(execute_action, plan,
                                               start_to_close_timeout=TIMEOUT)

7. Escalation và hàng đợi phê duyệt ở quy mô lớn

Khi số lượng yêu cầu phê duyệt tăng, một người không thể xử lý hết. Mẫu escalation định tuyến hành động lên các cấp thẩm quyền cao dần — hoặc tới chuyên gia theo lĩnh vực — dựa trên phân loại rủi ro và điểm confidence.

flowchart LR
    A[Yêu cầu phê duyệt] --> B{Phân loại rủi ro}
    B -- Thấp --> C[Trực ban L1
SLA: phút]
    B -- Trung bình --> D[Chuyên gia lĩnh vực
SLA: giờ]
    B -- Cao / tuân thủ --> E[Quản lý + Compliance
SLA: ngày]
    C --> F[Quyết định + ghi audit]
    D --> F
    E --> F
    style E fill:#e94560,stroke:#fff,color:#fff
    style F fill:#2c3e50,stroke:#fff,color:#fff

8. Những cái bẫy ai cũng vấp (oversight under load)

HITL thất bại không phải vì thiếu công nghệ, mà vì yếu tố con người dưới áp lực. Đây là những lỗi mô hình phổ biến nhất:

9. Góc nhìn Quản lý dự án: HITL là một quyết định quản trị

HITL không chỉ là vấn đề kỹ thuật — nó là một khế ước quản trị. Khi đưa agent vào quy trình, đội ngũ cần trả lời rõ ràng:

• Ai phê duyệt cái gì? Lập ma trận RACI cho từng loại hành động của agent, y như với một thành viên mới trong nhóm.
• Audit trail bất biến: mọi hành động (tự động hay được duyệt) phải để lại dấu vết: ai/cái gì quyết định, dựa trên reasoning nào, lúc nào. Đây là nền tảng cho tuân thủ và cho việc hậu kiểm.
• Lộ trình tăng tự chủ dần (progressive autonomy): bắt đầu bằng "phê duyệt mọi thứ", rồi nới quyền tự chủ theo từng loại hành động khi agent tích luỹ được "lý lịch tin cậy" qua dữ liệu thật.

10. Kết luận

Năm 2026, lợi thế cạnh tranh không thuộc về đội nào "loại bỏ con người nhanh nhất", mà thuộc về đội đặt con người vào đúng chỗ với chi phí giám sát thấp nhất. Human-in-the-Loop trưởng thành nghĩa là:

• Định tuyến hành động qua bốn chiều rủi ro, không phải cảm tính.
• Đặt ngưỡng confidence theo chi phí lỗi và hiệu chỉnh bằng ECE trên dữ liệu thật.
• Dùng interrupt + durable execution (LangGraph, Temporal) để chờ phê duyệt mà không đốt tài nguyên.
• Thiết kế chống lại alert fatigue và automation bias — vì HITL hỏng ở con người trước khi hỏng ở code.
• Quản trị bằng RACI, audit trail và progressive autonomy.

Agent giỏi nhất không phải agent tự chủ nhất, mà là agent biết khi nào nên dừng lại và hỏi.

Nguồn tham khảo

• Anthropic — Effective context engineering for AI agents
• MyEngineeringPath — Human-in-the-Loop Patterns for AI Agents (2026)
• Abstract Algorithms — HITL Workflows with LangGraph: Interrupts, Approvals, Async
• Galileo — How to Build Human-in-the-Loop Oversight for AI Agents
• CallSphere — AI Agent Human-in-the-Loop Patterns for Critical Decisions
• Massimo Mistretta — Human Oversight Under Load in the Age of AI Agents