Tác giả bài viết: @SantoshPraneeth và @jeffizhungry
Flux là nền tảng agent dựa trên đám mây của DoorDash dành cho kỹ sư. Chỉ trong một tháng của năm 2026, chúng tôi đã sử dụng Flux để tự động hóa 130.000 tác vụ kỹ thuật. Ra mắt vào quý 1 năm 2026 và đang mở rộng nhanh chóng, Flux hiện vận hành các quy trình nền khối lượng lớn trên toàn DoorDash, bao gồm hơn 25.000 lượt review mã tự động mỗi tuần, cùng hơn 300 playbook riêng biệt và hơn 10.000 lượt gọi được sử dụng mỗi tuần. Các quy trình này có thể chạy không cần giám sát, song song, 24/7.
Chúng tôi sẽ trình bày chi tiết về những giới hạn đã thúc đẩy chúng tôi vượt ra khỏi các workload agent chạy cục bộ trên laptop, lý do chúng tôi chọn tự xây dựng Flux nội bộ thay vì chỉ dựa vào các coding agent được lưu trữ bên ngoài, cùng các thành phần nền tảng như agent sandbox, MCP gateway, playbook và invocation surface để giúp việc ủy quyền cho agent trở nên lặp lại được và an toàn.
Các trường hợp sử dụng background workflow của Flux
Tổng quan về mức độ sử dụng Flux trên toàn DoorDash trong một tháng, bao gồm review mã tự động, các lần chạy playbook và hoàn thành các tác vụ nền
Điểm khởi đầu
Trong năm qua, người dùng chạy các workload agentic trên laptop đã nhanh chóng chạm phải những giới hạn:
- Tài nguyên và tính sẵn sàng. Laptop có số lượng lõi CPU cố định, bộ nhớ hạn chế và pin, tất cả đều được chia sẻ với mọi ứng dụng trên máy. Các quy trình agentic thường cần chạy song song những tác vụ tốn nhiều tài nguyên như build, test và tìm kiếm quy mô lớn, khiến laptop nhanh chóng cạn kiệt dung lượng. Các quy trình này cũng phụ thuộc vào việc thiết bị được bật nguồn, kết nối và sẵn sàng; công việc sẽ bị gián đoạn khi kỹ sư đóng laptop, mất kết nối hoặc rời khỏi máy.
- Kiểm soát an toàn. Laptop thường có quyền truy cập rộng rãi vào các thông tin xác thực và hệ thống nhạy cảm, bao gồm SSH key, phiên VPN và các công cụ đã xác thực. Cấp cho một agent tự hành cùng mức truy cập đó sẽ tạo ra rủi ro không cần thiết và phạm vi ảnh hưởng tiềm ẩn lớn. Môi trường cục bộ cũng khiến việc giới hạn chặt chẽ những gì agent có thể truy cập và trong bao lâu trở nên khó khăn hơn.
- Khả năng quan sát và kiểm toán. Khi workload chạy rải rác trên từng laptop riêng lẻ, việc thực thi bị phân mảnh và khó giám sát. Việc hiểu rõ cái gì đang chạy, chạy ở đâu, thay mặt ai và đã tác động đến những hệ thống hay tệp tin nào trở nên khó khăn hơn.
Luận điểm của chúng tôi để giải quyết những vấn đề này rất đơn giản:
Giao các tác vụ cho các coding agent tự hành, an toàn, để kỹ sư có thể dành nhiều năng lượng hơn cho đổi mới, tư duy phản biện và giải quyết các vấn đề phức tạp.
Vì sao chúng tôi tự xây dựng Flux
Các coding agent được lưu trữ bên ngoài rất hữu ích, nhưng chúng buộc bạn phải đánh đổi khó khăn: hoặc gửi mã nguồn nhạy cảm và bối cảnh thực thi cho bên thứ ba, hoặc mở một đường truy cập từ bên thứ ba đó vào các hệ thống nội bộ. Với DoorDash, bài toán khó hơn không chỉ là làm cho agent viết được mã; phần đó gần như đã được giải quyết. Bài toán thực sự là cung cấp cho agent đó môi trường, công cụ, quyền hạn, tích hợp và các ràng buộc phù hợp.
Chiến lược của chúng tôi là kiểm soát các thành phần nền tảng xung quanh agent, bao gồm khả năng điều phối, sandbox, quy trình làm việc, quyền hạn, tích hợp và ngữ cảnh đặc thù của DoorDash mà agent cần để hoạt động hiệu quả. Chúng tôi cũng thiết kế các thành phần này theo hướng mô-đun, mang lại sự linh hoạt để sử dụng công cụ bên thứ ba tốt nhất cho từng công việc hoặc tự xây dựng nội bộ khi cần kiểm soát sâu hơn về bảo mật, tích hợp, hiệu suất hoặc trải nghiệm người dùng.
Các thành phần này giúp dân chủ hóa việc tạo quy trình làm việc và khiến hệ thống dễ thích ứng hơn với các trường hợp sử dụng trong tương lai. Vì chúng có thể được kết hợp theo nhiều cách khác nhau, các đội nhóm có thể xây dựng quy trình agent mới mà không cần làm lại hạ tầng bên dưới hay áp đặt cách mỗi kỹ sư phải cấu trúc quy trình của mình. Ví dụ: chúng tôi chạy cả phần đánh giá (evals) cho hệ thống review mã của mình trên hạ tầng Flux.
Thành phần nền tảng, không phải quy trình
Bốn thành phần nền tảng tạo nên Flux — sandbox, MCP gateway, playbook và invocation surface — cùng cách chúng kết nối với nhau để biến một tác vụ thành công việc mà agent có thể thực hiện một cách an toàn
Như minh họa ở trên, Flux được xây dựng quanh bốn thành phần nền tảng: sandbox, model context protocol (MCP) gateway, playbook và invocation surface. Kết hợp lại, chúng giúp việc ủy quyền cho agent trở nên lặp lại được. Playbook định nghĩa công việc. Sandbox đám mây cho agent một nơi thực sự để thực hiện công việc đó. Agent gateway kiểm soát những hệ thống mà agent có thể truy cập. Và invocation surface cho phép kỹ sư bắt đầu và nhận công việc ngay từ những nơi họ đã sử dụng hàng ngày.
Sandbox cung cấp môi trường thực thi
Các agent cục bộ hoạt động tốt trong quá trình phát triển tương tác, nhưng lại không phù hợp với các quy trình không cần giám sát. Chúng phụ thuộc vào laptop của từng kỹ sư, tranh chấp tài nguyên cục bộ, khó kiểm toán và không mở rộng hiệu quả trên các tác vụ song song.
Flux đưa việc thực thi vào các sandbox đám mây cô lập, được hỗ trợ bởi micro virtual machines (microVM) Firecracker để cô lập ở cấp độ phần cứng. Mỗi sandbox được cấp phát các repository, công cụ phát triển, thông tin bí mật (secrets) và các thư viện phụ thuộc runtime mà tác vụ yêu cầu, mang lại cho agent một không gian làm việc kỹ thuật hoàn chỉnh, đồng thời cung cấp cho DoorDash một mô hình thực thi, bảo mật và quan sát nhất quán.
Việc kiểm soát lớp này cho phép chúng tôi hỗ trợ các quy trình kỹ thuật thực tế, bao gồm các thay đổi trên nhiều repository và nhiều pull request từ một phiên làm việc duy nhất. Flux có mục tiêu mức dịch vụ (service level objective) ở phân vị thứ 95 là dưới năm giây cho toàn bộ quá trình thiết lập end-to-end — từ khởi động microVM đến clone các repository cần thiết, cài đặt công cụ build và cấu hình các coding agent harness được hỗ trợ.
MCP gateway cung cấp quyền truy cập có kiểm soát
Agent cần truy cập vào các hệ thống mà kỹ sư sử dụng hàng ngày, bao gồm continuous integration (CI), nền tảng quan sát (observability), hệ thống theo dõi issue, công cụ triển khai, tìm kiếm mã nguồn, tài liệu và metadata dịch vụ. Nhưng việc cấp quyền truy cập rộng rãi và không giới hạn không nên là mặc định.
Flux kết nối agent với các hệ thống nội bộ thông qua một MCP gateway do chính chúng tôi xây dựng, có tên là Agent Gateway. Mỗi playbook khai báo các công cụ mà nó yêu cầu, và Flux chỉ cấp những quyền hạn giới hạn cần thiết cho tác vụ đó. Mọi hành động đều được ghi lại, tạo nên một dấu vết kiểm toán rõ ràng.
Kiến trúc gateway này mang lại cho chúng tôi một điểm kiểm soát tập trung cho xác thực, phân quyền, quan sát, theo dõi mức sử dụng và thực thi chính sách — tất cả đều giúp quyền truy cập của agent vừa an toàn hơn vừa dễ vận hành ở quy mô lớn.
Playbook định nghĩa công việc
Playbook là một đơn vị công việc agentic có thể tái sử dụng — tương đương với một Docker container dành cho các kỹ năng và các tác vụ do agent điều khiển trên nền tảng Flux. Được định nghĩa trong một tệp YAML markup duy nhất, playbook đóng gói tác vụ, đầu vào, ngữ cảnh, kỹ năng, công cụ, quyền hạn, xác thực, đầu ra dự kiến và các ranh giới an toàn cần thiết để thực hiện công việc một cách nhất quán.
Playbook có thể kết hợp các bước agentic — mang lại sự linh hoạt và khả năng phán đoán — với các bước xác định (deterministic) — mang lại tính dự đoán được, chi phí thấp hơn và dễ xác thực hơn. Điều này cho phép các đội nhóm chuyển logic giữa thực thi do agent điều khiển và mã thông thường khi yêu cầu phát triển, mà không cần thiết kế lại quy trình.
Invocation surface đến đúng nơi nhà phát triển đang làm việc
Cùng một playbook có thể được kích hoạt từ Slack, GitHub, cron, CLI hoặc một kỹ năng trò chuyện (conversational skill). Điều đó có nghĩa là các đội nhóm có thể định nghĩa một quy trình một lần và kích hoạt nó từ bất kỳ surface nào phù hợp nhất với từng thời điểm:
- Slack để cùng nhau ủy quyền
- GitHub để tự động hóa PR và CI
- Cron cho các tác vụ bảo trì định kỳ
- CLI để nhà phát triển kiểm soát trực tiếp, hoặc được gọi thông qua một skill
Đây chính là điều khiến Flux dễ dàng được áp dụng.
Bài học kinh nghiệm
Xây dựng Flux đã dạy chúng tôi nhiều điều về việc áp dụng sản phẩm cũng như về hạ tầng, bao gồm:
- Bắt đầu từ phạm vi nhỏ để tạo dựng niềm tin. Chúng tôi bắt đầu với việc tự động review mã thay vì cố gắng tự động hóa toàn bộ vòng đời phát triển phần mềm. Review mã diễn ra thường xuyên, có thể đo lường và dễ để kỹ sư đánh giá. Nó mang lại cho chúng tôi một quy trình sản xuất để có thể điều chỉnh chất lượng, độ trễ, chi phí và hành vi trước khi mở rộng sang phân loại CI (CI triage), các tác vụ on-call, playbook bảo trì và phát triển theo ticket.
- Làm cho công việc hiển thị rõ ràng. Tích hợp Slack đầu tiên của chúng tôi tạo ra các kênh riêng tư cho mỗi lần agent chạy. Điều đó khiến Flux hữu ích cho từng cá nhân, nhưng không tạo ra thói quen làm việc nhóm. Việc chuyển công việc vào các thread công khai đã thay đổi mô hình áp dụng. Kỹ sư có thể thấy những gì người khác ủy quyền, theo dõi Flux tiến triển, xem xét đầu ra và cùng nhau xây dựng niềm tin.
- Playbook cần được hỗ trợ triển khai. Các quy trình tái sử dụng không tự xuất hiện chỉ vì nền tảng tồn tại. Các buổi workshop và hackathon đã giúp đội nhóm chuyển hóa những công việc vận hành lặp đi lặp lại thành playbook. Các thành phần nền tảng giúp việc tự động hóa trở nên khả thi; sự hỗ trợ triển khai giúp đội nhóm nhận ra quy trình nào đáng được mã hóa.
Tiếp theo là gì
Chúng tôi sẽ đi sâu hơn vào các thành phần nền tảng làm nên Flux, cùng trải nghiệm nhà phát triển khi xây dựng các quy trình mới. Chúng tôi cũng sẽ đề cập đến các ứng dụng được xây dựng trên nền tảng này, bao gồm Flux Responder, agent Slack nội bộ của chúng tôi.
Lời cảm ơn
Xin cảm ơn Adam Rogal, Adam Yarger, Andy Fang, Ashwin Kachhara, Fan Xia, Ivan Rudovol, Jason Prasad, Jialu Deng, Justin Block, Justin Deocampo, Justin Fan, Keith Lyall, Praneet Singh, Sean Chen, Tyler Berrett và Volanda Zhu vì những đóng góp của họ cho nền tảng và bài viết này.
