Open SWE es un marco de código abierto para construir el agente de codificación asincrónico interno de una organización. Un desarrollador puede mencionar un bot en Slack, Linear o GitHub; el servicio reúne el contexto del problema/hilo, crea un entorno limitado de nube persistente, clona un repositorio, planifica y edita código, ejecuta comandos, se compromete con una rama y abre o actualiza un borrador de solicitud de extracción.
No es un servicio de codificación alojado que se vuelve seguro después de la instalación. Open SWE es una arquitectura de referencia construida sobre LangGraph y Deep Agents. El operador debe seleccionar modelos y proveedores de sandbox, crear aplicaciones GitHub/Slack/Linear, asegurar la implementación, alcance de repositorios y tokens, agregar validación determinista, controlar el acceso a la red y ser dueño de cada solicitud de extracción resultante.
La arquitectura de extremo a extremo
| capa | Rol publicado | Decisión que pertenece al operador |
|---|---|---|
| Invocación | Slack mención, Linear comentario o comentario de relaciones públicas de GitHub | ¿Quién puede activar qué repositorios y a qué costo? |
| Contexto | AGENTS.md más el historial completo de problemas o hilos | Qué contenido es confiable, está redactado o es propenso a ser inyectado rápidamente |
| Arnés | Deep Agents compuesto dentro de LangGraph | Modelo, aviso del sistema, herramientas, middleware y límites de llamadas |
| Caja de arena | Entorno Linux remoto persistente por tarea | Proveedor, imagen, salida, vida útil, recursos y ubicación de datos. |
| Herramientas | Shell, archivos, HTTP, Slack, Linear, GitHub y observabilidad opcional | Mínimos privilegios, aprobaciones de efectos secundarios y límites secretos |
| Orquestación | Subagentes y ganchos de middleware deterministas | Concurrencia, presupuesto, estado compartido y manejo de errores. |
| Entrega | Confirmar, impulsar, redactar relaciones públicas y respuestas del canal de origen | CI, revisores, política de fusión y separación de implementación |
El sandboxing reduce el riesgo del host, no la autoridad externa
El repositorio dice que cada tarea recibe un entorno limitado en la nube aislado con permisos de shell completos y sin mensajes de confirmación, y admite entornos limitados Modal, Daytona, Runloop, E2B y LangSmith. Una zona de pruebas separada limita los conflictos entre sistemas de archivos y procesos, pero la frase README de que el radio de explosión está "completamente contenido" no debe tratarse literalmente.
El agente puede tener salida de red, autoridad de repositorio, acceso a registro de paquetes y APIs externos. Puede filtrar fuentes, quemar créditos de modelos, abrir solicitudes de extracción dañinas, abusar de un token o atacar servicios internos accesibles desde la zona de pruebas. Un compromiso del plano de control del proveedor de espacio aislado también puede traspasar los límites de las tareas. La contención requiere una política de salida, credenciales de corta duración, cuotas, aislamiento de proveedores y una puerta de fusión/implementación independiente.
| Riesgo | La zona de pruebas ayuda | Control complementario requerido |
|---|---|---|
| Comando destructivo de shell | Limita el daño del proceso/disco local al entorno desechable | Sin montajes de producción; Límites de recursos/tiempo y desmontaje limpio. |
| Dependencia maliciosa | Separa la tarea de la computadora portátil del desarrollador | Archivos de bloqueo, lista de registros permitidos, escaneo y salida restringida |
| Uso indebido del token de GitHub | Poco si el token permite acciones externas | Token de aplicación de alcance/proxy limitado a operaciones de repositorio y sucursales |
| Inyección inmediata | Puede limitar el compromiso del host | Etiquetas de confianza, política de herramientas y denegación de sistemas sensibles |
| Código incorrecto | Permite realizar pruebas en un tiempo de ejecución aislado | CI determinista, revisión de seguridad y ramas protegidas |
| Fuga de datos | Separa los datos de la estación de trabajo local | Revisión de proveedores/datos, redacción y controles de destino salientes |
El problema y el texto del chat son instrucciones que no son de confianza
Open SWE inyecta el problema Linear completo o el hilo Slack en el contexto del agente. Eso mejora la comprensión de la tarea, pero crea una ruta directa de inyección de mensajes: un reportero externo o un registro copiado puede indicarle al agente que revele secretos, busque una URL maliciosa o cambie código no relacionado. AGENTS.md tiene más autoridad, pero también es contenido del repositorio que una rama comprometida puede modificar.
Marque el contenido por procedencia y nivel de confianza. La política del sistema, las reglas de organización y la configuración del repositorio aprobada deben tener prioridad sobre las descripciones de tickets, comentarios, registros, páginas web y cadenas de códigos. No permita que un colaborador que no es de confianza active una ejecución con herramientas de observabilidad o de datos internos. El proyecto actual limita explícitamente las herramientas Datadog/LangSmith opcionales a usuarios autorizados; preservar y poner a prueba ese límite.
Curación de herramientas y credenciales
El conjunto de herramientas predeterminado incluye ejecución de shell, operaciones de archivos, recuperación de URL, solicitudes HTTP arbitrarias, Linear búsquedas/comentarios y Slack reacciones/respuestas. Las operaciones de GitHub se pueden enviar mediante proxy para que la zona de pruebas vea un token ficticio mientras el servidor realiza solicitudes autorizadas. Las herramientas opcionales Datadog, LangSmith y Corridor se ejecutan en el lado del servidor, manteniendo esas credenciales fuera del entorno limitado.
| Grupo de herramientas | Permiso mínimo | Mal uso de alto riesgo |
|---|---|---|
| GitHub | Leer código; empujar una rama de tarea; abrir/actualizar borrador PR | Cambiar protecciones, secretos, liberaciones u otras ramas |
| Slack/Linear | Lea el hilo/problema desencadenante y responda allí | Búsqueda de discusiones confidenciales o mensajes masivos |
| HTTP/buscar | Documentación pública incluida en la lista permitida siempre que sea posible | SSRF, acceso a metadatos, exfiltración e instrucciones de páginas hostiles |
| Observabilidad | Servicios de alcance de solo lectura y usuarios autorizados | Filtrar datos de clientes o secretos incrustados en registros/rastreos |
| Concha | Control total solo dentro de una zona de pruebas con recursos limitados | Bombas de horquilla, criptominería, escaneo de red o persistencia |
| Subagentes | Autoridad igual o más limitada que la de los padres | Multiplicar costos, conflictos y llamadas de herramientas |
La validación es la mayor brecha predeterminada
El README describe la validación como basada en avisos: se le indica al agente que ejecute linters, formateadores y pruebas antes de confirmar. Las instrucciones no son cumplimiento. Un agente puede omitir pruebas costosas, leer mal los resultados, debilitar una prueba, burlarse de un comportamiento o afirmar que ha tenido éxito después de un tiempo de espera. El proyecto en sí recomienda agregar CI determinista, verificación visual o puertas de revisión.
Mueva la aceptación fuera del bucle del modelo. El servicio no debe marcar una tarea como exitosa hasta que los comandos requeridos se ejecuten en un entorno nuevo y devuelvan los resultados esperados legibles por máquina. El agente no debe editar el flujo de trabajo que determina su propio estado de aprobación a menos que ese cambio en el flujo de trabajo se revise por separado.
| Puerta | evidencia independiente | Política de fracaso |
|---|---|---|
| Alcance | Rutas modificadas en comparación con la lista de problemas permitidos | Bloquear actualización de relaciones públicas o solicitar excepción humana |
| Compilación/comprobación de tipo | Comando de pago nuevo y código de salida | Adjuntar registros y marcar como incompleto |
| Pruebas | Suites requeridas más revisión de prueba modificada | Sin bucle de reintento que edite silenciosamente las expectativas |
| Seguridad | Escáneres de dependencia, secretos y análisis estático | Hallazgo de cuarentena; nunca descartar automáticamente |
| visuales | Comparación de capturas de pantalla en rutas/ventanas gráficas definidas | Aprobación humana para diferencias significativas |
| Revisabilidad | Campos de tamaño de diferencia, resumen, riesgo y reversión | Dividir cambios de gran tamaño o de preocupaciones mixtas |
Los hilos persistentes necesitan reglas de ciclo de vida
Los mensajes Slack/Linear de seguimiento se enrutan al mismo hilo determinista y zona de pruebas persistente. Esto preserva el contexto, pero también puede preservar el estado comprometido, las ramas obsoletas, los secretos descargados y los procesos fuera de control. Defina la vida útil máxima, el tiempo de inactividad, la cuota de disco y una ruta de "recreación a partir de una plantilla limpia". Un ticket reabierto semanas después no debería reanudar silenciosamente un antiguo entorno sin parches.
El middleware inyecta mensajes en cola antes de la siguiente llamada del modelo. Registre qué mensaje cambió la tarea, quién la envió y si se amplió el alcance. Si un seguimiento solicita un nuevo repositorio, sistema externo o acción de producción, cree una nueva decisión de autorización en lugar de tratarla como un contexto conversacional ordinario.
Subagentes: paralelismo útil con coste no lineal
Deep Agents puede generar agentes secundarios con su propio middleware, listas de tareas pendientes y operaciones de archivos. Úselos sólo para trabajos independientes de lectura intensa, como localizar pruebas, comparar APIs o revisar una diferencia limitada. Varios escritores en una rama pueden sobrescribir suposiciones y crear un cambio mayor y menos coherente.
- Establezca un recuento máximo de niños, un límite de llamadas de modelos, un presupuesto de tokens y una fecha límite.
- Asigne archivos que no se superpongan o solicite que uno de los padres serialice las ediciones.
- Mantenga los permisos de los niños no más amplios que los de los padres.
- Hacer que cada niño devuelva evidencia e incertidumbre, no sólo conclusiones en prosa.
- Cargue toda la actividad secundaria a la tarea de origen para medir los costos.
Opciones de implementación y dependencia
Open SWE requiere más que instalar un paquete Python: backend, panel de control, servicios LangGraph/LangSmith, GitHub App/OAuth, integraciones de invocación, proveedor de espacio aislado, credenciales de modelo y alojamiento de producción. El código tiene licencia del MIT, pero los entornos limitados de pruebas en la nube, los modelos, la observabilidad y las plataformas de mensajería tienen términos de precios y datos separados.
Fije la confirmación Open SWE y todos los bloqueos de dependencia. Almacene secretos de aplicaciones en un sistema secreto administrado, rote secretos de webhooks, valide firmas y rechace eventos repetidos. Instalaciones separadas de desarrollo y producción. Un webhook público más un potente GitHub App es un objetivo atractivo.
selección de tareas
| Tarea | Idoneidad | Razón |
|---|---|---|
| Migración mecánica API | Buen piloto | Patrones claros, archivos acotados y pruebas deterministas. |
| Agregar pruebas unitarias faltantes | Bueno con reseña | Investigación útil, pero las pruebas pueden codificar comportamientos incorrectos |
| Actualización de dependencia | Condicional | Necesita revisión de registro de cambios, seguridad y compatibilidad. |
| Característica de producto ambigua | Mal ajuste inicial | Los requisitos y el juicio de UX dominan la codificación |
| Rediseño de autenticación | Alto riesgo | La arquitectura de seguridad requiere experiencia responsable |
| Incidente de producción | Mal ajuste autónomo | La presión del tiempo y la autoridad real magnifican los errores |
Medir el trabajo de ingeniería aceptado.
Realice un seguimiento de la tasa de aceptación de tareas, los minutos de los revisores, la aprobación de CI en la primera ejecución independiente, los defectos reabiertos, los hallazgos de seguridad, los minutos de la zona de pruebas, los tokens de modelo y el costo total por PR fusionado. Compare con una línea de base humana con una complejidad de tarea similar. El recuento de relaciones públicas y las líneas cambiadas son volumen de producción, no productividad.
Mantener un grupo de control sin agente y un grupo de agente síncrono. Los agentes asincrónicos pueden reducir las interrupciones al tiempo que aumentan los lotes de revisión. La pregunta útil es si el tiempo de entrega y la calidad aceptada mejoran sin transferir una carga de trabajo oculta a los revisores y a los ingenieros de la plataforma.
Alternativas
| Opción | Mejor ajuste | Compensación versus Open SWE |
|---|---|---|
| Open SWE | Equipos que crean una plataforma interna de agente asíncrono personalizable | Importante integración, seguridad y propiedad operativa |
| Codex / Claude Código | Trabajo terminal síncrono supervisado por el desarrollador | Menos orquestación del flujo de trabajo en segundo plano |
| GitHub Copilot agente codificador | Flujo de emisión a relaciones públicas gestionado de forma nativa en GitHub | Menos personalización a nivel de marco y modelo de alojamiento diferente |
| devin | Espacio de trabajo de codificación autónomo gestionado | Plataforma comercial alojada y menos control interno. |
| OpenHands | Investigación y tiempo de ejecución del agente de codificación de código abierto | Diferentes enfoques de integración y orquestación. |
| Scripts/bots de CI | Migraciones deterministas, formateo y actualizaciones. | Razonamiento menos flexible, a menudo más seguro y económico para tareas conocidas. |
Preguntas frecuentes
¿Es Open SWE un servicio alojado?
Es un marco de código abierto. Los operadores lo implementan y configuran y compran o ejecutan el modelo, la zona de pruebas y los servicios de integración necesarios.
¿Qué entornos sandbox son compatibles?
El repositorio actual enumera Modal, Daytona, Runloop, E2B y LangSmith, además de una ruta de personalización.
¿Es compatible con Slack, Linear y GitHub?
Sí. Estas son las principales superficies de invocación y seguimiento documentadas.
¿Un sandbox hace que los permisos completos sean seguros?
No. Aísla la ejecución local, pero la red, el repositorio y la autoridad de la cuenta externa necesitan controles separados.
¿Verifica automáticamente el código?
El valor predeterminado depende en gran medida de las instrucciones del agente para ejecutar comprobaciones. Los equipos deben agregar CI externa determinista y puertas de revisión.
¿Es de código abierto?
Sí. El repositorio actual tiene licencia del MIT.
fuentes primarias
- Repositorio oficial y arquitectura.
- Aplicación oficial Open SWE
- Guía de instalación oficial
- Guía de personalización oficial.
- Política de seguridad oficial
- LangGraph descripción general
- GitHub App mejores prácticas de seguridad
- Guía de inyección rápida de OWASP
Última revisión el 25 de julio de 2026. Open SWE evoluciona rápidamente; Fije la revisión implementada y revalide las integraciones, el comportamiento de la zona de pruebas, las herramientas y los controles de seguridad después de las actualizaciones.
