Protocolo de Coral sobre la construcción de la Internet de los Agentes para una economía de IA colaborativa
A medida que desaparece la era de los agentes de IA silados, está surgiendo un nuevo paradigma, uno en el que los agentes inteligentes no solo ejecutan, sino que colaboran.Protocolo de Corales pionero de esta visión con la infraestructura para la comunicación de agentes descentralizados, la orquestación y la confianza. nos sentamos con Roman Georgio y Caelum Forder, cofundadores deProtocolo de CoralPara profundizar en la arquitectura que impulsa el Internet de los Agentes, y por qué la economía de la IA de mañana necesitará más que sólo mejores modelos, necesitará una mejor cooperación.
Ishan Pandey:Hola Román, hi Caelum, es genial tener a ambos aquí. Comencemos con sus antecedentes. Ambos han trabajado en el borde de la investigación de AGI y la infraestructura de IA comercial. ¿Qué le llevó a iniciar el Protocolo de Coral, y cómo sus experiencias pasadas formaron esta visión?
Roman Georgio:Hola, gracias por tenernos, sí, así que nos encontramos trabajando en CAMEL-AI - un laboratorio de investigación de IA que encuentra las leyes de escalación de los agentes.Estábamos trabajando en proyectos multiagentes a lo largo de este tiempo y incluso antes de eso, Coral realmente llegó a nosotros por necesidad.
Caelum Forder:De hecho, empezamos a construir Coral como un medio para un fin para otro proyecto que queríamos hacer, era una especie de reportero automatizado que se pensaba en encontrar tendencias o eventos en los datos de comercio y conectarlos con artículos de noticias y lo que la gente estaba diciendo para crear y compartir narraciones relevantes. habíamos trabajado en algunas aplicaciones antes con necesidades similares, así que imaginamos que había una brecha allí para que realmente hiciéramos esto nuestra cosa principal.
Ishan Pandey:Pero en términos prácticos, ¿qué significa y qué problemas fundamentales busca Coral resolver en este contexto?
Roman Georgio:En pocas palabras, Cisco lo define como “un sistema en el que varios agentes de IA – desarrollados por diferentes proveedores o organizaciones – pueden comunicarse y colaborar sin problemas”.A primera vista, esto puede sonar abrumador, pero si realmente lo piensas, es poderoso: cualquier empresa o desarrollador puede aplicar su experiencia para construir los mejores agentes para su dominio.
La barrera de botella en este momento es que hay miles de frameworks de agentes, por lo que todos los agentes realmente cool que se están construyendo no pueden ser fácilmente reutilizados o colaborar entre sí. Coral tiene como objetivo desbloquear este bloqueador mediante la construcción de la infraestructura para que los agentes se unan a la "Internet de Agentes". Hemos hecho posible que cualquier agente, independientemente del marco, colabore. También proporcionamos una forma segura para que los creadores de agentes y desarrolladores de aplicaciones traten los pagos, por lo que las personas son realmente incentivadas a mantener y mejorar a sus agentes.
Ishan Pandey:La coordinación estructurada por gráficos y el sistema de memoria escalonada de Coral se destacan como novedosos primitivos. ¿Puede explicar cómo estas opciones técnicas de diseño soportan la colaboración multiagente escalable y segura?
Caelum Forder:He encontrado que la forma más útil de pensar sobre los agentes es en términos de responsabilidad en lugar de por tarea o capacidad - ¿de qué puede ser responsable? se hace claro entonces cómo descomponerlos y cuándo - un agente abrumado con responsabilidad fracasará, ya sea que sea demasiado en su ventana de contexto o simplemente demasiadas responsabilidades para asistir.
Los agentes basados en LLM son mucho más fáciles de sobreponer por la responsabilidad que los humanos son actualmente (y espero que esto no cambie demasiado pronto) Así que entonces este enfoque gráfico parece obvio, un enfoque estrictamente jerárquico impondrá responsabilidades abrumadoras a los agentes más cerca de la cima, teniendo que operar de forma independiente en un gráfico permite a los desarrolladores gestionar la responsabilidad de los agentes, prevenir la sobrecarga y escalar el sistema sin límites.
Ishan Pandey:Hablemos de MCP, el Protocolo de Contexto Modelo. ¿Qué hace que MCP sea un facilitador crítico de la interoperabilidad entre agentes? y cómo evita el tipo de bloqueo del vendedor que estamos viendo con marcos cerrados de IA?
Caelum Forder:Antes de MCP, la única forma práctica de definir herramientas era a través de los SDK propios del proveedor de modelos, como los SDK de openai o Python de Anthropic, o frameworks construidos para usarlos. Estos son técnicamente de código abierto, pero principalmente desarrollados por los propios proveedores de modelos que controlan las APIs de backend a las que se conectan. A medida que se hace disponible una funcionalidad específica como el caché prompt, se vuelve muy poco práctico no usar uno de estos SDK al hacer aplicaciones LLM, por lo que si querías que tu herramienta se utilizara ampliamente, tendrías que hacerlo disponible por separado en forma de herramienta que cada biblioteca con la que trabajan tus usuarios, que sería como 25 implementaciones separadas en unos pocos idiomas diferentes para capturar el 90% +, y mantener cada uno de ellos sería
Afortunadamente, MCP ha llegado y lo ha hecho mucho más práctico para construir software y servicios reutilizables para la intersección de la aplicación y el LLM, ni siquiera necesita considerar los lenguajes de programación ya que es io-limitado. que es muy bueno para evitar que cualquier proveedor de modelo único se convierta en el "default" y nos permite comenzar a escribir más lógica de aplicación reutilizada en nuestras aplicaciones alimentadas por el LLM.
Ishan Pandey:Muchos proyectos se centran en la inteligencia de agentes o el rendimiento del modelo. ¿Estás abordando la compostabilidad de agentes? ¿Por qué es esta la verdadera barrera para desbloquear la inteligencia colectiva entre agentes?
Roman Georgio:El objetivo de estos enfoques es realmente desbloquear capacidades, con capacidades desbloqueadas por el rendimiento del modelo más cerca de “crecimiento de capacidades” que de construir capacidades intencionalmente. Este enfoque de crecimiento anterior se ha demostrado popular y fácil, pero identificamos que la falta de enfocarse en elementos predictibles robustos que se pueden conectar entre sí estaba limitando la escala de composición que hace a Internet tan grande. Parece que hay una demanda de capacidad para hacer una especie de puente entre las capacidades “crecidas” y las “construidas”. La composibilidad es realmente esencial para construir cosas, hay estas propiedades que la mayoría de los software y servicios reutilizables tienen en común que faltan crucialmente en los servicios de IA. Y en realidad hay un gran lado de seguridad, una razón aún mayor en realidad. Queremos software que
Usted ve el último post de Anthropic sobre Claude 4 chantajeando al creador cuando sabe que va a ser cerrado, y usted tiene que pensar - los sistemas de crecimiento como este los hace realmente difíciles de confiar, no se puede saber cómo se comportarán en nuevas situaciones o con nuevos modelos. Incluso antes de que se vuelvan lo suficientemente poderosos como para ser una preocupación existencial, desde un punto de vista empresarial, ¿quieres usar modelos en la producción que no puedes confiar? la compostabilidad de los agentes, por otro lado, permite una forma mucho más predecible de escalar capacidades. También es un enfoque más descentralizado, creando más puntos de entrada para las empresas para ganar dinero y contribuir; versus un laboratorio de IA que se mueve hacia un monopolio.
Ishan Pandey:Desde una perspectiva de diseño de sistemas, ¿cuáles fueron los compromisos técnicos más difíciles que se enfrentaron al construir la arquitectura de Coral para la coordinación abierta y la gestión de la memoria?
Caelum Forder:Así que estábamos construyendo una especie de reportero automatizado que estaba destinado a encontrar tendencias o eventos en los datos de comercio y conectarlos con artículos de noticias y lo que la gente estaba diciendo para crear y compartir narraciones relevantes.
El caso de uso original suena relativamente complicado, pero comparte una propiedad increíblemente afortunada con algunas otras aplicaciones como la investigación y la prueba de software OSS, donde la confidencialidad de la información es mucho menos esencial que con la mayoría de los casos de uso donde desea agencia en servicios de software.
El “Problema de aislamiento” era casi un cryptid, como una criatura en el espacio de soluciones. Jugué con Roman que habría más observaciones de lo habitual a veces, o que debe estar teniendo hambre y que no le gustaría ciertas opciones mientras trabajaba en características potencialmente conectadas. tuve como 5 soluciones bastante profundas diseñadas, cada una con significativos compromisos y sus propios conjuntos de obstáculos.
He estado rastreando su actividad y podría decir que no les hubiera gustado. Pienso que como desarrolladores a menudo estamos perdiendo la oportunidad de tomar caminos de desarrollo intangibles, y terminamos teniendo que tomar caminos más largos, ancorados en cosas que son fáciles de explicar. Estos caminos pueden ser mucho más largos! Pero menos susceptibles de culpar. Un ejemplo de un camino tangible está haciendo una interfaz en React para coincidir con diseños que han sido entregados. La implementación y el diseño prácticamente forman una barra de progreso, y usted puede relajarse. Un camino de desarrollo menos tangible podría ser donde se le da una necesidad o intención específica, y usted podría ir a encontrar soluciones OSS con cartas de apoyo o desarrollar algo en casa, o alguna combinación. Incluso para comunicar un alto grado de intangibilidad en un camino de
Por supuesto, hay momentos en que los caminos tangibles son mucho mejores también, como cuando el trabajo necesita ser pre-emptable, su valor fácilmente comunicado antes de ser hecho, o hecho por un equipo desconocido y escalador.
Pero los incentivos comunes y la dinámica de confianza realmente predisponen a las personas hacia caminos de desarrollo tangibles, incluso cuando son los peores caminos, este es el problema. Las peores bases de código en las que alguna vez ha trabajado probablemente se formaron en entornos donde había un gran vicio lejos del trabajo intangible.
Esto es realmente problemático, sin embargo, porque te estás cortando de las conexiones restantes limitadas a la tangibilidad ocultando, y te obliga a tomar caminos más profundos y más peligrosos, que podrían ser incluso más largos, solo para evitar ser detectado y sacado del bosque oscuro en el que has invertido tanto.
Usted no puede simplemente quedarse en el bosque de criptógrafos, los no queridos no pueden alimentarte o pagar tu alquiler, todavía tienes que venir con frecuencia al aire y mantener alineamiento y contacto con la realidad. De todos modos, al final me sentí listo, y estaba en una posición muy afortunada donde podría pasar un montón de tiempo donde todo el progreso que hice era intangible y no necesitaba esconder.
El resultado que llamamos “Sesiones”, aunque no era una característica independiente tanto como un título de actualización. Se cambió el papel del protocolo 20% del camino a la de un marco o plataforma. Coral con Sessions impone restricciones de implementación (que puede ejecutar un proceso separado en una red privada con su aplicación), significa que cada implementación de nuestra especificación requiere un componente que es caro de implementar y obtener bien, lo que significa que está imponiendo sutilmente prescripciones a las aplicaciones que lo usan.
Estas cosas son muy incómodas para los desarrolladores de protocolos en teoría.En la práctica, sin embargo, el requisito de red privada se apoya casi universalmente después de la tendencia de microservicios.Sí, es difícil construir el servidor de coral, pero la gente puede simplemente usar el servidor de referencia que hemos hecho, ya que tiene límites de io y no necesita cumplir con los requisitos binarios / de vinculación que normalmente requerirían flexibilidad allí.
Con Sessions, los desarrolladores de agentes definen sus agentes como kubernetes o recursos de composición de docker, y se instantan de una manera en la que sería imposible mezclar accidentalmente los datos de los usuarios, y además, el servidor de coral puede opcionalmente desplegar y operar agentes en plataformas como Phala donde se realizan afirmaciones verificadas sobre lo que persiste y dónde se puede enviar la información.
Se siente poco intuitivo desde la perspectiva de diseño de soluciones, pero se adapta tan bien desde la perspectiva de alguien que quiere añadir agencia a sus aplicaciones. También limita a los agentes que ya están en una implementación de proceso fijo, tal vez desde una solución sin código, pero me parece increíblemente valiosa.
Ishan Pandey:Coral introduce conceptos como los anuncios de agentes, la memoria escalonada y los pagos basados en sesión. ¿Puede guiarnos por cómo funcionaría un caso de uso real, por ejemplo, en operaciones de comercio descentralizado o empresarial, utilizando el protocolo de Coral?
Roman Georgio:Coral pretende ser la forma más práctica de agregar agencia al software.Todas las características; como los anuncios de agentes, la memoria de alcance y los pagos basados en sesión; están diseñados con ese objetivo en mente.Por ejemplo, los desarrolladores de agentes ganan incentivos cuando se utilizan sus agentes, y los desarrolladores de aplicaciones pueden mezclar y combinar agentes de la creciente biblioteca de Coral para montar sistemas avanzados más rápidamente, sin bloquear a los proveedores.
Esto significa que si usted era un desarrollador de aplicaciones construyendo un sistema de comercio descentralizado y multiagente, simplemente elegiría a los agentes que investiguen tendencias, rastrearan a los líderes de opinión clave (KOLs), monitorizarían el intercambio de ideas, etc., y los combinarían según sea necesario.
Ishan Pandey:Finalmente, ¿qué consejo tienen ambos para los fundadores técnicos que construyen en la intersección de AI y Web3? ¿Qué mentalidad o marcos te ayudaron a ejecutar Coral de idea a protocolo?
Caelum Forder & Roman Georgio:Diría para los fundadores de Web3: menos marketing, más desarrollo. Y para los fundadores de Web2: más marketing, menos desarrollo. Pero ambos necesitan centrarse más en los clientes; lo que, sé, suena como un poco de un cliché.Estamos bastante temprano en este viaje, por lo que no puedo decir mucho sobre los clientes todavía. pero puedo hablar de la mentalidad que tenemos en comparación con otros fundadores que veo de estos espacios. Esto solo viene de estar en el mundo de la IA, veo a muchos investigadores altamente técnicos, brillantes o el talento de la IA para construir cosas realmente cool, pero no pongo mucho pensamiento en cómo comercializarlo, o incluso quién lo comercializa.
Incluso si lo construyes, puede que no vengan. Por el lado contrario, en Web3, a menudo ves un montón de proyectos de marketing pesados con poco desarrollo real. Incluso cuando son buenos en marketing, a menudo no es sostenible; porque están gastando todos sus esfuerzos dirigidos a personas que no realmente usarán el producto. tenemos una regla general para esto internamente, si son un proyecto técnico y no puedes encontrar su GitHub dentro de los primeros 5 segundos en su página principal, es más probable que sean un proyecto de marketing. Ambos tipos de fundadores a menudo fallan por la misma razón: nadie usa su producto. Algo que hemos tenido la mentalidad cada paso del camino es lo que esta experiencia final parece para el usuario, queremos construir algo que sea realmente usado y útil, así como fresco.
¡No te olvides de gustar y compartir la historia!
