Bảy bài trước cho bạn từng mảnh ghép: thang rủi ro, approval gate, undo/idempotency, audit, giám sát, trải nghiệm người duyệt. Bài này lắp chúng thành một hệ thống chạy được và bàn cách vận hành, điều chỉnh nó theo thời gian.
Kiến trúc tổng thể
[Agent lập kế hoạch] --> action (write)
|
v
[1. Tính risk] --(policy)--> mức tự chủ L0..L4
|
L0/L1 | L2 | L3/L4
auto | auto + undo window| tạo approval request -> chờ người
| | |
v v v (duyệt)
[2. Kill switch + rate limit + circuit breaker] <-- chặn nếu bất thường
|
v
[3. execute_once(idempotency key)]
|
v
[4. Audit trail (append-only)] --> dashboard, điều tra
Mọi hành động write chảy qua đúng một đường ống này. Không có cửa hậu.
Ví dụ cụ thể: hàm điều phối trung tâm
def run_action(agent, action, ctx):
if kill_switch.is_on():
raise Halted()
risk = assess_risk(action, ctx)
level = policy.level_for(risk)
idem = action.idempotency_key()
if breaker.tripped() or level in ('L3', 'L4'):
req = create_approval(action, ctx, risk, level)
audit(agent, action.name, action.params,
reasoning=ctx.reason, risk=risk, level=level,
approval={"required": True, "request": req.id})
raise Interrupt(req.id) # chờ người duyệt (Bài 3)
if level == 'L2':
job = schedule_with_undo(action, minutes=5) # Bài 4
audit(agent, action.name, action.params,
reasoning=ctx.reason, risk=risk, level=level,
result={"scheduled": job})
return job
result = execute_once(action, idem) # L0/L1 chạy ngay, chống trùng
audit(agent, action.name, action.params,
reasoning=ctx.reason, risk=risk, level=level, result=result)
return result
Một hàm, tất cả các lớp phòng thủ, một điểm để soi khi có sự cố.
Chính sách khởi động: bắt đầu chặt rồi nới
Khi đưa agent mới vào việc thật, hãy bắt đầu bảo thủ: đặt ngưỡng thấp để nhiều hành động qua người duyệt. Sau đó, dựa trên dữ liệu (tỉ lệ agent đúng, tỉ lệ người duyệt chỉ bấm "Duyệt"), dần nới quyền tự chủ cho các mẫu đã chứng minh an toàn. Nới quyền dễ; siết lại sau sự cố thì tốn niềm tin.
Các bước triển khai và vận hành
- Gom mọi write vào một
run_actionduy nhất; chặn mọi tool gọi tắt. - Ngoại hóa policy (rủi ro, ngưỡng, định tuyến duyệt) ra cấu hình chỉnh được không cần deploy.
- Chạy chế độ shadow trước: agent đề xuất, người luôn duyệt, đo độ chính xác trước khi trao quyền.
- Bật dần tự chủ cho các mẫu có tỉ lệ đúng cao và rủi ro thấp.
- Theo dõi chỉ số vận hành: thời gian duyệt, tỉ lệ từ chối, tỉ lệ undo, số lần breaker ngắt.
- Rà soát định kỳ audit trail để tìm mẫu cần tự động hóa thêm hoặc siết lại.
- Diễn tập sự cố kill switch/undo mỗi quý.
Checklist sẵn sàng production
- [ ] Mọi write đi qua một đường ống có gate, không có bypass?
- [ ] Risk tính động theo tham số tại thời điểm gọi?
- [ ] Có undo/compensate cho hành động ngoài L0?
- [ ] Idempotency key bắt nguồn từ ý định?
- [ ] Audit append-only, có reasoning và approval?
- [ ] Có kill switch (người nghiệp vụ bật được) + rate limit + circuit breaker?
- [ ] Màn duyệt đủ ngữ cảnh, chống approval fatigue?
- [ ] Policy ngoại hóa, chỉnh được không cần deploy?
- [ ] Đã chạy shadow mode và nới quyền dựa trên dữ liệu?
Sai lầm thường gặp
- Trao toàn quyền tự chủ ngay ngày đầu. Chưa có dữ liệu chứng minh agent đúng mà đã bỏ người ra khỏi vòng lặp là công thức của sự cố.
- Policy nằm trong code. Mỗi lần điều chỉnh khẩu vị rủi ro phải deploy lại — chậm và dễ sai; hãy ngoại hóa.
- Nới quyền mà không đo. Tăng tự chủ theo cảm tính thay vì theo tỉ lệ đúng thực tế.
- Coi HITL là dự án một lần. Rủi ro, mẫu lạm dụng, hành vi agent thay đổi theo thời gian; phải rà soát và điều chỉnh liên tục.
- Nhiều lớp nhưng có cửa hậu. Chỉ cần một tool gọi API trực tiếp ngoài
run_actionlà toàn bộ hệ thống kiểm soát vô nghĩa.
Tổng kết khóa học
HITL không phải là bắt agent hỏi ý bạn mọi lúc, mà là thiết kế đúng điểm chèn con người theo mức rủi ro: tự chủ ở nơi an toàn, phê duyệt ở nơi nguy hiểm, undo và audit ở khắp nơi, cùng giám sát chủ động để bắt lỗi ở quy mô. Làm được vậy, bạn có một agent vừa hữu ích thật sự vừa an toàn để đưa vào việc thật.