¿Cómo se construye un dispositivo de captura de energía para empresas?
Hemos desarrollado agentes internos en LangChain en áreas como marketing, ventas y ingeniería, y han cambiado completamente la forma en que funcionan esos equipos. No fue fácil hacerlos funcionar correctamente. Hemos invertido mucho tiempo en resolver los problemas que surgen con un sistema multijugador, y todos los equipos llegaron a los mismos principios básicos:
- Vive donde la gente ya trabaja (para nosotros, eso es Slack)
- Él sabe quién está pidiendo y actúa como esa persona para algunos servicios, mientras mantiene su propia identidad para otras personas
- Cuenta con memoria, delimitada globalmente y/o a nivel de usuario
- El código se ejecuta en un entorno de contenedor y puede realizar solicitudes a servicios que requieren autenticación
- Un gran porcento de sus ejecuciones está programado, en lugar de ser invocado explícitamente por alguien (agentes ambientales!!)
Gracias a @caspar_br por la ayuda en este blog
Agentes Internos de LangChain
Para fundamentar esta discusión, una breve descripción de los tres agentes principales que tenemos en LangChain:
Agente GTM: un agente proactivo y siempre activo que ayuda en las actividades de GTM. Monitorea y responde a correos electrónicos, a nuevos leads calificados, envía informes diarios, puede responder preguntas sobre cuentas y puede ejecutar acciones de salida.
OpenSWE: nuestro agente de ingeniería, puede trabajar en y redactar PRs, pero también ejecuta revisiones de código para todos los PRs
Content Studio: nuestro agente de marketing, puede redactar activos (blogs, imágenes, PowerPoint, videos) al estilo nuestro y con conocimiento de nuestra posición
Todos estos agentes se construyen de la misma manera. Creemos que esta es una receta general para fabricar arneses empresariales.
Problema: Experiencia de usuario
Todos nuestros agentes trabajan en lugares donde ya hay personas, que para nosotros es Slack. Cada uno tiene sus propias aplicaciones de Slack, y pueden ser contactados por mensaje privado o etiquetados en un canal. Una ventaja de trabajar con estos agentes en canales es que otros pueden ver cómo las personas los utilizan.
Una cosa buena que añadimos es el concepto de “dividir” una conversación en Slack. A menudo, tiene lugar una gran conversación y querrías incluir a tu agente para obtener su opinión o hacer que realice algo. Pero si se involucran en ese hilo, eso contaminaría la conversación humana y distraería. Por lo tanto, añadimos una forma sencilla para que los agentes puedan “dividirse” en su propio hilo dentro del canal.
Hay algunas experiencias de usuario que es mejor NO llevar a cabo en Slack. Por ejemplo, cuando se revisan los correos que el agente GTM me pide enviar, está bien hacerlo de forma única en Slack, pero si hay un gran volumen de trabajo acumulado, no es una experiencia agradable rastrear esos mensajes desde Slack. Para experiencias de ese tipo, terminamos construyendo una interfaz personalizada.
Problema: Identidad
El problema más complicado y difícil que hemos enfrentado fue la identidad, específicamente: cuando estos agentes toman acciones, en nombre de quién las realizan?
Existen dos formas principales en las que esto se maneja en la industria:
- En nombre de: el agente actúa en nombre del usuario que invoca al agente
- Credenciales fijas: existe un conjunto fijo de credenciales que el agente utiliza sin importar quién lo invoca (por ejemplo, un cuenta de servicio).
Así es como lo manejamos para cada agente (documentación: Añadir identidad a los Agentes Profundos Gestionados, Gestionar conexiones):
OpenSWE:
- Cuando lo envías por mensaje, actúa en nombre tuyo (por ejemplo, abrirá los PR con tu identificador de GitHub).
- Cuando se ejecuta en segundo plano (por ejemplo, como un agente de revisión de código), actúa con su propia identidad (aplicación GitHub).
Agente GTM:
- Tiene algunas herramientas (por ejemplo, acceso a Salesforce) donde utiliza una identidad fija, por lo que no todos tienen que iniciar sesión
- Tiene algunas herramientas (por ejemplo, correo electrónico) en las que actúa en nombre del usuario que invoca el agente. Estas herramientas están DISPONIBLES SOLO en mensajes privados. En canales compartidos, no están disponibles.
Content Studio:
- Tiene algunas herramientas (por ejemplo, Notion) en las que actúa en nombre del usuario que invoca el agente
- Tiene algunas herramientas (como Twitter) en las que utiliza un conjunto fijo de credenciales, en este caso para la cuenta de Twitter de nuestra empresa. Sin embargo, solo un conjunto de usuarios listados puede realizar ciertas operaciones aquí. Por ejemplo, no todos pueden publicar en Twitter (solo pueden leer o redactar).
Problema: Memoria
Todos los agentes tienen dos niveles de memoria:
- Memoria global: memoria que se aplica a todos los usuarios
- Memoria del usuario: memoria que solo aplica al usuario específico
Los agentes deciden a qué nivel de memoria quieren recordar los hechos.
¡Esto es probablemente el área menos explorada hasta ahora! Tenemos mucho trabajo que hacer aquí.
Problema: Ejecución de código
Los tres agentes de nosotros pueden escribir y ejecutar código, y a menudo necesitan hacerlo para completar las tareas. Todos siguen el patrón de ejecutarse fuera del sandbox, pero conectarse a él y ejecutar código allí. Todos tienen imágenes base ligeramente diferentes con dependencias distintas. OpenSWE (el agente más relacionado con la programación) es inteligente al elegir qué imagen base se inicia (diferencia según el canal o usuario). Todos aprovechan el proxy secreto en LangSmith Sandboxes (ver también Añadir un sandbox a Managed Deep Agents) para permitir que el agente se conecte a los servicios de una manera segura desde dentro del propio sandbox.
Problema: Ejecuciones programadas
Un porcentaje grande de ejecuciones se programan o se activan en segundo plano debido a eventos, en lugar de ser iniciadas directamente por un usuario.
Algunos de estos se configuran por el desarrollador del agente. Por ejemplo: OpenSWE escucha las cambios de prueba y, cuando se crea una nueva, la revisa.
Otros de estos son configurados por el usuario, quien pide al agente que lo haga. Por ejemplo: pedí al agente GTM que me envíe un resumen diario, y él creó su propio cron para hacerlo.
Todo está construido sobre Agentes Profundos Gestionados
Todos estos agentes se basan en Managed Deep Agents, que se encuentra sobre la infraestructura de Deep Agents de código abierto. Proporciona la infraestructura necesaria para resolver todos estos problemas (canales, crons, sandboxes, memoria, identidad), al mismo tiempo que ofrece suficiente flexibilidad para personalizar el comportamiento del agente según sea necesario. Prueba esto hoy con el quickstart.