Xây dựng không gian làm việc chung cho con người và tác nhân

Cách Dự án trên Perplexity giúp công việc dài hạn luôn bền vững, hỗ trợ làm việc đồng thời và có thể truy vết.

Tác giảPerplexity Engineering

Gần đây, chúng tôi đã ra mắt Dự án, nơi con người và tác nhân cùng làm việc trên các tác vụ dài hạn trong Perplexity Computer. Mỗi dự án nằm trên một không gian làm việc chung với hệ thống tệp tích lũy ngữ cảnh qua các phiên, tác nhân và người dùng. Sự cộng tác nhiều người kéo dài hàng tháng đòi hỏi tính bền vững, tính đồng thời và khả năng truy vết:

  • Tính bền vững: Công việc cần được lưu giữ bền vững vượt ra ngoài bất kỳ phiên tác nhân hay sandbox riêng lẻ nào, để chính người dùng hoặc tác nhân đó có thể tiếp tục công việc về sau và mọi cộng tác viên đều có thể phát triển tiếp trên đó.
  • Tính đồng thời: Nhiều người dùng trong cùng một dự án có thể cùng lúc có nhiều tác nhân chỉnh sửa song song, cùng bồi đắp cho một trạng thái chung thay vì ghi đè lên nhau.
  • Khả năng truy vết: Cả người dùng lẫn tác nhân đều cần xem được lịch sử, để kiểm tra ai đã thay đổi những gì kể từ phiên gần nhất mà không phải đọc lại toàn bộ dự án, đồng thời có thể hoàn tác các chỉnh sửa khi cần.

Những thách thức này khá quen thuộc với các kỹ sư phần mềm. Các Git forge đã ra đời từ nhiều thập kỷ trước để đáp ứng chính những yêu cầu này: một dịch vụ được lưu trữ trên máy chủ, bao bọc hệ thống quản lý phiên bản bằng các tính năng cộng tác để nhiều người đóng góp có thể cùng hội tụ về một nguồn thông tin chuẩn duy nhất. Hệ thống tệp vận hành Dự án chính là một Git forge như vậy, được xây dựng cho sự cộng tác giữa con người với tác nhân và giữa các tác nhân với nhau.

Một dự án: các tác nhân tương tác, tác nhân theo lịch và tác nhân của những người dùng khác đều hội tụ về cùng một kho lưu trữ.

Kiến trúc

Git vốn đã xử lý được tính bền vững, tính đồng thời và khả năng truy vết. Git nhận diện mỗi tệp dựa trên nội dung của nó, nên các tệp không thay đổi chỉ được lưu một lần và các bản đã lưu không bao giờ bị lỗi thời. Mỗi commit lưu tất cả các tệp được cập nhật cùng một lúc, nên cộng tác viên không bao giờ thấy một trạng thái dở dang. Khi hai bên ghi xung đột, bên thua có thể áp dụng lại thay đổi của mình trên phiên bản mới và thử lại. Chuỗi commit cho thấy ai đã thay đổi những gì và giúp dễ dàng khôi phục các phiên bản trước. Điều mà tác nhân không cần là phần còn lại của một forge được xây dựng cho con người, chẳng hạn như màn hình đánh giá, quản lý nhánh và thông báo.

Kiến trúc của chúng tôi chạy toàn bộ quy trình trên đám mây và hỗ trợ mọi hình thức công việc tri thức, không chỉ lập trình. Mỗi dự án Computer đều dựa trên một kho lưu trữ Git do 5 thành phần phục vụ:

  • CLI duy trì các bản checkout cục bộ, đồng bộ cập nhật và gửi các thay đổi của tác nhân trong từng sandbox.
  • Mặt phẳng điều khiển (control plane) định vị kho lưu trữ của dự án và cấp thông tin xác thực ngắn hạn để truy cập kho.
  • Dịch vụ Git gửi dữ liệu kho lưu trữ đến các sandbox, nhận các lượt gửi từ chúng và quyết định lượt gửi nào trở thành commit được chấp nhận mới nhất.
  • Bộ lưu trữ dựa trên AWS S3 lưu trữ bền vững dữ liệu kho lưu trữ.
  • Xử lý hạ nguồn trích xuất văn bản và các thông tin hữu ích khác từ tài liệu đã lưu, rồi cung cấp chúng khi tác nhân tải hoặc làm mới dự án.

Mỗi tác nhân có sandbox biệt lập của riêng mình. Bên trong sandbox đó, tác nhân làm việc với một bản cục bộ của kho lưu trữ, được quản lý bởi một CLI nhỏ. CLI yêu cầu mặt phẳng điều khiển định vị kho lưu trữ, sau đó tìm nạp và gửi thay đổi thông qua dịch vụ Git. Một proxy tác nhân kiểm tra quyền truy cập đối với các yêu cầu từ sandbox trước khi chúng đến được dịch vụ Git. Dịch vụ Git đọc và ghi kho lưu trữ trên một hệ thống tệp dùng chung, đồng thời quyết định liệu mỗi lượt gửi có trở thành commit được chấp nhận mới nhất hay không. Hệ thống tệp đó do AWS S3Files cung cấp, giúp truy cập bộ lưu trữ dựa trên S3 như các tệp và thư mục thông thường. Bộ lưu trữ được chia thành các ô biệt lập, mỗi ô có hệ thống tệp và các bản sao dịch vụ Git riêng. Sau khi một commit được chấp nhận, các worker chạy nền trích xuất văn bản và các thông tin hữu ích khác từ những tài liệu đã thay đổi, lưu kết quả tách biệt khỏi lịch sử kho lưu trữ và cung cấp chúng khi tác nhân tải hoặc làm mới dự án.

Tiếp theo, chúng ta sẽ lần lượt tìm hiểu từng thành phần.

CLI liên hệ với mặt phẳng điều khiển để định vị kho lưu trữ của mình, sau đó tìm nạp và gửi thông qua dịch vụ Git qua proxy tác nhân. Dịch vụ Git kiểm tra các lượt gửi và cập nhật head được chấp nhận cùng outbox trong DynamoDB. Các bản sao cục bộ trong từng ô dùng bộ lưu trữ S3Files, còn các worker hạ nguồn trích xuất văn bản phục vụ checkout và đồng bộ.

CLI: Làm việc với tệp cục bộ trong sandbox

Các tác nhân chạy trong SPACE, nền tảng sandbox do chúng tôi tự phát triển. Mỗi sandbox có một CLI nhỏ giúp hiện thực hóa kho lưu trữ và giữ cho kho luôn đồng bộ. Với mỗi đơn vị công việc có ý nghĩa mà tác nhân hoàn thành, CLI gửi các thay đổi dưới dạng một commit.

Tác nhân thường chỉ động đến một phần nhỏ các tệp dự án, nên không cần hiện thực hóa toàn bộ kho lưu trữ ngay từ đầu. Vì vậy, CLI hiện thực hóa theo kiểu lười: các tệp lớn và tệp nhị phân được lưu qua Git Large File Storage (LFS) sẽ xuất hiện dưới dạng các tệp con trỏ nhỏ ghi lại kích thước thực của đối tượng, nhờ đó tác nhân có thể dựa vào tên và kích thước để quyết định có đáng tải xuống hay không. Với các tài liệu như PDF, tác nhân đọc văn bản đã phân tích trước và chỉ tải xuống tệp nguồn khi cần thiết.

Một lựa chọn tự nhiên khác là sử dụng hệ thống tệp ảo. Chúng tôi đã thử nghiệm một triển khai dựa trên FUSE, nhưng nó chậm hơn khoảng 400 lần so với tệp cục bộ đối với các khối lượng công việc thao tác nhiều với hệ thống tệp, vì mỗi yêu cầu đều cần một lượt truyền mạng khứ hồi. Cách này cũng thường đòi hỏi các đặc quyền từ máy chủ, nên mọi tác nhân sẽ phải chạy trong một sandbox có đặc quyền.

Kích thước con trỏ và manifest phân tích cú pháp sẽ quyết định: đọc văn bản đã phân tích, tải xuống tệp nguồn hay bỏ qua.

Mặt phẳng điều khiển: Định vị kho lưu trữ và cấp quyền truy cập

Mặt phẳng điều khiển xác định nơi lưu trữ từng kho và cấp quyền truy cập vào kho đó. Khi một kho lưu trữ được tạo, mặt phẳng điều khiển gán kho đó cho một ô lưu trữ (storage cell), tức một đơn vị lưu trữ biệt lập có các bản sao (replica) dịch vụ Git riêng. Khi một tác nhân bắt đầu làm việc trên một dự án, CLI hỏi mặt phẳng điều khiển xem kho lưu trữ được lưu ở đâu. Mặt phẳng điều khiển trả về vị trí cùng thông tin xác thực tạm thời cho dịch vụ Git. Mặt phẳng điều khiển không bao giờ đọc hay ghi dữ liệu kho lưu trữ. Dịch vụ Git mới là bên quyết định những gì được đưa vào kho.

Dịch vụ Git: Di chuyển dữ liệu và điều phối cập nhật

Dịch vụ Git thực thi các thao tác Git và truyền nội dung kho lưu trữ cùng lịch sử phiên bản giữa các sandbox và bộ lưu trữ. Đây là một lớp bao mỏng quanh các lệnh phục vụ của chính Git. Dịch vụ hỗ trợ khám phá ref để cho máy khách biết head của kho lưu trữ đang ở đâu, upload-pack để clone và fetch, và receive-pack để nhận các đối tượng mới cùng yêu cầu dịch chuyển head của kho lưu trữ. Dịch vụ cũng phục vụ Git LFS API: với các tệp lớn và tệp nhị phân, dịch vụ cấp các liên kết ngắn hạn để sandbox có thể tải lên và tải xuống trực tiếp những tệp đó từ S3.

Chúng tôi bắt đầu với một máy chủ forge có sẵn, nhờ đó có thể tạo nguyên mẫu giao diện cho tác nhân và người dùng song song với việc xây dựng forge gọn nhẹ của riêng mình, chỉ tập trung vào các thao tác Git mà chúng tôi cần.

Dịch vụ gồm một nhóm bản sao (replica), mỗi bản sao là một thực thể đang chạy của cùng một máy chủ. Mỗi ô (cell) gom bộ lưu trữ dùng chung với một tập hợp bản sao và các dịch vụ hỗ trợ của chúng. Nhờ đó, các bản sao trong cùng một ô có thể truy cập cùng một hệ thống tệp dùng chung, thay vì phải duy trì các bản độc lập của mọi kho lưu trữ.

Nhờ bộ lưu trữ dùng chung này, các bản sao có thể hoạt động phi trạng thái. Bất kỳ bản sao nào trong ô cũng có thể phục vụ bất kỳ kho lưu trữ nào của ô đó, nên việc thay thế hoặc bổ sung bản sao không đòi hỏi di chuyển dữ liệu kho giữa các máy chủ. Các yêu cầu cho một kho lưu trữ thường được chuyển đến cùng một bản sao để bộ nhớ đệm của bản sao đó phát huy tác dụng, nhưng kho lưu trữ không phụ thuộc vào việc thực thể cụ thể đó phải luôn khả dụng.

Bước chấp nhận kiểm tra các bất biến của kho lưu trữ để đảm bảo mỗi commit được chấp nhận là một trạng thái hợp lệ của kho. Chúng tôi định nghĩa một hợp đồng rõ ràng cho mỗi kho lưu trữ, nhờ đó các bước kiểm tra tự động có thể ngăn kho phình to quá mức. Các tệp lớn và tệp nhị phân như PDF và hình ảnh được lưu qua Git LFS thay vì dưới dạng blob Git thô. Cơ chế nén (compaction) giữ lại lịch sử gần đây trong khi giới hạn kích thước của kho lưu trữ. Sau mỗi lượt gửi thành công, CLI hỏi dịch vụ Git xem kho có cần nén hay không. Nếu số commit được giữ lại vượt quá một ngưỡng, dịch vụ Git chỉ giữ lại một tập nhỏ hơn gồm các commit gần đây nhất. Lịch sử cũ hơn được thay bằng một ảnh chụp khởi đầu duy nhất, và các commit gần đây được phát lại để cập nhật mã định danh commit.

Cơ chế nén giữ lại các commit gần đây nhất, gộp lịch sử cũ hơn vào một gốc ảnh chụp duy nhất và phát lại các commit gần đây với mã định danh mới; head mới vẫn giữ nguyên các tệp.

Một bước đồng bộ hóa đơn giản kiểm soát các bên ghi đồng thời. Bước này theo dõi commit được chấp nhận mới nhất, còn gọi là head. Khi nhận được một lượt gửi, nó chỉ chấp nhận nếu lượt gửi đó được xây dựng trên head hiện tại. Nếu không, nó sẽ trả về một phản hồi có cấu trúc báo cơ sở đã lỗi thời (stale-base); khi đó, bên thua cần phát lại thay đổi của mình trên head mới và gửi lại. Thiết kế này đảm bảo các tác nhân chạy đồng thời không âm thầm ghi đè lên nhau, mà không gây chậm trễ đáng kể. Trong các quy trình làm việc thực tế của chúng tôi, chưa đến 2% lượt gửi bị từ chối do lỗi thời. Nhìn chung, độ trễ gửi trung vị dưới 1,7 giây và độ trễ p99 dưới 8 giây.

Hai tác nhân gửi đồng thời; một bên được chấp nhận, bên còn lại nhận phản hồi cơ sở lỗi thời (stale-base), phát lại trên head mới rồi gửi lại.

Dịch vụ Git cũng ghi lại mọi thay đổi được chấp nhận. Với mỗi lượt ghi được chấp nhận, dịch vụ thêm một mục vào hộp thư đi (outbox), tức một nhật ký liệt kê kho lưu trữ, commit mới, người dùng đã thực hiện thay đổi và các đường dẫn đã thay đổi. Các dịch vụ hạ nguồn như trình phân tích cú pháp đọc nhật ký này để tìm công việc mới.

Kết hợp lại, các thành phần này tạo nên một lớp quản lý kho lưu trữ, nhưng lược bỏ những phần mà tác nhân không cần đến. Pull request là không cần thiết, vì không có người nào xem xét từng thay đổi. Thay vào đó, dịch vụ Git kiểm tra hợp đồng tại thời điểm gửi, tác nhân thua trong cuộc tranh chấp sẽ áp dụng lại thay đổi của chính nó, và lịch sử commit ghi lại ai đã thay đổi những gì. Các bước kiểm tra tất định giữ mỗi kho lưu trữ trong phạm vi hợp đồng của nó, thay vì dựa vào người vận hành để quản lý mức tăng trưởng.

Lưu trữ: Giữ cho công việc bền vững

Lớp lưu trữ lưu giữ bền vững dữ liệu kho lưu trữ, độc lập với các sandbox và các bản sao dịch vụ Git. Các kho lưu trữ nằm trên AWS S3Files, dịch vụ cung cấp bộ lưu trữ dựa trên S3 thông qua giao diện hệ thống tệp mà Git nguyên bản có thể sử dụng mà không cần sửa đổi. Mỗi kho là một kho Git trần (bare) trên hệ thống tệp dùng chung, chứa các đối tượng và tham chiếu của kho thay vì một bản checkout làm việc.

Việc tách rời lưu trữ và tính toán cho phép sandbox chỉ tồn tại tạm thời. Mỗi tác nhân có sandbox riêng, và nhiều tác nhân có thể làm việc trên cùng một dự án mà không cần dùng chung máy. Nếu một sandbox gặp sự cố, chỉ những công việc chưa được gửi mới có nguy cơ bị mất.

Thay vào đó, chúng tôi có thể cấp cho mỗi dự án một sandbox tồn tại lâu dài mà mọi tác nhân của dự án cùng dùng chung, để các tệp của dự án nằm trên ổ đĩa của máy đó. Tuy nhiên, cách này sẽ gắn tài nguyên tính toán của các tác nhân với nơi máy đó chạy và đòi hỏi máy phải có cấu hình đáp ứng được những giai đoạn bận rộn nhất. Máy đó cũng cần duy trì ổn định trong nhiều tháng, với việc sao lưu và khôi phục được quản lý như một phần của hệ thống lưu trữ của dự án.

Một sandbox tồn tại lâu dài được các tác nhân của dự án dùng chung, so với các sandbox ngắn hạn cho từng tác nhân, truy cập bộ lưu trữ dùng chung bền vững thông qua các bản sao dịch vụ Git phi trạng thái.

Xử lý hạ nguồn: Giúp tác nhân đọc được tài liệu

Thành phần hạ nguồn chính là một quy trình xử lý phân tích cú pháp, có nhiệm vụ trích xuất văn bản và siêu dữ liệu từ các tài liệu mới được thêm hoặc cập nhật, giúp tác nhân dễ dàng đọc các tệp dự án. Một worker phân tích cú pháp nhận các cập nhật từ hàng đợi luồng thay đổi, xác định các tệp đã thay đổi từ siêu dữ liệu commit và tìm nạp các byte thô bằng mã băm nội dung. Sau đó, worker phân tích tài liệu để tạo ra văn bản trích xuất và siêu dữ liệu tài liệu.

Kết quả phân tích được lưu bên ngoài kho lưu trữ, trong một kho dữ liệu được đánh khóa theo mã băm của tài liệu nguồn. Các kết quả này không bao giờ được commit ngược vào kho lưu trữ, vì điều đó sẽ làm lịch sử lộn xộn một cách không cần thiết và làm tăng số lượt ghi đồng thời. Thay vào đó, kết quả phân tích đến được sandbox thông qua checkout và đồng bộ. Mỗi bản checkout có một thư mục dành riêng mà CLI dùng để hiện thực hóa các kết quả này. Việc phân tích diễn ra bất đồng bộ, nên worker phân tích cú pháp chạy nền không chặn các lượt checkout.

Cách tác nhân sử dụng không gian làm việc

Tác nhân khám phá phiên bản kho lưu trữ được tải vào sandbox bằng các công cụ hệ thống tệp tiêu chuẩn. Thay vì đi theo một quy trình cố định là tìm kiếm rồi đọc, chúng liệt kê thư mục, tìm kiếm nội dung tệp bằng grep, đọc các đoạn liên quan và dùng những gì tìm được để quyết định nơi cần xem tiếp theo.

Tương tự Computer, Search cũng áp dụng cách tiếp cận này thông qua các công cụ tệp tiêu chuẩn. Một tác nhân khám phá riêng biệt tìm kiếm trong dự án với ngân sách hạn chế hơn và trả về các đường dẫn tệp liên quan cùng các trích đoạn hỗ trợ. Sau đó, mô hình trả lời đọc các tệp đã chọn và tạo ra câu trả lời. Việc tái sử dụng một sandbox dự án hiện có giúp giảm thời gian thiết lập: gắn vào một bản checkout đã sẵn sàng mất khoảng 2,9 giây, so với khoảng 8 giây khi khởi động nguội.

Các sandbox của Computer, tác nhân con khám phá của Ask, các bên ghi tri thức chạy nền và các worker phân tích cú pháp đều đọc và ghi vào cùng một kho lưu trữ và outbox.

Văn bản đã phân tích giúp các tài liệu lớn hơn như PDF và tệp Office có thể được tìm kiếm bằng chính những công cụ đó. Trước tiên, tác nhân kiểm tra một manifest, tức danh sách cho biết tài liệu nào đã có văn bản trích xuất, sau đó tìm kiếm và đọc văn bản đó như các tệp thông thường. Tác nhân chỉ tải xuống tài liệu gốc khi văn bản không đủ, chẳng hạn để xem hình minh họa, bố cục hoặc dữ liệu nhúng.

Chúng tôi đã đánh giá phương pháp này so với tìm kiếm ngữ nghĩa trên chỉ mục, với 150 câu hỏi tài chính dựa trên một tài liệu duy nhất trên cùng một kho ngữ liệu. Tác nhân khám phá đạt 0,867 về truy xuất đúng tài liệu và 0,627 về trả lời đúng, so với khoảng 0,39 và 0,37 của tìm kiếm ngữ nghĩa, tức tốt hơn khoảng 1,7 lần về câu trả lời và 2 lần về truy xuất, với độ trễ thấp hơn khoảng 25%. Tác nhân khám phá chủ yếu làm việc với văn bản trích xuất và hiếm khi tải xuống các tệp PDF gốc.

So sánh phương pháp khám phá với tìm kiếm tệp theo ngữ nghĩa trên bộ đánh giá chuẩn nội bộ.

Một hạ tầng dùng chung

Bộ nhớ lâu dài của Computer sử dụng cùng một hạ tầng hệ thống tệp. Perplexity Brain, wiki tri thức của Computer, lưu bộ nhớ trong các kho tri thức có lịch sử và chính sách riêng. Việc tách biệt tri thức khỏi các tệp dự án giúp các cập nhật bộ nhớ chạy nền không tranh chấp với những chỉnh sửa trên các tệp đó. Một phiên cần cả hai sẽ tải cả hai kho lưu trữ.

Các tác nhân chạy nền đọc tri thức hiện có, bổ sung thông tin mới và lưu các trang đã cập nhật dưới dạng commit. Các tác nhân khác đọc những trang đó bằng công cụ tệp thông thường, và con người cũng có thể chỉnh sửa chúng. Bên ghi chia sẻ công việc qua kho lưu trữ thay vì phối hợp trực tiếp với từng bên đọc. Lịch sử commit ghi lại ai đã thay đổi những gì, còn outbox thông báo các cập nhật được chấp nhận cho các dịch vụ hạ nguồn. Con người và tác nhân có thể tiếp nối công việc của nhau, kèm theo bản ghi về quá trình phát triển của tri thức.

Kết luận

Khi con người và tác nhân cùng chia sẻ một dự án, không gian làm việc không chỉ dùng để lưu trữ tệp. Nó mang đến một nơi chung để kết hợp các đóng góp và theo dõi những gì đã thay đổi. Git đã cung cấp phần lớn nền tảng đó. Chúng tôi bổ sung khả năng điều phối và các bước kiểm tra tự động để tác nhân có thể gửi công việc mà không cần người phê duyệt từng cập nhật. Kết quả là một forge được tinh giản về những gì thiết yếu nhất, bởi về bản chất, cộng tác giữa các tác nhân và phát triển phần mềm với nhiều người đóng góp là cùng một bài toán.

Các tác nhân làm việc trong những sandbox tạm thời, độc lập, đồng thời đóng góp vào các kho lưu trữ bền vững. Giới hạn kho lưu trữ giúp kiểm soát mức tăng trưởng, cơ chế tải xuống chủ động cho phép tác nhân chọn những gì cần tìm nạp, và các tệp thông thường cho phép chúng khám phá bằng những công cụ quen thuộc. Các cập nhật chạy nền, chỉnh sửa tương tác và tác vụ theo lịch có thể tiếp nối công việc của nhau mà không cần phối hợp trực tiếp.

Khi ngày càng nhiều tác nhân làm việc tự chủ bên trong Dự án, không gian làm việc chung của chúng phải luôn đáng tin cậy và dễ hiểu đối với con người. Mục tiêu rất rõ ràng: mỗi thay đổi phải tồn tại bền vững hơn tác nhân đã tạo ra nó, sẵn sàng cho cộng tác viên tiếp theo và để lại bản ghi rõ ràng về những gì đã thay đổi.

Trích dẫn

BibTeX
@online{perplexity2026BuildingSharedWorkspacesForPeopleAndAgents,
  author = {{Perplexity} and Se Won Jang and Peter Hart and Kartik Kapur and Kevin Lau and Sidhant Rajadnya and Ishbir Singh and Thomas Wang and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{Building shared workspaces for people and agents}},
  date = {2026-10-12},
  url = {https://www.perplexity.ai/hub/blog/building-shared-workspaces-for-people-and-agents}
}