OpenAI Agents API

Artículo original ↗ Discusión en Hacker News ↗

La nueva API de Agents de OpenAI, que ofrece runtimes y sandboxes administrados para “agentes” sobre sus modelos, se ve como una forma potente de externalizar el escalado, el parcheo de seguridad y la gestión del entorno, pero también como un fuerte impulso hacia la dependencia del proveedor. Los comentaristas sopesan la comodidad de un harness alojado frente a preocupaciones sobre la seguridad de los datos, los opacos “reasoning tokens”, la confusión en los precios y la pérdida de control en comparación con ejecutar sus propios frameworks de agentes locales o de código abierto. Muchos señalan que los runtimes neutrales al proveedor y los sandboxes autohospedados emergentes son preferibles para la flexibilidad a largo plazo, aunque hoy requieran más esfuerzo de ingeniería.

API vs SDK, y sesiones administradas

  • Algunos ven la API de Agents como redundante con el SDK y la CLI existentes, y prefieren el desarrollo local basado en SDK donde controlan el harness.
  • Otros argumentan que la API reduce la carga operativa: OpenAI gestiona el escalado, el parcheo de seguridad y la orquestación de sesiones. Un patrón sugerido es “desarrollar vía SDK, desplegar vía API”.

Dependencia del proveedor, confianza y control de datos

  • Hay una fuerte preocupación de que esto profundice la dependencia del proveedor y empuje a la gente a abandonar la propiedad de su harness y su estado.
  • Varios comentaristas dicen que prefieren harnesses ligeros y sustituibles sobre APIs base de LLM para evitar depender de un solo laboratorio.
  • Se plantea el riesgo de fuga de datos: llamadas automáticas a herramientas o agentes en red podrían enviar datos sensibles a servicios externos sin control explícito del usuario.

Entornos sandbox y seguridad

  • Los controles de red (enabled/disabled/restricted) reciben escrutinio dada la información previa sobre agentes modificando /etc/hosts para eludir restricciones.
  • Algunos dudan de la capacidad de OpenAI para asegurar completamente estos sandboxes; otros señalan que al menos se bloquean algunos intentos básicos de evasión.
  • La opción de un entorno autohospedado se ve positivamente, especialmente para redes privadas y un control más estricto.

Precios, límites y suscripciones

  • Hay confusión sobre la facturación del entorno (unidades de 20 minutos, mínimo de ~5 minutos por activación). A algunos no les queda claro si cada sesión crea un entorno nuevo facturable o cómo apagarlo antes de tiempo.
  • Las suscripciones de consumidor (Codex, ACP, etc.) por lo general no pueden usarse con esta API; esto se ve como un favoritismo hacia clientes más grandes.
  • Múltiples reportes indican que el uso de Codex en algunas cuentas ahora consume la cuota de forma desproporcionada, aunque las causas se debaten y no están claras.

Casos de uso y escalado

  • Hay reacciones positivas de personas que ejecutan muchas sesiones concurrentes de agentes (p. ej., agentes de código o crawlers) y que actualmente están limitadas por la capacidad de sus propios VPS.
  • Otros creen que alojar agentes ellos mismos (VMs, Docker, harnesses locales) es lo bastante fácil como para que los agentes administrados aporten poco valor.

Abstracciones, harnesses y alternativas

  • Hay un amplio consenso en que el diseño del “agent harness” es complejo y está evolucionando; todavía no existe una abstracción consensuada.
  • Algunos dicen que construir un buen harness es un pozo profundo; otros informan éxito con harnesses personalizados mínimos o frameworks de código abierto, y argumentan que todo desarrollador serio debería poseer su harness.
  • Se mencionan varias plataformas de agentes neutrales al proveedor o de código abierto y competidores de “agents-as-a-service” como preferibles por la flexibilidad de modelos y la propiedad del estado a largo plazo.

Control local vs remoto

  • Algunos consideran que los harnesses remotos alojados por el laboratorio son un paso atrás: su principal problema es conceder a agentes remotos acceso a datos locales. Preferirían agentes locales con sandboxes remotos opcionales.
  • Otros enfatizan la comodidad: poder activar y monitorizar agentes desde Slack, la web o el teléfono, y no preocuparse por la disponibilidad ni por la orquestación.