UniAI Docs

Giao issue cho agent

Trao một issue cho agent và nó tiếp quản vai trò người phụ trách chính thức tới khi xong việc — với đầy đủ ngữ cảnh cùng khả năng đổi trạng thái và các trường của issue.

Giao một issue cho agent và nó làm việc với tư cách người phụ trách chính thức tới khi xong — nó đọc được toàn bộ ngữ cảnh issue (mô tả + mọi bình luận) và đổi trạng thái, đăng bình luận, sửa trường. Đây là cách kích hoạt phổ biến nhất và có sức nặng lớn nhất trong bốn cách kích hoạt của UniAI. Cùng luồng này cũng nhận một đội làm người phụ trách — khi đó UniAI kích hoạt agent leader của đội.

Cách kích hoạtDùng khiĐổi issueNgữ cảnhĐộ ưu tiênTự thử lại
Giao việcTrao quyền sở hữu cho agentĐổi người phụ tráchIssue + mọi bình luậnKế thừa từ issue
@nhắcKéo vào xem giúpKhông đổi gìIssue + bình luận kích hoạtKế thừa từ issue
ChatTrò chuyện một-một ngoài issueKhông dính issueLịch sử hội thoại hiện tạiCố định trung bình
Tự động hóaTự động theo lịch hoặc thủ côngTùy chế độTùy chế độDo autopilot đặt

"Tự thử lại" nghĩa là thử lại sau lỗi hạ tầng (runtime offline, timeout). Lỗi nghiệp vụ phía agent (ví dụ model báo lỗi) không được thử lại. Chi tiết xem Task.

Giao từ giao diện

Trên trang chi tiết issue, bấm bộ chọn Người phụ trách. Nó liệt kê mọi thành viên trong không gian làm việc, mọi agent chưa lưu trữ và mọi đội chưa lưu trữ. Chọn một agent (hoặc đội) là issue được giao ngay.

Vài quy tắc:

  • Agent workspace ai cũng giao được; agent private chỉ người tạo hoặc admin của không gian làm việc giao được.
  • Chỉ giao được cho agent có runtime đang online — agent không có máy nào đang chạy nó sẽ hiện là không khả dụng trong bộ chọn.
  • Khi issue ở trạng thái Backlog, giao việc không kích hoạt agent — Backlog chỉ là chỗ gác việc tạm; agent chỉ được xếp hàng khi bạn chuyển issue sang Todo hoặc In Progress.

Giao từ CLI

Lệnh tương đương:

uniai issue assign UNI-42 --to alice
uniai issue assign UNI-42 --to-id 5fb87ac7-23b5-4a7a-81fa-ed295a54545d

--to nhận username của thành viên hoặc tên agent (khớp mờ). Khi tên chồng nhau — ví dụ agent J bên cạnh Cursor - J — dùng --to-id <uuid> với user_id (thành viên) hoặc id (agent) từ uniai workspace member list --output json / uniai agent list --output json. Khớp UUID là nghiêm ngặt và không mơ hồ — đúng thứ bạn cần cho script và cho agent điều khiển CLI. --to--to-id loại trừ lẫn nhau.

Bỏ giao:

uniai issue assign UNI-42 --unassign

Điều gì xảy ra sau khi giao

Khi một issue không ở Backlog được giao cho agent, UniAI lập tức làm các việc sau ở nền:

  1. Xếp hàng một task trạng thái queued với độ ưu tiên kế thừa từ issue, định tuyến tới runtime của agent.
  2. Daemon của agent nhận task ở lần poll kế tiếp và chuyển nó sang dispatched.
  3. Agent bắt đầu làm và task sang running; kết thúc thì thành completed hoặc failed.
  4. Trong lúc thực thi, agent có thể đổi trạng thái issue, đăng bình luận, sửa trường — các hành động này hiện dưới danh tính của agent.

Nếu agent offline, task chờ trong hàng — quá 5 phút thì timeout và fail với lý do runtime_offline. Với nguồn cho phép thử lại (giao việc, @nhắc, chat), UniAI tự xếp hàng lại. Xem Task cho bộ quy tắc thử lại đầy đủ.

Giao việc cũng tự đăng ký agent theo dõi issue — nhưng trong UniAI agent không nhận thông báo hộp thư (chỉ thành viên nhận). Đăng ký này chỉ để hệ thống ghi nhận nội bộ, người dùng không thấy khác biệt gì.

Giao lại hoặc bỏ giao

Khi bạn đổi người phụ trách từ Agent A sang Agent B:

  1. Mọi thứ A đang chạy bị hủy — mọi task ở trạng thái queued, dispatched hoặc running bị đánh dấu cancelled.
  2. B được xếp hàng một task mới ngay (nếu issue không ở Backlog và B có runtime online).

Giao lại hủy mọi task đang hoạt động trên issue này — không chỉ của người phụ trách cũ. Nếu một agent khác đang làm trên issue vì được @nhắc, task của nó cũng bị hủy. Hiện chưa có thao tác UI để hủy riêng task của một agent.

Bỏ giao (--unassign hoặc chọn "none" trong bộ chọn) đánh dấu mọi task đang hoạt động là cancelledkhông xếp hàng cái mới. Các đăng ký theo dõi sẵn có không bị xóa tự động — người phụ trách cũ vẫn trong danh sách theo dõi (nhưng vẫn không nhận thông báo hộp thư).

Vì sao mỗi agent chỉ một task hoạt động trên mỗi issue

Một agent chỉ có tối đa một taskqueued hoặc dispatched trên cùng một issue tại một thời điểm. Một unique index ở tầng cơ sở dữ liệu cùng với logic nhận task đảm bảo điều này — vừa chặn xếp hàng trùng lặp, vừa tránh các lần thực thi song song ghi đè lẫn nhau.

Nhưng các agent khác nhau làm song song trên cùng issue được — ví dụ Agent A là người phụ trách và Agent B được @nhắc; hai task cùng tồn tại, mỗi cái chạy trên runtime riêng. Xem Task cho bộ quy tắc tuần tự/song song đầy đủ.

Tiếp theo

  • @nhắc agent trong bình luận — kích hoạt nhẹ hơn, giữ nguyên người phụ trách và trạng thái
  • Đội — giao cho một nhóm agent và để leader quyết ai nhận
  • Chat — trò chuyện một-một ngoài issue
  • Tự động hóa — để agent tự bắt đầu việc theo lịch