Kendi yapay zeka temsilci (agent) altyapınızı nasıl oluşturursunuz?

Çoğu agent ekibi bir koşum takımı inşa etmez. Onlar bir tane benimser. LangChain, LangGraph, OpenAI Agents SDK, Anthropic SDK, CrewAI, AutoGen, döngü, araçlar, bellek ve orkestrasyon, tek bir kararla raftan seçilir. Koşum takımı, import ettiğiniz bir framework'tür. İçindeki bir şey uymazsa, onu fork eder, onunla savaşır veya etrafından dolaşırsınız.

Bence bu şekil yanlış ve uzun süreli her agent ekibinin eninde sonunda koşum takımını sıfırdan yeniden yazmasının nedeni de bu. Koşum takımı tek bir şey değildir. Çevredeki ekosistem size bunları birleştirmenin bir yolunu vermediği için bir araya getirilmiş on veya on iki farklı şeydir. Pi agent paketleri doğru yolda, ancak hâlâ "Başka bir hizmet ekleyin ve onu diğerleriyle entegre edin" paradigmasındalar. iii motoru tüm işçilere aynı şekilde davranır ve entegrasyon mantığını tamamen ortadan kaldırır. Sağlayıcı yönlendirici, kimlik bilgisi kasası, politika motoru, onay kapısı, model kataloğu, oturum deposu, bütçe takipçisi, arama sonrası kanca fanoutu ve dayanıklı sıra döngüsü bağımsız unsurlardır. Bunların hepsi kuyruğunuz, HTTP/API sunucunuz, akışınız ve hatta tarayıcı işçilerinizle birlikte çalışabilir. Bunları tek bir blok olarak gönderen bir framework, size yapmak zorunda olmadığınız bir ödünleşim satıyordur.

iii'ün altında yatan iddia, bunların tek bir blok olmaması gerektiğidir. Paylaşılan bir motor üzerinde, her biri değiştirilebilir, her biri bağımsız olarak sürümlendirilmiş, her biri tek bir ilkel öğeyle (tetikleyici (iii.trigger())) bağlanan bir dizi işçi olmalıdır. Koşum takımı, kurulabilir işçilerden oluşan bir yığın haline gelir ve "kendininkini yapmak", "bir framework'ü fork etmek" anlamına gelmez. "Birkaç işçiyi değiştirmek" anlamına gelir.

Bu yazı, bunun gerçekte nasıl göründüğünü adım adım gösteriyor. Bugün bir iii agent dönüşünü yönlendiren eksiksiz yığın, her katmanın neden kendi işçisi olduğu ve herhangi birini nasıl değiştirebileceğiniz.

Bir agent koşum takımının yapması gereken 15 iş

Bir üretim agent koşum takımını sorumluluklarına ayırırsanız, kabaca şuna benzeyen bir liste elde edersiniz:

1. Bir istemciden gelen bir dönüş isteğini kabul etmek ve kalıcı hale getirmek
2. Hangi model sağlayıcısının çağrılacağına göre kimlik bilgilerini çözümlemek
3. Seçilen modelin gerçekte neler yapabileceğine bakmak (görüş, araçlar, akış, bağlam penceresi)
4. Dönüş başına durum makinesini çalıştırmak, hazırlamak, asistanı akışla göndermek, araçları çalıştırmak, yönlendirmek, yıkmak
5. Her bir fonksiyonun istek şeklini, hata kodlarını ve kullanım notlarını tanımlayan beceri gövdelerini yüklemek ve sunmak
6. Sistem promptunu, mod paragrafını, kimlik ön bilgisini, çalışma dizinini ve varsayılan beceriler ekini birleştirmek
7. Model bunları üretirken token'ları istemciye geri akışla göndermek
8. Her araç çağrısını (bu sadece bir fonksiyondur) çalıştırılmadan önce bir politikaya karşı kontrol etmek
9. İnsan kararı gerektiren araç çağrılarını duraklatmak ve cevabı doğru dönüşe yönlendirmek
10. LLM harcamalarını çalışma alanı veya agent başına bütçelere göre takip etmek
11. Araç çağrılarından önce ve sonra kancalar çalıştırmak (kayıt tutma, düzeltme, özel yan etkiler)
12. Oturumu, fork'lar ve devam ettirmeler çalışacak şekilde dallanan bir ağaç olarak kalıcı hale getirmek
13. Bağlam penceresi dolduğunda oturum geçmişini sıkıştırmak
14. UI'ın abone olduğu bir olay akışı yayınlamak
15. Gördüğüm her agent şirket yapısından eksik olan parça. Hata ayıklayabilmeniz için her adımda bir OpenTelemetry izi taşımak

Her ciddi agent, bunların çoğunu kullanır. Pahalı olanlar hepsini yapar. Ucuz olanlar köşeleri keser ve daha sonra üretime geçtiklerinde o köşeleri yeniden inşa ederler. Framework'ler bunları bir monolite bündeller ve her birinin tek bir sürümünü gönderir. Size maliyeti olan son kısım budur, çünkü bir yıl sonra, istediğiniz politika motorunun framework'ün gönderdiği politika motoru olmadığını ve onu değiştirmenin koşum takımını değiştirmek anlamına geldiğini fark edersiniz.

iii koşum takımı, bu on üç işin her birini workers.iii.dev kaydında ayrı bir işçi olarak gönderir. Her biri aynı WebSocket protokolünü konuşur. Her biri aynı motor veri yolunda fonksiyonlar ve tetikleyiciler kaydeder. Her biri iii worker add ile eklenebilir, değiştirilebilir ve SDK'sı olan herhangi bir dilde yazılabilir.

Yığın, işçi bazında

İşte iii-hq/workers monorepo'sundaki gerçek üretim yığını ve her işçinin işi tek bir satırda. Tüm paket github.com/iii-hq/workers/harness adresinde gönderilir:

On bir işçi. Bir motor. Her biri yayınlanmış bir sürümde. Her biri bağımsız olarak tek başına bir süreç olarak (geliştirmede pnpm dev:<worker>, bir sürüm ikili dosyası olarak iii worker add <specific-worker>) veya bunları birlikte başlatan birleşik giriş noktasının bir parçası olarak çalıştırılabilir.

Bunun önemli olmasının nedeni: Bu tablodaki her kutu, birinin size farklı bir işçi verebileceği ve sizin geri kalanını elinizde tutabileceğiniz bir yerdir. Statik model kataloğunu beğenmediniz mi? models::list kaydeden ve canlı bir API'den okuyan bir işçi ekleyin. Dosya tabanlı kimlik bilgilerini beğenmediniz mi? auth::get_token kaydeden ve bir sırlar yöneticisinden okuyan bir işçi ekleyin. Farklı dallanan bir iş akışı için farklı bir dönüş FSM'si mi istiyorsunuz? turn-orchestrator'ı değiştirin, her bağımlı aynı veri yolu üzerinden run::start çağırır ve turn_state okur, böylece yığının geri kalanı değişmez.

Döngü gerçekte nasıl çalışır

Bir dönüşün şekli, işçilerin ateşlenme sırasına göre şöyle görünür.

Bir tarayıcı/CLI/sohbet, {session_id, message_id, payload} ile harness::trigger aracılığıyla bir dönüş POST'lar. Harness meta-işçisi, yükü run::start'a iletir. Bu atlama, OpenTelemetry span sarmalayıcısının oturum ve mesaj kimliklerini, yığındaki her işçideki her iç içe iii.trigger çağrısına yayılan bagaj olarak ekleyebilmesi için vardır. Diğer taraftaki iz ağacı, birbirine bağlı tek bir grafiktir.

run::start, turn-orchestrator'a düşer. Çalıştırma isteğini kalıcı hale getirir, iii state'de session/<sid>/turn_state adresinde ilk TurnStateRecord'u oluşturur ve hemen geri döner. Gerçek iş, turn-step FIFO'suna yapılan yayınlarla uyandırılan dayanıklı durum makinesinin içinde gerçekleşir.

İki terminal durumu vardır: durduruldu (finishSession() aracılığıyla temiz çıkış) ve başarısız (beklenmeyen bir işleyici buraya yönlendirir, kuyruğu onaylar böylece yeniden denemeyi durdurur ve UI'ın nedeni göstermesi için message_complete{stop_reason:'error'} artı agent_end yüzeye çıkarır). Yıkma (teardown), ayrı bir sıraya alınmış adım değil, herhangi bir dönüş sonu yolundan çağrılan satır içi bir finishSession() portudur.

provisioning üç şey yapar. Çalıştırmanın izole yürütmeye ihtiyacı varsa bir iii-sandbox mikroVM'si başlatır. system_default_skills içindeki her ad alanı için directory::skills::download çağırır (varsayılan ["iii://iii-directory/index"]), böylece iii-directory, çalıştırmanın başladığı beceri gövdelerini önceden önbelleğe alır. Ve sistem promptunu üç katmanda birleştirir: run_request.mode'dan (plan, ask veya agent) seçilen bir mod paragrafı, modele agent_trigger kuralını ve directory::skills::get talep üzerine keşif modelini öğreten iii kimlik ön bilgisi ve agent'ın başlattığı varsayılan becerilerin eklenmiş bir dizini. Çağıran, run::start'ta system_prompt ileterek promptun tamamını geçersiz kılabilir; aksi takdirde orkestratör onu oluşturur. Fonksiyon şemaları canlı motor kataloğundan gelir.

assistant_streaming, çalıştırmanın sağlayıcı alanıyla eşleşen sağlayıcı işçisinde provider::<name>::stream çağırır. Sağlayıcı işçisi, kimlik bilgilerini auth::get_token (auth-credentials) aracılığıyla çeker, modelin SSE yanıtını bir iii kanalına akışla gönderir ve orkestratör, UI fanoutu için agent::events üzerinde message_update olayları yayınlayarak bu kanalı boşaltır. Kanal oluşturma ve okuma döngüsü, provider-stream.ts'de çekme tabanlı bir MessagePump'ın arkasında yaşar, böylece akış durumu geçişlere odaklanmış kalır.

Asistan araç çağrıları döndürdüğünde, FSM function_execute durumuna girer. Her araç çağrısı, orkestratördeki tek darboğaz olan dispatchWithHook'tan geçer. consultBefore, 5 saniyelik bir zaman aşımı ile doğrudan policy::check_permissions çağırır. Politika işçisi (varsayılan yığındaki harness meta-işçisi), iii-permissions.yaml dosyasını okur, çağrının function_id'sini kural setiyle eşleştirir ve üç sonuçtan birini döndürür:

• allow: gönderme devam eder; orkestratör hedef fonksiyonu tetikler ve sonucu yazar
• deny: gönderme bir DenialEnvelope ile kısa devre yapar, sonuç bir ret kaydı olur
• needs_approval: bireysel çağrı, dönüşün awaiting_approval listesine park edilir. Toplu işin geri kalanı göndermeye devam eder. Dönüş, yalnızca bir veya daha fazla giriş bekliyorsa function_awaiting_approval durumuna geçer.

Onay uyandırması tepkiseldir ve paylaşılır. Orkestratör, approvals kapsamında tam olarak bir turn::on_approval durum tetikleyicisi kaydeder. Konsol approval::resolve çağırdığında, onay-kapısı işçisi approvals/<sid>/<cid> = {decision, reason} bilgisini iii state'e yazar. Bu yazma, turn::on_approval tetikleyicisini ateşler ve bu da etkilenen oturumu ilerletir. function_awaiting_approval, yalnızca yeni gelen kararları okur, her birini geldiği gibi gönderir (allow önceden onaylanmış bir gönderme olur, deny veya aborted sentetik bir ret olur) ve awaiting_approval[] boşaldığında ilerler. Kaydedilecek çağrı başına devam ettirme fonksiyonu yok. Bekleyen onayları kurtarmak için başlangıçta yeniden tarama yok. Tek bir tetikleyici her oturumu kapsar.

Yapı gereği başarısızlığa kapalı: politika işçisine ulaşılamazsa veya 5 saniyelik zaman aşımı tetiklenirse, consultBefore çağrıyı bir gate_unavailable zarfı ile reddeder. Eğer iii::durable::publish işleminin kendisi hata verdiyse, kanca fanoutu publish_failed: true döndürür ve orkestratör bunu bir ret olarak ele alır.

Bu şekilden birkaç gecikme kazancı elde edilir. Fonksiyon sonrası kanca, konu için hiçbir dayanıklı abone kayıtlı olmadığında bir abone-varlığı önbelleği aracılığıyla publish_collect işlemini kısa devre yaptırarak, yürütülen her fonksiyon çağrısı başına yaklaşık 500 ms kaldırır. tearing_down, finishSession() içine satır içi olarak yerleştirilmiştir ve dönüş başına bir dayanıklı kuyruk atlamasını kaldırır. context-compaction, orkestratörün dönüş sınırlarında yaydığı özel bir agent::turn_end akışına abone olur, böylece sıkıştırıcı uyandırmaları olay başına değil dönüş başına olur. Oturum oluşturma fanout durum tetikleyicisi, yalnızca kapsama göre kapılar ve süreç içinde eşleşir, böylece önceki yazma başına harness::session::is_create_event RPC'si ortadan kalkar.

Toplu iş tamamlandıktan sonra, steering_check devam edip etmemeye, durdurmaya veya maksimum dönüş sayısına ulaşıp ulaşmadığına karar verir. Devam edilecekse, assistant_streaming'e geri dön. Durdurulacak veya maksimuma ulaşıldıysa, finishSession() satır içi çalışır: agent_end yayınla, sandbox'ı serbest bırak, stopped durumuna geç.

Çalıştırma boyunca, katılan her işçi iii.session.id, iii.message.id ve iii.function.id ile etiketlenmiş OTel yayılımları yayar. Bu etiketler, motorun engine::traces::group_by'sinin izler UI'ında "Gruba Göre Oturum" / "Gruba Göre Mesaj" / "Gruba Göre Fonksiyon"u doldurmak için okuduğu şeylerdir. Enstrümantasyon otomatiktir: src/runtime/worker.ts, her registerFunction'ı bir Proxy ile sarar, böylece hiçbir işçi başına kodun yayılım eklemeyi hatırlaması gerekmez.

Kendinizinkini oluşturun

İlginç kısım, yukarıdaki işçilerin hiçbirinin özel olmamasıdır. Her biri motora bir WebSocket açan, bazı fonksiyonlar ve tetikleyiciler kaydeden ve çalışan bir süreçtir. Sözleşme, her uygulama işçisinin kullandığı sözleşmeyle aynıdır. Koşum takımı, iş mantığınızın üzerine inşa edildiği ilkel öğe üzerine inşa edilmiştir.

Bu, "kendi koşum takımını oluşturmanın", "herhangi bir işçi yazmak" ile aynı işleme dönüştüğü anlamına gelir. Değiştirmek istediğiniz katmanı seçersiniz, veri yolunda aynı fonksiyonları kaydeden bir işçi yazarsınız, onu iii worker add ile eklersiniz ve yığının geri kalanı sizin işçinizi kullanmaya başlar.

Yukarıdaki işçi tablosunda görünmeyen ancak koşum takımının nasıl davrandığı için önemli olan iki katman vardır. Beceriler, her işçinin fonksiyonlarının ne yaptığını nasıl duyurduğudur. Her işçi, iii://<worker>/<function> adresinde bir beceri yayınlayabilir; agent, bu fonksiyonu ilk kez çağırmadan önce directory::skills::get aracılığıyla getirir. Sistem promptu, bir mod paragrafı, iii kimlik ön bilgisi ve çalıştırmanın yapılandırıldığı varsayılan beceri gövdelerinden dönüş başına birleştirilir. Her ikisi de veri yolu odaklıdır: beceriler iii-directory işçisi tarafından sunulur, sistem promptu turn-orchestrator tarafından birleştirilir. Her ikisi de değiştirilebilir.

Beş somut örnek.

Model kataloğunu canlı bir API ile değiştirin. models::list, models::get, models::supports kaydeden bir işçi yazın. Her N dakikada bir sağlayıcınızın katalog uç noktasından getirmesini ve önbelleğe almasını sağlayın. Yayınlayın. iii worker add your-org/dynamic-models-catalog. Statik models-catalog işçisini durdurun. turn-orchestrator farkı asla bilmez. iii.trigger('models::list') çağırır ve motor, bu fonksiyon kimliğini en son kaydeden işçiye yönlendirir.

Yeni bir sağlayıcı ekleyin. Şekil zaten provider-kimi ve provider-lmstudio tarafından kanıtlanmıştır. Her biri, provider::<name>::stream ve provider::<name>::complete kaydeden, bir üst API'den gelen SSE akışını bir iii kanalına boşaltan ve model kullanımını budget::record aracılığıyla llm-budget'a yazan bir işçidir. Beşinci bir sağlayıcı eklemek, bir klasörü bir iii.worker.yaml ve bir register.ts ile yazmaktır. Kayıt defterine yayınlayın veya yerel tutun. turn-orchestrator, sağlayıcıyı çalıştırmanın sağlayıcı alanına göre seçer; işçi bağlanır bağlanmaz yeni sağlayıcılar kullanılabilir hale gelir.

Becerileri özel bir yapı deposundan sunun. directory::skills::get ve directory::skills::list kaydeden, dahili dokümantasyon sisteminiz veya özel bir S3 bucket'ı tarafından desteklenen bir işçi yazın. Varsayılan iii-directory işçisinin bağlantısını kesin veya yeniden adlandırın. Orkestratörün başlatma rutini, ad alanı başına directory::skills::download çağırır; sizin işçiniz yanıt verir. Agent'ın "yeni bir fonksiyonu çağırmadan önce fonksiyon başına beceriyi getirme" modeli, tel şekli aynı olduğu için değişmeden çalışmaya devam eder.

Sistem promptunu tamamen geçersiz kılın. run::start isteğe bağlı bir system_prompt alanını kabul eder. Bunu iletin ve orkestratör, mod paragrafı + kimlik ön bilgisi + beceriler eki birleştirmesini atlayarak sizin dizenizi olduğu gibi kullanır. Mevcut bir prompt varlığınız olduğunda ve koşum takımının onu değiştirmeden onurlandırmasını istediğinizde kullanışlıdır. Beceri indirme işlemi başlatma sırasında hala çalışır, böylece agent özel bir promptla bile talep üzerine directory::skills::get keşfini sürdürür.

Onay kapısı UI yüzeyini değiştirin. Varsayılan onay-kapısı işçisi approval::resolve kaydeder. Tel şeması tek bir fonksiyon çağrısıdır:

İşleyici, approvals/<sid>/<cid> = {decision, reason} bilgisini iii state'e kaydeder. Orkestratörün tek turn::on_approval durum tetikleyicisi bu yazmayı alır ve doğru oturumu uyandırır. Onayları konsol yerine Slack üzerinden yönlendirmek istiyorsanız, /approve <id> ve /deny <id> slash komutlarını dinleyen ve ardından doğru yük ile approval::resolve çağıran bir Slack işçisi yazın. Orkestratör farkı asla bilmez. Onay-kapısı işçisinin tamamı değişmeden kalır. Yeni bir işçi eklediniz; mevcut olanı değiştirmediniz.

Farklı bir politika motoru (OPA, Cedar, kendi DSL'iniz) istiyorsanız, policy::check_permissions kaydeden ve { decision, rule_id?, matched_constraint? } döndüren bir işçi yazın. Varsayılan politika işçisinin bağlantısını kesin (bu, harness meta-işçisinin içine sarılmıştır, bu nedenle bu işleyiciyi devre dışı bırakır veya küçültülmüş bir meta-işçi çalıştırırsınız). turn-orchestrator'ın consultBefore'u farkı bilmez. Aynı 5 saniyelik zaman aşımı, aynı başarısızlığa kapalı semantik, aynı tel şekli.

Bu örneklerin amacı belirli değiştirmeler değil. İşlemin şeklidir. iii yığınındaki her koşum takımı katmanına, veri yolundaki bir veya iki fonksiyon kimliği aracılığıyla ulaşılabilir. Bir katmanı değiştirmek, bu kimlikleri kaydeden bir işçi yazmaktır. Sistemin geri kalanı olduğu gibi kalır.

Koşum takımı bir yol ayrımı değil, bir kaydırıcıdır

Klasik koşum takımı tartışması kendini ince ve kalın olarak çerçeveler. Anthropic'in ince döngüsüne karşı LangGraph'in açık DAG'ı. Çerçeveleme, bir tarafı seçip onunla yaşayacağınızı varsayar.

Koşum takımı aynı veri yolu üzerindeki işçilerden oluştuğunda, ince ve kalın sadece kaç tane işçi kurduğunuzun bir sayısıdır. İnce bir koşum takımı, turn-orchestrator artı provider-anthropic artı auth-credentials artı minimum bir harness meta-işçisidir. Bu kadar. Onay yok, bütçe yok, politika motoru yok, kanca fanoutu yok. Her şeyi çalıştır. Modele güven. Otonom araştırma agent'ları, deneysel döngüler, dahili herhangi bir şey için kullanışlıdır.

Kalın bir koşum takımı, on üç işçinin tamamı artı context-compaction artı özel bir politika işçisi artı özel bir onay-kapısı artı Slack ile entegre bir onay yüzeyi artı çalışma alanı başına limitleri uygulayan bütçe işçisidir. Her araç çağrısının denetlenebilir olması ve her model harcamasının bir finans panosuna yansıması gereken müşteri iş akışlarını çalıştıran bir agent için kullanışlıdır.

İnce ve kalın arasındaki mimari mesafe bir yeniden yazma değildir. Bir yapılandırma değişikliğidir. Aynı tel protokolü, aynı iz şekli, aynı gözlemlenebilirlik hikayesi. Kaydırıcı, config.yaml dosyanızdan işçi ekleyip çıkararak hareket eder. Diğer her şey sabit kalır.

Bu, tek bir işçinin içinde de geçerlidir. turn-orchestrator az önce FSM'sini on bir durumdan yediye düşüren, approvals kapsamında tek bir tepkisel turn::on_approval durum tetikleyicisi lehine çağrı başına turn::approval_resume::<sid>/<cid> mekanizmasını silen ve tearing_down'ı bir finishSession() portuna satır içi olarak yerleştiren bir yeniden düzenleme yayınladı. Yığındaki diğer her işçi (onay-kapısı, oturum, llm-bütçe, sağlayıcılar, modeller-kataloğu, auth-credentials, kanca-fanout, context-compaction) değişmeden kaldı. approval::resolve tel şekli hareket etmedi. Sözleşmeler tutuldu. Birleştirmenin size verdiği özellik budur: bir işçinin büyük bir dahili yeniden yazması, kendi kendine yeten bir değişikliktir çünkü her komşu onunla veri yolu düzeyindeki fonksiyon kimlikleri aracılığıyla konuşur.

Framework modelinin size veremeyeceği kısım budur. Bir framework, sizin için kaydırıcıda bir konum seçer ve sizi kilitler. İşçi modeli, kaydırıcıyı sizin elinize bırakır.

Bunun pratikte anlamı

Bir framework'ün üzerinde bir agent çalıştırıyorsanız ve çoğu ekibin ölçekte karşılaştığı aynı sınır sorunlarını hissediyorsanız, cevap muhtemelen "koşum takımını kendi framework'ümüzde yeniden yazmak" değildir. Politika motoru ihtiyacınız olduğu gibi genişlemiyor. Onay UI'ı framework'ün sohbet yüzeyine bağlı. Kimlik bilgisi deposu sırlar yöneticinizle konuşamıyor. Bütçe takipçisi, izin göremediği bir yan veritabanında. Cevap, koşum takımının en başında ayrıştırıldığı bir alt tabakaya geçmektir.

Argümanı hissetmenin en hızlı yolu, github.com/iii-hq/workers reposunu klonlamak, pnpm install, pnpm build yapmak ve birleşik giriş noktasını çalıştırmaktır. Bir iii motoruna yönelik tam on dört işçili koşum takımını elde edeceksiniz. Herhangi bir işçiyi, girişini önyükleme listesinden kaldırarak devre dışı bırakabilirsiniz. Herhangi bir işçiyi, aynı fonksiyon kimliklerini kaydeden bir yedek yazarak değiştirebilirsiniz. Herhangi bir işçiyi, kanca konularına bir abone ekleyerek genişletebilirsiniz. hook-fanout::publish_collect, her iii kancasının üzerine inşa edildiği genel yapıdır.

Dokümanlar iii.dev/docs adresinde. Motor github.com/iii-hq/iii adresinde. İşçi kaydı workers.iii.dev adresinde. Koşum takımı paketi github.com/iii-hq/workers/harness adresinde.

İddia

Bir koşum takımı, kurduğunuz bir şey değildir. Bir koşum takımı, bir agent'ın dayanıklı, güvenli ve gözlemlenebilir bir şekilde çalışması için sisteminizin yapması gereken bir dizi iştir. Framework çağı, bu işleri bir araya getirdi çünkü altında hiçbir şey size onları birleştirmenin bir yolunu vermiyordu.

iii'in iddiası, tek bir ilkel öğenin: motora WebSocket üzerinden bağlanan ve fonksiyonlar ile tetikleyiciler kaydeden bir işçinin, bu işlerin her birini ayrı ayrı emebilecek kadar küçük olduğu ve ortaya çıkan yığının, her katman bağımsız olarak değiştirilebilir olduğu için herhangi bir framework'ten daha kullanışlı olduğudur.

Siz iii koşum takımını benimsemezsiniz. İstediğiniz işçileri kurar, ihtiyacınız olanları yazar ve tam olarak sisteminiz gibi şekillendirilmiş bir koşum takımına sahip olursunuz. Her katmanda aynı protokol. Her çağrıda aynı iz. Kayıttan aldığınız parçalar için de kendinizin yayınladığı parçalar için de aynı iii worker add.

Alt tabaka doğru şekilde olduğunda "kendi agent koşum takımını oluşturmak" işte böyle görünür. İşçileri seçin. Eksik olanları yazın. Birleştirin. Koşum takımı, birleştirmenin kendisidir.

Modern dünyanın ihtiyaç duyduğu mükemmel agent koşum takımını oluşturmak için bize katılın: discord.gg/iiidev

iii açık kaynaktır. Başlamak için iii.dev/docs adresini ziyaret edin. Koşum takımı işçileri github.com/iii-hq/workers adresinde ve motor github.com/iii-hq/iii adresindedir.

— Mike Piccolo, Kurucu ve CEO @iiidevs