Câu trả lời nhanh: Để AI agent review pull request, hãy giao việc review cho một agent thứ hai với bộ hướng dẫn riêng, bản checkout riêng và nếu có thể, hãy dùng một model khác. Hãy kích hoạt agent này tự động khi công việc chuyển sang trạng thái cần review, yêu cầu nó chạy test rồi đưa ra kết luận PASS hoặc CHANGES REQUIRED, đồng thời chuyển các lỗi phát sinh ngược lại cho builder agent. Quyền merge cuối cùng vẫn thuộc về con người.
Tại sao nên để AI agent review pull request trước khi bạn xem xét
Mọi pull request do agent tạo ra cuối cùng đều đổ dồn về một nơi: bàn làm việc của bạn. Khi chỉ có một agent tạo một PR mỗi giờ, mọi chuyện vẫn ổn thỏa. Nhưng khi có năm agent chạy song song, hàng đợi sẽ phình to nhanh hơn tốc độ đọc diff của bạn, và lượt rà soát đầu tiên (first pass) sẽ trở thành điểm nghẽn cổ chai.
Một reviewer agent sẽ đảm nhận lượt rà soát đầu tiên đó. Nó không thay thế nhận định chuyên môn của bạn, mà giúp lọc bỏ những PR chạy test thất bại, đi chệch khỏi phạm vi yêu cầu hoặc để lộ secret, nhờ đó những PR đến tay bạn đều thực sự đáng bỏ thời gian. Trong Sharkly, bạn chỉ cần thiết lập việc này bằng một Agent bổ sung và hai Automation; phần còn lại của bài viết sẽ hướng dẫn chi tiết từng bước.
Nếu muốn tìm hiểu trước về giới hạn của việc review tự động, hãy đọc bài những gì AI code review agent có thể và không thể kiểm tra. Bài viết này sẽ tập trung vào phần thiết lập.
Tại sao một agent không thể tự review code của chính mình
Agent viết code cũng chính là kẻ dựng nên câu chuyện logic xoay quanh đoạn code đó. Khi bạn yêu cầu nó kiểm tra lại sản phẩm của chính mình, nó chỉ đọc lại lập luận của bản thân và gật đầu đồng ý. Những điểm mù tạo ra bug ban đầu cũng chính là những điểm mù tham gia vào quá trình review.
Hiện tượng này thể hiện rõ nhất ở các bài test. Một builder khi không thể làm cho test pass có thể sẽ hạ thấp điều kiện assertion rồi báo cáo là đã xong việc. Chúng tôi đã phân tích các trường hợp này trong bài viết cách phát hiện coding agent gian lận bài test. Ngược lại, một reviewer hoàn toàn độc lập sẽ soi diff với cái nhìn khách quan và đặt ra câu hỏi khác: thay đổi này có làm đúng yêu cầu của nhiệm vụ và không thừa thãi bất cứ thứ gì hay không?
Bài viết thiết kế về super-agent của đội ngũ DeepSeek Harness cũng đưa ra cách phân chia tương tự: nhiều Worker cùng gắn vào một PR, theo dõi các sự kiện của PR đó và có thể tự giải quyết xung đột với nhau. Dù đây mới chỉ là bản thiết kế nguyên mẫu chứ chưa phải sản phẩm hoàn thiện, nhưng ý tưởng cốt lõi vẫn hoàn toàn chuẩn xác: việc review sẽ hiệu quả hơn hẳn khi người review là một bên độc lập.
Bước 1: Tách riêng builder và reviewer
Hãy tạo hai Agent riêng biệt, thay vì một Agent có hai chế độ hoạt động. Mỗi Agent sẽ có tập lệnh hướng dẫn, repository và mục tiêu thực thi (execution target) riêng.
| Builder Agent | Reviewer Agent | |
|---|---|---|
| Nhiệm vụ | Triển khai nhiệm vụ, tạo PR | Đánh giá PR dựa trên yêu cầu nhiệm vụ |
| Viết code | Có | Không |
| Đẩy code (Push) | Lên feature branch | Không bao giờ |
| Runtime | Ví dụ: Claude Code | Tốt nhất là một runtime khác, ví dụ: Codex |
| Kết quả đầu ra | Branch, PR, comment tóm tắt | Comment đưa ra kết luận (verdict) |
Sharkly Agent không có tùy chọn chọn model trực tiếp. Mục tiêu thực thi của nó là một Computer kết hợp với Runtime được phát hiện trên Computer đó; do vậy, việc “dùng model khác” đồng nghĩa với việc gán reviewer cho một Runtime khác. Một Runtime thứ hai sẽ mang đến góc nhìn và thói quen đánh giá khác biệt cho bản diff. Chi phí cho mỗi lần chạy sẽ tính vào gói dịch vụ đã liên kết với Runtime đó, vì Sharkly không bán token.
Hãy thiết lập thư mục làm việc của reviewer sang chế độ Temporary (Tạm thời). Tài liệu về Computers giải thích rõ cách mỗi lần chạy nhận được một thư mục cô lập, và các tác vụ trên repository có thể chuẩn bị một Git worktree hoàn toàn mới. Nhờ đó, reviewer checkout nhánh PR trên bản sao riêng và không thể ghi đè hay làm hỏng các tệp của builder. Bài viết của chúng tôi về chạy agent song song trong các worktree cô lập đã giải thích lý do tại sao điều này lại quan trọng khi có nhiều agent cùng chia sẻ một repository.
Bước 2: Soạn thảo hướng dẫn cho reviewer
Hướng dẫn cho Agent (Agent instructions) bao gồm vai trò, các hạng mục cần kiểm tra và định dạng báo cáo. Các chi tiết cụ thể theo từng nhiệm vụ sẽ nằm trực tiếp ở task đó. Hãy giữ cho hướng dẫn của reviewer ngắn gọn và có thể kiểm chứng được:
You are the code reviewer for this Space. You never push, merge or edit files.
1. Read the triggering task. If it is not a code task in this Space, reply "not mine" and stop.
2. Find the linked pull request (the task ID appears in its title, description or branch).
3. Check out the PR branch in your worktree. Run the test command from the repo README.
4. Compare the diff to the task's acceptance criteria.
5. Post one verdict comment on the task in the format below. Nothing else.
Bước đầu tiên quan trọng hơn vẻ bề ngoài của nó. Hiện tại, các trigger theo trạng thái và trigger theo comment khớp trên phạm vi toàn bộ Organization, do đó phần hướng dẫn phải xác nhận đúng task trước khi thực hiện hành động. Tài liệu Automations đã chỉ rõ điều này.
Bước 3: Chọn cơ chế kích hoạt (trigger)
Sharkly Automation kết hợp các chỉ dẫn, một Agent hoặc Crew cùng với một hoặc nhiều trigger. Đối với quy trình review PR, có hai loại trigger phù hợp.
Thay đổi trạng thái task (Task status change). Hãy thêm một trạng thái như In Review vào quy trình làm việc trong Space của bạn. Builder sẽ chuyển task sang trạng thái này sau khi tạo PR, và reviewer sẽ bắt đầu chạy. Lượt chạy được kích hoạt theo trạng thái sẽ tạo một chuỗi hội thoại ngay trên task đó, giúp kết luận review và lượng token tiêu thụ luôn gắn liền với công việc.
Ảnh chụp màn hình đó chính là cánh cổng kiểm soát (gate) mà blog này áp dụng cho các bản nháp của mình: khi một task chuyển sang Ready for Release, một reviewer Agent sẽ tiếp nhận. Mô hình này hoàn toàn tương tự đối với mã nguồn.
Webhook. Nếu PR được tạo bên ngoài bảng nhiệm vụ (task board), hãy trỏ một pull_request webhook của GitHub tới webhook URL của Automation. Khi bật tính năng xác minh chữ ký (signature verification), Sharkly cũng chấp nhận header X-Hub-Signature-256 của GitHub, vì vậy bạn chỉ cần dán signing secret vào trường Secret của GitHub. Các lần chạy qua webhook không liên kết trực tiếp với task, do đó reviewer sẽ đưa ra nhận xét đánh giá ngay trên chính PR thông qua GitHub CLI.
Hãy kiểm thử cả hai phương thức bằng tính năng Run now trước khi đưa vào vận hành chính thức.
Bước 4: Cung cấp checklist kiểm tra cho reviewer
Một reviewer không có checklist sẽ viết như làm văn xuôi. Có checklist, nó sẽ chỉ tập trung vào các phát hiện cụ thể. Năm câu hỏi sau đây bao quát hầu hết các PR do agent tạo ra:
- Các bài test có chạy và pass không? Reviewer phải tự chạy test chứ không bao giờ tin vào bản tóm tắt của builder.
- Phạm vi có được đảm bảo không? Bất kỳ tệp nào bị chỉnh sửa ngoài phạm vi nhiệm vụ đều bị coi là vi phạm, ngay cả khi thay đổi trông có vẻ vô hại.
- Có bị lộ secret không? Kiểm tra token, key và các giá trị trong
.envxuất hiện ở diff hoặc trong log. - Có gây lỗi cho các nơi gọi đến (callers) không? Thay đổi signature hàm, xóa endpoint, hoặc migration thiếu phương án rollback.
- Bài test có bị làm suy yếu không? Xóa assertion, thêm skip mới hoặc nới lỏng các giá trị mong đợi (expected values).
Nếu có nhiều reviewer Agent cùng sử dụng checklist này, hãy lưu danh sách trong một Skill để chỉ cần một lần chỉnh sửa là cập nhật cho toàn bộ.
Bước 5: Cố định định dạng kết luận (verdict)
Một bản kết luận mà con người có thể lướt qua trong mười giây sẽ hiệu quả hơn nhiều so với một bài đánh giá dài dòng mà không ai thèm đọc. Hãy sử dụng một cấu trúc cố định:
VERDICT: CHANGES REQUIRED
Tests: 41 passed, 2 failed (test_refund_rounding, test_refund_zero)
Scope: OK, 3 files, all under billing/
Secrets: none found
Breaking changes: refund() now raises on amount=0; two callers in api/ not updated
Weakened tests: none
Required:
1. Handle amount=0 in refund() or update both callers.
2. Fix the rounding in test_refund_rounding; do not change the expected value.
Trường hợp PASS cũng sẽ có các trường tương tự nhưng danh sách Required để trống. Các trường cố định này cũng giúp các kết luận có thể đo lường và thống kê được: bạn có thể biết hạng mục nào thường xuyên thất bại nhất để thắt chặt chỉ dẫn của builder cho phù hợp.
Bước 6: Khép kín vòng lặp phản hồi cho builder
Kết luận CHANGES REQUIRED sẽ tự động kích hoạt builder chạy lại mà không cần bạn phải chuyển tiếp thông tin thủ công. Hãy tạo một Automation thứ hai, gán cho builder Agent, với trigger comment dựa trên một cụm từ đặc trưng.
Cơ chế khớp comment không phân biệt chữ hoa chữ thường và sẽ kích hoạt khi cụm từ xuất hiện ở bất cứ đâu trong comment. Hãy chọn một cụm từ không ai vô tình gõ vào, và chỉ dẫn reviewer chỉ viết cụm từ đó trên dòng CHANGES REQUIRED. Nếu builder trích dẫn lại cụm từ đó trong phản hồi của mình, nó có thể tự kích hoạt chính nó, vì vậy hãy yêu cầu nó không bao giờ lặp lại cụm từ đó.
Hãy giới hạn số vòng lặp. Sau hai vòng review và sửa đổi, reviewer sẽ chuyển giao task cho con người cùng với kết luận đánh giá cuối cùng.
Những phần việc con người vẫn nắm quyền quyết định
Bạn vẫn là người nắm quyền merge. Trong tích hợp GitHub của Sharkly, ID task trong tiêu đề PR sẽ liên kết PR với task tương ứng, và việc merge sẽ không làm thay đổi trạng thái của task. Không có đoạn code nào được đưa lên môi trường thực tế (ship) chỉ vì một agent nói PASS.
Hãy củng cố điều đó trên cả GitHub: thiết lập tính năng protected branches với yêu cầu phê duyệt bắt buộc từ con người, nhằm tránh việc một reviewer quá tự tin trở thành chốt chặn cuối cùng. Bạn cũng là người đưa ra các phán đoán mà checklist không thể làm được: liệu đây có phải thiết kế phù hợp và tính năng này có cần thiết phải tồn tại hay không? Để biết cách sắp xếp thứ tự ưu tiên những gì gửi đến bạn, hãy xem bài xếp hạng hàng đợi PR của agent và tại sao khâu review của con người lại là điểm nghẽn.
Lời kết
PR do agent tạo ra sẽ không còn ùn ứ trên bàn làm việc của bạn khi đã có một agent thứ hai đảm nhận lượt rà soát đầu tiên. Hãy tách riêng builder và reviewer, cấp cho reviewer worktree và Runtime riêng, kích hoạt nó qua trạng thái task hoặc webhook, và yêu cầu nó trả lời năm câu hỏi cố định theo một định dạng chuẩn. Trả lại kết quả thất bại qua cụm từ trigger trong comment, giới hạn vòng lặp ở mức hai vòng và giữ quyền merge cho chính bạn.
Nếu bạn đã vận hành mười coding agent cùng lúc, thì đây chính là mảnh ghép tiếp theo cần bổ sung. Bắt đầu miễn phí trên Sharkly và tạo reviewer Agent ngay hôm nay.
Câu hỏi thường gặp (FAQ)
AI agent có thể tự review pull request của chính nó không?
Hoàn toàn có thể, nhưng nó sẽ bỏ sót nhiều lỗi hơn. Agent đó mang sẵn những định kiến và giả định đã tạo nên đoạn code. Một reviewer độc lập với bộ chỉ dẫn riêng và lý tưởng nhất là một Runtime khác sẽ soi diff mà không bị ảnh hưởng bởi định kiến đó.
Reviewer có nên sử dụng model khác với builder không?
Nên, nếu bạn có thể. Trong Sharkly, model phụ thuộc vào Runtime, vì vậy hãy liên kết reviewer Agent với một Runtime khác so với builder, ví dụ để Codex review sản phẩm của Claude Code.
AI code reviewer nên kiểm tra điều gì đầu tiên?
Các bài test. Hãy yêu cầu nó tự chạy toàn bộ test suite và báo cáo số lượng test pass và fail. Tiếp đó là phạm vi thay đổi (scope), secret, breaking change và các bài test bị làm suy yếu, theo đúng thứ tự đó.
Reviewer agent có thể approve và merge PR không?
Đừng cho phép điều đó. Hãy giữ quyền merge cho con người thông qua thiết lập branch protection. Reviewer chỉ đưa ra comment kết luận; con người mới là bên quyết định.
Làm thế nào để ngăn vòng lặp review không chạy vô tận?
Hãy giới hạn tối đa hai vòng trong hướng dẫn của reviewer và sử dụng một cụm từ trigger trong comment mà builder không bao giờ lặp lại. Khi chạm giới hạn, reviewer sẽ chuyển giao task cho con người.
Cách này có hoạt động với các GitHub pull request được tạo bên ngoài Sharkly không?
Có. Hãy kết nối GitHub webhook với webhook trigger của một Automation. Sharkly sẽ chấp nhận signature header của GitHub khi bật chế độ xác minh.
