DeepSeek Benzeri Bir Süper Ajan Nasıl Geliştirilir: Router, Worker ve Trigger Mimarisi Açıklandı

DeepSeek Harness tasarımına benzer bir süper ajan nasıl geliştirilir: Router oturumu, izole Worker'lar, olay tetikleyicileri, Thread yönlendirmesi, bir Watchdog ve deney verileri.

Ashley Innocent

Ashley Innocent

4 November 2026

DeepSeek Benzeri Bir Süper Ajan Nasıl Geliştirilir: Router, Worker ve Trigger Mimarisi Açıklandı

Kurumsal İçin Apidog

Şirket İçi (On-Premises) Dağıtım

SSO ve RBAC

SOC 2 Uyumlu

Apidog Enterprise'ı Keşfedin

DeepSeek Harness'ın tarif ettiği gibi bir süper ajan (super-agent) inşa etmek için ajanı iki katmana ayırın: İnsanlarla iletişim kurup iş dağıtan uzun ömürlü tek bir Router oturumu ve her biri tüm araçlara tam erişimle tek bir görevi yürüten çok sayıda yalıtılmış Worker oturumu. Her iki katmanı da olay Trigger'ları (sohbet, GitHub, CI) ile besleyin, devam eden etkileşimleri Thread bazında yönlendirin ve her şeyi denetleyen bağımsız bir Watchdog ekleyin.

Bu rehber, DeepSeek Harness'ın tasarım makalesi olan “Exploring Super-agent Design” yazısını adım adım bir inşa planına dönüştürüyor. Yalnız küçük bir uyarı: Makale, kullanıma sunulmuş bir özelliği değil, bir mimariyi anlatıyor. Mimarinin bazı bölümleri, yazarların “resmi bir DeepSeek ürünü değildir” dediği dsh-superagent-prototype adlı bir prototip eklentide yer alıyor. Aşağıdaki tüm kod taslakları yalnızca açıklama amaçlıdır; DeepSeek'in kendi kodu değildir.

Süper ajan nedir?

Süper ajan; birçok kanaldan (sohbet, pull request'ler, CI) gelen olayları alan, yalıtılmış oturumlarda birden fazla görevi paralel olarak yürüten ve insanlara tek ve tutarlı bir kimlikle yanıt veren, her zaman çevrim içi bir yapay zekâ ekip arkadaşıdır.

Sorun şu: Ajan oturumları yalıtılmıştır ve “bir insan aynı anda genellikle yalnızca 3 ila 5 aktif oturumu takip edebilir.” Tek bir görev modelin kapasitesiyle sınırlıyken, çoklu görev (multitasking) ise insan dikkatiyle sınırlıdır. Süper ajan işte bu ikinci sınırı hedef alır.

Dört temel özelliği vardır:

Harness mimarisine henüz yabancıysanız, öncelikle DeepSeek Harness'ın ne olduğunu ve Claude Code ile nasıl karşılaştırıldığını inceleyebilirsiniz.

Süper ajan mimarisi: Beş ana modül

Makalede beş modülden bahsediliyor. Aşağıda bu modülleri ve her birini hangi adımda inşa edeceğinizi bulabilirsiniz:

Modül Ne yapar? İnşa adımı
İki seviyeli mimari Router yönlendirir, Worker'lar yürütür 1
Olay güdümlü Trigger'lar Sohbet, GitHub ve CI olaylarını ajan girdisine dönüştürür 2
Tam çift yönlü (Full-duplex), çok kanallı Asenkron araçlar, kanala duyarlı yanıtlar 4
Hesaplama, durum ve ortam ayrımı Durumsuz döngü, veritabanında durum, yerinde kalan makineler 5
Watchdog İlerlemeyi ve hataları denetleyen bağımsız oturum 6
Süper ajan mimarisi: tetikleyiciler bir kod filtresi ve bir LLM filtresinden geçerek tek bir Router'a ulaşır; Router her Thread için bir Worker görevlendirir; takip eden istekler doğrudan ilgili Worker'a aktarılır ve zamanlanmış bir Watchdog tüm Worker'ları izler

1. Adım: Router'ı Worker'lardan ayırın

Router, uzun ömürlü tek bir oturumdur. İnsanlarla olan tüm etkileşimi ve iş dağıtımını yönetir; görevleri asla kendisi yürütmez. Bir Bash aracı olmadan da çalışabilir ve daha hafif, daha ekonomik bir model bunun için yeterlidir. Tek bir Router turu sırasında birden fazla Trigger ulaştığında, bunlar bir sonraki çağrıda toplu olarak (batch) işlenir: uzun girdi, kısa çıktı, prefill aşamasında birleştirilir.

Her bir Worker ise görev başına oluşturulan yalıtılmış tek bir oturumdur. Tüm araçlara tam erişim hakkına ve bütçenizin elverdiği en güçlü modele sahiptir. İnsanlarla doğrudan asla iletişim kurmaz; durumu Router'a raporlar. Bir Worker kendi içinde alt ajanlar (subagent) kullanabilir veya başlı başına bir ajan ekibi olarak çalışabilir.

Bunu klasik bir ajan ekibiyle karıştırmayın. Bir ekip lideri birbirine bağlı tek bir görevi alt parçalara ayırırken, Router yalnızca birbirinden bağımsız görevleri dağıtır. İkisini üst üste katmanlandırarak da kullanabilirsiniz.

# Illustrative sketch, not DeepSeek's code
class Router:
    def on_events(self, batch):              # triggers arriving mid-turn are batched
        plan = self.llm_light.decide(batch)  # dispatch, reply, or ignore
        for task in plan.new_tasks:
            Worker.spawn(task, model="strongest", tools="all", report_to=self)
        for msg in plan.replies:
            self.channels.send(msg)          # only the Router speaks to humans

2. Adım: Olayları Trigger'lara dönüştürün

Bir süper ajana gelen her girdi bir Trigger'dır: bir sohbet mesajı, bir GitHub webhook olayı, bir Slack Events API veri yükü ya da bir CI geri çağrısı (callback). Bunların çoğunun bir modele hiç ulaşmaması gerekir; bu nedenle makale filtrelemeyi iki aşamada gerçekleştirir.

  1. Hızlı yol (kod ile): Kaynak, grup ve kullanıcı ya da bot izin listelerine (allowlist) göre filtreleyin. Her kaynağa bir mod atanır: “yalnızca açık isteklere yanıt ver”, “aday” veya “yoksay”.
  2. Yavaş yol (LLM ile): Adaylar, “bu kanalda biri hata bildirdiğinde yanıt ver” gibi prompt olarak tanımlanmış kuralları uygulayan bir modele yönlendirilir.

Giriş uç noktanız (intake endpoint) isteği hızla onaylamalı, işlemi daha sonra yapmalıdır. GitHub'ın webhook en iyi uygulamaları, 10 saniye içinde bir 2XX yanıtı döndürmenizi ister; bir model çağrısı ise bu süreyi her zaman garanti edemez. 202 Accepted yanıtı dönün, Trigger'ı kuyruğa alın ve Router'ın onu oradan almasını sağlayın. Güvenilir webhook tasarlama rehberimiz, bu katman için yeniden denemeleri (retries) ve idempotency kavramını ayrıntılı olarak ele almaktadır.

3. Adım: Devam eden iletileri Thread'e göre yönlendirin

Bir Thread; tek bir PR, tek bir anlık mesaj konusu veya tek bir e-posta zinciri üzerindeki ardışık olaylar dizisidir. Bir Thread'in ilk olayı için oluşturulan Worker, bu Thread'e abone olur. Ardından gelen takip olayları, Router çağrısına gerek kalmadan doğrudan bu Worker'a aktarılır.

Bu eşleme çoka çoktur (many-to-many). Eğer iki Worker aynı PR üzerinde çalışıyorsa, her ikisi de o PR'ın olaylarını alır ve birbirlerine doğrudan mesaj göndermeden, çakışmaları doğrudan PR üzerinden çözebilirler.

Bu adımı atlarsanız bedelini ödersiniz: Makaledeki deneyde, doğrudan geçişin (pass-through) kaldırılması Router'ın yaklaşık %30 daha fazla karar almasına neden olmuş ve token kullanımını yaklaşık %37 artırmıştır.

4. Adım: Bağlamı bir önbellek gibi ele alın ve araçları asenkron hale getirin

Router her şeyi aklında tutamaz; bu yüzden makale, bağlamı bir önbellek (cache) gibi ele alır:

Trigger'lar, Thread'ler ve Worker'lar üzerindeki sabit kimlikler (stable ID'ler), yazarların “Chain of Recall” (Hatırlama Zinciri) adını verdiği bir referans grafiği oluşturur. Ajan; bir Trigger'dan onun ait olduğu Thread'e, oradan da onu işleyen Worker'a atlayabilir. Bu da devasa bir prompt'a ihtiyaç duymadan çok adımlı (multi-hop) hatırlama olanağı sağlar.

Ardından tam çift yönlü (full-duplex) çalışmaya geçin. Bloklayıcı bir run() aracını, asenkron start() ve stop() ile değiştirin. start() çağrısı anında “Started” yanıtı döner ve sonuç daha sonra yeni bir olay olarak gelir. Ajanın, önceki görev henüz devam ederken bir sonraki talimatınızı alabilmesini sağlayan mekanizma tam olarak budur. Makalede, DeepSeek Harness'ın bunu uyguladığı ancak varsayılan olarak etkinleştirmediği belirtiliyor.

Son olarak, yanıtları kanala duyarlı (channel-aware) hale getirin. Test ettikleri kural, anlık mesajlaşma yanıtlarını en fazla 100 kelimeyle sınırlandırırken; GitHub, e-posta ve belgeler için yapılandırılmış, kapsamlı ve ayrıntılı metinler üretir.

Bu yaklaşım aynı zamanda spekülatif yürütmeyi (speculative execution) de mümkün kılar: Kendi kullanıcı gruplarında uyguladıkları “sessizce yeniden üret ve düzelt” politikası, yalnızca doğrulanmış basit bir düzeltme olduğunda sonuç sunar; aksi takdirde sessiz kalır.

5. Adım: Hesaplama, durum ve ortamları birbirinden ayırın

Ajan döngüsünü durumsuz (stateless) bulut konteynerlerinde çalıştırın ve oturum durumunu bir veritabanında saklayın. Ortamlar ise bulundukları yerde kalır: Her makine, makalede BYOM (Bring Your Own Machine - Kendi Makineni Getir) olarak adlandırılan hafif bir arka plan hizmeti (daemon) çalıştırır. Çöken bir döngü herhangi bir yerde yeniden başlayıp durumunu tekrar yükleyebilirken, depolar kendi makinelerinde kalmaya devam eder.

Makale, Anthropic'in kendi makineleriniz yerine yönetilen sanal alanları (sandbox) hedefleyen “Scaling Managed Agents: Decoupling the brain from the hands” yazısını da aynı fikrin bir örneği olarak gösteriyor.

6. Adım: Bir Watchdog ekleyin

Watchdog, ana sistemin dışında ve belirli bir zaman çizelgesine göre çalışan bağımsız bir oturumdur. API hatalarını ele alır ve bir modele danışarak her bir Worker'ın ilerleme mi kaydettiğini yoksa rotadan mı saptığını denetler. Bakım sorumluları da bir şeyin neden başarısız olduğunu doğrudan ona sorabilir. Kilitlenen bir Router'ın kendi denetleyicisini de çökertmesini önlemek için Watchdog'u Router sürecinin dışında tutun.

Deneylerin ortaya koyduğu sonuçlar

Yazarlar; yaklaşık 20 iş talebi içeren 300 civarında sohbet ve CI mesajı çalıştırdı, kodlama sürecini bir zamanlayıcı ile simüle etti ve her yapılandırmayı 5 kez tekrarladı. Elde edilen sonuçların “yalnızca fikir verici nitelikte” olduğunu belirtiyorlar.

Yapılandırma p50 (dk) p95 (dk) Çalıştırma başına önbellekten okunan token sayısı
Süper ajan 12.4 15.7 23.2M
Thread doğrudan geçişi olmadan 12.6 15.5 31.8M
Tek oturum + alt ajan aracı, nötr prompt 20.4 29.5 6.1M
Tek oturum, önce-görevlendirme prompt'u 13.8 29.0 10.8M
Süper ajan deneyinin çubuk grafikleri: yukarıdaki tabloda yer alan dört yapılandırma için p50 ve p95 süreleri (dakika) ile çalıştırma başına önbellekten okunan token sayıları

İki önemli bulgu öne çıkıyor: Nötr bir prompt ile tek oturum, 5 çalıştırma boyunca hiçbir zaman görev dağıtımı yapmadı; bu nedenle p95 süresi süper ajanınkinin neredeyse iki katı oldu. Görevlendirme öncelikli (delegation-first) bir prompt medyan değeri düzeltse de uç değerlerdeki (tail) gecikmeyi çözemedi. Süper ajan tek bir oturuma göre daha fazla token harcar; yani token maliyetini daha düşük gecikme süresi ve insan dikkatinin korunması karşılığında takas etmiş olursunuz.

İkinci bir testte ise yalnızca Router'a yük bindirildi. Dakika başına düşen Trigger sayısı 1'den 40'a çıktığında, toplu işlem boyutu (batch size) 1,0'dan 2,8'e yükseldi ve istek başına geçen süre 2,5 saniyeden 3,9 saniyeye çıktı; buna karşılık karar başına harcanan süre 6,4 saniyeden 1,6 saniyeye düştü. Tek bir Router'ın erkenden bir darboğaza dönüşmesini engelleyen temel unsur işte bu toplu işleme yeteneğidir.

Trigger giriş uç noktanızı Apidog CLI ile test edin

Her Trigger, giriş uç noktanıza ulaşan bir HTTP isteği olarak hayata başlar; dolayısıyla ilk test edilmesi gereken yer de tam olarak bu uç noktadır. Eğer bir PR yorumunu kaçırırsa veya her olaya yeni bir thread_id atarsa, Thread yönlendirmesi bozulur ve sonraki her iletinin tekrar Router'dan geçmesi gerekir. Kodlama ajanınızın bu testi Apidog CLI ile yazmasını ve çalıştırmasını sağlayabilirsiniz.

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

Ardından ajanınıza tek bir prompt verin:

In Apidog project <id>, create POST /triggers/github for a GitHub
pull_request_review_comment webhook. Add a test case that sends two
comments on the same PR and asserts: status 202, a trigger_id in the
body, and the same thread_id both times. Run it against staging and
summarize any failures.

Ajan her veri yükü şemasını okur, JSON doğrulamasını yapar, uç noktayı ve test senaryosunu yazar ve çalıştırır:

apidog cli-schema get endpoint-create
apidog cli-schema validate endpoint-create --file endpoint.json
apidog endpoint create --project <id> --file endpoint.json
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project <id> --file case.json
apidog run --test-case <caseId> --project <id> -e <stagingEnvId> -r cli,json

Aynı apidog run çağrısı -r junit parametresiyle işlem hattınıza (CI/CD pipeline) entegre edilebilir; bkz. CI/CD'de Apidog CLI. Kullandığınız ajan bizzat DeepSeek Harness ise bu kurulum rehberini; Claude Code ise bu rehberi izleyebilirsiniz. Apidog'un Ücretsiz planı 4 kullanıcıya kadar destek sunar.

Açık problemler ve çözülmemiş konular

Makale henüz çözüme kavuşturulmamış konuları şöyle sıralıyor:

button

Sıkça Sorulan Sorular

Süper ajan, DeepSeek Harness'ta doğrudan açabileceğim bir özellik mi? Hayır. Makale bir mimariyi tanımlamaktadır. Belirli parçalar, yazarların resmi bir DeepSeek ürünü olmadığını belirttiği dsh-superagent-prototype eklentisinde mevcuttur. Tam çift yönlü (full-duplex) araçlar geliştirilmiştir ancak varsayılan olarak devre dışıdır.

Router neden daha hafif bir model kullanıyor? Yalnızca iş dağıtımı yapar ve insanlarla iletişim kurar; görevleri asla kendisi yürütmez veya Bash'e ihtiyaç duymaz. Ağır muhakeme gerektiren işleri en güçlü modeli kullanan Worker'lar gerçekleştirir.

Süper ajanın bir ajan ekibinden farkı nedir? Bir ekip lideri, birbirine bağlı tek bir görevi parçalara ayırır. Router ise birbirinden bağımsız görevleri dağıtır. Bir Worker, süper ajanın içinde kendi ajan ekibini de çalıştırabilir.

Thread doğrudan geçişi (pass-through) nedir? Bir PR, anlık mesaj konusu veya e-posta zincirindeki devam eden olaylar, Router'ı atlayarak doğrudan ilgili Thread'i yöneten Worker'a iletilir...

API Tasarım-Öncelikli Yaklaşımı Apidog'da Uygulayın

API'leri oluşturmanın ve kullanmanın daha kolay yolunu keşfedin