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:
- Süreklilik: Anlık mesajlaşma ve GitHub genelinde tek bir ajan çalışır. Sohbette A Planını tartışıp bir PR yorumunda B Planına geçseniz bile süreci kesintisiz takip eder.
- Üretkenlik: Görevleri paralel olarak yürütür ve bir önceki görev henüz tamamlanmadan bir sonraki talimatınızı alabilir.
- Proaktiflik: Olayları izler ve kendisine ihtiyaç duyulmadığı sürece sessizliğini korur.
- Kalıcılık: Her zaman çevrim içidir ve olası kesintilerden sonra kendi kendine toparlanı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 |

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.
- 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”.
- 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:
- İhtiyaç duyulması muhtemel verileri satır içi (inline) tutun: Kimlikler (ID), kısa özetler, komşu mesajlar.
- Geri kalanını dışarı aktarın (spill): Veriyi kısaltın ve ajanın gerektiğinde takip edebileceği bir işaretçi (pointer) bırakın.
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 |

İ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:
- Yük arttıkça Router'ı ölçeklendirme ve uygun bir Worker topolojisi seçme.
- Chain of Recall'un ötesinde uzun vadeli bellek (long-term memory).
- Oturumsuz kullanıcı deneyimi: Tek bir sohbet penceresi olmadan ajanı yönlendirme.
- A2A'nın adaylardan biri olduğu bağlam sınırları ve ajandan ajana iletişim protokolleri.
- Güvenlik: Bulut döngüsüne sızan bir prompt injection, bağlı olan tüm makinelere erişebilir ve bağlamdaki kimlik bilgileri sızabilir. Yazarlar, ajanların kimlik bilgilerini hiçbir zaman doğrudan görmeden kullanabilmesini hedefliyor.
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...
