Phiếu và ủy thác

Phiếu là đơn vị công việc mà Control Center theo dõi. Nó cố ý là một thực thể ngốc: một tiêu đề, một nội dung, một trạng thái, một chủ sở hữu và một vị trí trong cây. Nó không phải thứ mà agent thực thi dựa trên — công việc của agent nằm trong các cuộc hội thoại, còn đầu ra có cấu trúc của một lần chạy nằm trên nhật ký chạy.

Gán là ghi nhận quyền sở hữu; nó không điều phối gì cả

Đây là điều quan trọng nhất cần nắm cho đúng về phiếu.

Đặt assignedAgentId chỉ ghi một trường và phát ra một sự kiện miền TicketAssigned. Sự kiện đó là một tín hiệu kiểm toán và thông báo, đồng thời là một trình kích hoạt quy trình. Gán phiếu cho một agent không khởi động lần chạy nào. Không có bộ điều phối phiếu nào theo dõi assignedAgentId rồi đánh thức agent đó.

Ngoại lệ là đội: khi assignedTeamId được đặt, TeamRoutingService điều phối trưởng đội kèm giao thức vận hành và danh sách thành viên.

Nếu bạn muốn một agent cụ thể làm một phiếu, hãy nhờ nó trong một cuộc hội thoại, hoặc để một bước quy trình điều phối nó, hoặc để một agent khác ủy thác cho nó. Gán phiếu cho một agent rồi ngồi chờ là việc duy nhất sẽ không bao giờ tạo ra công việc.

Bản gương và lớp phủ

Một phiếu có thể thuần cục bộ hoặc được một trình theo dõi bên ngoài hậu thuẫn, và nó mang cả hai trên cùng một hàng.

Bản gương — nhà cung cấp, khóa bên ngoài, URL, tiêu đề, mô tả, mức ưu tiên, nhãn, trạng thái thô và trạng thái đã chuẩn hóa, dấu thời gian — là một bộ đệm khi phiếu ở xa. Ở đó hệ thống từ xa là nguồn chân lý, và một lần làm mới sẽ ghi lại toàn bộ bản gương.

Lớp phủ — phân công, ủy thác, liên kết space, phiếu cha, dự án, các PR được liên kết — chỉ thuộc về Control Center. Trình theo dõi không biết gì về nó và một lần làm mới không bao giờ chạm tới nó.

Chính sự tách bạch đó khiến việc đồng bộ trở nên an toàn: một lần kéo từ nhà cung cấp có thể phá hủy bản gương mà không bao giờ làm mất siêu dữ liệu điều phối phủ bên trên.

Đồ thị vòng đời ràng buộc agent, không ràng buộc bạn

Các trạng thái chạy backlog → open → inProgress → inReview → done, với blocked là một vòng phụ và failed / cancelled là các trạng thái kết thúc còn lại.

Đồ thị chuyển trạng thái chỉ được thực thi trên đường đi của agent và tự động hóa — các công cụ MCP và bộ đối soát. Một chuyển trạng thái không hợp lệ ở đó sẽ bị ghi log và bỏ qua, nên một agent lú lẫn không thể kéo ngược một phiếu ra khỏi trạng thái kết thúc.

Mọi thay đổi do người dùng thực hiện trong giao diện đều truyền force: true và bỏ qua hoàn toàn đồ thị. Con người có thể chuyển một phiếu sang bất kỳ trạng thái nào mà hộp chọn liệt kê — kể cả mở lại một trạng thái kết thúc. Hộp chọn không đưa ra failed; agent đặt trạng thái đó qua fail_ticket. Đồ thị là một thanh chắn an toàn cho tự động hóa, chứ không phải một quy tắc về cách công việc được phép diễn ra.

TicketWorkflowService sở hữu mọi thay đổi qua một điểm nghẽn duy nhất: nó nạp hàng, khẳng định hàng thuộc không gian làm việc của bên gọi và ghi với một version mong đợi, nhờ đó hai chỉnh sửa đồng thời không thể âm thầm ghi đè lên nhau.

Để xem bảng trạng thái đầy đủ, các chuyển trạng thái, danh sách trường và các loại quan hệ, xem Vòng đời phiếu.

Nguồn gốc: một phiếu ra đời như thế nào

Mọi phiếu đều có một originKind. Enum này có năm giá trị — manual, pipelineStep, agentDelegation, externalSync, recovery — nhưng hiện chỉ hai giá trị được ghi: manual (mặc định trên createTicket, kể cả các phiếu con được ủy thác) và externalSync (bộ máy đồng bộ, khi kéo từ nhà cung cấp). TicketWorkflowService.createTicket không nhận đối số nguồn gốc, nên pipelineStep, agentDelegation và recovery không bao giờ xuất hiện trên một hàng.

Ủy thác có canh chừng

Ủy thác là nơi một agent tạo công việc cho một agent khác, và cũng là nơi đặc quyền có thể rò rỉ, nên các hàng rào nằm phía máy chủ tại một điểm nghẽn thay vì trong chỉ dẫn prompt.

delegate_task đi qua TicketWorkflowService.delegateGuarded, hàm này tính độ sâu và gốc của phiếu con từ chuỗi phiếu cha rồi chạy cả bốn kiểm tra của DelegationGuards: một bước nhảy vượt quá giới hạn độ sâu 3, một bước nhảy quay lại một agent đã có trong chuỗi (phát hiện chu trình), một mức trần tự chủ (cấp hiệu lực của bên được ủy thác trong space không được vượt quá cấp của bên ủy thác) và một phong bì ngân sách (việc ủy thác tính vào ngân sách dừng cứng còn lại của bên ủy thác và không thể tạo thêm). Phần đấu nối production cung cấp cả hai cổng resolver. Quyền tự chủ và ngân sách sẽ bị bỏ qua khi from_agent_id không được truyền (ngân sách không giới hạn / không chính sách cũng được chấp nhận). Một lời từ chối được ném ra dưới dạng DelegationRefusedException với thông điệp đến thẳng agent đang ủy thác nguyên văn — một lời từ chối rõ ràng, không bao giờ là một no-op im lặng.

delegate_ticket là người anh em cũ hơn, không được canh chừng: nó gọi thẳng createTicket và bỏ qua mọi hàng rào. Hãy ưu tiên delegate_task.

Đừng nhầm giới hạn độ sâu ủy thác (3, trên các chuỗi delegate_task) với giới hạn lồng subagent của harness tích hợp (2). Đó là hai giới hạn khác nhau trên hai cơ chế khác nhau.

Hệ thống phân cấp, liên kết và dự án

Quan hệ cha và vấn đề con nằm trên tickets.parent_ticket_id, do setParent / clearParent quản lý. Chúng không phải là các hàng ticket_links, nên bất cứ thứ gì đọc quan hệ của một phiếu đều phải hợp nhất cả hai nguồn.

ticket_links chứa các cạnh có hướng giữa những phiếu vốn không liên quan với nhau:

Loại liên kết	Ý nghĩa
blocks	Phiếu nguồn chặn phiếu đích
relatesTo	Hai phiếu có liên quan với nhau (đối xứng)
duplicateOf	Phiếu nguồn là bản trùng của phiếu đích

Một dự án là cách nhóm các phiếu trong phạm vi không gian làm việc hướng tới một mục tiêu chung. Dự án chỉ thuộc về Control Center và không bao giờ đồng bộ sang nhà cung cấp bên ngoài.

Cộng tác viên

Các hàng TicketCollaborator là cách gắn nhiều hơn một chủ thể vào một phiếu, với vai trò assignee, collaborator hoặc reviewer. Con người và agent là những hàng ngang hàng nhau — một principalId cộng một collaboratorType — không có giá trị đánh dấu (sentinel) cho “người dùng” và không có khóa ngoại trỏ tới bảng nào trong hai bảng đó.

Đồng bộ bên ngoài

Phiếu của Control Center là bản chính. Việc xóa một phiếu chỉ diễn ra cục bộ, nên một phiếu được nhà cung cấp hậu thuẫn mà bạn xóa sẽ không bị xóa trên trình theo dõi và có thể xuất hiện lại trong lần đồng bộ kế tiếp. Cộng tác viên và phiếu con bị xóa theo dây chuyền.

Thông tin xác thực của adapter được phân giải từ các kho thông tin xác thực của máy chủ (một khóa Linear hoặc token GitHub được dán trong Cài đặt sẽ được nhận ở yêu cầu kế tiếp; biến môi trường chỉ gieo mầm cho các kho đó).

Phiếu và quy trình

Không có nút quy trình nào tạo, hoàn tất hay hủy phiếu — bảng chọn không có bước như vậy và bộ máy không gọi TicketWorkflowService. Một trình kích hoạt quy trình vẫn có thể kích hoạt trên TicketAssigned, TicketCompleted, TicketFailed hoặc TicketCancelled (bốn sự kiện đó là những sự kiện phiếu mà EventPayloadMapper thực sự ánh xạ). Không có cột pipelineRunId trên phiếu; sự gắn kết với quy trình nằm trên nhật ký chạy của agent.

Xem thêm

• Quy trình và tự động hóa: các sự kiện phiếu có thể kích hoạt một quy trình
• Điều phối: một DAG các phiếu con đến từ đâu
• Mô hình agent: phiếu được gán cho ai
• Sự kiện miền: các sự kiện trong vòng đời phiếu
• Vòng đời phiếu: trạng thái, trường, chuyển trạng thái, quan hệ
• Tạo và quản lý phiếu
• Ủy thác công việc cho agent
• Tổ chức công việc bằng dự án