Every API is a Tool for Agents with Code Mode

Bienvenidos a esta sesión sobre APIs, Codemode y MCP. Así que supongo que la tesis de esto es que cada API va a ser una herramienta para agentes. Y hablaremos sobre lo que eso significa un poco en el futuro. Pero mi nombre es Matt. Trabajo en agentes y MCP en Cloudflare. Y bienvenidos a esta charla.

Mi trabajo es realmente, realmente divertido porque puedo averiguar cómo se verá el futuro de estas cosas. Y puedo probarlo y jugar con ello. Y muchas veces, me recuerda a este meme. Así que pensé en aligerar el ambiente con el meme. Entonces, si un perro usara pantalones, ¿los usaría así o así? No tengo idea. Pero supongo que sería genial experimentar con uno u otro. El de la derecha parece que sus piernas podrían enfriarse. Pero nunca se sabe. Pero esto es en realidad en lo que paso mi día a día trabajando.

Así que, como, dando manos a los agentes. ¿Cómo dejamos que la IA, que se ha vuelto tan útil en los últimos años, acceda a cosas fuera del entorno en el que la hemos contenido? ¿Cómo dejamos que acceda a cosas fuera de la caja de cristal? Esto podría ser hacer, como, llamadas a APIs. Esto podría ser usar una computadora. Están haciendo todo esto. Pero básicamente se reduce a lo que se llamaba llamada de funciones y ahora mucha gente llama llamada de herramientas, dando herramientas a los modelos. Un usuario pide algo, el LLM responde y decide llamar a esta, como, herramienta.

Esta es una herramienta que el usuario luego ejecutará y luego regresará y dará al LLM el resultado. Llamada de herramientas. Y estoy seguro de que has visto un montón de estas cosas tal vez, como, en chat GPT o lo que sea. Pero así es como, en general, damos manos a los agentes para acceder a cosas en el mundo exterior. Hemos estado haciendo esto lo suficiente tiempo ahora, unos pocos años, que han surgido algunas cosas nuevas. Comenzamos con solo dar herramientas a los agentes dentro de sus propias aplicaciones. Así que, cada desarrollador escribiría sus propias herramientas, se las daría a su propio agente, su propio LLM en un bucle, y ejecutarían las herramientas cuando fuera necesario.

Y esto es bastante útil para tu propia aplicación. Pero como CloudFlare, como empresa, un productor de cosas como APIs y un productor de una plataforma, queremos permitir que nuestros clientes usen nuestra plataforma a través de estos, como, LLMs, estos agentes. Y para eso, necesitamos, sería realmente bueno publicar, como, un conjunto más estandarizado de herramientas que todos los demás pudieran usar. Y a lo largo de parte de este proceso, MCP nació en noviembre de 2024, ya, lo cual es, como, hace mucho tiempo, de lo que se siente como ayer. Pero la idea era que podrías tomar herramientas y otros elementos primitivos, como, recursos y prompts, pero principalmente la gente ha usado herramientas, y podrías alojarlas en un servidor en otro lugar.

Y luego cualquier agente que quisiera usar esas herramientas podría registrarse dinámicamente con esa autenticación, usar las herramientas, y decir, muchas gracias, realmente. Y desde el punto de vista de un desarrollador de servidores, es, como, ¿cómo compartimos herramientas con, como, agentes que nunca hemos conocido, con personas que nunca hemos conocido? Y esto no es tan normal en internet. Así que, hubo un nuevo flujo con nueva autenticación, DCR, registro dinámico de clientes que tuvo que desarrollarse un poco más. Y ahora estamos moviéndonos a algo llamado SIMD, Documentos de Metadatos de ID de Cliente, como, simplemente, formas en que permitimos a los agentes acceder a cosas para las que no tienen interacción.

Y es un tipo diferente de contrato de, como, un uso de cliente a API, porque cuando haces ese contrato, dices que la API nunca debería cambiar. Porque escucho que, como, el servidor MCP podría cambiar sus herramientas cuando quiera. Están registradas dinámicamente. Así que las hace muy útiles. Pero este no es realmente el punto de la charla. Esto es un poco de contexto. Pasamos de herramientas empaquetadas en cada aplicación a muchas herramientas siendo remotas, compartidas a través de MCP, Protocolo de Contexto de Modelo. Y luego, muy rápidamente, llenamos ventanas de contexto. Probablemente hayas visto, como, memes, como, artículos de noticias o noticias en general sobre, como, hay algunos servidores MCP que llenan enormes cantidades de contexto.

Por ejemplo, toda la especificación de la API abierta de Cloudflare es de 2.3 millones de tokens. Esto es enorme. Esto es mucho más grande de lo que podría caber en una ventana de contexto de un LLM. Fluctúan entre unos 30 a 50,000 tokens, hasta, como, 1 o 2 millones en el extremo superior. Pero esto es mucho más grande. E incluso si elimináramos un montón de cosas y lo convirtiéramos en la especificación de herramienta más básica, aún podría ser de unos 1.1 millones de tokens. Así que, con este proceso de dar herramientas a los agentes, los agentes no pueden acceder a la API de Cloudflare. Terminamos teniendo que hacer cosas como dividirlo, dividir estos servidores MCP.

Y de hecho, en mayo del año pasado, o abril del año pasado, añadimos desde entonces, lanzamos unos 13 servidores MCP para diferentes productos. Los clientes pueden agregarlos a su agente, usar los productos, luego desactivarlos o volver a activarlos según sea necesario. Pero esto, como, creo que tal vez esto es un problema. Y este es un poco el punto de la charla. Este límite de contexto no es inherentemente un problema de MCP. Es un problema de agente. Y no hemos aprendido las técnicas relevantes para reducir esto lo suficiente como para hacerlo utilizable. Necesitamos divulgación progresiva de herramientas.

Así que, podrías lograr esto de varias maneras diferentes. Estoy seguro de que si doy esta charla en seis meses o un año, habrá otras tres formas al final en que podemos lograr esto. Pero las principales son CLI bash, donde generas un CLI o creas un CLI para tu API o servicio y dejas que el agente instale ese CLI. Los CLI normalmente tienen un comando dash dash help. Y esto divulga progresivamente, como, diferentes capacidades al agente. No tienen que cargarlo todo en la ventana de contexto inicialmente. También puedes hacer cosas como, oh, así que el CLI es lo que usa OpenCore y otros agentes personales.

También puedes usar otras cosas como la búsqueda de herramientas. Entonces, la búsqueda de herramientas se ha utilizado en el código, estoy bastante seguro de que también en cursor. Y hacen algún tipo de búsqueda semántica, búsqueda BM25 sobre descripciones de herramientas. Y luego cargan la herramienta que el cliente necesita bajo demanda. Eso también es genial. Voy a proponer un tercer método. Y es uno sobre el que escribimos un post en el blog en el verano del año pasado que causó un poco de revuelo llamado CodeMode. Y luego Anthopic salió con algo llamado ejecución programática de herramientas, que es algo similar. Y recientemente escribí otro post en el blog sobre cómo podemos hacer CodeMode con un servicio MCP. Así que, este es el punto de la charla. Pero la idea principal es que creemos que las herramientas deben descubrirse bajo demanda, no volcarse en el contexto.

Así que, probémoslo. Hagamos un ejemplo. Construyamos esta API de gestión de proyectos. Así que, en realidad generé todo esto, API de gestión de proyectos. Está ejecutándose en workers, usando D1 como una pequeña base de datos. Son solo operaciones CRUD. Así que, no hay frontend. Así que, básicamente vamos a construir todos los frontends. Los agentes no necesitan un frontend, solo necesitan una API. Y podemos jugar con ella. Así que, hay 20 herramientas aquí. Bueno, 20 endpoints, por ejemplo. Así que, tienes cosas que ver con proyectos, sprints, tareas, tal vez comentarios. Y puedes hacer get, post, patch, delete en prácticamente todos estos recursos. Muy restful. Esto es como algo estándar con lo que podrías terminar. Puedes ver cómo puede muy rápidamente convertirse en muchas herramientas. Así que, 20 endpoints.

Probemos con bash. Así que, esto es un pequeño terminal que está conectado a un sandbox. Y no creo que haya nada aquí. Pero si hacemos un PM, precargamos esto. Así que, esto es solo un CLI generado que puede llamar a endpoints en el servicio SaaS que acabamos de crear antes. Así que, podemos hacer algo como PM projects, create, y luego como test project. Oh, necesito un nombre. Y aunque cometí ese error allí, es muy poco probable que los agentes cometan ese error. Porque había un ejemplo aquí que lo decía bastante bien. Bien. Genial. Así que, creamos un proyecto. Y ahora si hacemos PM projects list, en solo un segundo, obtenemos el proyecto de vuelta. Así que, como puedes ver esto funciona. Y un agente podría aprender a usar esto bastante bien. Podrías tener una habilidad o algo así para decirle que inicialmente llame a PM. Porque fue muy difícil encontrar eso en el propio espacio de trabajo. Y eso es bastante bueno, ¿verdad? Como, cada uno de estos ejemplos sucede. Si hacemos PM projects, así que, terminamos en projects, entonces deberíamos poder hacer help. Sí. Genial.

PM projects, entonces, terminamos en projects, deberíamos poder hacer help. Sí. Genial. Y es como autodescriptivo.

Y si cambiamos projects a algo como comments, otro, es autodescriptivo. Así que, el agente puede llamar a todas estas cosas, puede trabajar a través del proceso, puede descubrir cómo hacer cosas. Y es bastante agradable.

Y no tenemos la sobrecarga de volcar todas las herramientas en el contenido. Así que, eso funciona bien. OpenCore usa esto.

Entonces, lo que harías es que la intención del usuario se pondría en alguna búsqueda VM25. Y luego haríamos alguna búsqueda a través de ella. Y luego agregaríamos, como, los tres primeros. Como, el K es igual a tres. Agregaríamos esos a la ventana de contexto. Y luego el modelo tendría la capacidad de llamar a una de estas tres herramientas. O, como, o más, por ejemplo.

Y ahora, hemos creado un proyecto. Ahora, tal vez queramos listar los proyectos. Agregaríamos, como, otro par, otras pocas herramientas. Pero ves ahora, ya estamos en, como, 17,020 tokens. Como, esto es bastante de tokens en la ventana de contexto ya. Y solo hemos agregado unas pocas herramientas. Y solo, todo lo que hemos hecho es crear un proyecto y luego intentar listar proyectos. Así que, dependes mucho de qué tan buena sea tu búsqueda, qué tan bien documentadas estén tus herramientas.

Por ejemplo, tal vez quiera crear una tarea. Crear una tarea, crear una tarea en un proyecto. Pero tal vez quiera, como, iniciar una tarea o algo ligeramente diferente que la redacción no sea la misma. Ahora no es completamente obvio lo que haría. Así que, la respuesta real a cómo comenzaría una tarea o establecería una tarea como iniciada es en realidad obtener la tarea y luego actualizar la tarea. Pero ves que estos no aparecen realmente en los tres primeros. Así que, podrías tener, como, peores resultados. Y la gente a menudo encuentra esto con la búsqueda de herramientas. Es como no lo mejor para este tipo de cosas. Tienes que tener descripciones muy buenas. Descripciones a menudo incluyendo ejemplos también.

Genial. Sí. Entonces, eso es búsqueda de herramientas. Y ahora, estamos proponiendo algo ligeramente diferente, que combina la flexibilidad de un CLI con la portabilidad de una simple búsqueda de herramientas. Y esto es code mode. Así que, esto fue del blog que salió en el verano. Pero donde el agente ejecuta código generado por LLM en un VA isolate en sandbox y enviamos herramientas de vuelta al host. Se ha hecho mucho aquí para hacerlo muy seguro. Hablaremos de eso en un momento. Pero, ¿qué es code mode? Primero, generamos un SDK tipado, y esto es genial.

Así que, de esto, como, obtener proyectos API, generamos estos tipos. Vienen directamente de la especificación open API y los escribimos en TypeScript. Y si quieres crear un proyecto, ves esta entrada de crear proyecto, salida de crear proyecto. Y estos tipos actúan como un esquema de entrada que podrías ver en una herramienta. Excepto que son un poco menos estructurados, potencialmente. Pero básicamente actúan de manera muy, muy similar. Podemos generarlos a partir de un esquema JSON en una especificación open API o de un esquema y podemos poner esto en una ventana de contexto. Así que, eso es bastante genial. Podemos generarlos.

Y luego podemos simplemente llamar, así que una vez que hemos generado los tipos, esos tipos viven en este SDK que generamos. Y luego simplemente llamamos a métodos en el SDK y el modelo sabe qué métodos puede llamar porque tiene los tipos y los tipos se relacionan con los métodos de una manera que puede interpretar. Así que, por ejemplo, si quisiéramos listar todos los proyectos, el agente generaría este código, este modo de código de proyectos lista proyectos. Tal vez console log algo, realmente no importa y luego devolver los proyectos con nombre e ID. Entonces, ¿qué pasó aquí? Enviamos el código a este VA isolate, llamamos a esta lista de proyectos, encontramos un proyecto, el proyecto que acabamos de crear antes. Todo esto se está ejecutando en la API que creamos justo al principio. Así que, todos estos procesos, todas estas cosas están ejecutándose directamente sobre esta compañía SaaS imaginaria que hicimos al principio, esta compañía SaaS de gestión de proyectos. Piensa en ello como un JIRA o un linear, por ejemplo.

Así que, aquí listamos proyectos. Pero ahora queremos crear un nuevo proyecto. Entonces, le preguntamos al agente, ¿puedes crear un proyecto? Y genera un código algo similar a esto. Y luego ejecutamos ese código. Y ahora probablemente estés pensando, oh, Dios mío, estás ejecutando código generado. Estás ejecutando como código generado no confiable. Esto es súper, súper aterrador. Y estoy de acuerdo contigo. Esto es súper, súper aterrador. Y hablaremos sobre cómo hacemos esto menos aterrador y por qué creo que este es el futuro. Pero puedes ver aquí que acabamos de crear un proyecto.

Y ahora tal vez queramos crear una tarea. Entonces, tarea, enviar code mode, estado crítico. Y creó una tarea. Eso es bastante bueno. Y podemos asignar una tarea. Vamos a asignarla a mí. Hermoso, hermoso, hermoso. Y todo esto es editable. Digamos que queríamos hacer un console log como hello node o algo así. Oh, no. Recuerda no usar las teclas de flecha. Si quisiéramos ejecutar esto. Oh, me falta. Tiene que ser typescript válido. Y esto es solo código que podemos generar. Y ahora podemos ejecutar.

Pero, ¿cómo lo ejecutamos? Oh, lo siento. Vamos a retroceder un poco. Primero, ¿por qué es esto realmente, realmente genial? Así que, hemos hecho todas estas cosas diferentes aquí. Pero todas estas podrían ser mapeadas a una herramienta individual. Y dirías, Matt, podríamos tener cuatro herramientas, cada una de estas cosas. Y claro, podrías hacer todo este flujo. Y yo digo, sí, claro, podrías hacer todo ese flujo. Pero, ¿por qué si la intención del usuario es crear un proyecto, crear una tarea en ese proyecto y luego asignarla a mí? En primer lugar, no necesitan listar proyectos inicialmente. La IA debería saber que podría hacer eso. Y en segundo lugar, todas estas tres cosas, no tienen que ser operaciones separadas. Podrían hacerse en una sola. Oh, Matt, ¿por qué no hacemos una herramienta singular para esto? Tal vez no quiero asignar la última tarea. Quiero asignarla a otra persona. O quiero cambiar el flujo de trabajo ligeramente.

Y ahora se vuelve frágil. ¿Cómo lo hacemos menos frágil? El código es una buena representación de un flujo de control. Especialmente, creo que TypeScript se ve bastante bien. O en este caso, JavaScript se ve bastante bien. Puedes escribir Python aquí. Puedes escribir lo que quieras. Pero el código ha sido construido a lo largo de los años para ser un plan muy natural y compacto. Entonces, en lugar de hacer esta llamada de herramientas muy voluminosa donde tenemos que llamar a esta, llamar a esta, llamar a esta, llamar a esta, y llamar a esta, podemos hacer un solo viaje de ida y vuelta y hacer todo de una vez.

La IA sabe lo que puede hacer porque tiene todos los tipos. Así que, ya tiene esa capacidad. Y puede simplemente hacerlo todo de una vez. Y verás algunas propiedades emergentes interesantes al hacer esto. Como que estaba jugando con esto antes, pidiéndole que eliminara algunos proyectos que no había usado en un tiempo. Y revisó todos mis proyectos. Encontró los de hace unos meses. Y fue como, ¿quieres los de hace más de seis meses? Yo estaba como, sí, más de seis meses suena bien. Los ordenó, los clasificó, y luego los eliminó todos de una vez. Y puede escribir una pieza singular de código para hacer eso. Lo cual creo que es realmente, realmente genial. Y supongo que lo último sobre por qué es que es enormemente eficiente en tokens hacer esto.

Así que, dejando de lado el hecho de que es tan componible, es como masivamente más eficiente en tokens. Si añadimos una búsqueda y ejecución en la parte superior del SDK de code mode. Entonces, en la búsqueda, puede buscar sobre los tipos o algún tipo de especificación estructurada. Y en ejecutar, puede simplemente escribir código para llamar al SDK de tipo. En la búsqueda, también simplemente escribe código. No hay una función de búsqueda estática. Simplemente escribe código. Luego tenemos los beneficios de como Bash, de poder ser como componible y cosas así y llamar a diferentes cosas y encadenar operaciones. Pero tenemos la eficiencia de herramientas de búsqueda de código, de búsqueda de herramientas. Y también tenemos algo de portabilidad aquí también. Porque en realidad no necesitamos una VM completa para hacer esto. No estamos ejecutando Bash. Solo estamos ejecutando TypeScript. Y en TypeScript, podrías ejecutar cosas en aislados muy, muy ligeros. Así es como estamos ejecutando esto. Los LLMs son mejores escribiendo código.

Todas estas diapositivas están bastante generadas. Creo que eso vino de una de nuestras publicaciones de blog. Creo que esa es la última. Y esto es cierto. Son mucho más eficientes en tokens. Hicimos algunas evaluaciones con brain trust que realmente no puedo compartir aquí. Pero mucho más eficientes en tokens. Hay muchas personas que han estado probándolo desde que salió nuestra última publicación de blog. Pero sí, siéntete libre, envíame algunos resultados.

Son mucho mejores escribiendo código para llamar a MCP que simplemente llamando a MCP directamente. Eso es porque la idea de llamar a herramientas es una idea muy voluminosa. Tienes que encapsular una acción en esta herramienta. ¿Por qué no simplemente escribimos código? Simplemente escribe código. Eso es genial. Pero ¿por qué no han escrito código antes? Porque generar código no confiable es súper aterrador. Es mentalmente aterrador donde estás como, está bien, todos nuestros clientes pueden escribir el código que quieran y lo vamos a ejecutar por ellos. No vamos a mirarlo. Nadie va a mirarlo. Simplemente lo vamos a ejecutar.

Podría no estar bien si haces eso. Y esta es la razón por la que la gente no ha hecho esto en el pasado. Condujo a muchas situaciones locas. Muchas personas han construido sus propios lenguajes específicos de dominio, sus propios lenguajes de consulta. Ves que la mayoría de las grandes empresas SaaS tienen su propio lenguaje de consulta. ¿Por qué no te dejan simplemente escribir código contra sus APIs internas? Porque quieren restringir lo que puedes hacer. Quieren tener acciones y tener políticas de permisos y tener todo esto para poder ejecutarlo en algún tipo de motor que controlen. Y anteriormente eso era realmente, realmente difícil. Si les permitías simplemente escribir JavaScript directamente o simplemente código directo y ejecutaban ese código, entonces ¿qué podrías hacer?

Podrías obtener variables .env. Eso sería malo. Podrías hacer solicitudes de red a Trojanhorse.com y luego descargar todo ese software y simplemente ejecutarlo en un subproceso. Eso también sería realmente malo. Podrías efectivamente realizar un ataque de denegación de servicio desde dentro de su propio entorno de cómputo. Eso también sería realmente malo. Podrías simplemente ejecutar bucles infinitos. Podrías ejecutar mineros de criptomonedas. Podrías ejecutar todas estas cosas. Y también podrías derribar todo su servicio agotando la memoria de ese proceso y cualquier otro proceso en el que te coloquen. Todas estas cosas serían realmente, realmente malas. Y la gente ha intentado muchas otras cosas para intentar restringir esto. Así que DSL ha sido el popular, pero Docker de alguna manera también hace esto. Y estos también son diferentes a las VMs, como AWS Lambda es una VM. Usa Firecracker bajo el capó.

Y eso es literalmente lo que están haciendo. Están evitando que escribas cosas que podrían romper su sistema. Y esto no es súper escalable, pero la verificación humana también es una opción. Y estas son solo varias versiones de un sandbox. Y supongo que la razón por la que podemos hacer code mode y somos muy populares, somos muy optimistas con code mode, es porque creemos que tenemos un sandbox muy, muy bueno para ejecutar código no confiable. Y esto es dynamic worker loaders. Dynamic worker loaders, nombre súper pegajoso, pero básicamente solo estás ejecutando un Cloudflare worker desde un script. Así que en realidad, muy similar a cómo ejecutamos Cloudflare workers bajo el capó, nos das algún tipo de módulo o podrías tener múltiples módulos.

Y luego, en este caso, es solo código generado. Y luego puedes simplemente ejecutar ese código en otro worker que generaste desde el worker anfitrión. Y así está súper aislado. Tenemos casi como inicios en frío instantáneos, como VA isolates comienzan muy, muy rápido. Sí. Está súper aislado. No hay sistema de archivos al que pueda acceder aparte de su propio código. E incluso eso, solo es accesible en ciertos escenarios. Tienes control total sobre la salida de red. Así que puedes bloquear todas las solicitudes fetch. Puedes hacerlo completamente aislado de la internet pública. O puedes inspeccionar cada solicitud fetch. Como esta función global outbound aquí te permite inspeccionar cada solicitud de red que sale. Decir que cumple con ciertos criterios, golpeando tu plataforma SaaS, si no, o incluso solo golpeando ciertos endpoints, dependiendo del usuario. Tienes ese control total allí. Cada isolate tiene su propia memoria.

Cada isolate tiene su propia memoria. También puedes darle herramientas externas a través de bindings, a través de Cloudflare bindings, en lugar de simplemente dejar que llame a fetch. Y así tienes más control allí también. Pero esencialmente, creemos que estos son un primitivo realmente, realmente bueno para ejecutar código generado no confiable bajo demanda. Y podemos jugar con ello un poco ahora.

Así que esta es solo una simple secuencia de Fibonacci. Y podemos ejecutarla. Y esto es ejecutando código ahora mismo. Creo que esto es genial. Y solo para que no esté haciendo trampa ni nada. Podríamos simplemente devolver Matt's. Hey. Oh, necesito recordar no usar las teclas de flecha. Es un hábito muy difícil de dejar. Pero si ejecutamos eso ahora, obtenemos Matt hello.

Esto no está ejecutándose en el navegador. Estoy ejecutando las diapositivas en el navegador. Todo es React. Esto no está ejecutándose en el navegador. Todo esto va a nuestro servidor. Va a nuestro worker. Y este código, como una cadena, se envía a un dynamic worker y se ejecuta en un dynamic worker. ¿Qué significa esto? Esto significa que si intentamos hacer una solicitud fetch, por defecto, está bloqueada. Y esto no es porque estemos parcheando fetch global o algo así. No, el host real no tiene, inspeccionamos todas las llamadas salientes. Y fetch aquí está simplemente bloqueado. Completamente bloqueado.

Pero tal vez vamos a permitir esto, en este caso. Y ahora podemos permitirlo. Así que esto es como HTTP.org. Creo que este es un ejemplo JSON que la gente usa. No lo sé. Claude lo encontró para mí. Pero esto es súper poderoso. Porque ahora podemos hacer cosas como poner esto frente a nuestra Cloudflare API y tener conocimiento absoluto. La única manera en que la gente puede usar este servicio es llamar a la Cloudflare API. Anteriormente, esto habría sido súper, súper difícil. Y este es un primitivo de infraestructura que tiene todo esto listo para usar. Y hay un montón de otras cosas, deberías jugar con dynamic worker loaders. Creo que son realmente, realmente geniales. VA isolates para código no confiable, inicio en frío súper rápido. Todo lo bueno. Pero con un aislamiento realmente bueno. Y solo como una mejor sandbox.

Una sandbox súper ligera. Así que estamos llegando al final de la charla ahora. Así que hay un poco de demostración aquí. Y lo que estamos demostrando aquí es de vuelta, cuando volvimos al principio, teníamos esto como la API de gestión de proyectos. Y dijimos que podríamos hacer código sobre la API de gestión de proyectos, por lo que podríamos generar un SDK de TypeScript. Y podríamos dar eso al agente. Así que eso es lo que estamos haciendo aquí. Y solo como una interfaz de chat muy pequeña. Así que podemos ser como, ¿qué proyectos tenemos? Y si solo inspeccionamos las llamadas de herramientas aquí. Todavía estamos moviéndonos. Acabamos de llamar a code mode.listprojects. Y está escrito código aquí. Y ha devuelto estos dos proyectos que tenemos. Así que tenemos el proyecto de prueba que creamos inicialmente a través de la sandbox, a través del CLI. Y luego tenemos el proyecto Node Congress que creamos a través del dynamic worker anteriormente. Y todos estos fueron creados allí. Sí, genial.

Así que puedes mostrar las tareas. ¿Qué tal si nos muestras las tareas en el proyecto Node Congress. Genial. Así que esta es la tarea. Así que la tarea era enviar code mode. Genial. Así que, ¿qué tal si decimos algo como esto está hecho, elimínalo. Pero el siguiente paso es que necesitamos hacer que esto funcione para la Cloudflare API, no solo algún creador de SAS aleatorio nuevo ticket para ese comentario asignado al mapa. Vamos. Así que anteriormente esto habría sido muchas llamadas de herramientas. Quiero decir, me pasé un poco solo para demostrar eso. Pero anteriormente esto habría sido eliminar esta tarea, hacer un nuevo ticket, eso ya son dos, luego asignarme tal vez otro, y luego comentar. Así que eso es como cuatro. ¿Qué es ahora? Es una herramienta de code mode donde escribimos algo de código. Y lo hace todo de una vez.

Eso es bastante genial. Así que actualizamos este, creamos este, y comentamos sobre él. Increíble, ¿verdad? Marcamos el code mode como hecho. Bien. Lo marcamos como hecho en lugar de eliminarlo. Muchas gracias. Eso es muy amable de tu parte, guardando todos mis datos. Pero todo esto sucedió en una sola llamada de herramienta. Así que no solo somos masivamente más eficientes en tokens en lo que entra en el LLM, somos más eficientes en tokens en la salida. Estos pasos, ninguno de ellos tuvo que ser devuelto al modelo. Ahorramos muchos tokens aquí solo a lo largo del proceso. Y haremos algunos benchmarks sobre esto más tarde, pero es casi tan abrumador que es como, una vez que lo pruebas, dices, oh, Dios mío, esto es simplemente mejor. Pero compartiremos algunos benchmarks sobre esto para casos de uso general. Genial.

Así que esto estaba haciendo code mode en esa API de gestión de proyectos. Pero comenzamos esto hablando sobre MCP. ¿Cómo podemos tomar lo que hemos hecho aquí con code mode solo en una API que poseemos y herramientas que poseemos y hacerlas remotas? Así que digamos que Cloudflare como plataforma crea una API, bueno, tenemos una API, enorme, 2.3 millones de tokens. Pero queremos un servidor MCP solo para toda la API de Cloudflare. Pero no queremos que los usuarios, no queremos que los agentes de usuario, si estoy usando esa palabra, pero no queremos que los agentes de usuario tengan que entender cómo funciona code mode o implementarlo incluso en sus agentes porque es mucho trabajo. Construir un cliente MCP ya es increíblemente difícil comparado con construir un servidor MCP. Tenemos algo de experiencia en esto. Vamos a intentar llevar algo de esta complejidad al servidor. Y de esto se trataba nuestro último post en el blog. Y fue bastante exitoso porque a la gente le gustó. Significa que pueden hacer clientes o agentes MCP muy, muy simples, solo un LM en un bucle que se conecta a un servidor MCP para sus herramientas. Y no tienen que preocuparse por todo esto porque nosotros manejamos todo en el servidor.

Entonces, ¿qué hacemos? El agente escribe algo de código. Llama a nuestro servidor MCP, nuestro servidor MCP de Cloudflare tiene dos herramientas, no solo una herramienta de code mode porque nuestra API todavía es realmente demasiado grande. Todavía necesitamos dos herramientas. Necesitamos permitir cierta divulgación progresiva, similar a la búsqueda de herramientas. Así que buscar y ejecutar. Y luego el LM puede llamar a buscar o ejecutar, llamar a buscar para tener una idea de lo que necesita llamar para ejecutar, llama a ejecutar para realmente ejecutar el código. Y luego para ambas herramientas, este cargador de trabajo dinámico de aislamiento V8 ejecuta el código. Y en eso llama a herramientas a través de RPC, usando un protocolo llamado CapMemWeb, que es súper, súper genial, pero una historia para toda otra charla. Creo que Kenton está hablando en esta conferencia. Así que sí, ve a su charla para entender más sobre CapMemWeb. Pero eso es en realidad parte de la magia subyacente a todo esto. El servidor controla la ejecución. Los agentes se mantienen súper simples. El protocolo MCP se preserva. No estamos tratando de reinventar MCP. Solo estamos permitiendo que funcione para APIs masivas. Y en realidad solo estamos permitiendo que el paradigma de herramientas funcione para APIs masivas punto final. Así que hagamos nuestra última pequeña demostración, nuestra última pequeña demostración. Intentemos listar algunos trabajadores en mi cuenta de CloudFlare. Uso este servidor MCP. Esta es una demostración muy pequeña. Estas ideas no son secretos ni nada. Pero vamos a usar map.

Así que vamos a ver qué workers están en mi cuenta. Esta es mi cuenta privada. O mi cuenta no laboral. Y así listamos algunos workers. Oh, debería haber cerrado eso. Bien. Estos son todos los workers en mi cuenta. Genial. Épico. Son en su mayoría solo demos. Pero hagamos bien. Entonces, ¿qué hacemos? Listamos algunos workers. Pregunta qué cuenta usamos. Y luego ha escrito algo de código para llamar al ha escrito algo de código qué es lo que aquí abajo? Ha escrito algo de código y está usando esta cosa llamada spec.path. Así que en es molesto dice herramienta aquí. Esto en realidad está llamando a la herramienta de búsqueda. Y en spec, tiene acceso a la especificación completa de open API de la API de CloudFlare. Y así está filtrando a través de algunos caminos. Está buscando el punto final de los scripts de worker. Lo está buscando. Lo ha encontrado. Es toda la información sobre todos mis workers. Y eso es todo. Y luego cuando sale, en realidad está llamando a ese punto final aquí. Así que hace estas dos herramientas. Dos llamadas de herramienta. Y ha llamado al punto final. Ha obtenido toda la información de vuelta de todos mis workers. Dulce. Bien. Eso fue genial. Ese es un caso de uso muy rehecho.

¿Qué pasa si queremos que los agentes tomen acción en CloudFlare en la plataforma de CloudFlare? Esto es genial porque ahora podemos construir infraestructura a escala global si esto funciona. Pero hagamos un worker de hello world. Genial. Y solo veremos qué hace esto. Vamos a llamarlo hello world. Así que vamos a construir un worker. Y voy a empezar a escribir algunas cosas porque esto toma un segundo. Sé que no nos queda mucho tiempo. Pero lo siguiente que vamos a intentar hacer es conectarnos a este worker. Así que podemos tener un contador de visitantes. Así que solo usando contador de visitantes. Así que solo usando otro primitivo en CloudFlare, kb es como un almacén de clave-valor. Así que vamos a intentar conectar eso a este worker. Solo crear un contador de visitantes muy, muy básico en el worker. ¿Está desplegado? Lo desplegó. Dame una URL. Así que solo estoy pidiendo cosas en inglés. No estoy pidiendo cosas muy específicas.

Oh, tuvimos un error. Vamos. Genial. Sí. No creo que haya leído lo que hice antes. Así que workers.dev dominio. Dame uno. Vamos. Quiero mostrarles todo esto funcionando. Es realmente bueno. Es realmente interesante aquí. Es un contador simple usando kb. Así que el tráfico concurrente no es perfectamente atómico. Para una demo, está bien. Si quieres un contador real, recomiendo durable objects en su lugar. También me gustan los durable objects. Gracias. Genial.

Eso es rebelde. No me ha dicho nada. Sé que es Matt Sedkeri. Pongamos esto aquí. ¿Demo, eh? Genial. Tenemos un contador de visitantes. Genial. Eso funciona. Espero que aún puedan ver mi pantalla. Bien. No ha deduplicado el favicon. Chrome siempre pide un favicon. Pero lo tenemos lo estamos obteniendo cada vez. Eso es genial. Vamos a ir un poco más salvaje. Sí. Añade el durable object. Permíteme escribir mensajes en esta pared. Hazlo local primero. Y sincroniza. Y ahora vamos a ir un poco más salvaje para la última demo que queda. Solo hazlo. Muchas veces uso cloud con esto y no hace preguntas. Simplemente va y lo hace. Pero veremos si esto va a funcionar. Lo siento, mi interfaz de usuario está como volviéndose loca. No lo he probado con tantas cosas. Puede que tengamos que terminar aquí. Le daremos un último intento para intentar hacer esto.

Pero yo, mientras esto está corriendo, les instaría a que, si están interesados en code mode, en cómo pueden dar a la API, una API masiva a un agente, yo, sí, echen un vistazo a este último blog post que publicamos. Y si quieren probar el servidor MCP ustedes mismos en un agente que sea un poco mejor que el demo que acabo de hacer ahora, tal vez Cloud Code o Open Code o algo realmente bueno, entonces prueben en mcp.Cloudflow.com. Esa es la URL para el servidor. Si quieren jugar con code mode ustedes mismos y quieren poner code mode encima de sus propios servidores MCP, entonces lanzamos un SDK para esto. Estamos contratando para mi equipo, equipo de agentes, realmente, realmente divertido. O siéntanse libres de conectarse conmigo en Twitter también. Sí, solo vamos a verificar cómo está yendo. Le pedí que hiciera demasiadas cosas de una vez. Eso fue tonto de mi parte. Mi UI está tan rota.

Sí, todas estas diapositivas fueron generadas. Tenemos una herramienta interna de generación de diapositivas llamada slides, creo, .Cloudflare.com, y todo usa Cloudflare sandboxes bajo el capó. Es muy, muy divertido. Sí, algunos de los nuevos modelos son realmente, realmente buenos haciendo diapositivas. Es solo React. Pero sí, muchas gracias. Y sí, siéntanse libres de contactarme si tienen alguna pregunta. Encantado de conocerlos a todos. Adiós.