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.

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.

Ábra az eredeti szolgáltatói válasz következő kéréshez való megőrzéséről és a megjelenítéshez használt külön normalizált reprezentációról. — Az eredeti szolgáltatói válasz marad a következő kérés forrása; a közös formátum a megjelenítést és az általános munkamenet-műveleteket szolgálja.

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.

A Crystal Lattice mobilos pluginvezérlői tömörítéshez, prompt-gyorsítótárazáshoz, gondolkodási beállításokhoz és webes kereséshez. — A mobilos pluginvezérlőkön külön kapcsolható a natív tömörítés, a prompt-gyorsítótárazás, a gondolkodási beállítások és a webes keresés.

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 Crystal Lattice első mobilbeszélgetése a Markdown-megjelenítés hozzáadása előtt. — Az első mobilfelület már kapcsolódott a számítógéphez és megjelenítette a beszélgetést, de még nem formázta a Markdown-t.

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.

A Crystal Lattice jelenlegi mobilos chatje kéréssel, gondolkodással, eszközhasználattal és munkamenet-állapottal. — A jelenlegi mobilos chatben a kérés, a gondolkodás, az eszközhasználat és a munkamenet állapota együtt követhető.

A Crystal Lattice jelenlegi asztali felülete, amely együtt mutatja a munkamenetlistát és az aktív beszélgetést. — Az asztali alkalmazás egyetlen munkafelületen mutatja a munkameneteket, az aktív beszélgetést, az eszközhasználatot és az üzenetírást.

Befejezett Crystal Lattice-válasz a tokenhasználat és a becsült költség kinagyított részletével. — Minden befejezett válasznál láthatók a bemeneti, kimeneti, gyorsítótárazott és gondolkodási tokenek, valamint a válasz és a teljes kör becsült költségei.

A Crystal Lattice mobilos költségriportja napi, projekt-, feladat- és munkamenet-bontásokkal. — A jelenlegi költségriport a kérés- és munkamenetköltséget napi, projekt-, feladat- és munkamenet-bontásokkal egészíti ki.

A Crystal Lattice mobilos kapcsolati lehetőségei helyi hálózati és bridge-eléréshez. — A telefon helyben vagy bridge kapcsolaton keresztül is elérheti a számítógépen futó alkalmazást.

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