Sierra ra mắt Agency: Hạ tầng sandbox an toàn và linh hoạt cho AI Agent

Đây là một phần trong loạt bài viết về cách chúng tôi "AI-pilling" (tích hợp AI vào mọi khía cạnh) tại Sierra.

Trong vài bài viết gần đây, chúng tôi đã thảo luận về những gì xảy ra khi mỗi nhân viên sở hữu một AI agent duy nhất có tên là Pinecone: công việc được hoàn thành nhanh hơn, kiến thức nội bộ được tích lũy, và agent có thể tương tác an toàn với các hệ thống của công ty để lấy ngữ cảnh cần thiết thông qua MCP Gateway.

Trước khi có Pinecone, không hiếm gặp cảnh các kỹ sư đi lại quanh văn phòng với chiếc laptop mở hé — không phải vì họ đang làm việc, mà vì các AI agent của họ đang chạy. Đóng nắp máy lại, agent sẽ dừng hoạt động. Đi ăn trưa quay về, bạn có thể thấy nó đang chờ phê duyệt sau khi không thực hiện được tiến triển nào trong suốt một giờ đồng hồ.

Hạn chế này, cùng với những yếu tố khác, đã củng cố một điều mà chúng tôi bắt đầu nhận ra: phần khó nhất khi xây dựng các agent tuyệt vời không còn nằm ở mô hình (model) nữa — mà là mọi thứ xung quanh nó. Đó là lý do Agency ra đời, một cơ sở hạ tầng cung cấp cho mỗi phiên làm việc của Pinecone và mỗi tác vụ của Ghostwriter (agent chuyên xây dựng agent cho khách hàng của chúng tôi) một nơi an toàn để lưu trữ và vận hành.

Khởi đầu nguyên mẫu: Môi trường là yếu tố quan trọng nhất

Cả Pinecone và Ghostwriter đều bắt đầu dưới dạng các nguyên mẫu: những sandbox biệt lập được đóng gói trên một máy ảo (VM) duy nhất. Chúng được xây dựng bởi các kỹ sư từ những đội ngũ khác nhau, mỗi người đều cố gắng giải quyết các vấn đề tương tự cho những đối tượng khác nhau. Thành công ban đầu của cả hai nguyên mẫu đã chứng minh giả thuyết của chúng tôi. Các mô hình đã đủ thông minh cho những tác vụ lập trình phức tạp: chính môi trường, công cụ và khả năng tự xác thực công việc bao quanh mô hình mới là thứ quyết định tốc độ tiến triển.

Quay lại ví dụ về những chiếc laptop mở hé: Việc chạy agent với `--allow-dangerously-skip-permissions` hoặc `sandbox_mode = “danger-full-access”` thực sự không phải là một lựa chọn khả thi. Điều đó đồng nghĩa với việc agent sẽ chạy bằng token truy cập của nhà phát triển, vốn có quyền ghi vào các hệ thống quá nguy hiểm để cấp cho một agent, đặc biệt là một agent không có người giám sát.

Để mang lại sự tự chủ an toàn cho cả Pinecone và Ghostwriter, cả hai nguyên mẫu đều có khái niệm về sandbox: các môi trường biệt lập mà tại đó chúng tôi có thể kiểm soát những gì agent được phép truy cập. Sau đó, chúng tôi có thể chạy chúng ở chế độ “full-access”. Tuy nhiên, các nguyên mẫu này bị giới hạn về số lượng sandbox có thể chạy đồng thời trước khi bị cạn kiệt tài nguyên.

Để thực sự khai phá tiềm năng của các sản phẩm này, chúng tôi cần một nguyên thủy (primitive) mới, với các sandbox có khả năng:

Tại sao chúng tôi tự xây dựng: Lĩnh vực này vẫn còn quá mơ hồ

Có những nhà cung cấp sandbox thương mại rất tốt (mặc dù khi chúng tôi bắt đầu thì số lượng ít hơn). Khi vấn đề đã được hiểu rõ và các đánh đổi của giải pháp có sẵn đã được biết đến, đó là một yếu tố thúc đẩy rất lớn — tại sao phải tự xây dựng blob store khi đã có S3 và GCS? Hơn nữa, cơ sở hạ tầng hoàn thiện cho phép bạn tập trung vào những gì tạo nên sự khác biệt cho sản phẩm của mình.

Nhưng sandbox cho agent vẫn chưa phải là một vấn đề hoàn thiện. Khi vấn đề chưa được xác định rõ ràng, hoặc chưa rõ đâu là sự đánh đổi phù hợp, bạn sẽ phải kế thừa các giả định của người khác và dành thời gian để tìm cách giải quyết chúng thay vì hiểu rõ vấn đề của chính mình. Vì vậy, chúng tôi quyết định tự xây dựng.

Vào thời điểm đó, các nhà cung cấp sandbox thường có những giới hạn cứng về lượng tài nguyên bạn có thể gán cho mỗi sandbox, hoặc giới hạn nghiêm ngặt về thời gian tồn tại của một sandbox, hay số lượng sandbox có thể chạy cùng lúc. Những ràng buộc đó sẽ trở thành ràng buộc của Pinecone hoặc Ghostwriter. Từ góc độ người dùng, họ sẽ cảm thấy điều đó thật vô lý: Tại sao agent của tôi không thể chạy qua đêm? Tại sao bản build của tôi lại chậm hơn so với trên laptop?

Cuối cùng, mục tiêu xây dựng của chúng tôi bao gồm hai phần:

Hình hài của Agency… và cách hầu hết các agent dành cả đời để chờ đợi

Agency là lớp điều phối sandbox cho agent của chúng tôi. Được đặt tên dựa trên cả việc trao quyền tự chủ cho agent – khả năng (agency) để thực hiện tác vụ một cách tự động – và là nơi các agent thực hiện công việc của mình, Agency được xây dựng như một ứng dụng Kubernetes thuần túy với hai lớp chính:

Lớp không trạng thái (stateless layer) cung cấp các API như `CreateRunnerInstance` và `DeleteRunnerInstance`, cho phép các ứng dụng xây dựng trên nền tảng Agency có thể cấp phát các runner theo yêu cầu. Nó xác thực các yêu cầu bằng IAM, quản lý các template và quyền hạn của runner, theo dõi trạng thái runner trong DynamoDB, và chuyển đổi mỗi định nghĩa runner thành một pod Kubernetes. Bản thân các runner chính là môi trường thực thi: mỗi runner nhận được tài nguyên tính toán chuyên dụng, bộ lưu trữ bền vững cho các kho lưu trữ (repo) và các artifact của bản build, cùng mọi thứ cần thiết để hoạt động như một máy trạm của lập trình viên.

Lớp runner có trạng thái (stateful runner layer) là nơi môi trường agent hoạt động, bao gồm tất cả các pod theo yêu cầu được tạo bởi mặt phẳng điều khiển (control plane). Mỗi pod thường chứa một Persistent Volume (được hỗ trợ bởi dịch vụ lưu trữ khối trên đám mây) để agent kiểm tra các repo, build code, v.v.

Bảo mật là yêu cầu bắt buộc

Chúng tôi biết rằng các runner cuối cùng sẽ cần làm việc với dữ liệu nhạy cảm của khách hàng trong khi vẫn phải tạo và chạy các đoạn mã không đáng tin cậy. Điều đó có nghĩa là bảo mật không thể là thứ được thêm vào sau, mà phải là một phần của chính kiến trúc. Chúng tôi cũng thống nhất yêu cầu rằng các agent không được phép truy cập mặc định vào bất kỳ khóa API hay thông tin bí mật nào, vì việc một agent bị "jailbreak" lấy cắp chúng là điều quá dễ dàng.

Việc giải quyết các yêu cầu bảo mật ngay từ đầu đã dẫn đến một số quyết định về kiến trúc, chẳng hạn như:

Hầu hết các agent dành thời gian để chờ đợi

Mặc dù chúng tôi dự tính sẽ tạo ra một số lượng lớn các runner instance, trực giác của chúng tôi cho thấy chỉ một phần nhỏ trong số đó thực sự làm việc tại bất kỳ thời điểm nào. Điều này chủ yếu dựa trên quan sát rằng các agent không có người giám sát dành phần lớn thời gian để chờ đợi đầu vào từ người dùng thay vì streaming token và thực hiện công việc. Điều này đã được chứng minh là đúng. Thường có sự khác biệt từ 2 đến 4 bậc độ lớn giữa số lượng runner instance hoạt động trong 8 giờ qua so với 8 ngày qua.

Nếu chúng ta có thể linh hoạt (và một cách minh bạch!) tắt các agent nhàn rỗi và khởi động lại khi cần, thì chúng ta có thể hỗ trợ cấp cho mỗi runner nhiều tài nguyên hơn mức có thể trên một nhóm node tương đối nhỏ. Quan sát đó đã dẫn đến một trong những nguyên thủy cốt lõi của Agency: runner hibernation (chế độ ngủ đông của runner). Để làm cho việc ngủ đông của runner trở nên minh bạch đối với các ứng dụng như Pinecone và Ghostwriter, chúng tôi cần tách biệt giao tiếp giữa runner và ứng dụng để runner không thể truy cập trực tiếp từ ứng dụng. Thay vào đó, ứng dụng và runner giao tiếp với nhau bằng cách truyền tin nhắn.

Một runner instance có thể được mô hình hóa như một Máy trạng thái hữu hạn (Finite State Machine - FSM). Các ứng dụng xếp hàng các tin nhắn gửi đến một instance cụ thể vào hàng đợi đầu vào của nó, và khi xử lý tin nhắn đó, runner có thể thay đổi trạng thái của mình. Bất cứ lúc nào, nếu runner muốn giao tiếp với thế giới bên ngoài, nó sẽ thực hiện bằng cách xếp hàng một tin nhắn vào hàng đợi đầu ra, sau đó được ứng dụng tiêu thụ. Theo cách này, cả runner instance và ứng dụng đều không cần phải giao tiếp đồng bộ với nhau để phát triển trạng thái FSM. Bằng cách sử dụng triển khai hàng đợi trong bộ nhớ, như Elasticache Redis Streams, và giới hạn kích thước của các sự kiện (vài trăm KiB), chúng ta có thể làm cho các vòng lặp đủ nhanh (p50: 8ms, p99: 40ms) khi cả hai bên đều trực tuyến.

Điều này để lại vấn đề khôi phục trạng thái của FSM sau khi ngủ đông. Vì một runner instance là singleton và chỉ nó mới xếp hàng bất cứ thứ gì vào hàng đợi đầu ra, hàng đợi đầu ra có thể được sắp xếp nghiêm ngặt và được coi là một bản ghi chỉ thêm (append-only log). Nếu runner instance định kỳ phát ra các sự kiện checkpoint, thuộc tính chỉ thêm, có thứ tự này có thể được sử dụng để khôi phục trạng thái runner instance: phát lại các sự kiện từ hàng đợi đầu ra kể từ sự kiện checkpoint cuối cùng trở đi. Trách nhiệm của runner dành riêng cho ứng dụng là quyết định những gì có trong các sự kiện checkpoint và delta — chúng là các thông điệp proto mờ đối với mặt phẳng điều khiển Agency. Sau khi việc phát lại sự kiện hoàn tất, runner có thể quay lại tiêu thụ hàng đợi đầu vào cho các hoạt động thông thường.

Đối với Pinecone và Ghostwriter, không có gì thay đổi. Một runner chỉ đơn giản là thức dậy và tiếp tục làm việc. Bên dưới, Agency đã thu hồi tài nguyên tính toán, khôi phục trạng thái của runner và tiếp tục thực thi mà ứng dụng không hề hay biết.

Những bài học kinh nghiệm

Có một vài thách thức khác mà chúng tôi đã giải quyết, và nhìn chung chúng tôi rút ra được một vài bài học then chốt:

Xây dựng các nguyên thủy có khả năng kết hợp, không phải các giải pháp dùng một lần. Triết lý tương tự đã dẫn dắt chúng tôi xây dựng MCP Gateway lại được áp dụng với Agency. Thay vì xây dựng một nền tảng dành riêng cho Pinecone hay Ghostwriter, chúng tôi đã xây dựng một nguyên thủy chung cho việc thực thi agent an toàn. Quyết định đó giúp việc tái sử dụng Agency trên nhiều sản phẩm trở nên dễ dàng, kể cả những sản phẩm mới mà chúng tôi chưa hình dung ra. Mức độ kết hợp tăng lên khi mỗi phần tự giải quyết một vấn đề duy nhất, đưa ra các giả định tối thiểu về cách nó được sử dụng trong bức tranh tổng thể.

Việc kiểm soát stack agent nội bộ mang lại hiệu quả. Khi bạn không bị phụ thuộc vào nhà cung cấp bên thứ ba để loại bỏ các rào cản, bạn có thể mở khóa năng suất. Ví dụ, chúng tôi đã có thể xây dựng “Ephemeral Sessions” trong Pinecone dưới một tuần. Những phiên này là nơi duy nhất cho phép tải dữ liệu khách hàng, do đó, nó có các giới hạn về nguồn gốc dữ liệu, tính bền vững và khả năng hiển thị. Vì chúng tôi kiểm soát việc điều phối, sandbox cho agent, MCP Gateway và trải nghiệm người dùng cuối, đây chỉ là một tính năng khác của Pinecone mà chúng tôi đã xây dựng bằng Pinecone và triển khai nhanh chóng.

Hãy nỗ lực xây dựng phần mềm "nhàm chán". Phần mềm nên nhàm chán. Nó nên trao quyền cho người dùng đạt được mục tiêu của họ trong khi vẫn đơn giản để sử dụng và đáng tin cậy để vận hành. Agency là một trong những dịch vụ "nhàm chán" nhất mà chúng tôi vận hành (theo nghĩa tích cực!): nó là lớp vô hình giữ cho sự tập trung của chúng tôi ở nơi quan trọng nhất — tại lớp ứng dụng Pinecone và Ghostwriter, nơi chúng tôi có tiềm năng tạo ra tác động lớn nhất với người dùng.

Xây dựng phần mềm đơn giản, nhàm chán là việc cực kỳ khó — và thực sự rất thú vị!