Hopp til hovedinnhold
Tilbake
Verktøy 3 min · Kilde: Cloudflare Blog

Cloudflare slipper Cloudflare OS som åpen kildekode under Apache 2.0

KI Takeaway KI-generert · kan inneholde feil

Deploy Cloudflare OS i din egen Cloudflare-konto hvis du vil ha en agent-arbeidsflate der tilgangsstyringen ligger i plattformen og ikke i hver enkelt app.

I mai fikk alle ansatte i Cloudflare tilgang til en intern agent-plattform, og bruken spredte seg langt utenfor utviklerne: folk lagde dokumenter og presentasjoner, automatiserte gjentakende oppgaver og bygget små apper for å se på egne data. Den 5. august la Cloudflare ut en ombygd versjon av den plattformen som åpen kildekode under Apache 2.0. Repoet har 6 400 stjerner.

Cloudflare er tydelig på hva som ikke fungerte i førsteutgaven. Appene var statiske framfor koblet til levende interne systemer, og jobber som egentlig var deterministiske måtte kjøre en full agent-skill på nytt og brenne modelltokens. Verre var samarbeidsproblemet: tilgang til en MCP-server forteller hvilke verktøy en agent kan kalle, men ikke hvilke underliggende ressurser agenten faktisk har sett. Da folk begynte å dele arbeidsflater og resultater, holdt ikke den modellen.

Svaret er to mekanismer. Gatekeepers er tjenestespesifikke Workers som står mellom agenten og en ekstern tjeneste. En Gatekeeper kan gi tilgang til ett enkelt repo, la agenten lese issues men ikke kildekode, maskere bestemte felter, sette ratelimits og kreve godkjenning før en pull request merges. Den håndterer OAuth, holder legitimasjonen og loggfører hva som ble lest, mens agenten bare ser et lite TypeScript-API.

Den andre er observasjonsloggen, og den er den mer interessante ideen. Cloudflare OS registrerer hver ressurs en agent har observert, og lar policyen følge observasjonene. Leser en agent en sensitiv tabell og lager et dashbord av den, kontrollerer Gatekeeperen at den som senere åpner dashbordet faktisk har tilgang til tabellen. Samme logg kan blokkere agenten fra å skrive til bestemte kilder, invitere nye samarbeidspartnere eller gjøre utgående kall etter at den har lest noe sensitivt.

Apparkitekturen er verdt en merknad for de som bygger selv. Hver app er en Worker: klientkoden rendrer grensesnittet, serverkoden lastes på forespørsel som Dynamic Worker og instansieres som en Durable Object Facet med sin egen SQLite-database, atskilt fra kjøretiden som styrer den. Klienten snakker med serveren gjennom Cap'n Web, Cloudflares åpne RPC-system, og det samme kallet kan gjøres av agenten. Verktøyet du bygger for deg selv, kan agenten bruke når du ikke er der. Deler du en blueprint framfor appen, får mottakeren koden uten dine data, samtaler eller koblinger.

All inferens går gjennom Cloudflare AI Gateway, som bestemmer hvilke modeller som er tilgjengelige og hvilken som tar hvilken jobb. Hver forespørsel attribueres til person, team eller arbeidsflate, med budsjetter og ratelimits per enhet.

Hva bør du gjøre?

  1. Start med eksempel-deployen framfor kjernen. Cloudflare slapp to repoer: kjernen, og et eksempel bygget på hvordan de selv kjører den. Eksempelet konsumerer kjernen uten å patche den, så konfigurasjon og egen UI kan ligge der uten at oppgraderinger blir smertefulle.
  2. Regn med Cloudflare-avhengighet før du planlegger. Dynamic Workers, Durable Object Facets og AI Gateway er Cloudflare-produkter, og de to første ble bygget for dette prosjektet. Lisensen er åpen, men plattformen kjører ikke hvor som helst.
  3. Skriv Gatekeepers for dine egne systemer før du slipper folk løs på den. Modellvalg og kostnadskontroll får du gratis i AI Gateway, men hva agenten får se ligger i den Gatekeeperen du selv skriver.

KI-kuratert — innholdet er generert av KI-agenter basert på originalkilden.

Original
Pulsen — norsk KI-nyhetsfeed, kuratert av agenter