Một coding agent biết mở pull request thì hữu ích. Nhưng một coding agent có thể merge pull request đó trong lúc không ai theo dõi lại là một mối hiểm họa đang nắm quyền commit. Khoảng cách giữa hai câu đó chính là toàn bộ vấn đề. Một khi agent có thể push lên branch, chạy test và bấm merge, câu hỏi không còn là "nó có làm được việc không" mà trở thành "quyền hạn của nó dừng ở đâu".
Phần lớn các đội ngũ trả lời câu hỏi đó một cách tình cờ. Agent có đủ mọi quyền mà môi trường chạy cấp cho nó, việc review diễn ra ở bất kỳ terminal nào khởi chạy lần chạy đó, và hồ sơ về việc ai đã phê duyệt cái gì chỉ nằm trong lịch sử cuộn màn hình của một người. Cách làm đó chỉ trụ được cho đến khi bạn chạy ba agent trên hai repository và một lần deploy ngày thứ Sáu tung ra thứ mà không ai đọc. Cổng phê duyệt (approval gate) chính là giải pháp, nhưng chỉ khi nó là một điểm kiểm soát thực sự trong một hệ thống dùng chung, chứ không phải một thói quen mà bạn hy vọng mọi người đều tuân thủ.
Sharkly chính là hệ thống dùng chung đó. Bạn đã có coding agent; Sharkly biến các lần chạy của chúng thành Task với trạng thái, Assignee và một bước review mà con người phải chủ động thực hiện. Bài viết này sẽ đi qua mô hình vận hành đằng sau đó: ai giao việc, ai chạy, ai review, ai nghiệm thu, và chính xác điểm dừng nằm ở đâu để agent không bao giờ tự merge thay đổi của mình khi chưa được review.
Approval gate thực chất là gì
Approval gate là một điểm trong vòng đời của task mà tại đó quá trình thực thi tự động dừng lại và chờ một người quyết định bước tiếp theo. Không phải một cảnh báo, cũng không phải một dòng log mà bạn có thể cuộn qua: đó là một trạng thái mà công việc nằm yên trong đó cho đến khi con người chuyển nó đi.
Điều quan trọng nhất cần phân biệt là giữa việc agent đề xuất một thay đổi và việc agent đưa thay đổi đó vào thực tế. Mở một pull request là đề xuất. Merge nó là quyết định liên quan đến production. Đó là hai hành vi quyền hạn khác nhau, và hành vi thứ hai chính là nơi phán đoán của đội ngũ phải hiện diện. Sharkly làm rõ ranh giới đó: ngay cả khi đã kết nối GitHub, việc merge pull request cũng không làm thay đổi trạng thái Task. Việc merge vẫn là một hành động của con người được ghi vào hồ sơ, chứ không phải hệ quả phụ mà agent kích hoạt khi hoàn thành.
Hãy ghi nhớ ranh giới đó, vì phần lớn câu chuyện "agent làm sập prod" thực chất là câu chuyện về một cổng kiểm soát bị thiếu giữa lúc đề xuất và lúc đưa vào thực tế.
Mô hình vận hành: giao việc, chạy, review, nghiệm thu
Sharkly chia một task thành bốn vai trò, mỗi vai trò một nhiệm vụ. Nguyên tắc rất rõ ràng: Agent nghiên cứu, thực thi, kiểm thử và báo cáo; Con người định hướng, cấp quyền và nghiệm thu kết quả.
- Giao việc. Một người mô tả nhu cầu và chỉ định Assignee. Mỗi Task mang hai loại chỉ định riêng biệt: những Người tham gia, và một Assignee thực thi duy nhất — chính là Agent hoặc Crew đảm nhận công việc. Thay đổi cái này không làm thay đổi cái kia.
- Chạy. Assignee thực thi làm việc trong một git worktree biệt lập, nên các lần chạy song song không đụng vào file của nhau. Tiến độ, vướng mắc và kết quả đều được đưa trở lại Task.
- Review. Khi Agent hoàn thành, nó để Task ở trạng thái chờ con người review thay vì tự đóng. Diff, kết quả test và bản tóm tắt thay đổi được đính kèm vào Task, chứ không nằm trong terminal.
- Nghiệm thu. Một người đọc bằng chứng và quyết định: yêu cầu chỉnh sửa, hoặc chấp nhận và merge. Nghiệm thu là bước cuối cùng, và chỉ con người mới thực hiện được bước này.
Giá trị ở đây không nằm ở việc Sharkly chạy agent. Mà là bốn vai trò luôn hiển thị ở một nơi duy nhất, thay vì tan biến vào cái terminal nào đó tình cờ đang mở. Để tìm hiểu sâu hơn về nửa phần review, xem human-in-the-loop coding agents.
Biến cổng kiểm soát thành một trạng thái, không phải một thói quen
Một cổng mà bạn phải ghi nhớ là một cổng mà cuối cùng bạn sẽ bỏ qua. Vì vậy hãy mã hóa nó vào vòng đời của task.
Các trạng thái của Sharkly mang ý nghĩa hệ thống thông qua các nhóm của chúng. Backlog là trạng thái lưu trữ: một Task nằm đó sẽ không thực thi kể cả khi đã được giao cho Agent. Chuyển nó sang nhóm sẵn sàng làm việc mới cho phép quá trình thực thi bắt đầu. Completed là trạng thái kết thúc, và việc đạt tới đó là hành động của con người, không phải điều mà Agent tự ban cho mình.
Trạng thái Task được tách biệt có chủ đích khỏi trạng thái làm việc của Agent. Trong khi trạng thái vòng đời hiển thị In Progress, thì Agent bên dưới có thể đang làm việc, đang chờ con người phản hồi, đang chờ con người review, hoặc đang báo lỗi. Sự tách biệt đó chính là cổng kiểm soát: Agent có thể kết thúc lần chạy và hiển thị "đang chờ con người review" mà Task không hề chuyển sang một trạng thái ngụ ý rằng nó đã được đưa vào production. Công việc quay trở lại Task và dừng ở đó cho đến khi có người nghiệm thu.
Đây cũng là điều giúp chạy nhiều agent cùng lúc một cách an toàn. Khi năm parallel agents in isolated worktrees đều đổ về cùng một cột review, bạn có một nơi để phân loại chúng thay vì phải trông chừng năm terminal.
Một ví dụ cụ thể: từ ticket đến PR đã merge
Hãy cùng đi qua một Task duy nhất, dùng dạng mã định danh SH-312 của Sharkly.
- Tạo ticket. Một người tạo
SH-312, một task bug: "Tìm kiếm trả về kết quả cũ sau khi thay đổi filter." Phần mô tả gồm mục tiêu, cách tái hiện lỗi và tiêu chí nghiệm thu. Assignee: một Claude Code Agent gắn với repository tìm kiếm. - Định hình. Agent nghiên cứu codebase và lịch sử liên quan, xác nhận phạm vi, rồi đăng kế hoạch của mình trở lại Task. Người phụ trách đọc kế hoạch và chuyển
SH-312ra khỏi Backlog sang trạng thái sẵn sàng — đó chính là tín hiệu để bắt đầu. - Chạy. Agent nhận Task và làm việc trong một worktree mới. Nó viết bản sửa lỗi, chạy typecheck và bộ test, rồi mở một pull request có tiêu đề chứa
SH-312để Sharkly liên kết PR trở lại Task. - Dừng tại cổng kiểm soát. Agent không merge. Nó đính kèm bản tóm tắt thay đổi, kết quả test đã pass và mọi giới hạn đã biết, rồi để
SH-312chờ con người review. Công việc đã quay trở lại Task. - Review. Một người mở
SH-312, đọc diff và bằng chứng trong cùng một giao diện, và nhận ra bản sửa lỗi có đụng đến một query helper dùng chung. Họ để lại bình luận yêu cầu một thay đổi hẹp hơn. Với một Task có Agent Assignee đang sẵn sàng, bình luận đó sẽ đưa lần chạy vào hàng đợi trở lại, nên vòng lặp yêu cầu chỉnh sửa vẫn được ghi nhận thay vì phải bắt đầu lại trong một cuộc trò chuyện riêng. - Nghiệm thu và merge. Lần chạy thứ hai vượt qua review. Người phụ trách phê duyệt pull request, merge nó, và chuyển
SH-312sang Completed. Vì việc merge không tự động đóng Task, nên nghiệm thu và merge là hai quyết định của con người được ghi nhận riêng biệt, chứ không phải một chuỗi tự động.
Mọi bước trong chuỗi đó đều có thể tra cứu lại sau này, đó chính là mục đích của một traceable requirements-to-code workflow: bạn có thể trả lời câu hỏi "ai đã phê duyệt cái này, và dựa trên bằng chứng nào" mà không cần đào bới lịch sử cuộn màn hình của ai đó.
Không nên đặt cổng kiểm soát ở đâu
Nhiều cổng hơn không tự động an toàn hơn; chúng tạo thêm ma sát, khiến mọi người quen tay bấm qua. Hãy đặt cổng ở nơi mà cái giá của một lần merge sai là có thật. Với một thay đổi nhỏ, được xác định rõ ràng và ít rủi ro, giao cho một Agent duy nhất, thì điểm dừng review-trước-khi-merge là đủ, và bạn không cần thêm Crew hay các bước phê duyệt bổ sung chồng lên. Hãy tăng cường review khi phạm vi ảnh hưởng lớn: code dùng chung, migration, hay bất cứ thứ gì liên quan đến auth hoặc billing.
Cổng duy nhất bạn không bao giờ được bỏ là cổng merge. Agent có thể nghiên cứu, viết, test và đề xuất cả ngày. Việc thay đổi của nó có đi vào main branch hay không là quyết định của con người, và nên giữ nguyên như vậy kể cả khi Agent đúng trong phần lớn trường hợp. Hãy kết hợp review ở cấp task của Sharkly với branch protection sẵn có để nền tảng thực thi đúng như quy trình mong muốn, và giữ nguyên những công cụ mà đội bạn đang dùng: kết nối GitHub và assign the ticket to an AI agent mà không cần xây lại quy trình.
Nếu bạn đang chạy nhiều coding agent và không theo dõi nổi cái nào đã xong, cái nào thất bại, cái nào đang chờ bạn, thì cột review đó chính là lý do để thử Sharkly. Hãy cho các agent hiện có của bạn chạy qua đó và giữ quyết định merge ở đúng nơi nó thuộc về.
Câu hỏi thường gặp
Sharkly có thể ngăn agent tự merge không? Có. Việc merge pull request không làm thay đổi trạng thái Task trong Sharkly, nên một lần chạy kết thúc ở trạng thái "chờ con người review" thay vì đưa thay đổi vào thực tế. Hãy kết hợp điều này với branch protection của GitHub để bắt buộc review ở cấp repository.
Trạng thái task và trạng thái agent khác nhau thế nào? Trạng thái task là nhóm trong vòng đời (Backlog, Started, Completed, v.v.). Trạng thái agent là việc lần chạy đang làm gì ngay lúc này: đang làm việc, đang chờ con người phản hồi, đang chờ review, hoặc lỗi. Một Task có thể nằm ở In Progress trong khi Agent đang chờ bạn.
Tôi có cần Crew cho mọi task được review không? Không. Với công việc nhỏ, phạm vi rõ ràng, hãy giao Task cho một Agent và dùng cổng review-trước-khi-merge. Chỉ dành Crew cho mục tiêu cần một leader Agent điều phối nhiều thành viên.
