Hầu hết các framework agent hiện nay đều giả định môi trường desktop. Một người dùng, một máy, một tiến trình. Agent chạy khi laptop mở, ghi vào hệ thống tệp cục bộ, lưu khóa API trong biến môi trường, và tắt khi terminal đóng. Khi có lỗi, người dùng thử lại. Khi agent cần một package, pip install sẽ đưa nó vào Python của người dùng. Trạng thái, bí mật và vòng đời — tất cả đều nằm trong một ranh giới tin cậy duy nhất.
Cơ sở hạ tầng agent trên đám mây không có những đặc quyền đó.
Agent chạy trên một sandbox khởi động mới tinh, trên phần cứng dùng chung với người lạ, được kích hoạt bởi những người gọi mà người dùng chưa từng gặp: một lịch trình, một yêu cầu HTTP, một agent khác. Người dùng thường đang ngủ khi quá trình chạy diễn ra. Mã bên trong sandbox có thể là mã thù địch. Hệ thống tệp phải tồn tại qua các lần triển khai. Thông tin xác thực không thể sống cùng nơi agent sống. Mọi đảm bảo mà desktop cho bạn miễn phí — tính bền vững, danh tính, độ tin cậy mạng, thử lại — đều phải được xây dựng lại như một hệ thống tường minh.
Chúng tôi đã dành vài tháng qua để siết chặt lớp đó tại CREAO. Hai bài học đã xuất hiện. Nếu bạn từng triển khai một agent trên desktop và tự hỏi điều gì thay đổi khi nó chuyển lên đám mây, thì đây là những thay đổi đó.
Bài học 1: Tách biệt những thứ thay đổi chậm khỏi những thứ thay đổi nhanh
Trên desktop, môi trường của người dùng và runtime của agent là một thứ, được cập nhật cùng nhịp, bởi cùng một người. Trên đám mây, chúng là hai thứ khác nhau.
Một ứng dụng agent tích lũy trạng thái về phía nền tảng. Một nhà phân tích chứng khoán cài đặt matplotlib, tải dữ liệu thị trường, viết script vẽ biểu đồ. Môi trường đó là trí nhớ cơ bắp của agent. Chúng tôi đóng băng nó thành một ảnh chụp sandbox ngay khi người dùng hài lòng, và giữ ảnh chụp đó đông lạnh cho đến khi người dùng chỉnh sửa môi trường lại. Mỗi lần chạy đều khởi động từ cùng một image. Cùng packages, cùng tệp, cùng phiên bản. Chạy thứ Hai giống như chạy thứ Sáu, bởi vì không có gì bên dưới thay đổi.
Đây là thuộc tính mà các framework desktop không thể cho bạn miễn phí. Một lần pip install sáu tháng trước giờ đây sẽ trỏ tới các phiên bản khác. Một ảnh chụp trên đám mây trỏ tới cùng một byte mãi mãi. Khả năng tái lập là thứ mà nền tảng nợ người dùng, và một ảnh chụp đông lạnh là cách rẻ nhất để mang lại nó.
Sau đó, vấn đề kết nối xuất hiện.
Cùng một image đóng băng môi trường của người dùng cũng chứa mã runner — thư viện harness nhỏ do chúng tôi phát triển để quản lý agent trong mỗi lần chạy. Người dùng muốn môi trường của họ đứng yên. Chúng tôi muốn runner của mình được triển khai nhiều lần trong ngày. Một artifact, hai yêu cầu đối lập.
Giải pháp đầu tiên của chúng tôi rất thô thiển. Khi khởi động, kiểm tra xem runner bên trong ảnh chụp có khớp với phiên bản vừa triển khai không. Nếu không, loại bỏ ảnh chụp và khởi động từ một template sạch. Nó hoạt động, và không ai phàn nàn. Chỉ có lần chạy đầu tiên sau khi triển khai mới bị ảnh hưởng.
Các lần chạy không giám sát đã phá vỡ lớp bảo vệ đó. Một cron job lúc 9h sáng thứ Hai không nên mất môi trường chỉ vì chúng tôi triển khai lúc 8:55. Cam kết mà chúng tôi đang lặng lẽ vi phạm — "môi trường của bạn bị đóng băng cho đến khi bạn thay đổi nó" — đã bị phơi bày.
Chúng tôi mất nhiều thời gian hơn mức cần thiết để nhận ra giải pháp. Môi trường của người dùng và mã runner thay đổi với tốc độ hoàn toàn khác nhau. Người dùng chỉnh sửa agent khi họ muốn. Chúng tôi triển khai nền tảng nhiều lần trong ngày. Coi chúng như một artifact buộc chúng tôi phải chọn lựa mỗi lần triển khai: giữ mã runner cũ, hoặc phá hủy môi trường đông lạnh mà người dùng đã yêu cầu chúng tôi bảo tồn.
Mô hình chúng tôi đi đến cuối cùng vay mượn từ cách hệ điều hành xử lý các bản cập nhật. Kernel thay đổi. Thư mục home của bạn thì không. Bạn không xóa toàn bộ ổ cứng để cài một bản vá bảo mật.
Chúng tôi vẽ cùng một ranh giới. Sandbox khởi động từ ảnh chụp đông lạnh của người dùng, không bị chạm đến. Sau đó chúng tôi hot-swap chỉ duy nhất runner. Trình tự:
- Đặt runner mới vào một thư mục tạm thời bên trong sandbox.
- Xác thực nó bằng
node --checkđể bắt lỗi cú pháp trước khi chạm vào bất cứ thứ gì đang hoạt động. - Hoán đổi nguyên tử: mở khóa flag bất biến trên runner cũ, sao chép runner mới vào, khóa lại bằng
chattr +i, sau đó ẩn chính binarychattrđể mã sandbox không thể đảo ngược khóa. - Xóa V8 compile cache (
/home/user/.cache/v8-compile-cache/*) để tệp mới thực sự được tải thay vì chạy bytecode cũ. - Nếu bất kỳ bước nào thất bại, tiêu diệt sandbox và thử lại với một sandbox mới. Không có trạng thái nửa nâng cấp nào từng chạy agent.
Toàn bộ quá trình hoán đổi mất khoảng 300 mili giây. Chúng tôi chụp lại ảnh sau một lần chạy thành công chỉ khi mã runner đã được hoán đổi, ghi mã cập nhật vào image của người dùng để lần chạy sau bỏ qua bước hoán đổi. Việc triển khai nền tảng không bao giờ loại bỏ trạng thái của người dùng; chúng tích hợp runner mới vào trong đó. Các package, tệp và tùy chỉnh của người dùng được giữ nguyên không thay đổi.
Nếu bạn chỉ nhớ một điều từ bài học này, đó là câu hỏi chẩn đoán. Đối với bất cứ thứ gì bạn duy trì trên nền tảng đám mây, hãy hỏi: ai kiểm soát nhịp độ thay đổi trên artifact này? Nếu cả người dùng và nền tảng đều sở hữu nó, cuối cùng bạn sẽ phải trả giá cho sự kết nối. Hãy tách artifact theo ranh giới sở hữu và để mỗi bên cập nhật theo đồng hồ riêng của mình.
Bài học 2: Giữ bí mật bên ngoài ranh giới thực thi
Đây là bài học phân tách cơ sở hạ tầng agent trên đám mây khỏi mọi thứ khác.
Một agent trên desktop chạy với tư cách người dùng. Nó sử dụng khóa của người dùng, trên máy của người dùng, trong mạng của người dùng. Một agent trên đám mây chạy với tư cách không ai cả, trên phần cứng dùng chung, trên internet mở, thực thi mã mà LLM viết từ một prompt có thể đã bị thù địch. Mô hình bảo mật phải giả định mã bên trong sandbox đã bị xâm phạm, chứ không phải hy vọng điều ngược lại.
Quy tắc chúng tôi giữ rất đơn giản. Không có thông tin xác thực tồn tại lâu dài nào từng sống bên trong sandbox.
Khi một agent cần gọi một dịch vụ có xác thực — Slack, GitHub, API riêng của người dùng — nó không giữ token. Nó gửi một yêu cầu HTTP cục bộ đến một cầu nối API chạy bên ngoài sandbox. Cầu nối đính kèm token OAuth ở phía host và chuyển tiếp cuộc gọi. Phản hồi quay về mà không có token nào từng đi vào bộ nhớ hoặc môi trường của sandbox.
Phần thú vị là cách cầu nối biết sandbox được phép yêu cầu đó. Hai bước kiểm tra, được xếp lớp có chủ đích.
Đầu tiên, danh sách trắng IP. Cầu nối chỉ chấp nhận kết nối từ dải mạng nội bộ mà các host sandbox của chúng tôi hoạt động. Một cuộc gọi từ bất kỳ nơi nào khác — laptop của nhà phát triển, một URL bị rò rỉ, internet công cộng — bị chặn ở lớp mạng trước khi bất kỳ mã ứng dụng nào chạy. Điều này ghim cầu nối vào một cơ sở hạ tầng vật lý duy nhất và khiến nó vô dụng với bất kỳ ai bên ngoài.
Thứ hai, một JWT tồn tại ngắn được tạo ra mỗi lần chạy. Khi sandbox khởi động, nền tảng ký một token có phạm vi cụ thể cho lần chạy đó: người dùng nào, ứng dụng nào, phiên nào, với thời gian hết hạn bao phủ thời gian chạy và không hơn. Sandbox trình token này trên mọi cuộc gọi đến cầu nối. Cầu nối xác minh chữ ký, kiểm tra thời hạn, và chỉ sau đó mới giải quyết thông tin xác thực đã lưu của người dùng và đính kèm chúng ở phía máy chủ. Nếu sandbox bị chiếm quyền, kẻ tấn công nhận được một token kết thúc với lần chạy và chỉ ủy quyền các cuộc gọi có phạm vi trong phiên đó. Không có thông tin xác thực chủ chốt nào để đánh cắp.
Cùng cầu nối này mang các khoản khấu trừ thanh toán, nhật ký và số liệu ra ngoài, vì vậy nó là giao diện duy nhất vượt qua ranh giới sandbox theo cả hai hướng. Mọi thứ khác bên trong sandbox được coi là đã bị xâm phạm theo mặc định.
Nếu một prompt injection thuyết phục agent đổ process.env vào một webhook vào ngày mai, kẻ tấn công sẽ nhận được một JWT tồn tại ngắn chỉ hoạt động từ bên trong mạng của chúng tôi và hết hạn với lần chạy. Thuộc tính đó là thứ cho phép chúng tôi chạy mã người dùng không đáng tin cậy trên cơ sở hạ tầng dùng chung mà không mất ngủ.
Mô hình bên dưới
Cơ sở hạ tầng agent trên đám mây đáng tin cậy, an toàn không phải là một hệ thống mới lạ. Nó là một vài thuộc tính được giữ mà không có ngoại lệ:
- Trạng thái sống trong sandbox, bị đóng băng cho đến khi người dùng thay đổi nó.
- Mã có thể hot-swappable, độc lập với trạng thái.
- Thông tin xác thực sống ở phía host, không bao giờ bên trong agent.
- Một pipeline thực thi duy nhất phục vụ mọi người gọi, bất kể kích hoạt là con người, bộ lập lịch, hay một phần mềm khác.
Thuộc tính cuối cùng đó là điểm mấu chốt của toàn bộ thiết kế. Một hàm executeAgent xử lý các cú nhấp chuột UI, các lần chạy theo lịch, và các cuộc gọi API. Hệ thống thanh toán, nhật ký khấu trừ tín dụng, các tín hiệu quan sát — tất cả đều giống hệt nhau bất kể con người nhấn Run, cron kích hoạt hay script gọi API. Thêm một bề mặt kích hoạt mới chỉ là thay đổi định tuyến, không phải thay đổi kiến trúc. Bản thân agent không biết và không quan tâm ai đã kích hoạt.
Đó là những gì framework desktop không thể cho bạn, và là điều làm cho phiên bản đám mây đáng để xây dựng. Một agent trên laptop bị ràng buộc vào laptop. Một agent trên đám mây là một hàm mà phần còn lại của stack của bạn có thể gọi. Người dùng viết nó một lần. Nền tảng đảm bảo nó tồn tại qua các lần triển khai, chạy an toàn trên phần cứng dùng chung, và chấp nhận những người gọi mà người dùng không bao giờ lường trước.
Một agent là một hàm với giao diện ngôn ngữ tự nhiên. Việc triển khai thuộc về người dùng. Bề mặt kích hoạt, runtime, ranh giới bảo mật của nó thuộc về nền tảng. Kỷ luật là xây dựng các lớp sao cho mỗi lớp phát triển theo đồng hồ riêng, và dành thời gian tìm ra các khe hở giữa các hệ thống trước khi người khác làm điều đó.
Đó là điều làm cho bề mặt tiếp theo trở nên rẻ để triển khai, và an toàn để triển khai.
