Orkas Orkas
Ana sayfa Blog Mimari
Mimari

Ajanın Temelini Yeniden Yazmak: Orkas'ın Baştan Aşağı Yeniden Yapılandırılması

Orkas, 1.0 sürüm serisi boyunca ajan temelini nasıl yeniden kurdu? Süreç içi çalışma ortamı, sağlayıcı rotasyonu, dinamik grup sohbeti orkestrasyonu, açık barındırma, bellek ve kendini geliştirme.

Bir yapay zekâ ajanı ürünü olgunlaştığında en maliyetli şey özellikler değil, temeldir. Bu makale, Orkas'ın 1.0 sürüm serisi boyunca gerçekleştirdiği köklü yeniden yapılandırmayı — model çağırma, ajan döngüsü, çoklu ajan orkestrasyonu ve araç ekosisteminin tamamen yenilenmesini — ve her kararın arkasındaki ödünleşimleri ele alıyor.

Kısa özet Yeniden yazımın amacı neydi? Sonuç, bugün yükleyebileceğiniz uygulamadır: MIT lisansıyla açık kaynaklı, yerel öncelikli ve isterseniz kendi sağlayıcı anahtarlarınızla çalışır.
Orkas'ı indirin — ücretsiz

Temele neden dokunmalı?

Orkas bir yerel öncelikli masaüstü yapay zekâ ajanı çalışma alanıdır: ajanların tüm çalışmaları kullanıcının kendi bilgisayarındaki bir süreç içinde yürür, veriler yerelde tutulur ve uçtan uca bulut eşitlemesi talep üzerine gerçekleşir. İlk sürümlerde özellikler hızla birikti — beceri kitaplığı, bilgi tabanı, bağlayıcılar, grup sohbeti tarzında çoklu ajan — ama ilerledikçe şu daha netleşti: asıl darboğaz tek bir özellik değil, "temel düzeyindeki" üç şeydi.

  1. Model çağırma katmanı eski sohbet yaklaşımını izlerse bir dizi yanlış varsayıma zincirlenir. Büyük bir modeli "tek soru, tek yanıt sohbeti" gibi çağırmak, sohbet için anlamlı ama ajan için uygun olmayan bir yığın varsayılanı beraberinde getirir: sabit bir çıktı token sınırı, sıralı araç çağrıları, gizli zaman aşımları, koda sabitlenmiş tek bir sağlayıcı. Ajan, art arda onlarca tur çalışan, bağlam penceresinin sınırlarına düzenli olarak yaklaşan, dosyaları paralel okuması gereken ve kullanıcı tarafından her an kesilebilen uzun süreli bir akıştır — bu varsayılanların her biri üretim ortamında sorun çıkarır. Daha da kötüsü, bir masaüstü ajanının en değerli yetenekleri — hassas dosya işlemleri, yerel arama, kabuk çalıştırma, birden fazla çalışanın paralel yürütülmesi, uzun soluklu görev çözümü — tam da bu varsayım katmanının dışarıda bıraktığı yeteneklerdir.

  2. Orkestrasyon "statik planlama" idi. İlk sürüm bir plan/DAG motoruydu: önce model görevi bir plan grafiğine ayırıyor, ardından yürütücü işleri grafiğe göre dağıtıyordu. Kulağa düzenli geliyor ama bir ajanın gerçekliği son derece dinamiktir — bir dosyayı okumak yön değiştirmeniz gerektiğini ortaya çıkarır ve bir alt görevin sonucu, sonraki adımın kime gideceğini belirler. Kararları önceden üretilmiş bir grafikte dondurmak, "plan gerçekliğe yetişemiyor" durumlarının her birinin yürütücü içinde yamalanması gerektiği anlamına gelir.

  3. Ekosistem kapalı bir katalogdu. Beceriler yalnızca resmî pazar yerinden gelebiliyordu, bağlayıcılar koda sabitlenmiş bir katalogdu ve kullanıcının bilgisayarında zaten bulunan haricî ajan araçları Orkas için tamamen bir kara kutuydu. Kullanıcının üçüncü taraf bir projeyi, kendi MCP sunucusunu bağlaması veya bilgisayarında zaten bulunan bir ajanın Orkas'ın becerilerine ve bilgi tabanına geri çağrı yapmasını sağlaması — mimari açıdan bunların hiçbiri mümkün değildi.

Bu yeniden yapılandırmanın ana fikri basit: ajanın temelini yeniden kendi elimize almak. Somut olarak bu, iç içe geçen dört ana çizgide karşılık buluyor — kendi geliştirdiğimiz süreç içi çalışma zamanı, sağlayıcıdan bağımsız model katmanı, dinamik grup sohbeti orkestrasyonu ve kapalı katalogdan açık bir barındırma ortamına geçiş. Bunları tek tek ele alalım.

1. Eksiksiz bir kodlama ajanı yetenek setini masaüstüne taşımak

Masaüstü, ajanın doğal ortamıdır — burada gerçek bir dosya sistemi, gerçek bir kabuk ve gerçek bir yerel araç zinciri vardır. Yalnızca sohbet edebilen bir asistan bu ortamı boşa harcar; masaüstünün avantajını gerçekten kullanan şey, eksiksiz bir kodlama ajanı yetenek setidir: karakter aralığı düzeyinde dosya okuma ve yazma, dosyalar arası arama, bash ve sistem araçlarını çalıştırma, birden fazla çalışanı paralel başlatma ve karmaşık bir görev gerçekten bitene kadar onlarca tur çalışmayı sürdürecek uzun soluklu problem çözme.

Yeniden yapılandırmanın temel çıktısı, tam da bu yetenek setini taşımak için var: doğrudan Orkas'ın kendi sürecine — bağımsız, dinamik olarak yüklenebilen, süreç içi bir ajan çalışma zamanı (kodda adı core-agent olarak geçiyor). Bu, sıradan bir sohbet sarmalayıcısı daha değil; Orkas'ın doğrudan kontrol ettiği bir ajan motoru.

Temel mimari karar, onu iki katmana ayırmaktı:

  • Motor katmanı (bağımsız paket): saf ajan mekanizması — araç çağırma döngüsü, akış olayları, bağlam sıkıştırma, hata sınıflandırma ve yeniden deneme, sağlayıcı soyutlaması, korumalı alan, beceri tarama, bellek, kendi kendine gelişim. Orkas'ın iş mantığı hakkında hiçbir şey bilmez : iş verilerinin dizinlerini okumaz, konuşma dosyası biçimini anlamaz ve IPC'ye asla dokunmaz.
  • Adaptör katmanı (ana süreç içinde): motoru Orkas'a bağlar — oturum kalıcılığı, sağlayıcı rotasyonu, araç izinleri, beceri kayıt sistemi, bağlayıcılar, bilgi tabanı ve çeşitli üretim araçları. Motorun yerel olaylarını Orkas'ın kendi olay biçimlerine dönüştürür; böylece iş mantığı katmanı her zaman kararlı bir arayüz görür.

Bu motor/adaptör sınırı, ardından gelen tüm esnekliğin kaynağıdır. Motor bağımsız olarak test edilebilir ve geliştirilebilir; adaptör katmanı ise Orkas'a özgü karmaşıklığı (rotasyon, bekleme süresi, korumalı alan, izinler) motoru kirletmeden güvenle üstlenebilir. Ekibin mimari incelemesi bunu tek cümlede özetledi: bu, varlığını hak eden bir karmaşıklık — katmanları birleştirmeyin.

Yetenek seti gerçekte neler içeriyor?

Çalışma zamanını kendi elimizde tutmak gösteriş için değil; ajanın masaüstünde gerçekten "işe el atmasını" sağlamak için. Yetenek seti kabaca dört gruba ayrılıyor:

  • Hassas dosya işlemleri ve yerel arama. read_file karakter aralığına göre okumayı destekler ve PDF / Office belgelerinden metni otomatik olarak çıkarır; edit_file hassas "eski dize → yeni dize" değişimi yapar ve her yazma işleminden önce okuma yapılmasını zorunlu kılar; write_file çıktıyı kaydeder ve kaydını tutar; stat_file boyutu sorgular; search_files ada/glob desenine göre bulur, grep_files dosyalar arasında içerik arar. Bu grup, ajanın yalnızca bütün blokları alıp üretmek yerine bir mühendis gibi gerçek bir çalışma alanında "kodu incelemesini, dosyaları değiştirmesini" sağlar.
  • Bash ve sistem araçları. Arka planda yürütme modu (uzun görevler mevcut turdan ayrılır, günlükler bir dosyaya gider) ve tehlikeli işlemler için risk derecesine göre denetimler sunan, korumalı alanda çalışan bir kabuk yürütücüsü. Bir masaüstü ajanının gücünün büyük kısmı, tam da sistem araç zincirine doğrudan komut verebilmesinden gelir.
  • Paralel çoklu çalışan. Tek bir tur içinde, birbirinden bağımsız salt okunur araçlar eşzamanlı çalışır; görev düzeyinde komutan da bağımsız alt görevleri birden fazla çalışana paralel olarak dağıtabilir (bkz. Bölüm 3). Güvenli olan yerlerde paralelleştirmek, "uzun soluklu görevleri" kabul edilebilir gerçek süreye indirmenin anahtarıdır.
  • Uzun soluklu akıl yürütme ve görev çözümü. Art arda onlarca tur çalışabilen, kendi bağlamını yönetebilen, hatalardan kurtulabilen ve aynı yerde dönüp durmaya takılmayan bir döngü — "karmaşık bir işi bitirmek" ile "bir soruyu yanıtlamak" arasındaki ayrım çizgisi budur.

Mühendislik açısından üretim ortamına nasıl hazırlandı

"Kendi döngünü yazmak" başına iş açmak gibi geliyor ve bakım maliyeti de var. Ancak karşılığında ajanın tüm yaşam döngüsü üzerinde ayrıntılı kontrol sağlıyor. Bu kontrol soyut değil; her biri yukarıdaki yeteneklerden birinin üretim ortamında "ayakta kalıp kalmadığına" karşılık gelen somut iyileştirmelerden oluşuyor:

  • Gerçek bağlam penceresi + yalnızca %80'de sıkıştırma. Motor, her modelin gerçek bağlam penceresini okur (milyon tokenlık pencerelere sahip modeller dahil) ve sıkıştırmayı ancak kullanım %80'e ulaştığında tetikler; temkinli davranıp %60'ta başlayarak yararlı bağlamın %40'ını atmaz. Ayrıca "kazanç sağlamayan sıkıştırma" için bir koruma da vardır: korunan son bölüm pencereyi zaten dolduruyorsa (örneğin son bölümde çok büyük bir dosya okuma sonucu varsa), sıkıştırma yer açamaz. Bu durumda yalnızca bir uyarı kaydedip işlemi atlar; boşa bir özetleme çağrısı başlatmaz. Uzun soluklu bir görevin "öncesinde olanları hatırlayıp hatırlayamayacağı" tamamen buna bağlıdır.

  • Art arda gelen salt okunur araçları paralel çalıştırma. Model tek bir turda read-file, search-file ve web-lookup gibi birbirinden bağımsız birkaç salt okunur aracı çağırdığında motor, art arda gelen ve paralelleştirilebilen araçları gruplayıp eşzamanlı çalıştırır; yazma araçları doğal sınırlar oluşturur ve bildirilen sıralarını korur. Araç çağrıları ve sonuçları kesinlikle bildirilen sırayla kayda geçirilir; böylece eşzamanlılık protokolü asla bozmaz. En yaygın salt okunur araçlar tek hamlede seri çalışmadan paralel çalışmaya geçer ve tüm grubun toplam süresi gözle görülür biçimde azalır.

  • Yazmadan önce okuma + iyimser eşzamanlılık kontrolü. Bir dosyayı düzenlemeden önce onu okumanız gerekir; motor, okunan dosya için bir referans durum kaydeder ve düzenleme anında bu durumun değişmediğini kontrol eder. Paralel çalışan işçiler aynı dosyayı aynı anda değiştirdiğinde, yarışı kaybeden taraf diğerinin değişikliklerini sessizce ezmek yerine açık bir "güncelliğini yitirmiş" hatası alır. Aynı çalışma alanında birden fazla işçi paralel çalışırken bu koruma vazgeçilmezdir.

  • Çalışma sırasındaki müdahaleyi anında dahil etme. Ajan işin ortasındayken kullanıcı bir satır daha eklediğinde motor, kuyruğa alınan bu mesajı mevcut turun girdisine araç döngüsü sınırında dahil eder; ayrı bir tur olarak başlatmayı beklemez. Böylece "çalışırken yönünü düzeltmek" doğal bir etkileşime dönüşür.

  • Döngü tespiti. Aynı araç çağrısı art arda tekrarlandığında motor önce uyarır (3. tekrarda), ardından kesin olarak durdurur (5. tekrarda); farklı bir çağrı imzası sayacı sıfırlar. Böylece sayfalama veya durum yoklama gibi meşru varyasyonlar yanlışlıkla tetikleyici olmaz. Model takılıp kaldığında artık sessizce token tüketmez.

  • Ana tur çıktısındaki kesin üst sınırı kaldırma. Ana tur çıktısı artık küçücük bir sınıra sabitlenmez; böylece uzun raporlar ve büyük düzenlemeler sessizce kesilmez. Yardımcı çağrılar (sıkıştırma, öz değerlendirme) ise temkinli biçimde küçük bir sınır kullanmayı sürdürür.

Söz etmeye değer, oldukça "yerel" bir ayrıntı var: Çince ve İngilizcenin karışık kullanıldığı metinlerde token tahmini. Genel bir tahmin, tamamen Çince bir konuşmayı gerçek değerinin yarısı ya da üçte biri kadar sayar; motor, Çince ve İngilizce karakterleri karakter sınıfına göre farklı ele alır ve sıkıştırma eşiğini güvenilir kılan da budur. Genel amaçlı bir SDK'nın sizin yerinize düşünmeyeceği türden bir ayrıntıdır bu.

Bu iyileştirmeler birlikte, "neden hazır bir SDK kullanmıyoruz" sorusunu yanıtlıyor: çünkü bir masaüstü ajanının en güçlü yetenekleri tam da SDK'nın dışarı açmadığı katmanda bulunuyor; bunları üretim ortamına hazır hale getirmek için döngünün kontrolü sizin elinizde olmalı.

2. Modeli her zaman çevrimiçi tutmak: çok katmanlı sağlayıcı sarmalayıcısı

Model katmanının amacı tek cümle: belirli bir anahtarda, sağlayıcıda veya ağda ne sorun çıkarsa çıksın, kullanıcının konuşmasının bu turu mümkün olduğu ölçüde devam edebilmeli. Bu amaçla adaptör katmanı, motorun sağlayıcı soyutlamasının üzerine birkaç sarmalayıcı ekler: rotasyon, bekleme süresi, kayıt ve harici uyarlama.

En kritik tasarım kararı, rotasyon bileşeninin çalıştırıcının altında yer almasıdır. Motor, herhangi bir sağlayıcıyı çağırmadan önce kullanıcının mesajını kalıcı oturuma yazar; yeniden denemeyi veya rotasyonu motor düzeyinde yapsaydınız kullanıcı mesajını yeniden göndermeniz ya da baştan sona bir oturum geri alma mekanizması yazmanız gerekirdi. Rotasyon bileşeni motorun altına yerleştirildiğinde kullanıcı mesajı tam olarak bir kez yazılır ve "başka bir adayla yeniden dene" işlemi oturum durumu açısından tamamen görünmez olur.

Rotasyon bileşeninin kararları da ölçülüdür; belirleyici sınır ilk içerik olayıdır:

  • Bir hata önce modelin anlamlı bir içerik (metin/araç çağrısı) üretmesinden önce oluşursa, sıradaki adaya geçmek güvenlidir;
  • İlk içerik olayı üretildikten sonra rotasyon durdurulur ve hatanın üst katmana iletilmesine izin verilir; çünkü model bir turun tamamını zaten çalıştırmış olabilir ve yeniden çalıştırmak yan etkileri tekrarlayabilir.

Hata sınıflandırması, "rotasyon yap, yapma veya yeniden dene" kararını belirler. Hesap düzeyindeki kimlik doğrulama hatası, yetersiz bakiye, hız sınırına takılma, abonelik süresinin dolması gibi hatalarda bir bekleme süresi işaretlenir ve rotasyon yapılır; geçici ağ hatalarında, örneğin bağlantı sıfırlandığında, bekleme süresi uygulanmaz; aynı yerde durum tutulmadan birkaç kez yeniden denenir. Hatalı biçimlendirilmiş istekler, içerik politikası hataları ve sunucu 5xx hataları ise başka bir anahtarla da aynı şekilde başarısız olacağından rotasyon yapılmadan doğrudan iletilir. Bekleme süresi on dakikalık, süreç içi, kalıcı olmayan bir ipucudur: yalnızca kısa vadeli bir sinyaldir, her hatada diske yazmaya değmez ve sürecin yeniden başlatılması tekrar denemek için tam da doğru andır.

Sağlayıcı "kadrosu" tarafında yeniden düzenleme, üç tür kaynağı tek bir birleşik soyutlamada toplar:

  • Orkas tarafından yönetilen LLM: oturum açıldıktan sonra kullanıma hazır, metin/görsel modelleri arasındaki yönlendirmeyi sunucunun yaptığı sunucu taraflı bir vekil;
  • Kendi anahtarınızı getirin: yaygın kullanılan standart büyük model sağlayıcıları;
  • Harici doğrudan bağlantı adaptörleri: doğrudan bağlantı gerektiren veya kendi faturalandırmasına sahip olan ve aynı sağlayıcı arayüzüne elle uyarlanan bir dizi model.

Üst katmanlara bunların tümü, tek bir kararlı (provider, model) çifti olarak görünür; rotasyon, bekleme süresi ve harici uyarlama tamamen adaptör katmanının içinde gizlidir.

3. Orkestrasyon olarak grup sohbeti: statik plan DAG'ından komutanın döngüde olduğu yapıya

Yeniden düzenlemenin düşünce biçimini en çok değiştiren kısmı bu.

Eski model statik planlamaydı: model önce bir plan/DAG üretir, yürütücü de bu grafiğe göre çalışırdı. Yeni model bu grafiği tamamen kaldırıp yerine komutanın döngüde olduğu dinamik bir grup sohbeti orkestrasyonu koyuyor.

Bunun metaforu bir grup sohbeti odası:

  • Buradaki Commander görünmez bir ara katman değil, odanın ev sahibidir;
  • Ajan işçileri odanın birinci sınıf, eşit üyeleridir;
  • Tüm etkileşimler, şu yapı üzerinden kuyruğa alınan asenkron mesajlardır: tek bir mesaj veri yolu (paralel dağıtım için özel bir yol yoktur).

Komutanın "görevlendirmesi", düz metne yazılmış bir @somebody değildir; bir LLM'nin @AgentA ifadesini gövde metnine yazması, yalnızca eğitim verisinden gelen markdown'dır ve güvenilir değildir. Gerçek görevlendirme sinyali bir yapılandırılmış araç çağrısıdır ve yeniden düzenlemeden sonra anlamı net üç eylemde birleşir:

  • dispatch_to — bir ajanı işi tamamlayıp sonucu geri getirmesi için gönderir; sonuçları komutan birleştirir. Birbirinden bağımsız birden fazla görev eşzamanlı dağıtılabilir.
  • run_worker — komutanın kendisinin sorumluluğunu üstlendiği, sonucu eşzamanlı dönen bir alt görevdir; isimsiz bir işçi komutanın "eli"dir (kullanıcıya görünmez), isimli bir işçi ise görünür bir uzmandır.
  • hand_off_to — devret konuşmayı şuna: ajana; komutan aradan çekilir ve ajan bu turda üzerine ek bir sentez yapılmadan kullanıcıya doğrudan yanıt verir.

Neden bir orkestratör veya alt ajan ağacı yerine grup sohbeti

Çok ajanlı yapıyı grup sohbetine dönüştürmek, geleneksel bir orkestratörün veya alt ajan ağacının sağlayamayacağı çeşitli avantajlar getirir:

  • Görünürlük dilimleri. Her mesaj yalnızca "onu görebilenlerin" dilimine eklenir. Bir ajan işçisi başlatıldığında yalnızca kendi dilimini yeniden oynatır; böylece başka bir ajanın büyük çıktısı onun bağlamını kirletmez. Komutan her şeyi görür.
  • Asgari durum. Tüm orkestrasyonun temel durumu yalnızca "şu anda söz kimde" bilgisi ve hafif bir görev kaydından ibarettir. DAG yok, karmaşık durum makinesi yok.
  • Doğası gereği yeniden oynatılabilir ve eşitlenebilir. Mesajlar doğal olarak zaman damgasına göre sıralandığından hem yeniden yükleme hem de cihazlar arası eşitleme doğrudan mesaj akışına dayanır. Mobil taraf uzaktan kontrolü tam olarak bu akış üzerinden yapar — ajanların tüm hesaplamaları masaüstünde çalışır ve mobil yalnızca görüntüyü yansıtır; özel bir orkestrasyon protokolüne ihtiyaç duymaz.

Ekibin mimari incelemesi de bu konuda aynı derecede açıktı: bir grup sohbeti veri yolu ile döngüde yer alan bir komutan tam olarak Orkas'ın çok ajanlı yapısıdır; süreç içine başka bir paralel alt ajan görevlendirme yolu eklemek, "yalnızca tek bir grup sohbeti görevlendirme yolu" değişmezini ihlal ederdi.

Bu sürümdeki yenilik: etkileşimli devir

Bu alandaki en yeni parça, etkileşimli ajan devri.

Sorun somut: "öğretmen" türündeki bir ajan kullanıcıya bir tur ders veriyor, kullanıcı devam soruları sormak istiyor, ancak sistem sözü zorla komutana geri veriyor ve kullanıcıyı her satırda yeniden-@ o ajanı belirtmek zorunda bırakıyor.

Çözüm, sunucunun yetkili olduğu söz sahipliği + modelin belirlediği alıcı:

  • Söz sahipliği, yeniden yüklemelerde korunan kalıcı bir durum alanına dönüşür ve mevcut durum değişikliği olayı üzerinden otomatik olarak eşitlenir tüm uçlara; yeni bir olay türü gerekmez.
  • Komutan şunu kullandıktan sonra: hand_off_to sözü etkileşimli bir ajana vermek için, kullanıcının sonraki "@" içermeyen mesajları doğrudan o ajana gider; ajan kendi isteğiyle geri devredene veya kullanıcı komutana yeniden hitap edene kadar.
  • Ajan kontrolü şu işaretle geri verir: <handback /> ; ayrıştırma gerçek bir eşleşme olduğunu kesin biçimde doğrular (böylece düz metinde tek başına geçen bir <handback ifadesi yanlışlıkla devir olarak yorumlanmaz).
  • Geri devir sırasında görev kaydında tamamlanmamış işler varsa komutan bunları kayıttan alıp devam eder.

Bununla birlikte deneyimi iyileştiren bir düzeltme de geliyor — komutan döngüsü balonları. Komutanın tek tur içindeki "görevlendir → sonucu oku → yeniden görevlendir" döngüsü eskiden tek bir balona sıkıştırılır, yeniden yüklemede ise sırasını kaybedip en alta atlayabilirdi. Yeniden düzenleme, bir turu her görünür görevlendirme sınırında birden fazla parçaya böler; her parça artan bir zaman damgasına sahip bağımsız bir mesajdır. Kullanıcı ilk kez komutanın "orkestrasyon döngüsünü" görebilir ve yeniden yükleme sırası da doğru olur.

Son olarak, tüm süreç boyunca işleyen iki güvenlik ağı: grup iptali tüm aktörler için tek durdurma yoludur (kullanıcı Durdur'a bastığı anda her işçinin iptal sinyali tetiklenir; isimsiz alt işçiler bile yedek bir eşleştirmeyle kapsanır); ve daha önce bahsedilen kesip yönlendirme, kullanıcının çalışma sırasındaki müdahalesini mevcut tura dahil eder.

4. Kapalı bir katalogdan açık bir barındırma ortamına

İlk üç ana eksen temeli sağlamlaştırmakla ilgiliyse, bu eksen tüm kapıları ve pencereleri sonuna kadar açmakla ilgili — Orkas'ı kapalı bir katalogdan açık bir barındırma ortamına dönüştürmek — güvenlik sınırından zerre taviz vermeden.

Yeniden düzenleme, çeşitli "kapalı" darboğazları sistematik olarak ortadan kaldırdı:

  • Harici paketler. Kullanıcı bir depo adresi verir ve Orkas bunu yerel olarak barındırır bir klasöre olduğu gibi klonlanmış halde — asla normalleştirilmez, yeniden yazılmaz veya buluta eşitlenmez (çünkü üçüncü taraf bağımlılık dizinleri içerir). Bağımsız bir komut satırı aracı kurulum/güncelleme/başlatma-durdurma yaşam döngüsünü yönetir, paketin "beceri biçiminde" mi (bir beceri açıklama dosyası içeriyor) yoksa "CLI biçiminde" mi (çalıştırılabilir bir giriş noktası içeriyor) olduğunu tarar ve meta verileri bir kayıt defterine yazar paket dizininin dışında (böylece gelecekte depodan çekilen güncellemeler asla çakışmaz). Bağımlılık kurulumu, "bir kez sor, hatırla" esaslı iki aşamalı onaydan geçer; çalıştırılabilir giriş noktaları için sarmalayıcılar üretilip bash aracının PATH'ine eklenir, böylece model bu üçüncü taraf CLI'ları doğrudan çağırabilir.

  • Birden fazla kökten beceri yükleme. Beceri yürütmenin tek giriş noktası, yalnızca iki kökü tanımaktan önceliğe göre çözümlenen dört katmana geçti: özel / pazar yeri / harici paket / genel. Harici paketlerdeki betikler, paketin kendi birlikte gelen bağımlılık ortamını tercih eder. Gerileme riski en yüksek olan darboğaz budur ve kapsamlı bir test fikstürü matrisiyle desteklenir.

  • Genel becerilerle birlikte çalışabilirlik. Orkas, kullanıcının makinesindeki diğer ajan araçlarının zaten yönettiği genel beceri dizinlerini doğrudan okuyarak beceri düzeyinde birlikte çalışabilirlik sağlar; kullanıcının bir yerde biriktirdiği beceri Orkas'ta da kullanılabilir. Kullanıcının bir beceriyi bu dizinlere yerleştirmesi başlı başına yetkilendirmedir; bu nedenle varsayılan olarak etkindir, ancak genel bir açma/kapatma anahtarı da bulunur. Bu üçüncü taraf beceri açıklamaları, güvenilmeyen bir istem enjeksiyonu yüzeyidir; bu yüzden "açık katman" yükleyicisinden geçerler, yalnızca komutana görünürler ve yapısal olarak bir ajanın izin verilen beceriler listesine giremezler.

  • Kullanıcı tarafından yapılandırılan MCP. Bağlayıcılar artık kod içine sabitlenmiş bir katalogdan ibaret değil. Kullanıcı herhangi bir MCP sunucusu ekleyebilir: uzak HTTP biçiminde (düşük risk) veya yerel alt süreç biçiminde (yüksek risk). Formun kendisi onay yüzeyidir (kullanıcının elle yazdığı komut olduğu gibi gösterilir), aktarım yapılandırmasının tamamı (gizli bilgiler dahil) şifreli depolamaya gider ve özel örnekler her zaman sabit bir önek taşır; böylece katalogdaki resmi bir bağlayıcının kimliğine asla bürünemezler.

  • Ters köprü: makinedeki harici ajanların da Orkas'ı algılayabilmesi. En ilginç parça bu. Kullanıcının makinesinde zaten bulunan harici ajan araçları eskiden Orkas için bir kara kutuydu; artık Orkas onları görevlendirdiğinde bir köprü kanalı ekleyerek onlara ters yönde Orkas'ın becerilerini listeleme/okuma/çalıştırma, bağlayıcıları çağırma ve bilgi tabanında arama yapma olanağı veriyor. Köprü, yerel bir süreçler arası kanal üzerinden çalışır (ağ bağlantı noktası açılmaz); kimlik doğrulama, her çalıştırmaya özgü olan ve çalıştırma bittiği anda yok edilen tek kullanımlık bir kimlik bilgisiyle yapılır. Harici yan etkisi olan her bağlayıcı çağrısı kullanıcı onayı iletişim kutusundan geçer — araç adına göre sezgisel bir okuma/yazma değerlendirmesiyle değil (bu yaklaşım fazla gevşek kalırdı), her (ajan, bağlayıcı) çifti için bir onayla; isteğe bağlı olarak "her zaman izin ver" seçeneği de vardır.

  • Nadir kodlama ihtiyaçlarına yaklaşım. Komutanın karar ağacı yeni bir dal kazanır: eşleşen bir ajan/beceri/bağlayıcı yoksa, bash ve kısa bir betikle doğrudan çözmeyi değerlendir, bu turda yap, çıktıyı doğrula ve isteğe bağlı olarak bunu özel bir beceriye dönüştürmeyi öner. Buna arka planda bash yürütme (uzun görevler mevcut turdan ayrılır, günlükler bir dosyaya yazılır) ve kullanıcının izin verdiği dizinler eşlik eder.

Açık, ama kontrolsüz değil

Kapıları ve pencereleri açarken en çok korktuğunuz şey cereyandır. Bu yeniden düzenlemenin disiplini: "tehlikeli eylemler" için süreç başlatma denetim noktalarının tek birine bile dokunulmuyor. MCP tam olarak tek bir yerden başlatılır, beceri yürütme tam olarak tek bir çalıştırıcıdan geçer ve bash tam olarak tek bir korumalı alan yürütücüsünden geçer. Bunların üzerine birkaç savunma katmanı daha eklenir:

  • Dosya işlemleri her zaman yol korumalı alanından geçer (çalışma alanı + mevcut ekler + kullanıcının açıkça izin verdiği dizinler); kimlik bilgisi dizinleri, sistem dizinleri ve Orkas'ın kendi dizinleri için ise erişim izni verilemez;
  • Tehlikeli bash işlemleri (veri sızdırma, yıkıcı silme, ayrıcalık yükseltme, hassas yollar) izin onayını tetikler; karar "yalnızca bu kez / bu çalıştırma boyunca / reddet" olarak ayrılır ve günlükler yalnızca kategori ile uzunluğu kaydeder — komut metnini asla kaydetmez;
  • Harici paket kurulumu güvenli biçimde kapanır ve kesin olarak reddeder sembolik bağlantı öğeleri içeren paketleri (sembolik bağlantı aracılığıyla korumalı alan dışındaki hassas dosyaların kapsama alınarak okunmasını önlemek için); klonlama kaynağı da bir protokol izin listesiyle sınırlandırılır;
  • Kimlik bilgisi taşıyan tüm aktarım yapılandırmaları/gizli bilgiler depolanırken şifrelenir ve köprü kimlik bilgileri her çalıştırma için yalıtılır;
  • Açık kaynak / barındırılan dağıtım, yalnızca ana ortama özgü yetenekleri bir budama kuralıyla çıkarır.

Tek cümleyle: kullanıcının her açık eylemi (kurulum / izin verme / form gönderme / onaya tıklama) rızanın kanıtıdır ve her rıza hak ettiği sınırla kısıtlanır.

5. Oturumlar boyunca daha akıllı hale gelmek: bellek ve kendini geliştirme

Temelin elden geçirilmesi, "ajanı kullanıldıkça daha akıllı hale getiren" iki alt sistemi de yeniledi; ikisi de aynı mühendislik disiplinini izliyor — varsayılan olarak kapalı, sınırlandırılmış, gözlemlenebilir.

Oturumlar arası bellek karma erişim kullanır: vektör tabanlı anlamsal arama + anahtar kelime araması (BM25), tek bir kanalın başarısızlığına bağlı kalmamak için RRF (karşılıklı sıralama birleştirmesi) ile birleştirilir; veriler yerel depolamada tutulur (tam metin diziniyle birlikte). Bellek iki türdür: ajanın kendi notları ve kullanıcı tercih profili. Her birinin karakter sınırı vardır, yazılmadan önce enjeksiyon tehditlerine karşı taranır ve sabitlenmiş halde eklenir her turun başında sistem istemine. Tüm bellek sistemi yalnızca ajanın mevcut kullanıcıyı daha iyi anlamasına hizmet eder; veriler her zaman yerelde kalır ve kullanıcı bunları ayarlardan istediği zaman görüntüleyebilir, düzenleyebilir ve dışa aktarabilir.

Kendini geliştirme ajana özel bir beceri kitaplığı (platformun paylaşılan beceri kitaplığından ayrı saklanır) ile bir üstbilişsel öz değerlendirme katmanından oluşur. Motor, öz değerlendirme yapıp yapmayacağına bir dizi ağırlıklı sinyallekarar verir: kullanıcı düzeltmesi (en yüksek ağırlık), basit olmayan bir hatadan toparlanma, görev karmaşıklığı, bilinen bir zayıflığın tetiklenmesi veya aşılması, becerinin etkisiz kalması... Öz değerlendirme yalnızca ağırlıklı sinyaller bir eşiği aştığında tetiklenir. Öz değerlendirmenin kendisi bir arka planda çalışan periyodik görevdir (yaklaşık 12 saatte bir tur, birkaç saatlik bekleme süresi, birkaç günlük yedek tetikleme) ve düşük maliyetli küçük bir model kullanarak son etkinliklerin özetini okur; bir beceri oluşturup oluşturmayacağına veya yamalayıp yamalamayacağına ve ajanın "yetkinlik profilini" güncelleyip güncellemeyeceğine karar verir.

En önemli güvenlik noktası: kendini geliştirme yalnızca açıkça bir ajan bağlanmış oturumlarda etkinleştirilir — varsayılan komutan oturumu kendini geliştirmez. Öz değerlendirmenin çift token sınırı vardır (sayı + toplam), bir ajanın başarısızlığı diğerlerini engellemez ve çalıştırma başına maliyet son derece düşük tutulur. Ajanı daha akıllı yapın, ama kontrolden çıkmasına izin vermeyin.

Mühendislik felsefesi: gerekçeli karmaşıklık — basitleştirirken yok etmeyin

Ekip yeniden düzenleme sırasında birkaç tur mimari inceleme yaptı ve bir sonuç sürekli tekrarlandı; bunu ayrıca vurgulamakta fayda var: "yapısal şişkinlik" ile "gerekçeli karmaşıklığı" ayırt edin ve yalnızca ilkine dokunun.

  • Eşitleme motorunun çoklu birleştirme stratejileri, özel geliştirilen ajan döngüsü, çok katmanlı sağlayıcı sarmalayıcısı, mobil uzaktan kontrolün sınırı: bunlar karmaşık görünür, ancak her katman varlığını hak eder (çok cihazlı nihai tutarlılık, derin entegrasyon, çok anahtarlı rotasyon, ürünün belirlediği uç sınırı). Bunları zorla "basitleştirmek" yalnızca veri kaybına ve katmanların belirsizleşmesine yol açardı.
  • Gerçekten müdahale edilmesi gerekenler, "her şeye hükmeden modüller" ve yerel tekrarlardır: şişkin grup sohbeti veri yolundan durumsuz saf fonksiyonları çıkarmak (istem oluşturma, komutan araçları, CLI turu) ve birkaç kez tekrarlanan "onay iletişim kutusu" kalıbını tek bir paylaşılan bileşende toplamak.

Bu tür kararların arkasında, projenin kısıtlar belgesine yazılmış katı ilkeler bulunur: sınır (tek süreç, tek yol olarak IPC, çalışma zamanının yalnızca dinamik yüklenebilmesi), katmanlama (her katmanın bağımlılık yönü), tek doğruluk kaynağı (kategoriler, telemetri sınıflandırması, alanlar) ve istemleri etkileyen her commit'te zorunlu "istem denetimi". Temelin çökmeksizin elden geçirilmesini sağlayan şey zekice bir tasarım değil, bu değişmezlerin sürekli korunmasıdır.

Kapanış

Dört ana ekseni bir araya getirdiğinizde, bu köklü yeniden düzenlemenin Orkas'a kazandırdığı ajan temeli kontrolü kendisinde olan, sağlayıcıdan bağımsız, dinamik olarak orkestre edilen, dışarıya açık ve kendini geliştirebilen bir yapıdır:

  • Kodlama ajanlarının tüm güçlü yönlerini — dosya işlemleri, yerel arama, sistem araçları, paralel çoklu işçi, uzun soluklu problem çözme — masaüstüne yerel olarak taşıyan ve her birini üretim ortamına hazır hale getiren, iki katmanlı motor/adaptör yapısında süreç içi bir çalışma zamanı;
  • Anahtar/sağlayıcı/ağ kaynaklı aksaklıklarda konuşmayı mümkün olduğunca sürdüren çok katmanlı bir model katmanı;
  • "Statik planlamayı" "dinamik kararla" değiştiren ve ajanlar arası devirleri ilk kez doğal hissettiren, grup sohbeti tarzında, komutanın döngüde olduğu çok ajanlı bir orkestrasyon;
  • Harici paketlerin, genel becerilerin, özel MCP'nin ve ters köprünün tamamının kullanıma açıldığı, kapalı bir katalogdan açık bir barındırma ortamına ilerleyen bir ekosistem — süreç başlatma denetim noktaları ise yerinden hiç oynamadan;
  • Ve varsayılan olarak kapalı, sınırlandırılmış ve gözlemlenebilir bellek ile kendini geliştirme.

Özellikler tek tek eklenebilir, ancak bir temeli ciddi biçimde elden geçirmek yalnızca bir kez yapılmaya değer. Tamamlandığında, üzerine ne inşa ederseniz edin daha hızlı ilerler; bu yeniden düzenlemenin hedeflediği sonuç da tam olarak buydu.