Các mức độ tự chủ của tác nhân

• Kỹ thuật theo kiểu tác nhân đang trở nên gần với thiết kế vận hành hơn là viết prompt, và với từng công việc cần đồng thời xác định mức độ tự chủ được phép cùng phương thức kiểm chứng để hỗ trợ mức đó
• Mô hình thang đơn hữu ích để biểu diễn mức độ tin cậy vào một tác nhân bằng con số, nhưng năng lực xử lý đồng thời nhiều tác nhân cần được nhìn theo hai trục: agency và orchestration
• Mô hình 0~5 kéo dài từ Assist chỉ đưa ra đề xuất đến Managed-by-exception orchestration nơi con người chỉ can thiệp trong tình huống ngoại lệ; cấp càng cao thì mục tiêu, phạm vi, bằng chứng, quyền hạn và ngân sách càng phải rõ ràng
• Trong phân tích về Anthropic Claude Code, dữ liệu từ khoảng 400.000 phiên và khoảng 235.000 người dùng cho thấy con người đảm nhiệm khoảng 70% quyết định lập kế hoạch, còn Claude đảm nhiệm khoảng 80% phần thực thi
• Việc tận dụng tác nhân một cách trưởng thành không nằm ở chỗ phô diễn mức tự chủ cao, mà ở việc áp dụng calibrated autonomy phù hợp với rủi ro và mức độ có thể hoàn tác, đồng thời quản lý nút thắt kiểm chứng

---

Từ viết prompt sang thiết kế vận hành trong kỹ thuật theo kiểu tác nhân

• Trọng tâm của kỹ thuật theo kiểu tác nhân đang dịch chuyển từ viết prompt sang thiết kế vận hành
• Software factory, mục tiêu, loop, background session, sub-agent, hook, sandbox, và cách tác nhân phê duyệt tác nhân khác đang xuất hiện ở tuyến đầu
• Claude Code và Codex được xem là các sản phẩm tiêu biểu cho sự thay đổi này
• Kỹ sư có thể dùng mức tự chủ thấp để giảm rủi ro và giúp dễ hoàn tác, còn với các hoạt động rõ ràng hoặc refactor codebase quy mô lớn thì có thể dùng mức tự chủ cao hơn cùng một đội tác nhân chạy song song
• Câu hỏi cốt lõi là với mỗi công việc nên cho phép mức độ tự chủ nào, và kiểu kiểm chứng nào có thể bảo vệ mức đó

Tự chủ theo hai trục thay vì một chiếc thang đơn

• Chiếc thang một trục được nhắc tới trong “Welcome to Gas Town” của Steve Yegge hữu ích khi biểu diễn mức độ tin cậy vào một tác nhân bằng con số
• Đầu năm 2026, ngay cả khi công việc chuyển từ ủy nhiệm sang orchestration, một trục đơn vẫn hoạt động như chỉ dấu đại diện gần đúng để đo rủi ro
• Khi có thể chạy đồng thời nhiều tác nhân, chỉ một cấp đơn lẻ sẽ khó giải thích năng lực đa tác nhân
• Thảo luận về tự chủ thường trộn lẫn hai câu hỏi khác nhau
  • Có thể để một tác nhân đi xa con người đến mức nào
  • Có thể điều phối nhiều tác nhân tốt đến mức nào
• Để tách chúng ra, cần hai trục
  • agency: một tác nhân có thể tự chủ tới đâu trong việc đề xuất, thực hiện tác vụ giới hạn, hay hoàn thành mục tiêu
  • orchestration: có thể điều phối tới đâu, từ một thread duy nhất đến nhiều cây công việc, rồi tới công việc liên tục dựa trên backlog, issue tracker và lịch

Ý nghĩa của agency và orchestration

• Ở mức thấp của trục agency, tác nhân đề xuất các hành động khả dĩ và chờ con người quyết định
• Ở mức trung bình, tác nhân thực hiện một số tác vụ cụ thể nhưng bị giới hạn phạm vi, đồng thời liên tục báo lại những gì đã làm kèm bằng chứng để con người có thể điều chỉnh
• Ở mức agency cao, tác nhân có thể thử nghiệm, học hỏi, kiểm thử, xử lý tình huống bị chặn, đặt câu hỏi, thử cách tiếp cận khác để tiến tới mục tiêu rồi trả lại bằng chứng
• Mức thấp của trục orchestration là một tác nhân với một thread duy nhất
• Ở mức trung bình, nhiều tác nhân thực hiện các mục tiêu khác nhau trong các worktree tách biệt
• Ở mức cao, một orchestrator biến backlog, issue tracker, lịch và queue thành công việc liên tục, còn con người chỉ can thiệp khi thất bại theo kiểu management by exception
• Ví dụ về tính năng và sản phẩm liên quan gồm
  • Claude Code: /plan, /goal, /loop, /background, /batch, /code-review, /security-review, sub-agent, hook, checkpoint, cách ủy nhiệm và quản lý tác nhân, background session, mẫu nhóm tác nhân, tham số /schedule
  • Codex: thread cục bộ và cloud, Goal mode, worktree, Automations, sub-agent, review panel, GitHub code review, hook, sandbox, Auto-review, rerun

Ba thời kỳ và sáu cấp độ

• Nếu đọc chiếc thang từ dưới lên trên, nó trông như thể đồng thời tăng cả agency lẫn orchestration
• Sáu cấp được chia thành ba thời kỳ
  • Thời kỳ con người ngồi ở ghế lái, tác nhân chỉ hỗ trợ và chờ thao tác của con người
  • Thời kỳ tác nhân nhận các tác vụ hoặc mục tiêu bị giới hạn nhưng vẫn được con người điều chỉnh và kiểm chứng
  • Thời kỳ orchestration, nơi hệ thống phân phối công việc cho nhiều tác nhân và con người chủ yếu chỉ can thiệp khi có vấn đề
• Trong kỹ thuật thực tế, việc di chuyển qua lại giữa nhiều cấp trong cùng một ngày là điều tự nhiên

Level 0: Assist

• Tác nhân thường đưa ra đề xuất tốt, đôi khi hoàn hảo, nhưng con người luôn là người quyết định có thực thi hay không
• Ví dụ là tự động hoàn thành, gợi ý chỉnh sửa inline, hoặc thảo luận trong chat về những thay đổi chưa thuộc sở hữu của ai
• Phù hợp với lỗi có chi phí lớn, thay đổi rất nhỏ, hoặc công việc mà con người vẫn đang hình thành nhận định
• Việc kiểm chứng chủ yếu diễn ra ở cục bộ

Level 1: Supervised action

• Tác nhân thay mặt chỉnh sửa hoặc chạy lệnh, nhưng sẽ xin phép con người trước những hành động quan trọng
• Đây gần với tư thế mặc định mà đa số mọi người sử dụng
• Có thể thực hiện trong sandbox cục bộ với phê duyệt trước khi áp dụng thay đổi, hoặc trong phiên tương tác
• Mỗi lần phê duyệt hoạt động như một bước kiểm chứng độc lập để xác nhận việc áp dụng thay đổi đó là chấp nhận được
• Chế độ lỗi chính là mệt mỏi vì phê duyệt
  • Mọi lần phê duyệt có thể bắt đầu giống nhau bất kể nội dung là gì
  • Có thể đối phó bằng cách lướt diff, dựa vào heuristic, nhờ người khác kiểm tra, hoặc cho phép tác nhân chịu trách nhiệm
• Codex Auto-review xử lý vấn đề này bằng cách giao khâu phê duyệt cuối ở điều kiện biên cho một reviewer agent riêng

Level 2: Scoped task delegation

• Đây là giai đoạn giao một tác vụ bị giới hạn cho tác nhân
• Tác vụ phải có mục tiêu rõ ràng, ràng buộc rõ ràng, và định nghĩa công việc hoàn tất rõ ràng
• Con người vẫn ở gần để có thể dừng lại, nhưng phần lớn không can dự trực tiếp
• Đây được xem là cấp gần với trung tâm nhất trong kỹ thuật phần mềm
• Việc kiểm chứng chuyển từ xác nhận trực tiếp của con người sang bằng chứng mà tác nhân có thể tạo ra
  • test tự động đã pass
  • kiểu dữ liệu phù hợp
  • gợi ý lint
  • ảnh chụp màn hình
  • quy trình tái hiện
  • nguồn dẫn theo ví dụ

Level 3: Goal-driven autonomy

• Tác nhân thực hiện những gì cần thiết để đạt mục tiêu cho đến khi một điều kiện cụ thể được đáp ứng
• Trong chế độ prompt, chính prompt trở thành mục tiêu
  • Ví dụ: “Có thể giảm time-to-interactive của trang này xuống dưới 1 giây không?”
• Trong Codex, Goal mode tương ứng với mức này; tác nhân lặp qua các bước plan -> act -> test -> review cho đến khi không còn đáp ứng tiêu chí thành công thì dừng
• Trong Claude Code, các lệnh /goal, /loop, /schedule tương ứng với mức này
• Để mức này hữu ích, điều kiện dừng phải đo lường được theo cách có thể tự động hóa
• Những mục tiêu mơ hồ như “cải thiện trải nghiệm người dùng nói chung” hoặc “làm codebase dễ test hơn” là không phù hợp
• Mục tiêu phù hợp hơn cần cụ thể, đo lường được và tự động hóa được
  • tìm bug production lọt qua phân tích tĩnh
  • giảm thời gian tải
  • đảm bảo build TypeScript strict không có any tường minh
  • phân loại toàn bộ dependency để chỉ giữ lại những dependency có thể hiểu được và vượt qua kiểm thử
• Muốn tìm bug production, tác nhân phải ở trong môi trường tương tự production

Level 4: Parallel delegation

• Đây là giai đoạn nhiều tác nhân làm việc song song
• Mỗi tác nhân đảm nhiệm một phần tách biệt của công việc
• Nút thắt lớn nhất là phân rã để quyết định nên giao phần nào đi
• Các tính năng hỗ trợ gồm sub-agent, background session, /batch, worktree, đội tác nhân
• Chế độ lỗi chính là song song giả
  • Nếu nhiều tác nhân xử lý các phần chồng lấn cùng lúc, chúng có thể tạo ra merge conflict và quyết định trùng lặp thay vì làm được nhiều việc hơn
• Muốn vận hành tốt, các tác nhân phải được cô lập với nhau
  • Mỗi tác nhân cần có file và trạng thái mà mình sở hữu
  • Mỗi tác nhân cũng nên có queue review riêng
• Mỗi tác nhân đều phát sinh chi phí token, tỷ lệ thuận với số tác nhân chạy đồng thời
• Ở phía con người, sau một ngưỡng nhất định, chi phí cận biên của việc thêm tác nhân tăng lên do thuế orchestration

Level 5: Managed-by-exception orchestration

• Con người định nghĩa thành công là gì và các chính sách cần áp dụng, còn manager agent sẽ thức dậy theo trigger để phân phối công việc
• Ví dụ về trigger là issue mới, tác vụ mới, hoặc đồng hồ
• Manager agent triển khai worker agent, theo dõi tiến độ, kiểm chứng đầu ra, và thử lại khi thất bại
• Khi điều kiện được thỏa mãn, nó sẽ escalate lên tác nhân có năng lực cao hơn hoặc con người, rồi tổng hợp kết quả và trả về các đầu ra công việc như PR cùng bằng chứng cho hệ thống bên ngoài
• Mức này được ví như một factory
  • đầu vào là issue tracker hoặc backlog
  • đầu ra là nhiều issue hoặc bug đã được giải quyết
• Tác nhân làm việc trong môi trường cô lập với ranh giới đủ rõ và có lối thoát khi cần
• Việc factory này phải làm gì được quyết định bởi hệ điều hành vận hành do manager agent định nghĩa
• OpenAI đã đề xuất spec cho Symphony, lấy board Linear làm trung tâm
  • mỗi issue có workspace tác nhân riêng
  • tác nhân kiểm tra xem nó có đang tiếp tục tiến về mục tiêu được định nghĩa trong file spec của workspace hay không
• Tuyến đầu của orchestration là xây dựng các factory tác nhân liên tục với hàng trăm hoặc hàng nghìn tác nhân hoạt động
• Ở cấp này, kiểm chứng độc lập trở nên quan trọng hơn
  • tách biệt người triển khai và người review
  • tách biệt người chạy test và QA
  • tách biệt kiểm tra bảo mật
  • tách biệt các process gate cho khâu chấp nhận

Rủi ro và mức độ có thể hoàn tác quyết định trần tự chủ

• Trong nghiên cứu liên quan đến Claude Code của Anthropic, ở một số tác vụ khó nhất Claude Code đặt câu hỏi làm rõ thường xuyên hơn hơn gấp đôi so với việc người dùng ngắt quãng
• Người dùng giàu kinh nghiệm, được định nghĩa là có khoảng 750 phiên, có xu hướng dùng auto-approve và interrupt thường xuyên hơn, đồng thời theo dõi tiến độ nhiều hơn so với người dùng có dưới 50 phiên
• Phân tích rộng hơn của Anthropic bao quát khoảng 400.000 phiên của khoảng 235.000 người dùng từ tháng 10/2025 đến tháng 4/2026
• Trong mỗi phiên, có thể xác định các quyết định như số hành động mà người dùng yêu cầu trong mỗi prompt, mục nào được auto-approve, và tần suất interrupt
• Con người đưa ra khoảng 70% quyết định lập kế hoạch, còn Claude thực hiện khoảng 80% phần thi hành
• Tự chủ cao không có nghĩa là loại con người ra khỏi vòng lặp, mà là chuyển từ việc con người làm từng bước sang việc con người quyết định hướng đi tiếp theo
• Muốn đánh giá liệu một hệ thống AI lớn có thực sự vận hành với mức tự chủ cao hay không, cần ba câu hỏi
  • Có thể biết nó đang làm sai điều gì nhanh đến mức nào
  • Có thể hoàn tác những gì nó đang làm sạch sẽ đến mức nào
  • Điều gì chứng minh rằng những gì nó đang làm là đúng
• Nếu câu trả lời là “không thể biết nhanh, khó hoàn tác, và phải tin vào bản tóm tắt” thì đó không phải là tự chủ cao

Những mục cần có trong hợp đồng trước khi tác nhân thực thi

• Trước mỗi lần tác nhân chạy cần có một hợp đồng định nghĩa nó sẽ làm gì
• Hợp đồng cần bao gồm các mục sau
  • mục tiêu: kết quả cần đạt được chứ không phải hoạt động hay kỹ thuật
  • phạm vi: miền công việc và kỹ thuật được phép dùng
  • phi mục tiêu: những thứ không thuộc mục đích
  • công cụ và quyền hạn: cách tác nhân tương tác với thế giới bên ngoài
  • điều kiện dừng: khi nào phải dừng, nếu có thể thì bằng biến số đo lường được
  • bằng chứng: test, ảnh chụp, log, bản ghi cơ sở dữ liệu... để có thể xác nhận hoàn thành một cách độc lập
  • escalation: trong tình huống nào ai sẽ can thiệp, và ai là người chạy tác nhân
  • ngân sách: giới hạn thời gian, công sức, token
• Token là ngân sách của các mô hình AI lớn, và cũng có thể bao gồm giới hạn số lần thử cùng mức độ song song

Chỉ số giúp tự chủ đáng tin hơn đôi chút

• Chỉ xác định chỉ số sau khi sự việc đã xảy ra có thể là chưa đủ
• Chỉ số có thể được chuẩn bị trước trong một tài liệu ngắn gọn và giúp mức tự chủ trở nên đáng tin hơn
• Ví dụ về các chỉ số có thể theo dõi theo từng mức tự chủ gồm
  • thời gian trung bình giữa các lần can thiệp
  • thời gian chạy không người giám sát dài nhất theo tiêu chí công việc được chấp nhận
  • tỷ lệ hành động được thực hiện trong sandbox so với hành động bị escalate
  • tỷ lệ hành động được auto-approve so với bị từ chối
  • số hành động trung bình của tác nhân trên mỗi chỉ thị của con người
  • tỷ lệ yêu cầu làm rõ
  • tỷ lệ yêu cầu ngắt
  • thời gian review trên mỗi thay đổi được chấp nhận
  • tỷ lệ làm lại theo từng mức độ tin cậy
  • tỷ lệ lọt lỗi theo từng mức độ tin cậy
  • chi phí token trên mỗi thay đổi được chấp nhận
• Một tác nhân đơn luôn bận rộn với các công việc do con người chuyền sang thì gần với Level 4 có gắn dashboard hơn, còn một tác nhân bảo thủ với intake tự động, retry, và không tiến lên nếu thiếu bằng chứng đầy đủ thì gần với Level 5 có cổng kiểm soát thực sự hơn

Chọn mức tự chủ theo độ sẵn sàng

• Công việc nên được phân loại theo rủi ro và mức độ có thể hoàn tác
• Tự chủ nên được áp dụng một cách bảo thủ, và chỉ tăng khi có thêm bằng chứng ủng hộ mức cao hơn
• Refactor payment engine với test mạnh, reviewer agent, và đường rollback sạch có thể hỗ trợ mức tự chủ cao hơn so với công việc tự động hóa tài liệu không có chuẩn đáp án
• Mức tự chủ nên đi theo quy trình kiểm chứng chứ không phải tên gọi của công việc

Bốn anti-pattern của tự chủ

• Autonomy as status

  • Mức xếp hạng tự chủ của tác nhân hoạt động như một huy hiệu địa vị vô nghĩa
  • Tự chủ cao bị xem như bằng chứng năng lực chứ không phải an toàn, và tác nhân được chạy ở mức mà kiểm chứng không thể hậu thuẫn
  • Cần khen thưởng và ghi nhận những người chọn đúng mức tự chủ và không vượt ranh giới

• Permission laundering

  • Vì mệt mỏi khi phê duyệt mà tác nhân AI và công cụ được cấp quyền truy cập rộng hơn mức cần thiết
  • Cần củng cố ranh giới như sandbox profile, root ghi có phạm vi giới hạn, danh sách lệnh được phép, hook, và Auto-review

• Summary substitution

  • Bản tóm tắt công việc của tác nhân thay thế cho review
  • Cần đóng gói cùng một bộ bằng chứng như review thủ công
  • Có thể bao gồm diff, test, log, ảnh chụp màn hình, phát hiện của reviewer, rủi ro và khoảng trống

• Fleet cosplay

  • Chạy song song hàng chục tác nhân nhưng con người vẫn phải tiếp tục điều phối thủ công mọi dependency
  • Trạng thái dùng chung, quy tắc sở hữu và theo dõi dependency tốt hơn sẽ giảm nhu cầu điều phối thủ công
  • Giới hạn WIP nhỏ hơn có thể buộc nhóm tập trung vào việc mã hóa và ghi chép các bước điều phối, từ đó dẫn tới tự động hóa orchestration

Cách tăng cấp an toàn

• Một bài tập hiệu chỉnh được đề xuất là xem lại 10 công việc gần đây có sự hỗ trợ của tác nhân
  • mức tự chủ của từng công việc
  • rủi ro
  • mức độ dễ hoàn tác
  • bằng chứng được tạo ra để đáp ứng yêu cầu kiểm chứng
  • thời gian review
  • có phải làm lại hay không
  • liệu lần sau cùng mức tự chủ đó còn phù hợp không
• Nên tăng từng trục một tại mỗi thời điểm
• Điểm khởi đầu là một supervised agent đơn lẻ thực hiện một tác vụ bị giới hạn và tạo ra bằng chứng thành công có thể bảo vệ được
• Sau đó mở rộng dần theo ba hướng
  • song song hóa các công việc khám phá thiên về đọc
  • thêm các write agent trong worktree riêng với quy tắc sở hữu file bị giới hạn
  • thêm tự động hóa lặp lại, rồi thêm orchestration do tác nhân dẫn dắt dựa trên issue hoặc âm thanh
• Mỗi lần tăng cấp đều đòi hỏi hàng rào an toàn mới để đối phó với chế độ lỗi mới
• Các chế độ lỗi gồm
  • chạy một tác nhân đơn quá dài: drift, hỏng ngữ cảnh, bỏ sót giao tiếp, lệch mục tiêu
  • công việc nền: giả định cũ, bàn giao yếu
  • quá nhiều công việc song song: merge conflict, quyết định trùng lặp
  • quá nhiều công việc lặp: âm thầm tiêu token, prompt lỗi thời
  • managed-by-exception: hàng review dài, mệt mỏi vì thông báo
• Không phải bằng cách tin mạnh hơn, mà bằng cách thu hẹp phạm vi, có bằng chứng tốt hơn, tạo đường rollback rẻ hơn, siết chặt gate, và làm rõ hơn các quy tắc sở hữu

Nơi phù hợp để dùng từng cấp

• Level 0 phù hợp nhất với công việc tinh tế và những tình huống mà con người vẫn đang hình thành nhận định
• Level 1 phù hợp với hầu hết hoạt động khám phá gần các ranh giới đã hiểu rõ
• Level 2 phù hợp với phần lớn tác vụ bị giới hạn nơi có thể tồn tại dependency chưa biết và vấn đề bất ngờ
• Level 3 phù hợp khi có thể diễn đạt điều kiện thành công đủ rõ
• Level 4 phù hợp khi có thể chia công việc gọn gàng theo các điều kiện thành công
• Level 5 phù hợp sau khi việc điều phối và giao tiếp cần thiết giữa nhiều điều kiện thành công đã được mã hóa hoàn toàn

Kiểm chứng vẫn tiếp tục là nút thắt

• Bất chấp mức tự tin và công cụ hiện tại, tư thế của các đội ngũ kỹ thuật trưởng thành khi làm việc với tác nhân AI vẫn là calibrated autonomy
• Trong tương lai gần, cần thiết kế các loop biết khi nào nên làm việc, khi nào nên kiểm chứng, và khi nào nên đặt câu hỏi
• Năng lực của kỹ sư vẫn nằm ở việc chọn mức tự chủ phù hợp, rồi tạo ra các mẫu và bằng chứng có thể bảo vệ được để ngăn mặt tối của nó