Issue của bạn vốn đã nằm trong GitHub. Mã nguồn, phần review pull request, và cả những quy tắc branch mà team bạn mất cả quý để thống nhất cũng vậy. Không ai muốn thêm một cái bảng thứ hai phải đồng bộ với cái bảng đầu tiên. Thứ còn thiếu là cách giao một trong những issue đó cho một coding agent và nhận lại một pull request có thể review, mà không cần rời khỏi repo gốc.
Đó chính là việc kết nối GitHub với Sharkly. Sharkly là nền tảng chỉ huy và quản lý Agent tất cả trong một: nó biến một issue trên GitHub thành một Task có thể gán, định tuyến đến một coding agent (Claude Code, Codex, Gemini, hay bất kỳ Runtime nào team bạn đang dùng), thực thi công việc trên một Computer bên trong một worktree biệt lập, rồi trả kết quả về dưới dạng pull request mà bạn review theo cách quen thuộc. Ở đây có hai điều quan trọng nhất: ai thực sự được phép chạm vào repository, và ở đâu con người vẫn phải gật đầu.
Toàn bộ vòng lặp gói gọn trong một câu
Kết nối GitHub, liên kết một repository với một Space, và một issue mới sẽ trở thành một Task. Gán nó cho một Agent thì cùng một "giao kèo" sẽ áp dụng ở mọi nơi trong Sharkly: Agent nghiên cứu, thực thi, kiểm thử và báo cáo; con người đọc diff và quyết định cái gì được đưa lên.
Hai kiểu kết nối, và vì sao chúng không phải là một
Tích hợp GitHub có hai tầng, và nhầm lẫn giữa chúng là cách nhanh nhất để rối tung lên về chuyện ai được thấy cái gì.
Tầng đầu tiên là kết nối organization. Một Organization Owner hoặc Admin mở Integrations, tìm GitHub, và cài GitHub App cho những repository mà nó được phép thấy. Chính kết nối này mới cho phép liên kết pull request và các bình luận linkback. Thành viên cũng có thể kết nối tài khoản GitHub cá nhân, nhưng việc đó chỉ thay đổi danh tính hiển thị trên các bình luận được đồng bộ, chứ không thay đổi những gì kết nối organization vốn đã làm.
Tầng thứ hai là liên kết một trong những repository đó với một Space. Làm vậy thì các issue GitHub mới bắt đầu xuất hiện dưới dạng Task; những issue đã có sẵn sẽ không được nhập vào. Một repository có thể cấp dữ liệu cho Space theo một chiều (thay đổi issue chỉ chảy vào, không bao giờ chảy ngược) hoặc hai chiều (issue và Task đồng bộ cả hai hướng), và mỗi Space chỉ nhận được một repository hai chiều tại một thời điểm, nên hãy chọn cho kỹ.
Đây là ranh giới khiến nhiều người vấp: không có gì trong số này là cách một Agent được cấp quyền clone mã của bạn. Tích hợp GitHub chỉ bao gồm liên kết pull request, đồng bộ issue và bình luận linkback. Nó không trao cho bất kỳ Agent nào quyền đọc hay ghi vào repository.
Cấp quyền truy cập mã cho Agent theo một cấu hình riêng
Quyền truy cập mã là một cấu hình riêng, được đặt trên Agent hoặc trên Space, chứ không phải trên kết nối GitHub. Một Agent không có repository riêng sẽ dùng theo cấu hình của Space chứa Task đó. Hãy thu hẹp danh sách ngay trên chính Agent khi nó chỉ nên chạm vào một codebase trong số nhiều codebase mà Space tham chiếu.
Dù theo cách nào, lượt chạy vẫn cần quyền truy cập Git hoạt động được trên chính Computer: một SSH key, một token HTTPS, hoặc thông tin đăng nhập host đã được thiết lập sẵn ở đó. Kết nối organization không cung cấp hay thay thế những thứ này. Nếu một lượt chạy không clone được, đó là vấn đề của Computer, chứ không phải của cài đặt GitHub App.
Gán issue cho một Agent
Khi một repository đã được liên kết, một issue GitHub mới sẽ hạ cánh thành một Task (Issue, Bug, Feature và Ticket đều là những task type hợp lệ, tùy Space của bạn dùng loại nào). Gán nó cho một Agent diễn ra giống hệt như gán cho một đồng nghiệp: mở ô Assignee và chọn Agent thay vì chọn người.
Một Agent là một cấu hình làm việc được lưu lại, chứ không phải một prompt dùng một lần: hướng dẫn, Runtime, repository và các thiết lập chạy của nó định hình công việc, giống như bản mô tả công việc định hình những gì một nhân viên mới làm. Nếu Task rơi vào Backlog thì chưa có gì chạy cả — đó là khu vực chờ. Chuyển nó sang một trạng thái đang làm việc thì Sharkly sẽ điều phối lượt chạy ngay khi Computer và Runtime sẵn sàng.
Khi hai Agent cùng đụng vào một repository
Đây là phần mà các team lo lắng nhất. Chế độ mặc định là Temporary: mỗi Task có một thư mục biệt lập, và các lượt chạy dựa trên repository sẽ chuẩn bị một worktree mới tinh. Hai Agent làm hai issue khác nhau trên cùng một repository sẽ mỗi bên có bản checkout riêng, không dùng chung, nên chúng không thể ghi đè file của nhau hay tranh nhau một branch, kể cả khi chạy trên cùng một Computer. Đó chính là kỷ luật đằng sau việc dùng git worktrees với AI coding agent bằng tay, chỉ khác là được tự động hóa.
Chạy đồng thời có giới hạn riêng của nó. Các lượt chạy Temporary mặc định ở khoảng một nửa giới hạn tổng của Computer; nếu bạn tăng thủ công, sản phẩm sẽ cảnh báo khi giá trị vượt quá dung lượng thư mục hiện có — đó mới là lúc va chạm thực sự bắt đầu. Chế độ Specified cũng tồn tại, cho phép một Agent dùng lại một thư mục cố định thay vì một worktree mới, nhưng nó chỉ phục vụ một lượt chạy tại một thời điểm, kém phù hợp hơn với một repository mà nhiều Agent cùng đụng vào.
Kết quả trả về: pull request
Khi Agent mở một pull request, bạn kết nối nó với Task bằng cách viết Task ID vào tên branch, tiêu đề, hoặc nội dung. Chỉ cần một trong ba chỗ đó là đủ; một ID trần như SH-312 cũng có tác dụng y như Fixes SH-312, vì không có xử lý đặc biệt nào cho các từ như fixes, closes hay skip. Trên repository công khai, chỉ tác giả đáng tin cậy — chủ sở hữu, thành viên hoặc collaborator — mới được liên kết, nên pull request của người lạ không thể giả mạo để gắn vào Task của bạn.
Các pull request đã liên kết cũng có thể nhận một bình luận linkback trỏ ngược về Task. Tính năng này mặc định bật với repository riêng tư và mặc định tắt với repository công khai — một công tắc nằm trong cài đặt GitHub, tách biệt với việc bản thân Space là công khai hay riêng tư.
Cổng review: nơi phán đoán của con người nằm ở đó
Merge một pull request không làm thay đổi trạng thái của Task, và việc đó không bao giờ tự động xảy ra. Đây là chủ ý. Trạng thái Task và trạng thái làm việc của Agent được theo dõi riêng, nên một Task đã Started vẫn có thể hiển thị Working, Waiting for human reply, Waiting for human review hoặc Error, và những tín hiệu này nổi lên trong Inbox cho người chịu trách nhiệm. Đóng hoặc mở lại issue GitHub gốc có thể làm thay đổi trạng thái của một Task hai chiều; merge pull request thì không.
Agent nghiên cứu, thực thi, kiểm thử và báo cáo. Con người đọc diff đối chiếu với issue gốc, yêu cầu chỉnh sửa hoặc chấp nhận, và tự mình đưa ra quyết định merge và release. Sự phân chia đó được giữ nguyên từ đầu đến cuối, trên GitHub cũng như mọi nơi khác trong Sharkly: tự động hóa dừng lại đúng ở chỗ cần đến phán đoán của team. Để hiểu sâu hơn về cơ chế, quy trình review human-in-the-loop của Sharkly đề cập trực tiếp vấn đề này.
Khi trung tâm agent của chính GitHub là đủ
Nếu team bạn dồn hết vào GitHub — source, CI, review và một ghế Copilot trả phí — thì Agent HQ của chính GitHub phối hợp các agent trong hệ sinh thái đó khá tốt, và có thể bạn chẳng cần gì thêm. Lý do để chọn Sharkly xuất hiện khi công việc còn đi qua Jira, khi Agent chạy trên những Computer nằm ngoài cloud của GitHub, hoặc khi team bạn dùng nhiều Runtime trộn lẫn và không muốn dựng lại quy trình mỗi lần Runtime tốt nhất thay đổi. Nếu Jira nằm trong số đó, thì gán một ticket Jira cho AI Agent cũng đi theo đúng vòng lặp ấy từ phía bên kia.
Muốn thử trên một issue thật: mở trang tích hợp GitHub, Jira và Slack của Sharkly, kết nối organization GitHub của bạn, liên kết một repository ít traffic với một Space, rồi gán issue nhỏ tiếp theo cho một Agent thay vì tự làm.
Câu hỏi thường gặp
Việc kết nối organization GitHub của tôi có cấp cho Agent quyền truy cập mã của tôi không? Không. Kết nối organization chỉ bao gồm liên kết pull request, đồng bộ issue và bình luận linkback. Quyền truy cập mã được cấu hình riêng, trên Agent hoặc trên Space, và lượt chạy vẫn cần thông tin đăng nhập Git riêng trên Computer.
Hai Agent cùng làm việc trên một repository có bao giờ va chạm không? Không, ở chế độ Temporary mặc định. Mỗi lượt chạy có worktree biệt lập riêng, nên các Agent chạy đồng thời không bao giờ dùng chung một bản working copy, kể cả trên cùng một Computer.
Merge pull request có đóng issue GitHub hoặc Task không? Việc merge tự nó không bao giờ thay đổi trạng thái của Task. Đóng issue GitHub gốc thì có thể, trên một repository đồng bộ hai chiều, nhưng đó là hành động tách biệt với việc merge PR.
Pull request của Agent thực sự nhắm vào đâu? Sharkly liên kết pull request dựa trên Task ID trong tên branch, tiêu đề hoặc nội dung, tùy Runtime của bạn viết vào chỗ nào. Nó không quy định một chiến lược branch cụ thể, nên hãy xác nhận hành vi base branch mặc định của Runtime trước khi gán bất cứ việc gì quan trọng hơn một issue thử nghiệm.
Tôi có thể giữ lại các issue GitHub hiện có, chứ không chỉ issue mới không? Liên kết một repository sẽ đồng bộ các issue được tạo mới từ đó về sau. Những issue hiện có không được nhập vào tự động.
