LLM önerilerini deterministik risk politikası, durum makinesi ve onay akışından geçirerek araç çalıştıran; Apple entegrasyonları içeren yerel öncelikli agent çekirdeği.
Prototip
Python
FastAPI
MLX
Swift
Firebase
TypeScript
Kategori için özgün kod tabanlı illüstrasyon; ürün ekran görüntüsü değildir.
Genel bakış
Jarvis Core, modelin araç önerisi ile aracın gerçekten çalıştırılması arasına açık bir kontrol katmanı yerleştiriyor. Python/FastAPI çekirdeği; risk sınıfları, onay bekleme, zaman aşımı ve tekrarlanan çağrı yönetimini içeriyor. Bellek, native Apple köprüsü, Gmail ve Firebase modülleri çekirdeği genişletiyor. Bu proje, farklı paketleri ve çalışma modeli olan J.A.R.V.I.S deposundan bağımsız bir sistem.
Problem ve amaç
Bir LLM’nin araç çağrısı önermesi, o işlemin otomatik olarak yetkili ve güvenilir olduğu anlamına gelmiyor. Yazma, harici iletişim ve yıkıcı eylemler farklı kurallar gerektiriyor. Onay bekleyen bir çalışmanın güvenli devamı, tekrar gelen çağrıların kontrolü ve sonlu yürütme sınırları da gerekli. Bu çekirdek, model muhakemesi ile uygulama yetkisini ayrı katmanlarda ele alıyor.
Çalışmadaki rolüm
Agent çalışma zamanı, risk politikası ve entegrasyon sözleşmelerinin geliştirilmesi.
Çözüm yaklaşımı
Bir chat isteği bağlam kurma ve LLM önerisiyle başlıyor; önerilen araç çağrısı mod ve risk sınıfına göre deterministik politika matrisinden geçiyor. Allow çağrıları executor’a gidiyor, approval kararları bekleme durumuna alınıyor, deny kararları sonuç olarak dönüyor. Onayların TTL’i, step/tool limitleri ve tekrar çağrı kimlikleri çalışma zamanı tarafından ele alınıyor. Mock adaptörler yerel geliştirmeyi mümkün kılıyor; MLX, Apple IPC, Gmail ve Firebase yolları ayrı konfigürasyon ve izin sınırlarıyla etkinleştiriliyor.
Uygulama ayrıntıları
01
Onayı belirli bir eyleme bağlama
ApprovalStore, onayı yalnızca bir evet/hayır bayrağı olarak saklamıyor. İstek oluşturulurken agent run kimliği, tool-call kimliği, araç adı ve argümanlardan bir action digest hesaplanıyor; kullanıcı kimliği ve bitiş zamanı da kayda bağlanıyor. Onaylama ve tüketme aşamaları bu bağın değişmediğini kontrol ediyor; tüketim tek kullanımlık işaretleniyor. Böylece kullanıcı onayladıktan sonra parametrelerin değiştirilmesi ayrı bir hata olarak ele alınabiliyor. Store bellekte olduğu için bu mekanizma tek başına süreç yeniden başlatmalarında kalıcı onay garantisi vermiyor.
02
Executor içinde ikinci politika kontrolü
Agent döngüsü politika kararını verdikten sonra ToolExecutor da çağrıyı yeniden değerlendiriyor; is_approved işareti hard deny kararını geçersiz kılamıyor. Pydantic argüman doğrulamasından geçen çağrı araca iletiliyor. Aynı tool-call kimliğine ait eşzamanlı istekler çağrı bazlı asyncio lock ile seri hale getiriliyor ve sonuç process içi cache’den tekrar kullanılabiliyor. Bu katmanlama, model döngüsündeki doğru karara bağımlılığı azaltıyor. Cache’in süreç belleğinde bulunması, servisler arası veya restart sonrası küresel exactly-once yürütme anlamına gelmiyor.
03
Bekleyen çalışmayı sonuçla devam ettirme
Runtime, onay gerektiğinde WAITING_APPROVAL durumuna geçiyor ve bekleyen çağrıyı run üzerinde tutuyor. Onay geldiğinde action bütünlüğü kontrol edilip onay tüketiliyor; executor sonucu TOOL mesajı olarak bağlama ekleniyor ve çok adımlı döngü yeniden başlıyor. Kullanıcı reddi de ayrı durum geçişi ve açıklama olarak işleniyor. Step ve tool-call limitleri bu devam yolunda da uygulanıyor. Bu tasarımın katkısı öneri, yetki ve yürütmenin okunabilir bir yaşam döngüsüne dönüşmesi; bütün entegrasyonların gerçek servislerde doğrulandığı iddiası değil.
Mimari akış
01
FastAPI chat isteği → bağlam oluşturma
02
Mock / MLX model adaptörü → yanıt veya araç önerisi
03
Mod + risk matrisi → allow / approval / deny
04
Onay durumu ve executor → araç sonucu
05
Sonuç → sonraki agent adımı / tamamlanma
Kaynak açıklamalarından türetilmiş kavramsal akış; bir uygulama ekran görüntüsü değildir.
Temel bileşenler
Observe / assist / autonomous politika modları
Risk düzeyine göre deterministik kararlar
Süreli onay ve devam akışı
Adım ve araç çağrısı sınırları
Bellek ve native Apple IPC bileşenleri
İsteğe bağlı Gmail / Firebase / iOS katmanları
Teknik zorluklar
Onay bekleyen çalışmayı doğru durumla sürdürmek ve yinelenen çağrıları yönetmek.
Araç risk etiketleri ile yürütme politikasının tutarlı kalmasını sağlamak.
Mock doğrulama ile gerçek model, cihaz ve servis kabulünü ayırmak.
Mühendislik tercihleri
Model önerisi, politika kararı ve executor ayrı katmanlara ayrıldı.
Assist varsayılanında yazma/harici/yıkıcı eylemler onay gerektiriyor; hassas sınıf reddediliyor.
Dış entegrasyonlar ayrı opt-in; yerel geliştirme için mock sağlayıcılar kullanılıyor.
Test ve doğrulama
Geçmiş doğrulamada dış ağ kapalı 237 Python testi geçti.
Swift ve Firebase-emulator işleri ayrı CI yolları; canlı Gmail, gerçek model kalitesi ve fiziksel iOS kabulü bu Python sayısına dahil değil.
Çıktılar
Araç önerilerinden bağımsız okunabilir bir mod/risk karar matrisi mevcut.
Onay, durum geçişi ve entegrasyonlar ayrı sözleşmelerle düzenlenmiş.
Sınırlar ve mevcut durum
Politika etiketleri araç tanımlarına bağlı; tüm prompt injection senaryolarına karşı garanti değil.
Autonomous modu R2 yazma işlemlerine onaysız izin verebiliyor.
Yerel öncelikli tasarım, Gmail/Firebase gibi isteğe bağlı yolların çevrimdışı olduğu anlamına gelmiyor.
Genişletilmiş rehber ve CI runner düzenlemesi açık #11 PR’sinde; henüz birleşmedi.
Teknik anlatım açık iyileştirme PR’sindeki belgeleri de esas alır. PR’nin ana dala birleştirildiği veya ürünün yayımlandığı anlamına gelmez.
