Hầu hết các quy trình làm việc đa agent (multi-agent workflows) không thất bại ở những khâu khó khăn nhất. Agent vẫn viết mã, chạy kiểm thử và mở pull request đều đặn. Chúng thường gãy ở mắt xích chuyển giao: khoảnh khắc công việc rời khỏi một agent và được kỳ vọng sẽ chuyển tiếp đến nơi tiếp theo. Một backend Agent xây dựng xong endpoint nhưng frontend Agent chẳng hề hay biết nó đã sẵn sàng. Một nhánh refactor được đẩy lên worktree và nằm im lìm ở trạng thái pass xanh rì, chỉ vì không có lập trình viên nào được thông báo để vào kiểm tra. Bản thân tác vụ không hề hỏng. Thứ bị gãy chính là khâu bàn giao (handoff).
Bàn giao giữa các AI agent (agent handoff) là quá trình chuyển giao một phần công việc cùng ngữ cảnh của nó từ nhân sự này sang nhân sự tiếp theo: giữa agent với agent, hoặc giữa agent với con người. Khi bạn chỉ chạy một coding agent duy nhất trong một terminal, khâu bàn giao dường như vô hình vì thực chất chẳng có gì để bàn giao. Nhưng ngay khoảnh khắc bạn vận hành từ hai agent trở lên, hoặc một agent cùng một người review, mỗi bước hoàn thành đều phải được đưa về một điểm tập kết để người tiếp theo có thể dễ dàng tiếp nhận. Điểm tập kết đó chính là mấu chốt quyết định toàn bộ cuộc chơi.
Bài viết này sẽ đi sâu vào các mô hình bàn giao đã được kiểm chứng trong thực tế, lấy Sharkly làm quy trình mẫu: một lớp điều phối nằm trên các coding agent giúp minh bạch hóa ngữ cảnh, tiến độ, các điểm nghẽn (blocker), kết quả đầu ra và khâu review của con người từ lúc tiếp nhận yêu cầu cho đến khi phát hành. Bạn vốn đã có các coding agent. Vấn đề mà bài viết này giải quyết chính là những gì diễn ra ở khoảng trống giữa chúng.
Tóm tắt nhanh
Bàn giao là quá trình công việc và ngữ cảnh liên quan được luân chuyển từ người thực hiện này sang người thực hiện tiếp theo. Quá trình bàn giao giữa agent với agent sẽ chuyển tiếp một sub-task đã hoàn thành sang cho agent kế tiếp; trong khi bàn giao từ agent sang con người sẽ tạm dừng quá trình tự trị tại một cổng kiểm duyệt (review gate). Hãy minh bạch hóa cả hai luồng này bằng các trạng thái rõ ràng: Agent chuyển Task sang Ready for review, Con người chuyển Task sang Done. Khi việc bàn giao được định nghĩa bằng một lần đổi trạng thái trên một Task chung thay vì một tin nhắn trôi nổi trong terminal, sẽ không có đầu việc nào bị bỏ sót trong im lặng.
Bản chất thực sự của việc bàn giao giữa các agent
Một quy trình bàn giao hoàn chỉnh gồm ba thành phần, và việc thiếu sót bất kỳ phần nào cũng sẽ khiến công việc bị thất lạc: sản phẩm đầu ra (diff, PR, file migration), ngữ cảnh (yêu cầu ban đầu là gì, những gì đã thay đổi, những điểm nào còn chưa chắc chắn) và người nhận (chính xác agent hoặc cá nhân chịu trách nhiệm cho bước tiếp theo).
Các quy trình làm việc dựa trên terminal chỉ giữ lại được sản phẩm đầu ra mà làm rơi mất hai yếu tố còn lại. Commit thì có đó, nhưng lý do đưa ra quyết định lại nằm trong bộ đệm cuộn trang (scrollback buffer) mà chỉ duy nhất một agent từng thấy, còn "ai làm tiếp theo" lại phụ thuộc vào việc ai tình cờ vào kiểm tra. Đó là lý do tại sao việc điều phối agent không đơn thuần là khởi chạy chúng, mà cốt lõi là định tuyến những gì chúng tạo ra.
Một quy trình bàn giao chuẩn mực phải chuyển tiếp đồng thời cả ba thành phần: phần thay đổi, bản tóm tắt những gì đã làm và chưa làm, cùng một tín hiệu dứt khoát rằng đã đến lượt người nhận tiếp theo xử lý. Với Sharkly, toàn bộ quá trình thực thi, điểm nghẽn, kết quả và các thảo luận tiếp nối đều được ghi nhận trực tiếp vào timeline của Task, giúp người tiếp nhận chỉ cần đọc một bản ghi duy nhất thay vì phải chắp vá thông tin từ ba nơi khác nhau.
Hai mô hình bàn giao phổ biến
Hai mô hình này thoạt nhìn có vẻ tương đồng nhưng lại có cơ chế mặc định hoàn toàn trái ngược. Bàn giao giữa agent với agent nên diễn ra tự động: Agent tiếp theo sẽ nhận sub-task đã sẵn sàng và tiếp tục công việc. Ngược lại, bàn giao giữa agent với con người theo mặc định phải tạm dừng: Agent hoàn thành phần việc của mình và đứng chờ, bởi vì quyết định cuối cùng phải thuộc về con người.
| Agent-to-agent | Agent-to-human | |
|---|---|---|
| Thời điểm kích hoạt | Một sub-task được đánh dấu là sẵn sàng | Công việc chạm đến cổng kiểm duyệt |
| Cơ chế mặc định | Tiếp tục tự động | Tạm dừng và chờ đợi |
| Thông tin chuyển giao | Sản phẩm đầu ra + ngữ cảnh + tiêu chí nghiệm thu | Diff + tóm tắt thay đổi + các giới hạn đã biết |
| Rủi ro nếu thiếu sót | Công việc bị trùng lặp hoặc xung đột | Code chưa qua kiểm duyệt bị merge mù quáng |
Dưới đây là nguyên tắc giúp bạn đưa ra quyết định chuẩn xác. Hãy tự động hóa khâu bàn giao giữa agent với agent khi bước tiếp theo đã được định nghĩa rõ ràng và có sẵn các tiêu chí nghiệm thu: “chạy bộ kiểm thử (test suite)”, “tạo file migration”, “cập nhật OpenAPI spec”. Ngược lại, bắt buộc phải bàn giao từ agent sang con người khi bước kế tiếp đòi hỏi sự đánh giá mà agent không thể tự chịu trách nhiệm: merge vào nhánh main, thay đổi public contract, động chạm đến module xác thực (auth) hoặc thanh toán (billing), hay phê duyệt kết quả cuối cùng.
Sai lầm thường gặp là đối xử với mọi khâu bàn giao như nhau. Nếu tự động hóa toàn bộ, bạn sẽ vô tình merge những đoạn code chưa từng được ai xem qua; nhưng nếu bước nào cũng dựng cổng kiểm duyệt, bạn sẽ vô tình tái lập một quy trình thủ công chậm chạp với hàng đống thủ tục rườm rà. Điều này liên quan mật thiết đến việc biết đặt cổng phê duyệt ở đâu để các agent dừng lại trước những sai lầm tai hại, chứ không phải sau mỗi tác vụ nhỏ nhặt tầm thường.
Trạng thái biến khâu bàn giao thành cổng kiểm soát, không phải sự trông chờ may rủi
Mô hình vận hành này gói gọn trong bốn động từ và người chịu trách nhiệm cho từng khâu: ai giao việc, ai thực thi, ai review, ai nghiệm thu. Các agent sẽ nghiên cứu, thực thi, kiểm thử và báo cáo. Con người sẽ định hướng, phân quyền và nghiệm thu kết quả. Tự động hóa phải dừng lại ở những nơi cần đến phán đoán chuyên môn của cả đội ngũ.
Các trạng thái (status) chính là cách biến cam kết đó thành cơ chế vận hành chính xác thay vì chỉ là kỳ vọng viển vông. Mọi Task đều đi qua cùng một quy trình:
- Todo: Đã được giao, chưa bắt đầu. Do con người hoặc một leader Agent đưa vào đây.
- In progress: Một Agent đã nhận việc và đang xử lý trong một worktree biệt lập.
- Ready for review: Ranh giới của Agent. Nó đã chạy typecheck, kiểm thử và build thành công, đính kèm tóm tắt thay đổi cùng các giới hạn đã biết, rồi dừng lại.
- Done: Ranh giới của con người. Ai đó đã nghiệm thu kết quả và đưa ra quyết định merge cũng như phát hành.
Quy tắc vàng giúp toàn bộ hệ thống trở nên rõ ràng, minh bạch: Agent chuyển Task sang Ready for review; Con người chuyển Task sang Done. Một Agent không bao giờ được tự ý đánh dấu công việc của mình là Done, và con người cũng không bao giờ phải phỏng đoán xem một Task pass xanh liệu có an toàn hay không. Bản thân trạng thái chính là sự bàn giao. Khi có mười agent đang chạy song song, bạn không cần phải soi từng dòng lệnh trên mười màn hình terminal; bạn chỉ cần nhìn vào bảng quản lý (board) là biết chính xác điều gì đang chờ bạn xử lý, điều gì đang chờ agent khác, và điều gì vẫn đang được thực thi. Khả năng quan sát trực quan đó tạo nên sự khác biệt giữa việc theo dõi những gì agent đã hoàn thành với việc chỉ biết phó mặc cho commit log giải thích mọi chuyện sau này.
Ví dụ thực tế: Từ ticket yêu cầu đến PR được merge
Hãy xét một Task thực tế, mã SH-312: “Thêm giới hạn tốc độ gọi (rate limiting) cho public API”. Hãy chú ý đến các điểm bàn giao, thay vì chi tiết mã nguồn.
Một kỹ sư mô tả nhu cầu bằng ngôn ngữ tự nhiên và giao việc. Một leader Agent sẽ nghiên cứu codebase cùng lịch sử các task trước đây, viết phạm vi công việc và tiêu chí nghiệm thu (giới hạn theo từng API key, trả về mã 429 kèm header Retry-After, áp dụng cho ba endpoint có lưu lượng lớn nhất), rồi chia nhỏ SH-312 thành ba sub-task có thể thực thi độc lập. Đó chính là lần bàn giao giữa agent với agent đầu tiên: đầu vào là mục tiêu, đầu ra là các sub-task sẵn sàng triển khai.
Các sub-task được luân chuyển một cách tự động. Một backend Agent nhận phần logic giới hạn tốc độ; một test Agent nhận viết test coverage. Vì mỗi agent hoạt động trong một worktree biệt lập, chúng không bị xung đột trên cùng các tệp tin, và kết quả của từng bên đều được đồng bộ về SH-312 thay vì nằm cục bộ ở phiên làm việc riêng. Khi backend Agent hoàn tất, nó không cần ping con người; nó chỉ cần đánh dấu sub-task của mình là sẵn sàng, và test Agent sẽ lập tức tiếp nhận phần triển khai thực tế thay vì phải dùng mã giả lập (stub).
Sau đó, kiểu bàn giao sẽ đổi hướng. Khi bộ giới hạn tốc độ đã được xây dựng, typecheck không có lỗi, kiểm thử vượt qua và bản build báo xanh, công việc sẽ chạm đến cổng chuyển giao từ agent sang con người. Agent chuyển SH-312 sang Ready for review, đồng thời đính kèm diff, bản tóm tắt thay đổi và một giới hạn đã biết: “Bộ đếm dựa trên Redis hiện chỉ giả định chạy trên một region duy nhất; việc hỗ trợ multi-region cần được xử lý trong một task tiếp theo”. Kỹ sư phụ trách chỉ cần đọc thông tin tập trung tại một nơi, kiểm tra hành vi trả về mã 429, rồi chuyển task sang Done để kích hoạt lệnh merge. Từ một ticket ban đầu trở thành PR được merge trọn vẹn, với đầy đủ nhật ký ghi rõ ai đã làm gì ở từng mắt xích. Đây chính là cách truy vết liền mạch từ yêu cầu đến mã nguồn trong toàn bộ quy trình.
Những điểm dễ gãy trong khâu bàn giao và cách khắc phục
Khâu bàn giao thường đổ vỡ theo ba kịch bản quen thuộc, và mỗi vấn đề đều cần một giải pháp mang tính cấu trúc thay vì dựa vào việc "cố mà nhớ".
Ngữ cảnh bị bốc hơi. Agent nắm rõ lý do nó đưa ra một lựa chọn kiến trúc; nhưng người review thì không. Giải pháp: việc bàn giao phải bắt buộc mang theo bản tóm tắt thay đổi và các giới hạn đã biết như một phần của hành động chuyển sang Ready for review, chứ không phải một điều bổ sung tùy hứng. Trách nhiệm bị mập mờ. Hai agent cùng nhảy vào tranh nhau một việc, hoặc chẳng có agent nào đoái hoài. Giải pháp: thiết lập trường Assignee (người được giao) rõ ràng trên mọi Task và sub-task, để “đến lượt bạn” là một trường dữ liệu cụ thể, không phải sự phỏng đoán cảm tính. Khâu review bị bỏ quên. Code tự động sinh ra được merge thẳng vào hệ thống chỉ vì không ai yêu cầu dừng lại. Giải pháp: đặt ra một trạng thái mà agent không thể tự ý vượt qua.
Bạn hoàn toàn có thể tự dựng tất cả những điều này bằng Git worktrees, quy ước đặt tên và tính kỷ luật. Cách đó vẫn hiệu quả cho đến khi số lượng agent, task và repository tăng vọt — lúc đó tính kỷ luật sẽ là thứ đầu tiên bị phá vỡ. Nếu bạn đang vận hành nhiều agent cùng lúc, Sharkly mang đến một không gian tập trung để quản lý toàn bộ task và kết quả của chúng: các Task dùng chung, gán Assignee theo từng Task, các worktree biệt lập và một quy trình trạng thái rõ ràng, nơi Agent chỉ dừng ở Ready for review còn Con người nắm quyền quyết định Done. Hãy tiếp tục sử dụng các coding agent quen thuộc của bạn; chỉ cần bổ sung thêm lớp điều phối giúp các khâu bàn giao trở nên minh bạch và trực quan. Tải Sharkly ngay khi những điểm nối giữa các agent bắt đầu tiêu tốn nhiều chi phí hơn cả bản thân công việc.
Câu hỏi thường gặp (FAQ)
Bàn giao giữa các AI agent (AI agent handoff) là gì? Đó là quá trình chuyển giao một nhiệm vụ, cùng với ngữ cảnh và tín hiệu thông báo đã đến lượt người tiếp theo xử lý, từ nhân sự này sang nhân sự khác. Hai hình thức chính gồm agent-to-agent (một sub-task hoàn thành được chuyển tiếp cho agent tiếp theo) và agent-to-human (quá trình làm việc tự trị tạm dừng tại cổng kiểm duyệt).
Sự khác biệt giữa bàn giao agent-to-agent và agent-to-human là gì? Bàn giao giữa agent với agent nên tiếp tục một cách tự động khi các tiêu chí nghiệm thu của bước tiếp theo đã được xác định rõ ràng. Còn bàn giao từ agent sang con người bắt buộc phải dừng lại và chờ đợi, bởi vì con người cần đưa ra những đánh giá mang tính chuyên môn: merge code, thay đổi public contract, hoặc chính thức nghiệm thu kết quả.
Agent có nên tự đánh dấu công việc của mình là hoàn thành (Done) không? Không. Hãy để Agent chuyển Task sang trạng thái Ready for review sau khi đã chạy kiểm thử và đính kèm bản tóm tắt; hãy dành quyền chuyển sang Done và quyết định merge cho con người. Việc phân định rõ hai ranh giới này chính là chốt chặn ngăn chặn mã nguồn chưa qua kiểm duyệt bị đưa lên production. Tham khảo thêm về mô hình coding agent có sự tham gia của con người (human-in-the-loop).
Các trạng thái (status) giúp ngăn ngừa việc sót việc như thế nào? Khi khâu bàn giao được thể hiện bằng sự thay đổi trạng thái trên một Task chung thay vì một tin nhắn trôi nổi trong terminal, người thực hiện tiếp theo sẽ thấy rõ chính xác những gì đang chờ họ xử lý. Không còn việc phụ thuộc vào việc ai đó phải để mắt đúng lúc tới dòng log cuộn trong terminal. Một hộp thư đến cho agent (agent Inbox) sẽ tự động làm nổi bật các đầu việc đang cần bạn xử lý.
Tôi có cần một công cụ chuyên biệt cho việc này không, hay có thể làm thủ công? Bạn hoàn toàn có thể triển khai thủ công bằng Git worktrees và một bảng theo dõi chung. Tuy nhiên, một tầng điều phối chuyên dụng sẽ thực sự phát huy giá trị khi bạn phải phối hợp nhiều agent trên nhiều repository khác nhau và việc theo dõi thủ công trở thành nút thắt cổ chai. Hãy đối chiếu mô hình tư duy: trợ lý AI so với đồng đội AI để đưa ra quyết định phù hợp.
