MCP on KnightLi Blog

Graphify resuelve la mayor limitación de Claude Code: convertir un codebase en un grafo consultable por IA

Thu, 21 May 2026 08:02:32 +0800

safishamsi/graphify es una herramienta de grafo de conocimiento para asistentes de programación con IA. Su objetivo es directo: tomar el código, documentación, SQL schemas, scripts, papers, imágenes, video y audio dentro de una carpeta de proyecto, convertirlos en un grafo consultable y evitar que los asistentes de IA dependan solo de grep, lectura completa de archivos o búsquedas improvisadas para entender el proyecto.

Proyecto: safishamsi/graphify

En el momento de preparar este artículo, la página de GitHub muestra unas 50.2k stars y 5.4k forks, con licencia MIT. El README lo describe así: escribe /graphify en tu asistente de programación con IA y mapeará todo el proyecto como un grafo de conocimiento consultable.

El problema central que resuelve

Los asistentes de programación con IA son cada vez más potentes, pero en codebases reales todavía encuentran varios problemas:

No saben cómo se conectan los módulos clave.
Leen muchos archivos, pero no forman un mapa general de arquitectura.
La búsqueda encuentra texto, pero no dependencias aguas arriba y aguas abajo.
Código, database schema, documentación e infraestructura están dispersos.
En colaboración de equipo, cada persona puede tener un modelo mental distinto de la estructura del proyecto.

Graphify intenta añadir una “capa de memoria” al proyecto. Conecta entidades de código, conceptos documentales, tablas de base de datos, configuración, notas de diseño y relaciones entre archivos para que el asistente de IA pueda consultar el grafo en lugar de escanear archivos desde cero cada vez.

Uso mínimo

El uso mínimo de Graphify es muy simple. Tras instalarlo, escribe esto en tu asistente de programación con IA:

`1`	`/graphify .`

En PowerShell, el / inicial se interpreta como separador de ruta, así que en Windows PowerShell usa:

`1`	`graphify .`

Después de ejecutarlo, genera el directorio graphify-out/ con tres archivos principales:

graphify-out/
├── graph.html
├── GRAPH_REPORT.md
└── graph.json

Cada archivo cumple una función:

graph.html: grafo interactivo que se abre en el navegador, con nodos clicables, filtros y búsqueda.
GRAPH_REPORT.md: puntos destacados del proyecto, conceptos clave, conexiones inesperadas y preguntas sugeridas.
graph.json: grafo completo, consultable después sin volver a leer todos los archivos.

Para generar una página de arquitectura más legible con diagramas Mermaid de flujo de llamadas, ejecuta:

`1`	`graphify export callflow-html`

Instalación y soporte de plataformas

El paquete de Graphify en PyPI se llama graphifyy, con doble y. El README advierte que otros paquetes graphify* en PyPI no están afiliados al proyecto, aunque el comando CLI sigue siendo graphify.

La instalación recomendada es:

`1`	`uv tool install graphifyy`

También puedes usar:

1
2

pipx install graphifyy
pip install graphifyy

Después, regístralo con tu asistente de IA:

`1`	`graphify install`

El proyecto soporta muchas plataformas, incluidas Claude Code, Codex, OpenCode, GitHub Copilot CLI, VS Code Copilot Chat, Aider, Cursor, Gemini CLI, Kimi Code, Kiro y Google Antigravity. Cada plataforma puede usar comandos distintos, por ejemplo:

graphify install --platform codex
graphify install --platform gemini
graphify cursor install
graphify antigravity install

Los usuarios de Codex también deben añadir esto bajo [features] en ~/.codex/config.toml:

`1`	`multi_agent = true`

El README también indica que Codex usa $graphify, no /graphify.

Qué archivos puede procesar

Graphify cubre muchos tipos de entrada.

En código, soporta 31 lenguajes, incluidos Python, TypeScript, JavaScript, Go, Rust, Java, C/C++, Ruby, C#, Kotlin, Scala, PHP, Swift, Lua, Zig, PowerShell, SQL, Shell, JSON y más.

En documentación, soporta:

.md
.mdx
.qmd
.html
.txt
.rst
.yaml
.yml

También puede ampliarse con dependencias opcionales:

pip install "graphifyy[pdf]"
pip install "graphifyy[office]"
pip install "graphifyy[video]"
pip install "graphifyy[mcp]"
pip install "graphifyy[neo4j]"
pip install "graphifyy[sql]"
pip install "graphifyy[all]"

pdf sirve para extracción PDF, office para .docx y .xlsx, video para transcripción de video y audio, mcp para MCP stdio server, neo4j para enviar a Neo4j, y sql para extracción de SQL schema.

Qué valor tiene el informe generado

GRAPH_REPORT.md no es un resumen normal. Selecciona relaciones del proyecto que son especialmente útiles para asistentes de IA.

El README menciona contenidos como:

God nodes: los conceptos centrales más conectados del proyecto.
Surprising connections: enlaces inesperados entre archivos o módulos.
The why: razones de diseño extraídas de comentarios, docstrings y documentos de diseño.
Suggested questions: preguntas que el grafo está especialmente preparado para responder.
Confidence tags: cada relación se marca como EXTRACTED, INFERRED o AMBIGUOUS.

Esto es importante. Una búsqueda normal solo dice “dónde aparece esta palabra”. Un grafo puede responder “con qué módulos, configuraciones, tablas y documentos se conecta este concepto”. En codebases grandes, eso se acerca más a entender la arquitectura que una simple búsqueda de texto completo.

Comandos comunes

Comandos comunes de Graphify:

/graphify .
/graphify ./docs --update
/graphify . --cluster-only
/graphify . --no-viz
/graphify . --wiki
graphify export callflow-html
/graphify query "what connects auth to the database?"
/graphify path "UserService" "DatabasePool"
/graphify explain "RateLimiter"

También puedes añadir un paper o video al grafo:

1
2

/graphify add https://arxiv.org/abs/1706.03762
/graphify add <youtube-url>

Para análisis asistido de PR:

graphify prs
graphify prs 42
graphify prs --triage
graphify prs --conflicts

Estos comandos encajan con revisiones de código: ver qué comunidades del grafo afecta un PR, si hay riesgo de conflicto con otros PRs y qué review queue conviene priorizar.

Relación con MCP, Neo4j y CI

Graphify no solo genera un grafo HTML. También puede exponer el grafo a asistentes de IA para uso repetido.

Por ejemplo, puedes iniciar un MCP server:

`1`	`python -m graphify.serve graphify-out/graph.json`

El MCP server ofrece capacidades como query_graph, get_node, get_neighbors, shortest_path, list_prs, get_pr_impact y triage_prs.

También soporta exportación o push a Neo4j:

1
2

/graphify ./raw --neo4j
/graphify ./raw --neo4j-push bolt://localhost:7687

Para trabajo en equipo, el README recomienda poder commitear graphify-out/, de modo que todos empiecen con el mismo mapa del proyecto. También puedes ejecutar:

`1`	`graphify hook install`

Así el grafo se reconstruye automáticamente después de cada git commit y se configura un merge driver para evitar que graph.json quede con marcadores de conflicto cuando varias personas commitean en paralelo.

Privacidad y coste

El README de Graphify explica bastante bien los límites de privacidad.

Los archivos de código se parsean localmente con tree-sitter y no generan llamadas API. Video y audio pueden transcribirse localmente con faster-whisper. Docs, PDFs e imágenes para extracción semántica pasan por la API del modelo usado por tu asistente de IA.

Si usas headless graphify extract, puede que necesites estas variables de entorno:

ANTHROPIC_API_KEY
GEMINI_API_KEY
GOOGLE_API_KEY
OPENAI_API_KEY
DEEPSEEK_API_KEY
MOONSHOT_API_KEY
OLLAMA_BASE_URL

También pueden usarse backends como Ollama local, AWS Bedrock o Claude Code CLI. El README indica además que el proyecto no tiene telemetry, usage tracking ni analytics.

En la práctica, conviene recordar que parsear código localmente no significa que todo se quede offline. Si intervienen docs, PDFs, imágenes o modelos cloud, hay que revisar backend, API keys, cumplimiento empresarial y límites de datos.

Escenarios adecuados

Graphify encaja con varios tipos de usuarios:

Desarrolladores que quieren que Claude Code, Codex, Cursor y Gemini CLI entiendan mejor la estructura del proyecto.
Personas que necesitan comprender rápido un codebase grande y desconocido.
Equipos que quieren analizar juntos código, SQL schema, documentación y configuración.
Personas que hacen revisión de arquitectura, PR review o análisis de impacto de refactors.
Equipos que quieren exponer conocimiento del proyecto como herramienta MCP para Agents.
Líderes técnicos que quieren conservar un “mapa del proyecto” para el equipo.

No es necesario para todos los proyectos. En scripts pequeños, demos puntuales o repositorios muy simples, una búsqueda normal y el README quizá basten. El valor de Graphify aparece con más claridad en proyectos con muchos módulos, mucha documentación, mucha colaboración y uso frecuente de asistentes de IA.

Resumen

Graphify importa porque mueve el contexto de los asistentes de programación con IA desde “leer archivos temporalmente” hacia “un grafo de conocimiento del proyecto consultable y persistente”.

Para desarrolladores, no reemplaza el IDE, la búsqueda o el LSP. Añade una capa de memoria estructurada para asistentes de IA: qué módulos importan, qué conceptos están muy conectados, qué documentos explican decisiones de diseño y qué comunidades puede afectar un PR. A medida que herramientas Agent como Codex, Claude Code, Gemini CLI y Antigravity se vuelvan más comunes, esta capa de grafo del proyecto será cada vez más útil.

Referencias:

GitHub: safishamsi/graphify

¿Dejar que la IA opere el ordenador? UI-TARS-desktop conecta escritorio, navegador y herramientas

Tue, 19 May 2026 10:56:50 +0800

bytedance/UI-TARS-desktop es el proyecto open source de ByteDance para AI Agents multimodales. No es solo una aplicación de escritorio, sino un stack de agentes. El README actual contiene principalmente dos direcciones: Agent TARS y UI-TARS Desktop.

URL del proyecto: https://github.com/bytedance/UI-TARS-desktop

Sitio oficial: https://agent-tars.com

En el momento de escribir este artículo, la API de GitHub mostraba unas 34k estrellas, TypeScript como lenguaje principal y licencia Apache-2.0. El README lo describe como “Open-Source Multimodal AI Agent Stack”.

Diferencia entre Agent TARS y UI-TARS Desktop

El README coloca ambos proyectos en una misma tabla comparativa:

Agent TARS: stack general de AI Agent multimodal que conecta GUI Agent, visión, terminal, navegador y flujos de producto.
UI-TARS Desktop: aplicación de escritorio basada en modelos UI-TARS, con capacidades nativas de GUI Agent para operar ordenadores locales o remotos y navegadores.

En pocas palabras, Agent TARS se parece más a un runtime general de agentes, mientras que UI-TARS Desktop es la entrada de operación GUI en escritorio.

Qué puede hacer Agent TARS

Agent TARS ofrece principalmente CLI y Web UI. Su objetivo es permitir que modelos multimodales completen flujos de tareas más cercanos a la operación humana mediante MCP y distintas herramientas.

El README lista capacidades como:

Arranque CLI con un comando, con Web UI headful y servidor headless.
Control híbrido de navegador mediante GUI Agent, DOM o estrategias mixtas.
Event Stream para trazado y depuración.
Integración MCP para montar MCP Servers y herramientas reales.

Inicio rápido:

`1`	`npx @agent-tars/cli@latest`

Instalación global:

`1`	`npm install @agent-tars/cli@latest -g`

Ejecución con proveedor de modelo:

1
2

agent-tars --provider volcengine --model doubao-1-5-thinking-vision-pro-250428 --apiKey your-api-key
agent-tars --provider anthropic --model claude-3-7-sonnet-latest --apiKey your-api-key

Qué puede hacer UI-TARS Desktop

UI-TARS Desktop es un GUI Agent de escritorio. Basado en UI-TARS y las familias Seed-1.5-VL / 1.6, se centra en que el modelo entienda la pantalla y ejecute acciones de ratón y teclado.

El README menciona:

Control con lenguaje natural.
Capturas de pantalla y reconocimiento visual.
Control preciso de ratón y teclado.
Soporte multiplataforma para Windows, macOS y navegador.
Feedback y estado en tiempo real.
Procesamiento local con énfasis en privacidad y seguridad.

Ejemplos de tareas incluyen cambiar ajustes de VS Code, revisar issues de GitHub y operar ordenadores o navegadores remotos.

Por qué importan los GUI Agents

La automatización tradicional depende de APIs, DOM o scripts. Un GUI Agent parte de la interfaz: ve botones, campos, menús y estado, y luego opera con ratón y teclado.

Tiene dos valores. Primero, muchas aplicaciones no tienen APIs estables o las APIs no cubren todo el flujo. Un GUI Agent puede actuar sobre la misma superficie que usa una persona.

Segundo, los modelos multimodales pueden manejar capturas, documentos, páginas web e interfaces de aplicaciones, combinando comprensión visual y ejecución.

También hay límites. Las operaciones GUI dependen de resolución, idioma, cambios de layout, pop-ups y latencia. En producción hacen falta permisos, confirmaciones y planes de reversión.

Relación con MCP

Agent TARS enfatiza la integración MCP. MCP ayuda porque da a los agentes una forma unificada de llamar navegadores, archivos, línea de comandos, bases de datos, servicios internos y otras herramientas.

Para tareas complejas, hacer clic en la GUI no basta. Un patrón más estable suele ser:

Usar APIs cuando existen.
Usar visión cuando hay que entender el estado de la página.
Usar control de navegador cuando se necesita interacción web real.
Usar GUI Agent cuando hay que operar software local.

Proyectos como UI-TARS-desktop exploran cómo juntar esas capacidades en un mismo stack de agentes.

Precauciones

Los agentes de escritorio tienen riesgo de ejecución. Pueden operar ratón, teclado y navegador, así que hay que limitar permisos para evitar cambios accidentales en archivos, cuentas, pagos o sistemas de producción.

El control de ordenadores y navegadores remotos necesita límites de seguridad claros. No se deben exponer endpoints de control sin autenticación a internet.

Los modelos multimodales pueden leer mal la interfaz. Operaciones críticas como borrar, enviar, pagar, publicar o ejecutar trades deberían requerir confirmación humana.

Para quién es

UI-TARS-desktop encaja con desarrolladores que exploran GUI Agents, equipos que construyen asistentes para flujos de escritorio e investigadores que comparan navegador, DOM, MCP y control visual. Todavía es más una base para desarrolladores que un asistente de consumo simple.

Resumen

UI-TARS-desktop merece atención porque mueve los AI Agents desde “responder en chat” hacia “ver la pantalla y operar herramientas”. Su valor no está solo en controlar el escritorio, sino en combinar GUI, navegador, terminal y MCP dentro de un mismo stack.

¿Demasiadas plataformas para publicar? AiToEarn quiere ahorrar trabajo a creadores con AI Agents

Tue, 19 May 2026 10:56:50 +0800

yikart/AiToEarn es un proyecto de marketing de contenidos con IA para creadores, marcas y empresas unipersonales. Intenta reunir creación, publicación, interacción y monetización en un mismo flujo de agentes, cubriendo plataformas como Douyin, Xiaohongshu, Kuaishou, Bilibili, WeChat Channels, TikTok, YouTube, Facebook, Instagram, Threads, X, Pinterest y LinkedIn.

URL del proyecto: https://github.com/yikart/AiToEarn

Sitio oficial: https://aitoearn.ai/

En el momento de escribir este artículo, la API de GitHub mostraba unas 15k estrellas, TypeScript como lenguaje principal y licencia MIT. El README lo describe como una plataforma de agentes de marketing de contenidos para OPC, creadores, marcas y empresas.

Posicionamiento

AiToEarn no es solo un generador de textos ni una herramienta de programación de publicaciones. Divide el marketing de contenidos en cuatro capacidades de agente:

Monetize: monetización de contenidos.
Publish: publicación multiplataforma.
Engage: interacción y operaciones de comunidad.
Create: creación de contenidos.

Este enfoque encaja con el flujo real de muchos creadores. El problema no es solo si la IA puede escribir un texto, sino qué ocurre después: calendario, distribución, respuestas, revisión y conexión con objetivos comerciales.

Funciones principales

Monetize: monetizar contenido

AiToEarn ofrece capacidades de monetización orientadas a tareas promocionales. El README menciona tres modelos de liquidación:

Modelo	Nombre completo	Significado
CPS	Cost Per Sale	Liquidación por ventas
CPE	Cost Per Engagement	Liquidación por interacción
CPM	Cost Per Mille	Liquidación por impresiones o reproducciones

Esta parte se parece a un mercado de tareas de contenido que conecta necesidades de marcas con la distribución de creadores.

Publish: agente de publicación

Publish distribuye contenido en varias plataformas y reduce el trabajo repetitivo de publicar a mano. El README cubre plataformas de vídeo corto, contenido gráfico y redes sociales de China y del exterior.

Su valor práctico está en la programación y gestión unificadas. Para matrices de cuentas, distribución multiplataforma y equipos globales, esto puede ser más valioso que una función aislada de redacción con IA.

Engage: agente de interacción

Engage usa una extensión de navegador para operaciones automatizadas como likes, guardados, follows, respuestas a comentarios y monitorización de marca.

Hay que usarlo con cuidado. La interacción automatizada puede activar controles de riesgo de las plataformas, por lo que conviene revisar permisos, límites de frecuencia, términos y reglas internas de cumplimiento.

Create: agente de creación

Create se encarga de la generación de contenido. El README menciona modelos de generación de vídeo, traducción de vídeo, edición, generación de imágenes y tareas por lotes.

Es útil para producción a escala, pero sigue haciendo falta revisión humana. Contenido de marca, anuncios y piezas multilingües necesitan precisión factual, revisión de derechos y consistencia de tono.

Cinco formas de uso

Método	Ideal para	¿Requiere despliegue?
Usar el sitio web directamente	Todos los usuarios	No
Usarlo en OpenClaw	Usuarios de OpenClaw	No
Usarlo en Claude / Cursor y otros asistentes	Usuarios de herramientas IA	No
Despliegue Docker en un clic	Equipos que quieren self-hosting	Sí, servidor
Desarrollo desde código fuente	Desarrolladores	Sí, entorno de desarrollo

El soporte MCP es un punto importante. Permite que Claude, Cursor u otros agentes compatibles con MCP llamen a AiToEarn como capacidad externa.

Una configuración MCP habitual contiene:

1
2

MCP URL: https://aitoearn.ai/api/unified/mcp
Auth Header: x-api-key: your-API-Key

En self-hosting hay que sustituirlo por la URL del servicio propio.

Despliegue con Docker

El README ofrece una ruta con Docker:

1
2
3

git clone https://github.com/yikart/AiToEarn.git
cd AiToEarn
docker compose up -d

Luego se visita:

`1`	`http://localhost:8080`

Para equipos que valoran control de datos, despliegue privado o flujos personalizados, Docker puede ser más práctico que depender solo del sitio alojado.

Para quién es

AiToEarn encaja con creadores que publican en muchas plataformas, equipos pequeños de contenido, empresas unipersonales, marcas que colaboran con creadores y desarrolladores que quieren conectar flujos de contenido con AI Agents.

Si solo necesitas un generador de texto simple, puede ser demasiado amplio. Su valor está en conectar creación, publicación, interacción y monetización.

Antes de usarlo

La publicación y la interacción automatizadas deben respetar las reglas de cada plataforma. Una herramienta puede mejorar la eficiencia, pero no elimina la seguridad de cuenta ni el cumplimiento.

El contenido generado necesita revisión humana. Anuncios, publicaciones de marca y contenido en varios idiomas pueden tener riesgos de hechos, derechos y tono.

Las funciones de monetización implican tareas comerciales, así que conviene revisar reglas de pago, requisitos de divulgación y políticas de plataforma.

Resumen

AiToEarn merece atención porque trata las operaciones de contenido como un flujo completo, no solo como escritura. Para creadores y equipos pequeños, lo atractivo es reducir trabajo repetitivo entre plataformas. Para desarrolladores, lo interesante está en MCP y la integración con agentes.

agentmemory: memoria persistente para Claude Code, Codex, Cursor y otros agentes de programación

Tue, 19 May 2026 10:56:50 +0800

rohitg00/agentmemory es un sistema de memoria persistente para agentes de programación con IA. Su objetivo es claro: que Claude Code, Codex CLI, Cursor, Gemini CLI, OpenCode y herramientas similares no tengan que volver a aprender el contexto del proyecto, las decisiones de arquitectura y los problemas históricos en cada sesión nueva.

URL del proyecto: https://github.com/rohitg00/agentmemory

En el momento de escribir este artículo, la API de GitHub mostraba unas 13k estrellas, TypeScript como lenguaje principal y licencia Apache-2.0. El README lo describe como “Persistent memory for AI coding agents”.

Qué problema resuelve

Un dolor habitual de los coding agents es la fragmentación de memoria. Puedes pedir a un agente que arregle un problema de autenticación hoy y abrir una conversación nueva mañana, pero quizá ya no recuerde:

Por qué se tomó una decisión de arquitectura.
Qué archivos son delicados.
Qué bugs se corrigieron antes.
Qué comandos, herramientas o servicios locales usa el proyecto.
Qué convenciones sigue el equipo.

Las notas estáticas ayudan, pero a menudo se olvidan o no están conectadas al flujo activo. agentmemory intenta ofrecer una capa de memoria compartida entre distintas herramientas de programación con IA.

Agentes compatibles

El README menciona Claude Code, Codex CLI, Cursor, Gemini CLI, OpenCode y otras herramientas compatibles con MCP. La idea central es exponer memoria mediante un servicio local, MCP, hooks e integraciones, para que varios asistentes compartan el mismo contexto de proyecto.

Esto es útil para equipos que cambian de herramienta. Un desarrollador puede usar Cursor, otro Claude Code y la automatización Codex CLI. Una capa de memoria compartida reduce explicaciones repetidas.

Inicio rápido

Instalación global:

npm install -g @agentmemory/agentmemory
agentmemory
agentmemory demo
agentmemory connect claude-code

También se puede ejecutar con npx:

`1`	`npx @agentmemory/agentmemory`

El servicio local queda disponible en:

`1`	`http://localhost:3113`

En la práctica, el flujo suele ser iniciar el servicio, conectar el asistente de programación y dejar que el agente lea o escriba memorias del proyecto durante el desarrollo.

Diferencia con archivos de memoria estáticos

Muchos equipos ya mantienen AGENTS.md, CLAUDE.md, README o documentación local. Esos archivos son útiles, pero estáticos. No capturan automáticamente historial de sesiones, resultados de tareas o decisiones recurrentes.

agentmemory se parece más a un servicio de contexto persistente. Puede guardar y mostrar memorias relevantes para el proyecto o la tarea actual. No busca reemplazar la documentación, sino hacer más reutilizable el contexto de trabajo.

Escenarios típicos

Puede servir para:

Recordar pasos de setup y comandos frecuentes.
Registrar por qué se evitó un refactor arriesgado.
Guardar notas sobre tests inestables o servicios locales.
Compartir terminología de dominio entre asistentes.
Ayudar a continuar trabajo después de abrir una sesión nueva.

Tiene más valor en productos de larga vida, monorepos y proyectos con muchas convenciones implícitas.

Precauciones

La calidad de la memoria importa. Si se guarda información vieja o incorrecta, los agentes futuros pueden repetir el error. Las memorias importantes deberían ser cortas, claras y revisables.

También importa la privacidad. No conviene guardar secretos, API keys, datos de clientes ni información sensible de producción si el modelo de seguridad no está claro.

Por último, la memoria no sustituye las pruebas. Ayuda a entender contexto, pero la garantía final viene de revisión de código, tests y verificación.

Para quién es

agentmemory encaja con desarrolladores que usan varias herramientas de AI coding, equipos con codebases grandes y usuarios que necesitan que un agente continúe trabajo anterior. No es imprescindible para scripts pequeños de una sola vez.

Resumen

agentmemory es interesante porque trata la memoria como infraestructura para AI coding, no como un pequeño truco de prompt. Si los coding agents entran en el desarrollo diario, la memoria persistente de proyecto se vuelve una pieza práctica que faltaba.

Guía para ahorrar tokens en Claude Code: cómo modelos, MCP, CLAUDE.md y Skills afectan la caché

Mon, 18 May 2026 18:30:24 +0800

En tareas largas con Claude Code, la tasa de aciertos de Prompt Cache afecta directamente el costo y la velocidad. Muchos usuarios saben que la caché puede ahorrar tokens, pero no qué acciones hacen que falle de repente.

La forma más simple de entenderlo es imaginar cada petición como una cadena de contexto de izquierda a derecha:

`1`	`tools -> system -> CLAUDE.md / skills -> messages`

Cuanto más a la izquierda está un contenido, más estable debería ser y mayor es el beneficio de cachearlo. Si cambia una sección de la izquierda, todo lo que va después puede necesitar recalcularse. Si cambia algo a la derecha, el impacto suele ser menor.

Optimizar Prompt Cache en Claude Code no es magia. La regla es simple: antes de iniciar una tarea, prepara modelo, servidores MCP, Skills, CLAUDE.md y el contexto base. Una vez iniciada, cambia lo menos posible esa parte fija.

Prompt Cache no guarda texto plano

Prompt Cache no es solo una caché de cadenas de texto. En la inferencia Transformer, lo importante es el estado Key/Value calculado por las capas de atención a partir del prefijo de contexto, lo que solemos llamar KV cache.

Eso implica dos cosas:

Si el prefijo se mantiene estable, parte del cálculo previo puede reutilizarse.
Si cambian el modelo, las definiciones de herramientas, el prompt del sistema o los mensajes iniciales, las entradas antiguas de caché pueden dejar de coincidir.

La documentación de Anthropic resume la jerarquía de invalidación como tools -> system -> messages. Cambiar definiciones de herramientas puede invalidar toda la caché; cambios en system afectan system y messages; cambios en messages afectan sobre todo la caché de mensajes.

Claude Code añade otras fuentes de contexto como CLAUDE.md, Skills, MCP, plugins y subagents, así que es fácil romper la caché sin querer.

Asesino de caché 1: cambiar de modelo a mitad de tarea

Cambiar de modelo es una de las operaciones más caras.

Prompt Cache está aislada por modelo. Opus, Sonnet y Haiku tienen arquitecturas y pesos distintos, así que el KV cache calculado desde el mismo texto no es intercambiable. Si construyes un contexto largo en Opus y luego cambias a Sonnet, Sonnet no puede reutilizar la caché de Opus.

Esto produce un resultado poco intuitivo: cambiar a un modelo más barato a mitad de tarea puede hacer inútil la caché acumulada. El contexto que podría leerse a precio de cache read quizá tenga que escribirse y calcularse de nuevo.

Un patrón más estable:

Mantén la conversación principal en un solo modelo.
Usa un subagent para tareas laterales que puedan ejecutarse con un modelo más barato.
Deja que el agente lateral busque, explore o resuma, y devuelva un resultado breve a la conversación principal.

Así el prefijo largo de la conversación principal se mantiene estable y la caché acierta con más consistencia.

Asesino de caché 2: añadir MCP o recargar plugins a mitad de tarea

MCP proporciona herramientas a Claude Code. Al añadir un servidor MCP, cambia la lista de herramientas, y las definiciones de herramientas están en el extremo izquierdo de la cadena de contexto.

Desde la perspectiva de Prompt Cache, cuando cambia la lista de herramientas, system y messages pueden necesitar recalcularse. Si usas muchos MCP, las definiciones de herramientas pueden ocupar muchos tokens, y el costo de invalidación se nota.

Un detalle importante: Claude Code suele leer la configuración MCP al iniciar la sesión. Cambiar configuración durante la sesión no siempre afecta de inmediato. Los momentos peligrosos son reiniciar, hacer resume, recargar plugins o reconstruir la lista de herramientas.

Recomendaciones:

Instala los MCP necesarios antes de iniciar una tarea larga.
Evita descubrir a mitad de trabajo que falta una herramienta y recargar.
Reduce los MCP habilitados por defecto cuando sea posible.
No mantengas servidores MCP raramente usados siempre activos.

Las definiciones de herramientas estables son la base de una Prompt Cache estable.

Asesino de caché 3: editar CLAUDE.md durante la sesión

CLAUDE.md es el archivo de memoria de proyecto de Claude Code. Sirve para comandos de build, tests, convenciones de arquitectura, estilo de código y restricciones del proyecto.

Es útil, pero también entra en el contexto. La ayuda de Claude explica que CLAUDE.md se lee al iniciar la sesión y se entrega como mensaje de usuario. También se beneficia de Prompt Cache: la primera petición paga el precio completo de entrada, y las siguientes pueden usar el precio menor de cache read si la caché sigue válida.

El problema es que CLAUDE.md se identifica por contenido. Si cambias el archivo, la caché antigua deja de coincidir.

Por eso conviene no editar CLAUDE.md con frecuencia durante tareas largas. Mejor:

Revisa si CLAUDE.md es suficiente antes de empezar.
Coloca reglas estables en el archivo e instrucciones temporales en la conversación.
No edites la memoria de largo plazo por una necesidad puntual.
Si debes cambiarlo, trata la siguiente fase como una nueva sesión o etapa.

CLAUDE.md debería ser guía estable de proyecto, no un borrador temporal que cambia cada ronda.

Asesino de caché 4: instalar o actualizar Skills a mitad de tarea

Skills también forman parte del contexto. Instalar una Skill nueva, actualizar una Skill o cambiar la lista de Skills cambia lo que se inyecta en la sesión.

Estos cambios suelen aplicarse al recargar, reanudar o abrir una nueva sesión. Cuando messages se reconstruye, las entradas antiguas de caché pueden dejar de servir.

La recomendación es similar a MCP:

Decide qué Skills necesitas antes de empezar.
Mantén estable el conjunto de Skills para tareas similares.
Evita instalar Skills en mitad de una tarea larga.
Si instalas una Skill nueva, trátalo como inicio de una nueva etapa.

Para flujos repetibles como producción de contenido, review, despliegue o traducción, mantener un conjunto fijo de Skills ayuda a estabilizar la estructura del contexto.

Asesino de caché 5: estar inactivo más allá del TTL

Prompt Cache no dura para siempre. Un TTL común está en el orden de minutos, y la documentación relacionada con Claude Code suele hablar de una ventana cercana a cinco minutos. Pasado el TTL, incluso la misma petición puede requerir reconstruir la caché.

Esto explica una sensación común en tareas largas: todo iba rápido y barato, sales por un café, vuelves y el costo de tokens sube otra vez.

Es fácil que ocurra. Lees la salida de Claude Code, inspeccionas archivos, ejecutas tests o piensas el siguiente paso. Cinco minutos pasan rápido.

Si tu entorno lo permite, puedes pedir un TTL de una hora antes de tareas largas:

`1`	`export ENABLE_PROMPT_CACHING_1H=1`

En Windows PowerShell:

`1`	`$env:ENABLE_PROMPT_CACHING_1H="1"`

Las escrituras de caché de una hora suelen costar más que las de cinco minutos. No siempre conviene para tareas cortas, pero en bases de código grandes, conversaciones largas y trabajos complejos de varias etapas, puede ser más barato que sufrir expiraciones repetidas.

Un flujo de Claude Code que ahorra tokens

Un flujo más estable sería:

Elegir el modelo antes de empezar y evitar cambios frecuentes.
Habilitar los MCP necesarios y desactivar los que no usarás.
Mantener CLAUDE.md breve, estable y centrado en reglas duraderas.
Preparar por adelantado las Skills necesarias.
En tareas complejas, considerar TTL de una hora.
Dividir la tarea en fases, pero mantener estable la estructura de contexto dentro de cada fase.
Usar subagents o sesiones separadas para exploraciones laterales, sin alterar la conversación principal.

El objetivo no es eliminar todos los fallos de caché. Es evitar los fallos caros y fáciles de pasar por alto.

Regla rápida

Hazte esta pregunta:

¿Esta operación cambia el modelo, las definiciones de herramientas, el contexto del sistema o los mensajes fijos del inicio de la sesión?

Si la respuesta es sí, probablemente afecte a Prompt Cache. Cuanto más a la izquierda esté en la cadena de contexto, mayor será el impacto.

Operaciones comunes:

Cambiar modelo: alto riesgo, cachés aisladas por modelo.
Añadir MCP o recargar plugins: alto riesgo, cambia la lista de herramientas.
Editar CLAUDE.md: riesgo medio-alto, cambia la memoria del proyecto.
Instalar Skills: riesgo medio-alto, cambia el contexto inyectado.
Continuar una conversación normal: bajo riesgo, principalmente añade messages.
Superar el TTL en inactividad: alto riesgo, la caché del servidor expira.

Resumen

Optimizar Prompt Cache en Claude Code consiste en mantener estable el prefijo de la sesión.

No cambies modelos sin necesidad. No instales MCP y Skills a mitad de trabajo. No uses CLAUDE.md como borrador temporal. En tareas complejas, considera un TTL más largo. Con estas bases estables, el costo en tokens y la velocidad de respuesta se vuelven mucho más predecibles.

La frase práctica es: configura antes de empezar, cambia menos después.

Referencias

easy-vibe: un mapa de aprendizaje para principiantes de Vibe Coding

Sat, 16 May 2026 22:44:43 +0800

easy-vibe es un proyecto open source de Datawhale para aprender Vibe Coding. No está dirigido a desarrolladores que ya dominan herramientas de AI Coding, sino a estudiantes, product managers, diseñadores, equipos de operaciones, indie developers y personas con interés técnico que apenas empiezan con Vibe Coding.

El valor del proyecto no está en listar otro grupo de herramientas de IA, sino en convertir “cómo empezar a construir proyectos con IA” en una ruta de aprendizaje más fácil de entender. Para muchos principiantes, lo difícil no es saber que existen Claude Code, Cursor, MCP o los Agents. Lo difícil es saber qué aprender primero, cómo practicar y cuándo pasar a herramientas más avanzadas.

Lo que más necesitan los principiantes es una ruta

Vibe Coding se ha vuelto popular en los últimos años, pero no es especialmente amigable para principiantes.

En apariencia, si sabes describir un requisito, puedes pedir a la IA que escriba código. En la práctica, en cuanto la tarea se vuelve un poco más compleja, aparecen problemas: el requisito no está claro, el modelo modifica el archivo equivocado, la estructura del proyecto no se entiende, los errores no se saben resolver, las dependencias no se instalan, los prompts se vuelven cada vez más confusos y el flujo termina regresando a “copiar código en una caja de chat”.

Por eso aprender Vibe Coding no puede limitarse a “cómo escribir prompts”. Como mínimo debe resolver varias cosas:

Cómo dividir una idea en tareas ejecutables;
Cómo hacer que la IA entienda la estructura del proyecto;
Cómo leer el código generado por el modelo;
Cómo manejar errores e iterar;
Cómo usar la terminal y el entorno local de desarrollo;
Cómo pasar del chat web a herramientas reales de AI Coding.

Ahí está el sentido de easy-vibe: intenta organizar estos temas en una ruta de aprendizaje, en lugar de dejar que los principiantes se pierdan entre herramientas, tutoriales y términos.

No es un tutorial aislado, sino una hoja de ruta

Según la presentación del proyecto, easy-vibe cubre tutoriales básicos, ejercicios interactivos, contenido visual, RAG, herramientas de terminal, herramientas de AI Coding y temas más avanzados como Claude Code, MCP, Skills y Agent Teams.

Esta forma de organizar el contenido es adecuada para principiantes. AI Coding no es una sola habilidad, sino una combinación de capacidades:

Describir requisitos;
Dividir tareas;
Leer proyectos;
Pedir al modelo que modifique código;
Ejecutar y verificar;
Iterar según los errores;
Convertir flujos repetidos en herramientas o skills.

Si solo aprendes una herramienta, es fácil quedar limitado por su interfaz. Cambias de modelo, editor o CLI, y el flujo vuelve a no estar claro. La ventaja de una hoja de ruta es construir primero el método de trabajo y luego poner las herramientas en el lugar adecuado.

Es especialmente útil para no programadores

El mayor atractivo de Vibe Coding es que permite a personas que no son programadoras profesionales crear prototipos.

Un product manager puede convertir una idea de producto en un demo interactivo. Un diseñador puede validar lógica de interacción. Un equipo de operaciones puede crear herramientas internas. Un estudiante puede construir proyectos de clase rápidamente. Un fundador puede validar demanda en etapas tempranas. Estas personas no necesariamente necesitan convertirse en ingenieros full-time en el sentido tradicional, pero sí necesitan un método para “hacer que la IA me ayude a llevar una idea a algo funcional”.

Por eso easy-vibe encaja bien con la comunidad china. Muchos usuarios chinos ya saben que la IA puede escribir código, pero aún faltan materiales sistemáticos para empezar: entorno de desarrollo, prompts, estructura de proyecto, depuración y uso de herramientas Agent. Es mejor cuando todo se explica con claridad en chino y se acompaña con ejercicios graduales.

Para este tipo de usuarios, lo más importante no es aprender un framework complejo desde el primer día, sino completar un ciclo completo: plantear un requisito, generar un proyecto, ejecutarlo, encontrar problemas, seguir modificando y terminar con una versión usable.

La parte avanzada se acerca a flujos reales de desarrollo con IA

Claude Code, MCP, Skills y Agent Teams, que aparecen en easy-vibe, ya no son solo conceptos introductorios.

Claude Code representa los Agents de programación en terminal: el modelo puede entrar en un proyecto local, leer archivos, modificar código y ejecutar comandos. MCP resuelve la conexión con herramientas y fuentes de datos, para que el modelo no se quede encerrado en una caja de chat. Skills permite conservar flujos reutilizables, como generación fija de proyectos, organización de documentos, revisión de tests o procesos de producción de contenido. Agent Teams va un paso más allá y divide tareas entre varios agentes.

Para principiantes, estos temas pueden parecer lejanos, pero vale la pena conocerlos pronto. La dirección de Vibe Coding ya está clara: pasar de “hacer que la IA escriba un fragmento de código” a “hacer que la IA participe en un flujo completo de proyecto”.

Si una ruta de aprendizaje se queda solo en prompts, pronto quedará atrás frente a la evolución de las herramientas. Pero si al principio se lanzan todos los conceptos avanzados a la vez, el principiante no sabrá por dónde empezar. El valor razonable de easy-vibe es colocar esos temas en una ruta de actualización gradual.

Dos errores que conviene evitar

El primer error es creer que Vibe Coding significa que, aunque no sepas código, puedes desentenderte por completo del código.

La IA puede generar muchas cosas, pero el usuario sigue necesitando juzgar si el resultado es correcto. Como mínimo, hay que entender la estructura del proyecto, saber cómo ejecutarlo y ubicar aproximadamente dónde ocurre un error. Aunque no escribas código complejo, necesitas sentido común básico de ingeniería.

El segundo error es creer que cuanto más avanzada sea la herramienta, mejor.

Un principiante no necesariamente necesita Claude Code, MCP o múltiples Agents al inicio. Un orden mejor es crear primero un ciclo de feedback con proyectos simples, y luego introducir poco a poco terminal, control de versiones, tests, llamadas a herramientas y flujos automatizados. Las herramientas deben coincidir con la complejidad de la tarea; si no, se convierten en algo que parece potente pero no se sabe para qué usar.

Cómo usarlo

Si apenas empiezas con Vibe Coding, puedes usar easy-vibe como una lista de aprendizaje.

Empieza con conceptos básicos y ejercicios simples. No hace falta perseguir todas las herramientas. Construye un proyecto pequeño, como una página personal, un dashboard de datos, una herramienta de formularios, un script de automatización o una demo de base de conocimiento. Durante el proceso, observa en qué partes ayuda la IA y en cuáles necesitas confirmar por tu cuenta.

Cuando puedas completar proyectos pequeños de forma estable, empieza con temas más complejos:

Usar herramientas de terminal para trabajar con proyectos locales;
Usar Git para gestionar cada cambio;
Usar RAG para conectar tus propios materiales;
Usar MCP para conectar herramientas externas;
Usar Skills para fijar flujos repetidos;
Usar Agent Teams para dividir tareas complejas.

Aprender Vibe Coding así no es solo aprender a preguntar a la IA. Es aprender a poner la IA dentro de tu propio flujo de trabajo.

Conclusión

easy-vibe puede verse como un mapa de entrada en chino para Vibe Coding. Organiza conceptos, herramientas y ejercicios dispersos de AI Coding en una ruta que ayuda al principiante a pasar de “he oído que la IA puede escribir código” a “puedo construir un proyecto con IA”.

El valor real de Vibe Coding no es saltarse todo aprendizaje, sino bajar la barrera entre idea y prototipo. Aún necesitas entender requisitos, organizar tareas, verificar resultados y controlar riesgos. Pero muchos pasos repetitivos, tediosos y fáciles de bloquear pueden hacerse con ayuda de la IA.

Si quieres una entrada sistemática al AI Coding y no quieres perderte desde el principio entre nombres de herramientas y configuraciones de ingeniería complejas, easy-vibe es un buen punto de partida.

Anthropic financial-services: convertir escenarios de agentes financieros en plantillas reutilizables

Sat, 16 May 2026 22:43:08 +0800

anthropics/financial-services es un proyecto de referencia de Anthropic para la industria de servicios financieros. No es una sola aplicación, sino un conjunto de ejemplos que se pueden estudiar y reutilizar por separado: Agents, Plugins, Skills, conectores MCP, además de prompts y patrones de integración diseñados alrededor de flujos financieros.

Este proyecto merece atención no porque ofrezca un “asistente financiero universal”, sino porque divide los problemas habituales de adopción de IA en finanzas en componentes más concretos: qué Agent necesita cada rol, qué fuentes de datos deben conectarse, qué tareas se pueden automatizar y qué pasos siguen requiriendo juicio humano.

Se parece más a una sala de muestras de agentes financieros

Cuando las empresas hablan de AI Agents, la conversación suele quedarse en lo abstracto: leer archivos, consultar datos, escribir informes y llamar herramientas. Pero al entrar en escenarios financieros, las preguntas se vuelven mucho más concretas.

Un analista de banca de inversión necesita organizar materiales de compañías, generar resúmenes de transacciones y comparar empresas comparables. La investigación de acciones necesita leer reportes, seguir noticias, hacer valoración y analizar riesgos. Los equipos de private equity y asset management necesitan filtrar oportunidades, escribir memos y seguir compañías en cartera. Wealth management necesita colocar perfiles de clientes, información de mercado y recomendaciones dentro de un marco de cumplimiento.

Estos escenarios no se resuelven solo con un cuadro de chat genérico. Requieren roles, procesos, fuentes de datos, formatos de salida y límites de permisos. El valor de este repositorio de Anthropic está ahí: convierte múltiples roles y tareas típicas de servicios financieros en plantillas de Agent que pueden servir como referencia.

Por qué ofrece Agents, Plugins, Skills y MCP a la vez

Por la estructura del proyecto, Anthropic no entregó solo un conjunto de prompts. Ofrece varios tipos de componentes al mismo tiempo. Eso corresponde a varias capas de una implementación empresarial de Agents.

Agents se parecen más a unidades de trabajo orientadas a roles o tareas. Definen qué debe hacer el agente, cómo debe hacerlo, cuándo llamar herramientas y cómo producir la salida.

Plugins se parecen a extensiones de capacidades externas. El trabajo financiero rara vez ocurre solo dentro del modelo. A menudo necesita conectarse a bases de datos, sistemas documentales, datos de mercado, CRM, bibliotecas de investigación y sistemas internos de workflow.

Skills funcionan como paquetes reutilizables de capacidad profesional. Marcos de análisis, estructuras de reportes, checklists y métodos de procesamiento de datos pueden convertirse en skills, en lugar de reescribirse como prompts cada vez.

Los conectores MCP resuelven la integración de herramientas y la estandarización del contexto. Para una empresa, cuantas más herramientas hay, más necesario es un modo relativamente unificado de conectarlas. Si no, cada sistema requiere una adaptación separada y el costo de mantenimiento crece.

Solo al combinar estas piezas el resultado empieza a parecerse a un flujo real de IA empresarial.

Por qué las finanzas son un buen sector para ejemplos de Agents

Los servicios financieros son un buen sector para mostrar Agents porque reúnen tres características.

Primero, la densidad de información es alta. El trabajo financiero depende mucho de estados financieros, anuncios, minutas de reuniones, informes de investigación, datos de trading, información de clientes y documentos regulatorios. Si un modelo depende solo de conocimiento general, se vuelve inútil rápidamente. Necesita conectarse a fuentes reales de datos.

Segundo, los formatos de salida son estables. Memos de inversión, perfiles de compañías, documentos KYC, resúmenes de investigación, briefings para clientes e informes de operaciones de fondos tienen estructuras relativamente fijas. Eso facilita que los Agents formen workflows verificables.

Tercero, los límites de riesgo son claros. Finanzas exige cumplimiento, auditoría, permisos y trazabilidad. La IA no puede dar recomendaciones de inversión libremente ni saltarse procesos de aprobación. Esto obliga a diseñar Agents de forma más ingenieril: conservar referencias, separar hechos e inferencias, registrar llamadas a herramientas y limitar acciones ejecutables.

Por eso este proyecto no es solo para compañías financieras. Cualquier equipo que quiera crear Agents empresariales puede observar cómo Anthropic descompone escenarios de industria.

Qué flujos típicos cubre

Según la descripción del proyecto, el repositorio cubre varias áreas de servicios financieros, incluidas:

Banca de inversión;
Investigación de acciones;
Private equity;
Wealth management;
Gestión de fondos;
Workflows de KYC y cumplimiento.

Estos procesos tienen algo en común: todos requieren mucha lectura, organización, comparación y generación de materiales estructurados. Aquí lo más adecuado para la IA no es decidir directamente, sino reducir el tiempo de procesamiento de información y producción documental.

Por ejemplo, en banca de inversión, un Agent puede ayudar a organizar información de una compañía objetivo, extraer métricas financieras clave y generar un primer borrador de resumen de transacción. En investigación, puede leer primero reportes y noticias, y listar cambios clave y preguntas pendientes. En KYC, puede ayudar a comprobar si la documentación está completa y si hay señales anómalas.

El juicio final debe seguir en manos de profesionales. El rol del Agent se parece más al de asistente, analista y acelerador de procesos.

Qué sugiere para la adopción empresarial

La parte más valiosa de este repositorio es que convierte “capacidad del modelo” en “componentes de negocio”.

Los proyectos internos de IA suelen encontrarse con el mismo problema: la demo del modelo se ve bien, pero al conectarlo con negocio real cuesta reutilizarlo. Un equipo escribe un conjunto de prompts, otro equipo escribe otro. Un sistema conecta una base de datos, otro vuelve a crear su propia interfaz. Los requisitos de seguridad y auditoría quedan dispersos.

Un enfoque más sólido es dividir las capacidades en varios tipos de activos:

Agents orientados a roles;
Skills orientados a procesos;
Conectores MCP para integración con sistemas;
Reglas de ejecución para permisos y auditoría;
Plantillas y checklists para salidas de negocio.

La ventaja es que la empresa no empieza cada vez desde “crear un chatbot”. Va acumulando activos de workflow de IA que se pueden mantener.

No se pueden ignorar cumplimiento y responsabilidad

El malentendido más común sobre los Agents financieros es confundir “puede generar análisis” con “puede sustituir decisiones”.

En servicios financieros, la salida de IA normalmente debe tratarse como material de apoyo. Puede ordenar hechos, generar borradores, señalar riesgos y completar documentos, pero no puede saltarse investigación, control de riesgos, legal, cumplimiento ni requisitos de idoneidad del cliente. Especialmente cuando hay recomendaciones de inversión, decisiones de trading, asignación de activos o verificación de identidad, deben mantenerse aprobación humana y cadena de responsabilidad.

Por eso los Agents empresariales no pueden evaluarse solo por la calidad de sus respuestas. También hay que mirar:

Si las fuentes de datos son fiables;
Si referencias y evidencia son trazables;
Si las llamadas a herramientas quedan registradas;
Si los datos sensibles están restringidos;
Si la salida pasa por confirmación humana;
Si los resultados erróneos pueden detectarse y revertirse.

Si estas preguntas no se resuelven, cuanto más automático sea el Agent, mayor será el radio de riesgo.

Conclusión

anthropics/financial-services se parece más a una implementación de referencia de Agents financieros que a un producto financiero listo para usar. Muestra una forma en que Anthropic piensa la adopción empresarial de IA: no crear solo asistentes de chat genéricos, sino organizar Agents alrededor de roles concretos, procesos concretos, fuentes de datos concretas y límites de permisos concretos.

Para instituciones financieras, puede servir como referencia para diseñar workflows internos de IA. Para desarrolladores, ofrece una muestra de arquitectura de Agents empresariales: Agents gestionan roles y tareas, Skills conservan procesos profesionales, Plugins y MCP conectan sistemas externos, y el modelo termina entrando en flujos reales de negocio.

Si las primeras herramientas de IA resolvían “cómo hacer que el modelo responda preguntas”, proyectos como este se preocupan más por “cómo dejar que el modelo participe en el trabajo dentro de límites controlados”. Ahí está la verdadera dificultad de los Agents empresariales.

¿Cómo evolucionaron los AI Agents? Guía completa de cinco generaciones, 2022-2026

Sat, 16 May 2026 19:19:52 +0800

Los AI Agents no aparecieron de un día para otro.

A finales de 2022, ChatGPT era principalmente una ventana de chat. Para 2026, los agentes empezaron a tener llamadas de herramientas, operaciones con archivos, control del ordenador, memoria a largo plazo, colaboración remota y ejecución persistente. En cuatro años pasaron de “modelos que responden preguntas” a “trabajadores digitales que empujan tareas”.

Vistos en línea temporal, los AI Agents pasaron por unas cinco generaciones. Cada una resolvió una limitación de la anterior y creó nuevas burbujas y nuevos problemas de seguridad.

Resumen: cinco generaciones de Agents

Etapa	Tiempo	Palabra clave	Cambio de capacidad	Problema central
Generación 0	Finales de 2022 - inicio de 2023	Chat	Genera texto, pero no actúa	El modelo está separado del mundo real
Generación 1	Mitad de 2023 - final de 2023	Tool calling	Produce llamadas estructuradas, conecta API y RAG	Ejecución abierta y pérdida de dirección
Generación 2	Finales de 2023 - 2024	Workflows de ingeniería	Planificación, estado, reflexión y multi-agent	Workflows fáciles de copiar
Generación 3	2024 - 2025	Computer Use	Ve pantallas y opera GUI	Permisos, seguridad y errores de operación
Generación 4	2025 - 2026	MCP / Skills / persistencia	Red de herramientas, contexto largo y skills	La ejecución persistente amplía el riesgo
Generación 5	Después de 2026	Loops y world models	Más memoria, validación y acción física	Gobernanza más difícil

Finales de 2022: Generación 0, la era del chat de ChatGPT

La Generación 0 empieza con el lanzamiento de ChatGPT el 30 de noviembre de 2022.

Todavía no era un Agent real. Tenía gran capacidad de lenguaje, pero estaba encerrado en una ventana de chat. Podía escribir Python, pero no ejecutarlo en tu ordenador. Podía planificar un viaje, pero no comprar billetes. Podía explicar cómo editar un archivo, pero no entrar en el sistema de archivos y modificarlo.

Sus límites eran claros:

entender lenguaje natural;
generar artículos, respuestas, código y planes;
no acceder por sí mismo a datos recientes;
no leer de forma estable documentos internos de empresa;
no ejecutar acciones externas;
no gestionar estado de tareas largas.

El problema central era la desconexión entre capacidad del modelo y mundo real. Podía pensar y hablar, pero no actuar.

Esta etapa también creó la primera burbuja: prompt engineers, mercados de plantillas, cursos y certificaciones. Los modelos tempranos sí eran sensibles al prompt, pero el mercado confundió un parche temporal con una ventaja duradera.

Con modelos tipo GPT-4, system prompts, function calling y mejores valores por defecto, muchas plantillas perdieron escasez. El patrón se repitió después: una nueva capacidad crea una capa intermedia; la siguiente generación la incorpora; la capa intermedia desaparece.

Mitad de 2023: Generación 1, despierta el tool calling

La palabra clave de la Generación 1 es tool calling.

En junio de 2023, OpenAI lanzó function calling. Los desarrolladores podían describir nombres de funciones, usos, tipos de parámetros y JSON Schema. Tras entender la petición del usuario, el modelo podía devolver una llamada JSON estructurada, que un sistema externo ejecutaba.

El cambio arquitectónico fue enorme: el modelo pasó de ser un cerebro que solo habla a un cerebro que puede mover herramientas externas.

Capacidades clave:

elegir herramientas según la intención;
producir argumentos estructurados;
llamar API externas;
devolver resultados al modelo para seguir razonando;
usar RAG para acceder a conocimiento externo;
formar personas tempranas con plugins y bases de conocimiento.

Al mismo tiempo, RAG y las bases vectoriales se volvieron populares. Resolvieron el problema de información reciente, material privado e información interna. El sistema recupera fragmentos relevantes, los inyecta en el contexto y el modelo responde a partir de ellos.

La estructura básica del Agent quedó así:

quién eres: system prompt y persona;
qué sabes: base de conocimiento, RAG, documentos privados;
qué puedes hacer: function calling, plugins, API externas.

La burbuja más visible fue AutoGPT. La idea era atractiva: el usuario da un objetivo amplio, y la IA descompone tareas, busca, escribe archivos, evalúa, itera y se detiene cuando cree haber terminado.

Pero AutoGPT mostró pronto sus fallos. Le faltaban restricciones de estado, condiciones de parada y feedback fiable. Las tareas se desviaban, las API se llamaban con argumentos erróneos y los costes podían dispararse. La lección fue clara: herramientas más bucles infinitos no hacen un Agent de producción.

Finales de 2023 a 2024: Generación 2, workflows de ingeniería

El fracaso de AutoGPT enseñó que no basta con dejar improvisar al modelo. Las tareas complejas necesitan proceso.

La Generación 2 trata de workflows de ingeniería. El Agent deja de ser una llamada al modelo y se convierte en un sistema con estado, control de flujo y evaluación.

Capacidades clave:

planificación: dividir objetivos grandes en pasos;
gestión de estado: saber por dónde va la tarea;
reflexión y revisión: generar, evaluar y corregir;
orquestación de herramientas;
intervención humana en puntos críticos;
colaboración multi-agent.

El patrón típico es ReAct, o Reasoning + Acting. El modelo razona, llama una herramienta, observa el resultado y razona otra vez. Así cada paso tiene lógica auditable y feedback.

La Generación 2 puso la capacidad del modelo dentro de un proceso controlable. Un buen workflow puede producir resultados más estables que una única llamada a un modelo grande.

También apareció la burbuja de plataformas low-code para Agents. Interfaces visuales permitían combinar prompt, RAG, plugins y flujos. Bajaban la barrera de construcción, pero si un workflow puede copiarse barato, la plataforma tiene poco moat.

Capturar demanda temprana no equivale a tener una defensa duradera.

2024 a 2025: Generación 3, Computer Use entra en interfaces reales

La palabra clave de la Generación 3 es Computer Use.

Antes, el tool calling dependía de API. Lo que el Agent podía hacer dependía de lo que alguien hubiera conectado. Pero muchas aplicaciones reales no tienen API limpias, abiertas o completas.

Computer Use permite al modelo ver pantallas, hacer clic y operar GUI. La interfaz general del ordenador se convierte en herramienta.

Capacidades clave:

reconocer contenido en pantalla;
hacer clic, escribir texto y cambiar ventanas;
operar web y software de escritorio;
leer repositorios, editar archivos y ejecutar pruebas;
revisar terminal y errores;
acercarse a un asistente de ingeniería real.

Esto empujó al Agent de “usar herramientas conectadas” a “operar software como una persona”. También acercó los coding agents al flujo real: leer proyecto, cambiar código, correr pruebas y corregir por errores.

Pero la frontera de confianza creció. Si la IA opera un ordenador, puede hacer clic mal, borrar archivos, enviar formularios o ser manipulada por texto de páginas, documentos o interfaces. Prompt injection pasa a ser un problema de archivos, permisos y seguridad del sistema.

La lección de la Generación 3: cuanto más cerca esté el Agent de operaciones reales, más necesita sandbox, aprobaciones, rollback y mínimo privilegio.

2025 a 2026: Generación 4, MCP, Skills y trabajadores digitales persistentes

La Generación 4 se centra en persistencia, conexión, memoria y especialización.

El foco ya no es solo hacer mejor una tarea aislada. Los Agents empiezan a tener contexto a largo plazo, red de herramientas, skills profesionales y sentido del tiempo. Se parecen menos a un asistente de una conversación y más a un trabajador digital continuo.

MCP resuelve la conexión de herramientas. Permite conectar sistemas de archivos, bases de datos, navegadores, herramientas de diseño, gestión de proyectos y sistemas empresariales de forma más estándar. Cuando el protocolo se estabiliza, muchas capas intermedias de conexión se comprimen.

Skills resuelve el método profesional. Las herramientas dicen qué puede hacer el Agent; las skills dicen cómo debe hacerlo. Una buena skill no es solo un prompt: empaqueta flujo de dominio, restricciones, checks, errores comunes y orden de herramientas.

Capacidades clave:

memoria a largo plazo: preferencias, reglas de proyecto e historial;
contexto de proyecto: repositorios, documentación y normas;
red de herramientas: MCP, API, navegador y sistema de archivos;
skills profesionales: métodos de tarea empaquetados;
ejecución persistente: esperar, despertar, recordar y seguir;
colaboración remota: aprobar y ajustar desde otros dispositivos.

Esta generación empieza a tener sensación de empleado: identidad, límites de responsabilidad, contexto largo, método profesional, sentido del tiempo, permisos de herramientas y capacidad de avanzar sin supervisión constante.

Pero cuanto más se parece a un empleado, más se parece su radio de riesgo. Ejecución persistente, datos locales, secretos, llamadas a herramientas y tareas reales convierten la seguridad en un asunto central.

Hay un punto especialmente importante: el texto también es superficie de ataque. Si un Agent lee y obedece Markdown, documentación, skill packs o páginas web, texto malicioso puede cambiar su conducta. Prompt injection se vuelve problema de supply chain, permisos y ejecución.

La lección de la Generación 4: los Agents persistentes necesitan gobernanza, no solo capacidad.

Después de 2026: Generación 5, loops, memoria interna y world models

La Generación 5 todavía no es historia cerrada. Es una extrapolación de los cuatro años anteriores.

Un Agent maduro necesita al menos tres loops:

loop de ejecución: verificar tras cada acción, hacer rollback, corregir y reintentar;
loop temporal: seguir objetivos largos entre varios ciclos de activación;
loop cognitivo: distinguir información segura, suposiciones e información caducada.

La segunda dirección es memoria interna. Hasta ahora, gran parte de la memoria está fuera del modelo: RAG, vectores, historial, archivos locales, memory.md. Si los modelos futuros soportan estado persistente entre sesiones, la memoria de los Agents se rediseñará.

La tercera dirección son los world models. Muchos Agents actuales son reactivos: observar, responder, volver a observar. Las tareas de alto riesgo necesitan simular consecuencias antes de actuar.

La cuarta dirección es embodiment. Las generaciones anteriores vivían sobre todo en espacio digital: API, pantallas, archivos, navegador, herramientas empresariales. El siguiente paso puede llevar la acción a robots, dispositivos, sistemas industriales e interfaces físicas.

La Generación 5 tendrá que resolver cómo ejecutar tareas, entender consecuencias, gestionar estado largo y mantenerse fiable en un radio de riesgo mayor.

Seis reglas detrás de la línea temporal

Primera: la capacidad del modelo base sigue siendo el techo. Un Agent no es magia fuera del modelo, sino capacidad del modelo liberada mediante ingeniería.

Segunda: la arquitectura de ingeniería amplifica el modelo. Planificación, verificación, reflexión, corrección, evaluación y permisos se acercan más a resultados entregables que una generación única.

Tercera: los protocolos abiertos redistribuyen valor. Cuando MCP, Skills y contexto de proyecto se estabilizan, la competencia pasa de conectar herramientas a acumular capacidad real de dominio.

Cuarta: la línea oculta es la ampliación de la confianza humano-máquina. Texto, API, workflows, ordenador y ejecución persistente amplían cada vez más el radio de riesgo.

Quinta: cada accidente se convierte en regla para la siguiente generación. Los bucles de AutoGPT empujaron la orquestación; los fallos de vibe coding empujaron evaluación; los borrados en producción empujaron permisos mínimos y sandbox.

Sexta: el ecosistema Agent alterna explosión y extinción. Las nuevas capacidades crean capas temporales; los modelos o plataformas las incorporan después. Confundir una ventana temporal con un moat es peligroso.

El moat real

El moat real en AI Agents no es empaquetar primero una nueva capacidad.

Hay tres moats más fiables.

Primero, profundidad vertical. ¿Entiendes de verdad el flujo, riesgos, excepciones y responsabilidades de una industria?

Segundo, data flywheel. ¿Puedes acumular feedback real de alta calidad y mejorar procesos, evaluación, fine-tuning y decisiones de producto?

Tercero, confianza del usuario. ¿Te entregan trabajo de más valor, más largo y más riesgoso, o solo te usan como herramienta puntual?

Cuando una plataforma o modelo base absorbe una capacidad, los productos que aún conservan procesos, feedback, límites de responsabilidad y confianza tienen más probabilidades de sobrevivir.

Cierre

De 2022 a 2026, la evolución de AI Agents no fue “modelos que chatean mejor”. Fue “humanos dispuestos a entregar más trabajo a la IA”.

Un Agent maduro no es el sistema que más se atreve a ejecutar. Es el sistema que sabe cuándo ejecutar, cuándo verificar, cuándo pausar y cuándo pedir confirmación humana.

Para juzgar si un producto Agent tiene valor a largo plazo, pregunta: cuando el próximo modelo o plataforma incorpore esta capacidad, ¿qué queda?

Si la respuesta es proceso de dominio, datos reales, resultados verificables y confianza del usuario, puede haber valor duradero.

Conectar Claude a Fusion 360: un ejemplo de edición de modelos STEP con AI

Thu, 14 May 2026 20:58:04 +0800

Después de conectar Claude a Fusion 360, ya no sirve solo para “explicar ideas”: puede participar directamente en la edición de modelos CAD. Un flujo típico consiste en abrir un archivo STEP existente, dejar que Claude lea el modelo actual, analice conflictos estructurales, planifique dimensiones y ejecute cambios de modelado a través del plugin de Fusion.

A continuación se usa la modificación de un divisor con engranaje planetario como ejemplo para resumir el flujo básico de Claude + Fusion 360.

Primero activa el servicio API/MCP de Fusion 360

Empieza con una configuración básica en Fusion 360:

Abre Preferences en la esquina superior derecha.
Entra en General.
Busca la opción API.
Activa el MCP server.
Anota el número de puerto. El ejemplo por defecto es 27182.

Después vuelve a Claude, entra en Connectors, busca el conector de Fusion e introduce la dirección y el puerto de Fusion 360. Normalmente basta con el puerto por defecto 27182.

Cuando la conexión funciona, Claude puede interactuar con el modelo abierto a través del plugin de Fusion.

Abre el archivo STEP y define claramente el objetivo

La pieza a modificar es un engranaje dentro de un divisor planetario. En el diseño original, el engranaje se fija al soporte con un tornillo que actúa como eje central.

El objetivo es convertirlo en una estructura con rodamiento:

el agujero central debe adaptarse al rodamiento;
los agujeros de tornillo alrededor no deben interferir con el agujero central ampliado;
el agujero para tornillo autorroscante del soporte también debe ajustarse a una estructura de eje adecuada para la rotación del rodamiento;
el modelo final debe poder importarse en un slicer y usarse para impresión 3D.

La clave es no decirle simplemente a Claude “modifica esto”. Hay que explicar claramente el uso, el método de ensamblaje, el material y el proceso de fabricación.

Claude puede entender el modelo actual mediante capturas

Algunas personas se preocupan de que el plugin de Fusion solo pueda ejecutar comandos y no permita que Claude vea el modelo. En pruebas reales, Claude puede reconocer el estado actual del modelo mediante capturas de pantalla.

En este caso, Claude pudo ver la estructura del engranaje y hacer varias cosas:

identificar el engranaje y el agujero central;
medir o estimar dimensiones relevantes;
recomendar dimensiones de rodamiento;
juzgar qué estructuras afectarían la instalación del rodamiento;
detectar que, al ampliar el agujero central, los agujeros de tornillo alrededor podrían generar interferencia geométrica.

Este paso es importante. Muestra que Claude no edita a ciegas siguiendo solo instrucciones de texto, sino que puede combinar la vista actual del modelo con razonamiento estructural.

El material y el método de fabricación deben indicarse antes

Si el modelo final se usará para impresión 3D, hay que decirle claramente a Claude el material y el proceso.

Por ejemplo, al imprimir con PLA, el agujero para el rodamiento no debe diseñarse estrictamente con tolerancias de mecanizado CNC en metal. Para un rodamiento de 6mm que debe entrar a presión, puede considerarse un diámetro de agujero cercano a 6.1mm. Si ese tamaño es adecuado dependerá de la precisión de la impresora, la contracción del material, los parámetros del slicer y las pruebas reales.

Si no se especifica el material, Claude puede asumir tolerancias propias de CNC. El agujero resultante puede ser demasiado pequeño para impresión 3D y dificultar el ensamblaje.

Un prompt útil sería:

1
2
3

Este modelo es para impresión 3D FDM, usando PLA.
El objetivo es instalar un rodamiento de 6mm, así que hay que considerar tolerancia de impresión y ajuste a presión.
No lo trates como tolerancia de mecanizado CNC en metal.

Deja que Claude modifique la estructura del engranaje

Una vez claro el objetivo, Claude puede ejecutar modificaciones concretas:

ampliar el agujero central;
ajustar los agujeros de tornillo que generan interferencia;
añadir un asiento para rodamiento;
añadir chaflanes en los bordes;
mantener el cuerpo del engranaje y la estructura de engrane clave sin cambios.

En este caso, Claude primero preparó un plan y luego llamó a Fusion 360 para ejecutar operaciones de modelado. Por ejemplo, al detectar un conflicto entre los agujeros de tornillo originales y el agujero central, movió los agujeros ligeramente hacia afuera para no destruir el espacio de instalación del rodamiento.

Después de la modificación, conviene revisar el modelo:

si el asiento central del rodamiento quedó bien formado;
si los agujeros alrededor conservan su función;
si la estructura del engranaje fue dañada por error;
si los chaflanes afectan el ensamblaje;
si existen voladizos, paredes delgadas o riesgos de slicing.

El soporte también debe modificarse

Modificar solo el engranaje no basta. El soporte original tenía un agujero para tornillo autorroscante. Si el centro del engranaje pasa a usar rodamiento, el soporte también debe adaptarse a una estructura de eje para el rodamiento.

Puedes pedirle a Claude una modificación similar en el soporte:

conservar la posición general de montaje;
convertir el agujero autorroscante original en un eje cilíndrico;
controlar diámetro y altura del eje;
reservar espacio para la rotación del rodamiento;
evitar interferencia con otras partes del soporte.

Después de imprimir, el engranaje puede presionarse en el rodamiento y el soporte puede proporcionar el nuevo centro de rotación. El resultado final convierte una estructura fijada con tornillo en una estructura de rotación con rodamiento más suave.

Exportar, laminar e imprimir para verificar

Después de modificar el CAD, todavía hay que pasar por el proceso real de fabricación:

Exportar el modelo modificado desde Fusion 360.
Importarlo en el slicer.
Revisar agujeros, paredes delgadas, voladizos y soportes.
Imprimir el engranaje y el soporte.
Presionar el rodamiento en su lugar.
Comprobar si la rotación es suave.

Los resultados CAD modificados por AI no deben juzgarse solo por si el modelo se ve bien en pantalla. Hay que verificarlos imprimiendo. En estructuras mecánicas como rodamientos, agujeros, clips y engranajes, un error de 0,1mm puede decidir si la pieza encaja y gira bien.

Sugerencias de uso

Claude + Fusion 360 encaja bien en tareas como:

hacer modificaciones locales en modelos STEP existentes;
ajustar agujeros, chaflanes, soportes y asientos de montaje;
convertir estructuras fijadas con tornillo en estructuras con rodamiento, clip o pasador;
corregir tolerancias para modelos impresos en 3D;
generar rápidamente varias versiones revisadas.

Pero no conviene usarlo para producir piezas finales sin revisión. Un flujo más confiable sería:

La persona define el objetivo de ensamblaje y el proceso/material.
Claude analiza la estructura y propone cambios.
Claude llama a Fusion para ejecutar el modelado.
La persona revisa dimensiones clave e interferencias.
Se imprime una muestra pequeña.
Se itera según el resultado físico.

Resumen

El valor de conectar Claude a Fusion 360 no está en reemplazar los fundamentos de CAD, sino en acelerar las modificaciones locales de modelos existentes.

Si explicas claramente el objetivo, material, dimensiones, tolerancia y método de ensamblaje, Claude puede ayudarte a leer el modelo, encontrar interferencias, modificar estructuras, añadir chaflanes y llevar el modelo hacia un estado imprimible. Para impresión 3D, modificación de piezas mecánicas open source e iteración en pequeños talleres personales, este workflow de AI CAD ya es práctico.

goose: un agente de IA open source con escritorio, CLI y API

Fri, 08 May 2026 13:41:15 +0800

goose es un agente de IA open source que corre en tu propia máquina. No se limita a completar código; busca cubrir código, investigación, escritura, automatización, análisis de datos y otros trabajos. El README lo presenta como aplicación de escritorio, CLI y API para usuarios normales y flujos personalizados.

El proyecto pasó de block/goose a la Agentic AI Foundation (AAIF), dentro de Linux Foundation. El repositorio actual es:

`1`	`https://github.com/aaif-goose/goose`

goose está escrito principalmente en Rust y TypeScript, con licencia Apache-2.0. Su descripción en GitHub dice que es un agente de IA extensible que va más allá de sugerencias de código: puede instalar, ejecutar, editar y probar con cualquier LLM.

Qué problema resuelve

Muchas herramientas de programación con IA se centran en sugerencias o cambios locales. goose apunta a algo más amplio: permitir que un agente de IA complete tareas directamente en tu máquina.

Puede servir para:

Cambios de código y pruebas.
Automatización local.
Investigación y escritura.
Análisis de datos.
Flujos multi-paso.
Integración mediante API.
Extensión mediante MCP.

Si solo necesitas autocompletado en el IDE, una herramienta tipo Copilot puede bastar. goose es más útil cuando quieres IA dentro de la cadena local de ejecución de tareas.

Escritorio, CLI y API

La aplicación de escritorio soporta macOS, Linux y Windows.

La CLI encaja con flujos de terminal y automatización local.

La API permite insertar goose como runtime de agente en otros sistemas o herramientas internas.

Para uso personal, empieza por escritorio o CLI. Para equipos, conviene revisar también la API y las distribuciones personalizadas.

Instalación

Aplicación de escritorio:

`1`	`https://goose-docs.ai/docs/getting-started/installation`

CLI:

`1`	`curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh \| bash`

GitHub Releases ofrece builds para varias plataformas. La versión latest consultada fue v1.33.1, publicada el 2026-04-29, con assets para macOS, Linux, Windows, deb, rpm y Flatpak.

Después de instalar, configura un proveedor siguiendo el Quickstart oficial y prueba primero en un directorio de bajo riesgo.

Proveedores

goose admite más de 15 proveedores, entre ellos Anthropic, OpenAI, Google, Ollama, OpenRouter, Azure, Bedrock y otros proveedores cloud o compatibles con OpenAI.

Puede usar API keys y también suscripciones existentes de Claude, ChatGPT o Gemini mediante ACP.

ACP es relevante porque muchos usuarios ya tienen suscripciones, pero no todas las herramientas las reutilizan bien. goose las integra en un flujo de agente. Aun así, verifica siempre términos del proveedor, cuotas y políticas para código corporativo o datos sensibles.

Extensiones MCP

goose soporta extensiones Model Context Protocol. El README menciona más de 70 extensiones.

MCP permite conectar el agente con documentación, bases de datos, navegadores, sistemas internos, búsqueda, herramientas de diseño o gestión de proyectos mediante interfaces estándar.

Para equipos, MCP puede ser una capa de integración más segura que exponer todos los sistemas directamente al modelo.

Diferencia frente a un asistente de código

goose no es solo autocompletado. Es más bien un runtime local de agente.

Los asistentes comunes se enfocan en completar, explicar, generar funciones y editar en el IDE. goose se centra en ejecución local de tareas, flujos multi-paso, proveedores intercambiables, extensiones, escritorio y CLI, API embebible y tareas que no son solo código.

Eso también implica más complejidad: configuración de modelos, permisos, extensiones, workspace, logs y credenciales.

Distribuciones personalizadas

CUSTOM_DISTROS.md explica cómo construir una distribución de goose con proveedores, extensiones y branding preconfigurados.

Un equipo puede predefinir proveedores permitidos, conectar servidores MCP internos, configurar seguridad y logs, bloquear servicios externos y aplicar onboarding propio.

Recomendaciones

Instala la app de escritorio o CLI.
Configura un proveedor conocido.
Ejecuta tareas simples en un directorio de prueba.
Observa qué archivos lee y qué acciones ejecuta.
Añade extensiones MCP.
Prueba repositorios complejos después.

Haz commit antes de cambios importantes, no guardes API keys en archivos del proyecto, limita los modos de alto permiso a workspaces confiables y revisa la política de datos antes de usar código de empresa.

Resumen

goose es un agente de IA open source bajo AAIF/Linux Foundation. Ofrece escritorio, CLI y API, soporta más de 15 proveedores, acceso a suscripciones vía ACP y más de 70 extensiones MCP.

Su valor no es solo escribir código, sino unir modelos, herramientas, extensiones y ejecución local dentro de un mismo marco de agente.

Referencias

CC Switch: una herramienta de escritorio para gestionar Claude Code, Codex, Gemini CLI y OpenClaw en un solo lugar

Wed, 06 May 2026 09:03:08 +0800

CC Switch es una herramienta de gestión de escritorio para usuarios intensivos de programación con IA. El problema que intenta resolver es directo: muchas personas ahora usan Claude Code, Codex, Gemini CLI, OpenCode y OpenClaw al mismo tiempo, pero cada herramienta tiene su propio formato de configuración, sintaxis de Provider, configuración MCP y forma de gestionar Skills.

Cuando solo usas una herramienta, editar archivos de configuración manualmente todavía es tolerable. Una vez que se mezclan varias herramientas, además de cuentas oficiales, APIs de terceros, servicios relay, modelos locales y configuración compartida de equipo, editar JSON, TOML y archivos .env a mano se vuelve tedioso rápidamente.

CC Switch se posiciona como una forma de reunir estas configuraciones dispersas en una sola app de escritorio multiplataforma.

Qué problema resuelve

Las herramientas modernas de programación con IA se sienten cada vez más como “colegas de desarrollo dentro de la línea de comandos”, pero sus ecosistemas aún no están completamente unificados.

Los puntos de dolor comunes incluyen:

Claude Code, Codex, Gemini CLI, OpenCode y OpenClaw usan formatos de configuración distintos.
Cambiar API Providers requiere editar repetidamente archivos de configuración.
Los servidores MCP se configuran una y otra vez en distintas herramientas.
Archivos de prompt como CLAUDE.md, AGENTS.md y GEMINI.md son difíciles de mantener de forma consistente.
Instalación, sincronización, respaldo y eliminación de Skills carecen de una entrada central.
Cambiar entre múltiples cuentas, relays y servicios de modelos puede volverse confuso fácilmente.
Cuando un archivo de configuración editado a mano se rompe, depurarlo cuesta tiempo.

La idea detrás de CC Switch es dejar de obligar a los usuarios a recordar los detalles de configuración de cada herramienta, y usar una interfaz unificada para gestionar Providers, MCP, Prompts, Skills, Sessions y proxies.

Herramientas soportadas

El README enumera cinco objetivos principales soportados:

Claude Code
Codex
Gemini CLI
OpenCode
OpenClaw

Estas herramientas son similares en posicionamiento: todas se centran en programación con IA, flujos Agent y colaboración por línea de comandos. Pero sus sistemas de configuración difieren, y el valor de CC Switch está en envolver esas diferencias.

Para quienes comparan con frecuencia distintas herramientas de programación con IA, esto es mucho más fácil que abrir manualmente archivos de configuración cada vez.

Gestión de Providers

La primera capa de CC Switch es la gestión de Providers.

Incluye más de 50 presets de Provider. El README menciona direcciones como AWS Bedrock, NVIDIA NIM y varios relays comunitarios. Los usuarios pueden copiar una API key, importarla con un clic y luego cambiar desde la interfaz.

Los puntos prácticos incluyen:

Añadir Providers con un clic.
Reordenar Providers arrastrando.
Cambiar rápidamente desde la bandeja del sistema.
Importar y exportar Providers.
Sincronizar algunos Providers comunes entre varias apps.

Para muchas personas, esta función por sí sola ya es atractiva. En el trabajo diario de programación con IA, el problema muchas veces no es “no sé usar el modelo”, sino “qué herramienta, endpoint y cuenta debería usar hoy esta key”.

Proxy local y failover

Además de escribir archivos de configuración, CC Switch también proporciona un modo de proxy local.

El foco de esta capacidad es:

Cambio en caliente de Providers.
Conversión de formatos.
Failover automático.
Circuit breakers.
Health checks de Providers.
Corrección de solicitudes.

En términos simples, no solo escribe configuración en herramientas objetivo. También puede añadir una capa de proxy local en el medio, para que distintas herramientas accedan a servicios de modelos mediante el proxy.

Esto es útil para usuarios con múltiples Providers: si un servicio cae, cambiar a otro; si un modelo es caro, pasar a uno más barato; si el formato de solicitud es incompatible, adaptarlo mediante la capa de proxy.

MCP, Prompts y Skills

La segunda capa importante de CC Switch es la gestión unificada de MCP, Prompts y Skills.

MCP

Proporciona un panel MCP unificado para gestionar servidores MCP entre varias apps, con soporte para sincronización bidireccional e importación mediante Deep Link.

Esto es práctico para usuarios que ya trabajan con MCP. Cuando hay muchos servidores MCP, la configuración se dispersa fácilmente entre distintos clientes. Un panel unificado reduce la configuración duplicada y facilita la migración.

Prompts

La sección Prompts soporta edición Markdown y puede sincronizar archivos correspondientes entre distintas herramientas, como:

CLAUDE.md
AGENTS.md
GEMINI.md

Estos archivos son esencialmente manuales de proyecto para Agents. La gestión unificada facilita mantener reglas de equipo, convenciones de proyecto y prompts globales.

Skills

Las Skills pueden instalarse con un clic desde repositorios GitHub o archivos ZIP. También se soportan gestión de repositorios personalizados, enlaces simbólicos y copia de archivos.

Si usas herramientas como Claude Code, Codex y OpenClaw al mismo tiempo, las Skills pueden convertirse fácilmente en archivos dispersos por distintos directorios. CC Switch las centraliza y reduce el costo de mantenimiento.

Sesiones y workspace

El README también menciona funciones de Session Manager y Workspace.

Puede explorar, buscar y restaurar historial de sesiones de varias apps. Para personas que usan herramientas de programación con IA durante mucho tiempo, la gestión de sesiones es realmente importante: muchos contextos valiosos, rastros de depuración y comparaciones de soluciones quedan enterrados en conversaciones antiguas.

También proporciona un editor de Workspace para OpenClaw, permitiendo editar archivos de agente como AGENTS.md y SOUL.md con vista previa Markdown.

Esto muestra que CC Switch no es solo una pequeña utilidad para “cambiar keys”. Se está expandiendo hacia una estación de trabajo para AI Agent.

Sincronización en la nube y almacenamiento de datos

CC Switch soporta sincronizar datos de Providers mediante Dropbox, OneDrive, iCloud, NAS o WebDAV.

El almacenamiento local de datos también está claramente definido:

Base de datos: ~/.cc-switch/cc-switch.db
Configuración local: ~/.cc-switch/settings.json
Copias automáticas: ~/.cc-switch/backups/
Skills: ~/.cc-switch/skills/
Copias de Skills: ~/.cc-switch/skill-backups/

Usa SQLite como fuente principal de datos y enfatiza escrituras atómicas y copias automáticas, con el objetivo de evitar corrupción de archivos de configuración durante cambios o escrituras.

Este diseño importa para usuarios intensivos. Si la herramienta de gestión de configuración escribe una mala configuración, todas las herramientas de programación con IA pueden verse afectadas.

Instalación

CC Switch es una app de escritorio multiplataforma construida sobre Tauri 2.

Los requisitos aproximados del sistema son:

Windows: Windows 10 o posterior
macOS: macOS 12 Monterey o posterior
Linux: Ubuntu 22.04+, Debian 11+, Fedora 34+ y otras distribuciones principales

Los usuarios de Windows pueden descargar el instalador .msi o un paquete comprimido portable.

Los usuarios de macOS pueden instalarlo con Homebrew:

1
2

brew tap farion1231/ccswitch
brew install --cask cc-switch

Para actualizar:

`1`	`brew upgrade --cask cc-switch`

Los usuarios de Linux pueden elegir .deb, .rpm o AppImage. Los usuarios de Arch Linux también pueden instalarlo con paru -S cc-switch-bin.

Al 6 de mayo de 2026, la página del repositorio muestra la última release como CC Switch v3.14.1, publicada el 23 de abril de 2026.

Stack técnico

Por la estructura del repositorio, CC Switch es una app de escritorio Tauri típica:

Frontend: React 18, TypeScript, Vite, TailwindCSS, TanStack Query, shadcn/ui
Backend: Tauri 2, Rust, SQLite, Tokio
Testing: Vitest, MSW, Testing Library

Los patrones de diseño principales incluyen:

SQLite como Single Source of Truth.
JSON para configuración local a nivel de dispositivo.
Escritura en la configuración viva de herramientas objetivo durante el cambio.
Rellenar ediciones del Provider actual desde la configuración viva.
Escrituras atómicas usando archivos temporales más rename.
Conexiones de base de datos bloqueadas para evitar problemas de escritura concurrente.

Esta arquitectura sugiere que el proyecto no es un script simple, sino una herramienta de escritorio diseñada para uso de largo plazo.

Para quién es

CC Switch encaja con estos usuarios:

Personas que usan Claude Code, Codex, Gemini CLI, OpenCode y OpenClaw juntas.
Personas que cambian con frecuencia entre cuentas oficiales, relays de terceros, modelos locales o Providers de equipo.
Usuarios que ya usan MCP intensivamente.
Equipos que quieren mantener CLAUDE.md, AGENTS.md y GEMINI.md en un solo lugar.
Usuarios que instalan, prueban y migran Skills con frecuencia.
Personas que quieren ver historial de sesiones y uso entre distintas herramientas.

Si solo usas una herramienta de programación con IA, dependes del login oficial y rara vez tocas Providers, MCP o Skills, su valor puede no ser evidente.

Pero si ya entraste en un estado de “muchas herramientas, muchas cuentas, muchos Providers, muchos proyectos”, puede eliminar mucho trabajo repetitivo de configuración.

Qué vigilar

Herramientas como esta son cómodas, pero también necesitan límites claros.

Primero, gestiona configuración para múltiples AI CLIs, así que los usuarios deben asegurarse de confiar en la herramienta y su lógica de escritura.

Segundo, API keys, endpoints relay y servidores MCP son configuración sensible. Antes de activar sincronización en la nube, asegúrate de que la carpeta de sincronización y el servicio WebDAV sean seguros y confiables.

Tercero, después de cambiar Providers, la mayoría de herramientas todavía necesitan reiniciar la terminal o CLI para que los cambios surtan efecto. El README menciona que Claude Code soporta cambio en caliente de datos de Provider, pero otras herramientas normalmente aún requieren reinicio.

Cuarto, al volver al login oficial, es mejor añadir el provider oficial según las instrucciones del proyecto y luego volver a ejecutar el flujo de login de la herramienta correspondiente.

Resumen

El valor de CC Switch no está en crear otra herramienta de programación con IA. Su valor está en reconocer una realidad: el ecosistema de AI coding entró en una etapa donde coexisten múltiples herramientas.

Claude Code, Codex, Gemini CLI, OpenCode y OpenClaw tienen cada una sus propios sistemas de configuración, mientras MCP, Skills, Prompts y Providers se expanden rápidamente. Seguir editando archivos de configuración a mano terminará convirtiéndose en una carga.

CC Switch reúne estas piezas en una app de escritorio, facilitando cambiar Providers, sincronizar MCP, gestionar Skills, mantener archivos de prompt y ver sesiones. Para usuarios intensivos de programación con IA, herramientas como esta pueden pasar de “utilidad opcional” a “infraestructura diaria”.

Referencias

farion1231/cc-switch

Guía inicial de Codex App: instalación, sandbox, tareas paralelas, Skills y MCP

Wed, 06 May 2026 08:41:17 +0800

Codex App puede entenderse como un espacio de trabajo de tareas para programación con IA. No es un IDE tradicional ni solo una ventana de chat. Reúne multitarea, gestión de proyectos, permisos de sandbox, Git, ejecución en la nube, plugins, Skills, MCP y automatización en una sola interfaz.

Si ya usas Codex CLI, Claude Code, Cursor u otros coding agents, la parte más interesante de Codex App es que convierte “ejecutar varios agentes en paralelo” en un flujo de escritorio más claro.

Para qué sirve Codex App

El valor central de Codex App no es responder preguntas, sino permitir que la IA ejecute tareas de forma continua dentro de un directorio de proyecto:

Editar código, ejecutar comandos e iniciar servidores de desarrollo.
Gestionar múltiples proyectos y múltiples tareas.
Ejecutar tareas largas localmente o en la nube.
Llamar plugins, Skills y MCP para ampliar capacidades.
Gestionar cambios mediante Git, worktree y flujos PR.

OpenAI también posiciona Codex App como una interfaz para gestionar múltiples coding agents. Es adecuada para personas que necesitan avanzar varias tareas de programación a la vez, especialmente páginas frontend, scripts, apps pequeñas, documentación y flujos de automatización.

Preparación antes de instalar

Antes de usar Codex App, conviene preparar tres herramientas básicas:

Git
Node.js
VS Code o tu IDE preferido

Codex App soporta macOS y Windows. Después de instalar, inicia sesión con tu cuenta de ChatGPT. En el primer lanzamiento, puedes elegir tu escenario principal de uso, como programación o trabajo diario. Codex precargará algunos plugins y Skills según tus elecciones, y luego puedes ajustarlos en configuración y en el marketplace de plugins.

Las funciones principales en Windows y macOS son bastante parecidas, pero algunas capacidades de automatización del ordenador pueden depender de la plataforma y del soporte de plugins. Usa lo que tu versión actual muestre realmente.

Estructura de interfaz: proyectos, tareas y chats

Codex App usa un diseño clásico de tres columnas:

Izquierda: proyectos, tareas, historial de chats, plugins y entradas de automatización.
Centro: ventana de chat actual.
Derecha: archivos, navegador, terminal, resultados de ejecución y otros paneles.

Un proyecto normalmente corresponde a una carpeta local. Puedes abrir varios chats dentro del mismo proyecto, o abrir varios proyectos a la vez para que distintos agentes trabajen en paralelo.

La lista de tareas muestra distintos estados:

Running: el agente sigue ejecutando.
Waiting for approval: debes confirmar permisos, red, instalación de dependencias o una acción de alto riesgo.
Completed: la tarea terminó, y puedes inspeccionar el resultado o seguir preguntando.

Esto es más intuitivo que cambiar entre varias ventanas de terminal, y se adapta mejor a gestionar varias tareas de IA a la vez.

Sandbox y control de permisos

El sistema de permisos de Codex App se construye alrededor del sandbox. Por defecto, la carpeta actual del proyecto se convierte en el workspace principal del agente.

Los límites de permisos comunes incluyen:

Puede leer y modificar archivos dentro del directorio del proyecto.
Por defecto no puede modificar libremente archivos fuera del proyecto.
La red o comandos de alto riesgo están restringidos por defecto.
Cuando necesita acceso elevado, pide aprobación al usuario.

Un modo práctico es “auto review”: las acciones de bajo riesgo se permiten automáticamente, mientras que las acciones de alto riesgo siguen siendo confirmadas por el usuario. Esto reduce ventanas emergentes frecuentes y evita que operaciones peligrosas ocurran en silencio.

“Full access” debe habilitarse con cautela. Es adecuado cuando sabes exactamente qué necesita hacer el agente, el proyecto ya tiene respaldos Git y los archivos importantes tienen copias separadas. No se recomienda como valor diario permanente.

Contexto, modelos y cuotas

Codex App muestra el uso de contexto del chat actual. Cuanto más larga es la conversación y más historial contiene, más contexto necesita procesar el modelo.

Hábitos útiles:

Empezar un chat nuevo después de terminar una tarea.
Los chats largos pueden comprimirse manualmente, pero no trates la compresión como memoria perfecta.
Para tareas complejas, declara claramente objetivos, límites y criterios de aceptación.
No pegues de golpe logs, errores o archivos grandes e irrelevantes en un chat.

Para selección de modelos, ajusta la fuerza de razonamiento según la complejidad de la tarea. Ediciones simples, escritura y tareas repetitivas no siempre necesitan el modelo más fuerte. Migraciones de arquitectura, bugs difíciles y refactors entre archivos encajan mejor con modelos más potentes.

Si la interfaz tiene un modo rápido, recuerda que normalmente consume más cuota. Úsalo cuando la velocidad importe, pero no como valor diario predeterminado.

Generación de imágenes y entradas multimodales

Codex App puede aceptar imágenes y archivos como contexto, y puede llamar generación de imágenes en escenarios adecuados.

Esto es útil para proyectos frontend y de contenido. Por ejemplo, puedes pedir a Codex:

Corregir estilos de página según capturas.
Reemplazar imágenes inadecuadas en una web.
Generar imágenes de producto, imágenes de carrusel o assets de página.
Señalar qué debe cambiarse a partir de una captura de UI.

Un enfoque más eficiente no es decir solo “hazlo más bonito”, sino usar capturas y señalar problemas concretos, como “el espacio en esta tarjeta es demasiado grande”, “esta imagen no coincide con la escena del servicio” o “haz más clara el área del mapa”.

Steer: corregir dirección durante la ejecución

Steer puede entenderse como tomar control de la dirección durante la ejecución. Si el agente ya empezó pero notas que entendió mal, no siempre conviene esperar a que termine para corregirlo.

Puedes usar steering para insertar una nueva instrucción en el flujo de ejecución actual y hacer que Codex corrija el rumbo.

Buenos casos de uso para Steer incluyen:

El agente entendió mal el requisito.
El estilo de página generado es claramente incorrecto.
El plan actual es demasiado costoso o pesado.
Necesitas añadir una restricción clave temporalmente.

En general, mantén el comportamiento predeterminado en cola y usa Steer manualmente solo cuando se necesite intervención. Esto evita interrumpir tareas normales y aun así permite recuperar la dirección en momentos clave.

Modo plan y navegador integrado

Para tareas complejas, empieza con modo plan. En modo plan, Codex no modifica código de inmediato. Primero produce un plan y puede hacer preguntas clave con tarjetas.

Tareas adecuadas para modo plan incluyen:

Migración de frameworks, como pasar un proyecto React a Next.js.
Refactors grandes.
Funciones que involucran bases de datos, autenticación o despliegue.
Requisitos donde aún no has decidido la ruta técnica.

El panel derecho de Codex App puede abrir un navegador integrado para previsualizar el servidor local de desarrollo. Puedes anotar la página y dejar que Codex modifique una ubicación específica de UI. Este flujo de “mirar la página, hacer clic en la posición y pedir a la IA que la cambie” suele ser mejor para depuración frontend que descripciones puramente textuales.

Git, IDE y rollback de código

Codex App no es un IDE completo. Puede ver código y añadir anotaciones, pero la edición manual sigue siendo mejor en VS Code, Cursor, Windsurf u otro IDE.

Todo proyecto de Codex debería inicializar Git temprano:

Pedir a Codex que cree o revise .gitignore.
Hacer un commit al llegar a un estado usable.
Asegurar un punto de commit limpio antes de cada cambio grande.
Volver atrás con Git si no estás satisfecho.

Si haces rollback solo del historial de chat, el código no vuelve automáticamente. Un enfoque más seguro es devolver el chat al punto correcto y luego usar un hash de commit Git para devolver el código al estado correspondiente.

Worktree: desarrollo paralelo en varias direcciones

git worktree es especialmente adecuado para agentes paralelos en Codex App.

Crea varios directorios de trabajo independientes desde el mismo repositorio, cada uno correspondiente a una rama distinta. Esto permite que diferentes agentes trabajen en distintas carpetas al mismo tiempo sin sobrescribirse.

Uso típico:

Un worktree optimiza el componente de reseñas de clientes.
Un worktree ajusta información de tienda y diseño del mapa.
Fusionar ambas tareas de vuelta a main tras completarlas.
Eliminar worktrees temporales después de fusionar.

Esto es mucho más seguro que dejar que varios agentes modifiquen código en el mismo directorio. Si hay conflictos, revísalos y fusiónalos con flujos Git normales.

Entorno de ejecución en la nube

Codex puede trabajar no solo en tu máquina local, sino también en un entorno de nube.

La ejecución en la nube es adecuada cuando:

Estás fuera y solo tienes un teléfono.
Quieres que los agentes ejecuten tareas largas en segundo plano.
El código ya se sincronizó con GitHub y Codex necesita modificar el repositorio remoto.
Quieres revisar y fusionar cambios mediante PRs.

Un flujo típico es: subir el código local a GitHub, dejar que Codex descargue el repositorio en un entorno de nube, ejecutar la tarea, generar cambios y presentarlos como PR o diff para revisión.

Al continuar el desarrollo local, recuerda traer los últimos cambios remotos.

Sistema de memoria: escribe un buen AGENTS.md

Los chats nuevos no tienen memoria histórica completa por defecto. Una vez que un proyecto se vuelve complejo, explicar el contexto repetidamente es ineficiente.

La solución más general es mantener AGENTS.md en la raíz del proyecto. Este archivo puede registrar:

Objetivos del proyecto y stack principal.
Comandos comunes.
Estructura de directorios.
Estilo de código y convenciones de nombres.
Acciones prohibidas, como borrar archivos en masa.
Reglas de pruebas, build y despliegue.

También puedes pedir a Codex que lea el proyecto y genere una primera versión de AGENTS.md, luego revisarla manualmente. Para proyectos complejos, vale la pena mantener este archivo.

Las reglas globales deben usarse con cuidado. Son adecuadas para restricciones universales de seguridad, como “no borrar directorios recursivamente” o “confirmar antes de operaciones destructivas”. No pongas detalles específicos del proyecto en reglas globales, o contaminarán otros proyectos.

Plugins y automatizaciones

Los plugins conectan Codex con servicios externos como GitHub, Gmail, Google Drive, bases de datos y plataformas de despliegue.

Su valor está en reducir copiar y pegar. Por ejemplo, Codex puede:

Revisar tendencias de estrellas de un repositorio GitHub.
Resumir contenido de email y enviártelo.
Ejecutar una revisión recurrente.
Escribir el resultado como resumen.

Las automatizaciones son adecuadas para tareas repetidas. Por ejemplo, revisar datos de un repositorio todos los viernes por la tarde y enviar un informe por email. Las tareas simples de automatización normalmente no requieren el modelo más fuerte; basta un modelo más ligero.

Skills: convertir flujos de trabajo en capacidades reutilizables

Las Skills son “manuales profesionales” para Codex. No son prompts de una sola vez. Empaquetan un flujo de tarea, reglas, scripts y notas para que Codex pueda reutilizarlos de forma fiable después.

Fuentes comunes incluyen:

Skills oficiales.
Skills de terceros.
Skills escritas por ti.

Buenos candidatos para Skills incluyen:

Convertir subtítulos en notas ilustradas.
Escribir informes semanales con formato de empresa.
Procesar imágenes o documentos por lotes.
Revisiones de código con formato fijo.
Inicialización de proyectos para un framework concreto.

Si has copiado y pegado el mismo prompt muchas veces, vale la pena convertirlo en una Skill.

MCP: conectar herramientas externas y bases de datos

MCP puede entenderse como un protocolo estandarizado de herramientas para modelos grandes. Mediante MCP, Codex puede llamar servicios externos para completar tareas más concretas.

Por ejemplo, después de conectar Supabase, Codex puede:

Crear tablas de base de datos.
Leer esquemas de base de datos.
Modificar endpoints backend.
Enviar formularios frontend a la base de datos.
Depurar problemas según el estado de la base de datos.

Esto es poderoso, pero los permisos importan. Bases de datos, entornos de producción, plataformas de despliegue y cuentas de email son recursos de alto riesgo. Al conectarlos por primera vez, usa un proyecto de prueba y una cuenta con pocos privilegios.

Plugins de despliegue

Los plugins de plataformas de despliegue pueden permitir que Codex complete builds y releases directamente, como desplegar un proyecto frontend en Netlify.

Estos plugins son adecuados para sitios pequeños, prototipos, herramientas internas y demos. En uso real, presta atención a:

Ejecutar un build local antes del despliegue.
No escribir variables de entorno directamente en el código.
Comprobar que la página abre normalmente después de publicar.
Mantener revisión humana para proyectos de producción.

La IA puede ayudar a conectar el flujo de despliegue, pero los permisos de despliegue deben gestionarse con cuidado.

Automatización del ordenador

Con plataformas y entornos de plugins soportados, Codex también puede operar navegadores o apps de escritorio, completando tareas más cercanas a RPA.

Ejemplos:

Abrir una app de chat y preparar un mensaje.
Navegar un tablero de proyecto y resumir estado de tareas.
Generar un brief en inglés.
Enviarlo a un destinatario especificado después de tu confirmación.
Convertir el flujo en una automatización programada.

Estas capacidades son imaginativas, pero requieren los límites de seguridad más fuertes. Cualquier operación que implique enviar mensajes, enviar email, enviar formularios, pagos o eliminar datos debe conservar confirmación humana.

Sugerencias de uso

La forma correcta de usar Codex App no es dejarle tomar todo de golpe, sino dividir tareas y permitir que ejecute eficientemente en un entorno controlado.

Hábitos recomendados:

Inicializar Git en cada proyecto.
Usar modo plan para tareas complejas.
Usar worktree para tareas paralelas.
Poner reglas de proyecto en AGENTS.md.
Mantener confirmación humana para acciones de alto riesgo.
Convertir flujos repetidos en Skills o automatizaciones.
Validar plugins y MCP primero en un entorno de prueba.

Referencias

Resumen

Codex App no es “otra ventana de chat con IA”. Su foco es convertir la programación con IA en un espacio de trabajo gestionable, donde proyectos locales, tareas en la nube, Git, worktree, plugins, Skills, MCP y automatización puedan conectarse.

La clave para usarla bien es equilibrar libertad y control. Las tareas pequeñas pueden entregarse a Codex con confianza. Las tareas complejas deben empezar con un plan. Las acciones de alto riesgo deben confirmarse. Usada así, Codex puede convertirse no solo en un asistente que escribe código, sino en una herramienta de ingeniería de largo plazo.

Claude for Creative Work: Anthropic lleva Claude a Adobe, Blender, Ableton y SketchUp

Fri, 01 May 2026 05:52:14 +0800

Anthropic lanzó Claude for Creative Work el 28 de abril de 2026. El punto no es otro chatbot nuevo, sino llevar Claude al software que las industrias creativas ya usan.

La lista de socios es muy representativa: Blender, Autodesk, Adobe, Ableton y Splice, junto con ecosistemas como Affinity by Canva, Resolume y SketchUp.

En pocas palabras, Anthropic quiere que Claude no solo dé consejos en una ventana de chat, sino que entre en flujos concretos de diseño, 3D, música, vídeo y visuales en vivo.

Claude no reemplaza el gusto, pero sí mucho trabajo repetitivo

Anthropic mantiene un tono prudente: Claude no reemplaza el gusto ni la imaginación de los creadores.

Ese juicio es correcto. En el trabajo creativo, lo difícil muchas veces no es “generar algo”, sino decidir qué dirección vale la pena, qué detalles conservar y qué propuesta encaja con el carácter del proyecto.

Pero los flujos creativos también contienen mucha labor repetitiva:

redimensionar imágenes por lotes;
renombrar capas;
exportar archivos en distintos formatos;
ordenar recursos;
buscar documentación del software;
escribir scripts para modificar escenas;
convertir formatos entre herramientas;
convertir una idea en un borrador visible rápidamente.

Estas tareas no siempre requieren inspiración, pero consumen tiempo. El papel de Claude se parece más a liberar al creador de esos pasos mecánicos.

Los connectors son el centro del lanzamiento

La clave del lanzamiento son los connectors.

Un connector es un puente entre Claude y plataformas o software externos. En lugar de copiar una petición a Claude y volver manualmente al software para actuar, el usuario puede dejar que Claude entienda la herramienta, invoque capacidades o lea documentación relevante.

Anthropic menciona conexiones como:

Ableton: Claude responde preguntas a partir de documentación oficial de Live y Push.
Adobe for creativity: conexión con más de 50 herramientas de Creative Cloud, incluidas Photoshop, Premiere y Express.
Affinity by Canva: automatización de tareas repetitivas como ajustes por lote, renombrado de capas y exportación.
Autodesk Fusion: creación y modificación de modelos 3D por conversación.
Blender: uso de la API Python de Blender mediante lenguaje natural.
Resolume Arena y Resolume Wire: control en tiempo real para VJs y artistas visuales.
SketchUp: convertir una conversación en punto de partida para modelado 3D.
Splice: búsqueda de samples royalty-free directamente desde Claude.

Estas integraciones cubren diseño, audio, 3D, vídeo, performance en vivo y modelado de ingeniería. No es un experimento pequeño; muestra que Anthropic quiere avanzar hacia una especie de banco de trabajo creativo.

Qué aporta al trabajo creativo

Los usos se pueden agrupar en varias categorías.

La primera es aprender herramientas complejas. Blender, Ableton, Fusion y Premiere son potentes, pero tienen curvas de aprendizaje pronunciadas. Claude puede explicar un modifier stack, una técnica de composición o una función desconocida sin que el usuario salte entre buscadores, foros y documentación.

La segunda es escribir scripts y plugins. El software creativo tiene mucho espacio para automatización. Claude Code puede ayudar con scripts, plugins, shaders, animación procedural o modelos paramétricos.

La tercera es conectar cadenas de herramientas. Un proyecto real rara vez vive en una sola aplicación: diseño en Adobe, 3D en Blender o SketchUp, audio en Ableton, recursos desde Splice y salida final hacia vídeo o sistemas de performance. Claude puede ayudar con conversión de formatos, reorganización de datos y sincronización de recursos.

La cuarta es exploración rápida. Anthropic también mencionó Claude Design, un producto de Anthropic Labs para explorar ideas de experiencia de software. Puede iterar propuestas visuales con feedback y exportar resultados a otras herramientas, empezando por Canva.

La quinta es reducir producción repetitiva: procesar recursos por lotes, crear estructuras de proyecto, modificar objetos de escena o automatizar exportaciones. Muchos creadores saben hacerlo, pero no quieren pasar una tarde repitiendo clics.

Blender es la pieza más interesante

Blender ocupa un lugar especial en este anuncio.

Blender es una suite 3D libre y de código abierto usada en juegos independientes, motion graphics, visualización arquitectónica, cine y más. Ya tiene una API Python potente y muchos flujos complejos.

Los desarrolladores de Blender crearon un connector MCP que ahora puede usarse oficialmente en Claude. Puede:

analizar y depurar una escena completa;
modificar objetos de una escena en lote;
escribir scripts personalizados con la API Python de Blender;
añadir herramientas directamente a la interfaz;
ayudar a entender configuraciones y documentación complejas.

Más importante aún: Anthropic se unió al Blender Development Fund como patron, apoyando el desarrollo continuo de la API Python de Blender.

Esto envía dos señales. Primero, Anthropic no solo quiere conectarse con software comercial, también apuesta por herramientas creativas open source. Segundo, el connector se basa en MCP, así que en teoría no está limitado a Claude.

No es “AI reemplazando diseñadores”; es “AI entrando en la capa de herramientas”

Lo importante no es si Claude puede generar una imagen, una canción o un modelo 3D.

El punto es que la IA se está moviendo de la caja de chat a la capa de herramientas.

Antes, muchas herramientas creativas de IA seguían este flujo:

Describir una necesidad en la herramienta de IA.
Obtener un resultado.
Descargar o copiar.
Volver al software profesional y corregir manualmente.

La nueva dirección se parece más a esto:

Claude entiende tu software creativo.
Claude lee documentación o contexto del proyecto.
Claude genera scripts, opera herramientas, organiza recursos o crea borradores.
El creador sigue juzgando y refinando dentro del software familiar.

Esto es más atractivo para profesionales porque no quieren abandonar sus cadenas actuales ni migrar todo a una nueva plataforma de IA.

Impacto en estudiantes y educación creativa

Anthropic también está colaborando con programas de arte y diseño para apoyar cursos con creative computation.

Los primeros programas incluyen:

Art and Computation en Rhode Island School of Design;
Fundamentals of AI for Creatives en Ringling College of Art and Design;
MA/MFA Computational Arts en Goldsmiths, University of London.

Estudiantes y docentes tendrán acceso a Claude y a los nuevos connectors, y su feedback ayudará a Anthropic a entender qué necesitan de verdad los creadores.

Esto es interesante porque, si la IA creativa se queda solo en “generar recursos”, se vuelve fácilmente una demo. En cursos, las preguntas importantes son otras: cómo entender los procesos detrás de las herramientas, cómo usar IA para explorar y prototipar, cómo conservar criterio propio, cómo ampliar límites creativos con código y cómo evitar que todo tenga el mismo sabor de IA.

Quién debería prestar atención

Claude for Creative Work merece atención para:

usuarios de Blender, SketchUp o Fusion para modelado 3D;
personas que usan Adobe o Affinity para diseño y vídeo;
productores que usan Ableton o Splice;
equipos que conectan varias herramientas creativas;
creadores con algo de scripting que quieren automatizar software;
docentes de creatividad, diseño interactivo o computational arts.

Si solo generas imágenes con IA de vez en cuando, quizá no cambie tu experiencia de inmediato. Pero si trabajas en software profesional y a menudo piensas “sé qué hacer, pero estos pasos son tediosos”, los connectors pueden ser valiosos.

Límites a recordar

Estas herramientas no son mágicas.

Claude sigue necesitando que el usuario juzgue estética, marca y objetivos. Al automatizar software profesional, conviene empezar con tareas pequeñas y no dejar que modifique en lote archivos difíciles de recuperar. La calidad del connector es crítica: consultar documentación y operar de verdad el software son experiencias muy distintas.

Los proyectos creativos también tienen archivos complejos, dependencias y control de versiones. Con IA en el flujo, backups y rollback son aún más importantes. Y derechos, licencias y fuentes de recursos siguen siendo responsabilidad del usuario.

Conclusión

Claude for Creative Work no es una actualización aislada. Es un paso de Anthropic para insertar Claude en el ecosistema de software creativo.

El objetivo no es convertir a Claude en creador, sino en un asistente de herramientas: consultar documentación, escribir scripts, procesar por lotes, conectar aplicaciones, generar borradores y reducir trabajo repetitivo.

El valor a largo plazo está en que Claude empiece a entrar en entornos que los creadores usan todos los días, como Blender, Adobe, Ableton y SketchUp.

Referencia:

Claude for Creative Work - Anthropic

qmd: Búsqueda de documentos de rebajas locales para agentes de IA

Fri, 01 May 2026 03:12:57 +0800

qmd es una herramienta de búsqueda de documentos Markdown locales, con los agentes AI como sus principales usuarios objetivo.

Resuelve un problema específico: cuando un proyecto contiene muchos documentos .md, los asistentes de codificación de IA a menudo no saben qué archivo leer, qué sección citar o qué instrucciones están actualizadas. grep de texto completo puede encontrar palabras clave, pero no comprende bien el significado. Poner toda la documentación en contexto desperdicia espacio en la ventana e introduce fácilmente contenido irrelevante.

La idea detrás de qmd es indexar primero los documentos de Markdown y luego devolver los fragmentos más relevantes a través de una interfaz de búsqueda para que los utilice la IA. Puede usarse como una herramienta de línea de comandos, integrarse a través de un SDK o exponerse como un servidor MCP para clientes que admiten MCP.

¿Qué problema resuelve?

Los proyectos reales suelen tener más de uno o dos archivos README.

Es posible que tengas:

Notas de arquitectura
Documentación API
Convenciones de desarrollo
Procedimientos de implementación
Registros de decisiones de arquitectura.
Notas de solución de problemas
Documentos de requisitos
Instrucciones de uso de IA
Notas y recordatorios de la cadena de herramientas.

Los humanos pueden buscar documentos a través de directorios, pero los agentes de IA necesitan un punto de entrada de recuperación claro. En caso contrario, podrán:

Leer el documento equivocado
Falta de restricciones clave
Utilice instrucciones obsoletas
Poner el contenido irrelevante en contexto.
Inventar reglas en respuestas basadas en la experiencia.

Aquí es donde “qmd” resulta útil. Convierte los documentos locales de Markdown en una fuente de conocimiento con capacidad de búsqueda, de modo que la IA puede buscar primero cuando necesita contexto y luego responder o actuar en función de fragmentos coincidentes.

Enfoque de búsqueda

El archivo README dice que “qmd” combina varios métodos de recuperación:

Búsqueda de palabras clave BM25
Búsqueda de vectores
Reclasificación de LLM

BM25 es bueno para palabras clave claras. Si busca el nombre de una función, una clave de configuración, un código de error o un nombre de archivo, suele ser directo y eficaz.

La búsqueda de vectores es mejor para cuestiones semánticas. Por ejemplo, si pregunta “¿cómo maneja este proyecto la validación de permisos?”, es posible que la documentación no contenga esa frase exacta, pero puede contener descripciones relacionadas sobre autenticación, control de acceso y comprobaciones de roles.

La reclasificación de LLM se utiliza para reordenar los resultados de los candidatos. Los dos primeros pasos encuentran contenido potencialmente relevante y luego el modelo juzga qué fragmentos coinciden mejor con la pregunta actual.

Esta combinación es más adecuada para los agentes de IA que la simple búsqueda de palabras clave, porque las preguntas de los agentes suelen ser intenciones de tareas en lugar de palabras clave fijas.

¿Por qué rebajas?

Markdown es el formato de documentación más común en proyectos de desarrollo.

Es lo suficientemente simple como para almacenarlo en Git y lo suficientemente estructurado como para incluir encabezados, listas, bloques de código, enlaces y tablas. Para la IA, Markdown también es más fácil de analizar que los archivos PDF, las instantáneas web o las capturas de pantalla.

Debido a que qmd se centra en Markdown, puede procesar la documentación del desarrollador de forma más directa:

Dividir el contenido por títulos y párrafos.
Preservar bloques de código
Preservar rutas de documentos
Devolver fragmentos adecuados para citar
Informar al Agente de qué documento proviene una respuesta.

Esto es más estable que pedirle a la IA que escanee aleatoriamente un repositorio y ahorra más contexto que poner todos los documentos en un mensaje a la vez.

Tres puntos de entrada

qmd proporciona tres puntos de entrada: CLI, SDK y servidor MCP.

1. CLI

La CLI es adecuada para uso directo de terminal y para scripts.

Puede indexar un directorio de documentación y luego buscar contenido relacionado con comandos. Para los desarrolladores, la CLI es la forma más sencilla de validar la herramienta: primero vea si puede encontrar los documentos correctos y luego considere integrarla en flujos de trabajo más complejos.

Este tipo de herramienta es útil dentro de proyectos locales. Por ejemplo, antes de cambiar el código puedes buscar documentos de diseño; antes de depurar, busque notas de solución de problemas; Antes de escribir una API, busque las convenciones de la API.

2. SDK

El SDK es adecuado para integrar qmd en sus propias herramientas.

Si está creando un asistente de desarrollo interno, un sistema de preguntas y respuestas sobre documentación, un robot de revisión de código o una base de conocimiento del proyecto, puede llamar a la capacidad de búsqueda a través del SDK en lugar de pedir a los usuarios que ejecuten comandos directamente.

El SDK brinda más control sobre:

Buscar directorios
Consultar contenido
Número de resultados devueltos
Formato de resultado
Si se deben pasar los resultados a un modelo para su resumen.

Esto se adapta a escenarios que necesitan una integración más profunda.

3. Servidor MCP

MCP es el punto de entrada más valioso para los agentes de IA.

A través del servidor MCP, los clientes que admiten MCP pueden llamar a qmd como herramienta de búsqueda de documentos. Esto permite a un agente buscar documentos de Markdown locales antes de actuar, en lugar de adivinar las reglas del proyecto.

Un flujo de trabajo típico podría ser:

El usuario le pide a la IA que modifique una función.
AI llama a “qmd” para buscar documentos de diseño relacionados
qmd devuelve los fragmentos de Markdown más relevantes
La IA modifica el código en función de esas restricciones de documentos.

Esto es más natural que pegar manualmente todas las reglas en una nueva sesión y se adapta mejor a proyectos a largo plazo.

Escenarios adecuados

qmd es adecuado para:

Proyectos con muchos documentos Markdown.
Agentes de IA que a menudo necesitan buscar reglas del proyecto.
Equipos que quieran respuestas de IA para citar documentos locales.
Documentación distribuida en varios directorios.
Reutilizar la misma capacidad de recuperación en CLI, SDK y MCP
Reducir la tendencia de los asistentes de codificación de IA a adivinar las convenciones del proyecto.
Conexión de bases de conocimientos locales a Claude Desktop, Claude Code u otros clientes MCP

Si su proyecto solo tiene un README corto, pedirle directamente a AI que lea el archivo es suficiente.

Pero si la documentación ha crecido hasta llegar a docenas o cientos de archivos, o si desea que el Agente busque documentos antes de actuar, este tipo de herramienta de indexación adquiere sentido.

Diferencia de grep

Herramientas como grep y rg son excelentes para una búsqueda exacta.

Si sabe que necesita DATABASE_URL, authMiddleware, 404 o docker compose, la búsqueda de palabras clave suele ser la más rápida.

qmd es mejor cuando no sabes las palabras exactas.

Por ejemplo, puedes preguntar:

¿Cuál es el proceso de lanzamiento de este proyecto?
¿Qué convenciones se aplican al agregar una nueva API?
¿Se documentó antes la estrategia de almacenamiento en caché?
¿Qué documentos debería leer la IA antes de cambiar el código?
¿Dónde está la base de diseño de un módulo?

Estas preguntas suelen requerir una recuperación semántica en lugar de hacer coincidir una palabra. La combinación BM25 + vector + reclasificación en qmd tiene como objetivo hacer que estas preguntas encuentren el contexto correcto más fácilmente.

Relación con RAG

qmd puede verse como un componente RAG liviano para documentos Markdown. No intenta crear un sistema completo de preguntas y respuestas para usted. Se centra en un paso: encontrar fragmentos de documentos relevantes. La forma en que se utilizan esos fragmentos posteriormente puede ser manejada por CLI, SDK, un cliente MCP o su propio flujo de trabajo del Agente.

Este posicionamiento es práctico. Muchos proyectos no necesitan un gran sistema de base de conocimientos; solo necesitan IA para buscar documentos locales con mayor precisión y rapidez, y luego devolver los resultados a la tarea actual.

Notas de uso

En primer lugar, la calidad de la documentación sigue siendo importante.

Una herramienta de recuperación sólo puede encontrar contenido existente. Si los documentos están desactualizados, duplicados o contradictorios, es posible que la IA aún reciba un contexto incorrecto. Antes de conectar qmd a un Agente, primero limpie los documentos clave.

En segundo lugar, no amplíe demasiado el alcance del índice.

Indexar cada archivo Markdown en el repositorio no siempre es mejor. La documentación de dependencia, las notas temporales y los borradores de soluciones antiguos pueden contaminar los resultados. Un mejor enfoque es definir qué directorios son fuentes de documentación confiables.

En tercer lugar, los resultados de la búsqueda deben preservar las fuentes.

Cuando la IA utiliza fragmentos de documentos, debe saber de qué archivo y sección provienen. Esto hace que la revisión humana sea rastreable y reduce el riesgo de que “esto parezca la conclusión de un documento, pero es sólo un resumen modelo”.

Cuarto, no reemplacen completamente el juicio humano.

qmd puede mejorar la calidad de la recuperación del contexto, pero no reemplaza la fuente de la verdad. Los cambios importantes aún requieren código actualizado, resultados de pruebas y los requisitos más recientes.

Equipos adecuados

Si su equipo ya ha comenzado a incluir agentes de IA en los flujos de trabajo de desarrollo diarios, herramientas como qmd pueden resultar valiosas.

Están especialmente indicados para equipos que:

Escribir mucha documentación.
Tener una larga historia de proyectos.
Necesita gente nueva e inteligencia artificial para comprender rápidamente el contexto.
Mantener registros de decisiones de arquitectura.
Tener muchos documentos de convención de Markdown.
Quiero que AI verifique las reglas antes de modificar el código.

Su objetivo no es hacer que la IA lo sepa todo. Es hacer que la IA adivine menos y busque más.

Referencia

-tobi/qmd

Pensamiento final

El valor de qmd es que convierte los documentos Markdown locales en un punto de entrada de búsqueda al que los agentes de IA pueden llamar de manera confiable.

Cuando la documentación del proyecto pasa de “instrucciones para humanos” a “una fuente de contexto que pueden buscar tanto humanos como IA”, los asistentes de codificación de IA pueden seguir las reglas del proyecto más fácilmente.

Prompt Optimizer: una herramienta de código abierto para optimización, pruebas y MCP rápidos

Fri, 01 May 2026 03:09:07 +0800

Prompt Optimizer es una herramienta de código abierto para mejorar las indicaciones. Su objetivo es sencillo: ayudarle a convertir una indicación aproximada en algo más claro, más estable y más fácil de seguir para modelos de lenguaje grandes.

No es sólo una página que “pule mi mensaje”. El proyecto proporciona optimización rápida, prueba, comparación y evaluación de resultados, acceso a múltiples modelos, manejo de imágenes rápidas e integración MCP. Para las personas que suelen escribir avisos del sistema, avisos de usuario y plantillas de flujo de trabajo de IA, se siente más como un banco de trabajo de avisos dedicado.

¿Qué problema resuelve?

Mucha gente se encuentra con problemas similares cuando utiliza la IA:

Las indicaciones son cada vez más largas, pero la calidad del resultado no mejora claramente
La misma tarea se comporta de manera diferente después de cambiar de modelo.
Las indicaciones del sistema y las indicaciones del usuario están mezcladas y son difíciles de depurar.
Después de cambiar un mensaje, no está claro si la nueva versión es mejor
Las plantillas variables son útiles, pero el reemplazo manual y las pruebas son tediosos
La optimización rápida debería estar disponible para otras herramientas de IA, pero no existe una interfaz estándar

Prompt Optimizer está diseñado en torno a estos problemas. Divide la “escripción de un mensaje” en optimización, prueba, evaluación, comparación e iteración, por lo que el ajuste del mensaje ya no se basa únicamente en la intuición.

Características principales

1. Optimice las indicaciones del sistema y las indicaciones del usuario

Hay más de un tipo de aviso.

Las indicaciones del sistema suelen definir roles, objetivos, límites, reglas de salida y métodos de trabajo. Las indicaciones del usuario están más cerca de la entrada para una tarea específica. Cuando los dos se mezclan, el modelo puede perder el punto clave y la reutilización se vuelve más difícil.

Prompt Optimizer admite tanto la optimización de los mensajes del sistema como la optimización de los mensajes del usuario. Puede mejorar las definiciones de roles reutilizables a largo plazo por separado de la entrada para una tarea específica.

Esto es útil para:

Redacción de reglas para asistentes de codificación de IA.
Diseño de roles de atención al cliente, revisor, traducción y análisis.
Optimización de mensajes de texto a imagen
Convertir requisitos temporales en plantillas reutilizables
Preparar diferentes estilos de mensajes para diferentes modelos.

2. Probar y comparar resultados

Optimizar un mensaje no es suficiente. La pregunta importante es si el mensaje optimizado realmente funciona mejor.

El proyecto apoya el análisis, la evaluación de un solo resultado y la comparación de múltiples resultados. Puede ejecutar el mensaje original y el mensaje optimizado en la misma tarea y luego comparar si el resultado es más preciso, estable y está alineado con el objetivo.

Esto es más práctico que las indicaciones que sólo “parecen más profesionales”. Muchas indicaciones parecen completas en la superficie, pero producen resultados detallados, rígidos o incluso mal dirigidos. Las pruebas comparativas ayudan a revelarlo tempranamente.

3. Soporte multimodelo

El README dice que el proyecto admite servicios modelo como OpenAI, Gemini, DeepSeek, Zhipu AI y SiliconFlow, así como API personalizadas compatibles con OpenAI.

Esto es importante porque el rendimiento rápido depende en gran medida del modelo. El mismo mensaje puede comportarse de manera muy diferente entre modelos. Las pruebas multimodelo ayudan a determinar:

Si el mensaje en sí es débil
Si un modelo específico no es adecuado para la tarea
Si se necesitan diferentes versiones de avisos específicos del modelo
Si un modelo más pequeño puede volverse utilizable con un mensaje más claro Si utiliza Ollama localmente o su empresa tiene un servicio de modelo interno compatible con OpenAI, también se puede conectar a través de una API personalizada.

4. Modo de prueba avanzado

El proyecto proporciona gestión de variables de contexto, pruebas de conversación de múltiples turnos y soporte de llamadas a funciones.

La gestión de variables es útil para tareas con plantillas. Por ejemplo, si tiene solicitudes de respuestas de ventas de segunda mano, descripciones de productos, respuestas de correo electrónico, revisiones de códigos o generación de documentos, puede reemplazar variables como producto, precio, tono y usuario objetivo para probar diferentes entradas rápidamente.

Las pruebas de conversación de varios turnos ayudan a validar el comportamiento de diálogo de larga duración. Muchas indicaciones parecen estar bien en un solo turno, pero una vez que comienzan las preguntas de seguimiento, es posible que olviden las limitaciones, se desvíen del papel o repitan explicaciones. Las pruebas de múltiples vueltas están más cerca del uso real.

El soporte de llamadas de funciones es adecuado para aplicaciones de IA más orientadas a la ingeniería. Ayuda a validar el comportamiento del modelo en torno a llamadas a herramientas, generación de parámetros y resultados estructurados.

5. Avisos de generación de imágenes

Prompt Optimizer también admite flujos de trabajo de texto a imagen y de imagen a imagen. El README menciona la integración con modelos de imágenes como Gemini y Seedream.

La optimización de mensajes de imagen es diferente de las tareas de texto. Se centra más en el tema, la composición, la relación espacial, el estilo, el material, la iluminación, el estado de ánimo y las limitaciones. Convertir una idea vaga en una descripción visual controlable suele ser más valioso que simplemente alargar la indicación.

Si genera con frecuencia imágenes de productos, portadas, ilustraciones, elementos visuales clave o referencias de estilo, este tipo de optimización es útil.

Formas de usarlo

El proyecto proporciona varios puntos de entrada:

Versión en línea
Vercel autohospedado
Aplicación de escritorio
Extensión de Chrome
Implementación de Docker
Implementación de Docker Compose
Servidor MCP

La versión en línea es buena para pruebas rápidas. El proyecto señala que es una aplicación puramente frontend: los datos se almacenan localmente en el navegador y se envían directamente a los proveedores de IA.

La aplicación de escritorio es mejor cuando necesita conectarse directamente a diferentes modelos de API. Los entornos de navegador pueden encontrarse con los límites de CORS; la aplicación de escritorio evita esos problemas, especialmente cuando se conecta a Ollama local o API comerciales con políticas estrictas de origen cruzado.

La implementación de Docker es adecuada para su propio servidor o entorno de intranet. El README da este comando básico:

`1`	`docker run -d -p 8081:80 --restart unless-stopped --name prompt-optimizer linshen/prompt-optimizer`

Para configurar claves API y contraseñas de acceso, pase variables de entorno:

docker run -d -p 8081:80 \
  -e VITE_OPENAI_API_KEY=your_key \
  -e ACCESS_USERNAME=your_username \
  -e ACCESS_PASSWORD=your_password \
  --restart unless-stopped \
  --name prompt-optimizer \
  linshen/prompt-optimizer

Si Docker Hub es lento en China, el proyecto también proporciona una dirección de imagen de Alibaba Cloud en el README.

Qué permite MCP

Prompt Optimizer admite el protocolo de contexto modelo o MCP.

Cuando se ejecuta a través de Docker, el servicio MCP puede iniciarse junto con la aplicación web y se puede acceder a él a través de la ruta /mcp. Esto lo convierte de una herramienta web en algo a lo que pueden acceder aplicaciones compatibles con MCP, como Claude Desktop.

El archivo README enumera estas herramientas MCP:

optimize-user-prompt: optimiza las indicaciones del usuario
optimize-system-prompt: optimiza las indicaciones del sistema
iterate-prompt: realiza una iteración específica en un mensaje existente Estas interfaces son muy adecuadas para los flujos de trabajo de IA. Por ejemplo, al escribir un mensaje de tarea compleja, un cliente compatible con MCP puede llamar a la herramienta de optimización de mensajes directamente en lugar de requerir que abra una página web y copie el texto manualmente.

Diferencia con las herramientas de chat normales

Las herramientas de chat normales también pueden ayudar a reescribir las indicaciones, pero normalmente carecen de varias partes:

Guardar y comparar múltiples versiones es inconveniente
Probar varios modelos a la vez es inconveniente
Convertir variables en plantillas es un inconveniente
La validación de conversaciones de varios turnos es inconveniente
La integración a través de MCP o autohospedaje es inconveniente

El valor de “Prompt Optimizer” es que convierte la optimización rápida en un proceso repetible. No solo te ofrece una versión que “parece más completa”; le permite seguir ajustando las indicaciones en torno a resultados reales.

¿Quién debería usarlo?

Este proyecto merece atención si:

A menudo escribe mensajes del sistema.
Diseñar roles y formatos de salida para aplicaciones de IA.
Necesidad de comparar resultados de diferentes modelos.
Quiere convertir indicaciones en plantillas reutilizables
Necesidad de probar el diálogo de varios turnos o las llamadas a herramientas.
Quiere conectar la optimización rápida a un flujo de trabajo MCP
Quiere implementar una herramienta de aviso localmente o dentro de una intranet.

Si sólo ocasionalmente le haces una pregunta sencilla a AI, una página de chat normal es suficiente. Esta herramienta es mejor para las personas que tratan las indicaciones como activos mantenibles.

Notas de uso

En primer lugar, no trate los resultados de la optimización como absolutamente correctos.

Las herramientas de optimización rápidas pueden mejorar la calidad de la expresión, pero no pueden garantizar que un modelo nunca se malinterprete. Las tareas importantes aún necesitan casos de prueba, revisión manual y comparación de versiones.

En segundo lugar, no se limite a perseguir la longitud.

Un buen mensaje no es necesariamente más largo. Debería expresar más claramente los objetivos, los límites, los formatos de entrada y salida y los criterios de evaluación. La acumulación de reglas sin sentido puede hacer que el modelo no entienda el punto.

En tercer lugar, ajuste las indicaciones por modelo.

Los diferentes modelos responden de manera diferente a la configuración de roles, restricciones de formato, pasos de razonamiento y ejemplos. Un mensaje que funciona bien en un modelo grande puede no ser adecuado para un modelo más pequeño. Las pruebas multimodelo son una de las razones por las que esta herramienta es útil.

Cuarto, considere las claves y el control de acceso al implementar.

Si lo implementa públicamente, configure una contraseña de acceso y maneje las claves API con cuidado. El proyecto soporta el control de acceso a través de variables de entorno; no escriba configuraciones confidenciales directamente en repositorios públicos.

Referencia

linshenkx/prompt-optimizer

Pensamiento final

Prompt Optimizer es útil para convertir mensajes de “un párrafo temporal que escribí a mano” en “un activo de trabajo que se puede probar, comparar e iterar”.

Cuando comienzas a mantener mensajes en múltiples modelos, escenarios y versiones, este tipo de herramienta es más conveniente que una ventana de chat normal.

Términos de AI explicados: Agent, MCP, RAG y Token en lenguaje simple

Thu, 23 Apr 2026 13:13:40 +0800

Cuando la gente empieza con AI, lo que suele alejarla no son los modelos en sí, sino la larga lista de términos que aparecen en cada discusión. Agent, MCP, RAG, AIGC y Token suenan familiares, pero sin una explicación simple muchas personas solo reconocen las palabras sin entenderlas de verdad.

Este artículo condensa 10 términos frecuentes de AI en significados más fáciles de recordar. El objetivo no es sonar académico, sino ayudarte a construir un modelo mental básico para seguir conversaciones cotidianas sobre AI.

10 términos comunes de AI y qué significan

1. Agent: una AI que hace más que chatear

Agent puede entenderse como un asistente AI que realmente hace trabajo.

Un chatbot normal suele seguir un patrón de pregunta y respuesta. Un Agent va más lejos: puede dividir una tarea en pasos, organizar un proceso, llamar herramientas y devolver un resultado terminado. Si le pides organizar materiales, buscar algo o generar un documento, quizá no solo dé consejos, sino que encadene acciones y las complete.

Por eso el punto clave de un Agent no es si puede hablar, sino si puede actuar.

2. OpenClaw: un asistente AI que vive en tu ordenador

Aquí, OpenClaw se describe como un tipo de asistente AI que vive en tu ordenador.

Puedes pensar en esta herramienta como un ayudante AI más orientado al escritorio. No solo recibe texto. También puede observar la interfaz, llamar herramientas locales y ejecutar tareas paso a paso. Frente a un chat web normal, enfatiza mucho más la capacidad operativa.

Si Agent es la idea abstracta de una AI orientada a ejecución, este tipo de asistente de escritorio es una versión concreta para ordenador personal.

3. Skills: paquetes de capacidad añadidos a un Agent

Skills pueden entenderse como módulos funcionales o instrucciones operativas para un Agent.

El mismo Agent puede comportarse muy distinto según las Skills que tenga. Algunas se centran en copywriting, otras en organizar datos y otras en código. Son un poco como apps en un teléfono y un poco como workflows reutilizables.

En muchos casos no es que el modelo se vuelva más inteligente de repente. Es que se añadieron reglas, herramientas y pasos más claros detrás.

4. MCP: una forma unificada para conectar AI con herramientas

MCP significa Model Context Protocol.

En términos cotidianos, es un poco como un conector Type-C para el mundo AI. Antes, conectar un modelo a distintas herramientas solía exigir integraciones separadas una por una. Con un protocolo unificado, la forma de conectar herramientas se vuelve más estándar y reutilizable.

Para la mayoría de usuarios, lo importante es recordar esto: MCP no trata de si un modelo puede responder una pregunta. Trata de cómo un modelo puede conectarse a herramientas y recursos externos de forma segura y estable.

5. Gacha: la salida AI es inherentemente aleatoria

El término “gacha” aparece a menudo en generación de imágenes, video y trabajo creativo con AI.

La idea es simple. Incluso con el mismo prompt y la misma dirección general, el resultado puede cambiar cada vez. A veces sale genial. A veces se rompe. Por eso se compara repetir generaciones con tirar gacha en un juego.

Esto recuerda que la generación AI no es una fórmula fija, sino un proceso probabilístico con variación.

6. API: la conexión entre una app y un modelo

API significa Application Programming Interface.

Puedes pensarla como el punto de entrada estándar por el que los programas se comunican. Cuando llamas un servicio de modelo desde tu app, script o editor, usas una API para enviar una solicitud y recibir un resultado.

Si comparas un servicio de modelo con un restaurante:

el menú es como la documentación de API
hacer un pedido es como una solicitud API
la cocina devolviendo el plato es como el modelo devolviendo resultado

Por eso muchas herramientas pueden verse distintas en superficie y aun así llamar alguna API por debajo.

7. Multimodalidad: AI maneja más que texto

Multimodality significa que AI ya no solo lee y escribe texto. Puede procesar varios tipos de entrada y salida.

Por ejemplo, puede leer imágenes, entender voz, interpretar video, generar dibujos o soportar interacción de voz y video en tiempo real. Frente a los primeros modelos solo texto, los modelos multimodales se acercan más a combinar ver, oír, hablar y escribir.

Por eso muchos productos AI ya no giran alrededor de una sola caja de texto.

8. RAG: recuperar información primero y luego generar respuesta

RAG significa Retrieval-Augmented Generation.

Sirve para resolver un problema práctico: los datos de entrenamiento de un modelo tienen un límite temporal y no conoce automáticamente los documentos nuevos de tu empresa, registros de soporte o reglas de negocio. La idea de RAG es recuperar primero material relevante de fuentes específicas y luego generar una respuesta basada en ese material.

Su valor aparece en tres formas:

las respuestas se mantienen más cerca del material fuente real
puedes rastrear de dónde salió la respuesta
documentos nuevos pueden añadirse y reflejarse rápido

Por eso muchas bases de conocimiento empresariales, sistemas de atención AI y herramientas internas de Q&A dependen de RAG.

9. AIGC: término general para contenido generado por AI

AIGC significa AI Generated Content.

No es una herramienta concreta. Es una etiqueta amplia para contenido producido por AI: texto, imágenes, audio, video y más. Escritura AI, ilustración AI, generación de video corto y síntesis de voz AI entran bajo AIGC.

Lo importante es que describe una forma de producir contenido, no un modelo específico.

10. Token: la unidad usada para medir procesamiento del modelo

Token puede entenderse como la unidad básica que un modelo usa para procesar texto.

No equivale exactamente a un carácter o una palabra, pero en la práctica puedes tratarlo como la unidad común para cómputo y facturación del modelo. Tu entrada consume Token, la salida del modelo consume Token y el contexto guardado en memoria también ocupa Token.

Por eso los servicios de modelos hablan tanto de longitud de contexto, control de coste y compresión de prompts. En el fondo, todo eso está ligado a Token.

Uso más eficiente de la cuota de código de Claude: modelos, contexto, almacenamiento en caché y /compact

Sun, 19 Apr 2026 15:29:06 +0800

Muchos usuarios de Claude Code o Claude Max se encuentran con el mismo problema: incluso después de pagar por Pro, Max 5x o Max 20x, la advertencia de uso aparece rápidamente o tienen que esperar al siguiente reinicio. Esto resulta especialmente obvio cuando Claude Code lee muchos archivos, corrige errores complicados o ejecuta tareas largas en un proyecto grande.

El punto clave es este: el uso no se deduce linealmente por “minutos”. Depende del modelo, la longitud del contexto, los archivos adjuntos, el tamaño del código base, el historial de conversaciones, las llamadas a herramientas y la capacidad actual. En el mismo período de 5 horas, una persona puede trabajar durante mucho tiempo mientras que otra alcanza el límite en minutos. Por lo general, la cuenta no está rota; cada solicitud es simplemente demasiado pesada.

Esta nota recoge un conjunto de hábitos prácticos para utilizar la cuota de forma más eficiente.

01 Primero comprenda la ventana de uso de Claude

Tanto Claude Pro como Max tienen límites de uso. El uso de Claude Code se comparte con Claude en la web, el escritorio y el dispositivo móvil bajo la misma cuota de suscripción. El centro de ayuda de Anthropic explica que el recuento de mensajes depende de la longitud del mensaje, el tamaño del archivo adjunto, la duración de la conversación actual, el modelo o característica utilizada, y que el uso de Claude Code también se ve afectado por la complejidad del proyecto, el tamaño de la base del código y la configuración de aceptación automática.

Una forma sencilla de pensarlo:

Pro: adecuado para uso ligero y proyectos pequeños.
Max 5x: adecuado para un uso más frecuente y bases de código más grandes.
Máx. 20x: adecuado para colaboraciones diarias más intensas.
Las ventanas de uso se restablecen en sesiones de 5 horas.
Los mensajes largos, las conversaciones largas, los archivos grandes y las tareas complejas consumen el uso más rápidamente.
Los modelos más fuertes, como Opus, alcanzan los límites más rápido que Sonnet.

Así que “sólo lo usé durante 20 minutos” no explica mucho por sí solo. Lo que importa es cuánto contexto leyó Claude durante esos 20 minutos, qué modelo se utilizó, si los archivos grandes se procesaron repetidamente y si la misma larga conversación siguió acumulando más tareas.

02 Primer hábito: no optar por el modelo más caro

La familia de modelos Claude suele posicionarse así:

Opus: capacidad más potente, adecuada para razonamientos complejos, decisiones de arquitectura y errores difíciles.
Sonnet: capacidad y coste equilibrados, adecuado para la mayoría de las tareas de codificación cotidianas.
Haiku: más ligero, adecuado para clasificación, resumen y conversión de formato sencillos.

Para scripts diarios, pequeñas correcciones de errores, limpieza de documentación y explicación de código, Sonnet suele ser suficiente. Guarde Opus para casos como:

Diseño de arquitectura compleja.
Refactorizaciones profundas de múltiples archivos.
Errores difíciles de reproducir.
Solución de problemas de cadena larga.
Tareas donde el modelo normal está claramente estancado.

En Claude Code, use /model para cambiar de modelo o establezca el valor predeterminado en /config. Un hábito más constante es utilizar Sonnet de forma predeterminada y cambiar a Opus sólo en puntos clave, en lugar de ejecutar toda la tarea en Opus.

03 Segundo hábito: controlar el contexto, no arrastrar tareas antiguas

Cuanto más largo sea el contexto, más necesitará procesar Claude en cada turno y más rápido se consumirá el uso. Los documentos del Código Claude recomiendan explícitamente la gestión proactiva del contexto:

Utilice /clear cuando cambie a una tarea no relacionada.
Utilice /compact cuando finalice una fase pero debe permanecer un contexto importante.
Utilice /context para ver qué está ocupando espacio.
Configure una línea de estado si desea visibilidad continua del estado.

Un ritmo útil:

Small phase done: /compact
Large task done: /clear
Switching to unrelated work: /clear
Context usage getting high: /compact early

/compact resume el historial de conversaciones anteriores y al mismo tiempo conserva el estado de las tareas clave, las conclusiones, las rutas de los archivos y el trabajo restante. Reduce la cantidad de historial que se incluye en solicitudes posteriores. También puede agregar una breve instrucción:

`1`	`/compact Preserve changed files, test results, remaining TODOs, and key design decisions`

No espere a que se compacte automáticamente. Los documentos señalan que Claude Code se autocompacta cuando el contexto se acerca al límite, pero la compactación manual en los límites de fase suele ser más fácil de controlar.

04 Tercer hábito: las conversaciones largas y los archivos grandes hacen que cada solicitud sea más pesada

Mucha gente supone que “Sólo hice una pregunta más” debería ser barato. Pero en una conversación larga, esa pregunta puede tener detrás una gran cantidad de historia, resúmenes de archivos, definiciones de herramientas y reglas del sistema.

Las cosas que fácilmente inflan el contexto incluyen:

Conversaciones largas que nunca se aclaran.
Pedirle a Claude que lea archivos grandes completos.
Pegar registros largos, resultados de compilación o resultados de prueba.
Agregar muchas capturas de pantalla o imágenes a la vez.
Pidiéndole que escanee repetidamente todo el repositorio.
Un CLAUDE.md demasiado largo.
Demasiados servidores MCP habilitados.

Un enfoque más eficiente: pegue solo los errores clave de los registros, incluya solo las partes fallidas del resultado de la prueba y deje que Claude use rg, head, tail y la búsqueda de símbolos antes de leer solo las partes necesarias. Si el filtrado de la línea de comandos puede reducir el contenido, no pegue todo en contexto.

05 Cuarto hábito: comprender el almacenamiento en caché, pero no adorarlo

El almacenamiento en caché de avisos de Anthropic puede almacenar en caché prefijos de avisos repetidos. La vida útil predeterminada de la caché es de 5 minutos y también se admite una caché de 1 hora. Cuando se alcanza el caché, no es necesario reprocesar completamente el contexto repetido de gran tamaño, lo que ayuda a reducir los costos y mejorar la utilización del límite de velocidad.

Pero el almacenamiento en caché tiene limitaciones:

El contenido debe coincidir exactamente, incluidos texto e imágenes.
La caché predeterminada es de corta duración.
Cambiar modelos, herramientas, indicaciones del sistema o estructura de contexto puede reducir los accesos al caché.
Los tokens de salida no desaparecen debido al almacenamiento en caché; aún es necesario generar la respuesta.
La forma en que Claude Code utiliza el almacenamiento en caché es un detalle de implementación a nivel de producto, por lo que no lo trate como “memoria libre” permanente.

En la práctica, lo importante no es estudiar cada detalle del almacenamiento en caché. Mantiene la sesión estable:

Evite cambios frecuentes de modelo dentro de la misma fase.
No reescriba repetidamente grandes bloques de reglas a mitad de la tarea.
No sigas agregando nuevas imágenes dentro de la misma tarea.
No dejes una tarea larga inactiva durante demasiado tiempo y luego regreses con otra gran solicitud.
Utilice /compact en los límites de fase.

Esto hace que el contexto repetido sea más fácil de reutilizar y reduce el peso de las solicitudes posteriores.

06 Sobre las horas pico: evítalas cuando puedas, pero no las trates como una fórmula

La gente suele decir que ciertas horas se sienten más apretadas. El centro de ayuda de Anthropic es más cuidadoso: el recuento de mensajes puede verse afectado por la capacidad actual de Claude, la duración de la conversación, los archivos adjuntos, el modelo y las características. En otras palabras, la capacidad máxima puede afectar la experiencia, pero no trate una ventana horaria local específica como una regla permanente.

Sugerencias prácticas:

Realice grandes refactorizaciones y análisis exhaustivos en períodos en los que tanto su red como el servicio sean estables.
No comiences una tarea enorme justo antes de que planees alejarte.
Si espera salir por un largo tiempo, ejecute /compact o /clear primero.
Para ediciones pequeñas, no utilices Opus con un contexto largo a menos que realmente lo necesites.

Esto es más confiable que memorizar una regla fija de “no usarlo de X a Y”.

07 Slim Down CLAUDE.md, reglas, MCP y habilidades

Claude Code carga reglas del proyecto, información de herramientas y algo de contexto ambiental en la sesión. Los documentos oficiales también recomiendan separar las reglas generales de las reglas especializadas para que cada sesión no comience con una gran cantidad de texto no relacionado.

Una división útil:

CLAUDE.md: sólo reglas globales que siempre se aplican.
reglas: reglas específicas de ruta o de tipo de archivo.
habilidades: flujos de trabajo específicos, como publicación de publicaciones, implementación, generación de imágenes o confirmación de código.
MCP: solo habilita los servidores que la tarea actual realmente necesita.

Si CLAUDE.md tiene cientos o miles de líneas, cada sesión conlleva ese costo. Un mejor patrón es trasladar flujos de trabajo ocasionales a habilidades y cargarlos solo cuando sea necesario.

MCP es similar. Más herramientas no significan automáticamente más eficiencia. Los documentos de Claude Code mencionan el uso de /mcp para ver y deshabilitar servidores innecesarios, y /context para ver qué está consumiendo espacio de contexto.

08 Lista de comandos prácticos

Estos son los comandos diarios más útiles:

/model

Cambiar de modelo. Sonnet es un buen valor predeterminado; Utilice Opus para razonamientos complejos.

/clear

Borrar el contexto actual. Úselo cuando cambie a un trabajo no relacionado.

`1`	`/compact`

Comprimir el historial de conversaciones. Úselo cuando finalice una fase pero continúe la misma tarea.

`1`	`/context`

Inspeccione el uso del contexto y encuentre qué está ocupando espacio.

/status

Verifique la suscripción o el estado relacionado con el uso. El centro de ayuda de Anthropic también recomienda monitorear la asignación restante.

/mcp

Vea y administre servidores MCP y desactive las herramientas que no sean necesarias para la tarea actual.

Si utiliza la facturación API, /cost puede resultar útil. Pero para las suscripciones Pro/Max, los documentos de Claude Code explican que la estimación en dólares de “/cost” no es la referencia de facturación correcta; los suscriptores deberían confiar más en la información de uso como /stats y /status.

09 Un flujo de trabajo para ahorrar cuotas

Un flujo de trabajo práctico se ve así:

Ejecute /clear antes de comenzar una nueva tarea.
Utilice Sonnet de forma predeterminada.
Deje que Claude inspeccione primero la estructura del proyecto y los archivos clave, no todo el repositorio.
Ejecute /compact después de cada pequeña fase.
Cambie a Opus solo para bloqueadores duros.
Filtre registros, errores y pruebe los resultados antes de pegarlos.
Ejecute /clear una vez finalizada la tarea; No comience un nuevo trabajo con un contexto obsoleto.
Revise periódicamente CLAUDE.md, MCP y las habilidades para reducir el contexto siempre activo.

La idea central es simple: dejar que Claude vea sólo lo que realmente necesita para la tarea actual.

10 Resumen

El uso de Claude Code que se agota rápidamente no suele deberse a una sola cosa. A menudo es una combinación de modelos de alto costo, largas conversaciones sin borrar, demasiados archivos y registros, contexto de reglas y MCP pesado, reutilización de caché más débil y fluctuaciones máximas de capacidad.

Las soluciones prácticas también son sencillas:

Utilice Sonnet para el trabajo diario.
Guarde Opus para problemas verdaderamente complejos.
Utilice /compact cuando finalice una fase.
Utilice /clear al cambiar de tarea.
Utilice /context para encontrar el contexto hinchado.
Adelgazar CLAUDE.md, reglas, MCP y habilidades.
No volcar todo el repositorio, registros completos o lotes de imágenes grandes en contexto.

La cantidad de trabajo que puede soportar el mismo plan Pro o Max depende en gran medida de cómo gestiona el contexto. Si reduce el contexto y aclara los límites de las tareas, Claude Code se sentirá mucho más estable.

Referencias

Centro de ayuda de Claude: uso de Claude Code con su plan Pro o Max: https://support.claude.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan
Centro de ayuda de Claude: Acerca del uso del plan Max de Claude: https://support.anthropic.com/en/articles/11014257-about-claude-s-max-plan-usage/
Claude Code Docs: Gestione los costes de forma eficaz: https://code.claude.com/docs/en/costs
Anthropic Docs: almacenamiento en caché rápido: https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching

Notas del proyecto Firecrawl: APIs de búsqueda web, scraping e interacción para AI Agents

Wed, 15 Apr 2026 13:45:03 +0800

Firecrawl tiene un propósito claro: convertir páginas web en datos que los AI Agents puedan consumir con más facilidad. No es solo un script crawler. Envuelve búsqueda, scraping de una página, crawling de sitios, interacción con páginas, extracción estructurada y flujos de agentes en APIs, para que modelos y sistemas de automatización gasten menos esfuerzo lidiando con ruido web.

01 Qué problema resuelve

Muchas aplicaciones AI necesitan leer páginas web, pero los sitios reales son desordenados: contenido renderizado con JavaScript, pop-ups, paginación, estado de login, defensas anti-bot, archivos PDF o DOCX, y mucha navegación, anuncios, scripts y estilos que no tienen que ver con el contenido principal.

Firecrawl intenta resolver este problema de capa intermedia. La aplicación pide datos de una página, un sitio o un tema; Firecrawl se encarga de abrir, scrapear, limpiar y devolver salida en formatos más fáciles de usar para LLMs, como Markdown, HTML, screenshots o JSON.

El valor de este tipo de herramienta no está solo en si puede solicitar una URL. La pregunta real es si puede convertir páginas complejas en datos utilizables de forma fiable. Para RAG, búsqueda AI, investigación competitiva, recolección automatizada de información y monitoreo de contenido web, esta capa suele convertirse en la fontanería incómoda del sistema.

02 Funciones principales

El README de Firecrawl agrupa sus capacidades en varias áreas:

Search: busca en la web y devuelve contenido completo de páginas desde los resultados.
Scrape: convierte una URL individual en Markdown, HTML, screenshots o JSON estructurado.
Interact: scrapea una página y luego usa prompts o código para hacer clic, scroll, escribir, esperar y realizar otras acciones.
Agent: describe lo que quieres y deja que el agente busque, navegue y devuelva el resultado.
Crawl: scrapea múltiples páginas dentro de un sitio.
Map: descubre rápidamente URLs de un sitio web.
Batch Scrape: scrapea grandes lotes de URLs de forma asíncrona.

A primera vista parece un servicio de scraping. Pero como conjunto completo de funciones, está más cerca de un punto de entrada de datos para aplicaciones AI: search descubre fuentes, scraping limpia contenido, interaction maneja páginas dinámicas y Agent empuja toda la tarea de “encontrar información” un paso más hacia la automatización.

03 Por qué encaja con AI Agents

Los crawlers tradicionales suelen asumir que ya conoces la URL y entiendes la estructura de la página. Los flujos con agentes a menudo son diferentes. Un usuario puede pedir simplemente: “Encuentra las diferencias entre los últimos planes de precios en la página de precios de una empresa”. Entonces el sistema tiene que buscar, abrir páginas, comparar contenido y devolver fuentes.

El endpoint Agent de Firecrawl está diseñado para este tipo de tarea. Puede aceptar solo un prompt en lenguaje natural, o puede restringirse a URLs concretas. Si se necesitan resultados estructurados, también puede trabajar con un schema para devolver campos fijos.

Esto da dos beneficios a la capa de aplicación:

No necesitas escribir un parser separado para cada sitio.
El resultado devuelto es más fácil de enviar a un LLM, una base de datos o un flujo de automatización posterior.

Por supuesto, esto no significa que reemplace todos los crawlers personalizados. Para tareas muy acotadas, de alta frecuencia y gran escala con campos muy estables, escribir lógica de parsing dedicada puede seguir siendo más barato y más fácil de controlar. Firecrawl encaja mejor cuando las fuentes están dispersas, las estructuras cambian a menudo y quieres conectar datos web a un flujo AI rápidamente.

04 MCP, CLI e integraciones

Firecrawl también se mueve claramente hacia el ecosistema de herramientas para agentes. El README ofrece configuración de MCP Server, junto con comandos de inicialización Skill/CLI para agentes de programación AI.

Esto significa que no está pensado solo para llamadas API backend. También quiere conectarse directamente a Claude Code, OpenCode, Antigravity, clientes MCP y flujos similares. Para personas que piden con frecuencia a agentes investigar, scrapear y organizar contenido web, esta integración es más ligera que escribir llamadas API a mano.

También enumera integraciones con plataformas como Zapier, n8n y Lovable. Esa dirección es práctica: los datos web no siempre van a código. Pueden fluir a tablas de automatización, workflows low-code, sistemas de contenido o bases de conocimiento internas.

05 Open source, self-hosting y licencias

Firecrawl es open source. El repositorio principal usa principalmente la licencia AGPL-3.0; el README también señala que los SDKs y algunos componentes UI usan MIT, con detalles según los archivos LICENSE de cada directorio.

Esto importa. Si solo usas el servicio cloud, las preocupaciones principales son coste de API, fiabilidad y límites de cumplimiento. Si planeas self-hostearlo y ofrecer un servicio a otros, las obligaciones de AGPL-3.0 necesitan revisión cuidadosa.

El README también recuerda a los usuarios que respeten políticas de sitios web, políticas de privacidad y términos de uso, y dice que Firecrawl respeta robots.txt por defecto. Cuanto más potente se vuelve este tipo de herramienta, más importante es diseñar límites de cumplimiento y scraping dentro del sistema desde el inicio, no parchearlos después del lanzamiento.

06 Casos de uso adecuados

Consideraría Firecrawl primero en estos escenarios:

Scrapear contenido web para un sistema RAG y querer Markdown limpio directamente.
Construir asistentes de búsqueda o investigación AI que necesiten leer páginas completas tras buscar.
Scrapear sitios con mucho JavaScript sin mantener tú mismo un clúster de navegadores.
Monitorear información pública como competidores, precios, documentación, noticias y páginas de empleo.
Dar a clientes MCP o agentes de programación AI capacidad de lectura web en tiempo real.
Validar rápidamente un producto de datos web antes de construir infraestructura crawler.

Los casos menos adecuados también son claros:

El sitio objetivo tiene muy pocos campos, estructura estable y puede manejarse con un script simple.
El volumen de scraping es enorme y la sensibilidad al coste importa más que el coste de desarrollo y mantenimiento.
El negocio necesita control muy fino sobre fuentes, estrategia de reintentos, comportamiento anti-bot y trazas de auditoría.
Requisitos de licencia o cumplimiento no permiten componentes AGPL o servicios cloud externos.

07 Conclusión rápida

El valor central de Firecrawl es productizar el camino desordenado de “página web” a “datos utilizables por AI”. Pone búsqueda, scraping, limpieza, interacción, procesamiento por lotes e investigación estilo agente en una sola interfaz, lo cual es cómodo para desarrolladores de aplicaciones AI.

Si tu proyecto necesita a menudo que los modelos lean páginas web reales, especialmente cuando las fuentes están dispersas, las estructuras son inestables y MCP o flujos de agentes están involucrados, Firecrawl merece estar en tu caja de herramientas. Si la tarea es solo recolección masiva de bajo coste desde sitios fijos, un crawler tradicional o un parser dedicado puede seguir siendo la mejor opción.

Enlaces relacionados

Proyecto GitHub: https://github.com/firecrawl/firecrawl

Qué es Hermes Agent: resumen, fortalezas, primeros pasos y comparación con OpenClaw

Sun, 12 Apr 2026 14:07:58 +0800

Si has estado siguiendo agentes AI open source recientemente, Hermes Agent es un proyecto al que vale la pena prestar atención. Creado por Nous Research, su atractivo principal no es simplemente ser otro envoltorio de chat, sino intentar reunir memoria a largo plazo, skills reutilizables, archivos de contexto, extensiones MCP, una pasarela de mensajería y sub-agentes paralelos en un único runtime de agentes.

Según el README oficial, Hermes Agent tiene un objetivo muy claro: puede funcionar como un asistente CLI local en tu terminal, o como un asistente personal alojado en la nube y disponible a través de Telegram, Discord, Slack, WhatsApp, Signal y otros canales. Para usuarios que quieren combinar un asistente de programación, un asistente de automatización y un espacio personal de AI en un solo sistema, ese posicionamiento es atractivo.

01 Resumen de Hermes Agent

Hermes Agent es un agente AI open source y auto-mejorable de Nous Research. Soporta varios proveedores de modelos, incluidos Nous Portal, OpenRouter, OpenAI y endpoints personalizados compatibles con OpenAI. También puede ejecutarse en distintos backends como terminal local, Docker, SSH, Daytona y Modal.

Lo que separa a Hermes de muchos chatbots con herramientas es que no se centra solo en llamadas a herramientas dentro de una sesión. Da mucha más importancia a construir capacidades persistentes entre sesiones. La documentación oficial divide esta idea en varias partes:

Memoria persistente: guarda información clave sobre el entorno, el proyecto y las preferencias del usuario mediante MEMORY.md y USER.md.
Sistema de skills: convierte flujos de trabajo exitosos en skills reutilizables que pueden cargarse bajo demanda.
Archivos de contexto: lee automáticamente archivos como AGENTS.md, SOUL.md y .cursorrules para inyectar convenciones del proyecto directamente en la sesión.
Integración MCP: puede conectarse a cualquier servidor compatible con MCP para ampliar capacidades de bases de datos, GitHub, filesystem y scraping.
Pasarela de mensajería: además de la CLI, puede usarse desde Telegram, Discord, Slack, WhatsApp, Signal, Email y otros puntos de entrada.

En una frase, Hermes Agent se siente más como una capa operativa de agentes de propósito general con memoria, skills, extensibilidad y acceso multicanal.

02 Dónde destaca

1. Cubre flujos CLI y flujos de mensajería

Muchos proyectos de agentes se inclinan hacia asistencia de desarrollador en terminal o hacia bots de plataformas de chat. Hermes intenta combinar ambos. Puedes ejecutar hermes directamente en la terminal, o continuar con el mismo asistente por Telegram o Discord después de iniciar la gateway.

El beneficio práctico es que Hermes no se limita a ser útil solo cuando estás frente al ordenador. Si lo despliegas en la nube o en un VPS, puede convertirse en un asistente personal disponible de forma continua.

2. Está diseñado para uso a largo plazo

Hermes hace más que chatear y llamar herramientas. También está construido alrededor de acumulación a largo plazo:

Memoria persistente con límites, en lugar de meter contexto sin fin en cada conversación.
Un sistema de skills que permite guardar y reutilizar flujos exitosos.
Búsqueda en sesiones pasadas para recuperación y recuerdo.
Archivos de contexto de proyecto que reducen la necesidad de repetir el mismo trasfondo.

Esto importa mucho para personas que trabajan repetidamente en los mismos repositorios, flujos y convenciones de equipo. Significa que el agente no solo ayuda una vez; puede familiarizarse gradualmente con tu entorno.

3. El soporte MCP le da gran extensibilidad

La documentación de Hermes soporta explícitamente MCP y describe modos de integración por stdio y HTTP. En la práctica, si un sistema externo ya tiene un servidor MCP, Hermes suele poder conectarse con un coste de integración mucho menor.

Eso es más flexible que escribir un plugin personalizado para cada sistema. Para usuarios que ya tienen herramientas alrededor del ecosistema MCP, Hermes debería ser mucho más fácil de extender.

4. Es amigable para usuarios de OpenClaw

Esta parte es especialmente interesante. El README de Hermes ofrece directamente hermes claw migrate y dice explícitamente que puede importar configuración, memoria, skills, claves API y ajustes de plataformas de mensajería desde OpenClaw.

Eso sugiere que Hermes no intenta ignorar el ecosistema existente y empezar desde cero. Claramente posiciona a algunos usuarios de OpenClaw como audiencia de migración.

03 Cómo empezar rápido

El método de instalación recomendado oficialmente para Hermes Agent es muy directo:

`1`	`curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh \| bash`

Según el README oficial, soporta Linux, macOS, WSL2 y Android Termux. Una nota importante es que Windows nativo no está soportado por ahora, así que se recomienda a los usuarios de Windows usar WSL2.

Después de instalar, normalmente conviene refrescar primero la shell:

`1`	`source ~/.bashrc`

Luego puedes iniciarlo directamente:

hermes

Si quieres pasar por un flujo de inicialización más completo paso a paso, el comando más sencillo es:

`1`	`hermes setup`

Según la documentación y el README oficiales, una ruta simple de primera configuración sería:

Ejecuta hermes setup para completar la configuración base.
Usa hermes model para elegir proveedor y modelo.
Usa hermes tools para activar los conjuntos de herramientas que quieras.
Ejecuta hermes para entrar en la CLI interactiva.
Si quieres canales como Telegram o Discord, continúa con hermes gateway.

Si ya usas OpenClaw, también vale la pena previsualizar el comando de migración:

`1`	`hermes claw migrate --dry-run`

Así puedes inspeccionar qué se puede migrar antes de hacer una importación real.

04 Cómo pensarlo frente a OpenClaw

Según la documentación y el README oficiales, Hermes Agent y OpenClaw no son simplemente un caso de uno reemplazando al otro. Sus posicionamientos se solapan, pero sus prioridades son claramente diferentes.

Cómo se siente Hermes Agent

Hermes se siente más como un producto centrado en un núcleo de agente y un sistema de flujos de trabajo. Enfatiza:

experiencia CLI
acumulación de memoria y skills
archivos de contexto de proyecto
extensibilidad MCP
sub-agentes paralelos
cambio de backends de ejecución entre local, contenedor, remoto y serverless

Si tu objetivo principal es que el agente entienda mejor tu proyecto, reutilice capacidades con el tiempo y se conecte de forma más natural a MCP y flujos de desarrollo, Hermes probablemente encaje mejor.

Cómo se siente OpenClaw

OpenClaw se siente más como una plataforma centrada en un asistente personal AI más una pasarela de mensajería. Enfatiza:

integración rica con canales de mensajería
una Gateway siempre en ejecución
una Control UI basada en navegador
emparejamiento de dispositivos, acceso remoto y gestión de estado
superficies más orientadas a asistente, como voz, acceso móvil y Canvas

Si tu objetivo principal es mantener un asistente personal AI disponible de forma fiable en varios canales y dispositivos, con un panel de control para gestionarlo, OpenClaw tiene una sensación de producto más fuerte en esa dirección.

Una regla práctica

Puedes pensar en los dos así:

Hermes Agent: más como un espacio de trabajo de agentes de propósito general que crece con el uso
OpenClaw: más como una plataforma de asistente personal AI multicanal y siempre disponible

La distinción no es absoluta, porque ambos proyectos siguen expandiéndose y Hermes también ofrece una ruta de migración desde OpenClaw. Pero según el material público actual, Hermes destaca más en memoria, skills, contexto, MCP y flujos de desarrollo, mientras OpenClaw parece más maduro en gateway, multicanal, Control UI y acceso a dispositivos.

05 Quién debería probarlo

Hermes Agent merece probarse primero si encajas en alguno de estos perfiles:

Ya dependes mucho de herramientas AI en la terminal y quieres un agente que entienda mejor tu codebase y reglas de proyecto.
Quieres combinar AGENTS.md, skills, memoria y MCP en un solo flujo.
No quieres quedar bloqueado en un único proveedor de modelos y prefieres cambio flexible de proveedores.
Ya usas OpenClaw y quieres explorar una dirección más centrada en flujos de agentes.

Si te importa más el alcance móvil, la integración amplia con plataformas de mensajería, una consola de control en navegador y la sensación de un asistente personal siempre online, OpenClaw sigue teniendo mucho atractivo.

Referencias

Hermes Agent GitHub: https://github.com/NousResearch/hermes-agent
Hermes Agent Docs: https://hermes-agent.nousresearch.com/docs/
Hermes Features Overview: https://hermes-agent.nousresearch.com/docs/user-guide/features/overview
Hermes MCP: https://hermes-agent.nousresearch.com/docs/user-guide/features/mcp/
OpenClaw GitHub: https://github.com/openclaw/openclaw
OpenClaw Getting Started: https://docs.openclaw.ai/start/quickstart
OpenClaw Control UI: https://docs.openclaw.ai/web/control-ui

¿Abandonar MCP? Por qué CLI se está convirtiendo en la capa de herramientas predeterminada para agentes

Fri, 10 Apr 2026 21:55:12 +0800

Durante el último año, el debate sobre las cadenas de herramientas para agentes se ha concentrado cada vez más en una pregunta:

¿MCP (Model Context Protocol) simplifica las llamadas a herramientas, o vuelve más complejas tareas que antes eran simples?

Para la mayoría de tareas cotidianas de ingeniería, CLI se está convirtiendo en la opción predeterminada más práctica.

La diferencia de coste no es un problema de UX, sino de orden de magnitud

La mayor presión práctica de MCP es el gasto de tokens.

En escenarios comunes, MCP suele tener que cargar grandes esquemas de herramientas antes de ejecutar la tarea real. Tomando como ejemplo un GitHub MCP Server, solo la inicialización puede consumir decenas de miles de tokens. En tareas largas, esto reduce directamente el presupuesto de contexto.

Las pruebas de la comunidad apuntan una y otra vez a la misma conclusión:

una llamada MCP suele costar varias veces, o incluso decenas de veces, más que CLI
la recuperación tras fallos también es más cara, porque hay que reconectar y recargar contexto

Esto no es simplemente “un poco más lento”. Escala hasta convertirse en problemas de coste de API, latencia y estabilidad.

Por qué los modelos son naturalmente mejores usando CLI

Un hecho que se pasa por alto con frecuencia es la distribución de entrenamiento.

Los LLM han visto enormes cantidades de texto de terminal durante el entrenamiento: comandos, salidas, errores, scripts y man pages. En otras palabras, la interacción por CLI ya está cerca del patrón de entrada nativo del modelo.

En cambio, el estilo JSON-RPC y los tool schemas de MCP solo se popularizaron a gran escala en los últimos años. Los modelos pueden aprenderlo, por supuesto, pero la familiaridad y la eficiencia de compresión suelen ser peores que en patrones CLI con décadas de corpus histórico.

Esto también explica por qué muchas veces:

para el mismo objetivo, los comandos CLI son más cortos
la salida es más fácil de usar para seguir razonando
las rutas de recuperación de errores son más estables

Seguridad y aislamiento: MCP aún tiene tarea pendiente

MCP no es incapaz de ser seguro, pero su ecosistema todavía está en una etapa temprana.

Las preocupaciones habituales incluyen:

Tool Poisoning en descripciones
deriva de comportamiento del servicio, o Rug Pull
sobrescritura por herramientas con el mismo nombre, o Shadowing

CLI también tiene riesgos de seguridad, como inyección, abuso de privilegios y riesgos de rutas. Pero su modelo de procesos, límites de permisos y cadena de auditoría han sido validados durante décadas de práctica de ingeniería. En producción, esa previsibilidad importa.

Esto no significa que MCP no tenga valor

No creo que MCP deba abandonarse.

Una posición más razonable es:

CLI se encarga de la capa de ejecución: local, baja latencia y llamadas frecuentes
MCP se encarga de la capa de conexión: descubrimiento de servicios remotos, autenticación unificada, auditoría y multitenencia

Es la arquitectura híbrida que suele resumirse como CLI + MCP Gateway.

Cuando hay que integrar muchos sistemas remotos y aplicar gobierno de permisos y auditoría de cumplimiento, MCP sigue teniendo un valor claro. Pero para “ayudar a un Agent a completar tareas de desarrollo rápidamente”, CLI-first suele encajar mejor con los límites actuales de capacidad de los modelos.

En la realidad de ingeniería actual, CLI se parece más al idioma de trabajo nativo de un Agent; MCP encaja mejor como protocolo de conexión que como único protocolo de ejecución.