UniAI Docs

Task

Đơn vị công việc của mỗi lượt agent chạy, với máy trạng thái rõ ràng, timeout và quy tắc thử lại.

Một task là đơn vị của mỗi lượt agent chạy — giao issue cho agent, @nhắc agent trong bình luận, gửi tin nhắn trong chat, hay một Autopilot kích hoạt theo lịch đều sinh ra một task. UniAI đưa nó vào hàng đợi; một daemon nhận và chuyển cho công cụ lập trình AI tương ứng, rồi ghi kết quả về server khi xong.

Task và issue là hai đối tượng khác nhau. Một issue có thể được giao, @nhắc và chạy lại thủ công nhiều lần — mỗi lần sinh một task mới.

Các trạng thái một task đi qua

Rendering diagram…
  • Queued — task vừa được tạo, chờ daemon nhận
  • Dispatched — một daemon đã nhận và đang khởi chạy công cụ lập trình AI
  • Running — công cụ lập trình AI đang thực sự làm việc
  • Completed — hoàn thành; kết quả (bình luận, commit mã, thay đổi trạng thái) được ghi về server
  • Failed — bị dừng vì lỗi hoặc timeout; nếu lý do lỗi cho phép thử lại, task tự quay về queued để chạy thêm lần nữa
  • Cancelled — người dùng đã hủy

Điều gì xảy ra khi task timeout

UniAI server quét mỗi 30 giây. Hai loại timeout gây thất bại:

Tình huốngTimeout
Đã dispatched nhưng không khởi chạy (daemon nhận nhưng chưa bật công cụ AI)5 phút
Chạy quá lâu2,5 giờ

Cả hai đều dùng lý do lỗi timeouttự thử lại (mục kế tiếp). Về cơ chế kiểm tra runtime mất kết nối liên quan, xem Daemon và runtime → Khi runtime bị đánh dấu offline.

Lỗi nào tự thử lại, lỗi nào không

Lỗi chia hai loại: cho phép thử lạikhông cho phép thử lại.

Cho phép thử lại (UniAI tự xếp hàng lại):

  • runtime_offline — daemon mất tích sau khi task đã dispatched
  • runtime_recovery — daemon sập rồi khởi động lại, thu hồi các task chưa xong
  • timeout — timeout khi chạy hoặc khi dispatch

Không cho phép thử lại (task nằm nguyên ở failed):

  • agent_error — bản thân công cụ lập trình AI báo lỗi (lỗi API, hết quota, bug nội bộ). Loại lỗi này không được thử lại — thử lại cũng chỉ lỗi mãi, lặp vô hạn.

Tự thử lại còn hai điều kiện phụ:

  1. Tối đa 2 lần chạy — 1 lần gốc + 1 lần thử lại. Nếu lần thử lại vẫn lỗi thì dừng hẳn, không thử thêm, kể cả khi lý do cho phép thử lại.
  2. Chỉ với task kích hoạt từ issue và chat — task do Autopilot kích hoạt không tự thử lại.

Task của Autopilot không tự thử lại là chủ ý thiết kế. Autopilot có nhịp chạy riêng (ví dụ hằng ngày); tự thử lại khi lỗi sẽ chồng lên lần chạy kế theo lịch. Cần chạy lại ngay sau lỗi thì dùng chạy lại thủ công (mục kế tiếp).

Làm sao biết task của Autopilot lỗi: một thông báo sẽ được gửi về Hộp thư đến của bạn, và trạng thái issue liên quan lùi từ in_progress về todo. Trang Tự động hóa cũng hiện kết quả lần chạy mới nhất của từng autopilot.

Chạy lại thủ công vs. tự thử lại

Chạy lại thủ công là do bạn kích hoạt từ CLI hoặc API (POST /api/issues/{id}/rerun):

uniai issue rerun <issue-id>

Hành vi:

  • Mặc định nhắm vào agent đang phụ trách issue — hữu ích khi bạn muốn lần chạy lại bám theo phân công hiện tại, bất kể ai chạy task trước.
  • Nút thử lại trên một dòng trong nhật ký thực thi gửi kèm ID task của dòng đó, nên lần chạy lại nhắm vào agent đã chạy đúng task đó — không phải người phụ trách hiện tại. Nhờ vậy, thử lại theo từng dòng vẫn đúng nghĩa với worker của đội, các agent được @nhắc song song, hoặc những dòng mà agent đã bị thay do phân công lại.
  • Hủy task đang xếp hàng hoặc đang chạy của agent mục tiêu trên issue này (nếu có). Task của agent khác trên cùng issue (ví dụ các lượt @nhắc song song) được để yên.
  • Tạo một task hoàn toàn mới — bộ đếm lần chạy về 1, kể cả khi task gốc đã chạm trần số lần thử.
  • Bắt đầu phiên agent mới — ID phiên trước không được kế thừa. Chạy lại thủ công nghĩa là bạn đã đánh giá kết quả trước là tệ, nên nối lại cuộc trò chuyện cũ chỉ lặp lại đúng trạng thái hỏng đó. (Ngược lại, tự thử lại kế thừa phiên — cơ chế đó dành cho lỗi hạ tầng, không phải cho kết quả tệ.)

So sánh:

Khía cạnhTự thử lạiChạy lại thủ công
Kích hoạtHệ thống, theo lý do lỗiBạn, thủ công
Giới hạn số lần2 lần chạyKhông giới hạn
Nguồn áp dụngIssue, chatIssue có agent phụ trách
Agent được chọnCùng agent với task lỗiAgent của task nguồn (thử lại theo dòng trên UI) hoặc người phụ trách hiện tại (CLI / không có task_id)
Kế thừa phiênCó (nối phiên trước)Không (phiên mới)

Task lỗi ảnh hưởng trạng thái issue thế nào

Nếu một task sinh ra do giao issue cho agent bị thất bại (và không lần tự thử lại nào thành công), trạng thái issue tự lùi từ in_progress về todo — mở bảng là bạn thấy ngay "cái này cần được xem lại". Xem Issue và dự án.

Task có tiếp tục được từ ngữ cảnh trước không

Có — miễn công cụ lập trình AI hỗ trợ khôi phục phiên.

UniAI ghim ID phiên hai lần trong một task: một lần lúc bắt đầu (khi công cụ AI trả về system message đầu tiên), một lần lúc kết thúc (hoàn thành hoặc thất bại). Lần đầu giúp daemon phục hồi nếu sập giữa chừng; lần sau dành cho lượt tự thử lại kế tiếp: khi đó ID được truyền lại để agent nối tiếp cuộc trò chuyện và trạng thái file trước đó. Chạy lại thủ công chủ ý bỏ qua bước này và mở phiên mới — xem Chạy lại thủ công vs. tự thử lại.

Nhưng công cụ nào thực sự hỗ trợ tính năng này thì lại rất khác nhau:

  • Hỗ trợ thật — Antigravity, Claude Code, Codex, Copilot, Cursor, Hermes, Kimi, Kiro CLI, OpenCode, OpenClaw, Pi
  • Không hỗ trợ — Gemini

Xem Ma trận provider → Khôi phục phiên.

Tiếp theo