Esettanulmány
- Asztali alkalmazás
- Mobilalkalmazás
- AI-eszközök
Az AI-agent munkafolyamat, amelyet mi is használni akartunk
A Crystal Lattice-et nyilvános terméknek terveztük, az első mérföldkő azonban nagyon gyakorlatias volt: készüljön el egy olyan MVP, amelyet valós fejlesztéshez használhatunk, működés közben átláthatunk, hiba után folytathatunk, különböző szolgáltatókhoz konfigurálhatunk, és új képességekkel bővíthetünk anélkül, hogy minden változtatást szétszórnánk az alkalmazás magjában.
- Projekt
- crystallattice.dev
- Első mérföldkő
- Belső fejlesztésben használt MVP
- Jelenlegi állapot
- Aktív fejlesztés alatt
Kiinduló probléma
Az OpenCode állt a legközelebb ahhoz, amit szerettünk volna, de több gyakorlati probléma is megmaradt.
A költségkövetés megbízhatatlan volt, miközben a szolgáltató már biztosította a szükséges információt. Ha egy szolgáltatói kérés hibával leállt, nem lehetett a hiba pontjától folytatni. Vissza kellett vonnunk a teljes kört — a már lefutott eszközhívásokkal együtt —, majd elölről kellett kezdenünk.
A szükséges OpenRouter-integrációban a gondolkodási adatok elvesztek az eszközhívások után, ezért a modellnek újra és újra végig kellett gondolnia a munkát. Ennek a szolgáltatóspecifikus hibának a kijavítása aránytalanul sok időt vitt el, mert a teljes megoldás több repository módosítását és több upstream pull requestet igényelt.
Az eszközleírások olyan utasításokat is tartalmaztak, amelyeket nem akartunk, és nem tudtunk konfigurálni. Egy olyan szolgáltatói beállítás módosításához, mint a reasoning effort, vissza kellett térni a konfigurációhoz ahelyett, hogy az értéket a felületen állíthattuk volna.
A Codexet és a Claude Code-ot szándékosan felhasználóbarátabbra tervezték. A mi esetünkben ez azt is jelentette, hogy olyan részleteket rejtettek el, amelyeket látni szerettünk volna, és olyan vezérlőket tettek távolabb, amelyeket közvetlenül akartunk elérni.
Közben a szolgáltatók már natív webes keresést és tömörítést vezettek be, a rendelkezésre álló nyílt forrású agentekben pedig nem volt egyszerű mód ezek hozzáadására. Nem további kerülőmegoldásokat és több repository között szétszórt javításokat akartunk fenntartani, hanem olyan terméket, amelynek a működése érthető, módosítható és bővíthető.
Mit kellett lehetővé tennie az első MVP-nek
- Látható
- Munka közben érthetőnek kellett maradnia a szolgáltatói költségnek, az agent gondolkodásának, az eszközhasználatnak és a kérés állapotának, nem pedig egy leegyszerűsített felület mögé rejteni ezeket.
- Konfigurálható és testreszabható
- A szolgáltatói paramétereket, a reasoning effort értékét, az eszközutasításokat és a releváns felületi vezérlőket úgy kellett módosíthatóvá tenni, hogy a speciális esetek ne szóródjanak szét a konfigurációban, a felületen és a mag működésében.
- Cserélhető és bővíthető
- A szolgáltatóknak, eszközöknek, riportoknak és szolgáltatónatív képességeknek egyértelmű határokra volt szükségük, hogy a termék újraírása nélkül lehessen őket hozzáadni vagy lecserélni.
Első mérföldkő: működő terminál és Codex-szerű eszközök
Az első használható mérföldkő egy egyszerűen működő terminál volt.
Az MVP-hez egy kicsi, Codex-szerű eszközkészlet is elég volt: Bash, apply_patch és webes keresés. Ez a kombináció már természetes munkát tett lehetővé az agenttel, és elegendő volt az alkalmazás továbbfejlesztéséhez.
Nem volt mindegy, milyen szerkesztőeszközt kapott a modell. Kevésbé megfelelő eszközöknél sok időt tölthetett azzal, hogyan kellene elvégeznie a módosítást, vagy miért nem sikerült az eszközhívás. Az apply_patch közvetlenebb és kiszámíthatóbb szerkesztési munkafolyamatot adott, hasonlót ahhoz, ami a Codexet hatékonnyá tette ebben a felhasználásban.
Az MVP minden befejezett lépés után megőrizte a munka állapotát, így egy szolgáltatói hiba után anélkül lehetett folytatni, hogy a már lefutott eszközhívásokat is vissza kellett volna vonni. A munkamenetet a beszélgetés tetszőleges pontjáról el lehetett ágaztatni is, nem csak egy felhasználói üzenet után.
A használati plugin átvette a szolgáltató natív használati adatait, és megjelenítette a kérés költségét, valamint a munkamenet folyamatosan frissülő teljes költségét. A nyers értékeket a szolgáltató már biztosította; a plugin tartalmazta a felületi megjelenítéshez szükséges szolgáltatóspecifikus értelmezést.
Miért marad a szolgáltató eredeti válasza az elsődleges forrás
Ha a szolgáltató azt várja, hogy a következő kérésben visszaküldjük egy korábbi válasz adatait, a legegyszerűbb megoldás ezeket eredeti formájukban megőrizni. A közös formátumra alakítás, majd a szolgáltatóspecifikus változat minden kérés előtti újraépítése további átalakítási logikát igényel, és információvesztéssel járhat.
A Crystal Lattice a teljes szolgáltatónatív előzményt a native_messages reprezentációban őrizte meg, és ezt használta a következő kérések bemeneteként. A külön normalizált messages reprezentáció a megjelenítést és az általános munkamenet-műveleteket szolgálta.
A gondolkodási adatok kezelése fontos teszteset volt, mert szolgáltatónként eltért, milyen formában és milyen adatokkal lehetett folytatni a kört. Ezek között szerepelhetett a gondolkodás szövege, titkosított gondolkodási adat és aláírás is. Az eredeti válasz megőrzése egyszerűbbé tette ezeknek a különbségeknek a kezelését az eszközhívási körök között, miközben a folytatáshoz szükséges adatok változatlanul megmaradtak.
Megőrzött szolgáltatói adatok
- Titkosított vagy natív gondolkodás
- Szolgáltatóspecifikus eszközhívások és azonosítóik
- Használati és költségadatok
- Gyorsítótárazott tokenek adatai
- Hivatkozások
Későbbi integrációk
- Natív tömörítési elemek
- Csatolmányok és képek
- Más folytatási adatok
Plugin-alapú működés és vezérlők
A szolgáltatóspecifikus költségkezelést, gondolkodási vezérlőket, eszközöket és felületi beállításokat pluginok valósították meg ahelyett, hogy a logika szétszóródott volna a magban és a különböző frontendekben.
Így egy szolgáltatói natív képesség, például a webes keresés vagy a tömörítés egységes bővítményként kerülhetett a rendszerbe. Egy olyan paraméter, mint a reasoning effort, szolgáltatótól függő pluginadatok alapján jelenhetett meg a felületen, ahelyett, hogy minden frontendben külön beégetett vezérlőre lett volna szükség.
- A szolgáltatói működés cserélhető vagy bővíthető maradt.
- Az eszközutasítások és képességek konfigurálhatók voltak.
- A felületi vezérlők követhették az aktív szolgáltatót vagy képességet.
- A riportok tartalmazhatták a szükséges szolgáltatóspecifikus logikát.
Mobilkapcsolat a számítógéphez
A mobilalkalmazás a számítógépen futó agent chatfelületeként működött.
Azonos hálózaton a telefon közvetlenül, helyi hálózaton kapcsolódhatott. A hálózaton kívül a bridge biztosította a kapcsolatot. A telefon egy másik felületet adott a számítógépen futó agenthez és ugyanazokhoz a munkamenetekhez.
A jelenlegi termék fejlesztése
Ezek a jelenlegi képek az első MVP után hozzáadott vagy továbbfejlesztett képességeket mutatják.
Hogyan igazoltuk az MVP használhatóságát
Amint az alapvető terminál elkészült, azonnal valós fejlesztési munkára kezdtük használni a Crystal Lattice-et — többek között magának a Crystal Lattice-nek a további fejlesztésére.
Ez volt az első mérföldkő gyakorlati igazolása. A termék nem maradt egy prototípus, amely egy későbbi tesztprojektre várt: abból az eszközből lett, amellyel a termék fejlesztését folytattuk.
Az első MVP használhatóvá vált arra a munkafolyamatra, amely miatt eredetileg létrehoztuk.
Jelenlegi állapot és következő mérföldkő
A Crystal Lattice-et kezdettől nyilvános használatra szántuk. Az első MVP-t azért használtuk belső munkában, mert így attól a pillanattól kezdve valós problémákat oldott meg, hogy a terminál használhatóvá vált.
A projekt aktív fejlesztés alatt áll. A következő mérföldkő a nyilvános, nyílt forráskódú kiadás: először jobb első felhasználói élménnyel macOS-en, majd a támogatás és a kezdeti használhatóság bővítésével más operációs rendszereken.
Saját AI-terméket vagy egyedi agentmunkafolyamatot fejlesztene?
Írja meg, melyik munkafolyamatnak kell átláthatónak maradnia, melyik viselkedést kell konfigurálni, és mely szolgáltatóknak, eszközöknek vagy képességeknek kell később is szabadon fejlődniük.
Beszéljünk a termékről