The Agent SDK

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

Los “agent SDKs” que proliferan rápidamente, como el de Cursor, están siendo comparados con la rotación de frameworks de JavaScript, y muchos ingenieros dudan de que flujos de trabajo de agentes cada vez más elaborados superen prompts bien diseñados y herramientas más simples. Los comentaristas sopesan las compensaciones entre harnesses propietarios como Claude Code, Cursor y las ofertas de OpenAI —a menudo muy ajustadas a sus propios modelos y subvencionadas mediante suscripciones— y harnesses de código abierto o personalizados que prometen flexibilidad pero pueden carecer de integración profunda y de una economía estable. Debajo del branding y las siglas, las tensiones centrales son la dependencia del proveedor, la ausencia de benchmarks o estándares claros, y si las arquitecturas complejas multiagente aportan ganancias reales de productividad o solo teatro de productividad.

Ecosistema, estándares y dependencia del proveedor

  • Varios comentarios quieren un estándar común (p. ej., OpenResponses) para que las apps no queden atadas a proveedores específicos (OpenAI, Anthropic, Cursor, etc.).
  • Otros señalan que estamos en una fase “pre-estándares”: hay muchos intentos paralelos porque nadie sabe todavía cuál es el “diseño correcto”.

SDKs de agentes, harnesses y niveles de abstracción

  • Algunos argumentan que un “agent SDK” podría ser tan simple como PROMPT.md + runtime + tools; los frameworks complejos como LangChain parecen sobrediseñados.
  • Contraargumento: los runtimes aportan el control necesario: distintas herramientas, modelos, permisos, guardrails, cuotas y auditabilidad entre flujos de trabajo, especialmente para empresas.
  • Varias personas describen el uso de Temporal, gRPC, k8s o el ADK de Google como bases de orquestación en lugar de frameworks de agentes pesados.

Escepticismo: teatro de productividad y rotación

  • Muchos ven los infinitos flujos de trabajo con “agentes” como hype, con poca evidencia empírica de que superen buenos prompts individuales.
  • Se hacen comparaciones con la rotación de frameworks de JS, la manía de los diagramas OOP/UML y el ajuste interminable de entornos de desarrollo (p. ej., configuraciones de neovim).
  • Algunos critican las “software factories” multiagente que generan enormes PRs sin revisar, advirtiendo que esto degrada los estándares de ingeniería y aumenta el riesgo.

Harnesses de código abierto vs propietarios

  • Un grupo considerable sigue con harnesses propietarios (especialmente Claude Code y Cursor) debido a:
    • Integración profunda con modelos de frontera y precios de suscripción subvencionados.
    • La creencia de que los modelos rinden mejor en su harness “nativo”.
    • UX familiar, baja presión para cambiar y una percepción de falta de funciones destacadas en los harnesses OSS.
  • Otros abogan por harnesses abiertos (Pi, OpenCode, personalizados), enfatizando:
    • Portabilidad entre modelos/proveedores.
    • Capacidad de enrutar entre suscripciones y APIs.
    • Que no hay una dependencia real, ya que los harnesses pueden llamar a las CLI de los demás.
  • Hay confusión y desacuerdo sobre los términos de Anthropic, la facturación y si los harnesses de terceros consumen suscripciones de Claude o créditos API separados; la documentación y el comportamiento se describen como ambiguos, aunque recientemente actualizados.

Cursor, “Agent SDK” y alternativas

  • Algunos sienten que la UX de Cursor decayó al perseguir flujos de trabajo agénticos, prefiriendo su modelo anterior, más simple, de “tabs + cmd‑K”.
  • A otros les gusta la historia agéntica de cloud/deploy de Cursor y ven los “agentes” como cargas de trabajo para alojar y monetizar.
  • Las comparaciones mencionan herramientas competidoras (Anthropic Agent SDK, OpenAI Agents, Vercel AI/Eve, Devin), pero el hilo no encuentra nada claramente único en la propuesta del Agent SDK de Cursor.

UI/UX y necesidades reales del negocio

  • Un profesional dice que lo más difícil son las UIs de chat específicas del dominio y los flujos de aprobación; las interfaces de chat genéricas y MCP/tooling no resuelven esto, obligando a muchos a reconstruir el frontend por su cuenta.
  • Se mencionan varias bibliotecas/frameworks (TanStack AI, ChatGPT Apps, TUI personalizadas) como intentos de abordar flujos de UI más ricos sobre agentes.