TaskGoblin là một tác nhân đám mây, nghĩa là câu hỏi quan trọng nhất — mã của tôi chạy ở đâu? — chỉ có một câu trả lời: trong một sandbox đám mây tách biệt, không bao giờ trên máy tính xách tay của bất kỳ ai. Trang này giải thích sandbox đó là gì, vì sao nó tách biệt, và làm thế nào nó giữ được điều đó khi đội ngũ của bạn lớn lên.
Sandbox là gì
Sandbox là một container tách biệt trên đám mây, có sẵn một bản checkout kho mã của bạn. Khi bạn giao một tác vụ, tác nhân chạy bên trong container đó — nó đọc và sửa tệp, chạy lệnh và khảo sát kho mã ngay tại đó, không có quyền truy cập vào máy của bạn và không phụ thuộc vào việc máy có bật hay không.
Vì sandbox nằm trên đám mây, công việc mang tính bất đồng bộ tự nhiên: bạn giao một tác vụ rồi rời đi, và tác nhân vẫn tiếp tục làm dù bạn có theo dõi hay không.
Tách biệt: mỗi tổ chức một ranh giới
Công việc của mỗi tổ chức chạy bên trong sandbox của riêng nó. Ranh giới đó là cốt lõi của việc cô lập dữ liệu trong TaskGoblin — một tổ chức không bao giờ có thể đọc hay ghi mã, kho mã hay lịch sử chạy của tổ chức khác. Tác nhân chỉ nhìn thấy các workspace, kho mã và dự án mà bạn kết nối một cách rõ ràng; ngắt kết nối là nó mất quyền truy cập ngay lập tức.
Bền vững: nó nhớ cả môi trường, không chỉ tác vụ
Sandbox là bền vững và được tái sử dụng qua các tin nhắn trong cùng một luồng. Một lượt hỏi tiếp về cùng issue sẽ rơi vào môi trường đã sẵn kho mã được clone và trạng thái của lần chạy trước còn nguyên — nên tác nhân tiếp tục nhanh chóng thay vì bắt đầu từ một chiếc hộp rỗng mỗi lần. Đây là điều khiến việc lặp lại trên một tác vụ có cảm giác liền mạch chứ không lặp đi lặp lại. (Về cách sự liền mạch đó mang các quyết định xuyên qua nhiều lần chạy, xem Agent hoạt động như thế nào, phần luồng và bộ nhớ bàn giao.)
Bí mật nằm ngoài tác nhân
Tác nhân không bao giờ nhìn thấy thông tin xác thực của bạn. Quyền truy cập git bên trong sandbox được cấp phát theo từng tổ chức vào lúc chạy — một token OAuth GitLab hoặc một token cài đặt GitHub vừa được tạo — và được tiêm vào môi trường xung quanh tác nhân, thay vì trao cho nó như một thứ để đọc. Tác nhân có thể dùng quyền truy cập nó cần để clone và push, mà bí mật của bạn không bao giờ lọt vào bản ghi hay ngữ cảnh của nó.
Đây là một ranh giới có chủ đích, không phải tác dụng phụ: thông tin xác thực sẵn sàng cho công cụ git trong sandbox, nhưng không bao giờ là một phần của tài liệu mà tác nhân đọc hay suy luận trên đó.
Sandbox tùy chỉnh
Ở các gói dành cho đội nhóm, bạn có thể mang theo sandbox tùy chỉnh — một image container đã nạp sẵn bộ công cụ, gói hệ thống và dịch vụ mà dự án của bạn cần để build và kiểm thử. Khi công việc của tác nhân phụ thuộc vào nhiều hơn một bản checkout trần (một runtime cụ thể, một cơ sở dữ liệu, công cụ build nội bộ), sandbox tùy chỉnh nghĩa là môi trường đã sẵn sàng ngay khi tác vụ bắt đầu, và thay đổi của tác nhân có thể được kiểm chứng trong một thiết lập sát thực tế.
Sandbox tự lưu trữ
Các đội có yêu cầu về tuân thủ hoặc nơi lưu trú dữ liệu có thể chạy sandbox trên hạ tầng của chính mình. Lớp điều khiển vẫn lên lịch và dẫn dắt công việc, nhưng container nơi mã của bạn được checkout và thực thi lại nằm bên trong môi trường của bạn — nên mã nguồn, sản phẩm build và trạng thái chạy không bao giờ rời khỏi ranh giới bạn kiểm soát. Đây là lựa chọn khi "trên đám mây" phải có nghĩa là đám mây của bạn.
Đi tiếp tới đâu
- Agent hoạt động như thế nào — toàn bộ luồng từ kích hoạt tới merge request, các luồng và bộ nhớ bàn giao.
- Giao việc cho tác nhân — mọi cách bắt đầu một lần chạy, và cách công việc song song dùng một sandbox cho mỗi tác vụ.
- Loops — các lần chạy lặp lại dùng chính mô hình sandbox này theo nhịp.