Yazarlar: @SantoshPraneeth ve @jeffizhungry
Flux, DoorDash'in mühendisler için bulut tabanlı ajan platformudur. 2026'da tek bir ayda Flux'u kullanarak 130.000 mühendislik görevini otomatikleştirdik. Q1 2026'daki lansmanının ardından hızla büyüyen Flux, halihazırda DoorDash genelinde yüksek hacimli arka plan iş akışlarını destekliyor; buna her hafta 25.000'den fazla otomatik kod incelemesi, 300'den fazla benzersiz playbook ve her hafta kullanılan 10.000'den fazla çağrı dahildir. Bu iş akışları gözetimsiz, paralel ve kesintisiz olarak çalışabilir.
Bu yazıda bizi yerel, dizüstü bilgisayar tabanlı ajan iş yüklerinin ötesine taşıyan sınırlamaları, Flux'u yalnızca barındırılan kodlama ajanlarına güvenmek yerine neden kendi içimizde geliştirmeyi seçtiğimizi ve ajan delegasyonunu tekrarlanabilir ve güvenli kılmak için ajan sandbox'ları, MCP ağ geçidi, playbook'lar ve çağrı yüzeyleri gibi platform ilkellerini ele alacağız.
Flux arka plan iş akışı kullanım senaryoları

DoorDash genelinde tek bir ayda Flux kullanımının özeti: otomatik kod incelemeleri, playbook çalıştırmaları ve arka plan görev tamamlamaları
Nereden başladık
Geçtiğimiz yıl boyunca, dizüstü bilgisayarlarında ajan tabanlı iş yükleri çalıştıran kullanıcılar hızlıca sınırlarla karşılaştı:
- Kaynaklar ve kullanılabilirlik. Bir dizüstü bilgisayarın sabit sayıda CPU çekirdeği, sınırlı belleği ve pili vardır; tümü cihazdaki her uygulamayla paylaşılır. Ajan tabanlı iş akışlarının genellikle derlemeler, testler ve büyük aramalar gibi bilgi işlem yoğun görevleri paralel çalıştırması gerekir; bu da dizüstü bilgisayarların kapasitesinin hızla dolmasına neden olur. İş akışları ayrıca cihazın açık, bağlı ve kullanılabilir olmasına bağlıdır; bir mühendis dizüstü bilgisayarı kapattığında, bağlantısı kesildiğinde veya uzaklaştığında iş durur.
- Güvenlik kontrolleri. Dizüstü bilgisayarlar genellikle SSH anahtarları, VPN oturumları ve kimliği doğrulanmış araçlar dahil olmak üzere hassas kimlik bilgilerine ve sistemlere geniş erişime sahiptir. Otonom bir ajana aynı düzeyde erişim vermek gereksiz risk ve potansiyel olarak geniş bir etki alanı yaratır. Yerel ortamlar ayrıca bir ajanın neye ve ne kadar süre erişebileceğini sıkı bir şekilde sınırlandırmayı zorlaştırır.
- Görünürlük ve denetlenebilirlik. İş yükleri bireysel dizüstü bilgisayarlarda çalıştığında, yürütme parçalıdır ve izlenmesi zordur. Neyin çalıştığını, nerede çalıştığını, kimin adına çalıştığını ve hangi sistemlere veya dosyalara dokunduğunu anlamak zorlaşır.
Bu sorunları çözmek için tezimiz basit:
Görevleri güvenli, otonom kodlama ajanlarına devredin ki mühendisler daha fazla enerjilerini inovasyona, eleştirel düşünmeye ve karmaşık sorunları çözmeye ayırabilsin.
Flux'u neden kendi içimizde geliştirdik
Barındırılan kodlama ajanları kullanışlıdır, ancak zor bir takas dayatırlar: Ya hassas kodu ve yürütme bağlamını üçüncü bir tarafa gönderirsiniz ya da o üçüncü taraftan iç sistemlere geri dönen bir yol açarsınız. DoorDash için daha zor sorun, bir ajana kod yazdırmak değildi; bu büyük ölçüde çözüldü. Asıl sorun, o ajana doğru ortamı, araçları, izinleri, entegrasyonları ve kısıtlamaları sağlamaktı.
Stratejimiz, orkestrasyon, sandbox'lar, iş akışları, izinler, entegrasyonlar ve verimli çalışmak için gereken DoorDash'e özgü bağlam dahil olmak üzere ajanın etrafındaki ilkelleri kontrol etmektir. Ayrıca bu ilkelleri modüler olarak tasarladık; böylece her iş için en iyi üçüncü taraf aracını kullanma veya daha derin güvenlik, entegrasyon, performans veya UX sahipliği önemli olduğunda kendi içimizde geliştirme esnekliğine sahip olduk.
Bu ilkeller iş akışı oluşturmayı demokratikleştirir ve sistemleri gelecekteki kullanım senaryolarına daha uyumlu hale getirir. Farklı şekillerde birleştirilebildikleri için ekipler, altta yatan altyapıyı yeniden düzenlemeden veya her mühendisin iş akışını nasıl yapılandırması gerektiğini dikte etmeden yeni ajan iş akışları oluşturabilir. Örneğin, hem değerlendirmeleri hem de kod incelememizi Flux altyapısı üzerinde çalıştırıyoruz.
İlkeller, iş akışları değil

Flux'u oluşturan dört platform ilkeli — sandbox'lar, MCP ağ geçidi, playbook'lar ve çağrı yüzeyleri — ve bir görevi ajanın güvenle yürütebileceği işe dönüştürmek için nasıl bağlandıkları
Yukarıda gösterildiği gibi Flux, dört platform ilkeli etrafında inşa edilmiştir: sandbox'lar, model bağlam protokolü (MCP) ağ geçidi, playbook'lar ve çağrı yüzeyleri. Birlikte, ajan delegasyonunu tekrarlanabilir hale getirirler. Bir playbook işi tanımlar. Bir bulut sandbox'ı ajana işi yapması için gerçek bir yer verir. Bir ajan ağ geçidi, ajanın hangi sistemlere erişebileceğini kontrol eder. Çağrı yüzeyleri ise mühendislerin halihazırda kullandıkları yerlerden iş başlatmasına ve iş almasına olanak tanır.
Sandbox'lar yürütme ortamını sağlar
Yerel ajanlar etkileşimli geliştirme için iyi çalışır, ancak gözetimsiz iş akışları için uygun değildir. Bireysel mühendislerin dizüstü bilgisayarlarına bağımlıdırlar, yerel kaynaklar için rekabet ederler, denetlenmeleri zordur ve paralel görevlerde verimli şekilde ölçeklenmezler.
Flux, yürütmeyi donanım düzeyinde izolasyon için Firecracker mikro sanal makineleriyle (microVM) desteklenen izole bulut sandbox'larına taşır. Her sandbox, görevin gerektirdiği depolarla, geliştirici araçlarıyla, sırlarla ve çalışma zamanı bağımlılıklarıyla donatılır; böylece ajanlara eksiksiz bir mühendislik çalışma alanı sağlanırken DoorDash'e tutarlı bir yürütme, güvenlik ve gözlemlenebilirlik modeli sunulur.
Bu katmanı kontrol etmek, tek bir oturumdan birden fazla depoda değişiklik ve birden fazla pull request dahil olmak üzere gerçek mühendislik iş akışlarını desteklememizi sağlar. Flux'un uçtan uca kurulum için 95. yüzdelik hizmet düzeyi hedefi beş saniyenin altındadır — microVM'i başlatmaktan gerekli depoları klonlamaya, derleme araçlarını kurmaya ve desteklenen kodlama ajanı donanımlarını yapılandırmaya kadar.
MCP ağ geçidi kontrollü erişim sağlar
Ajanların, sürekli entegrasyon (CI), gözlemlenebilirlik platformları, sorun takipçileri, dağıtım araçları, kod arama, dokümantasyon ve hizmet meta verileri dahil olmak üzere mühendislerin her gün kullandığı sistemlere erişmesi gerekir. Ancak geniş ve kısıtsız erişim vermek varsayılan olmamalıdır.
Flux, ajanları iç sistemlere Agent Gateway adı verilen dahili bir MCP ağ geçidi üzerinden bağlar. Her playbook gerektirdiği araçları bildirir ve Flux yalnızca o görev için gereken kapsamlı izinleri verir. Her eylem günlüğe kaydedilir ve net bir denetim izi oluşturur.
Bu ağ geçidi mimarisi bize kimlik doğrulama, yetkilendirme, gözlemlenebilirlik, kullanım takibi ve politika uygulama için merkezi bir kontrol noktası sağlar; bunların tümü ajan erişimini hem daha güvenli hem de ölçekte çalıştırmayı kolaylaştırır.
Playbook'lar işi tanımlar
Playbook, ajan tabanlı işin yeniden kullanılabilir bir birimidir — Flux platformunda beceriler ve ajan odaklı görevler için Docker konteynerinin eşdeğeridir. Tek bir işaretleme YAML dosyasında tanımlanır; işi tutarlı bir şekilde yürütmek için gereken görevi, girdileri, bağlamı, becerileri, araçları, izinleri, doğrulamayı, beklenen çıktıları ve güvenlik sınırlarını paketler.
Playbook'lar, esneklik ve muhakeme sağlayan ajan adımlarını; öngörülebilirlik, düşük maliyet ve daha kolay doğrulama sunan deterministik adımlarla birleştirebilir. Bu, ekiplerin gereksinimler geliştikçe iş akışını yeniden tasarlamadan mantığı ajan odaklı yürütme ile geleneksel kod arasında taşımasına olanak tanır.
Çağrı yüzeyleri geliştiricilerle bulundukları yerde buluşur
Aynı playbook Slack, GitHub, cron, CLI veya konuşmaya dayalı bir beceriden tetiklenebilir. Bu, ekiplerin bir iş akışını bir kez tanımlayıp onu ana uyan herhangi bir yüzeyden çağırabileceği anlamına gelir:
- İş birliğine dayalı delegasyon için Slack
- PR ve CI otomasyonu için GitHub
- Tekrarlayan bakım için cron
- Doğrudan geliştirici kontrolü için CLI veya bir beceri aracılığıyla çağrılabilir
Flux'u benimsenmesi kolay yapan da budur.
Çıkarılan dersler
Flux'u geliştirmek bize altyapı kadar ürün benimsenmesi hakkında da çok şey öğretti:
- Güven kazanmak için dar başlayın. Otomatik kod incelemesiyle başladık, tüm yazılım geliştirme yaşam döngüsünü otomatikleştirmeye çalışmak yerine. Kod incelemesi sıktı, ölçülebilirdi ve mühendislerin değerlendirmesi kolaydı. Kaliteyi, gecikmeyi, maliyeti ve davranışı CI triyajına, nöbet görevlerine, bakım playbook'larına ve bilet odaklı geliştirmeye genişlemeden önce ayarlayabileceğimiz bir üretim iş akışı sağladı.
- İşi görünür kılın. İlk Slack entegrasyonumuz her ajan çalıştırması için özel kanallar oluşturdu. Bu, Flux'u bireyler için kullanışlı hale getirdi, ancak ekip alışkanlıkları yaratmadı. İşi herkese açık başlıklara taşımak benimsenme modelini değiştirdi. Mühendisler başkalarının neleri devrettiğini görebiliyor, Flux'un ilerlemesini izleyebiliyor, çıktıyı inceleyebiliyor ve birlikte güven oluşturabiliyordu.
- Playbook'lar etkinleştirme gerektirir. Yeniden kullanılabilir iş akışları yalnızca platform var olduğu için ortaya çıkmaz. Atölye çalışmaları ve hackathon'lar ekiplerin tekrarlayan operasyonel işleri playbook'lara dönüştürmesine yardımcı oldu. İlkeller otomasyonu mümkün kıldı; etkinleştirme, ekiplerin hangi iş akışlarını kodlamaya değer olduğunu fark etmesine yardımcı oldu.
Sırada ne var
Flux'u çalıştıran platform ilkellerine ve yeni iş akışları oluşturmaya yönelik geliştirici deneyimine daha derinlemesine bakacağız. Ayrıca üzerine inşa ettiğimiz uygulamaları, dahili Slack ajanımız Flux Responder dahil olmak üzere ele alacağız.
Teşekkürler
Platforma ve bu yazıya katkılarından dolayı 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 ve Volanda Zhu'ya teşekkürler.





