Crea agentes autónomos con el SDK de Claude Code: guía práctica para desarrolladores

Construye agentes autónomos con el Claude Code SDK: una guía práctica para desarrolladores

El Claude Code SDK — llamado oficialmente Agent SDK — es una librería en Python y TypeScript que te permite controlar el motor agéntico completo de Claude Code de forma programática: sin terminal, sin una persona delante del teclado, solo tu aplicación llamando a una función asíncrona query() y recibiendo en streaming cada paso del trabajo del agente. Si has usado Claude Code de forma interactiva, el SDK te ofrece ese mismo bucle de leer archivos / editar código / ejecutar comandos como una librería componible que puedes integrar en pipelines de CI, bots de revisión de código, orquestadores multiagente o cualquier servicio backend.

Qué es el Agent SDK — y por qué existe

Claude Code es conocido sobre todo como una herramienta de terminal. Escribes un prompt, el agente razona sobre tu base de código, invoca herramientas integradas (Read, Edit, Bash, Grep, entre otras) y te devuelve los resultados. Pero en el momento en que quieres automatizar ese bucle — lanzar una revisión en cada pull request, repartir el trabajo entre varios subagentes especializados o construir un producto encima de él — la CLI interactiva deja de ser la abstracción adecuada. Necesitas una librería.

El Agent SDK cubre ese hueco. Según la documentación oficial de Anthropic, expone "las mismas herramientas, el mismo bucle de agente y la misma gestión de contexto que impulsan Claude Code, programables en Python y TypeScript". No es lenguaje de marketing: es la arquitectura literal. El SDK lanza el binario de la CLI de Claude Code como un subproceso gestionado, se comunica con él a través de stdio y expone todo como un stream asíncrono de objetos de mensaje tipados que tu código puede consumir y ante los que puede reaccionar.

Esta distinción importa por varias razones:

Mismo motor, interfaz distinta. Cuando pasas de la CLI al SDK, no estás migrando a una herramienta más limitada o simplificada. El SDK hereda todas las capacidades de la CLI — conectividad con servidores MCP, ciclo de vida de hooks, archivos de skills, memoria de CLAUDE.md, delegación en subagentes y el catálogo completo de herramientas.

El SDK ejecuta las herramientas por ti. Si usas el Anthropic Client SDK (el paquete de nivel más bajo anthropic para Python/JS) y quieres que Claude llame a herramientas, tienes que implementar tú mismo el bucle de herramientas: llamar a la API, detectar una respuesta de uso de herramienta, ejecutar la herramienta, devolver el resultado y repetir hasta que Claude se detenga. El Agent SDK reduce todo ese bucle a un único async for message in query(...) — Claude decide qué herramientas llamar, las ejecuta dentro de su subproceso y continúa el bucle hasta terminar la tarea. Tú solo consumes el stream.

Diseñado para funcionar sin supervisión. Los avisos de permisos de la CLI — "¿permitir este comando de bash?" — se quedan bloqueados esperando la entrada de una persona. El SDK los sustituye por una opción permissionMode y un conjunto de modos de permiso — por ejemplo acceptEdits para aprobar automáticamente las ediciones de archivos y bypassPermissions para ejecutar todo sin preguntar en un entorno de CI en sandbox — además de un callback de aprobación programático para flujos personalizados. Los nombres exactos de los modos y su comportamiento están documentados en la referencia del SDK de Anthropic (consúltala para conocer la lista actual), pero el efecto es el mismo: tu automatización nunca se queda esperando una pulsación de tecla.

El mismo motor de Claude Code, dos interfaces: la CLI interactiva para trabajo con una persona en el bucle, el Agent SDK para automatización programática y sin supervisión, en la que tu aplicación controla el prompt y un modo de permiso sustituye al diálogo de aprobación.

Instalación del SDK

Anthropic publica dos paquetes:

• TypeScript: @anthropic-ai/claude-agent-sdk (npm)
• Python: claude-agent-sdk (pip; requiere Python 3.10+)

El paquete de TypeScript incluye un binario nativo de Claude Code para tu plataforma, así que no hace falta instalar la CLI por separado. La autenticación se realiza mediante una variable de entorno ANTHROPIC_API_KEY obtenida desde la Anthropic Console. El SDK también admite Amazon Bedrock, Google Vertex AI y Microsoft Azure AI Foundry — consulta la documentación de Anthropic para conocer los patrones de variables de entorno correspondientes.

Conceptos fundamentales

Entender cuatro conceptos cubre la gran mayoría de los usos reales del SDK.

1. La función query() y el stream asíncrono de mensajes

Toda interacción con el SDK empieza con query(). Pasas una cadena prompt y un objeto options; a cambio recibes un iterador asíncrono que va emitiendo objetos de mensaje tipados a medida que el agente trabaja. El bucle termina cuando el agente finaliza o encuentra un error.

Los mensajes que recibes incluyen:

• AssistantMessage — el texto de razonamiento de Claude y las descripciones de las llamadas a herramientas
• ToolResultMessage — el resultado de cada ejecución de herramienta
• ResultMessage — el resultado final, con un campo subtype que indica éxito o fallo
• SystemMessage — eventos del ciclo de vida de la sesión (el subtipo init lleva el session_id)

En la mayoría del código en producción se filtra por ResultMessage para extraer la salida final, y opcionalmente se registran los bloques de AssistantMessage para trazar lo que ha hecho el agente.

2. Herramientas y allowedTools

El catálogo de herramientas integradas del SDK se corresponde directamente con las capacidades de Claude Code:

La opción allowedTools aprueba de antemano un subconjunto de estas, concediendo al agente permiso para llamarlas sin ninguna comprobación adicional. Un agente de auditoría de solo lectura podría incluir únicamente ["Read", "Glob", "Grep"]; una automatización completa podría incluir ["Read", "Edit", "Bash", "Glob", "Grep"].

3. Modos de permiso

Los modos de permiso controlan qué ocurre cuando el agente quiere usar una herramienta que no está preaprobada en allowedTools:

• acceptEdits — aprueba automáticamente las ediciones de archivos y las operaciones habituales del sistema de archivos; pregunta para todo lo demás. Ideal para flujos de desarrollo de confianza.
• dontAsk — deniega silenciosamente cualquier cosa que no esté en allowedTools. Ideal para agentes sin supervisión y muy restringidos.
• bypassPermissions — ejecuta cualquier herramienta sin ninguna comprobación. Úsalo solo dentro de un entorno en sandbox.

El SDK también expone un callback de aprobación programático para que puedas implementar lógica de aprobación totalmente personalizada, y los nombres de modo disponibles pueden ampliarse con el tiempo — consulta la referencia del SDK de Anthropic para conocer la lista autorizada y actual, así como el comportamiento exacto de cada uno. En CI, casi siempre usarás una configuración muy acotada y de denegación por defecto, o bypassPermissions dentro de un contenedor sandbox que controles tú.

4. Sesiones, reanudación y contexto

Cada llamada a query() crea (o reanuda) una sesión. El session_id de la sesión llega en el primer SystemMessage con subtype === "init". Puedes capturarlo y pasarlo como resume: sessionId en una llamada posterior para continuar exactamente donde se dejó la conversación — con las mismas lecturas de archivos, el mismo historial de razonamiento, la misma ventana de contexto.

Así es como se construyen agentes de varios turnos: una llamada a query() analiza un módulo, captura el session_id, y una segunda llamada a query() (con resume) hace referencia a "eso" o "el archivo que acabas de leer" sin necesidad de volver a explicarlo. Por defecto, las transcripciones de sesión se escriben en el disco local; en producción puedes conectar un adaptador SessionStore respaldado por S3, Redis o Postgres para que las sesiones sobrevivan a reinicios de contenedores.

Patrón de construcción 1: un bot de revisión de código para CI

Este es el caso canónico de "automatización sin supervisión". En cada pull request, un job de CI hace checkout de la rama, ejecuta un agente que lee los archivos modificados y publica un comentario de revisión.

El flujo:

1. Un evento de PR dispara un workflow de GitHub Actions (o un job de GitLab CI).
2. El runner hace checkout de la rama y ejecuta tu script de revisión.
3. Tu script llama a query() con un prompt de revisión, allowedTools: ["Read", "Glob", "Grep", "Bash"] y permissionMode: "dontAsk".
4. Claude lee el diff, busca patrones y razona sobre los hallazgos.
5. El ResultMessage contiene el texto de la revisión; tu script lo publica en la PR a través de la API de GitHub.

La decisión de diseño clave es usar dontAsk con una lista de herramientas de solo lectura. El agente no puede escribir archivos ni realizar llamadas de red más allá de lo que permiten las herramientas, así que tu job de CI no puede fusionar commits ni llamar a APIs externas por accidente. Un límite maxTurns (definido en las opciones) acota la profundidad del agente para que los bucles descontrolados no consuman presupuesto.

Para ver la arquitectura ilustrada de este flujo, consulta el diagrama a continuación.

Un pipeline de revisión de código totalmente automatizado. El agente del SDK se ejecuta dentro de un contenedor de CI con una lista de herramientas de solo lectura; los hallazgos vuelven en streaming como un ResultMessage y tu código los publica como un comentario de PR en GitHub. El agente nunca escribe archivos ni sale del contenedor.

Puedes ampliar este patrón con hooks — una funcionalidad del SDK que tratamos en nuestro análisis en profundidad de los hooks de Claude Code — para registrar cada llamada a herramienta en un archivo de auditoría, bloquear la lectura de rutas de archivo concretas o emitir telemetría estructurada junto con la revisión.

Patrón de construcción 2: cadenas de herramientas multiagente

La opción agents del SDK te permite definir subagentes con nombre, cada uno con su propio system prompt, lista de herramientas y permisos. Tu agente principal les delega trabajo mediante la herramienta integrada Agent. Los mensajes de los subagentes incluyen un campo parent_tool_use_id para que puedas rastrear exactamente qué delegación produjo cada parte de la salida.

Un ejemplo práctico: una cadena de agentes para auditoría de seguridad en la que un subagente code-scanner busca posibles vulnerabilidades usando Grep y Glob, un subagente dependency-checker ejecuta Bash para consultar los metadatos de tus paquetes, y un agente coordinador sintetiza ambos informes en una auditoría unificada. Cada subagente tiene el mínimo acceso a herramientas necesario para su función, lo que limita el radio de impacto si un subagente alucina un comando peligroso.

Las cadenas multiagente funcionan bien para tareas que se descomponen de forma natural: un agente por cada área, cada uno con una lista de herramientas acotada, orquestados por un coordinador que solo necesita Read y Agent. Para una visión más amplia de cómo las arquitecturas multiagente se combinan con funcionalidades de Claude Code como la memoria de CLAUDE.md y los archivos de skills, consulta nuestra guía de harness engineering.

Patrón de construcción 3: pipelines de automatización sin supervisión

Más allá de la revisión de código, el SDK destaca en cualquier automatización recurrente en la que el agente es un paso dentro de un pipeline más grande:

Auditorías nocturnas de dependencias. Un cron job llama a query() con un prompt para comprobar paquetes desactualizados, ejecutar escáneres de seguridad y generar un informe estructurado. La herramienta Bash ejecuta npm audit o pip check; Read inspecciona los archivos de bloqueo. El ResultMessage alimenta una notificación de Slack.

Traducción e i18n al fusionar una PR. Cuando se fusiona una PR, un webhook dispara un agente que lee los archivos de cadenas modificados con Glob y Read, genera versiones traducidas con Write, y abre una nueva PR mediante Bash (ejecutando gh pr create).

Detección de anomalías en logs. Se pasa la salida reciente de los logs a un prompt de query(). El agente lee archivos de contexto adicionales si los necesita, razona sobre los logs y emite un hallazgo estructurado. No se requieren escrituras de archivos; una lista de herramientas de solo lectura es suficiente.

Sincronización de documentación. Tras fusionarse las PR, un agente lee los archivos fuente actualizados y reescribe las páginas de documentación correspondientes, y luego confirma los cambios. permissionMode: "acceptEdits" gestiona las escrituras de archivos sin preguntar.

El hilo común: query() sustituye a una integración de LLM hecha a medida. No implementas un bucle de herramientas, no gestionas manualmente las ventanas de contexto ni analizas la salida del modelo para decidir qué ejecutar a continuación. El agente se encarga de la orquestación; tú aportas el prompt y consumes el resultado.

Un ejemplo ilustrativo completo: un agente que corrige errores

El quickstart oficial demuestra este patrón con claridad (el código de abajo sigue la API documentada — verifica la sintaxis exacta en la documentación de quickstart de Anthropic):

Python ilustrativo (verifica la API exacta en la documentación oficial):

# Illustrative — confirm exact import paths and option names in official docs
import asyncio
from claude_agent_sdk import query, ClaudeAgentOptions, AssistantMessage, ResultMessage

async def run_bug_fixer(file_path: str):
    async for message in query(
        prompt=f"Review {file_path} for bugs that would cause crashes. Fix any issues.",
        options=ClaudeAgentOptions(
            allowed_tools=["Read", "Edit", "Glob"],
            permission_mode="acceptEdits",
        ),
    ):
        if isinstance(message, AssistantMessage):
            for block in message.content:
                if hasattr(block, "text"):
                    print(block.text)
        elif isinstance(message, ResultMessage):
            print(f"Completed: {message.subtype}")

asyncio.run(run_bug_fixer("src/utils.py"))

TypeScript ilustrativo (verifica la API exacta en la documentación oficial):

// Illustrative — confirm exact import paths and option names in official docs
import { query } from "@anthropic-ai/claude-agent-sdk";

for await (const message of query({
  prompt: "Review src/utils.ts for crash-causing bugs and fix them.",
  options: {
    allowedTools: ["Read", "Edit", "Glob"],
    permissionMode: "acceptEdits",
  },
})) {
  if (message.type === "assistant" && message.message?.content) {
    for (const block of message.message.content) {
      if ("text" in block) console.log(block.text);
    }
  }
  if (message.type === "result") console.log("Done:", message.subtype);
}

Qué ocurre cuando esto se ejecuta: Claude lee utils.py (o .ts) usando la herramienta Read, razona sobre el código, identifica casos límite y después llama a Edit para introducir un manejo defensivo. Ves el razonamiento y las llamadas a herramientas pasar en streaming como objetos AssistantMessage; el ResultMessage final indica la finalización. Todo el bucle del agente — incluida la relectura del archivo para verificar la edición — está gestionado por el SDK.

Esto es lo que hace que el SDK sea distinto a llamar directamente a la API de modelos de Anthropic: no implementas la capa de ejecución de herramientas. Claude decide cuándo llamar a Read, la llama, recibe de vuelta el contenido del archivo y continúa razonando. El bucle es autónomo.

Permisos, sandboxing y seguridad en producción

Ejecutar agentes autónomos en producción exige pensar con cuidado qué pueden tocar. El SDK ofrece varios controles en capas.

El acotamiento de herramientas es la primera línea de defensa. Si un agente no necesita Bash, no lo incluyas en allowedTools. Un agente con solo ["Read", "Glob", "Grep"] no puede modificar archivos, ejecutar comandos de shell ni hacer llamadas de red, independientemente de lo que diga su prompt.

Los modos de permiso ofrecen una segunda barrera. dontAsk garantiza que cualquier cosa fuera de allowedTools se deniegue silenciosamente en lugar de preguntar. Esto es fundamental en entornos sin supervisión — un aviso que se queda esperando la entrada del usuario bloqueará tu pipeline.

La opción cwd acota el acceso del agente al sistema de archivos a un directorio concreto. En entornos multiinquilino, pasa un directorio de trabajo por sesión para que los agentes de distintos inquilinos no puedan leer los archivos de otros.

El aislamiento entre inquilinos requiere pasos adicionales: establecer settingSources: [] para que no se filtren ajustes del sistema de archivos entre inquilinos; establecer CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 para evitar que se cargue la memoria automática; apuntar CLAUDE_CONFIG_DIR a una ruta específica por inquilino. Todo esto está documentado en detalle en la guía de hosting de Anthropic.

El sandboxing con contenedores es la capa exterior. Para agentes en producción que necesiten acceso a Bash, ejecuta el SDK dentro de un contenedor con la salida de red restringida a los dominios que autorices explícitamente. Proveedores como Modal, E2B, Cloudflare Sandboxes, Fly Machines y Vercel Sandbox se mencionan en la documentación de Anthropic como opciones para despliegues del SDK en sandbox.

maxTurns limita el número de idas y vueltas de uso de herramientas, acotando tanto el coste como los bucles descontrolados. Ajústalo según la complejidad esperada de tu tarea — una revisión sencilla de lectura de archivos puede necesitar entre 5 y 10 turnos; una refactorización compleja de varios archivos puede necesitar entre 30 y 50.

Para los equipos que construyen hooks y flujos de permisos en producción, nuestra guía de hooks de Claude Code trata en detalle el ciclo de vida de los hooks PreToolUse y PostToolUse, incluyendo cómo escribir callbacks de hooks que bloqueen, transformen o registren las llamadas a herramientas antes de que se ejecuten.

MCP: conectar el agente con sistemas externos

El SDK admite por completo el Model Context Protocol (MCP), que te permite conectar tu agente a cualquier sistema externo que exponga un servidor MCP: bases de datos, automatización de navegador, Jira, Slack, GitHub y cientos de servidores creados por la comunidad.

Configuras los servidores MCP en la opción mcpServers — cada entrada especifica un comando a ejecutar y argumentos opcionales. El SDK inicia esos servidores como subprocesos, y el agente puede llamar a sus herramientas de la misma forma que llama a las herramientas integradas. Así es como se le da a un agente de revisión de código acceso a tu sistema de seguimiento de incidencias, o se conecta un agente de documentación a la base de conocimiento de tu empresa.

El modelo de permisos también se aplica a las llamadas a herramientas MCP — allowedTools puede incluir nombres de herramientas MCP, y permissionMode rige lo que ocurre con las herramientas no incluidas en la lista.

Errores comunes y problemas frecuentes

Las sesiones son locales al subproceso por defecto. Las transcripciones de sesión residen en el disco local del host, bajo ~/.claude/projects/. En despliegues en contenedores o con escalado horizontal, esto significa que el estado de la sesión se pierde al reiniciar o al reasignar el nodo. Usa un adaptador SessionStore para cualquier sesión que necesites reanudar entre contenedores.

El modelo de subprocesos tiene implicaciones de memoria. Cada sesión en ejecución es un subproceso independiente. Ejecutar cincuenta sesiones simultáneas significa cincuenta procesos de Claude Code. La recomendación oficial es de aproximadamente 1 GiB de RAM por agente como punto de partida, pero el uso real de memoria depende de la duración de la sesión y de la actividad de herramientas. Dimensiona tus contenedores en consecuencia y usa maxTurns para limitar la profundidad de la sesión.

Los grandes repartos entre subagentes topan con los límites de tasa. Si tu orquestador delega en veinte subagentes simultáneamente, es probable que alcances los límites de tasa de la API de Anthropic. Divide los repartos amplios en lotes y añade un pequeño retraso entre envíos.

bypassPermissions requiere un sandbox real. Este modo omite todas las comprobaciones de permisos. Está pensado para entornos totalmente controlados, como contenedores de CI donde tú controlas todo el contexto de ejecución. Usarlo en la máquina de un desarrollador — donde el agente tiene acceso a claves SSH, credenciales en la nube y rutas de sistema de archivos arbitrarias — supone un riesgo de seguridad.

El SDK de TypeScript incluye el binario de Claude Code; el de Python no lo requiere por separado. Pero ambos SDK están vinculados a una versión concreta de la CLI. Cuando actualizas el paquete del SDK, actualizas también la CLI subyacente. Revisa el changelog antes de actualizaciones menores — los cambios de comportamiento que rompen compatibilidad se anuncian allí.

El texto de los prompts y las entradas de las herramientas no se incluyen en las exportaciones OTEL por defecto. Es un comportamiento intencionado por privacidad. Si necesitas trazabilidad a nivel de prompt para depuración, debes activarla explícitamente mediante variables de entorno documentadas en la guía de observabilidad de Anthropic.

Las versiones antiguas del SDK pueden no ser compatibles con los modelos más nuevos. La documentación de Anthropic señala que los modelos recientes pueden requerir una versión reciente del SDK debido a cambios en la API del parámetro de thinking, por lo que un SDK desactualizado puede fallar con un modelo nuevo. Consulta siempre el changelog y fija una versión conocida como estable al adoptar modelos nuevos.

El SDK frente a la CLI: ¿cuál necesitas?

Para la mayoría de los desarrolladores, la respuesta es ambos — y así está pensado.

La CLI interactiva es la herramienta adecuada para el desarrollo del día a día: explorar una base de código desconocida, resolver un error complejo de forma interactiva o ejecutar una refactorización puntual. El SDK es la herramienta adecuada para cualquier cosa que necesite ejecutarse sin una persona presente: CI, tareas programadas, funcionalidades de aplicación y pipelines multiagente.

El SDK y la CLI no son productos que compiten entre sí. Los flujos de trabajo que desarrollas de forma interactiva con la CLI se trasladan directamente a la automatización con el SDK — las mismas herramientas, los mismos conceptos de permisos, la misma memoria de CLAUDE.md y el mismo sistema de skills. Un flujo de revisión que prototipas hoy con claude en tu terminal se convierte mañana en un bot de CI impulsado por el SDK.

Para los equipos que usan la versión web de Claude Code (tratada en nuestra guía de Claude Code en la web), el SDK abre la puerta a combinar sesiones web con orquestación programática — inicia una tarea de larga duración desde la web y luego conéctate a ella de forma programática desde tu backend.

Preguntas frecuentes

¿Qué es exactamente el Claude Code SDK (Agent SDK)? Es una librería en Python (claude-agent-sdk) y TypeScript (@anthropic-ai/claude-agent-sdk) que expone el motor agéntico completo de Claude Code — herramientas, permisos, gestión de sesiones, subagentes, MCP — como una API asíncrona y programable. Llamas a query(), pasas un prompt y unas opciones, y recibes en streaming el trabajo del agente como objetos de mensaje tipados.

¿Necesito tener Claude Code instalado para usar el SDK? Para el SDK de TypeScript, no — el paquete incluye un binario nativo de Claude Code. Para el SDK de Python, el paquete claude-agent-sdk se encarga de la dependencia. Sí necesitas una clave de API de Anthropic obtenida en la Anthropic Console.

¿Puedo usar el SDK con modelos distintos de Claude a través de la API de Anthropic? Sí. El SDK admite Amazon Bedrock, Google Vertex AI, Microsoft Azure AI Foundry y Claude Platform en AWS mediante variables de entorno. También puedes enrutar las solicitudes a través de un proxy personalizado configurando ANTHROPIC_BASE_URL.

¿Cómo uso el SDK en un workflow de GitHub Actions? Añade tu ANTHROPIC_API_KEY como secreto de GitHub Actions, haz checkout de la rama de la PR en tu workflow, instala el paquete del SDK y ejecuta tu script de agente. Usa permissionMode: "dontAsk" con una lista allowedTools de solo lectura para que el agente no pueda modificar archivos en tu entorno de CI. La documentación de Anthropic también cubre una integración dedicada con GitHub Actions que automatiza la revisión de PR y el triaje de incidencias sin escribir código de SDK personalizado.

¿Cuál es la diferencia entre el Agent SDK y Managed Agents? El Agent SDK es una librería que ejecuta el bucle del agente dentro de tu propio proceso e infraestructura. Managed Agents es una API REST alojada en la que Anthropic ejecuta el agente y el sandbox — tú envías eventos y recibes los resultados en streaming. El SDK es mejor para prototipado local y agentes que trabajan directamente sobre tu sistema de archivos; Managed Agents es mejor en producción cuando no quieres operar infraestructura de contenedores.

¿Cómo limito lo que el agente puede acceder? Usa allowedTools para restringir qué herramientas están disponibles, permissionMode: "dontAsk" para denegar cualquier cosa fuera de esa lista, y cwd para acotar el acceso al sistema de archivos a un directorio concreto. Para despliegues multiinquilino, establece además settingSources: [] y CLAUDE_CODE_DISABLE_AUTO_MEMORY=1.

¿El SDK admite salida en streaming? Sí — el iterador asíncrono de query() transmite los mensajes en tiempo real. Si no necesitas salida en directo (para trabajos en segundo plano o pipelines de CI donde solo te importa el resultado final), la documentación de Anthropic describe un modo de un solo turno que recopila todos los mensajes antes de devolverlos. Consulta Streaming vs. single-turn mode en la documentación oficial.

¿Puedo ejecutar varios agentes en paralelo? Sí. Cada llamada a query() lanza un subproceso independiente. Puedes ejecutar N sesiones simultáneas — pero cada una es un proceso separado, así que aprovisiona la memoria en consecuencia y ten en cuenta los límites de tasa de la API. Para repartos concurrentes de subagentes desde un único orquestador, agrupa tus envíos por lotes para evitar alcanzar los límites de tasa.

¿Qué ocurre si la sesión falla a mitad de la tarea? Por defecto, las transcripciones de sesión son locales al contenedor y se pierden al reiniciar. Para sobrevivir a los reinicios, configura un adaptador SessionStore (S3, Redis o Postgres) y pásalo en las opciones. Después podrás reanudar la sesión por session_id en un contenedor nuevo.

Ejecutar agentes sin una configuración local

La propuesta de valor del SDK es la automatización — pero poner en marcha esa automatización requiere infraestructura real: un entorno de ejecución de Python o Node, una clave de API, una estrategia de contenedores, una decisión de sandboxing y tiempo dedicado al modelado de permisos antes de tu primer despliegue en producción.

Para los desarrolladores que quieren iterar sobre ideas de agentes sin esa sobrecarga de configuración, Happycapy ejecuta agentes al estilo de Claude Code directamente en el navegador. No hay instalación local, ni gestión de subprocesos, ni aprovisionamiento de contenedores. Tú aportas un prompt, Happycapy se encarga del entorno de ejecución — con acceso a más de 150 modelos y un sandbox seguro en la nube. Es una vía rápida para prototipar el comportamiento del agente que más adelante llevarás a producción con el SDK.

Empieza gratis en happycapy.ai

Guías relacionadas

• Claude Code Hooks: The Power-User Guide to Automating Your Agent
• How Claude Code Review Actually Works: Diffs, Hooks, and What the Agent Catches
• Claude Code Web: How to Run Claude Code in Your Browser (No Install)
• What Is Harness Engineering? Building Reliable AI Agent Harnesses (2026)