# Nâng tự chủ cho agent từng bậc, rồi bàn giao quyền giám sát cho đội vận hành của khách

> Hai thứ quyết định agent được khách tin dùng hay bị khoá mãi ở chế độ duyệt tay: một bảng phân quyền kiểu đèn giao thông, và một bản bàn giao vẫn chạy được khi bạn đã rời dự án.

Bản gốc: https://fdetimes.net/vi/bach-khoa/muc-tu-chu-cua-agent-va-ban-giao-van-hanh/

Thử hình dung tuần thứ ba của một dự án: agent xử lý ticket chăm sóc khách hàng bạn dựng đã chạy trơn tru trong sandbox. Trưởng nhóm vận hành bên khách hỏi: "Bao giờ nó tự làm được, không cần người bấm duyệt nữa?" Rồi tiếp một câu khó hơn: "Khi anh rời dự án, ai bên tôi giữ nó?"

Thật ra hai câu hỏi này cùng thuộc một kỹ năng. Một là nâng quyền tự chủ cho agent theo bằng chứng chứ không theo cảm giác. Hai là chuyển việc giám sát agent sang đội của khách sao cho nó còn sống được sau khi bạn đi.

Làm hỏng một trong hai, agent sẽ rơi vào một trong hai số phận: bị khoá mãi ở chế độ duyệt tay, hoặc được thả quá sớm rồi bị rút quyền ngay sau sự cố đầu tiên.

## Tin cậy là thứ tích luỹ, và đo được

Dữ liệu Anthropic công bố về cách người dùng thực sự dùng agent cho thấy một quy luật đơn giản. Người dùng mới, dưới 50 phiên, bật auto-approve toàn phần khoảng 20% số phiên. Người đã qua 750 phiên bật nó trên 40% số phiên.

Ở phía agent, số liệu nội bộ của Anthropic cho thấy số lần con người phải can thiệp trung bình mỗi phiên giảm từ 5,4 xuống 3,3 khi agent chạy tốt hơn. Anthropic gọi khoảng cách giữa mức tự chủ model làm được và mức nó thực sự được trao là "deployment overhang", và cho rằng khoảng cách này đáng kể.

Với một FDE, đây là bản mô tả công việc. Model có lẽ đã đủ giỏi, thứ còn thiếu là con đường bằng chứng để khách dám trao thêm quyền. Anthropic cũng nhấn mạnh rằng muốn hiểu agent được dùng ra sao thì không thể thiếu giám sát sau triển khai. Không có log và chỉ số, bạn không có gì để thuyết phục ai cả.

## Đèn giao thông: phân quyền theo hành động, không theo agent

Mô hình đèn giao thông mà Data Science Dojo mô tả làm ngược lại: phân loại *từng hành động* theo mức rủi ro và gán bậc quyền tương ứng. Nhóm rủi ro cao chạy ở chế độ chỉ đề xuất, có người duyệt.

Nguyên tắc đi kèm là agent phải "giành" được quyền tự chủ bằng năng lực đã được chứng minh, từng bậc một.

Thang A1 đến A5 của MIT Media Lab bổ sung hai ý đáng nhớ. Ở A3, agent phải biết khi nào dừng lại và leo thang lên người. Ở A4, con người không còn giám sát từng hành động mà chuyển sang quản trị hệ thống: đặt chính sách, xác nhận phạm vi nghiệp vụ agent được phép hoạt động, và kiểm toán.

Ở bậc cao nhất, MIT Media Lab vạch thêm một ranh giới mà FDE nên thuộc lòng. A5 nghĩa là agent tự thực thi, không phải agent có thẩm quyền riêng. Nó vẫn bị ràng buộc bởi quyền hạn của tổ chức mà nó đại diện.

**Điểm mấu chốt:** Tự chủ tăng thì con người không biến mất, chỉ chuyển từ duyệt từng thao tác sang viết luật và kiểm toán.

## Một ví dụ: agent xử lý ticket hoàn tiền

Quay lại agent ticket ở đầu bài. Việc đầu tiên là liệt kê mọi tool nó gọi được rồi tô màu. Bảng dưới đây là một ví dụ minh hoạ. Ngưỡng nâng bậc là những con số bạn tự thoả thuận với khách, không có chuẩn chung.

| Hành động | Màu | Bậc ban đầu | Điều kiện nâng bậc (ví dụ) |
|---|---|---|---|
| Đọc lịch sử đơn, tra trạng thái giao hàng | Xanh | Tự làm, ghi log | Không cần |
| Gắn nhãn, phân luồng ticket | Vàng | Tự làm, người kiểm mẫu hằng ngày | Tỷ lệ sửa nhãn thấp trong vài tuần liên tục |
| Gửi email trả lời khách | Vàng | Soạn nháp, người bấm gửi | Tỷ lệ nháp bị sửa nội dung giảm đều |
| Hoàn tiền | Đỏ | Chỉ đề xuất, người duyệt | Chỉ nâng cho khoản nhỏ, và chủ sở hữu chính sách bên khách ký duyệt |

Hàng cuối là nơi phân biệt thực thi và thẩm quyền trở nên cụ thể. Agent có thể đủ chính xác để tự bấm hoàn tiền. Nhưng ai được phép hoàn bao nhiêu là chính sách của khách, và ngưỡng đó phải do người bên họ quyết, không phải bạn.

Chính sách nên nằm trong config, đọc được và review được, thay vì rải rác trong prompt:

```yaml
actions:
lookup_order:   { tier: green,  mode: auto }
tag_ticket:     { tier: yellow, mode: auto, sample_review: daily }
send_reply:     { tier: yellow, mode: draft_only }
issue_refund:   { tier: red,    mode: propose_only, owner: "trưởng nhóm CSKH" }
escalate_when:
- confidence_below_threshold
- customer_mentions_legal_action
promotion_review: weekly   # xem số can thiệp, số lần bị sửa, sự cố
```

Trường `owner` là chi tiết nhiều người bỏ qua. Mỗi hành động đỏ cần một người có tên chịu trách nhiệm quyết định nâng bậc, và đó chính là mầm của việc bàn giao.

## Tự làm: năm việc theo thứ tự

Bắt đầu trong sandbox có guardrail, đúng như Anthropic khuyến nghị, và thiết kế sẵn các checkpoint để agent dừng lại xin phản hồi. Sau đó tô màu toàn bộ hành động như bảng trên, mặc định để mọi thứ không chắc chắn ở màu đỏ.

Tiếp theo là dựng giám sát trước khi lên production: đếm số lần người can thiệp mỗi phiên, số lần đầu ra bị sửa, số lần leo thang. Đây là thứ thay thế cho câu "tôi thấy nó ổn rồi".

Mỗi tuần, ngồi với khách xem số liệu và chỉ nâng một nhóm hành động lên một bậc khi bậc hiện tại đã ổn định. Cuối cùng, khi phần lớn hành động đã ở xanh hoặc vàng, chuyển cuộc họp review đó cho người bên khách chủ trì. Lúc ấy họ đang làm đúng vai trò quản trị ở A4.

## Bàn giao bắt đầu từ ngày đầu tiên

Lời khuyên của Tandem nghe ngược nhưng đúng: hãy bắt đầu bàn giao trước khi biết mình cần nó. Tài liệu tĩnh viết vào tuần cuối sẽ lỗi thời rất nhanh. Vì thế hãy trỏ người đọc tới trạng thái sống của hệ thống, như file config chính sách, dashboard can thiệp, lịch sử nâng bậc, thay vì chép lại chúng vào một file Word.

PostHog đặt chuẩn hoàn thành rất rõ: sản phẩm bàn giao chỉ xong khi một người ngoài cuộc trong đội khách có thể nhận lại mà không cần ai giải thích trước. Các bước tiếp theo phải cụ thể, có thứ tự và gán cho người có tên. "Đội vận hành sẽ theo dõi" không phải là một bước tiếp theo.

Runbook nên viết theo triệu chứng chứ không theo kiến trúc. Người trực lúc nửa đêm sẽ bắt đầu từ "agent gửi email sai giọng" hay "tỷ lệ leo thang tăng vọt", không ai bắt đầu từ sơ đồ service. AI Codex đề xuất một bài kiểm thử: đưa runbook cho người không tham gia xây hệ thống và nhờ họ đọc to cách xử lý một triệu chứng.

## Những lỗi hay gặp

Lỗi đầu tiên là nâng bậc theo lịch ("sau một tháng thì cho tự chạy") thay vì theo số liệu. Lỗi thứ hai là trộn khả năng và thẩm quyền: agent đúng 99% không có nghĩa nó được tự quyết chính sách hoàn tiền.

Lỗi thứ ba là không có giám sát sau triển khai, nên cuộc họp nâng bậc chỉ còn là tranh luận cảm tính. Lỗi cuối cùng là để bàn giao cho tuần cuối, khi người duy nhất hiểu vì sao hành động X vẫn ở màu đỏ lại chính là người sắp rời đi.

Nếu đang xin việc FDE, bạn nên đưa kỹ năng này vào CV bằng con số thay vì tính từ. Ví dụ: thiết kế lộ trình nâng tự chủ cho agent, giảm số lần can thiệp mỗi phiên từ bao nhiêu xuống bao nhiêu, và bàn giao quy trình review cho đội vận hành của khách.

## Bài tập tuần này

Chọn một quy trình tự động bạn đang vận hành: một agent, một cron job hay một bot nội bộ. Viết file chính sách như mẫu YAML ở trên, gán owner cho mỗi hành động đỏ, rồi viết một mục runbook cho đúng một triệu chứng. Đưa nó cho đồng nghiệp chưa từng đụng vào hệ thống và im lặng nghe họ đọc to.

Chỗ họ khựng lại chính là chỗ hệ thống của bạn vẫn còn phụ thuộc vào bạn. Một FDE giỏi là người làm cho chỗ đó biến mất trước ngày rời dự án.

**Thử ngay tuần này:**

- Lấy một agent hoặc script tự động bạn đang có, liệt kê mọi hành động nó gọi được và tô màu xanh, vàng, đỏ cho từng hành động.
- Đếm số lần bạn phải can thiệp tay mỗi phiên trong một tuần và ghi lại. Con số đó đưa vào CV có sức nặng hơn mọi tính từ.
- Đọc ba JD FDE hoặc solutions engineer, gạch chân các cụm như human-in-the-loop, guardrails, runbook, handover để biết nhà tuyển dụng đang chờ kỹ năng nào.

## Nguồn

- [Measuring AI agent autonomy in practice (Anthropic)](https://www.anthropic.com/research/measuring-agent-autonomy)

- [Graduated autonomy for AI agents: the traffic-light model](https://datasciencedojo.com/blog/graduated-autonomy-ai-agents/)

- [From Autonomous Cars to Autonomous Agents: The Five Levels of AI Agent Autonomy](https://www.media.mit.edu/articles/from-autonomous-cars-to-autonomous-agents-the-five-levels-of-ai-agent-autonomy/)

- [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)

- [Working with customers - Handbook (PostHog)](https://posthog.com/handbook/forward-deployed-engineering/working-with-customers)

- [The handoff that survives your departure (AI Codex)](https://www.aicodex.to/articles/fde-handoff-that-survives)

- [FDE handoffs: keeping an engagement alive when the builder changes | Tandem](https://usetandem.ai/blog/fde-handoff-runbook)