AI Agent on KnightLi Blog

Clasificación de proyectos open source de AI en GitHub: de Coding Agent a bases de conocimiento RAG

Thu, 21 May 2026 08:53:13 +0800

Esta página organiza proyectos de AI en GitHub por dirección de uso: AI Coding y Coding Agents, skills y flujos Agent, RAG y bases de conocimiento, creación multimodal, modelos locales e inferencia, aplicaciones verticales y automatización, e infraestructura para desarrollar aplicaciones de AI. Cuando aparezcan nuevos proyectos, pueden añadirse con la misma estructura.

Resumen por categoría

Categoría	Proyectos	Para quién empezar aquí
AI Coding y Coding Agents	19	Usuarios que trabajan con Claude Code, Codex, Cursor, agents de terminal o automatización de repositorios
Skills y flujos Agent	7	Usuarios que quieren estandarizar AI Coding, investigación o flujos de creación
RAG, bases de conocimiento y memoria	7	Usuarios que necesitan búsqueda documental, bases de conocimiento, memoria de largo plazo, crawling web o extracción estructurada
Aplicaciones verticales y automatización	7	Usuarios interesados en finanzas, trading, monitoreo de Xianyu, control de escritorio, automatización de navegador y otros escenarios prácticos
Multimodal y creación de contenido	5	Usuarios que trabajan con imágenes, video, transcripción, librerías de prompts y distribución de contenido
Infraestructura para aplicaciones de AI	3	Desarrolladores que construyen apps de AI, automatización de navegador o toolchains Prompt/MCP
Modelos locales e inferencia	1	Usuarios interesados en DeepSeek local, motores de inferencia y adaptación de hardware

La distribución muestra varias direcciones frecuentes en los proyectos open source actuales de AI: las herramientas de AI Coding son las más numerosas, seguidas por flujos Agent, bases de conocimiento RAG y escenarios aplicados. Hay menos proyectos centrados solo en inferencia local porque mucho contenido de despliegue local se organiza alrededor de modelos, GPUs o planes de despliegue, no de un único proyecto de GitHub.

AI Coding y Coding Agents

Esta categoría se centra en comprensión de código, modificación de código, flujos de ingeniería y agents de terminal. Es el grupo más grande, con 19 proyectos.

Proyecto	Artículo	GitHub	Uso principal	Para quién
Ralph	Ralph: convertir Claude Code y Amp en un ciclo autónomo de desarrollo	snarktank/ralph	Guiar Claude Code / Amp por PRD, planificación, ejecución y revisión	Quienes quieren ordenar el flujo de AI Coding
Claude-Mem	Claude-Mem: memoria de largo plazo entre sesiones para Claude Code	thedotmack/claude-mem	Añadir memoria entre sesiones a Claude Code	Usuarios intensivos de Claude Code
Claude Code Hooks Mastery	Claude Code Hooks Mastery: introducción a 13 etapas del ciclo de hooks	disler/claude-code-hooks-mastery	Aprender el ciclo de vida de hooks y control de automatización	Quienes quieren personalizar Claude Code
Compound Engineering Plugin	Compound Engineering Plugin: convertir AI Coding en ciclos de planificación, ejecución y revisión	EveryInc/compound-engineering-plugin	Dividir AI Coding en planificación, ejecución y revisión	Usuarios que buscan ingeniería más disciplinada
free-claude-code	free-claude-code: conectar Claude Code a OpenRouter, DeepSeek y modelos locales	Alishahryar1/free-claude-code	Conectar Claude Code a distintos backends mediante proxy	Usuarios que quieren reducir costes
Hermes Agent	Qué es Hermes Agent: visión general, ventajas, inicio rápido y comparación con OpenClaw	NousResearch/hermes-agent	Framework local de Agent con herramientas y ejecución de tareas	Usuarios que quieren correr Agents locales
OpenHarness	Qué puede hacer OpenHarness como Agent Harness open source	HKUDS/OpenHarness	Agent Harness y ejecución multi-agent	Investigadores de orquestación Agent
CodexBridge	Usar Codex con modelos nacionales: API compatibles con OpenAI y CodexBridge	begonia599/CodexBridge	Conectar Codex a APIs compatibles con OpenAI	Usuarios que quieren usar Codex con modelos nacionales
ccx	Usar CCX para gestionar APIs compatibles con OpenAI para Codex y modelos nacionales	BenedictKing/ccx	Gestionar proxies de API para Claude, Codex, Gemini y más	Usuarios que alternan varios modelos
cc-haha	cc-haha: un escritorio de trabajo para Claude Code	NanmiCoder/cc-haha	Workspace de escritorio y entrada Computer Use para Claude Code	Usuarios de Claude Code que prefieren GUI
DeepSeek-TUI	DeepSeek-TUI: convertir DeepSeek V4 en un agente de programación en terminal	Hmbown/DeepSeek-TUI	Ejecutar un agente de programación DeepSeek en terminal	Usuarios de DeepSeek y línea de comandos
Open Design	Open Design: convertir Claude Code y Codex en herramientas de diseño AI	nexu-io/open-design	Llevar Claude Code / Codex a generación de diseño	Usuarios que quieren agentes para prototipos
agentmemory	agentmemory: memoria persistente para Claude Code, Codex y Cursor	rohitg00/agentmemory	Añadir memoria persistente a coding agents	Desarrolladores con proyectos largos
Graphify	Graphify: convertir una base de código en un grafo consultable por AI	safishamsi/graphify	Convertir código en grafo de conocimiento para reducir lecturas repetidas	Usuarios con bases de código grandes
CC Switch	CC Switch: gestionar Claude Code, Codex, Gemini CLI y OpenClaw en una herramienta de escritorio	farion1231/cc-switch	Gestionar varias CLI de AI y cambios de cuenta/configuración	Usuarios de varias CLI
Warp	Warp open source: del terminal al Agentic Development Environment	warpdotdev/warp	Terminal y entorno de desarrollo agentic	Usuarios intensivos de terminal
opencode	opencode vs Claude Code vs Codex: guía de herramientas open source de AI Coding	anomalyco/opencode	Agent open source para AI Coding	Quienes buscan alternativas a Claude Code / Codex
9Router	9Router: conectar Claude Code, Codex y Cursor a un único router de AI	decolua/9router	Ruteo de modelos para AI Coding y control de coste de tokens	Usuarios multi-herramienta y multi-modelo
goose	goose: AI Agent open source para escritorio, CLI y API	aaif-goose/goose	Agent open source en escritorio, CLI y API	Usuarios que quieren un workspace Agent general

Skills y flujos Agent

Esta categoría convierte capacidades de AI en skills, procesos y especificaciones repetibles. Incluye 7 proyectos.

Proyecto	Artículo	GitHub	Uso principal	Para quién
mattpocock/skills	Rechazar Vibe Coding: el repo skills de Matt Pocock añade restricciones de ingeniería	mattpocock/skills	Usar skills para controlar flujos de AI Coding	Quienes quieren disciplina de ingeniería para Agents
Superpowers	Superpowers: devolver Coding Agents al flujo de ingeniería	obra/superpowers	Framework de skills agentic y metodología de desarrollo	Quienes quieren flujos sistemáticos con Coding Agents
Prompt-Vault	Prompt-Vault: biblioteca de especificaciones de prompts para probar AI Coding	w512/Prompt-Vault	Reunir prompts de prueba para AI Coding	Evaluadores de modelos y herramientas
web-video-presentation	web-video-presentation: skill Agent para convertir artículos en videos web grabables	ConardLi/garden-skills	Convertir artículos en videos web grabables	Creadores y usuarios de automatización
nuwa-skill	nuwa-skill: convertir “destilar una persona” en un flujo ejecutable	alchaincyf/nuwa-skill	Reproducir estilo expresivo y flujo de pensamiento con skill	Usuarios que construyen Agents de estilo
Scientific Agent Skills	Scientific Agent Skills: entregar flujos científicos a AI Agents	K-Dense-AI/scientific-agent-skills	Colección de skills para investigación científica	Investigadores, analistas y redactores técnicos
easy-vibe	easy-vibe: mapa de aprendizaje para principiantes de Vibe Coding	datawhalechina/easy-vibe	Mapa de aprendizaje de Vibe Coding	Principiantes de AI Coding

RAG, bases de conocimiento y memoria

Esta categoría aborda búsqueda documental, construcción de bases de conocimiento, memoria de largo plazo y extracción estructurada. Incluye 7 proyectos.

Proyecto	Artículo	GitHub	Uso principal	Para quién
LangExtract	Google LangExtract: extraer datos estructurados de textos largos con LLM	google/langextract	Extraer información estructurada de textos largos	Usuarios de extracción de información y datos
qmd	qmd: búsqueda local en Markdown para AI Agents	tobi/qmd	Búsqueda local en documentos Markdown	Usuarios que gestionan conocimiento en Markdown
Firecrawl	Firecrawl: búsqueda, crawling e interacción web para AI Agents	firecrawl/firecrawl	Crawling web, búsqueda y entrada de datos estructurados	Usuarios de RAG e ingestión de datos para Agents
RAGFlow	RAGFlow: funciones y uso de un motor RAG open source	infiniflow/ragflow	Motor RAG open source	Bases de conocimiento empresariales y Q&A documental
OpenHuman	OpenHuman: ruta de escritorio para AI Agent personal open source	tinyhumansai/openhuman	Agent personal local-first y capa de memoria	Usuarios que quieren integrar datos personales
OpenKB	OpenKB: compilar documentos en bases de conocimiento LLM actualizables	VectifyAI/OpenKB	Compilar documentos en bases de conocimiento actualizables	Mantenedores de documentación y conocimiento
PageIndex	PageIndex: indexación RAG razonada sin bases vectoriales	VectifyAI/PageIndex	Indexación documental razonada sin bases vectoriales	Usuarios que siguen nuevas rutas de RAG

Multimodal y creación de contenido

Esta categoría cubre imágenes, video, transcripción y distribución de contenido. Incluye 5 proyectos.

Proyecto	Artículo	GitHub	Uso principal	Para quién
rembg	rembg: herramienta local para quitar fondos de imágenes	danielgatis/rembg	Eliminación local de fondos	E-commerce, diseño y procesamiento de imágenes
awesome-gpt-image-2-prompts	Biblioteca de prompts GPT-Image 2: e-commerce, pósters, retratos y UI	EvoLinkAI/awesome-gpt-image-2-prompts	Prompts y casos para GPT-Image 2	Usuarios de AI Art y prompts
faster-whisper	faster-whisper: motor Whisper más rápido para transcripción	SYSTRAN/faster-whisper	Speech-to-text de alto rendimiento	Usuarios de subtítulos, transcripción y voz
Pixelle-Video	Pixelle-Video: motor AI open source para generar videos cortos desde un tema	AIDC-AI/Pixelle-Video	Flujo para generar videos cortos desde un tema	Creadores de videos cortos y AIGC
AiToEarn	¿Demasiadas plataformas de contenido? AiToEarn usa Agents para ahorrar trabajo	yikart/AiToEarn	Distribución multicanal y automatización para creadores	Operadores de contenido y creadores

Modelos locales e inferencia

Esta categoría se centra en ejecución local de modelos y experimentos de inferencia. Actualmente tiene menos proyectos, con 1 proyecto.

Proyecto	Artículo	GitHub	Uso principal	Para quién
ds4	Ejecutar DeepSeek 4 localmente: Antirez ds4 en Apple Silicon Mac	antirez/ds4	Experimentar con DeepSeek 4 en Apple Silicon	Usuarios de modelos locales e inferencia

Aplicaciones verticales y automatización

Esta categoría aplica Agents o AI a finanzas, trading, navegadores, escritorio, monitoreo de comercio electrónico y otros escenarios concretos. Incluye 7 proyectos.

Proyecto	Artículo	GitHub	Uso principal	Para quién
TradingAgents-CN	TradingAgents-CN: framework multi-agent para investigación de trading financiero en chino	hsliuping/TradingAgents-CN	Framework multi-agent de investigación financiera	Investigadores quant, financieros y de Agents
FinceptTerminal	FinceptTerminal: terminal financiero open source, investigación quant y workspace AI Agent	Fincept-Corporation/FinceptTerminal	Terminal financiero, investigación quant y workspace Agent	Analistas financieros y usuarios quant
Anthropic financial-services	Anthropic financial-services: plantillas reutilizables para escenarios Agent financieros	anthropics/financial-services	Plantillas de Agents para servicios financieros	Usuarios que crean soluciones AI financieras
ai-goofish-monitor	ai-goofish-monitor: sistema open source de monitoreo AI para productos de Xianyu	Usagi-org/ai-goofish-monitor	Monitoreo de productos y automatización de Xianyu	Usuarios de monitoreo de segunda mano
CloakBrowser	CloakBrowser: navegador más humano para Playwright y Puppeteer	CloakHQ/CloakBrowser	Entorno de automatización de navegador más humano	Automatización de navegador y operación Agent
UI-TARS-desktop	¿Dejar que AI use el ordenador? UI-TARS-desktop conecta escritorio, navegador y herramientas	bytedance/UI-TARS-desktop	Agent para operar escritorio, navegador y herramientas	Usuarios que quieren que AI opere el ordenador
AI-Trader	Qué es AI-Trader: plataforma para señales y simulación de trading con Agents	HKUDS/AI-Trader	Señales de trading y simulación con AI Agent	Investigadores de trading y Agents financieros

Infraestructura para aplicaciones de AI

Esta categoría ofrece componentes base para construir aplicaciones de AI y toolchains Agent. Incluye 3 proyectos.

Proyecto	Artículo	GitHub	Uso principal	Para quién
Prompt Optimizer	Prompt Optimizer: optimización, pruebas y herramientas MCP open source	linshenkx/prompt-optimizer	Optimización de prompts, pruebas y MCP	Usuarios de prompt engineering y ajuste de apps
Playwright CLI	Playwright CLI: instalación, skills, sesiones y comandos comunes	microsoft/playwright-cli	CLI de automatización de navegador para coding agents	Usuarios Agent que necesitan operar navegador
Vercel AI SDK	Qué es Vercel AI SDK: toolkit unificado para apps AI en TypeScript	vercel/ai	SDK para aplicaciones AI en TypeScript	Desarrolladores front-end y full-stack

Resumen de Google I/O 2026: Gemini 3.5, Omni, Antigravity y Agents a nivel de sistema

Thu, 21 May 2026 00:07:06 +0800

La línea principal de Google I/O 2026 es clara: Google está llevando Gemini desde “modelo” y “asistente de chat” hacia un ecosistema Agent más completo. Ya no se trata solo de responder preguntas. Gemini entra en Search, Android, herramientas de desarrollo, creación de video, compras, Workspace, hardware y plataformas empresariales para ayudar a los usuarios a completar cadenas de tareas más largas.

Este artículo resume los principales anuncios de Google I/O 2026 desde la información oficial y una perspectiva de desarrolladores. Para desarrollo real, conviene seguir siempre la documentación oficial de Google, Android Developers y Gemini API.

Resumen en una frase

La palabra clave de Google I/O 2026 es agentic Gemini era.

Google anunció o reforzó varias líneas:

Gemini 3.5 Flash: velocidad, capacidad de acción y flujos Agent.
Gemini Omni: crear contenido desde cualquier entrada, empezando por creación y edición de video.
Gemini app: pasar de asistente de chat a Agent personal proactivo, siempre disponible y capaz de ejecutar tareas.
Google Antigravity 2.0: evolucionar de herramienta de programación con IA a plataforma de desarrollo agent-first.
Gemini API Managed Agents: crear Agents alojados mediante API, capaces de razonar, usar herramientas y ejecutar código.
Google AI Studio: expansión a móvil, soporte nativo para Android y exportación de proyectos a Antigravity.
Search, Shopping, YouTube, Workspace y Android: todos incorporan capacidades más fuertes de Gemini y Agent.

En otras palabras, Google ya no solo muestra “qué tan inteligente es el modelo”, sino cómo el modelo entra en productos, herramientas y sistemas para ejecutar tareas reales para el usuario.

Gemini 3.5 Flash: del prompt a la acción

Gemini 3.5 es la nueva familia de modelos que Google presentó en I/O 2026, con Gemini 3.5 Flash como primer foco público.

Google no lo posiciona simplemente como “un modelo de chat más rápido”, sino como un motor de alta velocidad para flujos Agent reales. El artículo para desarrolladores de Google señala que 3.5 Flash combina inteligencia de frontera y alta velocidad para apoyar el paso de prompt a acción.

Su importancia principal:

Optimizado para escenarios Agent y coding.
Soporta cadenas de tareas más largas y uso de herramientas.
Disponible en Antigravity, Gemini API, Google AI Studio, Android Studio, Gemini Enterprise y otras entradas.
Más adecuado para aplicaciones que requieren respuesta rápida, ejecución en múltiples turnos y llamadas frecuentes a herramientas.

Para desarrolladores, Gemini 3.5 Flash no es solo otra opción de modelo. Es uno de los motores por defecto de la nueva cadena de herramientas Agent de Google.

Gemini Omni: video y capacidades de modelo del mundo

Gemini Omni es otro anuncio central de I/O 2026. Google lo describe como creación de contenido desde cualquier entrada, con foco inicial en video.

Sus puntos principales son tres:

Entrada multimodal: texto, imágenes, video, audio y más pueden usarse como referencia.
Edición de video: el usuario puede modificar video en múltiples turnos con lenguaje natural, en lugar de terminar tras una sola generación.
Comprensión del mundo: enfatiza consistencia física, escenas, acciones, narrativa y salida audiovisual.

Esto significa que las herramientas de video con IA pasan de “escribir un prompt para generar un clip” a “revisar paso a paso como si hablaras con un editor”. Para creadores, el valor real no es la generación de una sola vez, sino un flujo de edición controlable, trazable e iterativo.

Gemini App: de asistente de chat a Agent personal siempre activo

Google también empuja Gemini app hacia una dirección más agentic. Las publicaciones oficiales dicen que Gemini app será más proactiva, con briefs diarios y ayuda continua.

Algunos puntos clave:

Gemini 3.5 Flash llega a Gemini app.
Nueva UI e interacción más dinámica.
Conceptos de AI Agent personal como Gemini Spark.
Proactive daily briefs, que organizan de forma proactiva lo que el usuario debe atender cada día.
Más énfasis en asistencia de fondo 24/7, en lugar de esperar a que el usuario inicie cada chat.

Esta parte afecta más a usuarios normales. Antes Gemini se parecía más a un asistente de “preguntas y respuestas”. Después de I/O 2026, Google quiere que se parezca más a un Agent personal que sigue tareas, recuerda de forma proactiva y coordina entre productos.

Antigravity 2.0: las herramientas de desarrollo se vuelven Agent-first

Uno de los anuncios más importantes para desarrolladores es Google Antigravity 2.0.

Google posiciona Antigravity como agent-first development platform. Después de I/O 2026, no solo ayuda a escribir código, sino que busca ayudar al desarrollador desde la idea y el prototipo hasta la orquestación de Agents y la entrega de aplicaciones en producción.

Los cambios principales que menciona Google incluyen:

Aplicación de escritorio independiente Antigravity 2.0.
Orquestación paralela de múltiples Agents.
Subagents dinámicos.
Tareas programadas en segundo plano.
Integración con Google AI Studio, Android, Firebase y otros ecosistemas.
Antigravity CLI para usuarios de terminal.
Antigravity SDK para personalizar comportamiento y despliegue de Agents.

Esto muestra que las herramientas de programación con IA entran en una etapa posterior a “autocompletado / generación conversacional”: los desarrolladores gestionarán múltiples Agents ejecutables, no solo una ventana de chat.

Gemini API Managed Agents: alojar Agents como capacidades API

Google también presentó Managed Agents in the Gemini API.

Según la descripción oficial, estos Agents pueden crearse con una sola llamada API. Pueden razonar, usar herramientas y ejecutar código en un entorno Linux aislado, con soporte del Antigravity agent harness.

Esto es clave para desarrolladores:

No hace falta construir todo el runtime Agent por cuenta propia.
Se obtiene un entorno de ejecución persistente y aislado.
Las interacciones en múltiples turnos pueden conservar archivos y estado.
Se pueden extender Agents con markdown skills, instrucciones personalizadas y plantillas.
Están disponibles mediante Interactions API y Google AI Studio.

Si esta línea madura, las plataformas Agent se parecerán cada vez más a servicios cloud: los desarrolladores no solo llamarán a modelos, sino a Agents con estado, herramientas, entorno de ejecución y límites de seguridad.

Google AI Studio: de prompt playground a entrada de generación de apps

En I/O 2026, Google AI Studio también avanza.

Cambios principales:

Google AI Studio mobile app para capturar ideas y generar prototipos desde móvil.
Integración con Workspace API, para que los Agents accedan de forma más natural a Google Workspace.
Exportación de proyectos a Antigravity, llevando contexto al desarrollo local y a producción.
Soporte nativo para Android, permitiendo construir apps Android con prompts.
Integración con Google Play Console para publicar apps en canales de prueba.

Esto convierte AI Studio de “lugar para ajustar prompts y probar modelos” en una entrada desde la idea hasta la aplicación. Su relación con Antigravity también queda más clara: AI Studio sirve para idear y generar rápido; Antigravity para seguir desarrollando, orquestar, depurar y entregar.

Android y AppFunctions: interfaces clave para Agents móviles

Los Agents a nivel de sistema en Android son una dirección que merece atención propia, pero deben entenderse con interfaces y límites de producto precisos.

Lo más importante ahora es AppFunctions oficial de Android. La documentación lo describe como una API de plataforma Android con bibliotecas Jetpack, que permite a las apps exponer sus capacidades a agents, asistentes y otros llamadores autorizados. También simplifica la integración de Android MCP.

Su importancia está en que la automatización móvil ya no tiene que depender solo de capturas de pantalla, OCR, taps simulados y localización de controles UI.

La automatización móvil tradicional sigue este camino:

Reconocer la pantalla.
Encontrar el botón.
Simular un tap.
Esperar cambios de página.
Reintentar tras errores.

La dirección de AppFunctions es:

La app declara qué puede hacer.
El Agent llama esas capacidades con autorización.
El sistema gestiona permisos, límites de llamada y restricciones de seguridad.

Esto afectará al diseño de apps Android. Las apps futuras no solo tendrán que diseñar UI para humanos, sino también convertir sus funciones centrales en interfaces invocables por Agents.

Search, compras y productos de contenido también se vuelven agentic

Los cambios de Google I/O 2026 no están solo en modelos y herramientas de desarrollo. Search y productos de consumo también cambian en paralelo.

Los resúmenes oficiales de I/O mencionan:

Search entra en una nueva etapa de AI Search.
Information agents aparecen en escenarios de búsqueda.
Gemini Spark y Daily Brief llegan a Gemini app.
Universal Cart hace más inteligente el carrito de compras.
Ask YouTube permite consultar y navegar contenido de video de forma conversacional.
Las capacidades de Gemini se expanden a más productos y formatos.

Estos anuncios muestran que la dirección Agent de Google no es un producto aislado, sino una expansión horizontal hacia búsqueda, video, compras, productividad, móvil y hardware.

Impacto práctico para desarrolladores

El mayor impacto de Google I/O 2026 para desarrolladores no es “otro modelo más”, sino que cambia el objeto de desarrollo.

Antes los desarrolladores construían principalmente:

Apps.
Sitios web.
APIs.
Plugins.
Scripts de automatización.

Ahora también tendrán que construir:

Capacidades de app invocables por Agents.
Flujos de trabajo multi-Agent.
Entornos de ejecución de herramientas con estado.
Flujos de automatización auditables.
Mecanismos human-in-the-loop.
Integraciones con MCP, AppFunctions, Workspace API, Playwright, Firebase y otras herramientas.

El software se parecerá cada vez más a un “conjunto de capacidades”, no solo a un “conjunto de interfaces”. Quien exponga sus capacidades de forma clara, fiable y segura a Agents tendrá más posibilidades de entrar en las cadenas de tareas automatizadas del usuario.

Impacto en automatización móvil

La automatización móvil pasará gradualmente de “GUI primero” a “interfaces primero, GUI como respaldo”.

A corto plazo, reconocimiento de capturas, OCR, taps simulados y automatización de navegador siguen teniendo valor, porque muchas apps antiguas no tienen interfaces estándar.

A largo plazo, si Android AppFunctions, MCP y el modelo de permisos a nivel de sistema maduran, la ejecución estable de tareas tenderá a:

Llamar primero capacidades declaradas por la app.
Llamar interfaces del sistema cuando sea necesario.
Usar automatización GUI como respaldo cuando no haya otra opción.

Esto cambiará RPA, Agents móviles, herramientas de prueba y ecosistemas de apps. Las apps que expongan capacidades serán más fáciles de invocar por Agents a nivel de sistema. Las que no lo hagan quizá sigan dependiendo del viejo método de “mirar pantalla y tocar pantalla”.

Seguridad, permisos y auditoría serán requisitos duros

Cuanto más fuertes sean los Agents, mayor será el riesgo.

Si un Agent puede ejecutar tareas entre apps, invocar pagos, cambiar configuraciones, acceder a archivos y leer contexto, necesita límites de seguridad claros:

Niveles de permisos.
Autorización explícita del usuario.
Confirmación secundaria para acciones sensibles.
Aislamiento por sandbox.
Logs de operación.
Capacidad de deshacer y rollback.
Auditoría y cumplimiento empresarial.

Por eso Google enfatiza entornos aislados para Agents alojados, requisitos de permisos de AppFunctions, plataformas empresariales y despliegues controlados. El futuro de los Agents no es “poder hacer todo sin límites”, sino ejecutar de forma controlada, trazable y gobernable dentro de límites de seguridad.

Resumen

El contenido principal de Google I/O 2026 puede resumirse así: Google está convirtiendo Gemini en una plataforma Agent que cruza modelos, apps, sistemas, herramientas de desarrollo y hardware.

Gemini 3.5 Flash aporta velocidad y capacidad de acción. Gemini Omni lleva la creación multimodal hacia video y comprensión del mundo. Gemini app avanza hacia asistente personal proactivo. Antigravity 2.0 y Managed Agents empujan las herramientas de desarrollo hacia lo Agent-native. AppFunctions permite que las apps Android empiecen a exponer capacidades a agentes inteligentes.

Para desarrolladores, lo siguiente a vigilar no son solo parámetros de modelo, sino cómo estructurar capacidades de aplicación, cómo integrarse con cadenas de herramientas Agent, cómo diseñar permisos y auditoría, y cómo hacer que los productos sean invocables de forma segura y fiable dentro de un ecosistema Agent a nivel de sistema.

Referencias:

Qué es PageIndex: un índice documental RAG basado en razonamiento sin bases vectoriales

Wed, 20 May 2026 23:51:37 +0800

VectifyAI/PageIndex es un proyecto RAG interesante. No parte de “crear otra base de datos vectorial”, sino que primero organiza documentos largos en una estructura de árbol similar a una tabla de contenidos, y luego deja que un LLM haga recuperación basada en razonamiento siguiendo ese árbol.

Proyecto: VectifyAI/PageIndex

En el momento de preparar este artículo, la página de GitHub muestra unas 31.8k stars y 2.7k forks, con licencia MIT. El README lo define como Vectorless, Reasoning-based RAG: RAG sin base vectorial y basado en razonamiento.

Qué problema intenta resolver

El flujo común del RAG tradicional es: dividir en chunks, vectorizar, escribir en una base de datos vectorial y recuperar fragmentos mediante búsqueda por similitud. Es un enfoque simple, general y maduro, pero en documentos profesionales largos suele encontrar varios problemas:

La similitud no equivale a relevancia real.
La estructura del documento se rompe por el chunking, y se pierden relaciones entre secciones.
Los resultados de recuperación tienen poca explicabilidad; cuesta explicar por qué se eligió ese fragmento.
En informes financieros, documentos regulatorios, textos legales o manuales técnicos, las preguntas suelen requerir razonamiento entre secciones.

La idea de PageIndex es la inversa: primero organizar el documento como un árbol semántico, y después hacer que el modelo busque como una persona que lee el índice, entra en capítulos y localiza información por niveles.

Flujo básico de PageIndex

El README divide la recuperación de PageIndex en dos pasos:

Generar para el documento un índice en árbol parecido a Table-of-Contents.
Hacer reasoning-based retrieval mediante búsqueda en árbol.

Este árbol no es un simple directorio de archivos, sino una estructura documental pensada para LLMs. Los nodos pueden incluir títulos, rangos de páginas, resúmenes, nodos hijos y otros datos. Así, al responder una pregunta, el modelo no tiene que enfrentarse de entrada a una gran cantidad de chunks sueltos; primero puede decidir a qué sección entrar y luego seguir buscando hacia abajo.

Este enfoque encaja mejor con documentos bien estructurados pero muy largos, como:

Informes financieros y SEC filings.
Material regulatorio y documentos de cumplimiento.
Libros académicos y papers.
Documentos legales.
Manuales técnicos y documentación de producto.
PDFs grandes que superan la ventana de contexto del modelo.

Diferencias con el RAG vectorial tradicional

Los principales puntos de PageIndex se pueden resumir en cinco.

Primero, no necesita Vector DB. Usa estructura documental y razonamiento del LLM para localizar contenido, en lugar de depender solo de búsqueda por similitud vectorial.

Segundo, no usa chunking tradicional. Los documentos se organizan por secciones naturales, no por fragmentos de longitud fija.

Tercero, ofrece mejor explicabilidad. La ruta de recuperación puede asociarse con páginas, secciones y nodos del árbol, lo que es más fácil de rastrear que “este texto fue encontrado por similitud vectorial”.

Cuarto, la recuperación es sensible al contexto. La pregunta, el historial de conversación y el conocimiento del dominio pueden influir en la ruta de búsqueda por árbol.

Quinto, se parece más a cómo los expertos humanos leen documentos. Normalmente no cortamos un documento entero en trozos para calcular similitud; primero revisamos el índice, ubicamos capítulos y luego leemos detalles.

Esto no significa que las bases vectoriales no tengan valor. Una forma más precisa de verlo es que PageIndex encaja en escenarios donde “la similitud semántica no basta y se necesita estructura más razonamiento” para recuperar información en documentos largos.

Cómo ejecutarlo localmente

El README ofrece una ruta de autoalojamiento local. Primero instala dependencias:

`1`	`pip3 install --upgrade -r requirements.txt`

Después crea un archivo .env en la raíz del proyecto y escribe la LLM API key. El proyecto admite múltiples modelos mediante LiteLLM:

`1`	`OPENAI_API_KEY=your_openai_key_here`

Genera la estructura PageIndex para un PDF:

`1`	`python3 run_pageindex.py --pdf_path /path/to/your/document.pdf`

También puede procesar Markdown:

`1`	`python3 run_pageindex.py --md_path /path/to/your/document.md`

Parámetros opcionales habituales:

--model
--toc-check-pages
--max-pages-per-node
--max-tokens-per-node
--if-add-node-id
--if-add-node-summary
--if-add-doc-description

El README también advierte que la versión local de código abierto usa parsing PDF estándar. Para PDFs complejos, el servicio cloud del proyecto ofrece OCR mejorado, construcción de árbol y flujo de recuperación.

Ejemplo de Agentic Vectorless RAG

El proyecto también incluye un ejemplo de agentic vectorless RAG usando PageIndex autoalojado y OpenAI Agents SDK. Instala la dependencia opcional y ejecútalo:

1
2

pip3 install openai-agents
python3 examples/agentic_vectorless_rag_demo.py

El valor de este ejemplo está en que lleva PageIndex de “generar un árbol documental” a “permitir que un Agent use el árbol para recuperar información”. Si estás construyendo una base de conocimiento empresarial, Q&A sobre informes financieros, preguntas regulatorias o un Agent de documentación técnica, vale más la pena correr este ejemplo que limitarse a leer el README.

Servicio cloud, MCP y API

PageIndex no es solo un GitHub repo. La página del proyecto también ofrece varias entradas:

Autoalojamiento: ejecutar el código abierto en local, adecuado para pruebas y despliegues controlados.
Chat Platform: una plataforma de análisis documental estilo ChatGPT.
MCP / API: útil para integrarse con Agents existentes o flujos de automatización.
Enterprise: orientado a despliegues privados u on-premises.

Esto muestra que su posición no es la de una simple demo. Busca convertir la “recuperación documental basada en razonamiento” en una infraestructura de inteligencia documental integrable.

Escenarios adecuados

PageIndex encaja bien con tareas como:

Preguntas y respuestas sobre PDFs largos.
Análisis de informes financieros, informes anuales, prospectos y documentos regulatorios.
Recuperación en documentos legales y de cumplimiento.
Q&A sobre manuales técnicos.
Recuperación en libros o papers con múltiples secciones.
Bases de conocimiento empresariales que necesitan rutas de recuperación explicables.
Proporcionar contexto documental estructurado a Agents.

Si tu material es corto, tiene poca estructura o es simplemente un FAQ común, embedding + vector DB tradicional puede ser suficiente. Las ventajas de PageIndex aparecen con más claridad en documentos largos, estructura fuerte, dominios profesionales y preguntas que requieren razonamiento.

Aspectos a tener en cuenta

Primero, PageIndex sigue dependiendo de LLMs. La construcción del árbol, los resúmenes y la calidad de recuperación se ven afectados por la capacidad del modelo, los prompts y la calidad del parsing documental.

Segundo, la versión local usa parsing PDF estándar. Documentos escaneados complejos, PDFs con muchas tablas y gráficos, o materiales con maquetación desordenada pueden requerir OCR y preprocesamiento más potente.

Tercero, sin base vectorial no significa coste cero. Construir el árbol también consume llamadas al modelo y tiempo, especialmente en colecciones documentales grandes.

Cuarto, PageIndex se parece más a un marco de indexación estructural y recuperación por razonamiento. No reemplaza directamente todas las pilas RAG. En producción, también puede combinarse con recuperación vectorial, búsqueda por palabras clave, control de permisos, caché y sistemas de auditoría.

Resumen

Lo interesante de PageIndex es que desplaza el foco del RAG desde la “recuperación por similitud textual” hacia “estructura documental + razonamiento LLM”. Para documentos largos y profesionales, esta dirección merece atención.

Si estás construyendo Q&A documental empresarial, análisis de informes financieros, recuperación regulatoria o Agents para manuales técnicos, PageIndex puede servir como referencia de una nueva arquitectura RAG: primero dar estructura al documento y luego dejar que el modelo razone sobre esa estructura, en lugar de trocear todo desde el principio y meterlo en una base vectorial.

Referencias:

GitHub: VectifyAI/PageIndex

Gemini 3.5 ya está aquí: Flash llega primero y Google pone el foco en agentes y tareas largas

Wed, 20 May 2026 22:51:31 +0800

Google lanzó oficialmente la serie Gemini 3.5 el 20 de mayo de 2026. El primer modelo disponible es Gemini 3.5 Flash. Su posicionamiento no es solo chat, sino agentes, generación de código y ejecución de tareas complejas de larga duración.

El mensaje de esta presentación es claro: Google quiere que Gemini 3.5 no solo responda preguntas, sino que también planifique, ejecute, compruebe resultados y mantenga el avance en flujos de trabajo de varios pasos.

Gemini 3.5 Flash llega primero

Gemini 3.5 Flash ya está disponible para varios tipos de usuarios:

Los usuarios generales pueden probarlo en la app Gemini y en AI Mode de Google Search.
Los desarrolladores pueden usarlo mediante Google Antigravity, Google AI Studio y la Gemini API en Android Studio.
Los usuarios empresariales pueden acceder a él mediante Gemini Enterprise Agent Platform y Gemini Enterprise.

Google también dijo que Gemini 3.5 Pro sigue en desarrollo, ya se usa internamente en Google y se espera para el próximo mes.

Esto indica que la serie 3.5 mantiene la división entre Flash y Pro: Flash enfatiza velocidad, costo y ejecución a escala, mientras que Pro probablemente apuntará a escenarios más complejos y con mayores requisitos de capacidad.

El foco está en agentes y código

Google describe Gemini 3.5 Flash como uno de sus modelos más fuertes para agentes y programación. El anuncio afirma que supera algunos resultados de Gemini 3.1 Pro en benchmarks de código y agentes como Terminal-Bench 2.1, GDPval-AA, MCP Atlas y CharXiv Reasoning.

La mayoría de usuarios no necesita obsesionarse con cada número. Lo más importante es que Google está llevando la capacidad del modelo hacia flujos ejecutables: no solo escribir código, sino migrar proyectos antiguos, desarrollar aplicaciones complejas, organizar reportes financieros, analizar datos y ejecutar pruebas repetidas.

Dentro del framework de desarrollo Antigravity, Gemini 3.5 Flash puede usar varios subagents colaborativos para manejar tareas grandes. Google mostró ejemplos como analizar el paper de AlphaZero y crear un juego jugable, convertir código legacy a Next.js y generar paisajes urbanos y opciones de UI en paralelo.

La dirección es clara: las herramientas de programación con IA están pasando de “generar un fragmento de código” a “coordinar varios agentes para completar un proyecto”.

UI multimodal y gráficos más potentes

Gemini 3.5 Flash se apoya en la base multimodal de Gemini 3. Google dice que puede generar interfaces web más ricas, animaciones interactivas y contenido visual.

El anuncio incluye ejemplos como:

Crear animaciones interactivas para papers de investigación.
Convertir descripciones de texto en modelos de hardware interactivos.
Generar un concepto completo de marca para una campaña escolar de recaudación.
Producir varias opciones de UX para un flujo de checkout en poco tiempo.

Esto importa para desarrolladores y equipos de producto. El modelo ya no solo escribe explicaciones. También puede participar en prototipos frontend, diseño de interacción y visualización.

Uso empresarial: automatizar flujos que consumen tiempo

Google citó varios ejemplos de socios. Shopify usa subagents para analizar datos complejos y predecir crecimiento de comerciantes. Macquarie Bank prueba 3.5 Flash con documentos de más de 100 páginas para acelerar la apertura de cuentas. Salesforce lo integra en Agentforce. Ramp lo usa para mejorar OCR en facturas complejas. Xero usa agentes de IA para procesos administrativos. Databricks usa flujos automatizados para monitorear anomalías de datos y sugerir correcciones.

Estos casos apuntan a la misma tendencia: la adopción empresarial de modelos grandes se está moviendo de preguntas puntuales a automatización de procesos. Que un modelo sea barato, rápido y estable en tareas largas puede importar más que una respuesta aislada muy llamativa.

Gemini Spark: un agente personal de IA

Google también anunció Gemini Spark, un agente personal de IA impulsado por Gemini 3.5 Flash. Su objetivo es ejecutarse durante largos periodos y realizar tareas de forma proactiva bajo la guía del usuario.

Gemini Spark ya empezó a desplegarse para testers de confianza. Google planea abrir una beta la próxima semana para suscriptores de Google AI Ultra en Estados Unidos.

Vale la pena seguir esta parte. Google Search, la app Gemini, Android, Workspace y el ecosistema del navegador ya están presentes en muchas áreas de la vida digital personal. Si un agente personal puede conectarse con estas entradas, su impacto puede ser mayor que el de un chatbot aislado.

La seguridad se mueve más arriba en el proceso

Google dice que Gemini 3.5 fue desarrollado bajo su Frontier Safety Framework, con protecciones reforzadas para seguridad de la información y riesgos CBRN. El anuncio también menciona herramientas de interpretabilidad para ayudar a examinar y entender el razonamiento del modelo antes de entregar respuestas.

Esto muestra que los lanzamientos de modelos frontera ya no son solo una competencia de capacidad. Cuanto más se enfatizan agentes, ejecución autónoma y tareas largas, más importantes se vuelven los controles de seguridad, la tasa de rechazos erróneos, la prevención de salidas dañinas y la interpretabilidad.

Cómo mirar Gemini 3.5

Gemini 3.5 Flash no es solo otro lanzamiento de modelo. Parece más bien la apuesta de Google por la siguiente forma de los productos de IA: modelos que llaman herramientas, dividen tareas, coordinan ejecución, generan UI y entran en flujos personales y empresariales.

Para desarrolladores, lo importante será la experiencia real en Google Antigravity, AI Studio, Gemini API y Android Studio. Para empresas, la pregunta es si puede reducir trabajo manual de forma estable en flujos reales, no solo sacar buenos resultados en benchmarks.

Gemini 3.5 Pro todavía no está disponible públicamente. Cuando Pro llegue, las diferencias entre Flash y Pro en capacidad, precio, velocidad y manejo de contexto determinarán para qué escenarios de producción conviene cada uno.

Referencias:

Google Blog: Gemini 3.5

¿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.

Qué es AI-Trader: una plataforma para que AI Agents publiquen señales y hagan paper trading

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

HKUDS/AI-Trader es un proyecto de plataforma de trading para AI Agents. El README lo define como una “Agent-Native Trading Platform”: una plataforma para que agentes de IA se conecten, publiquen señales de trading, participen en discusiones, copien operaciones y usen datos de mercado.

URL del proyecto: https://github.com/HKUDS/AI-Trader

URL de la plataforma: https://ai4trade.ai

En el momento de escribir este artículo, la API de GitHub mostraba unas 18k estrellas y Python como lenguaje principal. La API del repositorio no devolvió un valor de licencia claro, así que conviene confirmar los términos antes de un uso formal.

Este artículo solo presenta el proyecto open source y no constituye asesoramiento de inversión. El trading automatizado implica riesgo de capital real. Ninguna estrategia, señal o salida de agente garantiza rentabilidad.

Posicionamiento

La idea central de AI-Trader es simple: si los humanos tienen plataformas de trading, quizá los AI Agents también necesiten una plataforma propia.

Según el README, cualquier AI Agent puede leer el archivo Skill de la plataforma y registrarse rápidamente:

`1`	`Read https://ai4trade.ai/skill/ai4trade and register on the platform. Compatibility alias: https://ai4trade.ai/SKILL.md`

Después de conectarse, los agentes pueden publicar señales, participar en discusiones, copiar estrategias de traders con buen rendimiento, sincronizar señales con varios brokers y acumular puntos según desempeño predictivo.

Funciones principales

El README lista capacidades como:

Instant Agent Integration: acceso rápido para AI Agents.
Collective Intelligence Trading: varios agentes colaboran y discuten ideas.
Cross-Platform Signal Sync: sincronización de señales entre plataformas.
One-Click Copy Trading: seguimiento de traders o agentes seleccionados.
Universal Market Access: acciones, cripto, forex, opciones, futuros y más.
Three Signal Types: señales de estrategia, acción y discusión.
Reward System: puntos por señales y atención recibida.

Desde el producto, no es solo un framework local de backtesting cuantitativo. Combina agentes, señales, discusión, copy trading y paper trading en una misma capa de plataforma.

Dos tipos de usuarios

El README divide los usuarios en dos grupos.

El primero es Agent Traders. Los AI Agents leen el documento Skill, se conectan a la plataforma, instalan componentes necesarios y publican señales.

El segundo es Human Traders. Los usuarios normales pueden visitar la plataforma, crear cuentas, revisar señales o seguir a traders con mejor rendimiento.

Juntos forman una estructura donde AI Agents producen señales y humanos u otros agentes las consumen.

Arquitectura

El README muestra esta estructura:

AI-Trader (GitHub - Open Source)
念岸岸 skills/              # Agent skill definitions
念岸岸 docs/api/            # OpenAPI specifications
念岸岸 service/             # Backend & frontend
岫   念岸岸 server/         # FastAPI backend
岫   弩岸岸 frontend/        # React frontend
弩岸岸 assets/              # Logo and images

El repositorio agrupa skills de agente, documentación API, backend y frontend. El backend usa FastAPI y el frontend React. Las notas del README también mencionan separación entre servicio web y workers backend, para que tareas de precios, rendimiento histórico, liquidación e inteligencia de mercado corran en segundo plano sin afectar páginas ni health checks.

Por qué merece atención

AI-Trader merece atención no porque “la IA pueda ganar dinero automáticamente”, sino porque explicita mejor la interfaz entre agentes y escenarios financieros.

Hay varios puntos interesantes.

Primero, usa un documento Skill como punto de entrada para agentes. Esto se parece al modo de trabajo de Codex, Claude Code, OpenClaw y otras herramientas de agentes.

Segundo, coloca señales, discusión, copy trading y sistema de recompensas en la capa de plataforma, no solo en un script local.

Tercero, ofrece documentación OpenAPI, lo que facilita entender las interfaces.

Cuarto, soporta paper trading. Para investigar decisiones de agentes, un entorno simulado es mucho más seguro que dar acceso directo a dinero real.

Riesgos y límites

El trading automatizado es un escenario de alto riesgo.

Primero, las señales generadas por agentes no son asesoramiento de inversión. Los modelos pueden alucinar, sobreajustar, leer mal noticias o no entender condiciones extremas.

Segundo, el copy trading tiene riesgo de contagio. Si muchos siguen una señal errónea, las pérdidas pueden concentrarse.

Tercero, el acceso a capital real debe aislarse estrictamente. No se debe dar a un agente permiso ilimitado para enviar órdenes.

Cuarto, antes de uso comercial o en producción hay que revisar licencias y cumplimiento, especialmente si intervienen brokers, datos financieros y cuentas de usuario.

Para quién es

AI-Trader encaja con investigadores de toma de decisiones de agentes, desarrolladores que exploran interfaces financieras para agentes y equipos interesados en paper trading o colaboración con señales. No es para quien busca una herramienta de ganancias garantizadas.

Resumen

AI-Trader es una plataforma de señales y paper trading diseñada alrededor de AI Agents. La lectura útil no es “la IA te hace ganar dinero”, sino “cómo deberían conectarse los agentes a flujos financieros, publicar señales y operar dentro de límites de riesgo controlados”.

Panorama de herramientas AI PPT populares: cómo elegir entre generación automática, presentaciones web, PPTX e imágenes

Mon, 18 May 2026 22:29:43 +0800

Hacer PPT con IA ya no consiste solo en “escribir un título y aplicar una plantilla”. En entornos de programación con IA como Claude Code, Codex y Cursor, la generación de PPT se está convirtiendo en un conjunto de Agent Skills instalables y reutilizables: algunas generan presentaciones web, otras crean archivos .pptx realmente editables, otras usan modelos de imagen para convertir cada diapositiva en un borrador visual, y otras permiten que la IA opere archivos de PowerPoint mediante MCP.

Aquí organizamos un grupo de Skills populares relacionadas con PPT. Lo valioso no es solo la lista, sino separar estas herramientas por forma de entrega. Antes de elegir una herramienta, conviene hacer una pregunta: quién va a editar el entregable final, dónde se va a presentar y si necesita colaboración posterior.

Varias rutas

1. Presentaciones web HTML

Algunos proyectos representativos son frontend-slides, guizang-ppt-skill y html-ppt-skill.

La ventaja de esta ruta es su capacidad visual. Se pueden usar animaciones CSS, Canvas, WebGL y diseño responsive. Basta abrir el resultado en un navegador para presentarlo, así que encaja con charlas técnicas, lanzamientos de producto, Demo Day y presentaciones con un estilo personal fuerte.

El coste también es claro: después de la entrega no es ideal para clientes que necesitan editar texto punto por punto. Si el cliente recibe HTML en lugar de un archivo de PowerPoint, los cambios posteriores suelen tener que volver al flujo de generación.

Si solo miramos presentaciones HTML, frontend-slides se parece más a una entrada general con muchas estrellas, guizang-ppt-skill destaca por sus restricciones estéticas y estilo temático, y html-ppt-skill sobresale por cantidad de temas, layouts y modo de presentador.

2. PPTX nativo

Algunos proyectos representativos son mckinsey-pptx, ppt-agent-skills, claude-office-skills y ppt-master.

Esta es la ruta más estable para entregas de negocio. Si el cliente pide “poder editar texto, cambiar imágenes y aplicar la plantilla de la empresa en PowerPoint”, el resultado final debe llegar a .pptx.

ppt-master merece una mención aparte. Su idea es pedir primero al LLM que genere SVG y luego convertirlo en objetos DrawingML nativos de PowerPoint. El objetivo es que cuadros de texto, formas y gráficos sigan siendo editables dentro del PPTX. También puede generar PPTX desde PDF, DOCX, URL y Markdown, además de replicar plantillas, añadir animaciones, narración y vista previa local.

Esta ruta encaja con entregas de consultoría, reportes corporativos, presentaciones de white papers y conversión de informes largos en PPT. La desventaja es que el techo visual suele estar limitado por PowerPoint, por lo que los efectos complejos no son tan libres como en HTML o en rutas basadas en imágenes.

3. Flujos impulsados por imágenes de IA

Algunos proyectos representativos son NanoBanana-PPT-Skills, gpt_image_2_skill y ppt-image-first.

Esta ruta trata cada diapositiva primero como una imagen visual, y luego coloca esas imágenes en PPTX u otro contenedor. Su ventaja es un alto nivel de acabado visual, especialmente para portadas, gráficos de redes sociales, propuestas visuales y contenido orientado a difusión.

El problema es la baja editabilidad. La página es, en esencia, una imagen. Si luego hay que cambiar un título, reemplazar un párrafo o mover un icono, quizá haya que regenerarla. Sirve para “que se vea bien”, pero no para “el cliente va a revisarlo muchas veces”.

4. MCP / capa de protocolo

Algunos proyectos representativos son Office-PowerPoint-MCP-Server y PPTAgent.

Estas herramientas no necesariamente generan un PPT completo directamente. Más bien le dan a la IA una interfaz para operar PowerPoint. Tras conectarse con MCP, el modelo puede leer, modificar y escribir archivos .pptx.

Esta ruta encaja con flujos donde ya existe un archivo PPT y se necesita ayuda de IA para modificarlo. Por ejemplo, cambiar formato en lote, reordenar páginas según feedback o pedir al modelo que revise si cada diapositiva cumple el objetivo. PPTAgent enfatiza la generación reflexiva: después de generar cada diapositiva vuelve a revisarla. Esa dirección ayuda a reducir el problema de que “los PPT de IA se ven toscos”.

5. Plataformas de diseño integradas

Algunos proyectos representativos son open-design y docsagent.

Estos proyectos ya van más allá de la generación de PPT. open-design se parece más a una plataforma de diseño local-first: puede generar prototipos, slides, images y videos, y admite varios formatos de exportación. docsagent no es una herramienta de PPT, pero puede indexar documentos locales y conversar con ellos, por lo que sirve como capa de organización de materiales antes de generar PPT.

Si tu necesidad no es hacer un PPT puntual, sino un flujo completo desde materiales, diseño y prototipo hasta entrega, este tipo de plataforma merece más atención.

Metadatos de Skills

Los conteos de Star vienen del resultado capturado el 2026-05-15. Solo sirven como referencia de popularidad. Antes de usarlos en serio, conviene abrir de nuevo los repositorios y confirmar estado de mantenimiento, README y LICENSE.

Skill	Autor	Enlaces	Star	Lenguaje	Ruta
frontend-slides	@zarazhangrui	GitHub: zarazhangrui/frontend-slides	17,530	Shell	Presentación web HTML
guizang-ppt-skill	@op7418 (Guizang)	Artículo interno: guizang-ppt-skill GitHub: op7418/guizang-ppt-skill	8,832	HTML	Presentación web HTML
html-ppt-skill	@lewislulu	GitHub: lewislulu/html-ppt-skill	3,834	HTML/CSS/JS	Presentación web HTML
mckinsey-pptx	@seulee26	GitHub: seulee26/mckinsey-pptx	426	Python	PPTX nativo
ppt-agent-skills	@sunbigfly	GitHub: sunbigfly/ppt-agent-skills	714	Python	PPTX nativo
claude-office-skills	@tfriedel	GitHub: tfriedel/claude-office-skills	631	Python	PPTX nativo
ppt-master	@hugohe3	GitHub: hugohe3/ppt-master	16,626	Python	PPTX nativo
NanoBanana-PPT-Skills	@op7418 (Guizang)	GitHub: op7418/NanoBanana-PPT-Skills	2,668	Python	Impulsado por imágenes de IA
gpt_image_2_skill	@wuyoscar	GitHub: wuyoscar/gpt_image_2_skill	2,102	Python	Impulsado por imágenes de IA
ppt-image-first	@NyxTides	GitHub: NyxTides/ppt-image-first	799	Python	Impulsado por imágenes de IA
Office-PowerPoint-MCP-Server	@GongRzhe	GitHub: GongRzhe/Office-PowerPoint-MCP-Server	1,708	Python	MCP / capa de protocolo
PPTAgent	@icip-cas	GitHub: icip-cas/PPTAgent	4,354	Python	MCP / capa de protocolo
open-design	@nexu-io	Artículo interno: open-design GitHub: nexu-io/open-design	40,822	TypeScript	Plataforma de diseño integrada
docsagent	@docsagent	GitHub: docsagent/docsagent	687	TypeScript	Plataforma de diseño integrada

Cómo elegir

Si el cliente necesita seguir editando, prioriza la ruta de PPTX nativo, especialmente ppt-master, mckinsey-pptx y ppt-agent-skills.

Si vas a presentar tú mismo y la expresión visual pesa más que la edición posterior, prioriza la ruta HTML, especialmente frontend-slides, guizang-ppt-skill y html-ppt-skill.

Si el objetivo es una pieza con sensación de póster, portada o imagen para difusión, prioriza la ruta de imágenes, como ppt-image-first, gpt_image_2_skill y NanoBanana-PPT-Skills.

Si ya tienes un archivo PPT y solo quieres que la IA te ayude a leerlo, editarlo y reorganizarlo, mira la ruta MCP.

Para escenarios claros como academia, marketing, traducción o compresión de informes largos, también puedes buscar Skills verticales en lugar de forzar un generador generalista de PPT.

Notas finales

No conviene juzgar proyectos open source solo por sus Star. Antes de usarlos de verdad, confirma tres cosas:

Si la LICENSE permite tu forma de uso.
Si el resultado generado cumple los requisitos de entrega, especialmente la editabilidad.
Si el coste es aceptable, incluyendo llamadas a modelos, generación de imágenes, modelos de contexto largo y posibles servicios cloud.

Estas herramientas cambian muy rápido. Los Star cambian y el estado de mantenimiento también. Pero la lógica de selección es relativamente estable: primero define la forma de entrega y luego mira las herramientas concretas. Si un PPT es para presentar, para que otros lo editen o para que otros lo miren, esas tres respuestas suelen reducir mucho el rango de opciones.

wx-cli explicado: consultar el historial local de WeChat desde la línea de comandos

Mon, 18 May 2026 21:02:21 +0800

wx-cli es una herramienta de línea de comandos escrita en Rust para datos locales de WeChat. Su objetivo es permitirte consultar desde la terminal tus propias sesiones de WeChat, historial de chats, contactos, miembros de grupos, favoritos, Moments, artículos de cuentas oficiales, adjuntos y estadísticas.

No es un servicio de sincronización de WeChat en la nube, ni un chatbot. Se parece más a una capa local de recuperación de datos en modo solo lectura: WeChat sigue ejecutándose en tu máquina, los datos siguen quedándose en tu máquina, y wx-cli se encarga de descifrar, cachear y consultar las bases de datos locales bajo demanda, para después devolver resultados en YAML o JSON a una persona o a un Agent.

Hay dos puntos que hacen interesante este proyecto. Primero, convierte la consulta de datos locales de WeChat en una CLI multiplataforma. Segundo, tiene en cuenta de forma explícita los escenarios de AI Agent con herramientas como Claude Code, Cursor y Codex, ofreciendo un archivo SKILL.md y salida estructurada con campos meta.

Qué puede hacer wx-cli

Según el README del proyecto, wx-cli cubre un conjunto de funciones bastante completo:

Ver sesiones recientes y sesiones no leídas.
Consultar el historial de chat de un contacto o grupo.
Buscar palabras clave en toda la base de datos local.
Ver mensajes nuevos.
Consultar contactos, miembros de grupos y apodos dentro de grupos.
Consultar favoritos.
Consultar notificaciones, línea de tiempo y contenido de Moments.
Consultar artículos enviados por cuentas oficiales.
Listar y extraer adjuntos de imágenes en chats.
Generar estadísticas de chat.
Exportar historiales de chat como Markdown o JSON.

Estas capacidades hacen que no sea solo una herramienta para “buscar chats”, sino una forma de convertir los datos locales de WeChat en una base de información local que se puede buscar, analizar y exportar.

Por qué encaja con AI Agents

Muchas herramientas CLI están pensadas solo para personas, y su salida es un bloque de texto. wx-cli, en cambio, claramente considera la lectura por parte de agentes.

El README menciona que comandos como history, search, sessions, unread, new-messages, stats y attachments incluyen información meta. Esa metadata contiene estado del resultado, shards desconocidos, la hora más reciente de los datos encontrados, la hora más reciente registrada en la session y otros campos similares.

Esto es útil para un Agent. La IA no solo necesita saber “qué se encontró”; también necesita saber si el resultado está actualizado, si puede faltar algún mensaje y si conviene ejecutar init de nuevo. Por ejemplo:

status puede indicar si el resultado es ok o possibly_stale.
unknown_shards puede indicar si existen shards de base de datos para los que el daemon aún no tiene key.
chat_latest_timestamp le dice al Agent cuál es la hora del mensaje más reciente en los datos encontrados.
session_last_timestamp ayuda a determinar si el registro local de la session está claramente por delante del resultado de la consulta.

Este tipo de metadata reduce errores de juicio de la IA y hace que herramientas como Claude Code, Cursor y Codex sean más fiables al trabajar con datos de WeChat.

Instalación

El proyecto recomienda la instalación multiplataforma mediante npm:

`1`	`npm install -g @jackwener/wx-cli`

También admite instalación con curl en macOS / Linux:

`1`	`curl -fsSL https://raw.githubusercontent.com/jackwener/wx-cli/main/install.sh \| bash`

En Windows, ejecútalo en PowerShell como administrador:

`1`	`irm https://raw.githubusercontent.com/jackwener/wx-cli/main/install.ps1 \| iex`

Si quieres compilar desde el código fuente, también puedes usar Rust directamente:

1
2

git clone git@github.com:jackwener/wx-cli.git && cd wx-cli
cargo build --release

El artefacto generado es target/release/wx; en Windows, wx.exe.

Relación con Agent Skills

wx-cli también ofrece una Skill orientada a AI Agents. Se puede instalar con un solo comando en Claude Code, Cursor, Codex y otros entornos compatibles con Skills mediante la skills CLI:

`1`	`npx skills add jackwener/wx-cli`

Instalación global:

`1`	`npx skills add jackwener/wx-cli -g`

Después de instalarla, el Agent lee el SKILL.md del repositorio y entiende cómo instalar, inicializar y llamar a wx-cli.

Esto significa que puedes pedir a un Agent que te ayude con tareas locales de organización de información, por ejemplo:

Encontrar palabras clave comentadas en un grupo durante un periodo determinado.
Resumir mensajes recientes no leídos.
Exportar el historial reciente de una sesión concreta.
Buscar enlaces de artículos de cuentas oficiales.
Analizar estadísticas de participación en un grupo.

La condición sigue siendo la misma: esos datos deben ser tus propios datos de WeChat, en tu propia máquina.

Uso básico

Antes de inicializar, mantén WeChat en ejecución. Los requisitos varían según la plataforma.

En Linux:

`1`	`sudo wx init`

En Windows, usa PowerShell como administrador:

wx init

En macOS es más complejo. El README explica que, con la ruta predeterminada, primero hay que aplicar una firma ad-hoc a WeChat para poder escanear la memoria del proceso. Después de volver a firmar, también hay que limpiar registros antiguos de autorización TCC; de lo contrario, permisos como captura de pantalla, videollamadas o micrófono pueden parecer activados pero estar realmente denegados. La documentación del proyecto también advierte que volver a firmar puede hacer que macOS muestre con frecuencia avisos para acceder a datos de otras apps.

Después de inicializar, puedes verificarlo con:

`1`	`wx sessions`

Si ves las sesiones recientes, la ruta básica ya funciona. El daemon se inicia automáticamente en la primera llamada.

Ejemplos de comandos comunes

Ver sesiones recientes:

`1`	`wx sessions`

Ver sesiones no leídas:

`1`	`wx unread`

Mostrar solo no leídos de personas y grupos, filtrando cuentas oficiales y entradas plegadas:

`1`	`wx unread --filter private,group`

Ver el historial reciente de una sesión:

`1`	`wx history "张三"`

Obtener más historial:

`1`	`wx history "张三" -n 2000`

Consultar un grupo por rango de fechas:

`1`	`wx history "AI群" --since 2026-04-01 --until 2026-04-15`

Buscar en toda la base:

`1`	`wx search "关键词"`

Buscar una palabra clave dentro de un grupo:

`1`	`wx search "会议" --in "工作群" --since 2026-01-01`

Exportar historial de chat:

1
2

wx export "张三" --format markdown -o chat.md
wx export "AI群" --since 2026-01-01 --format json

Estos comandos encajan bien con scripts o Agents, sobre todo cuando se combinan con --json.

Moments y artículos de cuentas oficiales

wx-cli no se limita a consultar chats.

Los comandos relacionados con Moments se dividen en notificaciones y publicaciones:

1
2
3

wx sns-notifications
wx sns-feed
wx sns-search "关键词"

Conviene tener presente que los datos de Moments solo cubren contenido que haya aparecido localmente. El cliente de WeChat descarga datos bajo demanda; si algo nunca apareció en tu entorno local, la herramienta no puede obtenerlo de la nada.

Los artículos de cuentas oficiales se consultan mediante comandos independientes:

wx biz-articles
wx biz-articles --account "返朴"
wx biz-articles --since 2026-05-01 --until 2026-05-10
wx biz-articles --json | jq '.[].url'

Devuelve campos como nombre de la cuenta oficial, título, URL, resumen, portada y hora. Para quienes organizan referencias, recopilan artículos o construyen una base de conocimiento local, esta función resulta muy práctica.

Extracción de adjuntos

Los adjuntos de imagen en chats de WeChat normalmente no son archivos de imagen corrientes que se puedan leer directamente. Suelen existir como archivos .dat bajo xwechat_files/<wxid>/msg/attach/....

wx-cli ofrece un flujo de dos pasos:

1
2

wx attachments "张三"
wx attachments "AI群" --kind image -n 100

Primero obtienes el attachment_id; después lo extraes:

`1`	`wx extract <attachment_id> -o ~/Desktop/photo.jpg`

El informe de salida incluye campos como md5, dat_path, dat_size, output, format y decoder. El README indica que admite modos de decodificación como legacy XOR, V1 fixed-AES y V2 AES + XOR, y que la extracción de image key varía según la plataforma.

Esta parte es potente, pero también requiere más cautela: procesa solo tus propios datos y no la uses para acceder a datos sin autorización.

Por qué importa la arquitectura daemon

El punto de rendimiento de wx-cli está en su daemon.

La estructura descrita en el README es aproximadamente esta:

wx (CLI) ──Unix socket──▶ wx-daemon (proceso en segundo plano)
                              │
                    ┌─────────┴──────────┐
               DBCache               caché de contactos
           (reutilización sensible a mtime)

Después del primer descifrado, el daemon persiste información de base de datos y mtime en ~/.wx-cli/cache/. Si el mtime del archivo de base de datos no cambió, las llamadas posteriores pueden reutilizar la caché sin volver a descifrarlo todo.

Esto es clave para consultas de línea de comandos y bucles de Agent. Un Agent puede consultar varias sesiones seguidas, buscar múltiples palabras clave y luego generar estadísticas o exportaciones. Si cada llamada tuviera que escanear y descifrar todo de nuevo, la experiencia sería mala. La caché del daemon lo acerca más a un servicio local de consultas.

Principio básico

El README del proyecto explica el principio de forma directa: WeChat 4.x cifra las bases de datos locales con SQLCipher 4, y WCDB cachea la raw key derivada en la memoria del proceso.

wx-cli usa métodos diferentes según la plataforma para escanear la memoria del proceso de WeChat, encontrar patrones de key y extraer la clave. Luego el daemon descifra y cachea las bases de datos bajo demanda.

El mecanismo de bajo nivel varía por plataforma:

macOS usa Mach VM API.
Linux usa /proc/<pid>/mem.
Windows usa VirtualQueryEx y ReadProcessMemory.

Estas capacidades explican por qué la inicialización suele requerir permisos elevados, y por qué en macOS intervienen firma y autorización de privacidad.

Límites y riesgos de uso

Con herramientas de este tipo, primero hay que hablar de límites.

El descargo de responsabilidad del README de wx-cli es claro: la herramienta es solo para aprendizaje e investigación, para descifrar tus propios datos de WeChat, y exige cumplir las leyes y regulaciones aplicables. No debe usarse para acceder a datos sin autorización.

En la práctica, también conviene tener en cuenta lo siguiente:

Úsala solo en tu propio ordenador y con tu propia cuenta de WeChat.
No subas sin pensar historiales de chat exportados a modelos en la nube.
Si usas un Agent para analizar chats, confirma primero el proveedor de API y los riesgos de transferencia de datos.
Después de exportar Markdown / JSON, cuida los permisos del archivo y la ubicación de las copias de seguridad.
En equipos de empresa o compartidos, confirma antes la autorización y el cumplimiento normativo.

Una herramienta local no significa que no haya riesgo de privacidad. Reduce la ruta predeterminada por la que los datos salen de tu máquina, pero si entregas la salida a un modelo en la nube, un disco en la nube o un script de terceros, el riesgo vuelve.

Para quién es

wx-cli encaja en estos escenarios:

Quieres buscar rápidamente tu propio historial de mensajes de WeChat de forma local.
Necesitas exportar una sesión como Markdown o JSON.
Quieres analizar la actividad de mensajes de un grupo durante un periodo.
Quieres que Claude Code, Cursor, Codex u otros Agents organicen material local de WeChat.
Quieres incorporar enlaces de artículos de cuentas oficiales a una base de conocimiento local.
Quieres estudiar la estructura local de bases de datos de WeChat y su flujo de descifrado.

No encaja tan bien en estos casos:

Quieres sincronización de WeChat en la nube.
Quieres saltarte permisos de dispositivos o cuentas de otras personas.
Quieres operar solo con una interfaz gráfica y no tocar la línea de comandos.
No quieres lidiar con permisos de macOS, derechos de administrador en Windows o sudo en Linux.

Resumen

El valor de wx-cli no es simplemente “buscar historiales de chat de WeChat desde la línea de comandos”. De forma más precisa, convierte los datos locales de WeChat en una fuente local que se puede consultar, exportar y consumir desde Agents.

Su arquitectura daemon resuelve los problemas de descifrado repetido y rendimiento de consulta; el wrapper meta ayuda a los AI Agents a determinar si los resultados están actualizados; y SKILL.md permite que herramientas como Claude Code, Cursor y Codex entiendan cómo instalarlo y usarlo.

Si a menudo necesitas encontrar información en WeChat, organizar chats de grupos, exportar registros o construir una base de conocimiento personal, wx-cli merece atención. Pero al usarlo conviene recordar siempre una regla básica: procesa solo tus propios datos y gestiona con cuidado los resultados exportados.

Referencias

Repositorio GitHub de jackwener/wx-cli

Anthropic Founder’s Playbook explicado: cómo Claude ayuda a los equipos startup a moverse más rápido

Mon, 18 May 2026 18:02:58 +0800

Anthropic publicó The Founder’s Playbook en el blog oficial de Claude, dirigido a fundadores. La pregunta central es directa: ¿cómo puede una startup AI-native avanzar más rápido desde una idea hasta producto, lanzamiento y escala?

El playbook no es simplemente una lista de funciones de Claude. Divide el proceso de construir una empresa en cuatro etapas: Idea, MVP, Launch y Scale. El punto no es dejar que la IA reemplace el juicio del fundador, sino entregar primero a Claude tareas repetitivas como investigación de mercado, borradores de texto, andamiaje de código, flujos operativos y materiales de ventas, para que los fundadores dediquen más tiempo a juicio, criterio, decisiones y construcción de confianza.

De qué trata este playbook

Las startups de IA enfrentan cada vez más una carrera de compresión: los ciclos de producto son más cortos, hay más competidores y los usuarios exigen velocidad y calidad al mismo tiempo. Trabajos que antes requerían un equipo de varias personas ahora pueden tener una primera versión generada por IA, y luego ser revisados, corregidos y empujados por el equipo fundador.

El marco de Anthropic es claro: no intentes convertir toda la empresa en “AI-powered” desde el primer día. Primero encuentra un proceso que consuma tiempo, sea repetitivo y tenga baja densidad creativa. Deja que Claude genere un primer borrador, script, resumen de investigación o lista de ejecución. Los fundadores siguen siendo responsables de definir objetivos, calibrar la dirección, juzgar la calidad y conectar los resultados útiles con el negocio real.

Primera etapa: Idea

La etapa Idea no consiste en imaginar un concepto llamativo. Consiste en validar si la idea merece más inversión.

Claude puede ayudar a los fundadores en esta etapa a mapear mercados, resumir dolores de usuarios, comparar posicionamiento de competidores, proponer posibles puntos de entrada y convertir ideas vagas en propuestas de valor más concretas.

Pero lo más importante sigue siendo el juicio humano. La IA puede ayudarte a ver más posibilidades con mayor rapidez, pero no puede asumir la responsabilidad de decidir si un mercado tiene una demanda realmente fuerte. Los fundadores todavía necesitan hablar con usuarios reales, observar si están dispuestos a cambiar sus flujos de trabajo existentes e incluso si están dispuestos a pagar.

Segunda etapa: MVP

La etapa MVP es donde Claude Code puede ser especialmente útil.

Para equipos pequeños, el recurso más escaso no suele ser la idea, sino la velocidad para convertirla en un producto que los usuarios puedan probar. Claude Code puede ayudar a generar andamiaje, escribir scripts, completar componentes, revisar casos límite y producir notas de plan técnico, ayudando al equipo a llegar antes a una versión verificable.

La clave no es pedirle a la IA que escriba un producto perfecto de una sola vez. Es reducir la fricción desde cero hasta la primera versión. Los fundadores e ingenieros aún deben revisar arquitectura, seguridad, manejo de datos y experiencia de usuario, pero no necesitan gastar tanto tiempo en borradores mecánicos.

Tercera etapa: Launch

La etapa Launch pone a prueba narrativa, distribución y velocidad de feedback.

Muchos equipos startup subestiman la complejidad de un lanzamiento: copy del sitio web, demos de producto, correos, contenido para redes sociales, entrevistas con usuarios, guiones de venta, actualizaciones para inversores. Cada pieza debe explicar claramente por qué este producto es necesario ahora.

Claude puede actuar aquí como un colaborador de alta frecuencia: generar variantes de posicionamiento, reescribir introducciones para distintos grupos de usuarios, simular preguntas de usuarios, ordenar el ritmo de lanzamiento y convertir feedback temprano en la siguiente ronda de acciones de producto y mercado.

Cuarta etapa: Scale

La etapa Scale cambia el foco de “construirlo” a “crecer de forma repetible”.

Cuando una empresa empieza a tener usuarios e ingresos estables, el equipo fundador se ve arrastrado por operaciones, ventas, soporte, análisis de datos y coordinación interna. Capacidades tipo agente como Claude Cowork encajan mejor con tareas más completas: hacer investigación de mercado, diseñar campañas, organizar una estrategia de fundraising, resumir métricas de crecimiento o convertir un proceso operativo en pasos repetibles.

Aquí también empieza a verse la diferencia entre empresas AI-native y compañías de software tradicionales. El cambio real no es solo que los empleados usen herramientas de IA. Es que los procesos de la empresa se diseñan desde el inicio alrededor de la colaboración con IA: qué tareas requieren que humanos definan estándares, cuáles debe ejecutar primero la IA, qué resultados deben revisarse y qué flujos pueden convertirse en plantillas reutilizables.

Para qué sirven Claude Code, Claude Cowork y Chat

Según la publicación oficial, Anthropic quiere que los fundadores piensen en Claude en tres tipos de uso.

Claude Code está más orientado a ingeniería. Sirve para escribir código, generar scripts, analizar casos límite, producir especificaciones de componentes y redactar documentación técnica. Ayuda a convertir ideas en algo que pueda ejecutarse.

Claude Cowork se parece más a un agente de trabajo delegable. Encaja con tareas que requieren ejecución continua, como investigación de mercado, diseño de campañas, estrategia de fundraising y análisis operativo. Ayuda a avanzar una primera ronda de una tarea de negocio relativamente completa.

Claude Chat encaja mejor en momentos de juicio del fundador: pensar una estrategia go-to-market, poner a prueba el posicionamiento del producto, comparar prioridades de roadmap y pulir narrativas clave. No es una máquina de ejecución, sino un compañero de pensamiento para iterar rápido.

Qué es realmente útil para los equipos startup

El valor de este playbook no está en decirles a los fundadores que “la IA es importante”. Eso ya no es nuevo.

Su aporte más útil es mover el uso de IA desde llamadas sueltas a herramientas hacia una metodología de construcción de empresa. Cada etapa tiene cuellos de botella distintos, y cada cuello de botella puede dividirse en partes donde la IA puede participar.

En la etapa Idea, la IA amplía el espacio de búsqueda. En MVP, comprime el ciclo de implementación. En Launch, acelera la expresión y los experimentos de distribución. En Scale, ayuda a convertir procesos en flujos repetibles.

Esta lógica es especialmente importante para equipos pequeños. Un equipo pequeño no tiene suficientes personas para cubrir todas las funciones, pero puede usar IA para crear una primera versión de una capacidad, y luego concentrar la energía humana limitada en las partes que más requieren juicio y construcción de relaciones.

Errores que conviene evitar

El primer error es tratar la salida generada por IA como una conclusión. Investigación de mercado, análisis de competidores, personas de usuario y estrategias de crecimiento deben validarse con datos reales y feedback de usuarios.

El segundo error es subestimar el costo de revisión. La IA puede reducir mucho el costo del primer borrador, pero calidad de código, riesgo legal, expresión de marca, promesas comerciales y seguridad siguen requiriendo responsabilidad humana.

El tercer error es automatizar demasiado pronto. Un proceso que todavía no funciona manualmente no debería entregarse a un agent para ejecución automática. Un enfoque más estable es dejar que la IA participe en una parte pequeña del flujo, observar la calidad del resultado y luego ampliar gradualmente el alcance.

Resumen

La señal de The Founder’s Playbook de Anthropic es clara: la ventaja de una startup AI-native no es solo saber usar IA para escribir código. Es incorporar la IA desde el primer día como una capa de colaboración en producto, ingeniería, marketing, ventas y operaciones.

Para los fundadores, el punto de partida más práctico no es construir un gran flujo de trabajo de IA. Es elegir una tarea que consuma demasiado tiempo, se repita demasiado y frene más el avance, y dejar que Claude produzca la primera versión. La competitividad real viene del control humano sobre dirección, calidad y confianza, y de si el equipo puede integrar este patrón de colaboración en el trabajo diario.

Referencias

The founder’s playbook for the age of AI

Qué es Vercel AI SDK: un toolkit unificado para desarrolladores TypeScript que crean apps de IA

Sun, 17 May 2026 23:07:38 +0800

vercel/ai es el AI SDK open source mantenido por Vercel.

Su posicionamiento es claro: ofrece a los desarrolladores TypeScript un conjunto de herramientas unificado para crear aplicaciones de IA y AI Agents. Viene del equipo detrás de Next.js, pero no se limita a Next.js. También soporta React, Svelte, Vue, Angular y runtimes como Node.js.

Repositorio del proyecto: https://github.com/vercel/ai

Si estás creando una app de chat, una herramienta de escritura con IA, una aplicación RAG, un Agent con tool calling, una interfaz con salida en streaming, o un producto que debe conectar varios proveedores de modelos en la misma aplicación, Vercel AI SDK merece atención.

El problema central que resuelve

Hoy, al crear aplicaciones de IA, uno de los mayores problemas no es “si se puede llamar a un modelo”, sino que cada proveedor tiene APIs, formatos de streaming, convenciones de tool calling, manejo de errores y necesidades de estado en frontend distintas.

Por ejemplo:

OpenAI tiene su propio SDK y formatos de respuesta.
Anthropic tiene su propia estructura de mensajes.
Google, xAI, Mistral, DeepSeek, Groq y otros también difieren.
La salida en streaming requiere manejar chunks.
El tool calling requiere procesar solicitudes estructuradas iniciadas por el modelo.
La UI de chat también debe gestionar mensajes, estados de carga, cancelación, reintentos y errores.

Si escribes un adaptador manual para cada proveedor, el proyecto se vuelve complejo muy rápido.

La idea de Vercel AI SDK es reunir esas diferencias detrás de una API unificada. El desarrollador escribe la aplicación contra una sola interfaz y conecta distintos modelos mediante Providers.

Arquitectura unificada de Providers

Una característica clave de Vercel AI SDK es que es provider-agnostic, es decir, no está atado a un único proveedor de modelos.

Puede acceder a OpenAI, Anthropic, Google y otros proveedores mediante una API unificada. El README del proyecto también indica que AI SDK usa Vercel AI Gateway de forma predeterminada, lo que facilita acceder a varios providers principales.

Esto es útil en proyectos reales.

Muchos productos de IA terminan usando más de un modelo:

Algunas tareas necesitan modelos de razonamiento fuerte.
Algunas tareas necesitan modelos rápidos y baratos.
Algunas tareas requieren multimodalidad.
Algunas tareas requieren contexto largo.
Algunas tareas necesitan modelos locales o privados.

Una arquitectura unificada de Providers facilita el cambio de modelo, las pruebas graduales, el control de costos y las estrategias de fallback.

El streaming es clave para la experiencia frontend

Una gran diferencia entre las apps de IA y las APIs tradicionales es que las respuestas pueden ser largas.

Si el usuario debe esperar a que vuelva toda la respuesta, las herramientas de chat, escritura y programación se sienten lentas. La salida en streaming permite mostrar texto de forma progresiva, para que el usuario vea avance antes.

Vercel AI SDK encapsula bastante bien la generación en streaming. El desarrollador no necesita manejar desde cero eventos de bajo nivel, sino usar las APIs de generación y streaming del SDK para conectar la salida del modelo con la UI.

Esto resulta especialmente cómodo en aplicaciones Next.js / React.

Una interfaz de chat con IA parece simple, pero en realidad debe manejar:

Lista de mensajes.
Entrada del usuario.
Solicitudes al servidor.
Visualización de tokens en streaming.
Estado de carga.
Estado de error.
Cancelación de generación.
Regeneración.

Estas son las tareas repetitivas que AI SDK intenta reducir.

Tool calling y escenarios de Agent

A medida que las aplicaciones de IA pasan de “chatear” a “hacer cosas”, el tool calling se vuelve cada vez más importante.

El modelo no solo devuelve lenguaje natural; también puede necesitar llamar funciones externas:

Consultar una base de datos.
Buscar documentos.
Llamar APIs de negocio.
Leer el estado de un pedido.
Generar gráficos.
Crear eventos de calendario.
Modificar archivos de proyecto.

Vercel AI SDK soporta capacidades de tool calling, para que el desarrollador defina herramientas, parámetros y lógica de ejecución, y el modelo pueda solicitar esas herramientas cuando corresponda.

Esta es una de las razones por las que pasó de ser un “SDK de UI de chat” a un toolkit más amplio para aplicaciones de IA y Agents.

Pero añadir tool calling no lo resuelve todo. En proyectos reales también hay que considerar:

Validación de parámetros.
Límites de permisos.
Logs de llamadas a herramientas.
Idempotencia.
Timeouts y reintentos.
Confirmación humana.
Restricciones para acciones sensibles.

AI SDK puede ayudar con interfaces y flujo, pero los límites de seguridad los debe diseñar el desarrollador.

Integración de UI

Vercel AI SDK es amigable con frameworks frontend.

No solo ofrece APIs centrales de generación; también abstrae chat, completions, estado de mensajes y UI en streaming. Para equipos que usan Next.js y React, esto puede reducir mucho código repetitivo.

Pero no sirve únicamente para despliegues en Vercel.

Si tu proyecto usa TypeScript, o tu backend corre en Node.js, AI SDK puede funcionar como capa de llamada a modelos y procesamiento de streaming. Desplegar o no en Vercel depende de la arquitectura, hábitos del equipo e infraestructura.

Skill for Coding Agents

El README de vercel/ai incluye una sugerencia interesante: si usas coding agents como Claude Code o Cursor, puedes añadir el skill de AI SDK al repositorio.

El comando de ejemplo es:

`1`	`npx skills add vercel/ai`

Esto muestra que Vercel entiende que los usuarios de AI SDK no son solo desarrolladores humanos, sino también coding agents.

Cuando un agent modifica un proyecto que usa AI SDK, un skill dedicado en el repositorio puede ayudarle a entender convenciones del SDK, APIs frecuentes, estructura del proyecto y buenas prácticas, reduciendo la probabilidad de cambios desordenados.

Esta dirección merece seguimiento.

En el futuro, los proyectos open source quizá no solo ofrezcan README y documentación, sino también instrucciones estructuradas para AI coding agents. En SDKs complejos, eso puede convertirse en una nueva puerta de entrada a la experiencia de desarrollo.

Proyectos para los que encaja

Vercel AI SDK encaja en estos escenarios:

Apps de chat con IA basadas en Next.js / React.
Herramientas de escritura, preguntas y respuestas, soporte y asistentes de código que necesitan streaming.
Productos de IA que deben conectar varios model providers.
Equipos que quieren crear prototipos RAG o de preguntas sobre documentos rápidamente.
Apps que necesitan tool calling, function calling o capacidades ligeras de Agent.
Equipos que ya usan TypeScript / Node.js.

Es especialmente útil para desarrolladores frontend y full-stack. En muchas apps de IA, la dificultad no es solo llamar al modelo, sino convertir la salida del modelo en una experiencia estable, fluida e interactiva.

Para qué no encaja tanto

Si tu proyecto es principalmente un backend Python, entrenamiento de deep learning, fine-tuning de modelos o servicio de inferencia de bajo nivel, Vercel AI SDK quizá no sea la herramienta central.

Está más cerca de la capa de aplicación que de un framework de entrenamiento.

Si necesitas:

Entrenar tu propio modelo.
Gestionar clusters de inferencia con GPU.
Hacer batch inference de bajo nivel.
Controlar profundamente tokenizer, KV cache, cuantización y motores de inferencia.

Conviene mirar PyTorch, vLLM, SGLang, TensorRT-LLM, llama.cpp o servicios cloud de inferencia.

Vercel AI SDK se parece más a la capa que conecta capacidades de modelos con productos.

Qué tener en cuenta al usarlo

Primero, no interpretes una API unificada como ausencia total de diferencias.

Los distintos model providers siguen variando en capacidades, longitud de contexto, formatos de tool calling, detalles de streaming, tipos de error y precios. Un SDK unificado reduce fricción de ingeniería, pero no elimina las diferencias entre modelos.

Segundo, controla costos.

Cuando una app de IA sale a producción, el chat en streaming, los reintentos, tool calls, recuperación RAG y fallbacks multi-modelo pueden aumentar costos. Hace falta rate limiting, caché, logs y monitoreo de presupuesto.

Tercero, diseña límites de seguridad.

Si el modelo puede llamar herramientas, debes limitar qué pueden hacer esas herramientas. No dejes que el modelo ejecute directamente acciones de alto riesgo, ni expongas secretos, permisos de escritura en bases de datos u operaciones de producción sin controles.

Cuarto, conserva observabilidad.

Cuando una app de IA falla, no basta con mirar el error del frontend. Necesitas saber entrada del usuario, modelo elegido, llamadas a herramientas, tiempo de respuesta, consumo de tokens, tipo de error y salida final.

Resumen

vercel/ai no es un modelo nuevo, ni solo un componente de chat.

Se parece más a infraestructura para desarrollar aplicaciones de IA con TypeScript: Providers unificados, salida en streaming, tool calling, gestión de estado frontend y escenarios de Agent dentro de un SDK open source.

Para equipos que ya usan Next.js, React, TypeScript y Node.js, puede reducir mucho el costo de ingeniería entre “la API del modelo funciona” y “la experiencia de producto es usable”.

Pero no es una capa universal. La elección de modelos, permisos, control de costos, logs, monitoreo y seguridad de negocio siguen siendo responsabilidad del desarrollador.

Si quieres crear aplicaciones de IA, no entrenar modelos, Vercel AI SDK es un toolkit que vale la pena probar temprano.

Referencias

Actualización de Midjourney de mayo de 2026: modo conversacional, desarrollo asistido por IA y organización de SREF

Sun, 17 May 2026 20:20:51 +0800

Lo más importante del Office Hours de Midjourney del 14 de mayo de 2026 no es un parámetro de modelo aislado. Es que el producto sigue moviéndose desde “escribir un prompt y generar una imagen” hacia un sistema creativo más conversacional, organizado e iterativo.

La información viene de un resumen japonés de una sesión reciente de preguntas y respuestas del equipo de Midjourney. Cubre modo conversacional, desarrollo asistido por IA, rediseño del sitio web, organización de SREF y etiquetas, Omni-reference, consistencia de múltiples personajes y cómo el propio equipo usa Midjourney.

En una frase: Midjourney intenta que la generación de imágenes se parezca más a un sistema creativo con el que se puede conversar, ordenar e iterar.

El modo conversacional gana importancia

El cambio más directo es Conversational Mode, el modo conversacional.

Hasta ahora, usar Midjourney seguía dependiendo mucho de parámetros y sintaxis fija. Había que recordar reglas de relación de aspecto, referencias de imagen, referencias de estilo, parámetros del modelo y escribirlas en el prompt o ajustarlas en la interfaz.

La dirección del nuevo modo conversacional es permitir que los usuarios describan esas configuraciones en lenguaje más natural.

Por ejemplo, mediante voz o texto se podrán especificar:

Parámetros predeterminados.
Relación de aspecto, como 16:9.
Referencias de imagen.
Referencias de estilo, es decir, --sref.
Omni-reference en V7.

Esto muestra que Midjourney no solo quiere mejorar la calidad de generación. También quiere reducir el coste operativo de manejar parámetros.

Para usuarios ocasionales, el mayor cambio es no tener que memorizar comandos todo el tiempo. Para usuarios intensivos, si el modo conversacional se vuelve suficientemente estable, puede convertirse en una entrada principal para ajustar configuraciones de generación con lenguaje natural.

El desarrollo asistido por IA cambia la velocidad de iteración de Midjourney

Otro punto interesante es que el propio equipo de Midjourney está usando desarrollo asistido por IA a gran escala.

El texto original menciona que ahora pueden corregir pequeños bugs, fricciones de interfaz y problemas de workflow mucho más rápido. Incluso hubo un ejemplo en el que se identificó un bug durante una llamada con usuarios, se corrigió en tiempo real con ayuda de IA, se revisó y se desplegó rápidamente.

Esto es más interesante que decir simplemente “la IA ayuda a los ingenieros a escribir código”.

Muestra que las herramientas de desarrollo con IA empiezan a influir en la forma en que los propios productos de IA iteran:

El feedback de usuarios puede entrar antes en el flujo de corrección.
Los problemas pequeños de experiencia son más fáciles de resolver.
Los ingenieros pueden dedicar más energía a arquitectura, review, decisiones de diseño y pruebas.
Los equipos de producto pueden limpiar edge cases con más frecuencia.

Un producto como Midjourney tiene muchas rutas creativas, combinaciones de parámetros, experiencia móvil, búsqueda y flujos de organización. Muchos problemas no son que el modelo central no pueda generar, sino que una entrada es incómoda, una operación tiene un paso de más o un estado límite se siente mal.

El desarrollo asistido por IA encaja especialmente bien para acelerar muchas mejoras pequeñas de este tipo.

El rediseño del sitio trata de workflow, no de recortar funciones

En el Office Hours también se mencionó que el sitio de Midjourney está pasando por un rediseño importante.

El objetivo no es eliminar funciones complejas, sino hacer el flujo creativo más intuitivo, facilitar el onboarding y organizar mejor herramientas y funciones.

Esto es clave.

El problema de Midjourney no es que tenga pocas funciones. Cuando las funciones crecen, entradas, colecciones, organización, referencias, exploración y reutilización se vuelven más complejas. Para usuarios ligeros, la dificultad es “por dónde empiezo”. Para usuarios intensivos, es “cómo gestiono muchos estilos, referencias y resultados experimentales”.

Las posibles estrategias de despliegue incluyen:

Ofrecer interfaces antigua y nueva en paralelo.
Empezar con una fase alpha.
Migrar por etapas para evitar afectar a usuarios intensivos.

Estas estrategias muestran que el equipo entiende que Midjourney no es un simple juguete de generación de imágenes. Muchos usuarios ya lo han incorporado a flujos creativos reales, así que un cambio de interfaz no puede romper hábitos existentes sin cuidado.

SREF, estilos y etiquetas siguen siendo puntos de dolor

SREF y la organización de estilos fueron una de las partes más interesantes de la sesión.

Los usuarios quieren mejores sistemas de organización, especialmente para:

SREF aleatorios.
Referencias de estilo.
Estéticas guardadas.
Etiquetas y etiquetas de color.
Más capacidad de filtrar, agrupar y reutilizar.

Pero el equipo también planteó una pregunta: si el sistema actual de carpetas ya permite que una imagen pertenezca a varias carpetas, soporta carpetas ilimitadas y permite filtrar y ordenar, ¿qué aportan exactamente las etiquetas que las carpetas no puedan resolver?

La pregunta es práctica.

Muchos productos añaden etiquetas porque los usuarios dicen que quieren etiquetas. Pero si el sistema de etiquetas está mal diseñado, se convierte en otra capa de clasificación caótica. Si carpetas, etiquetas, favoritos, búsqueda, filtros, proyectos y bibliotecas de estilo no tienen límites claros, el usuario termina gestionando peor.

Por eso el equipo de Midjourney quiere ejemplos concretos de workflow: ¿en qué escenario necesitan etiquetas los usuarios? ¿Por qué no bastan las carpetas? ¿Es para combinar estilos rápidamente, reutilizar entre proyectos, filtrar por tema, tono de color, estilo fotográfico o relación entre personajes?

Para Midjourney, el sistema de organización puede volverse tan importante como el modelo de generación. Cuando los usuarios trabajan a largo plazo, lo difícil no es generar una imagen, sino gestionar miles de imágenes, cientos de direcciones de estilo y resultados de experimentos repetidos.

Omni-reference apunta a un control de personajes más complejo

El texto también menciona que los futuros sistemas Omni-reference / subject reference podrían permitir múltiples referencias de personajes al mismo tiempo y una mejor separación entre sujetos.

Esto corresponde a un problema persistente de la generación de imágenes con IA: consistencia de personajes y relaciones entre varios personajes.

Mantener un solo personaje consistente ya es difícil. Varios personajes lo son más. Problemas comunes:

Rasgos del personaje A pasan al personaje B.
Identidades mezcladas entre varias personas.
Ropa, peinado y rasgos faciales cambian entre imágenes.
La imagen de referencia afecta demasiado al estilo completo en vez de controlar solo el sujeto.

Si Omni-reference puede manejar mejor la separación de sujetos, Midjourney será más útil para cómics, storyboards, visuales publicitarios, diseño de personajes, concept art de juegos y narrativas continuas.

Esta es una dirección que merece seguimiento después de V7.

Midjourney está reinterpretando el prompt

El resumen también incluye una idea interesante: el lenguaje es una capa imperfecta de compresión de la imaginación.

Esa frase explica bien la dirección de producto de Midjourney.

Muchos usuarios creen que el núcleo de la generación de imágenes con IA es escribir prompts más largos y precisos. Pero en el trabajo creativo real, referencias de imagen, referencias de estilo, moodboards, SREF, variaciones, regeneración y postproducción suelen ser más útiles que un prompt muy largo.

El workflow de Duncan, miembro del equipo de Midjourney, refleja esto. Usa Midjourney como un sketchbook, combinando moodboards, SREF, poco texto, regeneración alta con --r, variaciones fuertes y sutiles, retoque en Photoshop y flujos externos de upscaling.

Esto muestra que los usuarios maduros de Midjourney no trabajan solo con “prompts mágicos”.

Un proceso más realista sería:

Usar poco lenguaje para marcar dirección.
Usar referencias de imagen para dar contexto visual.
Usar SREF para acotar estilo.
Usar muchas variaciones para explorar el espacio.
Usar criterio humano para seleccionar resultados.
Usar herramientas externas para postproducción.

El prompt sigue importando, pero no lo es todo.

Qué significa para los usuarios

Si solo generas imágenes ocasionalmente, el efecto más directo será que el modo conversacional debería ser más fácil de usar. En el futuro podrás expresar proporción, referencias, estilo y parámetros de forma más natural, sin memorizar tantos comandos.

Si eres usuario intensivo, hay tres áreas que conviene vigilar.

Primero, la organización.

La evolución de SREF, estilos, carpetas, favoritos y etiquetas afectará directamente la eficiencia creativa a largo plazo.

Segundo, el rediseño web.

Si la nueva interfaz conecta exploración, organización, reutilización y exportación, Midjourney se parecerá más a una herramienta creativa profesional que a un generador aislado.

Tercero, referencias de personajes y sujetos.

Si Omni-reference maneja de forma estable múltiples personajes y separación de sujetos, Midjourney será más adecuado para proyectos continuos, no solo para imágenes sueltas.

Resumen

El punto central del Office Hours de Midjourney de mayo de 2026 no es un parámetro llamativo, sino que el producto sigue evolucionando hacia un sistema creativo.

El modo conversacional reduce la barrera de entrada. El desarrollo asistido por IA acelera la iteración. El rediseño web intenta reorganizar workflows. La discusión sobre SREF y etiquetas apunta a gestión de activos a largo plazo. Omni-reference se relaciona con consistencia de personajes y control de sujetos complejos.

Para las herramientas de generación de imágenes con IA, la capacidad del modelo importa, por supuesto. Pero cuando la calidad de generación alcanza cierto nivel, lo que decide si los usuarios se quedan a largo plazo suele ser workflow, organización, controlabilidad y velocidad de iteración.

Midjourney está completando esas piezas.

Referencias

Midjourney 最新ニュース（2026年5月14 日）｜アキスケ

Cómo ve el desarrollo de software con IA Peter Steinberger, creador de OpenClaw: de OpenClaw a la programación en bucle cerrado

Sun, 17 May 2026 20:02:26 +0800

La trayectoria de Peter Steinberger sirve para observar qué está cambiando en el desarrollo de software con IA.

No es un recién llegado que se hizo visible de repente gracias a la IA. Antes de OpenClaw, ya era fundador de PSPDFKit, una empresa dedicada a renderizado PDF, procesamiento de documentos y herramientas para desarrolladores. Este tipo de producto no gana solo con narrativa: debe resolver rendimiento, compatibilidad, diseño de API, clientes empresariales y mantenimiento a largo plazo.

Por eso, cuando Steinberger construyó OpenClaw con herramientas de IA y empezó a hablar de AI Agent, automatización personal y AI coding, lo importante no fue solo que “una persona escribió mucho código”. Lo más interesante es cómo combinó años de experiencia en ingeniería de software con una nueva generación de AI coding agents para reinterpretar el proceso de desarrollo.

AI coding no es un botón mágico

Muchas discusiones sobre AI coding se reducen a dos extremos.

Uno dice que la IA ya puede escribir código y que los programadores pronto no serán necesarios.

El otro dice que el código generado por IA no es fiable y que la ingeniería real debe seguir escribiéndose a mano.

La experiencia de Steinberger apunta a una tercera idea: la IA cambia la unidad de operación del desarrollo de software, pero no elimina el juicio de ingeniería.

Antes, el trabajo del desarrollador giraba alrededor de editar código. Descomponer requisitos, decidir arquitectura, implementar, probar y corregir bugs se organizaba alrededor de cambios manuales.

Cuando entran AI coding agents, el desarrollador empieza a parecerse más a alguien que gestiona un sistema de ejecución:

Explicar el objetivo.
Proporcionar contexto.
Definir límites.
Dejar que el agent modifique código.
Ejecutar pruebas y comprobaciones.
Iterar según los resultados.

Esto no es simplemente entregar el teclado al modelo. Es pasar de “escribir cada línea a mano” a “definir dirección, diseñar feedback y juzgar resultados”.

Por qué no le convence llamarlo vibe coding

Una expresión frecuente alrededor de Steinberger es vibe coding.

El término nació para describir una nueva forma de desarrollo: el desarrollador describe ideas en lenguaje natural, deja que la IA genere mucho código y luego ajusta con resultados de ejecución y feedback.

Pero Steinberger no está del todo de acuerdo con esa etiqueta. En cobertura pública se ha señalado que ve vibe coding como una expresión que puede volverse despectiva, porque sugiere que el desarrollo asistido por IA es solo “generar por intuición” e ignora la habilidad, el juicio y la experiencia detrás.

La crítica tiene sentido.

El AI coding efectivo no consiste en escribir una frase casual y confiar en la salida del modelo. Requiere:

Convertir requisitos vagos en tareas ejecutables.
Detectar si el modelo entendió mal el objetivo.
Diseñar pruebas y criterios de aceptación.
Juzgar si la estructura del código será mantenible.
Saber cuándo dejar de generar y pasar a revisión humana.

En otras palabras, la IA reduce la fricción de escribir código, pero no reduce la responsabilidad de entender el sistema.

La clave es el bucle

Una idea que se asocia con frecuencia a entrevistas y textos de Steinberger es el bucle.

Dejar que la IA genere código es un proceso de bucle abierto.

Dejar que la IA genere código, lo ejecute, lea errores, corrija problemas y vuelva a ejecutar pruebas se acerca más a un bucle cerrado.

La diferencia es importante.

La generación en bucle abierto crea con facilidad software que parece utilizable. La página abre, las funciones parecen existir y hay bastante código. Pero al entrar en escenarios reales aparecen problemas de estado, permisos, manejo de errores, casos límite y despliegue.

El desarrollo en bucle cerrado exige que la salida esté limitada por feedback. El bucle más simple es:

Escribir claramente el objetivo.
Dejar que la IA modifique el código.
Ejecutar automáticamente pruebas, type checks, lint o build.
Devolver los errores a la IA.
Repetir hasta que pase.
Hacer una revisión humana de la ruta crítica.

Ahí es donde el desarrollo de software con IA puede mejorar de verdad la eficiencia. No porque el modelo acierte a la primera, sino porque puede participar rápidamente en el ciclo de generar, validar y reparar.

Cuanta más experiencia, mejor se usa la IA

Uno de los malentendidos más comunes sobre AI coding es que la experiencia deja de importar.

El caso de Steinberger sugiere lo contrario: la experiencia importa más, aunque su función cambia.

Un ingeniero con experiencia juzga mejor:

Qué tareas conviene pasar a un agent.
Qué módulos necesitan pruebas primero.
Qué cambios son demasiado riesgosos para una refactorización amplia con IA.
Qué código generado solo parece razonable.
Qué problemas deberían resolverse con arquitectura y no con más parches.

La IA puede generar muchas soluciones candidatas, pero cuantas más opciones hay, más juicio se necesita. Alguien sin experiencia puede quedar impresionado porque “funciona”. Un ingeniero con experiencia pregunta: ¿se puede mantener? ¿se puede extender? ¿rompe límites de seguridad? ¿se puede depurar si falla?

Por eso los AI coding agents no convierten la ingeniería de software en puro chat. Más bien externalizan una parte del trabajo de ejecución y amplifican la importancia de planificar, revisar, validar y decidir trade-offs.

OpenClaw importa más allá del proyecto

OpenClaw llamó la atención no solo porque es un AI agent open source, ni solo porque creció rápido.

También funciona como señal: los desarrolladores empiezan a querer que la IA no solo responda preguntas, sino que se conecte a herramientas reales y ejecute acciones reales.

Los chatbots tradicionales se quedan dentro de la caja de conversación. Pueden explicar código, escribir borradores y dar consejos, pero muchas veces una persona todavía debe copiar, pegar, abrir software y ejecutar comandos.

La dirección de los agents es conectar modelos con herramientas:

Sistema de archivos.
Navegador.
Terminal.
Email.
Calendario.
Servicios de terceros.
Repositorios de proyecto.

Cuando los modelos pueden usar esas herramientas, cambian los límites del desarrollo de software. La IA deja de ser solo autocompletado de código y participa en lectura de proyectos, descomposición de tareas, edición de archivos, ejecución de pruebas, preparación de PR y automatización de workflows.

Por eso también llamó la atención la incorporación de Steinberger a OpenAI. No representa solo una historia individual de desarrollador, sino una dirección de producto: los agents personales pasarán de demos a la capa de trabajo diaria.

Qué significa para desarrolladores comunes

Para desarrolladores comunes, la experiencia de Steinberger no se puede copiar directamente en todos los casos.

No todo el mundo puede gestionar varios agents a la vez. No todos los proyectos toleran generación intensa con IA. No todos los equipos aceptan el ritmo de “generar primero e iterar rápido”.

Pero hay varias lecciones útiles.

Primero, escribir tareas con claridad.

La IA es sensible a objetivos vagos. Si dices “optimiza esto”, puede cambiar estilo, estructura, funciones y lógica. Si dices “cambia el mensaje de error al fallar el login de inglés a chino sin alterar el flujo de autenticación”, el resultado suele ser más controlable.

Segundo, fijar comandos de validación.

Si un proyecto no tiene pruebas, build ni lint, la IA tiene dificultades para formar un bucle. Incluso comandos básicos como npm test, go test ./..., pytest o hugo son mejores que revisar solo a ojo.

Tercero, controlar el alcance del cambio.

Pedir a la IA que trabaje en un módulo, un bug o una página cada vez suele ser más fiable que pedirle “refactoriza todo el proyecto”.

Cuarto, mantener revisión humana.

En autenticación, pagos, permisos, eliminación de datos, scripts de despliegue, migraciones de base de datos y configuración de seguridad, no bajes el estándar de revisión solo porque el código lo generó IA.

Quinto, revisar prompts y patrones de fallo.

Si la IA malinterpreta a menudo cierto tipo de tarea, escribe esas restricciones en reglas del proyecto, agent instructions o archivos de skill. La capacidad de AI coding no viene solo del modelo, sino también del entorno de trabajo que construyes alrededor.

Hacia dónde va el desarrollo de software con IA

La historia de Steinberger muestra que el desarrollo de software con IA se mueve desde “ayudar a escribir código” hacia “organizar flujos de producción de software”.

Las primeras herramientas de AI coding servían sobre todo para completar funciones, explicar errores y generar plantillas. El cambio actual es que los agents pueden trabajar entre archivos, llamar herramientas, ejecutar comprobaciones y seguir corrigiendo con feedback.

Esto apunta a varias tendencias.

Primero, subirá el techo productivo de los desarrolladores individuales.

Una persona puede avanzar más prototipos, scripts, herramientas internas y productos pequeños. Pero producir más no significa producir mejor automáticamente. Cuanto más rápido se genera, más importante es validar.

Segundo, la estructura del proyecto será más importante.

Cuanto más claro sea el código, más explícitas las pruebas y más completa la documentación, más fácil será que la IA haga cambios correctos. Los proyectos caóticos son difíciles para humanos y para IA.

Tercero, los ingenieros de software se parecerán más a diseñadores de workflows.

En el futuro no importará solo conocer un lenguaje, sino saber organizar requisitos, contexto, herramientas, pruebas, despliegue y permisos en un bucle controlable.

Cuarto, los límites de seguridad serán más sensibles.

Si un agent puede hacer cosas, también puede hacer cosas equivocadas. Si puede leer archivos, ejecutar comandos y acceder a servicios, permisos, auditoría y rollback se vuelven infraestructura básica del entorno de desarrollo con IA.

Resumen

Lo más valioso de la visión de Peter Steinberger sobre desarrollo de software con IA no es “cuánto código generó la IA”, sino la nueva postura de desarrollo que muestra.

Las personas ya no solo escriben línea por línea dentro del editor. Diseñan objetivos, gestionan agents, construyen bucles de feedback, revisan resultados y ajustan el sistema. El código sigue siendo importante, pero ya no es el único centro del trabajo.

Si el desarrollo tradicional enfatizaba “escribir bien el código”, el desarrollo con IA enfatizará cada vez más “hacer que el sistema produzca resultados correctos y verificables de forma continua”.

No se trata solo de bajar la barrera de la ingeniería. Cambia la forma de la capacidad técnica: de implementación manual hacia descomposición de tareas, gestión de contexto, orquestación de herramientas, validación automática y juicio final.

Referencias

Filtración de Google Gemini Spark: podría llegar un Gemini Agent online las 24 horas

Sun, 17 May 2026 11:58:08 +0800

Google todavía no ha lanzado oficialmente Gemini Spark.

La información actual proviene sobre todo de interfaces internas de prueba en Gemini Web, capturas de la comunidad, reportes de TestingCatalog y resúmenes de 36Kr / Xinzhiyuan sobre filtraciones relacionadas. La lectura más consistente es que Gemini Spark BETA podría ser un AI Agent always-on que Google está preparando. Su posición ya no sería solo la de un asistente de chat, sino la de un “agente de IA cotidiano” capaz de manejar correo, tareas online y flujos de varios pasos en segundo plano.

Así que conviene fijar primero el límite: esto es un análisis de filtraciones, no un anuncio oficial de Google. Funciones, nombre y fecha de lanzamiento aún deben ser confirmados por Google.

Conclusión rápida

Según la información expuesta hasta ahora, Gemini Spark tiene tres puntos clave:

Podría ser un Agent online las 24 horas dentro del sistema Gemini, no un modelo de chat normal.
Podría usar un contexto personal más amplio, incluyendo apps de Google, historial de chats, tareas, sitios con sesión iniciada y ubicación.
Sus riesgos son tan grandes como su atractivo, porque puede involucrar compartir información, datos de navegador remoto, compras y llamadas a servicios de terceros.

Si Google realmente lanza Spark, el papel de Gemini cambiará: de “IA que responde preguntas” a “IA que gestiona tareas por ti de forma continua”.

Qué es Gemini Spark

TestingCatalog reportó el 14 de mayo de 2026 que Google está probando Gemini Spark BETA dentro de Gemini Web. El texto de bienvenida expuesto lo describe como un everyday AI agent que puede ayudar 24/7 con inbox, online tasks y más trabajo de varios pasos.

El artículo de 36Kr / Xinzhiyuan también menciona que, tras descubrirse Spark, lo que se ve desde fuera es una dirección de “Agent de tiempo completo”: puede permanecer disponible todo el día, procesar la bandeja de entrada, ejecutar tareas online e incluso involucrar compras y compartición de información.

Esto significa que Spark no es simplemente el nombre de un nuevo modelo. Se parece más a una actualización de la capa de producto de Gemini: sacar a Gemini de la ventana de conversación y llevarlo al correo, la web, el calendario, las tareas y los flujos entre apps del usuario.

Cómo podría funcionar

Según el texto de onboarding oculto divulgado por TestingCatalog, Gemini Spark obtendría contexto de varias fuentes, incluyendo:

Connected Apps.
skills.
chats.
tasks.
Sitios web donde el usuario inició sesión.
Personal intelligence.
location.

Esta información ayudaría a Spark a entender qué quiere completar el usuario y a invocar el contexto necesario durante la ejecución de tareas. El texto también menciona que, para completar algunas acciones, Gemini podría compartir información necesaria con terceros, como nombre, datos de contacto, archivos, preferencias e información que el usuario podría considerar sensible.

Si estas descripciones terminan siendo correctas, Spark funcionaría más como un sistema de agente con contexto que como una herramienta de preguntas y respuestas de una sola vez. No miraría solo el prompt actual, sino que podría combinar preferencias a largo plazo, apps conectadas, estado del navegador e historial de tareas.

Por qué importa

La clave de Gemini Spark no es añadir otra entrada de chat. La clave es que Google tiene una entrada natural al ecosistema.

OpenAI y Anthropic pueden construir Agents muy fuertes, pero no poseen de forma natural la cadena completa de Gmail, Calendar, Drive, Chrome, Android y Workspace. Si Google conecta Spark con estos productos, los usuarios no necesitarán montar demasiados flujos adicionales para que un Agent entre en su trabajo diario.

Esto puede traer tres cambios.

Primero, Gemini pasaría de preguntas y respuestas pasivas a ejecución activa. Los usuarios ya no solo preguntarían “resúmeme este correo”, sino que podrían pedirle que organice el inbox, siga tareas y ejecute acciones posteriores de forma continua.

Segundo, los Agents dependerán más del contexto personal. Cuanto más entienda tu correo, calendario, archivos, estado del navegador y preferencias, más útiles podrán ser sus resultados.

Tercero, los límites de permisos serán más sensibles. Poder hacer más también significa que el usuario debe saber con más claridad cuándo puede actuar, hasta dónde puede llegar y si necesita confirmación.

Dónde están los riesgos

Hay varios puntos en el texto divulgado por TestingCatalog que merecen atención.

Primero, Spark es experimental. Incluso si se lanza, no debería tratarse como un sistema completamente maduro que no requiere supervisión.

Segundo, aunque el sistema está diseñado para pedir permiso antes de operaciones sensibles, el texto también advierte que podría compartir información o completar compras sin preguntar.

Tercero, para mantener la continuidad de la sesión, Gemini guardará remote browser data, como detalles de inicio de sesión y remote code execution data. Los usuarios pueden borrar estos datos en Settings y también desactivar Connected Apps y capacidades relacionadas con Personal intelligence.

En conjunto, estos puntos muestran que la dirección de producto de Spark es agresiva: quiere ser un Agent que realmente ejecute tareas, no solo que genere sugerencias. Pero cuanto más se acerca a la ejecución real, más necesita permisos estrictos, auditoría, confirmación y mecanismos de reversión.

Relación con Remy y AI Ultra

TestingCatalog menciona que Spark podría ser una versión renombrada de la agentic Gemini upgrade antes conocida internamente como Remy, y que también podría estar relacionada con la dirección de Gemini Agent para suscriptores de Google AI Ultra.

Si esta pista es correcta, Spark no sería un proyecto nuevo surgido de la nada. Podría ser una forma de reempaquetar capacidades de Agent más avanzadas y cerradas, para prepararlas para una audiencia más amplia.

36Kr / Xinzhiyuan también lo describe como una evolución de “Remy” a “Spark”: Gemini Agent deja de ser solo una función y se mueve hacia un gestor digital de vida 24/7.

Pero esto sigue siendo una interpretación basada en filtraciones. Si Google usará Spark como nombre oficial, si será solo para AI Ultra o si habrá una suscripción más ligera todavía necesita confirmación oficial.

MCP, skills y ecosistema de herramientas

En la misma tanda de capturas comunitarias también aparecieron entradas del selector de modelos como MCP Tool Testing. El artículo de 36Kr cree que esto podría sugerir soporte nativo de Gemini para integración de herramientas de terceros vía MCP, además de una reconstrucción del modo Thinking.

Esta pista se vuelve más interesante al mirarla junto a Spark.

Si Spark fuera solo un “asistente que chatea”, skills y MCP tendrían menos importancia. Pero si Spark es un Agent de larga duración, necesita llamar herramientas de forma fiable, acceder a páginas web, ejecutar tareas, leer y escribir contexto, y entregar resultados al usuario.

Es decir, Spark quizá no sea una función aislada, sino parte del ecosistema de herramientas Agent de Google: el modelo entiende y planifica, mientras skills / MCP / connected apps ejecutan y amplían.

Qué significa para usuarios comunes

Si Gemini Spark se lanza de verdad, los cambios más directos para usuarios comunes podrían ser:

El correo no solo se resume, sino que se clasifica, se sigue y se convierte en tareas.
Las tareas web no solo reciben sugerencias, sino que podrían ejecutarse de forma continua en un navegador remoto.
Calendario, ubicación, preferencias y conversaciones previas se convierten en contexto a largo plazo del Agent.
Compras, reservas, formularios y acciones similares podrían entrar en el alcance de ejecución de la IA.

Suena cómodo, pero los usuarios tendrán que crear nuevos hábitos: no solo mirar qué dice la IA, sino también qué se prepara para hacer, qué ya hizo, si se puede deshacer y si hay registro.

La experiencia futura de AI Agent no dependerá solo de qué tan inteligente sea el modelo, sino también de si los avisos de permisos son claros, si los logs de tareas se pueden revisar y si los errores se pueden recuperar.

Qué significa para desarrolladores y equipos

Para desarrolladores, Spark importa porque Google podría estar moviendo los Agents desde “productos demo” hacia plataformas reales de workflow.

Si Spark puede conectar de forma estable apps de Google, herramientas de terceros y estado del navegador, los desarrolladores se preguntarán:

Si habrá APIs o mecanismos de extensión abiertos.
Si MCP o skills podrán ser conectados por terceros.
Si administradores empresariales podrán controlar permisos, retención de datos y auditoría.
Si los fallos de ejecución del Agent tendrán logs rastreables.
Si habrá sandboxing, flujos de aprobación y confirmación para operaciones sensibles.

Para equipos, Spark probablemente entraría primero por escenarios frecuentes como Gmail, Calendar, Docs, Drive y Chrome. Quizá al principio no sea adecuado para automatizar por completo tareas de alto riesgo, pero encaja bien como asistente para inbox triage, seguimiento de reuniones, organización de documentos, investigación de mercado y tareas ligeras de operaciones.

Cómo leerlo ahora

Esta noticia se entiende mejor como “dirección de alta confianza, detalles de baja certeza”.

La dirección de alta confianza es que Google está empujando Gemini Agent hacia algo más proactivo, más duradero y más profundamente integrado con su ecosistema. El texto de prueba de Gemini Web reportado por TestingCatalog, las capturas comunitarias y la recopilación de filtraciones de 36Kr apuntan en la misma dirección.

Los detalles de baja certeza son el nombre oficial, la fecha de lanzamiento, las reglas de permisos, los niveles de suscripción, las regiones disponibles, si habrá API abierta y si realmente se llamará Gemini Spark.

La lectura más prudente por ahora:

No tratar Spark como un producto oficial ya lanzado.
Verlo como una señal fuerte de la próxima ruta de Google en AI Agents.
Esperar cómo Google explicará permisos, privacidad, compartición de datos con terceros y almacenamiento de datos de navegador remoto.

Resumen

Si Gemini Spark finalmente se lanza, podría ser un paso clave para que Gemini pase de asistente de chat a Agent always-on. No es solo cambiar un modelo, sino colocar Gemini dentro del ecosistema de Google: correo, web, tareas, ubicación, personal intelligence y servicios de terceros.

Su potencial es grande: más proactivo, más cercano a flujos reales y más fácil de distribuir a muchos usuarios gracias al ecosistema de Google. Sus riesgos son igual de grandes: si la IA puede compartir información, guardar estado del navegador, ejecutar compras y llamar servicios de terceros, los límites de permisos deben ser muy claros.

Por eso lo más importante de Gemini Spark no es “qué tan inteligente es”, sino cómo piensa Google hacer que un AI Agent online las 24 horas sea controlable, auditable y confiable.

Referencias:

Filtración de Gemini 3.5 Pro: con nombre en clave Cappuccino, Google intenta recuperar ritmo en coding y agentes

Sun, 17 May 2026 11:47:27 +0800

Google todavía no ha lanzado oficialmente Gemini 3.5 Pro.

La información disponible por ahora proviene sobre todo de capturas de comunidades de desarrolladores, benchmarks anónimos, filtradores y reportes de medios. El 15 de mayo de 2026, 36Kr / Xinzhiyuan publicó que un checkpoint de la próxima generación de Gemini podría tener el nombre interno Cappuccino, y que modelos relacionados ya habrían aparecido en comunidades y plataformas de evaluación.

Esta información no debe tratarse como un lanzamiento oficial, pero sí muestra una dirección clara: Google intenta cubrir dos brechas a la vez, coding y razonamiento por un lado, y agentes de IA always-on por el otro.

Conclusión rápida

Esta filtración puede leerse en tres capas:

Gemini 3.5 Pro aún no ha sido lanzado oficialmente, y Cappuccino parece más un checkpoint interno o una build candidata.
La información filtrada sugiere que el nuevo Gemini mejora en generación de código, generación SVG / web interactiva y salida multimodal.
La prueba paralela de Gemini Spark por parte de Google puede ser más importante que el modelo en sí, porque apunta a un agente personal de IA funcionando 24 horas.

En otras palabras, no es solo una historia de benchmarks. Parece más una señal de roadmap antes de Google I/O: el modelo necesita alcanzar a GPT-5.5, mientras la capa de agentes necesita capturar flujos de trabajo de usuarios.

Qué es Cappuccino

El artículo de 36Kr menciona que, según una publicación de Lentils, el checkpoint de Gemini 3.5 Pro con nombre en clave Cappuccino ya habría empezado a producirse. La comunidad todavía hablaba de Gemini 3.2 horas antes, pero la filtración más reciente saltó directamente a 3.5.

Si ese nombre termina siendo correcto, Google podría querer presentar el próximo Gemini como un salto de versión más grande, no como una actualización menor.

Por ahora, Cappuccino debe tratarse como un nombre interno filtrado. No significa que Google haya lanzado públicamente el modelo final, ni garantiza que el nombre de lanzamiento vaya a ser Gemini 3.5 Pro.

Por qué el coding es el foco

La parte más comentada de la filtración es la capacidad de coding del nuevo Gemini.

Según capturas y supuestos benchmarks citados por 36Kr, el nuevo modelo parece más fuerte en:

Generación de SVG y componentes visuales.
Generación de aplicaciones web interactivas.
Manejo de animación, 3D, paneles de parámetros ajustables y otras salidas frontend complejas.
Mejoras en razonamiento lógico y generación de código.

El artículo también cita a Bindu Reddy, CEO de Abacus.AI, diciendo que 3.2 Flash se acerca a GPT-5.5 en coding y razonamiento, con un coste mucho menor. Otras fuentes de medios creen que el nuevo Gemini se ubica aproximadamente en el nivel de GPT-5.5, aunque quizá no represente un salto cualitativo.

Por eso conviene leer con cautela la frase “alcanza a GPT-5.5”. Se parece más a un juicio relativo basado en filtraciones y pruebas anónimas que a un resultado oficial de benchmark de Google.

Por qué Google necesita ponerse al día en coding

El AI coding pasó de ser una categoría de herramientas para desarrolladores a ocupar el centro de la competencia entre modelos fundacionales.

OpenAI tiene Codex y Anthropic tiene Claude Code. No solo sirven a ingenieros: también llevan a product managers, diseñadores y equipos de operaciones a flujos donde el lenguaje natural produce productos ejecutables.

En comparación, Google tiene Gemini y Antigravity, pero no ha logrado formar el mismo punto de entrada predeterminado en la mente de los desarrolladores. El artículo de 36Kr también señala que Antigravity no ha logrado despegar claramente en el mercado externo, y que precios, avisos de cuota y estabilidad de experiencia han generado discusión en la comunidad.

Así que, si el nuevo Gemini necesita demostrar algo, coding será el campo de batalla más directo. La pregunta no es solo si puede escribir código, sino si puede producir interfaces completas de forma estable, entender requisitos complejos, llamar herramientas, corregir errores e integrarse en flujos reales de desarrollo.

Spark puede importar más que 3.5 Pro

En la misma ola de filtraciones también apareció Gemini Spark BETA.

Según TestingCatalog y otras fuentes, Spark se posiciona como un agente de IA always-on: puede procesar la bandeja de entrada, ejecutar tareas online, gestionar flujos de varios pasos y conectar contexto de apps de Google, módulos de habilidades, historial de chats, tareas programadas, sitios con sesión iniciada e información de ubicación.

Eso significa que Spark no es una entrada de chat normal. Podría ser un sistema que permanece online, lee contexto de forma continua y ejecuta tareas por el usuario.

El atractivo es obvio: si Google puede conectar Gmail, Calendar, Chrome, Android, Workspace y Gemini, Spark tendrá una ventaja de distribución difícil de copiar para OpenAI y Anthropic.

El riesgo también es obvio. El artículo de 36Kr menciona una descripción de Spark según la cual podría compartir información o completar compras sin preguntar. Aunque el sistema esté diseñado para pedir permiso antes de operaciones sensibles, este tipo de agente sigue planteando riesgos de privacidad, límites de autorización y acciones accidentales.

Qué significa para usuarios comunes

Si eres un usuario normal de Gemini, lo más importante de esta filtración no es el nombre del modelo, sino tres cambios.

Primero, Google puede seguir reforzando la capacidad de producir resultados completos. Antes, usuarios se quejaban de que Gemini podía ser perezoso en generación visual, SVG y páginas frontend. Si el nuevo modelo puede generar varias propuestas completas en una sola pasada, la experiencia mejorará de forma visible.

Segundo, la capacidad de coding seguirá bajando a modelos más ligeros. La filtración menciona varias veces mejoras de Flash en coding, razonamiento y generación interactiva, lo que significa que en el futuro no siempre hará falta un modelo Pro para tareas complejas.

Tercero, los agentes serán más proactivos. Si Spark se lanza, Gemini podría dejar de limitarse a responder preguntas y empezar a asumir correo, web, compras, calendario y tareas entre apps durante periodos largos.

Eso es bueno para la eficiencia, pero crea un nuevo desafío de gestión de permisos.

Qué significa para desarrolladores

Los desarrolladores deberían vigilar dos cuestiones.

La primera es el ecosistema de herramientas. El artículo de 36Kr dice que la comunidad vio una entrada no publicada llamada MCP Tool Testing en el selector de modelos. Si Gemini soporta MCP o pruebas de herramientas de terceros de forma nativa, será más fácil conectarlo a las toolchains propias de los desarrolladores.

La segunda es coste y estabilidad. Aunque el nuevo Gemini alcance a GPT-5.5 en algunos benchmarks, los desarrolladores acabarán mirando tres cosas: calidad real del código, estabilidad del contexto, y si precios y cuotas son predecibles.

El último año de competencia en herramientas de AI coding ha demostrado que la capacidad del modelo es solo el billete de entrada. Lo que retiene a los desarrolladores es si la herramienta puede editar código, ejecutar tests, leer contexto y manejar casos límite de forma fiable en proyectos diarios.

Cómo leer esta noticia ahora

Esta noticia se entiende mejor como “señal fuerte, confirmación débil”.

La señal fuerte es que múltiples pistas comunitarias apuntan a que Google prepara un Gemini más fuerte y un Gemini Spark Agent más proactivo.

La confirmación débil es que Gemini 3.5 Pro aún no ha sido lanzado oficialmente, Cappuccino sigue siendo un nombre filtrado, y la afirmación de que “alcanza a GPT-5.5” necesita validación con benchmarks oficiales de Google, pruebas de terceros y experiencia real de usuarios.

La lectura más prudente por ahora:

No tratarlo como un producto ya lanzado.
Tratarlo como una vista previa temprana de la próxima dirección de Gemini.
Observar si I/O u otros eventos oficiales confirman el nombre del modelo, disponibilidad de API, precios, ventana de contexto, tool calling y límites de permisos del agente.

Resumen

La exposición de Gemini 3.5 Pro / Cappuccino sugiere que Google podría estar preparando un empuje más fuerte para la próxima generación de Gemini. No intenta corregir una sola capacidad aislada, sino todo un flujo de trabajo de IA: el modelo debe escribir mejor código, generar interfaces y manejar razonamiento complejo, mientras Spark empuja Gemini hacia un agente always-on.

Pero antes de un lanzamiento oficial, todos los benchmarks y capturas siguen siendo pistas. Lo que decidirá si Gemini 3.5 Pro puede recuperar impulso no será si el nombre en clave suena bien, sino si puede ganar de forma fiable en desarrollo real, trabajo de oficina real y tareas reales de varios pasos.

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.

DeepSeek-TUI: convertir DeepSeek V4 en un agente de programación en la terminal

Sat, 16 May 2026 22:41:41 +0800

DeepSeek-TUI es un proyecto open source que lleva DeepSeek V4 al flujo de desarrollo en terminal. No es una simple carcasa de chat. Se parece más a un “agente de programación de línea de comandos”, como Claude Code o Codex CLI: puede leer archivos, modificar código, ejecutar comandos, llamar herramientas y seguir avanzando tareas desde una TUI.

Si ya estás acostumbrado a alternar entre editor y terminal, el valor de este tipo de herramienta es directo: no tienes que copiar código una y otra vez en una ventana de chat web, ni describir manualmente toda la estructura del proyecto. Le das una tarea, puede leer el contexto del workspace actual, planificar pasos, aplicar cambios y devolverte el resultado para revisión.

Resuelve el problema de entrada para usar DeepSeek

Los modelos DeepSeek ya ofrecen buenas capacidades de razonamiento y código, pero para llevar esa capacidad a un flujo real de desarrollo hace falta una capa de ingeniería.

El chat web sirve para hacer preguntas, pero no para editar proyectos durante mucho tiempo. La API sirve para integraciones, pero un desarrollador común tendría que construir por su cuenta llamadas a herramientas, gestión de contexto, operaciones de archivos y control de permisos. DeepSeek-TUI intenta cubrir esa capa: envolver DeepSeek V4 como un Agent que puede trabajar dentro de la terminal.

Según la presentación del proyecto, sus capacidades principales incluyen:

Interfaz TUI en terminal;
Conversación y ejecución de tareas para DeepSeek V4;
Llamadas a herramientas y operaciones de archivos;
Soporte de contexto de 1M;
Modo Auto;
Subagentes;
Ejecución en sandbox;
Cola de tareas persistente.

El objetivo de combinar estas funciones no es que el modelo responda de forma más humana, sino que pueda entrar con más facilidad en el entorno de desarrollo.

Una TUI encaja mejor con tareas largas que una CLI textual

Muchas herramientas AI CLI empiezan con interacción de texto puro: escribes un prompt, esperas la salida, copias comandos o añades más contexto. Es simple, pero cuando la tarea se alarga, se vuelve confuso.

La ventaja de una TUI es que puede colocar conversaciones, archivos, resultados de ejecución y estado de tareas en una interfaz más estable. Para un Agent de programación, eso importa. Una tarea de código rara vez es una sola pregunta y respuesta. Suele incluir:

Entender la estructura del proyecto;
Encontrar archivos relevantes;
Modificar código;
Ejecutar tests o comandos;
Corregir según los errores;
Resumir los cambios.

Si la interfaz solo es una cadena de logs, al usuario le cuesta ver en qué punto está el Agent. Una TUI al menos ofrece un lugar mejor para observar y tomar el control.

El modo Auto conviene para tareas con límites claros

El modo Auto que menciona DeepSeek-TUI encaja con trabajos de límites claros. Por ejemplo, arreglar un bug pequeño, añadir un script, cambiar una configuración, ordenar documentos o implementar una función local.

Estas tareas tienen algo en común: el objetivo es claro, la forma de comprobarlo también, y el alcance del impacto es controlable. El Agent puede revisar archivos, editarlos, ejecutar comandos y luego entregar el resultado al usuario para confirmación.

Pero el modo Auto no debe significar permisos ilimitados. En proyectos reales, borrar archivos, hacer refactors masivos, migrar bases de datos o ejecutar despliegues debería requerir confirmación explícita. La eficiencia de los Agents de programación viene de la automatización, pero el riesgo también. Cuanto más pueda ejecutar comandos una herramienta, más necesita sandbox, límites de permisos y revisión humana.

Los subagentes importan porque dividen tareas

Los subagentes no son un concepto nuevo, pero son útiles en escenarios de código.

Una tarea algo compleja suele requerir varios tipos de trabajo a la vez: alguien lee el código, alguien cambia la implementación, alguien revisa tests y alguien ordena documentación. Los sistemas multi-agent tradicionales a menudo parecen llamativos porque no tienen herramientas reales ni un workspace real; solo discuten dentro de una conversación.

Si los subagentes se combinan con sistema de archivos, ejecución de comandos y cola de tareas, se parecen más a un mecanismo de descomposición de trabajo. Por ejemplo, un subagente analiza dependencias, otro modifica un módulo concreto y el agente principal integra el resultado. Así se reduce el problema de meter demasiada información no relacionada en un solo contexto.

Por supuesto, los subagentes también añaden costo: más tokens, estado más complejo y límites de responsabilidad más difíciles de seguir. Por eso encajan mejor con tareas de complejidad media o superior, no necesariamente con cada cambio pequeño.

El contexto de 1M no es magia, pero ayuda a leer proyectos

El contexto de 1M suena exagerado, pero en programación no es solo una cifra de marketing.

El contexto de un repositorio real está fragmentado: README, archivos de configuración, definiciones de tipos, tests, cadenas de llamadas, convenciones históricas y logs de errores pueden influir en un cambio. Un contexto más largo puede reducir el problema de editar tras mirar solo una parte local, y ayudar al modelo a conservar más restricciones del proyecto.

Aun así, más contexto no significa mejor juicio automáticamente. Las tareas de código siguen necesitando búsqueda, filtrado y verificación. Meter todo el proyecto en el contexto no siempre es mejor que leer con precisión los archivos relevantes. Un buen Agent de programación debería tratar el contexto largo como un buffer, no como un atajo que sustituye el criterio de ingeniería.

Para quién es más útil

DeepSeek-TUI encaja mejor con varios grupos:

Desarrolladores que quieren usar DeepSeek para tareas de código en la terminal;
Personas que no quieren construir por su cuenta frameworks de llamadas a herramientas y operaciones de archivos;
Usuarios que ya conocen Claude Code o Codex CLI y quieren probar una entrada basada en DeepSeek;
Quienes necesitan contexto de proyecto local, no solo preguntar por fragmentos de código en una web;
Desarrolladores que quieren llevar el flujo de AI Coding al entorno de línea de comandos.

Si solo preguntas de vez en cuando cómo escribir una función, el chat web basta. Si quieres que el modelo participe directamente en cambios del proyecto, un Agent de terminal tiene más sentido.

Riesgos a vigilar

Hay tres cosas especialmente importantes en este tipo de herramienta.

La primera son los permisos. Si una herramienta puede leer y escribir archivos o ejecutar comandos, hay que saber a qué puede acceder por defecto, si puede borrar archivos, si puede conectarse a la red y si los comandos peligrosos requieren confirmación.

La segunda es la reversibilidad. Antes de usarla, conviene mantener limpio el árbol de trabajo de Git, para que cada cambio del Agent pueda verse claramente con git diff. No conviene dejar que un Agent edite automáticamente un proyecto con muchos cambios sin commit.

La tercera es la verificación. Que el Agent escriba código no significa que la tarea esté terminada. Tests, builds, lint y review humana siguen siendo necesarios. Las herramientas de AI Coding pueden acelerar el avance, pero no sustituyen la confirmación final de ingeniería.

Conclusión

La importancia de DeepSeek-TUI no está en añadir otro cliente de chat, sino en poner DeepSeek V4 dentro de un entorno de terminal más cercano al trabajo real de desarrollo.

Para los desarrolladores, la capacidad del modelo es solo el primer paso. La experiencia real depende de si puede leer el proyecto, modificar archivos con seguridad, ejecutar comandos de verificación, mantener estado en tareas largas y permitir que el usuario tome el control en cualquier momento.

Si quieres usar DeepSeek para cambios diarios de código, lectura de proyectos y tareas de desarrollo automatizadas, DeepSeek-TUI merece atención. La dirección también está clara: las herramientas de AI Coding están pasando de “responder preguntas de código” a “participar en la ejecución de proyectos”.

¿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.

Filtraciones de Gemini 3.5 Pro: Google quiere recuperar la entrada de programación AI con Spark Agent

Fri, 15 May 2026 23:45:34 +0800

Gemini 3.5 Pro todavía no se ha lanzado oficialmente, pero las filtraciones a su alrededor ya están ganando fuerza.

La información actual gira alrededor de varios términos: Gemini 3.5 Pro, el nombre en clave Cappuccino, Gemini Spark, programación AI e integración de herramientas MCP. Todos apuntan en la misma dirección: Google no solo quiere actualizar otro modelo de chat. Quiere volver a conectar modelos, herramientas, Agents y puntos de entrada del ecosistema Google.

Antes de un lanzamiento oficial, todo esto debe tratarse como información filtrada. La señal importante no está en una captura concreta ni en un resultado de benchmark, sino en las carencias que Google podría estar intentando cerrar.

Por Qué Gemini 3.5 Pro Importa

Según la información expuesta, Gemini 3.5 Pro podría representar un salto de nombre.

Hasta hace poco se hablaba de Gemini 3.2, y luego apareció Gemini 3.5 Pro en filtraciones. Si el nombre es real, Google probablemente quiere contar una historia de versión más grande en la próxima presentación, no solo lanzar una actualización menor.

Los puntos filtrados se concentran principalmente en tres áreas:

mejoras continuas en programación y razonamiento;
mayor capacidad para generar SVG, páginas interactivas, animaciones y 3D;
un nuevo producto Agent, Gemini Spark, que podría pasar al primer plano.

Ninguna de estas direcciones sorprende. Gemini siempre ha enfatizado la multimodalidad, y Google tiene canales de distribución muy fuertes. La verdadera pregunta es si puede alcanzar el ritmo de OpenAI y Anthropic en herramientas para desarrolladores y flujos de trabajo tipo Agent.

La Programación Es La Asignatura Que Google Más Necesita Recuperar

En 2026, la programación ya no es solo un punto de evaluación de modelos. Se ha convertido en uno de los puntos de entrada de producto más directos.

La razón es simple: las herramientas de programación AI tienen uso frecuente y generan muchos datos de retroalimentación. Los desarrolladores piden a los modelos leer código, modificar código, ejecutar pruebas y corregir errores todos los días. Estas interacciones empujan de forma natural la siguiente generación de modelos y herramientas.

Durante el último año, Claude Code ha ganado mucha presencia entre desarrolladores, mientras OpenAI ha seguido reforzando la colaboración entre Codex y ChatGPT. Google tiene productos como Antigravity, pero su presencia externa no ha sido tan fuerte.

Por eso Gemini 3.5 Pro está bajo observación. Si solo chatea mejor o responde más rápido, el impacto será limitado. Si realmente mejora la comprensión de código, la edición entre varios archivos, las llamadas a herramientas y la ejecución de tareas largas, entonces sí puede cambiar flujos de trabajo de desarrollo.

Gemini Spark Puede Ser La Variable Más Grande

Más agresivo que el modelo en sí es el rumoreado Gemini Spark.

Según las filtraciones, Spark no se posiciona como un asistente de chat normal, sino como un AI Agent siempre activo. Podría conectarse a correo, calendario, páginas web, tareas, estado de cuenta y contexto personal para ayudar al usuario a manejar flujos de varios pasos.

Este tipo de producto abre mucho espacio de imaginación. Por ejemplo:

organizar automáticamente la bandeja de entrada;
hacer seguimiento de tareas para el usuario;
ejecutar acciones en páginas web;
manejar procesos entre aplicaciones;
organizar asuntos diarios según preferencias personales.

Pero los riesgos son igual de evidentes. Si un Agent siempre activo puede acceder al estado de sesión, datos del navegador, archivos, ubicación y servicios de terceros, debe responder varias preguntas: ¿cuándo debe confirmar el usuario una acción? ¿qué operaciones deben quedar prohibidas para la automatización? ¿se compartirán datos con terceros? ¿cómo se aíslan el navegador remoto y las credenciales?

Así que el punto clave de Spark no es solo si puede hacer trabajo por ti. Es si Google puede dejar suficientemente claros los permisos, la auditoría, los flujos de confirmación y el control del usuario.

Qué Sugiere La Integración De Herramientas MCP

Las filtraciones también mencionan que el nuevo selector de Gemini podría incluir modelos o entradas de prueba relacionadas con MCP.

Si esto llega al producto, sugiere que Google también está empujando los modelos desde un sistema de preguntas y respuestas hacia un sistema operativo de herramientas. El modelo ya no solo genera texto. Debe llamar herramientas externas, acceder a sistemas de negocio, leer y escribir archivos, ejecutar comandos y mantener estado de tarea entre varios pasos.

Es la misma dirección que siguen OpenAI y Anthropic. Quien logre llamadas a herramientas más estables tendrá más facilidad para insertar AI en flujos reales.

Pero la integración MCP no es el final. Lo difícil es la estabilidad:

si el modelo puede elegir la herramienta correcta;
si los parámetros son fiables;
si puede recuperarse tras un fallo;
si los límites de permisos están claros;
si el usuario puede rastrear cada paso.

Si estas preguntas no se resuelven, más herramientas también significan más superficie de error.

La Multimodalidad Sigue Siendo Una Carta Fuerte Para Google

El área donde Google tiene más opciones de diferenciarse sigue siendo la multimodalidad.

Según los ejemplos filtrados de SVG, páginas interactivas, animaciones y generación visual, Gemini podría seguir reforzando la capacidad de generar contenido interactivo a partir de prompts. Frente a escribir solo un fragmento de código, esto se acerca más al prototipado de producto: el usuario describe una idea y el modelo entrega directamente una interfaz operable, ajustable y previsualizable.

Esta ruta encaja bien con Google. Aprovecha las fortalezas multimodales de Gemini y también puede conectarse con Android, Chrome, Workspace, Search, Ads y Cloud.

Si Google quiere evitar competir solo en “qué modelo programa mejor”, probablemente pondrá más peso en un sistema Agent multimodal más completo.

Las Tres Compañías Empiezan A Diferenciar Sus Jugadas

La competencia actual de grandes modelos ya no es solo una competencia de rankings.

La ventaja de OpenAI está en la velocidad de iteración de producto y distribución. Codex, ChatGPT, herramientas empresariales y APIs están cada vez más conectados.

La ventaja de Anthropic está en la mente de los desarrolladores y en la calidad de sus modelos de código. Claude Code ya se ha convertido en el punto de entrada de programación AI por defecto para muchas personas.

La ventaja de Google es el acceso al ecosistema. Gmail, Docs, Chrome, Android, Search, YouTube, Maps y servicios cloud forman una enorme red de datos personales y empresariales. Si los Agents pueden conectarse a estos puntos de entrada de forma segura, Google puede pasar de ser un “perseguidor de modelos” a controlar entradas de flujo de trabajo.

Por eso Gemini Spark merece atención. No necesita quedar primero en todos los benchmarks. Si logra entrar en los flujos diarios, puede construir su propio foso.

Cómo Deberían Leer Esto Los Usuarios Comunes

Para usuarios comunes, no hace falta dejarse arrastrar por cada filtración a corto plazo.

Los puntos prácticos a observar son tres:

Si la capacidad de programación de Gemini 3.5 Pro mejora de verdad, especialmente en repositorios complejos, contexto largo y llamadas a herramientas.
Si Gemini Spark es seguro por defecto, con confirmación clara y registros rastreables antes de operaciones sensibles.
Si Google ofrece precios, cuotas y gestión de permisos empresariales claros, no solo demos llamativas.

Generar unas cuantas capturas bonitas tiene valor limitado. Poder conectarse de forma estable a flujos reales es la línea divisoria de esta generación de productos AI Agent.

Qué Significa Para Desarrolladores

Los desarrolladores deberían preocuparse menos por “qué modelo ganó” y más por si su flujo de trabajo es portable.

Claude Code, Codex, Gemini, Antigravity, Cursor, Windsurf y muchas otras herramientas compiten por el punto de entrada. Si todos los procesos quedan atados a una sola plataforma, cualquier cambio futuro de coste, cuota, política de modelo o regla de permisos hará dolorosa la migración.

Una postura más segura es:

mantener flujos Git estándar en proyectos importantes;
revisar siempre el diff después de ediciones automáticas;
usar pruebas y CI como respaldo para tareas clave;
no entregar credenciales de producción a Agents opacos;
cuando se puedan conectar herramientas con protocolos abiertos, preferir opciones reemplazables.

Los modelos seguirán mejorando, pero la disciplina de ingeniería no quedará obsoleta.

Resumen

Las filtraciones de Gemini 3.5 Pro sugieren que Google está acelerando para cerrar brechas en programación AI y puntos de entrada tipo Agent. La mejora del modelo es solo una parte; Agents siempre activos como Gemini Spark podrían ser el movimiento estratégico más grande.

Pero cuanto más puede un sistema “hacer cosas automáticamente” por el usuario, más necesita límites estrictos de permisos y flujos verificables. Para Google, el reto real no es solo alcanzar a GPT-5.5 o Claude. Es combinar modelos fuertes, mecanismos de seguridad y entradas de ecosistema en un flujo diario confiable.

Si lo consigue, Gemini no necesitará liderar todos los rankings para recuperar parte de la iniciativa en los puntos de entrada de AI.

Lectura rápida de OpenHuman: la ruta de escritorio para un AI Agent personal de código abierto

Fri, 15 May 2026 14:52:31 +0800

OpenHuman es un proyecto de AI Agent personal de código abierto creado por tinyhumansai. Su objetivo no es construir otra ventana de chat, sino colocar una aplicación de escritorio, memoria personal, integraciones de terceros, voz, herramientas de programación y una base de conocimiento local dentro del mismo agent harness, para que la IA entienda más rápido el contexto de tu trabajo diario.

El README del proyecto lo presenta como “Personal AI super intelligence”, y el sitio oficial también destaca private, simple y extremely powerful. Es una afirmación ambiciosa, pero conviene descomponerla: lo realmente interesante de OpenHuman es que intenta poner el “contexto personal” en el centro del producto, en lugar de dejar al usuario la tarea de ensamblar llamadas a modelos, configuración de plugins y búsqueda documental.

En el momento de revisar este artículo, el repositorio de GitHub tenía alrededor de 7.8k stars y 629 forks. La versión más reciente era OpenHuman v0.53.43, fechada el 13 de mayo de 2026. El proyecto sigue en Early Beta, y el README advierte claramente que está en desarrollo activo, así que conviene esperar bordes ásperos.

Qué problema intenta resolver

El problema de muchos asistentes de IA no es que el modelo sea débil, sino que el contexto está demasiado frío. Cada vez tienes que volver a explicar el fondo del proyecto, correos recientes, calendario, repositorios de código, documentos, tareas y preferencias. Cuando cruzas Gmail, Notion, GitHub, Slack, Calendar, Drive, Linear, Jira y otros sistemas, la información se dispersa entre herramientas distintas.

La idea de OpenHuman es conectar primero esas fuentes de datos y luego construir una capa de memoria personal que pueda actualizarse continuamente mediante captura automática, compresión, resumen y base de conocimiento local. Así el agent no recuerda solo la conversación actual, sino que puede formar contexto a largo plazo alrededor de tu flujo de trabajo.

Esa es también su mayor diferencia frente a un chatbot común. Los chatbots suelen trabajar alrededor del prompt; OpenHuman se parece más a una entrada de sistema operativo personal en el escritorio, intentando empaquetar de antemano conectores, memoria, herramientas y enrutamiento de modelos.

Capacidades principales

Las capacidades centrales listadas en el README de OpenHuman incluyen:

UI orientada al escritorio y una ruta de inicio corta, sin exigir que el usuario empiece configurando desde la terminal.
Un mascot de escritorio con “cara”, capaz de hablar, responder al entorno y participar en Google Meet.
118+ integraciones de terceros, con Gmail, Notion, GitHub, Slack, Stripe, Calendar, Drive, Linear, Jira y otras herramientas.
Mecanismo de captura automática: la descripción del proyecto menciona recorrer conexiones activas cada 20 minutos y llevar nuevos datos al memory tree.
Memory Tree: comprime datos conectados e información de actividad en bloques Markdown y los guarda en SQLite local.
Obsidian-compatible vault: escribe bloques de conocimiento como archivos .md, que el usuario puede abrir, navegar y editar con Obsidian.
Búsqueda integrada, captura web, herramientas de programación, sistema de archivos, git, lint, test, grep, entrada y salida de voz, entre otras capacidades.
Model routing: enruta solicitudes a distintos tipos de modelo según la tarea.
TokenJuice: comprime tokens antes de que resultados de herramientas, páginas web, cuerpos de correo y resultados de búsqueda entren al LLM.
Ollama opcional para cargas de trabajo de IA locales.

La lista es amplia, pero el foco real se puede resumir en dos puntos: reducir configuración y ensamblaje de plugins, y convertir tus datos personales en memoria que el agent pueda buscar, comprimir y actualizar de forma continua.

Instalación

El proyecto ofrece una entrada de descarga en el sitio web y comandos de instalación desde terminal.

macOS o Linux x64:

`1`	`curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh \| bash`

Windows:

`1`	`irm https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.ps1 \| iex`

Si se trata de tu máquina principal de uso diario, conviene descargar primero el instalador desde el sitio oficial, o al menos abrir y revisar el script antes de decidir si ejecutar directamente un script remoto. OpenHuman involucra permisos sobre correo, documentos, repositorios de código, calendarios y archivos locales, así que la instalación y autorización merecen más cuidado que una utilidad pequeña común.

Código abierto y stack técnico

El repositorio de OpenHuman usa licencia GPL-3.0. El desglose de lenguajes muestra Rust como principal, seguido por TypeScript, además de JavaScript, Shell, CSS y PowerShell. Las notas de contribución del README requieren Node.js 24+, pnpm 10.10.0, Rust 1.93.0, CMake y dependencias de compilación de escritorio específicas por plataforma.

La ruta aproximada de desarrollo local es:

git submodule update --init --recursive
pnpm install
pnpm dev
pnpm --filter openhuman-app dev:app

Antes de enviar cambios se recomiendan focused checks, por ejemplo:

1
2
3

pnpm typecheck
pnpm format:check
cargo check -p openhuman --lib

Por la estructura del directorio, no es un proyecto de scripts ligero. Es un repositorio de producto completo con aplicación de escritorio, frontend, backend en Rust, documentación, pruebas, ejemplos y scripts de build.

Por qué importan Memory Tree y Obsidian vault

El concepto de OpenHuman que más merece una mirada aparte es Memory Tree. El README describe que normaliza los datos conectados en Markdown chunks de hasta unos 3k tokens, los puntúa, los pliega en un árbol jerárquico de resúmenes y los guarda en SQLite local. El mismo contenido también entra en un vault compatible con Obsidian.

Esta ruta tiene varias ventajas:

El usuario puede ver directamente la base de conocimiento del agent, en lugar de confiar solo en una memoria de caja negra.
Los archivos Markdown facilitan búsqueda, backup, control de versiones y revisión manual.
SQLite sirve bien para indexación local y consultas rápidas.
Los resúmenes jerárquicos son más adecuados para compresión de contexto a largo plazo que una pila plana de documentos.

Pero también hay desafíos prácticos: si la sincronización de datos es estable, si los resúmenes pierden detalles clave, si los límites de permisos son lo bastante claros, si la eliminación y reversión son completas, y si la semántica de distintos conectores se puede manejar de forma consistente. Nada de eso queda resuelto por una frase del README como “remembers everything”; requiere uso prolongado y auditoría.

TokenJuice: capa intermedia para costo y latencia

OpenHuman también destaca TokenJuice. Su función es comprimir páginas web, correos, resultados de búsqueda y resultados de llamadas a herramientas antes de que entren al modelo. Por ejemplo, convertir HTML a Markdown, acortar URL largas y eliminar algunos caracteres innecesarios. El README afirma que esto puede reducir costo y latencia, con hasta 80% menos uso de tokens.

La dirección es razonable. En sistemas de agents, lo que realmente consume recursos no suele ser una conversación aislada, sino captura en segundo plano, llamadas a herramientas, búsqueda, análisis de páginas web e inyección de contexto largo. Limpiar los datos antes de entregarlos al modelo suele ser más estable que meter contenido crudo directamente.

Sin embargo, una capa de compresión también trae preguntas nuevas: decide qué información se conserva y cuál se descarta. Si la usas para contratos, facturas, registros médicos, material de cumplimiento o logs de incidentes de producción, no basta con mirar ahorro de tokens; también hay que revisar trazabilidad, consulta del texto original y error de compresión.

Privacidad: argumento de venta y foco de auditoría

Uno de los argumentos de OpenHuman es private. El sitio oficial menciona que los modelos de IA locales pueden manejar tareas de bajo nivel, y el README enfatiza workflow data stays on device, encrypted locally y treated as yours.

Esta dirección de diseño resulta atractiva, porque cuando un AI Agent personal se conecta a Gmail, Drive, Calendar, Slack y GitHub, toca algunos de los datos de trabajo más sensibles. Frente a un asistente completamente en la nube, una capa de memoria local-first y un Markdown vault visible al menos dan al usuario más sensación de control.

Pero también hay que contar la historia completa: OpenHuman menciona one subscription, 30+ providers, model routing, ElevenLabs TTS, OAuth integrations y otras capacidades. Eso significa que no es una herramienta puramente offline. Para evaluar la privacidad en serio, hay que mirar qué datos envía cada conector, cada tipo de llamada a modelo y cada función de voz o búsqueda, y a dónde los envía.

Para quién es relevante

OpenHuman hoy encaja mejor con tres grupos:

Usuarios que quieren una mesa de control de IA personal, no solo un chatbot puntual.
Desarrolladores dispuestos a probar una Early Beta y aceptar cambios de funciones y bordes ásperos.
Personas interesadas en memoria local, flujos de Obsidian, agent connector y compresión de contexto.

Si solo quieres un asistente offline estable, ligero y con límites de privacidad muy simples, por ahora quizá sea demasiado pesado. Si quieres estudiar cómo la próxima generación de AI Agents personales podría integrar escritorio, conectores, memoria y herramientas, OpenHuman es una muestra de código abierto que vale la pena seguir.

Mi sugerencia es observarlo primero como un “experimento open source con forma de producto”: mirar ritmo de releases, calidad de issues, permisos de conectores, capacidad de exportar datos, mecanismos de eliminación y legibilidad del vault local. La clave de la IA personal no es solo si puede responder preguntas, sino si puede cargar tu contexto a largo plazo de forma transparente y controlable.

Referencias

Qué es Token Efficiency: DeepSeek V4, planificación con modelos grandes y ejecución con modelos pequeños

Fri, 15 May 2026 08:59:33 +0800

La próxima métrica importante en AI Coding quizá no sea quién tiene el modelo más fuerte, sino quién completa más trabajo verificable con menos tokens, menor coste y un proceso más estable.

Ese es el valor de Token Efficiency.

Muchos lo entienden como modelos baratos, contexto largo o cache hits más económicos. Eso es solo la base. Lo que lo convierte en productividad es la división de trabajo entre modelos, la orquestación de tareas, el presupuesto de contexto y la evaluación.

Token Efficiency no es un truco para ahorrar dinero. Es un método de ingeniería para convertir tokens en producción.

DeepSeek V4: separar planificación y ejecución

DeepSeek V4 no es solo otro modelo más fuerte. Divide las dos capacidades necesarias para Token Efficiency en V4 Pro y V4 Flash: V4 Pro encaja mejor con planificación, razonamiento, juicio arquitectónico y revisión crítica; V4 Flash encaja con ejecución frecuente, reescritura en lote, completado de código, organización de información y nodos normales de un agente.

En AI Coding esto se traduce así:

V4 Pro: planner / consultant para requisitos, diseño técnico, bugs complejos, revisión de arquitectura y aceptación final.
V4 Flash: executor para escanear archivos, implementar cambios simples, completar tests, ordenar documentación, generar candidatos y repetir tareas.

La documentación API de DeepSeek indica que ambos soportan 1M de contexto, JSON Output, Tool Calls, Chat Prefix Completion y FIM Completion. La página de precios también separa input con cache hit y señala una bajada fuerte de ese precio.

La combinación es lo importante: 1M de contexto reduce compresión en tareas agent complejas; el cache hit barato reduce el coste de volver a cargar prompts, docs, código e historial; la separación Flash / Pro evita usar un modelo flagship para cada paso o depender solo de un modelo pequeño inestable.

Así, DeepSeek V4 ofrece una estructura de coste realista para el patrón “modelo consultor + modelo ejecutor + harness de orquestación”.

No hacer que el modelo más fuerte lo haga todo

Antes era común elegir el modelo más inteligente y dejarle requisitos, código, tests y resumen de punta a punta.

Es sencillo, pero no siempre eficiente. Muchas tareas no necesitan razonamiento de frontera. Los modelos caros deberían actuar como consultores, arquitectos o planificadores que intervienen en puntos clave.

Una estructura mejor:

Modelos grandes para descomponer problemas y tomar decisiones clave.
Modelos pequeños para ejecutar, procesar en lote y repetir cambios.
Herramientas y harness para proceso, estado, contexto y validación.
Personas para definir producto, aceptar resultados y decidir tradeoffs.

Así el razonamiento caro no se desperdicia en ejecución mecánica.

Más contexto no siempre es mejor

El contexto largo importa en coding agents porque código, documentos, historial, salida de tests y logs consumen ventana. Cuando se llena, aparecen compresión, olvido y errores de juicio.

Pero contexto largo no significa meterlo todo.

Token Efficiency exige que cada tarea quepa en una ventana clara y controlada: archivos necesarios, documentos relevantes para la decisión, estado actual, entradas y salidas claras, y resumen estructurado para el siguiente nodo.

Si el contexto es barato, la tentación es meter ruido. El ruido no hace al modelo más inteligente.

El harness importa más que un modelo aislado

Conectar Claude Code, Codex u otro agent a un modelo barato no basta. Los modelos pequeños se desvían en cadenas largas si no hay control de proceso.

Un harness decide cómo dividir tareas, correr nodos, escoger modelos, validar resultados, reintentar fallos y pasar contexto.

Sin esa capa, un modelo pequeño solo es barato. Con esa capa, puede convertirse en palanca.

Dividir tareas con DAG

Una tarea compleja puede convertirse en un DAG. Por ejemplo: aclarar requisitos, diseñar solución, dividir tareas, implementar, completar tests, hacer Code Review, corregir y enviar PR.

Cada nodo puede ser un agente independiente con rol, prompt, permisos de herramientas y formato de salida. Los nodos deberían intercambiar resultados estructurados, no conversaciones largas.

Esto hace cada nodo más corto, más fácil para modelos pequeños y más medible.

Ejecutar varias réplicas de una tarea

Cuando los tokens son suficientemente baratos, una tarea no tiene por qué ejecutarse una sola vez. Puedes correrla con distintos modelos, prompts u orquestaciones, luego elegir el mejor resultado o combinar partes útiles.

Sirve para diseños, copy, casos de prueba, hipótesis de bug, alternativas de refactor y Code Review. No sirve para tareas con efectos externos, estado compartido o criterios de aceptación borrosos.

El objetivo no es apostar, sino obtener muestras comparables para mejorar la orquestación y la elección de modelos.

Construir evaluación

Token Efficiency no se mide solo por precio. Un modelo barato con alta tasa de fallo consume tiempo humano y puede salir más caro.

Conviene registrar tasa de finalización, intervenciones humanas, fallos de tool calls, tests que pasan, hallazgos de review, coste por tarea, tiempo, retrabajo y diferencias entre combinaciones de modelos.

Con esos datos se sabe qué tareas van bien con modelos pequeños, cuáles requieren modelos grandes y cuáles deben quedarse en manos humanas.

Hacer atómicos los workflows

No todo el mundo tiene que construir un harness completo. Pero sí puede dividir sus procesos en nodos atómicos.

Producción de contenido: tema, investigación, esquema, borrador, fact-check, estilo, título SEO, traducción y revisión de publicación.

Desarrollo de software: requisitos, diseño técnico, estructura de datos, cambios de API, unit tests, implementación, migraciones, documentación y review.

Cada nodo debe tener entrada, salida, aceptación y contexto claros. Cuando maduren las herramientas de harness, esos procesos podrán conectarse directamente.

El hardware no es lo primero

Muchas conversaciones sobre Token Efficiency saltan a despliegue local y GPU. Para la mayoría, la API debería ser la primera opción.

Antes de validar el modelo económico, el hardware local es coste adelantado. Mejor: validar el workflow con API, medir coste y calidad, detectar nodos frecuentes y estables, y solo después estudiar qué merece localizar.

Resumen

Token Efficiency no consiste en sustituir modelos caros por baratos, sino en rediseñar el workflow de IA.

Modelos grandes juzgan, modelos pequeños ejecutan, el harness orquesta y valida, y las personas definen objetivos y aceptación. Solo juntas estas capas convierten tokens en productividad.

La diferencia futura quizá no esté en quién llama al modelo más fuerte, sino en quién convierte los mismos tokens en más resultados reales.

Superpowers: un framework de skills que devuelve los coding agents al proceso de ingeniería

Fri, 15 May 2026 08:53:17 +0800

obra/superpowers es un framework de skills para coding agents y también una metodología de desarrollo de software. Su objetivo no es crear otro prompt universal, sino hacer que el agente siga un proceso: aclarar objetivos, producir diseño, escribir un plan, implementar con TDD, revisar y cerrar.

Proyecto: https://github.com/obra/superpowers

En el momento de escribir, la API de GitHub muestra más de 190.000 stars, licencia MIT y actividad reciente. El README lo describe como An agentic skills framework & software development methodology that works.

Qué problema resuelve

Muchas herramientas de AI Coding no fallan por no saber escribir código, sino por escribirlo demasiado pronto.

El usuario da una petición vaga, el agente edita archivos y el resultado parece terminado, aunque los límites, tests y arquitectura sigan sin estar claros. En tareas pequeñas puede pasar; en proyectos complejos se convierte en retrabajo y deuda técnica.

Superpowers hace que el agente entre en un workflow antes de tocar código:

Si detecta que el usuario quiere construir algo, pregunta primero por el objetivo.
Convierte la conversación en una especificación y la confirma por partes.
Tras aprobar el diseño, genera un plan de implementación.
Solo cuando el usuario dice “go” empieza a implementar.
Durante la implementación enfatiza TDD, YAGNI, DRY y revisión.

No es ingeniería nueva, pero los agentes rápidos necesitan barandillas más fuertes.

Herramientas soportadas

Superpowers no está ligado a un único agente. El README lista Claude Code, Codex CLI, Codex App, Factory Droid, Gemini CLI, OpenCode, Cursor y GitHub Copilot CLI.

Su papel se parece más a una capa de workflow entre harnesses que a un truco para un modelo concreto.

Workflow base

Primero está brainstorming: antes de implementar, el agente convierte ideas vagas en diseño ejecutable y lo confirma.

Después using-git-worktrees: crea un worktree y una rama aislados, y comprueba que instalación y tests parten de una base limpia.

Luego writing-plans: divide el diseño en tareas pequeñas con rutas, alcance de código y pasos de validación.

En ejecución puede usar subagent-driven-development para delegar o executing-plans para avanzar por lotes. Cada tarea debe poder revisarse y verificarse.

Después llega test-driven-development: RED-GREEN-REFACTOR real. Escribir un test que falla, confirmar el fallo, implementar lo mínimo, confirmar el paso y refactorizar.

requesting-code-review introduce revisión entre tareas, y los hallazgos críticos bloquean el avance.

Finalmente finishing-a-development-branch valida tests y ofrece opciones como merge, PR, conservar o descartar el worktree.

Qué hay en la Skills Library

La parte de testing gira alrededor de test-driven-development.

La parte de debugging incluye systematic-debugging y verification-before-completion: reproducir, minimizar, formular hipótesis, validar y no declarar completado sin verificar.

Las skills de colaboración incluyen:

brainstorming
writing-plans
executing-plans
dispatching-parallel-agents
requesting-code-review
receiving-code-review
using-git-worktrees
finishing-a-development-branch
subagent-driven-development

También hay skills meta como writing-skills y using-superpowers.

Juntas dan al agente hábitos de ingeniería: cuándo preguntar, planificar, testear y detenerse para review.

Diferencia frente a un prompt normal

Un prompt normal suele apilar reglas en un system prompt: no cambies de más, piensa primero, prueba, explica, sé breve. Cuantas más reglas, más fácil es que el modelo olvide algunas en tareas complejas.

Superpowers divide las reglas en módulos de workflow activables. Cada skill es más corta y enfocada. El agente sabe en qué fase está, el proceso se vuelve revisable y el equipo puede codificar sus propias prácticas.

La lección no es solo usar un modelo más inteligente, sino darle una forma repetible de trabajar.

Para quién sirve

Superpowers encaja mejor con desarrolladores que ya usan coding agents en proyectos reales: tareas de varios archivos, diseño antes de implementación, TDD o validación, ramas o worktrees paralelos, subagents para implementación o review, y equipos que quieren convertir su flujo en skills reutilizables.

Para cambiar una línea de configuración puede ser pesado. Para trabajos de varias fases, sus restricciones aportan valor.

Precauciones

No es piloto automático. Da proceso al agente, pero requisitos, límites y aceptación final siguen siendo humanos.

TDD y review añaden coste inicial. En tareas pequeñas pueden parecer lentos; en tareas complejas reducen retrabajo.

Los subagents en paralelo no siempre ayudan. Funcionan si los límites y el alcance de escritura son claros. Si el requisito es borroso, el paralelismo multiplica la confusión.

También hay que mantener la calidad de las skills. Procesos obsoletos, instrucciones vagas y reglas conflictivas perjudican al agente.

Resumen

Superpowers vale porque aleja al coding agent de “recibir petición y editar código” y lo devuelve al proceso de ingeniería de software.

Lo que falta en AI Coding no suele ser velocidad de generación, sino aclaración, planificación, verificación, review y cierre. Cuanto más fuerte sea el modelo, menos conviene saltarse esos pasos.

Si usas Codex, Claude Code, Cursor o Gemini CLI en proyectos reales, Superpowers merece una lectura. Aunque no lo instales, su forma de dividir skills sirve como referencia para diseñar tu propio workflow de agentes.

Codex /goal vs Claude Code /goal: ejecutar tareas largas hasta terminarlas

Thu, 14 May 2026 22:25:31 +0800

/goal se está convirtiendo en un comando importante dentro de las herramientas de programación con IA.

No se trata de hacer que el modelo escriba unas cuantas líneas más de código. Resuelve un problema más práctico: cuando una tarea tiene condiciones claras de finalización, ¿puede el Agent seguir avanzando hasta cumplirlas, en lugar de detenerse después de cada turno y esperar a que el usuario escriba “continúa”?

Codex CLI ya añadió un /goal experimental en su documentación oficial. Claude Code también publicó su propia documentación de /goal, y lo describe como una capacidad de automatización que puede seguir trabajando durante varios turnos. El nombre es el mismo, pero la orientación del producto no es exactamente igual.

Qué problema resuelve `/goal`

Una conversación normal de programación con IA suele funcionar turno por turno:

El usuario plantea una tarea.
El Agent analiza, modifica código y ejecuta pruebas.
El Agent informa el resultado.
El usuario decide el siguiente paso.

Ese flujo funciona bien para tareas cortas. Pero cuando se trata de migraciones, refactors, correcciones de pruebas o limpieza de un issue backlog, se vuelve fragmentado. El Agent puede avanzar solo un poco y luego detenerse hasta que escribas “continúa”.

La idea de /goal es cambiar la pregunta de “qué hago ahora” a “qué estado final cuenta como terminado”. Por ejemplo:

`1`	`/goal 完成登录模块迁移，所有 auth 测试通过，lint 无报错`

Este tipo de objetivo encaja de forma natural con tareas largas, porque tiene un punto final claro: las pruebas pasan, la compilación funciona, los archivos se han dividido, una cola queda vacía o se cumplen los criterios de aceptación.

`/goal` en Codex: experimental y ligado al hilo actual

La documentación de Codex CLI de OpenAI marca /goal como experimental. No es una capacidad estable activada por defecto; primero hay que habilitar features.goals.

Hay dos formas de hacerlo:

`1`	`/experimental`

O añadir esto a config.toml:

1
2

[features]
goals = true

Una vez habilitado, se puede usar así:

`1`	`/goal Finish the migration and keep tests green`

Los comandos habituales incluyen:

/goal
/goal pause
/goal resume
/goal clear

Según la documentación de OpenAI, Codex adjunta el goal al active thread actual y sigue ese objetivo mientras avanza una tarea más grande.

Aquí hay un detalle importante: el lenguaje oficial sobre Codex /goal es prudente. Enfatiza configurar un objetivo experimental para trabajo de larga duración y adjuntar ese objetivo al hilo actual, pero no describe con el mismo detalle que la documentación de Claude Code un evaluator independiente que revise cada turno y arranque automáticamente el siguiente. Por eso, de momento conviene tratar Codex /goal como un mecanismo experimental para objetivos de tareas largas, no como un modo de ejecución desatendida plenamente estable.

`/goal` en Claude Code: ejecución por varias rondas guiada por condiciones de finalización

La documentación de /goal en Claude Code es más explícita: después de que el usuario define una completion condition, Claude sigue trabajando entre turnos hasta cumplirla.

Ejemplo:

`1`	`/goal all tests in test/auth pass and the lint step is clean`

El mecanismo de Claude Code, a grandes rasgos, es este:

Cuando termina el turno actual, el control no vuelve inmediatamente al usuario.
Un modelo pequeño y rápido revisa si la condición del objetivo ya se cumplió.
Si no se cumplió, Claude empieza automáticamente el siguiente turno.
Si se cumplió, el goal se borra automáticamente y el estado de finalización queda registrado en el transcript.

Esto hace que /goal en Claude Code se parezca más a “continuar automáticamente hasta satisfacer la condición de finalización”. No solo fija un objetivo en la conversación; delega en un paso de evaluación independiente la decisión de si debe continuar.

Claude Code también permite ver el estado directamente:

/goal

El estado muestra la condición del objetivo, el tiempo transcurrido, la cantidad de turnos evaluados, el consumo de tokens y la razón más reciente del evaluator.

Para detenerlo antes de tiempo, se puede usar:

`1`	`/goal clear`

stop, off, reset, none y cancel también funcionan como alias de limpieza. Después de activar un objetivo, si la sesión se interrumpe y más tarde se reanuda con --resume o --continue, un goal activo puede recuperarse. Sin embargo, el tiempo, el número de turnos y la línea base de tokens se recalculan.

La diferencia principal

Codex y Claude Code están empujando la programación con IA desde respuestas de un solo turno hacia la ejecución de tareas largas, pero la posición de /goal no es la misma.

Comparación	Codex CLI `/goal`	Claude Code `/goal`
Estado	experimental	documentado en una página oficial dedicada
Activación	requiere `features.goals`	usable directamente en un workspace confiable
Alcance del objetivo	active thread actual	session actual
Operaciones habituales	set / view / pause / resume / clear	set / view / clear
Evaluación automática	la documentación enfatiza adjuntar y seguir el objetivo	la documentación describe checks del evaluator después de cada turno
Continuación automática	el lenguaje oficial es prudente	empieza el siguiente turno automáticamente si las condiciones no se cumplen
Mejor caso de uso	mantener un objetivo de largo plazo en una tarea de Codex	dejar que Claude Code avance según condiciones de finalización

En resumen, /goal en Codex se parece más a “adjuntar un objetivo experimental de largo plazo al hilo actual”. /goal en Claude Code se parece más a “definir una condición verificable de parada para la sesión actual y dejar que siga trabajando hasta satisfacerla”.

Cómo escribir un buen `/goal`

Uses la herramienta que uses, /goal no es un buen lugar para deseos vagos.

Un mal ejemplo:

`1`	`/goal 把项目优化一下`

Un mejor ejemplo:

`1`	`/goal 将 payment 模块迁移到新 API，npm test -- payment 退出码为 0，git diff 只包含 payment 相关文件`

Un buen objetivo suele incluir tres cosas:

Un estado final claro.
Un método de validación ejecutable.
Límites que deben respetarse.

Si el objetivo es grande, conviene añadir una condición de parada:

`1`	`/goal 修复 eslint 报错，npm run lint 退出码为 0；如果超过 20 轮仍未完成，停止并总结剩余问题`

Esto importa. Cuanto más potente sea /goal, más necesita límites. Si no, el Agent puede modificar demasiados archivos, ejecutarse durante demasiado tiempo, consumir demasiados tokens o seguir adelante con una cuestión que debería haberse detenido para pedir criterio humano.

Cuándo conviene usar `/goal`

Encaja bien con:

Corrección de pruebas: hasta que pasen pruebas específicas.
Migraciones de código: hasta que todos los puntos de llamada estén actualizados y la compilación funcione.
Limpieza por lotes: hasta eliminar una clase de errores de lint o tipos.
Documentación: hasta que todos los módulos especificados tengan explicación.
Gestión de issues: hasta que todos los issues bajo una etiqueta estén tratados o clasificados con claridad.

No encaja bien con:

Requisitos que todavía no están claros.
Tareas que requieren juicio de producto frecuente.
Eliminaciones de alto riesgo, migraciones de datos o cambios de permisos.
Criterios de aceptación puramente subjetivos.
Tareas que cruzan muchos módulos no relacionados.

Una regla práctica: si puedes escribir “qué comando ejecutar, qué resultado esperar y qué archivos no se deben tocar”, es buen candidato para /goal. Si solo puedes escribir “hazlo mejor”, sigue siendo más seguro usar conversación normal, plan mode o revisión humana.

Qué significa esto para las herramientas de programación con IA

/goal apunta a una dirección clara: las herramientas de programación con IA están pasando de asistentes interactivos a unidades de trabajo que pueden ejecutarse de forma continua.

Antes, usar un Agent solía implicar quedarse cerca. Si se atascaba, lo guiabas. Si terminaba las pruebas, le decías que continuara. Si aparecía un error, dabas otra orden. /goal comprime esa interacción en una condición de finalización y deja que el Agent decida qué debe hacer el siguiente turno.

Pero esto también sube el listón para los usuarios. Escribir prompts ya no consiste solo en describir una tarea; también implica definir criterios de aceptación, comandos de validación, límites de modificación y reglas de parada. Dicho de otro modo, el trabajo del usuario pasa de “pedirle que continúe” a “definir qué significa terminado”.

Que Codex y Claude Code hayan llegado a /goal muestra que los Agents de tareas largas ya no pertenecen solo a tareas en segundo plano o colas en la nube. Las herramientas locales de programación en terminal también empiezan a necesitar una capacidad más fuerte de avance autónomo.

Resumen

Codex CLI y Claude Code tienen /goal, pero por ahora no conviene tratarlos como la misma función.

El /goal de Codex sigue siendo experimental, requiere features.goals y encaja mejor como una forma de mantener un objetivo de largo plazo en el hilo actual de Codex. El /goal de Claude Code conecta de forma más explícita las condiciones de finalización con la continuación automática, usando un evaluator independiente para decidir si debe seguir.

Para el desarrollo diario, este tipo de comando funciona mejor en tareas de ingeniería con criterios de aceptación claros. No reemplaza el juicio de producto ni la revisión de código, pero puede reducir mucho el ciclo repetitivo de “continúa”, “ejecútalo otra vez” y “corrige hasta que pasen las pruebas”.

La habilidad importante no es memorizar el comando, sino aprender a escribir tareas como objetivos claros, verificables y detenibles.

Referencias

OpenAI Codex CLI Slash Commands: https://developers.openai.com/codex/cli/slash-commands
Documentación de Claude Code Goal: https://code.claude.com/docs/en/goal

Por qué DeepSeek se volvió la clave para ahorrar en esta ola de herramientas de AI Coding

Mon, 11 May 2026 04:59:00 +0800

En esta ola de herramientas de AI Coding, la competencia parece girar en torno a capacidad del modelo, ecosistema de plugins y automatización con agentes. Pero cuando se usan de verdad, el primer muro que aparece es el coste.

Claude Code, Codex, OpenClaw y Superpowers son herramientas muy útiles, pero comparten una característica: cuando una tarea se vuelve compleja, consumen muchísimos tokens. Tienen que leer el proyecto, crear planes, llamar herramientas, resumir contexto, revisar resultados una y otra vez, e incluso lanzar subtareas. Cuanto más inteligente es el modelo y más automatizado es el workflow, más fácil es que la factura crezca en silencio.

Por eso DeepSeek se volvió importante en esta ronda. No solo porque pueda escribir código, sino porque su contexto largo y su coste de caché atacan justo la parte más cara de las herramientas de AI Coding.

Por qué las herramientas agent consumen tantos tokens

Los asistentes de programación tradicionales en modo chat suelen funcionar con preguntas y respuestas. Preguntas cómo escribir una función y el modelo responde con un fragmento de código. Ese modo también consume tokens, pero sigue siendo relativamente controlable.

Las herramientas agent son distintas. No solo responden preguntas, sino que entran al proyecto como un ingeniero temporal:

escanean directorios y archivos clave;
entienden el requisito y la arquitectura existente;
crean un plan;
modifican archivos;
ejecutan comandos o tests;
siguen corrigiendo según los errores;
resumen al final qué cambió.

Durante este proceso, el modelo lee repetidamente el mismo contexto. Descripciones del proyecto, fragmentos de código, resultados de herramientas, historial de conversación, planes y logs de error vuelven una y otra vez al contexto. Cuando la tarea es un poco compleja, cientos de miles de tokens desaparecen rápido.

Si además instalas plugins más agresivos, el coste se nota todavía más. Algunas extensiones de OpenCode o Claude Code pueden organizar por defecto todo un equipo de agentes. Tú solo querías cambiar una pequeña función, pero la herramienta puede iniciar planificación, revisión, ejecución y retrospectiva. La tarea parece más “inteligente”, pero los tokens suben sin parar.

La ventaja de Superpowers es activarse bajo demanda

Una ventaja de herramientas como Superpowers es que no fuerzan un flujo agent completo en todas las tareas.

Normalmente puedes seguir usando Claude Code, OpenCode o Codex de la forma habitual. Solo cuando llamas explícitamente a una skill, como brainstorming, planificación, ejecución de plan o retrospectiva, entra en un flujo de automatización más pesado.

Esto importa mucho para el coste.

AI Coding no debería usar artillería pesada para todo. Cambiar una línea de configuración, revisar un error o escribir un script pequeño se puede resolver con una conversación normal. Solo refactors complejos, cambios en varios archivos, procesamiento de documentos largos y validación por varias rondas justifican un flujo agent completo.

Cuanto más poderosa es la herramienta, más importante es controlar cuándo se activa. Si no, más automatización solo significa más desperdicio.

La ventaja clave de DeepSeek es una caché barata

Una razón importante por la que DeepSeek encaja con estas herramientas agent es su bajo coste cuando hay cache hit.

Las tareas de AI Coding tienen muchos prefijos repetidos: contexto del proyecto, prompts de sistema, instrucciones de herramientas, contenido de archivos y turnos anteriores aparecen muchas veces en solicitudes posteriores. Si el servicio del modelo soporta prompt cache, esas partes repetidas cuestan mucho menos después de un acierto de caché.

En muchos modelos, un cache hit solo es algo más barato que un miss, quizá alrededor de un tercio del precio original. La ventaja de DeepSeek es que la diferencia después de un hit puede ser mucho mayor. En workflows agent con contexto largo, muchas rondas y lectura repetida del proyecto, esa diferencia se ve directamente en la factura.

Es decir, DeepSeek no tiene por qué dar la mejor respuesta en cada turno. Pero en escenarios con tareas largas, muchas rondas y lectura repetida de contexto, su estructura de costes encaja especialmente bien con AI Coding.

El contexto largo hace más útil a Claude Code

Al conectar Claude Code o herramientas similares a DeepSeek V4, otra ventaja clara es el contexto largo.

Lo que más temen las herramientas de AI Coding es quedarse sin contexto. Cuando el contexto no alcanza, hay que comprimir con frecuencia. Cuando se comprime mucho, se pueden perder detalles ya leídos. El modelo empieza a olvidar la estructura del proyecto, las restricciones o por qué se modificó cierto archivo, y la calidad baja después.

La capacidad de contexto largo de DeepSeek V4 lo hace más adecuado para repositorios de código, procesamiento por lotes de documentos, traducción de subtítulos y limpieza de artículos de sitio. Especialmente al conectarlo a Claude Code u OpenClaw, una buena configuración puede retrasar la compresión de contexto y conservar más detalles del proyecto.

Por eso algunas tareas se sienten “resistentes” con DeepSeek: no necesariamente impresiona en cada paso, pero aguanta llamadas largas, baratas y repetidas.

Cómo repartir trabajo entre V4 Pro y V4 Flash

DeepSeek V4 Pro y V4 Flash no deberían usarse sin distinción.

Para tareas simples, DeepSeek V4 Flash suele ser mejor. Es rápido, barato y normalmente suficiente para:

traducir subtítulos;
ordenar documentos;
generar scripts comunes;
modificar pequeñas zonas de código;
ejecutar tareas ligeras en OpenClaw;
procesar contenido simple de un sitio.

Para tareas complejas, conviene considerar DeepSeek V4 Pro:

refactors de gran escala;
comprensión de código con varios módulos;
razonamiento complejo;
tareas agent de cadena larga;
cambios de código de alto riesgo;
tareas de ingeniería que requieren planificación más fuerte.

Mucha gente quiere conectar siempre el modelo más fuerte, pero eso suele ser poco rentable. La forma práctica de usar herramientas de AI Coding es dividir las tareas por capas: que el modelo barato procese mucho trabajo rutinario, y reservar el modelo caro para los puntos críticos.

MiniMax, Doubao y DeepSeek ocupan posiciones distintas

Entre modelos y planes chinos, MiniMax, Doubao, Kimi y DeepSeek tienen posiciones diferentes.

MiniMax destaca por dar mucho volumen, bajo precio y funciones amplias. Quizá no sea el modelo de programación más inteligente, pero sirve muy bien para traducción, limpieza ligera y procesamiento por lotes. Procesar subtítulos, cambiar formatos o hacer revisión simple son buenos casos para planes tipo MiniMax.

Doubao destaca por un ecosistema de herramientas más completo: imagen, video, búsqueda, TTS, posible STT y embedding pueden conectarse dentro de la misma caja. Se parece más a una caja de herramientas general.

DeepSeek tiene una posición más clara: texto, código, contexto largo y caché barata. No tiene un ecosistema completo de generación de imagen, voz y video, y sus debilidades son evidentes. Pero en AI Coding y workflows agent de texto largo, sus fortalezas son suficientemente fuertes.

No se trata de que uno sustituya a otro. Se trata de dividir la tarea y usar cada herramienta donde encaja.

Ahorrar no es solo elegir un modelo barato

Ahorrar en AI Coding no significa cambiar todas las solicitudes al modelo más barato.

Las formas realmente efectivas son:

No iniciar un agent pesado para tareas simples.
No usar Pro cuando Flash basta.
Aprovechar la caché en tareas largas.
Mantener estable el contexto repetido para no romper cache hits con cambios inútiles.
Dejar que un modelo barato haga borradores y batch processing, y usar un modelo fuerte para revisiones clave.
Decirle claramente al agent que no repita hechos ni resuma el mismo punto una y otra vez.

El último punto es especialmente importante. Las herramientas de AI tienden a ser verbosas, y la verbosidad no es solo un problema de lectura; también es un problema de coste. Incluir en el prompt “describe cada hecho una sola vez y expresa cada opinión una sola vez” puede mejorar tanto la calidad del texto como el consumo de tokens.

Para qué workflows de AI Coding encaja DeepSeek

DeepSeek encaja mejor en:

lectura de repositorios largos;
cambios ligeros en varios archivos;
limpieza de documentos por lotes;
traducción masiva de subtítulos;
limpieza de artículos Hugo;
ejecución de planes agent;
automatización barata con mucho contexto repetido.

No sirve para todo. Si necesitas gusto frontend especialmente fuerte, juicio de producto complejo o creación multimodal, quizá necesites combinarlo con Claude, GPT, Gemini, Doubao u otras herramientas.

Pero cuando la tarea es de texto largo, contexto largo, llamadas repetidas y sensibilidad al coste, DeepSeek se vuelve fácilmente la primera opción.

Resumen

En esta ola de herramientas de AI Coding, el valor de DeepSeek no es solo que un modelo chino pueda escribir código. Su valor real es resolver el dolor más práctico de las herramientas agent: las tareas largas cuestan demasiado.

Herramientas como Claude Code, OpenClaw y Superpowers automatizan cada vez más el proceso de desarrollo, pero detrás de esa automatización hay lecturas masivas de contexto y llamadas en múltiples rondas. Quien consiga bajar ese coste puede convertir AI Coding de algo “agradable de vez en cuando” en algo “usable todos los días”.

El contexto largo de DeepSeek, su bajo coste de caché y el uso por capas de V4 Flash / V4 Pro lo colocan justo en esa posición.

La verdadera clave de ahorro en esta ronda no es dejar de usar buenos modelos. Es combinar bien modelos buenos, modelos baratos, caché y workflows agent. Cuando entiendes esa factura, las herramientas de AI Coding se convierten en productividad real, no en un juguete bonito pero caro.

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

24 consejos de Claude Code: modo plan, rewind, CLAUDE.md, Skills, Agents y plugins

Fri, 08 May 2026 08:54:14 +0800

Claude Code no es solo una caja de chat. Se parece más a un Agent de programación que puede entrar en un directorio de proyecto, leer y escribir archivos, ejecutar comandos y mantener contexto.

Si solo le das un requisito y esperas código, pronto aparecen problemas: el plan no queda claro, los permisos se repiten, el contexto crece, el resultado no convence, no sabes cómo volver atrás y no hay un lugar estable para reglas del proyecto.

Estos son consejos prácticos para quienes empiezan con Claude Code.

Empieza dentro del directorio del proyecto

Claude Code funciona mejor cuando se inicia dentro del directorio del proyecto, no desde una terminal cualquiera.

Crea una carpeta de proyecto, entra en ella, abre la línea de comandos e inicia Claude Code:

claude

Si al entrar por primera vez pregunta si confías en la carpeta actual, confirma antes de seguir. Así podrá leer archivos, crear archivos y ejecutar operaciones alrededor del proyecto.

Una práctica sencilla es pedirle que cree una web personal de fotógrafo. Es una tarea visual, permite inspeccionar el resultado y sirve para practicar generación de archivos, comandos, rewind y refactorización.

Usa modo plan para aclarar la dirección

Ante tareas complejas, Claude Code puede entrar en modo plan. Su función es discutir requisitos, dividir pasos y pedir aprobación antes de ejecutar.

Tras escribir un plan, suelen aparecer opciones como:

Aprobar el plan y permitir automáticamente herramientas de edición posteriores.
Aprobar el plan, pero pedir confirmación manual para futuras ediciones.
Pausar y seguir discutiendo el plan con Claude Code.

Si la tarea está clara, aprueba y continúa. Si no, pídele que complete el plan: estilo de página, stack técnico, estructura de carpetas, interacciones y criterios de aceptación.

El modo plan reduce retrabajo. Si el Agent empieza directamente, puede crear muchos archivos rápido; si la dirección era incorrecta, luego todo se vuelve más difícil de corregir.

Cambia de modo con Shift + Tab

En Claude Code, Shift + Tab permite cambiar entre modos de trabajo. Se usa a menudo para entrar en modo plan o para cambiar a un modo de aprobación automática de edición.

Hábitos recomendados:

Proyecto nuevo, función nueva o cambio grande: primero modo plan.
Cambio pequeño o arreglo claro: ejecutar directamente.
Borrado, reemplazos masivos o instalación de dependencias: mantener confirmación humana.

En modo plan, Claude Code puede preguntar detalles del proyecto. Usa flechas para elegir opciones y Enter para confirmar. Después de enviar feedback, actualizará el plan.

No abras todos los permisos

Cuando Claude Code ejecuta comandos, edita archivos o inicia programas, puede pedir permisos.

Opciones comunes:

Permitir solo esta vez.
Permitir el mismo tipo de comando en esta sesión.
Rechazar o pausar.

Para abrir una página local, iniciar un servidor de desarrollo o revisar archivos, aprueba según necesidad. Pero no uses durante mucho tiempo un modo de “permitir todo” solo por comodidad.

La aprobación total automática solo tiene sentido en tareas de bajo riesgo, muy claras y con respaldo Git. En el uso diario, conserva confirmación humana para borrar, sobrescribir carpetas, instalar dependencias, usar red, hacer commits o ejecutar scripts.

Ejecuta comandos locales en modo terminal

Claude Code puede entrar en modo de comandos de terminal y ejecutar comandos locales.

Por ejemplo, después de generar una página, puedes abrir un archivo HTML con:

`1`	`start index.html`

start es un comando de Windows para abrir archivos. Es más rápido que buscar el archivo manualmente.

El modo terminal sirve para:

Abrir páginas generadas.
Ver contenido de directorios.
Iniciar servidores locales.
Ejecutar pruebas o builds.

Pero los comandos de alto riesgo siguen requiriendo cuidado: borrado recursivo, mover directorios, sobrescrituras masivas y cambios de entorno.

Usa rewind cuando el resultado se desvía

Si la página o el código que hizo Claude Code no es lo que quieres y cada corrección lo empeora, usa rewind temprano.

Rewind puede devolver conversación o código a un punto anterior. Opciones comunes:

Revertir código y conversación.
Revertir solo conversación.
Revertir solo código.
Comprimir contenido anterior como resumen.
Cancelar.

Cuando la dirección se desvió claramente, conviene volver código y conversación juntos. Así contexto y archivos regresan a un estado más limpio.

Ten en cuenta que el rewind de Claude Code normalmente cubre archivos creados o modificados con herramientas internas. Archivos creados por comandos externos quizá no se reviertan por completo. Para proyectos importantes, usa Git.

Escribe prompts largos en un editor

No metas requisitos complejos en una sola línea.

Si el sistema permite editar un prompt largo en un editor, úsalo, guarda y luego envíalo a Claude Code.

Un prompt largo debería aclarar:

Objetivo.
Stack técnico.
Qué no debe hacerse.
Qué archivos deben conservarse.
Cómo verificar el resultado.
Criterios de aceptación.

Por ejemplo, si quieres refactorizar una página HTML a un stack más moderno, no escribas solo “refactoriza”. Explica estructura por componentes, preservación visual, diseño responsive y pide ejecutar una comprobación de build.

Recupera sesiones después de salir

Si necesitas salir de Claude Code, hazlo normalmente. Luego vuelve al mismo directorio y arranca otra vez:

claude

Si el historial anterior no aparece, usa comandos de historial para ver sesiones recientes y cargar la sesión anterior.

Esto sirve para continuar trabajo interrumpido. Pero no uses el historial como única memoria. Reglas del proyecto, stack, comandos comunes y notas deben estar en archivos del proyecto.

Guarda reglas del proyecto en CLAUDE.md

CLAUDE.md es un archivo de memoria importante para Claude Code. Normalmente está en la raíz del proyecto y registra reglas, stack, estructura de carpetas y restricciones de colaboración.

Puedes inicializarlo con:

/init

CLAUDE.md sirve para registrar:

Objetivos del proyecto.
Stack técnico.
Comandos de inicio, prueba y build.
Estructura de directorios.
Estilo de código.
Acciones prohibidas.
Reglas de commit y despliegue.

En cada conversación, Claude Code puede usar estas reglas como parte del contexto. Piensa en él como un manual del proyecto.

Una prueba sencilla es añadir una regla evidente en CLAUDE.md y luego preguntar algo. Si la respuesta sigue la regla, leyó la memoria del proyecto.

Usa @ para referenciar archivos

En el cuadro de entrada, @ permite seleccionar archivos o Agents y añadirlos al contexto actual.

Sirve para:

Hacer que Claude Code lea un archivo de configuración.
Pedir cambios en una página concreta.
Continuar según CLAUDE.md u otro documento.
Decir explícitamente “mira solo este archivo, no adivines la estructura”.

Comparado con pegar el contenido del archivo, @ es más claro y menos propenso a omisiones.

Revisa y comprime contexto

Tras una conversación larga, el contexto crece. Si se vuelve demasiado largo, el modelo puede ralentizarse o ignorar detalles antiguos.

Usa:

`1`	`/context`

Si el contexto ya es largo, comprime el historial:

`1`	`/compact`

Si aun así el efecto es malo, limpia el contexto actual:

/clear

Después de limpiar, Claude Code todavía puede entender parte del proyecto mediante archivos, CLAUDE.md y el directorio actual, pero no conserva todo el historial de conversación.

Una regla útil: abre una conversación nueva al terminar una tarea, escribe reglas del proyecto en CLAUDE.md, y no acumules discusión temporal para siempre en un solo chat.

Skills: convierte flujos fijos en instrucciones

Skills son instrucciones reutilizables para Claude Code. No son prompts de una sola vez, sino flujos de tarea empaquetados.

Por ejemplo, si generas informes semanales a menudo, crea una Skill de informe semanal con:

Información de entrada necesaria.
Formato de salida.
Tono y estructura.
Qué debe conservarse.
Qué no debe inventarse.

Las Skills suelen contener name, description e instrucciones detalladas. Al instalarlas en el directorio global de Skills, Claude Code puede reconocerlas y cargarlas cuando la tarea encaja.

Candidatos adecuados:

Informes semanales.
Plantillas de revisión de código.
Organización de documentos.
Procesamiento de imágenes por lotes.
Artículos con formato fijo.
Flujos de inicialización de proyectos.

Si copias el mismo prompt muchas veces, conviértelo en Skill.

Agents: delega subtareas a asistentes independientes

Agents no son lo mismo que Skills.

Una Skill es un manual de instrucciones. Un Agent se parece más a un asistente independiente que trabaja fuera de la conversación principal y devuelve resultados.

Su valor está en aislar contexto. Para una revisión de código, puedes crear un Agent de solo lectura que lea el proyecto y entregue un informe sin modificar archivos. Así no contamina la conversación principal y reduce riesgos.

Al crear un Agent, considera:

Si será de proyecto o de usuario.
Si Claude Code debe generar la configuración.
Qué herramientas puede usar.
Qué modelo usará.
Si guardará memoria.
Si el prompt del Agent es claro.

Para Agents de auditoría de código, da solo permisos de lectura. Primero que entregue un informe; luego la conversación principal decide si cambia código.

Plugins: empaqueta Skills, Agents, MCP y Hooks

Los plugins son paquetes de capacidad más completos. Pueden incluir:

Skills
Agents
MCP
Hooks

Frente a una Skill aislada, un plugin sirve mejor para capacidades de conjunto. Un plugin de diseño frontend puede empaquetar estética de página, reglas de layout, hábitos de componentes y Agents relacionados.

Al instalar plugins, suele haber opciones:

Directorio de usuario, efectivo para todos los proyectos.
Directorio de proyecto, compartido con el proyecto.
Directorio local del proyecto, solo efectivo en tu ordenador.

Para capacidades personales frecuentes, usa el directorio de usuario. Para acuerdos de equipo, usa el proyecto. Para pruebas temporales, usa instalación local.

Los plugins mejoran tareas concretas

En generación de páginas frontend, un plugin suele ser más estable que un prompt desnudo.

Por ejemplo, para “crear una web personal de fotógrafo”, un prompt normal puede crear una página aceptable. Si usas explícitamente un plugin de diseño frontend, la estructura, jerarquía visual, espaciado, color y acabado suelen mejorar.

Esto no reemplaza el criterio humano. Lo razonable es dejar que el plugin genere un primer borrador mejor y luego ajustar detalles manualmente.

Un flujo de trabajo más estable

Combinando todo lo anterior, queda un flujo más estable:

Inicia claude dentro del directorio del proyecto.
Discute requisitos primero en modo plan.
Confirma stack y criterios de aceptación antes de aprobar.
Mantén confirmación manual para acciones de alto riesgo.
Usa modo terminal para previsualización y pruebas.
Usa rewind cuando el resultado se desvíe.
Escribe reglas en CLAUDE.md.
Revisa y comprime contexto en conversaciones largas.
Convierte flujos repetidos en Skills.
Delega inspección, investigación y análisis a Agents de solo lectura.
Usa plugins para tareas de dominio específico.
Mantén puntos de commit Git en proyectos importantes.

Así Claude Code será mucho más estable que enviar una frase y esperar generación.

Resumen

La eficiencia de Claude Code no viene solo del modelo, sino también del control del flujo.

El modo plan define la dirección, los permisos controlan el riesgo, rewind reduce retrabajo, CLAUDE.md guarda reglas del proyecto, /context, /compact y /clear gestionan contexto, Skills reutilizan flujos, Agents aíslan subtareas y plugins empaquetan capacidades completas.

La mejor forma de usar Claude Code es dejar que avance dentro de límites claros, no entregarle todo el proyecto de una vez.

opencode, Claude Code y Codex: diferencias y guía de herramientas open source de programación con IA

Fri, 08 May 2026 08:33:37 +0800

opencode es un AI Coding Agent open source de anomalyco. Su posicionamiento es directo: dar a los desarrolladores un asistente de código programable, extensible y capaz de conectarse a varios proveedores de modelos dentro de la terminal.

Si lo comparamos con Claude Code y Codex, los tres resuelven una misma clase de problema: llevar la IA a bases de código reales para entender contexto, modificar archivos, ejecutar comandos y correr pruebas. Pero su orientación de producto es distinta.

opencode pone más énfasis en open source, soporte de múltiples modelos y TUI de terminal. Claude Code enfatiza el ecosistema de modelos de Anthropic y la colaboración de ingeniería local. Codex es el AI coding agent de OpenAI, disponible desde la terminal, IDEs, Codex app y tareas en la nube.

Para quién es opencode

opencode encaja mejor con estos tipos de desarrolladores:

Quienes quieren completar cambios de código, análisis de proyectos y tareas de ingeniería desde la terminal.
Quienes no quieren que su AI Coding Agent dependa de un único proveedor de modelos.
Quienes prefieren herramientas open source y quieren auditarlas, ampliarlas o construir sobre ellas.
Quienes ya están cómodos con Neovim, TUI y flujos de línea de comandos.
Quienes quieren controlar en el futuro el mismo agente de programación desde una app de escritorio, móvil u otros clientes.

Su objetivo no es crear otra ventana de chat, sino poner capacidades de programación con IA dentro de la terminal y los directorios de proyecto que los desarrolladores ya usan.

Instalación

El README oficial ofrece varias formas de instalación.

# Instalación directa
curl -fsSL https://opencode.ai/install | bash

# npm
npm i -g opencode-ai@latest

# Windows
scoop install opencode
choco install opencode

# macOS y Linux
brew install anomalyco/tap/opencode
brew install opencode

# Arch Linux
sudo pacman -S opencode
paru -S opencode-bin

# Otros métodos
mise use -g opencode
nix run nixpkgs#opencode

El README oficial también recomienda eliminar versiones anteriores a 0.1.x antes de instalar, para evitar problemas causados por restos de versiones antiguas.

El script de instalación elige el directorio de instalación con esta prioridad:

$OPENCODE_INSTALL_DIR
$XDG_BIN_DIR
$HOME/bin
$HOME/.opencode/bin

Si necesitas especificar una ruta, puedes usar:

1
2

OPENCODE_INSTALL_DIR=/usr/local/bin curl -fsSL https://opencode.ai/install | bash
XDG_BIN_DIR=$HOME/.local/bin curl -fsSL https://opencode.ai/install | bash

La app de escritorio sigue en Beta

Además de la herramienta de línea de comandos, opencode también ofrece una app de escritorio, actualmente marcada como Beta. Se puede descargar desde GitHub Releases o opencode.ai/download.

La versión de escritorio cubre estas plataformas:

Plataforma	Archivo
macOS Apple Silicon	`opencode-desktop-mac-arm64.dmg`
macOS Intel	`opencode-desktop-mac-x64.dmg`
Windows	`opencode-desktop-windows-x64.exe`
Linux	`.deb`, `.rpm` o `.AppImage`

En macOS y Windows también se puede instalar la app de escritorio con gestores de paquetes.

# macOS
brew install --cask opencode-desktop

# Windows
scoop bucket add extras
scoop install extras/opencode-desktop

Dos modos Agent integrados

opencode incluye dos Agent integrados, que se pueden cambiar con la tecla Tab.

build es el modo predeterminado. Tiene permisos completos de desarrollo y sirve para editar código directamente, ejecutar comandos y avanzar en tareas de ingeniería.

plan es el modo de solo lectura. Es más adecuado para analizar bases de código desconocidas, entender la estructura del proyecto y preparar un plan de cambios. Por defecto rechaza ediciones de archivos y pregunta antes de ejecutar comandos bash.

Además, opencode incluye un sub-Agent general para búsquedas complejas y tareas de varios pasos. Los usuarios pueden invocarlo escribiendo @general en un mensaje.

Este diseño es bastante práctico: antes de actuar, usa plan para entender el proyecto; cuando haga falta cambiar código, cambia a build. En repositorios grandes, separar permisos de lectura y escritura ayuda a reducir errores.

Qué es Codex

Codex es el AI coding agent de OpenAI para ayudar a desarrolladores a escribir código, revisar código, corregir bugs y entregar tareas de ingeniería.

A diferencia de una herramienta simple de autocompletado, Codex se parece más a un Agent capaz de operar sobre una base de código. Puede trabajar contigo en herramientas locales y también puede recibir tareas delegadas para ejecutarlas en la nube. Los materiales oficiales de OpenAI describen Codex como disponible desde varias superficies, incluyendo CLI, IDEs, Codex app y flujos en la nube de ChatGPT/Codex.

Para desarrolladores, Codex tiene varios puntos importantes:

Puede leer bases de código, editar archivos, ejecutar comandos y correr pruebas.
Soporta varias interfaces, incluyendo terminal, IDE, app y nube.
Encaja con corrección de bugs, desarrollo de funciones, refactorización, migraciones, revisión de código y generación de pruebas.
Está más ligado a cuentas, modelos y ecosistema de producto de OpenAI.
Las tareas en la nube sirven para ejecutar en paralelo varias tareas de ingeniería relativamente bien definidas.

Si opencode se parece más a un framework abierto de agente en terminal, Codex se parece más a un banco de trabajo completo de programación con IA ofrecido por OpenAI: colaboración local, delegación en la nube y flujos de ingeniería más largos para equipos.

Diferencias principales

opencode, Claude Code y Codex son herramientas de programación con IA, pero la elección se entiende mejor mirando estas dimensiones.

Herramienta	Posicionamiento central	Ventajas principales	Mejor para
`opencode`	AI Coding Agent open source	Open source, múltiples modelos, TUI, arquitectura cliente/servidor	Desarrolladores que quieren una cadena de herramientas abierta, modelos reemplazables y un flujo centrado en terminal
`Claude Code`	Herramienta de programación de línea de comandos de Anthropic	Experiencia con modelos Claude, comprensión de código, contexto largo, colaboración en tareas de ingeniería	Desarrolladores que ya usan el ecosistema Claude/Anthropic y quieren avanzar tareas de código locales
`Codex`	AI coding agent de OpenAI	CLI, IDE, Codex app, tareas en la nube, flujos multi-Agent	Equipos que ya usan ChatGPT/OpenAI y quieren combinar colaboración local con delegación en la nube

En resumen, las palabras clave de opencode son “apertura y reemplazabilidad”; las de Claude Code son “ecosistema Claude y agente local de ingeniería”; y las de Codex son “ecosistema OpenAI y colaboración desde múltiples entradas”.

Diferencias con Claude Code

El FAQ oficial de opencode lo compara directamente con Claude Code. Ambos son muy parecidos en capacidad, pero las diferencias principales son estas.

Primero, opencode es un proyecto 100% open source, alojado en GitHub y publicado con MIT license.

Segundo, opencode no depende de un único proveedor de modelos. Recomienda los modelos ofrecidos a través de OpenCode Zen, pero también puede trabajar con Claude, OpenAI, Google o modelos locales. Para desarrolladores, esto significa que cuando cambien el costo, la capacidad o la disponibilidad de los modelos, no quedarán atados a una sola plataforma.

Tercero, opencode incluye soporte LSP opcional. Para autocompletado, navegación, diagnósticos y comprensión del proyecto, LSP es una base muy importante.

Cuarto, opencode pone más énfasis en TUI. Está creado por usuarios de Neovim y los creadores de terminal.shop, así que el foco del producto está claramente en la experiencia de terminal.

Quinto, opencode usa una arquitectura cliente/servidor. Esto significa que opencode puede ejecutarse en tu computadora y, en el futuro, controlarse desde una TUI, una app de escritorio, una app móvil u otros clientes. La TUI es solo una de las posibles interfaces.

Cuándo elegir opencode, Claude Code o Codex

Si ya usas Claude Code o Codex, opencode no tiene por qué reemplazarlos de inmediato. Una forma más razonable de verlo es que ofrece una opción abierta, con modelos reemplazables y orientada a la terminal.

Conviene considerar primero opencode cuando:

Quieres que tu herramienta de programación con IA sea lo más open source posible.
No quieres atar tu flujo de trabajo a un proveedor de modelos.
Quieres probar Claude, OpenAI, Google o modelos locales con la misma herramienta.
Te gustan los flujos TUI y no quieres que una app de escritorio o web interrumpa tu flujo principal.
Te interesa el potencial de control remoto de una arquitectura cliente/servidor.

Conviene considerar primero Claude Code cuando:

Usas principalmente modelos Claude.
Te importan el contexto largo, la comprensión de código y la colaboración en tareas de ingeniería complejas.
Quieres avanzar cambios, pruebas y refactorizaciones dentro de un repositorio local.
Confías más en la experiencia predeterminada de Claude Code diseñada por Anthropic.

Conviene considerar primero Codex cuando:

Ya usas ChatGPT o el ecosistema de cuentas de OpenAI.
Quieres un mismo coding agent en terminal, IDE, app de escritorio y tareas en la nube.
Quieres delegar en la nube correcciones de bugs, desarrollo de funciones, migraciones o generación de pruebas relativamente claras, en paralelo.
Necesitas revisión de código, tareas en segundo plano, colaboración de equipo y flujos multi-Agent.

Si priorizas una experiencia oficial de extremo a extremo, configuración predeterminada de modelos, administración empresarial e integraciones listas, Claude Code o Codex pueden ser más cómodos. Si priorizas control, apertura y enfoque provider-agnostic, opencode merece atención.

Puntos a tener en cuenta

opencode, Claude Code y Codex avanzan rápido. Los releases de GitHub, comandos de instalación, nombres de archivos de escritorio, disponibilidad de modelos y permisos de planes pueden cambiar. Antes de instalar o elegir, conviene revisar directamente el README, la documentación y las páginas de releases oficiales de cada herramienta.

Además, la app de escritorio de opencode sigue marcada como Beta, así que no conviene tratarla por defecto como una herramienta estable de producción. Para tareas de ingeniería diarias, la versión de terminal sigue siendo la entrada principal.

Visto como tendencia de herramientas, opencode representa la dirección de cadena de herramientas abierta para AI Coding Agents: modelos reemplazables, clientes reemplazables y una capacidad central de agente lo más abierta posible. Codex y Claude Code se parecen más a modelos convertidos por sus empresas en superficies de producto completas para coding agents. Para desarrolladores, ambas rutas probablemente coexistirán durante mucho tiempo.

Referencias

opencode GitHub: https://github.com/anomalyco/opencode
sitio oficial de opencode: https://opencode.ai
documentación de opencode: https://opencode.ai/docs
opencode Releases: https://github.com/anomalyco/opencode/releases
OpenAI Codex: https://openai.com/codex/
Using Codex with your ChatGPT plan: https://help.openai.com/en/articles/11369540-codex-in-chatgpt
OpenAI Codex CLI Getting Started: https://help.openai.com/en/articles/11096431-openai-codex-ci-getting-started

Warp Open Source: de terminal a entorno de desarrollo agentico

Thu, 07 May 2026 20:15:08 +0800

warpdotdev/warp es el repositorio open source del cliente de Warp. Warp se describe ahora como un “entorno de desarrollo agentico, nacido del terminal”: parte del terminal, pero lleva agentes de programacion con IA, indexacion de codebase, gestion de tareas y flujos de desarrollo a un solo entorno.

No es un repositorio open source ordinario de emulador de terminal. Se parece mas a una respuesta a una pregunta mayor: cuando agentes como Claude Code, Codex y Gemini CLI se vuelven comunes, deberia el propio terminal convertirse en un entorno de desarrollo para planificar, observar y gestionar agentes?

La respuesta de Warp es si.

Estado actual del repositorio

Al 7 de mayo de 2026, warpdotdev/warp es un repositorio publico. GitHub muestra alrededor de 56k stars y 4.1k forks. El README dice que el codigo del cliente Warp ahora es open source y da la bienvenida a contribuciones de la comunidad.

El lenguaje principal es Rust. El desglose de lenguajes de GitHub muestra Rust por encima del 98%, lo que encaja con el posicionamiento de Warp: no es un wrapper web, sino una herramienta de desarrollo nativa y multiplataforma.

Varios detalles del README importan:

Warp es un entorno de desarrollo agentico, nacido del terminal.
Puede usar su agente de programacion integrado y tambien conectar con agentes CLI externos como Claude Code, Codex y Gemini CLI.
OpenAI es el patrocinador fundador del repositorio Warp recien abierto.
Los flujos de gestion agentica del repositorio estan impulsados por modelos GPT.
Los crates del framework de UI de Warp usan licencia MIT, mientras que el resto del codigo usa AGPL v3.

Esto muestra que el movimiento open source de Warp no consiste solo en publicar un terminal. Esta operando el proyecto como un campo de pruebas para flujos de trabajo con agentes.

Warp es mas que un terminal

Los terminales tradicionales hacen principalmente tres cosas:

iniciar una shell;
ejecutar comandos;
mostrar salida.

La diferenciacion inicial de Warp era hacer que el terminal se sintiera mas moderno: bloques de comandos, autocompletado, historial, colaboracion, interacciones con estilo de UI y pulido multiplataforma. Ahora el foco se ha desplazado mas hacia organizar el desarrollo alrededor de agentes de IA.

Segun el README, Warp ya no enfatiza solo “un mejor terminal”. Enfatiza:

agentes de programacion integrados;
soporte para agentes CLI externos;
triage de issues;
escritura de especificaciones;
revision de PR;
coordinacion de contribuidores;
sesiones de agentes observables.

En otras palabras, Warp quiere convertir el terminal de “donde escribes comandos” en “donde trabajas con multiples agentes”.

Oz y gestion de proyectos open source

El README menciona Oz varias veces.

La vista de contribucion de Warp muestra miles de agentes Oz trabajando en triage de issues, especificaciones, implementacion y revision de PR. Esto es interesante porque extiende los agentes de IA desde “ayudar a una persona a escribir codigo” hasta “ayudar a gestionar colaboracion open source”.

La parte mas dificil de muchos proyectos open source no es escribir codigo, sino mantener:

demasiados issues y poca clasificacion;
bugs y feature requests mezclados;
nuevos contribuidores sin saber que tareas son abordables;
presion de revision de PR;
maintainers intentando seguir cada hilo de comunidad.

La idea de Warp es dejar que los agentes asuman primero parte del trabajo de gestion de proyecto y colaboracion. El README tambien menciona Oz for OSS, un programa orientado a maintainers para llevar flujos similares de gestion open source agentica a otros repositorios.

Esto sugiere que la ambicion de Warp no es solo el producto terminal, sino tambien un nuevo modelo de mantenimiento open source en la era de la IA.

Estructura del repositorio y stack tecnico

Por la estructura del repositorio, Warp es un proyecto Rust grande.

La raiz contiene:

app/: codigo principal de la aplicacion.
crates/: crates Rust centrales.
assets/: archivos de recursos.
command-signatures-v2/: contenido relacionado con firmas de comandos.
docker/, script/, resources/, specs/ y otros directorios de ingenieria.
.claude/, .warp/, .agents/skills y otras configuraciones relacionadas con agentes.

WARP.md aporta mas detalle de ingenieria. Describe Warp como un emulador de terminal basado en Rust que usa un framework de UI interno llamado WarpUI.

Los modulos principales pueden entenderse aproximadamente asi:

app/: emulacion de terminal, gestion de shell, integracion de IA, Drive, autenticacion, ajustes, workspace y sesiones.
crates/warp_core/: utilidades centrales y abstraccion de plataforma.
crates/editor/: funcionalidad de edicion de texto.
crates/warpui/ y crates/warpui_core/: framework de UI interno.
crates/ipc/: comunicacion entre procesos.
crates/graphql/: cliente GraphQL y esquema.

WARP.md tambien menciona rasgos arquitectonicos como:

un sistema Entity-Handle;
una estructura modular de workspace;
targets para macOS, Windows, Linux y WASM;
integracion de IA, incluyendo Agent Mode, conciencia de contexto e indexacion de codebase;
sincronizacion cloud Warp Drive.

Esta complejidad esta mas cerca de un IDE completo que de un terminal tradicional ligero.

Comandos de build local

El README da un flujo local conciso:

1
2
3

./script/bootstrap
./script/run
./script/presubmit

Donde:

./script/bootstrap realiza la inicializacion especifica de la plataforma.
./script/run compila y ejecuta Warp.
./script/presubmit ejecuta formato, clippy, tests y otras comprobaciones previas al envio.

WARP.md tambien lista comandos mas detallados:

cargo run
cargo bundle --bin warp
cargo nextest run --no-fail-fast --workspace --exclude command-signatures-v2
cargo fmt
cargo clippy --workspace --all-targets --all-features --tests -- -D warnings

Si quieres contribuir a Warp, ./script/presubmit es practicamente obligatorio.

Flujo de contribucion

El flujo de contribucion de Warp no es simplemente “abre un PR”.

El README describe un proceso ligero desde issue hasta PR:

Buscar primero issues existentes.
Si no hay duplicado, abrir un bug o feature request.
Los maintainers revisan el issue y pueden anadir etiquetas de preparacion.
ready-to-spec significa que el diseno puede expandirse en una especificacion.
ready-to-implement significa que el diseno esta lo bastante claro para empezar un PR de implementacion.
Los contribuidores pueden tomar issues etiquetados.

Este proceso encaja con un proyecto open source grande. Separa ideas, diseno e implementacion, reduciendo el riesgo de que los contribuidores pasen tiempo construyendo en una direccion equivocada.

Tambien encaja bien con agentes de IA. Un agente puede organizar issues, redactar specs, anadir tests y luego pasar a implementacion. Warp usa este patron para demostrar gestion de proyecto agentica.

Licencia: MIT + AGPL v3

Warp usa una estructura de doble licencia.

El README dice:

el framework de UI de Warp, concretamente los crates warpui_core y warpui, usa licencia MIT;
el resto del repositorio usa AGPL v3.

Esto importa. AGPL v3 tiene requisitos open source mas fuertes para servicios de red y distribucion. Si estas aprendiendo, investigando o contribuyendo, normalmente es sencillo. Pero si quieres usar codigo de Warp en un producto comercial o en un derivado closed-source, debes leer la licencia con cuidado y consultar asesoria legal si hace falta.

En resumen, Warp es open source, pero no es open source de “tomalo y cierralo libremente”.

Por que merece atencion

Primero, Warp une terminal, agentes y gestion de proyecto.

Muchas herramientas de programacion con IA siguen siendo CLI o plugins de editor. Warp parte del punto de entrada del terminal e intenta unificar tareas de agentes, ejecucion de codigo, salida de comandos, flujos de PR y colaboracion de equipo.

Segundo, el enfoque open source de Warp es un buen lugar para observar flujos con agentes.

No solo publica codigo. Tambien expone vistas de contribucion, sesiones de agentes, triage de issues y flujos de especificacion. Para cualquiera que estudie como la IA puede participar en colaboracion open source, el propio repositorio es una muestra.

Tercero, Warp es una aplicacion de escritorio Rust compleja.

Si quieres estudiar GUI en Rust, emulacion de terminal, apps multiplataforma, clientes GraphQL, sincronizacion cloud e integracion de IA, el repositorio tiene mucho que leer. Pero no es un proyecto pequeno, asi que los nuevos contribuidores deberian leer primero la documentacion y el proceso de issues.

Cuarto, Warp soporta tanto un agente integrado como un enfoque “trae tu propio agente CLI”.

Esto es realista. Los desarrolladores no usaran un solo agente. Claude Code, Codex, Gemini CLI, OpenCode, OpenClaw y herramientas similares probablemente coexistiran. Si Warp puede convertirse en un banco de trabajo para ellos, se vuelve mas valioso que un terminal de proposito unico.

A quien deberia importarle

Si eres un usuario normal de terminal, Warp importa porque el terminal puede estar cambiando de herramienta de linea de comandos a banco de trabajo con IA.

Si eres usuario intensivo de agentes de programacion con IA, Warp merece seguimiento porque intenta gestionar multiples agentes en vez de actuar como otro punto de entrada de chat.

Si mantienes proyectos open source, la direccion de Oz for OSS merece atencion. Explora triage de issues con agentes, revision de PR, colaboracion comunitaria e incorporacion de contribuidores.

Si eres desarrollador Rust, Warp es una aplicacion de escritorio real y de gran escala que merece estudiarse por organizacion de UI, internals de terminal, sincronizacion cloud, integracion de IA y codigo multiplataforma.

Si solo quieres un terminal que pueda reemplazar al actual de inmediato, es mejor descargar primero la version estable y despues decidir si estudiar el codigo fuente. Compilar desde codigo es mas adecuado para contribuidores y usuarios profundos.

Lectura breve

El punto de que Warp se vuelva open source no es simplemente “un terminal moderno se hizo open source”.

Mas precisamente, Warp intenta actualizar el terminal hasta convertirlo en un entorno de desarrollo agentico: el terminal conecta shell, codebase, ejecucion de comandos, agentes, issues, PRs y flujo de colaboracion.

A medida que los agentes de programacion con IA sigan creciendo, el punto de entrada del entorno de desarrollo puede cambiar. Antes, el IDE dominaba la experiencia del desarrollador mientras el terminal ejecutaba comandos. Ahora el terminal puede convertirse en el centro de colaboracion con agentes. El repositorio de Warp explora esa posibilidad.

Enlaces relacionados

GitHub repository: https://github.com/warpdotdev/warp
Warp website: https://www.warp.dev
Warp documentation: https://docs.warp.dev
Warp build overview: https://build.warp.dev
WARP.md: https://github.com/warpdotdev/warp/blob/master/WARP.md
CONTRIBUTING.md: https://github.com/warpdotdev/warp/blob/master/CONTRIBUTING.md

Hermes + Qwen3.6: una solucion barata para desplegar un Agent local

Mon, 04 May 2026 06:40:30 +0800

La idea es ejecutar el modelo Qwen3.6 GGUF con llama.cpp dentro de WSL2 y conectar Hermes Agent a una API local compatible con OpenAI. Asi puedes tener un asistente de IA local siempre disponible en tu propio ordenador, sin depender de cuotas de tokens de servicios online.

Esta solucion encaja con usuarios que quieren probar un AI Agent local y, al mismo tiempo, conservar privacidad de datos y control a largo plazo. Puede servir para preguntas diarias, escritura, ayuda con codigo, organizacion de informacion y automatizacion simple. Hay que tener en cuenta que cuanto mayor sea el modelo, mas VRAM necesitara; el ejemplo original usa Qwen3.6-27B y va mas estable con 24GB de VRAM. Si tienes menos VRAM, conviene elegir un modelo mas pequeno o una cuantizacion mas baja.

Estructura de la solucion

La cadena completa es sencilla:

Instalar WSL2 y Ubuntu 24.04 en Windows.
Instalar CUDA Toolkit y compilar llama.cpp dentro de WSL2.
Descargar el modelo Qwen3.6 GGUF.
Iniciar el servicio local con llama-server.
Instalar Hermes Agent y configurarlo hacia http://localhost:8080/v1.
Opcional: escribir un script de inicio para arrancar el servicio del modelo al abrir WSL2.

Hermes aporta la capacidad de Agent, y Qwen3.6 aporta el LLM local. Combinados, convierten el ordenador en un asistente de IA local y privado.

Instalar WSL2 y Ubuntu

En una ventana de Windows PowerShell como administrador:

1
2

wsl --install
wsl --set-default-version 2

Despues de reiniciar, instala Ubuntu 24.04:

`1`	`wsl --install -d Ubuntu-24.04`

Al terminar, Ubuntu pedira usuario y contrasena. Ya dentro de Ubuntu, comprueba primero si la GPU NVIDIA se reconoce correctamente en WSL2:

`1`	`nvidia-smi`

Si no se reconoce la GPU, normalmente hay que actualizar primero el driver NVIDIA en Windows. WSL2 hereda el driver de Windows, pero CUDA Toolkit debe instalarse por separado dentro de WSL2.

Instalar Python y herramientas basicas

`1`	`sudo apt update && sudo apt install -y python3-pip python3-venv`

Tambien hacen falta herramientas de compilacion, Git y CMake:

`1`	`sudo apt install -y cmake build-essential git`

Compilar llama.cpp

Clona primero el codigo:

1
2

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp

Si WSL2 ya tiene un entorno CUDA utilizable, compila directamente:

1
2

cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89
cmake --build build -j$(nproc)

CMAKE_CUDA_ARCHITECTURES=89 es adecuado para GPU Ada, por ejemplo la serie RTX 40. En otras tarjetas debes ajustarlo segun la arquitectura real.

Si al compilar aparece que falta CUDA Toolkit, instalalo primero dentro de WSL2:

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install -y cuda-toolkit-12-8

Despues configura variables de entorno:

export PATH=/usr/local/cuda-12.8/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH
echo 'export PATH=/usr/local/cuda-12.8/bin:$PATH' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc

Y compila de nuevo:

cd ~/llama.cpp
rm -rf build
cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89
cmake --build build -j$(nproc)

Descargar el modelo Qwen3.6 GGUF

El ejemplo original usa Qwen3.6-27B-UD-Q4_K_XL.gguf de unsloth/Qwen3.6-27B-GGUF:

1
2
3

hf download unsloth/Qwen3.6-27B-GGUF \
Qwen3.6-27B-UD-Q4_K_XL.gguf \
--local-dir ~/models/

El archivo ronda los 17GB. Si Hugging Face descarga lento, puedes cambiar a espejos como ModelScope. Si no tienes suficiente VRAM, no fuerces 27B; usa un modelo mas pequeno o una cuantizacion mas baja.

Iniciar el servicio local del modelo

Arranca llama-server segun el nombre real de tu archivo de modelo:

~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 32768 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--port 8080

Tras iniciar correctamente, abre en el navegador de Windows:

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

Para que Hermes Agent u otros clientes compatibles con OpenAI lo llamen, la direccion de API suele ser:

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

Elegir Thinking mode

Qwen3.6 puede activar Thinking mode por defecto. Es util para razonamiento complejo, problemas de codigo complicados y analisis de varios pasos, pero sera mas lento.

Si quieres desactivarlo, detén el servicio y agrega --chat-template-kwargs:

~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 32768 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--chat-template-kwargs '{"enable_thinking":false}' \
--port 8080

Sin Thinking, las preguntas simples, escritura, autocompletado de codigo y explicacion de codigo iran mas rapido; para algoritmos complejos, Debug dificil y analisis de arquitectura, sigue siendo recomendable activarlo.

Instalar Hermes Agent

Mantén llama-server en ejecucion y abre otra terminal WSL2 para instalar Hermes Agent:

`1`	`curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh \| bash`

El script instala dependencias como Python, Node.js, ripgrep y ffmpeg. Al configurar el endpoint del modelo, elige endpoint personalizado:

1
2
3

URL: http://localhost:8080/v1
API Key: 12345678
Model: autodetect

Para el llama-server local, la API Key puede ser cualquier valor de relleno. Tras configurarlo, puedes conectar Telegram, WeChat, QQ, Discord y otros canales para que Hermes Agent use el modelo local y ejecute tareas.

Arrancar automaticamente el servicio del modelo

Puedes escribir un script para iniciar el servicio al abrir la terminal WSL2.

Crea el script:

cat > ~/start-llm.sh << 'EOF'
#!/bin/bash
echo "Starting Qwen3.6-27B llama-server..."
~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 65536 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--port 8080 \
--host 0.0.0.0 &
echo "llama-server started, PID: $!"
echo "API: http://localhost:8080/v1"
echo "Chat UI: http://localhost:8080"
EOF
chmod +x ~/start-llm.sh

Escribe en .bashrc:

echo '# Auto-start llama-server' >> ~/.bashrc
echo 'if ! pgrep -f "llama-server" > /dev/null 2>&1; then' >> ~/.bashrc
echo '    ~/start-llm.sh' >> ~/.bashrc
echo 'fi' >> ~/.bashrc

Asi, cada vez que abras WSL2, si llama-server no esta en ejecucion se iniciara automaticamente; si ya esta corriendo, se omitira para evitar duplicados.

Notas

El modelo 27B exige bastante VRAM; 24GB va mas estable. Con menos VRAM, usa un modelo mas pequeno.
--ctx-size 65536 aumenta mucho la presion de VRAM y RAM. Si no es estable, baja primero a 32768 o menos.
CUDA Toolkit dentro de WSL2 y el driver de Windows deben estar correctos; si falta uno, la compilacion o ejecucion CUDA puede fallar.
Cuando Hermes Agent se conecta al servicio local, en esencia llama a una API compatible con OpenAI. Lo clave es que http://localhost:8080/v1 responda bien.
Si quieres acceder desde el telefono u otros dispositivos, debes configurar firewall de Windows, direccion LAN y aislamiento de seguridad. No expongas el servicio local directamente a Internet.

Enlaces relacionados

Original: Hermes + Qwen3.6：本地最强 Agent 组合！零成本、无限 Token，太香了！
llama.cpp: ggerganov/llama.cpp
Hermes Agent: NousResearch/hermes-agent
Ejemplo Qwen3.6 GGUF: unsloth/Qwen3.6-27B-GGUF

Cómo usar DeepSeek V4 Pro en Cline

Fri, 01 May 2026 20:59:06 +0800

Cline ya admite el proveedor OpenAI Compatible. La API de DeepSeek también es compatible con llamadas al estilo del SDK de OpenAI, así que conectar deepseek-v4-pro a Cline no es complicado: elige OpenAI Compatible y completa la Base URL de DeepSeek, la API Key y el nombre del modelo.

Los pasos siguientes cubren tanto la interfaz de la extensión para VS Code como Cline CLI.

Preparar una API Key de DeepSeek

Primero, crea una API Key en la plataforma de DeepSeek.

Necesitas tres valores:

Elemento	Valor
Provider	`OpenAI Compatible`
Base URL	`https://api.deepseek.com`
Model ID	`deepseek-v4-pro`

La documentación oficial de DeepSeek indica que la serie V4 usa la interfaz existente compatible con OpenAI. Mantén base_url como https://api.deepseek.com y establece model en deepseek-v4-pro o deepseek-v4-flash al llamarlo.

Configurarlo en la extensión de Cline

Si usas la extensión de Cline en VS Code, configúrala así:

Abre Cline desde la barra lateral de VS Code.
Entra en la configuración de Cline o en la configuración de modelos.
Selecciona OpenAI Compatible como proveedor.
Introduce tu API Key de DeepSeek.
Configura Base URL como:

`1`	`https://api.deepseek.com`

Configura Model ID como:

`1`	`deepseek-v4-pro`

Guarda la configuración y ejecuta una prueba sencilla en Cline.

Empieza con una tarea de solo lectura y bajo riesgo:

`1`	`Please read the current project directory structure and summarize what type of project this is. Do not modify any files.`

Si Cline puede leer y responder con normalidad, la conexión del modelo funciona.

Configurarlo en Cline CLI

Si usas Cline CLI, ejecuta cline provider configure openai-compatible para entrar en la configuración interactiva.

Ejemplo:

`1`	`cline provider configure openai-compatible`

Completa:

1
2
3

API Key: sk-...
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-pro

Después de configurarlo, prueba con una tarea de solo lectura:

`1`	`cline "Summarize this repository structure without changing files."`

Si quieres reducir el coste al principio, puedes cambiar temporalmente Model ID a:

`1`	`deepseek-v4-flash`

Luego vuelve a deepseek-v4-pro para planificación compleja, verificación de hechos, colaboración con varias herramientas o cambios de código de alto riesgo.

División de modelos recomendada

DeepSeek V4 Pro y Flash funcionan mejor con una separación clara.

Modelo	Mejor para
`deepseek-v4-flash`	Lectura rutinaria de código, pequeños arreglos por lotes, generación de scripts, resúmenes de contexto, cambios frontend de bajo riesgo
`deepseek-v4-pro`	Planificación de arquitectura, bugs complejos, refactors entre archivos, verificación de hechos, llamadas multi-herramienta, cambios de alto riesgo

En herramientas de Agent como Cline, el coste suele venir del contexto largo, lecturas repetidas de archivos, generación de planes y llamadas de herramientas en varias rondas. Si la tarea es ligera, usa Flash para volumen; si necesita mejor juicio, cambia a Pro.

Cómo configurar la longitud de contexto

DeepSeek V4 Pro y Flash admiten contexto largo. Si Cline exige un valor manual de ventana de contexto, puedes interpretarlo según el contexto de 1M indicado en la página oficial de modelos de DeepSeek.

En la práctica, no conviene meter todos los archivos en contexto desde el inicio. Cline lee archivos según la tarea, y un flujo mejor suele ser:

primero pedirle que inspeccione la estructura del directorio;
luego pedirle que localice los archivos relevantes;
finalmente dejar que modifique solo los archivos objetivo.

Esto ahorra tokens y mantiene más claro el límite de la tarea.

Problemas comunes

1. Modelo no encontrado

Primero comprueba que Model ID sea exactamente:

`1`	`deepseek-v4-pro`

No escribas DeepSeek V4 Pro, deepseek-v4 ni otro nombre mostrado.

2. 401 o fallo de autenticación

Comprueba la API Key:

si se copió completa;
si contiene espacios adicionales;
si se introdujo en la configuración de proveedor que Cline está usando;
si la cuenta de DeepSeek tiene saldo disponible.

3. Fallo de conexión

Comprueba la Base URL:

`1`	`https://api.deepseek.com`

No añadas /v1/chat/completions al final. El proveedor OpenAI Compatible de Cline construirá por sí mismo las solicitudes de la interfaz compatible.

4. Las llamadas de Cline son demasiado caras

Puedes pasar las tareas rutinarias a deepseek-v4-flash y usar deepseek-v4-pro solo para tareas complejas.

Además, haz que la descripción de la tarea sea lo más clara posible:

`1`	`Only modify files related to the login page. Do not refactor unrelated modules. First provide a plan, and modify code only after confirmation.`

Las tareas de Agent son más caras cuando los límites son poco claros. Cuanto más claro sea el límite, menos archivos leerá, menos llamadas de herramienta hará y más controlable será el coste.

5. Error: reasoning_content must be passed back

Si ves un error como este:

{
  "message": "400 The `reasoning_content` in the thinking mode must be passed back to the API.",
  "code": "invalid_request_error",
  "modelId": "deepseek-v4-pro"
}

Normalmente no es un problema de Key, cuota o Base URL. Significa que el modo de pensamiento de DeepSeek V4 Pro y el historial multi-ronda de llamadas de herramientas del cliente actual no están alineados.

La documentación oficial de DeepSeek indica:

el modo de pensamiento está enabled por defecto;
el modo de pensamiento devuelve reasoning_content;
si ocurre una llamada de herramienta en una ronda, las solicitudes posteriores deben devolver el reasoning_content de ese mensaje del asistente;
si el cliente no lo devuelve correctamente, la API devuelve 400.

Cuando Cline se conecta mediante el proveedor OpenAI Compatible, este error puede aparecer en la segunda ronda o después de llamadas de herramienta si la versión actual no conserva y reenvía por completo el reasoning_content de DeepSeek.

Prueba en este orden:

Actualiza Cline a la versión más reciente;
confirma que estás usando OpenAI Compatible, no el proveedor normal OpenAI;
si Cline admite cuerpo de solicitud personalizado, intenta desactivar el modo de pensamiento:

{
  "thinking": {
    "type": "disabled"
  }
}

si Cline no admite parámetros extra en el body, usa temporalmente otro modelo o un servicio proxy compatible;
vuelve a deepseek-v4-pro cuando Cline admita reenviar reasoning_content de DeepSeek V4.

Ten en cuenta que desactivar el modo de pensamiento puede reducir la capacidad de razonamiento complejo, pero puede esquivar problemas de compatibilidad del cliente cuando reasoning_content no se devuelve.

Configuración copiable

Provider: OpenAI Compatible
API Key: sk-your DeepSeek API Key
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-pro

Para modo de bajo coste:

Provider: OpenAI Compatible
API Key: sk-your DeepSeek API Key
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-flash

Resumen

Solo hay tres pasos clave para llamar a DeepSeek V4 Pro en Cline:

elegir OpenAI Compatible como proveedor;
establecer Base URL en https://api.deepseek.com;
establecer Model ID en deepseek-v4-pro.

Después de configurarlo, prueba con una tarea de solo lectura antes de darle cambios reales de código. Si ejecutas tareas de Agent con frecuencia, separa Flash y Pro: Flash maneja trabajo ligero y frecuente, mientras Pro se ocupa del juicio complejo y las tareas de respaldo.

Referencias:

Cómo las rebajas de DeepSeek V4 reescriben el modelo de costes de los AI Agents

Fri, 01 May 2026 19:47:47 +0800

DeepSeek V4 no llegó con un lanzamiento especialmente ruidoso. No hubo gran evento ni una historia de benchmarks que aplastara al instante a todos los competidores. Pero unos días después apareció la parte que realmente afecta a la industria: rebajas repetidas de precio.

El punto de este cambio no es que “el modelo se volvió un poco más fuerte”, sino que “el coste de uso fue empujado a otro nivel”. Cuando los precios por token bajan lo suficiente para que una tarea ordinaria de Agent termine por unos pocos centavos o un par de yuanes, la lógica de negocio detrás de muchos Coding Plans y Token Plans necesita reconsiderarse.

El día de lanzamiento no fue explosivo

La primera ola de comentarios sobre DeepSeek V4 no fue especialmente intensa. Mucha gente esperaba un impacto como el de R1: liderazgo general en benchmarks, validación del cómputo doméstico y avances simultáneos en multimodalidad y capacidades de Agent. Tras el lanzamiento real, sin embargo, se pareció más a una actualización sólida.

V4 Pro es sin duda un modelo fuerte, especialmente en programación, matemáticas, contexto largo y agentic coding. Pero no es el tipo de producto que hace que todos los modelos pares parezcan obsoletos de inmediato. Por eso, el día de lanzamiento la discusión se sintió algo incómoda: la gente quería elogiarlo, pero era difícil encontrar un ángulo lo bastante explosivo.

El verdadero punto de inflexión no fue el lanzamiento, sino los ajustes de precio que llegaron después.

Las rebajas sucesivas son la clave

Después de publicarse DeepSeek V4, los precios empezaron a moverse hacia abajo. Según la página oficial de precios de DeepSeek y la información resumida en el artículo fuente, los precios aproximados de aquel momento eran:

DeepSeek V4 Flash: alrededor de 1 yuan por 1 millón de tokens de entrada; alrededor de 0,02 yuan por 1 millón de tokens tras un cache hit;
DeepSeek V4 Pro: alrededor de 3 yuanes por 1 millón de tokens de entrada; alrededor de 0,025 yuan por 1 millón de tokens tras un cache hit;
el precio de entrada con cache hit en toda la familia de modelos cayó a una décima parte del precio de lanzamiento;
V4 Pro estuvo en un periodo de descuento del 75%, extendido hasta el 31 de mayo de 2026 a las 23:59.

Los precios de API en dólares estadounidenses muestran la diferencia con más claridad:

Modelo	Entrada cacheada	Entrada no cacheada	Salida	Contexto
`deepseek-v4-flash`	$0.0028 / 1M tokens	$0.14 / 1M tokens	$0.28 / 1M tokens	1M
`deepseek-v4-pro` precio promocional	$0.003625 / 1M tokens	$0.435 / 1M tokens	$0.87 / 1M tokens	1M
`deepseek-v4-pro` precio regular	$0.0145 / 1M tokens	$1.74 / 1M tokens	$3.48 / 1M tokens	1M

Aquí importan dos detalles.

Primero, los $0.435 / $0.87 de V4 Pro son precio promocional, no el precio regular a largo plazo. En las notas oficiales de DeepSeek, este descuento del 75% fue extendido hasta el 31 de mayo de 2026 a las 15:59 UTC.

Segundo, el precio con cache hit es la variable clave del modelo de costes de Agent. La entrada cacheada de Flash baja hasta $0.0028 / 1M tokens, mientras el precio promocional cacheado de Pro es $0.003625 / 1M tokens. Eso significa que contexto de proyecto repetido, definiciones de herramientas, system prompts y resúmenes históricos ya no necesitan cobrarse al precio completo de entrada.

Lo más importante de esta política de precios es que vuelve “insensible” el coste en tokens de muchas tareas. Antes, los desarrolladores temían que una tarea de Agent consumiera mucho contexto, leyera y escribiera código repetidamente y llamara herramientas con frecuencia. Ahora, mientras la tasa de cache hit sea lo bastante alta, el coste puede empujarse muy abajo.

Comparación de precios con GPT y Claude

Los precios de DeepSeek por sí solos no transmiten toda la brecha. El contraste se vuelve mucho más claro al ponerlos junto a modelos cerrados comunes del mismo periodo.

Modelo	Entrada	Entrada cacheada	Salida	Mejor para
`deepseek-v4-flash`	$0.14 / M	$0.0028 / M	$0.28 / M	Agents de alta frecuencia, programación rutinaria, tareas por lotes
`deepseek-v4-pro` precio promocional	$0.435 / M	$0.003625 / M	$0.87 / M	Programación compleja, planificación, verificación de hechos
`deepseek-v4-pro` precio regular	$1.74 / M	$0.0145 / M	$3.48 / M	Línea base de coste Pro tras la promoción
GPT-5.5	$5 / M	$0.50 / M	$30 / M	Tareas complejas de alta calidad, razonamiento general
GPT-5.4	$2.50 / M	$0.25 / M	$15 / M	Opción intermedia para programación y trabajo profesional
GPT-5.4 mini	$0.75 / M	$0.075 / M	$4.50 / M	Modelo general y de subtareas de menor coste
Claude Opus 4.7	$5 / M	$0.50 / M	$25 / M	Escritura de alta calidad, razonamiento complejo, tareas largas
Claude Sonnet 4.6	$3 / M	$0.30 / M	$15 / M	Programación, Agents, trabajo general
Claude Haiku 4.5	$1 / M	$0.10 / M	$5 / M	Tareas ligeras, resumen, clasificación

El número más llamativo de esta tabla es el precio de salida. Los Agents no solo leen contexto; también generan planes, parches, explicaciones, logs y siguientes acciones. Si hay mucha salida, los $0.87 / M promocionales de DeepSeek V4 Pro son drásticamente más baratos que los $30 / M de GPT-5.5 o los $15 / M de Claude Sonnet 4.6.

Incluso al precio regular de salida de V4 Pro, $3.48 / M, sigue claramente por debajo de GPT-5.4, GPT-5.5 y Claude Sonnet / Opus. Si la tarea puede manejarse con Flash, el precio de salida baja aún más hasta $0.28 / M.

La brecha de entrada cacheada es todavía más extrema. DeepSeek V4 Flash cuesta $0.0028 / M en entrada cacheada, mientras GPT-5.5 y Claude Opus 4.7 cuestan ambos $0.50 / M. No están en el mismo orden de magnitud. Para Agents que leen repetidamente el mismo repositorio de código, esta brecha importa más que en un chat normal.

Por qué las tareas de Agent se ven especialmente afectadas

Los AI Agents son distintos del chat ordinario. El chat normal suele ser un flujo de pregunta y respuesta con contexto de entrada relativamente limitado. Las tareas de Agent leen archivos de proyecto repetidamente, generan planes, llaman herramientas, inspeccionan resultados y vuelven a modificar código.

Estas tareas tienen dos rasgos:

gran consumo de tokens;
mucho contexto repetido.

El segundo punto es crucial. En un proyecto de código, el modelo lee una y otra vez los mismos archivos, estructura de directorios, logs de error y resultados de modificación. Si la plataforma admite cache hits, el coste de entrada repetida cae de forma pronunciada.

El artículo fuente mencionaba una experiencia real: conectar DeepSeek V4 Pro y Flash a una herramienta parecida a Claude Code, pedirle que descargara un repositorio de prompts y lo convirtiera en un sitio local de búsqueda. La tarea se completó con un coste total de poco más de 0,8 yuanes, y Pro alcanzó una tasa de cache hit del 98,7%.

Este ejemplo ilustra un punto práctico: cuanto más se parece una tarea de Agent a “trabajo repetido alrededor del mismo proyecto”, más valiosos se vuelven los cache hits. Si generar un sitio, arreglar un bug o cambiar un frontend cuesta solo unos centavos o unos pocos yuanes, los planes de suscripción pierden atractivo.

Podemos estimar la brecha con una tarea simplificada. Supongamos que una tarea de coding agent incluye:

500.000 tokens de entrada, de los cuales 80% pueden cachearse;
50.000 tokens de salida;
sin llamadas de herramientas, costes de búsqueda ni markup de plataforma, solo coste de tokens del modelo.

Los costes aproximados son:

Modelo	Coste estimado
DeepSeek V4 Flash	alrededor de $0.03
DeepSeek V4 Pro precio promocional	alrededor de $0.09
DeepSeek V4 Pro precio regular	alrededor de $0.36
GPT-5.4 mini	alrededor de $0.30
GPT-5.4	alrededor de $1.01
GPT-5.5	alrededor de $1.75
Claude Sonnet 4.6	alrededor de $1.11
Claude Opus 4.7	alrededor de $1.65

Esta estimación no significa que DeepSeek sea mejor para todas las tareas. Calidad del modelo, estabilidad de tool calls, capacidad de recuperación en contexto largo, estilo de código y fiabilidad factual necesitan evaluación separada. Pero desde el coste, DeepSeek V4 empuja muy abajo el coste marginal de “dejar correr al Agent unas rondas más”. Eso animará a diseñar flujos más largos, autochecks más frecuentes y más soluciones candidatas sin preocuparse por la factura de tokens cada vez.

La diferencia entre Coding Plans y Token Plans

Muchos productos de IA ofrecen ahora dos tipos de planes: Coding Plans y Token Plans.

La diferencia aproximada es:

los Coding Plans suelen estar orientados principalmente a programación;
los Token Plans suelen cubrir más capacidades, como STT, TTS, generación de imágenes, búsqueda, embeddings y RAG;
STT significa speech to text;
TTS significa text to speech;
los Coding Plans a menudo restringen al usuario a escenarios de programación, mientras otras capacidades requieren compras separadas.

Desde el negocio, un Coding Plan se parece más a un buffet. Los usuarios pagan una tarifa fija por adelantado, mientras el proveedor apuesta a que la mayoría no agotará la cuota. Algunos usuarios consumen más, otros menos, y la plataforma todavía puede ganar dinero en promedio.

Pero si los precios pay-as-you-go por token bajan lo suficiente, los usuarios empiezan a calcular: ¿por qué tengo que comprar un plan? Si el coste mensual real es solo unos pocos yuanes o una decena, un plan de 40 o 200 yuanes puede dejar de valer la pena.

Por qué las rebajas desafían el modelo de suscripción

Los planes de suscripción dependen de una premisa: los usuarios sienten que cada uso individual es caro, o no quieren calcular el coste de cada llamada. Cuando los tokens son caros, un plan da tranquilidad. Cuando los tokens son casi insignificantes, pay-as-you-go se vuelve más natural.

La rebaja de DeepSeek V4 revela de hecho el coste subyacente:

las tareas de Agent pueden ser muy baratas;
el contexto largo no es necesariamente demasiado caro de usar;
los cache hits pueden reducir mucho el coste;
los desarrolladores comunes no necesitan necesariamente una suscripción fija;
el punto de entrada del modelo puede desplazarse de una “plataforma de planes” a una “API de bajo coste”.

Esto incomodará a plataformas construidas alrededor de Coding Plans. Si los usuarios ven que las llamadas pay-as-you-go son más baratas y libres, tienen menos razones para quedar atados a la suscripción de una plataforma.

Cómo elegir entre Flash y Pro

Una forma práctica de usar DeepSeek V4 es dividir el trabajo entre Flash y Pro.

Flash es adecuado para tareas frecuentes, ligeras y repetibles:

corregir bugs;
escribir código frontend;
escribir scripts;
comprensión rutinaria de código;
procesar información ordinaria en contexto largo;
ejecutar gran cantidad de subtareas.

Flash es barato, rápido y también admite contexto muy largo. Para agents de programación cotidianos, muchas tareas no necesitan Pro desde el inicio.

Pro es mejor para juicio complejo y trabajo de respaldo:

planificación multi-ronda;
flujos complejos de Agent;
múltiples llamadas de función;
verificación de hechos;
investigación financiera;
producción de contenido que requiere conocimiento y juicio más fuertes;
cambios de código de alto riesgo.

Una configuración razonable es: Flash maneja volumen, Pro maneja fallback. Empieza tareas ordinarias con Flash y cambia a Pro para planificación de largo alcance, juicio complejo, verificación de hechos o colaboración multi-herramienta. Así se controla el coste sin renunciar a calidad de modelo.

Por qué DeepSeek puede poner estos precios

DeepSeek tiene una estructura de negocio distinta a muchas grandes plataformas. No tiene e-commerce, redes sociales, video corto, cloud computing, teléfonos, coches, suites de oficina, sistemas operativos, navegadores ni un gran ecosistema SaaS empresarial.

Eso significa que no necesita encerrar a los usuarios en una plataforma completa. Puede simplemente vender capacidad de modelo de texto: usa modelos de texto baratos aquí y llama cualquier otra capacidad en otro lugar.

Las grandes plataformas suelen pensar distinto. Si compras su Coding Plan o Token Plan, entras en su ecosistema de cloud, búsqueda, generación de imágenes, voz, base de datos y herramientas de desarrollo. El plan no solo vende el modelo; compite por el punto de entrada del usuario.

El enfoque de DeepSeek es más directo: bajar el precio de los modelos de texto e intentar convertirse en el punto de entrada por defecto para Agents. Una vez ocupado ese punto de entrada, muchos desarrolladores y toolchains se adaptarán naturalmente alrededor.

Modelos abiertos y el punto de entrada por defecto

Si DeepSeek V4 mantiene una ruta de modelo abierto, proveedores cloud y plataformas de terceros pueden desplegarlo por su cuenta y ofrecer servicios. Para DeepSeek, eso es distribución y posible desviación a la vez.

Aquí es donde importa una API oficial de bajo precio. Si el precio oficial ya es lo bastante bajo, otras plataformas tendrán difícil ofrecer una ventaja clara aunque puedan desplegar el modelo. Los usuarios tenderán a usar directamente el punto de entrada por defecto, barato y estable.

Esto es especialmente cierto para herramientas de Agent. Las tareas de Agent dependen de contexto largo, caching, llamadas de herramientas y throughput estable. Una vez que un modelo es lo bastante barato en estos escenarios, tiene opción de convertirse en la opción por defecto.

Los Coding Plans aún no son inútiles

Esto no significa que los Coding Plans desaparezcan inmediatamente. Todavía encajan con algunos usuarios.

Si algunos usuarios son realmente intensivos y agotan su cuota todos los días, una suscripción fija puede seguir siendo económica. Igual que un buffet: si nadie pudiera comer suficiente para amortizarlo, nadie lo compraría.

El problema es que la mayoría de usuarios no son tan extremadamente frecuentes. Usuarios de baja frecuencia, desarrolladores ligeros y personas que ocasionalmente escriben scripts o modifican proyectos encajan mejor con pay-as-you-go. Después de que DeepSeek reduzca los costes por uso, el atractivo de los planes se debilita.

El futuro probablemente será una elección por capas:

usuarios intensivos de alta frecuencia seguirán comprando Coding Plans;
usuarios ordinarios se moverán a APIs de bajo coste;
las herramientas de Agent elegirán automáticamente Flash / Pro según la tarea;
los planes de plataforma tendrán que ofrecer más valor no relacionado con el modelo, como workflows, integración IDE, despliegue, gestión de equipos y auditoría de seguridad.

Resumen

DeepSeek V4 no creó su mayor impacto mediante benchmarks. Lo que realmente cambió las expectativas de la industria fue la reducción de precios posterior.

Cuando los tokens de entrada y el precio con cache hit bajan mucho, cambia el coste de usar AI Agents. Contexto largo, análisis de proyectos de código y llamadas multi-ronda de herramientas que antes parecían caras pueden convertirse en costes cotidianos de unos centavos o unos pocos yuanes.

Esto desafía directamente la lógica de negocio de Coding Plans y Token Plans. Si los usuarios pueden pagar por uso, combinar libremente modelos y herramientas, y mantener costes lo bastante bajos, quizá no quieran quedar atados a un plan de plataforma específico.

Lo que DeepSeek V4 toca realmente esta vez no es solo el ranking de capacidades del modelo, sino la estructura de costes de los AI Agents y la batalla por el punto de entrada por defecto.

Referencias:

NVIDIA lanza Nemotron 3 Nano Omni: un modelo abierto de razonamiento omnimodal para agentes

Fri, 01 May 2026 12:07:15 +0800

NVIDIA lanzó Nemotron 3 Nano Omni, un modelo abierto de razonamiento omnimodal diseñado para flujos de AI Agents. Su foco no es solo responder preguntas de texto, sino poner lenguaje, visión y audio en un mismo marco de razonamiento para trabajar con entradas más cercanas al trabajo real.

Por posicionamiento, Nemotron 3 Nano Omni parece un modelo base preparado para agentes. Puede entender información de pantallas, documentos, imágenes, voz y vídeo, y convertirla en resultados de razonamiento accionables.

Especificaciones del modelo

Nemotron 3 Nano Omni usa arquitectura MoE. NVIDIA lista estos puntos:

Item	Information
Model name	`Nemotron 3 Nano Omni`
Architecture	MoE
Parameter scale	30B total / 3B active
Modalities	Text, image, audio, video
Context length	256K tokens
License	Apache 2.0
Main deployment direction	AI Agents, multimodal reasoning, enterprise agents

Lo más llamativo es 30B-A3B: el modelo tiene unos 30B parámetros totales, pero activa alrededor de 3B por paso de inferencia. Es un equilibrio entre capacidad y coste.

Pero active params en MoE no significa que la VRAM pueda estimarse como si fuera solo un modelo de 3B. Hay que contar pesos de expertos, KV cache, módulos de visión y audio, contexto y sobrecarga del framework.

No resuelve un problema de una sola modalidad

Los LLM tradicionales procesan sobre todo texto. Los multimodales añaden imagen. Nemotron 3 Nano Omni apunta a algo más amplio: entrada omnimodal, con texto, imágenes, audio y vídeo dentro de un razonamiento unificado.

Esto importa para agentes porque las tareas reales suelen incluir:

leer botones, tablas y ventanas en pantalla;
analizar PDFs, capturas, gráficos y webs;
escuchar instrucciones o reuniones;
entender acciones y tiempos en vídeo;
combinar esas señales para decidir el siguiente paso.

Si un modelo solo maneja una modalidad, el agente necesita mucho pegamento entre modelos especializados. Un modelo omnimodal reduce ese coste de integración.

Pensado para operación de ordenador e inteligencia documental

NVIDIA menciona explícitamente tareas de operación de ordenador. Estas requieren entender interfaces:

qué controles aparecen en pantalla;
en qué estado está la ventana actual;
qué botón o menú debe usarse;
qué significan tablas, diálogos y campos de entrada.

Esto es difícil de evitar cuando los agentes entran en despliegues reales. Para operar software de oficina, navegadores, backends empresariales o herramientas de desarrollo, el agente debe entender la interfaz, no solo leer documentación.

La inteligencia documental tiene una lógica parecida. Los materiales empresariales mezclan texto, tablas, imágenes, páginas escaneadas y gráficos. Un modelo omnimodal puede poner todo eso en un mismo contexto para revisión de contratos, análisis de informes, facturas, QA de conocimiento y automatización de procesos.

Audio y vídeo acercan los agentes a escenarios reales

Las entradas de audio y vídeo amplían mucho los usos:

resúmenes de reuniones;
análisis de llamadas de atención al cliente;
comprensión de comandos de voz;
organización de contenido educativo;
análisis de vídeos instructivos;
inspección de seguridad o industrial;
revisión de grabaciones de pantalla;
razonamiento temporal en tareas de varios pasos.

Si estas tareas dependen solo de transcripciones, se pierde información visual y temporal. Un modelo omnimodal puede combinar voz, fotogramas y texto para dar al agente una visión más completa.

Despliegue y ecosistema

NVIDIA sitúa Nemotron 3 Nano Omni dentro de un ecosistema abierto y usa licencia Apache 2.0. Para desarrolladores y empresas, esto reduce la barrera de experimentación, integración y desarrollo secundario.

También está muy ligado al ecosistema de inferencia de NVIDIA. En despliegues empresariales aparecen preguntas como:

si corre de forma eficiente en GPUs NVIDIA;
si soporta contexto largo y entrada multimodal;
si conecta con frameworks de agentes existentes;
si procesa documentos internos, audio/vídeo y capturas de UI;
si puede desplegarse en entornos privados.

NVIDIA afirma que el modelo puede alcanzar hasta 9x el throughput de modelos abiertos omnimodales comparables. El valor real dependerá del hardware, contexto, modalidades y framework, pero la dirección es clara: unir modelos abiertos multimodales con infraestructura de inferencia empresarial.

Casos de uso adecuados

Nemotron 3 Nano Omni encaja mejor en:

agentes que entienden texto, imagen, audio y vídeo al mismo tiempo;
inteligencia documental empresarial y QA de conocimiento;
operación de ordenador basada en capturas o interfaces web;
análisis multimodal de reuniones, atención al cliente y docencia;
comprensión de vídeo, revisión de workflows y razonamiento temporal;
equipos que necesitan licencia abierta y despliegue privado.

No es necesariamente lo mejor para todo usuario. Para chat local, completado de código o QA simple, un modelo de lenguaje de una sola modalidad puede ser más ligero y rápido.

Qué significa para AI Agents

Para que los AI Agents entren realmente en escenarios de trabajo, no basta con escribir texto. Necesitan entender interfaces, voz, documentos y cambios en vídeo, y convertirlo en la siguiente acción.

Ahí es donde Nemotron 3 Nano Omni importa. No es solo hacer el modelo más grande: es unificar muchos tipos de entrada que los agentes encuentran en tareas reales.

Desde este ángulo, el lanzamiento de NVIDIA no es solo “otro modelo multimodal”. Es parte del esfuerzo por conectar modelos abiertos, inferencia GPU, agentes empresariales y despliegue privado. Lo siguiente a observar será su rendimiento en frameworks de agentes, workflows empresariales y despliegues locales.

Referencias:

NVIDIA Technical Blog: NVIDIA Nemotron 3 Nano Omni

FinceptTerminal: terminal financiera open source, investigaci贸n cuantitativa y banco de trabajo para AI Agents

Fri, 01 May 2026 03:47:18 +0800

FinceptTerminal es un proyecto de terminal financiera de código abierto de Fincept Corporation.

Según el README, no es un simple panel de cotizaciones de mercado. Es una plataforma de escritorio integral para análisis financiero, investigación quant, flujos de trabajo de trading y AI Agents. La Versión 4 está construida con C++20 y Qt6 como una aplicación de escritorio nativa, mientras incrusta el ecosistema Python para análisis, scripting, machine learning y modelado financiero.

Si necesitamos una comparación, se asemeja más a un banco de trabajo (workbench) de investigación financiera de código abierto: conectando fuentes de datos en un lado, y gestionando gráficos, carteras (portfolios), investigación quant, trading, análisis de inteligencia y flujos de trabajo automatizados en el otro.

Primero debe quedar claro algo: herramientas como esta pueden usarse para investigación, análisis, educación y construcción de herramientas internas, pero ninguna salida debe tratarse directamente como asesoramiento de inversión. Los mercados financieros son riesgosos, y los datos, modelos, estrategias y la ejecución requieren verificación independiente.

false

¿Qué problema resuelve?

La investigación financiera a menudo está dispersa en muchas herramientas:

Los datos de mercado se encuentran en una aplicación
El código de investigación se encuentra en Jupyter
Los gráficos se encuentran en otra herramienta
El análisis de cartera se realiza en hojas de cálculo
Los registros de trading se encuentran en los sistemas de corretaje
Las noticias y la inteligencia se encuentran en el navegador
El análisis de IA se encuentra en una ventana de chat

Este enfoque funciona, pero la colaboración y la reproducibilidad son difíciles.

FinceptTerminal intenta integrar estas capacidades en una única terminal de escritorio, para que los usuarios puedan completar flujos de trabajo relacionados con el acceso a datos, el análisis, el modelado, la visualización, la colaboración de Agentes y el trading en el mismo entorno.

Su objetivo no es reemplazar cada sistema profesional, sino proporcionar una base de código abierto y extensible para una terminal financiera.

false

Arquitectura técnica

El README menciona que v4 usa C++20 y Qt6.

Esto significa que no es un panel web puro, sino una aplicación de escritorio nativa. Para una terminal financiera, las aplicaciones nativas tienen varias ventajas:

Mayor estabilidad en la capacidad de respuesta de la UI
Mejor adaptación para ventanas complejas y diseños multipanel
Acceso más fácil a archivos locales y recursos del sistema
Capacidad para integrar componentes de alto rendimiento
Mejor adecuada para flujos de trabajo de escritorio de larga duración

Al mismo tiempo, el proyecto también integra Python.

Esto es importante. En la investigación financiera y el análisis quant, Python es uno de los lenguajes principales de facto. El análisis de datos, el machine learning, las estadísticas, el backtesting, la creación de gráficos (charting) y la modelización financiera dependen en gran medida del ecosistema Python. C++/Qt maneja el framework de la aplicación y la experiencia de escritorio, mientras que Python se encarga de la investigación y la extensibilidad. Esa es una combinación muy práctica.

false

Data connectors

El README indica que el proyecto proporciona más de 100 data connectors.

El valor de una terminal financiera depende en gran medida del acceso a datos. Sin datos, incluso la mejor UI y los mejores models son solo una cáscara vacía.

Estos conectores suelen poder cubrir diferentes fuentes:

Market quotes
Macroeconomic data
Company financials
News and intelligence
Exchange data
Crypto asset data
Research data sources
Internal or custom APIs

Para los usuarios, los data connectors reducen el flujo de trabajo de “descargar CSV, limpiarlo manualmente y luego importarlo de nuevo”, haciendo que el análisis se acerque al tiempo real y a la automatización.

Dicho esto, la calidad, la licencia, la latencia, la cobertura y el costo de los datos financieros son todos críticos. Antes de utilizar cualquier fuente de datos, su licencia y los límites de uso deben ser confirmados.

false

Módulo AI Agents

El proyecto hace hincapié en AI Agents, lo que también es donde difiere de las terminales financieras tradicionales.

Las terminales tradicionales son interfaces operadas principalmente por humanos: las personas miran los datos y emiten juicios. Con AI Agents, la herramienta puede asumir más trabajo de estilo asistente:

Resumir información de mercado
Explicar informes y anuncios financieros
Generar resúmenes de investigación
Ayudar a filtrar datos
Asistir con scripts de análisis
Organizar flujos de trabajo de trading o de investigación
Pasar contexto entre módulos

Esto no significa que la IA pueda reemplazar a los analistas o a los traders.

Una postura más razonable es esta: AI Agents ayudan a reducir el trabajo de organización repetitivo y proporcionan análisis preliminares y consultas interactivas, pero las conclusiones importantes aún requieren validación de datos, validación de modelos y juicio humano.

false

Capacidades de investigación cuantitativa

FinceptTerminal también está orientado a la investigación quant.

La investigación quant generalmente incluye:

Limpieza de datos
Construcción de factores
Hipótesis de estrategia
Backtesting
Evaluación de riesgos
Optimización de portafolio
Estimación de costos de trading
Visualización de resultados

Si una terminal puede integrar conexiones de datos, análisis en Python, gráficos y flujos de trabajo, puede ser muy útil para la investigación quant. Los investigadores pueden pasar paso a paso de los datos a la validación de la estrategia en un solo entorno.

Sin embargo, el mayor peligro en la investigación quant es algo que “parece efectivo”. Si una estrategia no maneja estrictamente la validación fuera de muestra (out-of-sample validation), los costos de trading, el deslizamiento (slippage), el sesgo de supervivencia (survivorship bias), el sobreajuste (overfitting) y la fuga de datos (data leakage), incluso un hermoso backtest no es confiable.

Por lo tanto, este tipo de herramienta debe tratarse como una plataforma de investigación, no como una máquina automática para ganar dinero.

false

QuantLib y modelado financiero

El README menciona capacidades relacionadas con QuantLib.

QuantLib es una librería de código abierto común en ingeniería financiera. Se utiliza a menudo para tasas de interés, bonos, opciones, valoración de derivados, construcción de curvas, cálculo de riesgo y áreas relacionadas.

Esto significa que FinceptTerminal no se trata solo de ver cotizaciones de acciones. También intenta cubrir escenarios de modelado financiero más profesionales.

Estas capacidades son adecuadas para:

Aprender ingeniería financiera
Experimentos en valoración de derivados
Cálculo de métricas de curva y riesgo
Análisis de riesgo de cartera
Prototipado de modelos de investigación

Sin embargo, el modelado financiero en sí mismo tiene una alta barrera. Los parámetros del modelo, las suposiciones del mercado, las fuentes de datos y la lógica de precios afectan todos los resultados. Una herramienta puede reducir los costos operativos, pero no puede reemplazar el juicio profesional.

false

Node workflows

El README también menciona los workflows basados en Node.

Los Node workflows son adecuados para dividir tareas complejas en procesos visuales:

Read data
Clean data
Run models
Generate charts
Trigger AI analysis
Output reports
Send notifications

Para escenarios financieros, este enfoque tiene dos ventajas.

Primero, el proceso se vuelve visible. El análisis complejo ya no está oculto solo dentro de una pila de scripts, y los usuarios pueden ver cómo fluyen los datos.

Segundo, es adecuado para la automatización. Los procesos de investigación repetitivos se pueden guardar, reutilizar y ajustar.

Si estos workflows se pueden combinar con Python scripts, data connectors, Agents y reporting systems, este tipo de node workflow puede convertirse en un módulo muy valioso dentro de una terminal financiera.

false

Trading y gestión de portafolio

El proyecto también menciona capacidades relacionadas con el trading y la gestión de portafolio.

Esta es el área que requiere la mayor cautela.

La gestión de portafolio puede ayudar a los usuarios a comprender la exposición de activos, rendimientos, drawdowns, volatilidad, correlación y concentración de riesgos. Los módulos de trading pueden involucrar órdenes, cuentas, ejecución y registros.

Pero siempre que esté involucrado el trading real, deben considerarse lo siguiente:

Latencia de datos
Riesgo de ejecución de órdenes
Permisos de API
Costos de trading
Slippage
Liquidez
Límites de control de riesgo
Auditoría y registros (logs)
Disparadores accidentales de estrategias

Las características de trading en entornos de desarrollo e investigación no deben equipararse con sistemas de trading de grado de producción. Antes de conectarse al trading en vivo, se requieren pruebas estrictas, aislamiento de permisos, mecanismos de control de riesgo y revisión manual.

false

¿En qué se diferencia de Bloomberg Terminal?

Muchos proyectos de terminales financieros se comparan con Bloomberg Terminal.

Pero el posicionamiento es diferente.

El valor de Bloomberg Terminal no es solo su interfaz de software. También incluye:

Cobertura de datos
Licenciamiento de datos
Red de noticias
Ecosistema de trading
Soporte al cliente
Flujos de trabajo de instituciones financieras
Confianza industrial acumulada a lo largo del tiempo

FinceptTerminal es más parecido a un framework de terminal financiero de código abierto y una plataforma de investigación. Sus fortalezas son la extensibilidad, la personalización, la localización y la integración con flujos de trabajo de Python y AI.

No debe entenderse simplemente como un reemplazo gratuito para Bloomberg.

Una visión más razonable es esta: si quieres estudiar cómo se construyen los terminales financieros, o si quieres crear tu propio banco de trabajo de análisis financiero, FinceptTerminal proporciona un punto de partida de código abierto.

false

Licenciamiento y límites comerciales

El README menciona que el proyecto utiliza AGPL y un modelo de licenciamiento comercial.

AGPL tiene requisitos explícitos para servicios de red y obras derivadas. Si solo lo utilizas para aprender, investigación o experimentos personales, generalmente no es un problema importante. Pero si planeas convertirlo en un producto comercial, una plataforma interna o un servicio externo, necesitas leer la licencia cuidadosamente.

Las herramientas financieras a menudo entran en sistemas empresariales internos. En ese caso, las licencias de código abierto, las licencias comerciales, las licencias de datos y las licencias de modelo deben revisarse todas juntas, en lugar de solo preguntar si el código puede ejecutarse.

false

¿A quién debe prestar atención?

FinceptTerminal es adecuado para:

Desarrolladores interesados en la arquitectura de terminales financieras
Personas que realizan investigación cuantitativa o experimentos de ingeniería financiera
Personas que desean integrar análisis de Python en herramientas de escritorio
Personas que exploran flujos de trabajo de AI Agent + finanzas
Equipos que desarrollan plataformas internas de análisis financiero
Personas que aprenden el desarrollo de aplicaciones financieras en C++/Qt

Si solo desea seguir cotizaciones de algunas acciones, el software de mercado ordinario puede ser más sencillo.

Si quiere entender cómo se integra un terminal financiero datos, gráficos, modelos, Agents, trading y flujos de trabajo, este proyecto vale más la pena estudiar.

false

Cosas a tener en cuenta al usarlo

Primero, distingue la investigación del trading.

Los entornos de investigación pueden tolerar experimentos y fallos. Los entornos de trading no pueden. No conectes una herramienta de investigación a cuentas reales antes de que haya sido verificada.

Segundo, toma en serio la licencia de datos.

Los datos financieros no pueden simplemente ser raspados y utilizados comercialmente. Las diferentes fuentes de datos tienen diferentes términos de licencia, especialmente los datos de mercado, las noticias, los estados financieros y los datos de intercambio.

Tercero, no confíes ciegamente en los AI Agents.

La IA puede ayudar a organizar la información, pero las conclusiones financieras deben basarse en datos, modelos, riesgos y validación fáctica.

Cuarto, presta atención a la seguridad.

Si una herramienta se conecta a cuentas, API keys, interfaces de trading o datos internos, la gestión de claves, el aislamiento de permisos, los logs y los límites de red deben manejarse correctamente.

Quinto, comprende la licencia open-source.

AGPL tiene implicaciones importantes para el uso comercial y el despliegue de servicios. Antes de la productización, los problemas de licencia deben manejarse primero.

false

Referencia

Fincept-Corporation/FinceptTerminal

false

Pensamiento final

Lo que hace que FinceptTerminal merezca la pena es que integra terminales financieros, investigación quant en Python, AI Agents, data connectors y node workflows en el mismo concepto de plataforma de escritorio de código abierto.

Está mejor orientado como punto de partida para la investigación de tecnología financiera y la creación de herramientas internas, que como un producto terminado que pueda reemplazar directamente los terminales financieros profesionales o los sistemas de trading en vivo. false

mattpocock/skills: una colecci贸n pr谩ctica de habilidades para agentes de codificaci贸n con IA

Fri, 01 May 2026 03:43:20 +0800

mattpocock/skills es una colección pública de habilidades de agentes de codificación IA de Matt Pocock.

No es una aplicación completa ni un nuevo cliente de chat. Es un conjunto de habilidades funcionales que pueden ser utilizadas por asistentes de codificación IA. La idea es práctica: desglosar problemas comunes de codificación de IA en pequeñas habilidades que un Agent puede llamar en la tarea adecuada, en lugar de depender de un solo prompt enorme cada vez.

Si a menudo utilizas Claude Code, Codex, Cursor o herramientas de codificación IA similares, vale la pena observar este tipo de colección de habilidades. Lo que realmente afecta la experiencia de codificación con IA a menudo no es si el modelo puede escribir código, sino si puede avanzar en la tarea según tu estilo de trabajo preferido.

false

Qué Problema Resuelve

Los asistentes de codificación de IA son potentes, pero pueden cometer errores fácilmente.

Las situaciones comunes incluyen:

Comenzar cambios de código sin entender el requisito
Modificar demasiados archivos a la vez
Producir mucha explicación pero poca acción útil
Intentar cosas a ciegas después de errores
No ejecutar pruebas o verificaciones a tiempo
Ignorar patrones de proyecto existentes
Introducir abstracciones innecesarias para terminar una tarea
Escribir código sin revisar realmente los riesgos después

Estos problemas no siempre son causados por una débil capacidad del modelo. A menudo, el flujo de trabajo no está lo suficientemente restringido.

El valor de mattpocock/skills es que transforma estos modos de fallo comunes en métodos operativos reutilizables, haciendo que el Agent se comporte más como un colaborador de ingeniería experimentado en diferentes escenarios.

false

¿Qué son los Skills

En el contexto de AI Agent, un skill se puede entender como una instrucción de tarea reutilizable, un método de trabajo o un flujo de trabajo profesional.

No tiene por qué ser un código plugin, y no siempre necesita llamar a un servicio externo. En muchos casos, un skill es simplemente un conjunto claro de reglas:

Cuándo usarlo
Qué hacer primero
Qué no hacer
Qué salida se requiere
Cómo juzgar la finalización de la tarea

Esto es algo parecido a una normal prompt template, pero la granularidad está más cerca de una capacidad de tarea.

Las normal prompt templates suelen copiarse y pegarse manualmente por el usuario. Los skills son mejores como parte de una toolbox de agente, lo que permite al Agent elegir el flujo de trabajo correcto para la tarea.

false

Por qué es importante la pequeñez y la componibilidad

El README enfatiza que estas habilidades son pequeñas y componibles.

Esta dirección es importante.

Si una habilidad intenta manejarlo todo, rápidamente se convierte en un nuevo prompt gigante: largo, vago y difícil de mantener. La ventaja de las habilidades pequeñas son los límites claros.

Por ejemplo, una habilidad puede centrarse en:

Planificar primero
Arreglar errores de TypeScript
Ejecutar pruebas y corregir basándose en los resultados
Realizar revisión de código (code review)
Resumir convenciones del proyecto
Mejorar prompts
Eliminar abstracciones innecesarias

Estas habilidades se pueden combinar según la tarea. Una tarea simple puede necesitar solo una habilidad, mientras que una tarea compleja puede encadenar varias.

Esto se acerca más al trabajo de ingeniería real. No utilizas el mismo flujo de trabajo (workflow) para cada problema; eliges las herramientas según la situación.

false

Manteniendo al Ingeniero en Control

Una dirección importante de este repositorio es mantener al ingeniero en control.

La codificación con IA puede derivarse fácilmente en dos extremos.

El primero es completamente manual. La IA solo ayuda a escribir unas pocas líneas de código, mientras que todo el contexto, la planificación y la verificación todavía dependen de ti.

El segundo es completamente automatizado (hands-off). Tú envías una tarea a un Agent, lo dejas cambiar muchas cosas, y luego te enfrentas a un diff que es difícil de revisar.

Las habilidades ayudan a encontrar una posición intermedia más estable.

Permiten que la IA asuma más flujo de trabajo repetitivo, mientras la sigue limitando con reglas:

Entender la tarea antes de actuar
Leer los archivos relevantes antes de editar
Mantener el alcance de la modificación controlado
Informar sobre la incertidumbre
Verificar después de los cambios
No refactorizar código no relacionado solo para demostrar

Esto no debilita a la IA. Hace que las acciones de la IA sean más fáciles de revisar y asumir para los humanos.

false

Problemas de Alineación

El primer tipo de fallo de codificación de IA suele ser un fallo de alineación.

El usuario quiere un cambio muy específico, pero el Agent puede entenderlo como una refactorización más amplia. El usuario solo quiere que se arregle un bug, pero cambia estilos en el proceso. El usuario quiere que se siga la arquitectura existente, pero introduce un patrón nuevo.

Las habilidades pueden ayudar al Agent a hacer varias cosas al comienzo de una tarea:

Restatear el objetivo
Identificar el alcance del impacto
Reconocer los patrones de implementación existentes
Proporcionar un plan
Aclarar lo que no se hará

Este paso es como una autocomprobación del ingeniero antes de comenzar el trabajo.

Si el Agent no puede declarar claramente los límites de la tarea y comienza a escribir código directamente, es fácil que la tarea se desvíe.

false

Problemas del Bucle de Retroalimentación

La IA no debe escribir código únicamente mediante la generación one-shot.

En el desarrollo real, los bucles de retroalimentación son importantes:

Cambiar una pequeña parte
Ejecutar pruebas o type checks
Leer los errores
Corregirlos
Verificar de nuevo

Muchos Agents fallan porque omiten la retroalimentación intermedia. Cambian muchas cosas a la vez y luego resumen por intuición que “it should work”.

Las Skills pueden hacer explícito el bucle de retroalimentación. Por ejemplo, pueden exigir al Agent que:

Ejecute comprobaciones relevantes después de la modificación
Lea los mensajes de error primero si las comprobaciones fallan
Evite cambiar ciegamente archivos no relacionados
Verifique de nuevo después de cada ronda de correcciones
Informe los resultados finales de la verificación

Esto hace que la codificación con IA se parezca más al depurado (debugging) real y menos a la escritura one-shot.

false

Problemas de Control de Arquitectura

AI es bueno generando abstracciones, y también bueno sobregenerando abstracciones.

Para completar un requisito pequeño, puede crear una capa de servicio (service layer), funciones auxiliares (helper functions), objetos de configuración, type wrappers y adaptadores, haciendo que el código sea mucho más complejo que el requisito en sí.

Esto es especialmente peligroso en proyectos grandes. Las abstracciones generadas por AI a menudo parecen profesionales, pero pueden no coincidir con el estilo del proyecto existente y pueden aumentar el costo de mantenimiento.

Las buenas habilidades recuerdan al Agent que:

Preferir patrones existentes
Evitar nuevas abstracciones innecesarias
Evitar la refactorización de áreas no relacionadas
Ajustar el cambio al tamaño de la tarea
Comprender el código antes de diseñar la estructura

Esto reduce la producción que parece ingenierizada pero que en realidad es más difícil de mantener.

false

Por qué son importantes las habilidades de revisión

Escribir código y revisar código son estados diferentes.

Cuando un Agent escribe código, generalmente tiende a demostrar que su implementación funciona. Puede explicar por qué el cambio debería funcionar, pero no siempre busca activamente riesgos.

El propósito de una habilidad de revisión es cambiar el rol del Agent:

Encontrar posibles errores (bugs)
Encontrar regresiones de comportamiento
Encontrar pruebas faltantes
Encontrar casos límite (edge cases)
Encontrar mayor complejidad
Encontrar inconsistencias con las convenciones existentes

Esto es importante para la programación con IA porque la IA genera código rápidamente. Sin revisión, los usuarios pueden sentirse fácilmente abrumados por grandes diffs.

Una buena salida de revisión debe listar los problemas primero, no alabar la implementación primero. Debe ayudar al ingeniero a decidir si el cambio se puede fusionar (merged).

false

Diferencia con los archivos de reglas normales

Muchas herramientas de codificación de IA admiten reglas, instrucciones o memoria.

Estos archivos generalmente registran reglas a largo plazo, como:

Stack tecnológico del proyecto
Convenciones de nomenclatura
Comandos de prueba
Directorios que no deben modificarse
Preferencias de estilo de respuesta

Las habilidades (Skills) se centran más en el flujo de trabajo de la tarea.

Las reglas le dicen al Agent “cómo comportarse a largo plazo”, mientras que las habilidades le dicen al Agent “cómo ejecutar este tipo de tarea”.

Ambos funcionan mejor juntos.

Por ejemplo, las reglas pueden indicar que el proyecto usa pnpm test, mientras que una habilidad de revisión requiere verificar la cobertura de pruebas después de los cambios. Entonces el Agent sabe no solo el comando, sino también cuándo usarlo.

false

Escenarios Adecuados

Los repositorios como mattpocock/skills son adecuados para:

Uso frecuente de AI coding tools
Agents que trabajan en codebases reales
Reducir ediciones de AI fuera de alcance
Hacer que el Agent verifique los resultados de forma más activa
Convertir tus hábitos de ingeniería en skills
Aprender cómo otros diseñan workflows de agentes
Convertir prompts temporales en una colección de skills mantenible

Si solo pides ocasionalmente a AI que escriba una función pequeña, quizás no necesites mantener skills.

Pero si ya tratas a AI como un socio de desarrollo a largo plazo, las skills se vuelven cada vez más importantes. Son como un método de trabajo reutilizable para el Agent.

false

Cómo aprender de este repositorio

Incluso si no utilizas cada habilidad directamente, puedes aprender varias cosas de este repositorio.

Primero, anota los modos de fallo.

No solo te quejes cuando la AI comete un error. Convierte los patrones que a menudo se equivoca en reglas, para que una habilidad pueda evitarlos la próxima vez.

Segundo, mantén las habilidades cortas.

Una habilidad debe resolver un problema claro. Cuanto más corta sea, más fácil será llamarla correctamente y mantenerla.

Tercero, haz que el formato de salida sea claro.

Si quieres que el Agent enumere un plan primero, ejecute después y resuma los resultados de verificación al final, escribe esa estructura claramente. Los requisitos vagos suelen producir resultados vagos.

Cuarto, conserva puntos de traspaso humano.

Una buena habilidad no debe permitir que la AI funcione sola durante demasiado tiempo. Cuando haya incertidumbre, un alcance de impacto expandido, pruebas fallidas o una decisión de producto, debe detenerse y explicar la situación.

false

Notas de uso

Primero, no conviertas todo en habilidades (skills).

Demasiadas habilidades hacen que el sistema sea complejo, y el Agent podría no saber cuál elegir. Empieza con los escenarios más frecuentes y más problemáticos.

Segundo, las habilidades necesitan iteración.

La primera versión de una habilidad puede no ser buena. Observa cómo la IA la ejecuta realmente, luego elimina, añade y reescribe gradualmente.

Tercero, no permitas que las habilidades reemplacen el juicio de la ingeniería.

Las habilidades pueden mejorar el flujo de trabajo, pero no pueden garantizar una implementación correcta. Las pruebas (tests), la revisión, las comprobaciones de compilación (build checks) y el juicio humano siguen siendo importantes.

Cuarto, presta atención a las diferencias entre los Agents.

Claude Code, Codex, Cursor y Copilot soportan las instrucciones, las habilidades y las reglas de manera diferente. La misma idea se puede reutilizar, pero el formato específico debe ajustarse para cada herramienta.

false

Referencia

mattpocock/skills

false

Pensamiento Final

Lo que hace que mattpocock/skills merezca la pena es no un único prompt mágico dentro de él, sino la idea práctica de codificación con IA que demuestra: dividir la experiencia de ingeniería en pequeñas habilidades y luego permitir que el Agent las combine según el escenario.

A medida que la codificación con IA pasa de ser una asistencia ocasional a formar parte del flujo de trabajo diario, las habilidades se convierten en herramientas importantes para limitar a los Agents, mantener a los ingenieros en control y mejorar la calidad de la retroalimentación. false

free-claude-code: conectar Claude Code a OpenRouter, DeepSeek y modelos locales mediante un proxy

Fri, 01 May 2026 03:41:49 +0800

free-claude-code es un Anthropic-compatible proxy para usar con Claude Code.

La idea no es crackear Claude Code ni ofrecer un servicio Claude oficial gratuito, sino iniciar localmente un proxy compatible con la forma de la API de Anthropic y reenviar las solicitudes de Claude Code a otros backends de modelos. El README menciona backends como NVIDIA NIM, OpenRouter, DeepSeek, LM Studio, llama.cpp y Ollama.

En pocas palabras, resuelve este problema: te gusta la experiencia de Claude Code en la terminal, pero quieres conectar las peticiones del modelo a otro provider o a un modelo local.

Qué problema resuelve

La experiencia interactiva de Claude Code es muy adecuada para tareas de desarrollo.

Puede leer código en la terminal, modificar archivos, ejecutar comandos y avanzar según el contexto del proyecto. El problema es que muchos usuarios no necesariamente quieren usar siempre el mismo backend de modelo:

Quieren probar distintos modelos en OpenRouter
Quieren usar modelos como DeepSeek para reducir costes
Quieren conectar las peticiones a Ollama local
Quieren ejecutar modelos locales con LM Studio o llama.cpp
Quieren unificar en el entorno de desarrollo una entrada de proxy
Quieren comparar el rendimiento de distintos modelos dentro del flujo de Claude Code

El posicionamiento de free-claude-code es añadir una capa de proxy compatible entre Claude Code y estos servicios de modelos.

Así, Claude Code sigue enviando solicitudes con estilo Anthropic, y el proxy se encarga de adaptarlas a distintos backends.

Funcionamiento

Puede entenderse como tres capas:

El frontend es Claude Code
En medio está el proxy free-claude-code
El backend es OpenRouter, DeepSeek, un modelo local u otro servicio de modelo

Claude Code cree que está accediendo a una API Anthropic-compatible.

El proxy recibe la solicitud, elige el provider objetivo según la configuración, transforma los campos necesarios y devuelve la respuesta a Claude Code.

La ventaja de esta estructura es que no necesitas modificar Claude Code ni exigir que cada servicio de modelo soporte Claude Code de forma nativa. Mientras el proxy pueda alinear la interfaz, puede conectar más modelos al mismo flujo de trabajo.

Backends soportados

Las direcciones listadas en el README incluyen:

NVIDIA NIM
OpenRouter
DeepSeek
LM Studio
llama.cpp
Ollama

Estos backends representan varias formas de uso.

OpenRouter se parece más a una entrada agregadora de modelos, útil para probar distintos modelos comerciales y open source.

DeepSeek conviene a quienes se preocupan por capacidad en chino, capacidad de código y coste.

LM Studio, llama.cpp y Ollama se inclinan hacia la ruta de modelos locales. Sirven para ejecutar modelos en tu propia máquina o en un entorno de intranet, reducir dependencia de APIs externas y facilitar experimentos offline.

NVIDIA NIM está más orientado a inferencia empresarial y despliegue con GPU.

Por qué un Anthropic-compatible proxy

Claude Code está diseñado alrededor de la interfaz y los hábitos de modelo de Anthropic.

Si quieres conectarlo a otros modelos, el problema más directo es que las interfaces no coinciden:

Campos de solicitud distintos
Nombres de modelo distintos
Formatos de streaming distintos
Expresión de tool use distinta
Formatos de error distintos
Límites de tokens y contexto distintos

El valor de la capa proxy está ahí.

Mantiene la interfaz vista por Claude Code con una forma cercana a Anthropic y adapta el backend. Para el usuario, después de configurar el proxy, puede probar distintos modelos dentro del mismo flujo de Claude Code.

Escenarios adecuados

free-claude-code es adecuado para:

Querer usar el flujo de terminal de Claude Code
Probar modelos no Anthropic dentro de Claude Code
Reducir costes de llamadas de modelo
Conectar Claude Code a OpenRouter
Integrar DeepSeek u otros servicios de modelo compatibles
Usar Ollama, LM Studio o llama.cpp para ejecutar modelos locales
Configurar para un equipo una entrada unificada de proxy de modelos

Si solo usas Claude Code oficial normalmente y no tienes necesidades especiales de provider, coste o despliegue local, quizá no necesites este tipo de proxy.

Pero si comparas modelos con frecuencia o quieres que Claude Code acceda a modelos locales y de terceros, este tipo de herramienta es útil.

Diferencia frente a usar directamente OpenRouter u Ollama

Usar directamente OpenRouter, Ollama o LM Studio normalmente significa conversar con el modelo o llamarlo mediante API.

El punto central de free-claude-code no es sustituir esos servicios, sino conectarlos al flujo de desarrollo de Claude Code.

La diferencia está en:

Sigues usando la experiencia de terminal de Claude Code
La IA puede realizar tareas alrededor del repositorio de código
El backend de modelo puede cambiarse por otro provider
Los modelos locales también tienen oportunidad de entrar en el flujo de Claude Code
La configuración se concentra en la capa proxy, no se cambia por separado en cada herramienta

Por eso se parece más a un puente que a un nuevo cliente de chat.

Precauciones con modelos locales

Conectar Claude Code a modelos locales es atractivo, pero también tiene límites prácticos.

Primero, diferencia de capacidad del modelo.

Las tareas de Claude Code no son solo chat; incluyen entender código, planificar cambios, editar archivos y procesar salidas de comandos. Un modelo local pequeño no necesariamente puede completar estas tareas de forma estable.

Segundo, ventana de contexto.

Las tareas de código consumen mucho contexto. Si la ventana del modelo es demasiado pequeña, puede no leer archivos completos, perder restricciones o olvidar contexto durante varias rondas.

Tercero, compatibilidad con tool use.

El flujo de Claude Code depende de llamadas a herramientas y comportamiento estructurado. Aunque un backend pueda chatear, no necesariamente sigue bien protocolos de tool calling.

Cuarto, velocidad y hardware.

La velocidad del modelo local depende de la máquina, el método de cuantización y el tamaño del modelo. Si una tarea de código responde demasiado lento, la experiencia se degrada de forma notable.

Por eso, los modelos locales son más adecuados para experimentos, tareas de bajo riesgo y escenarios concretos. Para tareas de código realmente complejas, todavía hay que elegir con cuidado según la capacidad del modelo.

Límites de uso

Este tipo de proyecto puede malinterpretarse fácilmente por el título, así que conviene aclarar los límites.

Primero, no es cuota gratuita oficial de Claude Code.

Solo reenvía las solicitudes de Claude Code a otros backends de modelos. Al usar OpenRouter, DeepSeek, NVIDIA NIM u otras APIs, sigues teniendo que cumplir precios, cuotas y condiciones de uso de esos servicios.

Segundo, no es una herramienta para saltarse autorización.

Al usar cualquier proxy, hay que cumplir las licencias y términos de Claude Code, del proveedor de modelo y del propio proyecto. No debería entenderse como una forma de evitar restricciones oficiales.

Tercero, el proxy procesará el contenido de tus solicitudes.

Código, salida de comandos y contexto del proyecto pueden pasar por el proxy y por el servicio backend. Al desplegarlo, hay que considerar logs, claves, red y límites de privacidad. Para código de empresa o proyectos sensibles, es mejor usar un entorno controlado.

Cuarto, el rendimiento de distintos modelos puede variar mucho.

La misma operación de Claude Code puede comportarse de forma completamente distinta al cambiar de modelo. No asumas que todos los modelos pueden sustituir a Claude.

Relación con proxies como LiteLLM

Desde el punto de vista de diseño, free-claude-code pertenece a la categoría de “proxies de interfaz compatible”.

El objetivo común de estas herramientas es reducir el acoplamiento entre la aplicación superior y los servicios de modelos inferiores. La aplicación superior solo se enfrenta a una interfaz relativamente unificada, y los providers de abajo pueden cambiarse por configuración.

Cada proyecto tiene un foco distinto. Algunos se orientan a gateway de modelos general, otros a OpenAI-compatible API, y otros se adaptan específicamente a herramientas como Claude Code.

Lo interesante de free-claude-code es que coloca el escenario objetivo directamente en Claude Code, no en un proxy de chat genérico.

Usuarios adecuados

Es más adecuado para usuarios con cierta capacidad de configuración:

Conocen Claude Code
Saben configurar API key y provider de modelos
Entienden cómo arrancar un proxy y variables de entorno
Pueden diagnosticar problemas de red, puertos, nombres de modelo y streaming
Quieren comparar el rendimiento de distintos modelos en tareas de código

Si solo quieres algo listo para usar, la configuración oficial suele ser más tranquila.

Si estás dispuesto a montar proxy, cambiar modelos, ajustar parámetros y quieres llevar Claude Code a más entornos de modelo, este proyecto merece estudio.

Referencia

Alishahryar1/free-claude-code

Una última frase

El valor de free-claude-code no está en la palabra “free”, sino en construir un puente entre Claude Code y más backends de modelos.

Cuando quieres conservar la experiencia de desarrollo de Claude Code y al mismo tiempo probar OpenRouter, DeepSeek, modelos locales o servicios de inferencia empresariales, este tipo de Anthropic-compatible proxy tiene sentido.

Compound Engineering Plugin: convertir la programación con IA en un ciclo de planificación, ejecución y revisión

Fri, 01 May 2026 03:15:39 +0800

Compound Engineering Plugin es un plugin de flujo de trabajo de programación con IA publicado como open source por Every Inc.

No se centra en “hacer que la IA escriba un fragmento de código más rápido”, sino en colocar la programación con IA dentro de un ciclo más parecido al de un equipo de ingeniería: primero planificar, luego implementar, después revisar y finalmente conservar la experiencia aprendida. Para quienes usan con frecuencia herramientas como Claude Code, Codex, Cursor o Copilot, este tipo de plugin resuelve un problema de flujo de trabajo, no solo de prompts.

Las herramientas de programación con IA son cada vez más fuertes, pero en proyectos reales lo más difícil no suele ser generar código, sino lograr que siga de forma continua las reglas del proyecto, entienda los límites de la tarea, evite repetir errores y acumule contexto durante iteraciones largas.

Qué problema resuelve

Muchas personas usan asistentes de programación con IA más o menos así:

Describen directamente el requisito
Dejan que la IA modifique código
Miran si el resultado puede ejecutarse
Si hay error, añaden más instrucciones
En la siguiente tarea vuelven a explicar desde cero

Este método puede completar tareas pequeñas, pero en proyectos complejos aparecen problemas con facilidad:

El requisito no se divide primero con claridad y la IA empieza a modificar directamente
Falta una review sistemática después de los cambios
Las reglas del proyecto dependen de que el usuario las recuerde una y otra vez
El mismo tipo de error vuelve a aparecer en la siguiente ocasión
Falta un método de trabajo común entre varias herramientas Agent
La experiencia no se convierte en reglas reutilizables

Compound Engineering Plugin quiere resolver precisamente estos problemas. Divide la programación con IA en varias etapas, para que el Agent no solo ejecute comandos, sino que participe en un proceso de ingeniería más completo.

Qué es Compound Engineering

Según la descripción del README del proyecto, Compound Engineering puede entenderse como un método de desarrollo de software asistido por IA.

Destaca un ciclo:

Planificación: entender primero el objetivo, dividir tareas y confirmar la ruta
Ejecución: modificar código según el plan, ejecutar comandos y tratar problemas
Revisión: comprobar calidad de implementación, riesgos y cobertura de pruebas
Aprendizaje: convertir la experiencia en reglas reutilizables para el futuro

Este ciclo se parece mucho a la forma de trabajo de un equipo de ingeniería real.

Un ingeniero fiable no recibe un requisito y empieza a cambiar cosas sin rumbo, ni entrega directamente después de modificar. Primero evalúa el alcance de impacto, luego implementa, después revisa riesgos y resultados de pruebas, y finalmente registra los problemas encontrados. Los AI Agent también necesitan restricciones similares.

Por qué hace falta un plugin

Un prompt puede decirle a la IA “planifica antes de ejecutar”, pero el prompt por sí mismo no siempre es estable.

Cuando la conversación se alarga y el contexto se vuelve complejo, el modelo puede saltarse la planificación, ignorar reglas o volverse demasiado confiado para terminar la tarea. El valor del plugin está en fijar el proceso para que distintos entornos Agent sigan un método parecido.

Este tipo de plugin suele dividir el flujo de trabajo en comandos, reglas, plantillas o subprocesos. El usuario no necesita escribir cada vez un prompt completo, sino que activa una etapa mediante una entrada fija.

Por ejemplo:

Pedir primero al Agent que genere un plan
Implementar después paso a paso según el plan
Activar review tras terminar los cambios
Volver a corregir cuando se encuentren problemas
Escribir las experiencias valiosas en memoria o reglas

Esto hace que la programación con IA se parezca más a una “colaboración controlada” que a una conversación de una sola vez.

Qué entornos Agent soporta

El README menciona que el proyecto soporta varios entornos de programación con IA, incluyendo:

Claude Code
Codex
Cursor
GitHub Copilot
Amp
Factory
Qwen Code

Este punto es importante.

Muchas herramientas de flujo de trabajo están atadas a un solo cliente; al cambiar de herramienta, las reglas dejan de reutilizarse. Compound Engineering Plugin se parece más a un método de ingeniería transversal a distintos Agent, llevando procesos similares de planificación, ejecución y revisión a varias herramientas.

Si usas varios asistentes de programación con IA al mismo tiempo, este tipo de flujo unificado gana valor. Las herramientas tienen capacidades distintas, pero las normas del proyecto, los hábitos de review y el método de división de tareas deberían ser lo más consistentes posible.

Para qué sirve la etapa de planificación

El valor de la planificación es evitar que la IA actúe demasiado pronto.

En tareas complejas, las preguntas realmente importantes suelen ser:

Qué archivos hay que modificar
Qué módulos pueden verse afectados
Cuál es el patrón existente
Si hay pruebas
Dónde están los riesgos
Si hay que leer documentación antes
Si puede dividirse en pasos más pequeños

Si el Agent no piensa primero estas preguntas y se pone a escribir código directamente, es fácil que produzca una implementación que parece terminada, pero que se aleja de la estructura del proyecto.

El plan no tiene que ser largo. Un buen plan debería ser corto, concreto y ejecutable. Su objetivo no es fabricar documentación, sino dar límites a la implementación posterior.

Qué evitar en la etapa de ejecución

Cuando la IA ejecuta tareas de código, aparecen con facilidad varios problemas:

Refactorizar código no relacionado de paso
Sobrescribir cambios existentes del usuario
Cambiar solo el happy path
Ignorar manejo de errores
No seguir el estilo existente del proyecto
No ejecutar validaciones necesarias
Probar a ciegas tras encontrar errores

Un plugin de flujo de trabajo no puede garantizar que estos problemas desaparezcan por completo, pero puede reducir su frecuencia mediante reglas y restricciones por etapa.

Por ejemplo, la etapa de ejecución puede pedir al Agent que avance paso a paso según el plan; si descubre algo fuera del alcance previsto, primero explica el riesgo; si modifica módulos compartidos, añade pruebas o al menos ejecuta validaciones relacionadas.

Esta restricción es especialmente importante en codebases grandes. Cuanto más rápido escribe código la IA, más necesita un proceso que limite su inercia.

Por qué importa la etapa de review

Muchos fallos de programación con IA no ocurren porque el código no pueda ejecutarse en absoluto, sino porque los detalles están mal:

No se tratan condiciones límite
Las actualizaciones de estado no son consistentes
El contrato de API se cambia en silencio
Las pruebas no cubren rutas clave
Los mensajes de error no son claros
No se mencionan riesgos de rendimiento o seguridad

La etapa de review cambia al Agent de “modo autor” a “modo revisor”.

El modo autor tiende a justificar su propia implementación; el modo revisor debe buscar activamente defectos, riesgos de regresión y pruebas omitidas. Separar estas dos etapas suele ser más fiable que pedir en una misma respuesta que implemente y se autoevalúe.

Para el usuario, la salida de review también es más valiosa. Ayuda a decidir rápidamente si este cambio merece integrarse o si necesita otra ronda de trabajo.

El sentido de aprendizaje y memoria

La palabra “Compound” del nombre del proyecto sugiere una idea importante: la experiencia de ingeniería debería crecer con efecto compuesto.

Si cada vez que la IA comete un error solo lo arregla en ese momento, pero la próxima vez comete el mismo error, la mejora de eficiencia es limitada. Un mejor método es conservar la experiencia útil:

Convenciones de directorios del proyecto
Métodos de diagnóstico para ciertos errores
Comandos de prueba y precauciones
Archivos generados que no deben tocarse
Preferencias de estilo de código
Patrones de implementación habituales

Estas experiencias pueden convertirse en reglas, memoria, documentación o plantillas. En tareas posteriores, el Agent lee primero ese conocimiento acumulado y luego empieza a trabajar.

Esa es la clave para que la programación con IA pase de “pregunta y respuesta puntual” a “colaboración de largo plazo”.

Escenarios adecuados

Compound Engineering Plugin es adecuado para:

Usar AI Agent para escribir código de forma continua
Modificar un mismo proyecto durante muchas rondas
Querer que la IA planifique antes de implementar
Querer que después de modificar entre automáticamente en mentalidad de review
Equipos que quieren unificar el flujo de programación con IA
Personas que usan a la vez Claude Code, Codex, Cursor y otras herramientas
Querer convertir experiencia del proyecto en reglas reutilizables

Si solo pides ocasionalmente a la IA que escriba un pequeño script, el flujo completo puede parecer pesado.

Pero si estás tratando al asistente de programación con IA como un compañero diario de desarrollo, el ciclo de planificación, ejecución, revisión y aprendizaje se vuelve claramente útil.

Diferencia frente a plantillas de prompt comunes

Las plantillas de prompt comunes suelen resolver “cómo expresar bien la tarea”.

Por ejemplo:

Piensa paso a paso
Lee primero los archivos
Mantén el estilo de código
Ejecuta pruebas
Resume los cambios

Estas indicaciones son útiles, pero siguen dependiendo de que el usuario las use correctamente cada vez.

Compound Engineering Plugin se sitúa más en la capa de flujo de trabajo. Organiza estos requisitos en un proceso repetible y lo adapta a distintas herramientas Agent. Así, no partes de cero escribiendo prompts cada vez, sino que avanzas dentro de un proceso.

En pocas palabras, una plantilla de prompt se parece a un recordatorio; un plugin de flujo de trabajo se parece a un sistema.

Precauciones al usarlo

Primero, no conviertas el proceso en una carga.

Las tareas pequeñas no siempre necesitan un plan completo y una review larga. Un buen flujo de trabajo debería ajustarse a la complejidad de la tarea: resolver rápido los problemas simples y usar el ciclo completo en problemas complejos.

Segundo, la review no sustituye a las pruebas.

Una review hecha por Agent puede encontrar muchos problemas, pero aun así puede omitir errores reales de ejecución. El juicio final depende de pruebas, type checking, resultados de build y revisión humana.

Tercero, hay que limpiar reglas de forma continua.

Acumular experiencia es importante, pero demasiadas reglas también se convierten en ruido. Reglas obsoletas, repetidas o que solo servían para una tarea puntual deberían ordenarse periódicamente.

Cuarto, consistencia entre herramientas no significa identidad total.

Claude Code, Codex, Cursor, Copilot y otras herramientas tienen capacidades e interacciones diferentes. Lo que se unifica es el método de trabajo, no necesariamente cada comando ni cada detalle de configuración.

Qué equipos pueden aprovecharlo

Si un equipo ya permite que AI Agent modifique código real, no basta con discutir “qué modelo es más fuerte”.

Debería preocuparse más por:

Si la IA entiende la tarea antes de modificar
Si respeta límites del proyecto mientras modifica
Si revisa riesgos activamente después de modificar
Si aprende de errores históricos
Si el equipo tiene una norma común de uso de Agent

Ahí está el sentido de proyectos como Compound Engineering Plugin. Llevan la programación con IA desde una habilidad personal hacia un proceso reutilizable por el equipo.

Referencia

EveryInc/compound-engineering-plugin

Una última frase

Lo que merece atención de Compound Engineering Plugin no es que añada un comando más de programación con IA, sino que organiza la programación con IA como un proceso de ingeniería que puede mejorar en ciclos.

Cuando los AI Agent empiezan a participar en proyectos reales, planificación, ejecución, revisión y acumulación de experiencia importan más que generar código una sola vez.

TradingAgents-CN: un marco multiagente de investigación de trading financiero para usuarios chinos

Fri, 01 May 2026 03:14:15 +0800

TradingAgents-CN es un marco de investigación de trading financiero multiagente orientado a usuarios chinos.

Su objetivo no es dar una respuesta simple a “qué acción comprar”, sino usar varios AI Agent para simular un equipo de análisis financiero más completo: alguien observa los fundamentales, alguien mira el análisis técnico, alguien sigue noticias y sentimiento, y alguien se encarga del riesgo y de la decisión final. Para quienes quieren estudiar LLM + Agent + análisis financiero, este tipo de proyecto es una buena puerta de entrada experimental.

Primero hay que dejar algo claro: estas herramientas son adecuadas para aprendizaje, investigación y análisis asistido, y no deben tratarse como asesoramiento real de trading. Los mercados financieros tienen riesgo, y las salidas del modelo también pueden ser erróneas, retrasadas o demasiado confiadas.

Qué problema resuelve

Un modelo de chat común también puede analizar acciones, por supuesto.

Puedes preguntar directamente: “Ayúdame a analizar si cierta empresa se puede comprar.” El modelo dará una respuesta que parece completa. Pero ese enfoque tiene varios problemas:

La cadena de análisis no es transparente
Las distintas dimensiones se mezclan con facilidad
Falta división de roles
Falta choque entre puntos de vista favorables y contrarios
Las advertencias de riesgo pueden quedarse en una formalidad
Es difícil reproducir el mismo proceso de análisis

La idea de TradingAgents-CN es dividir el análisis financiero en varios roles, dejar que distintos Agent se encarguen de distintas perspectivas y formar el resultado mediante colaboración, discusión y síntesis.

Esto se acerca más al proceso real de investigación de inversión. Un juicio de inversión normalmente no mira solo una noticia o un indicador técnico, sino que combina fundamentales de la empresa, entorno de mercado, tendencia de precios, sentimiento de capital, riesgo regulatorio y control de posición.

Qué significa análisis multiagente

Multiagente no significa simplemente dejar que varios modelos hablen por turnos.

Una práctica más valiosa es asignar responsabilidades claras a distintos Agent. Por ejemplo:

Agent de análisis de mercado: observa tendencias de mercado, cambios de precio y entorno general
Agent de análisis fundamental: observa negocio de la empresa, datos financieros y valor de largo plazo
Agent de análisis de noticias: observa anuncios, noticias, opinión pública e impacto de eventos
Agent de análisis técnico: observa tendencias, indicadores, soportes, resistencias y señales de trading
Agent de gestión de riesgo: observa volatilidad, drawdown, posición e incertidumbre
Agent de decisión: integra distintas opiniones y forma el juicio final

Esta estructura puede reducir el problema de que un único modelo “diga todas las conclusiones de una vez”.

Cuando distintos roles analizan el mismo objetivo, el sistema puede presentar juicios multidimensionales con más facilidad y también exponer discrepancias. Para quien aprende, esto suele aportar más que leer solo un resumen.

Por qué hace falta una versión china

El análisis financiero está muy ligado al entorno lingüístico.

Las fuentes de información que siguen los usuarios chinos, los hábitos del mercado, los nombres de acciones, los sistemas de negociación, el estilo de las noticias y los términos comunes son distintos de los del entorno inglés. Al usar directamente un marco en inglés, aparecen a menudo varios problemas:

Los nombres y códigos de acciones chinas no se procesan con fluidez
Se mezclan contextos de acciones A, acciones de Hong Kong y acciones estadounidenses
La comprensión de noticias financieras chinas es inestable
No es cómodo integrar fuentes de datos nacionales
El estilo de salida no encaja con los hábitos de lectura de usuarios chinos

El valor de TradingAgents-CN está en adaptar este proceso de análisis financiero multiagente al usuario chino. Hace más fácil construir, ejecutar y entender todo el flujo experimental de análisis de trading.

Para qué se puede usar

Este proyecto es más adecuado para investigación y análisis asistido que para órdenes automáticas.

Usos relativamente adecuados:

Aprender cómo colaboran los sistemas multiagente
Investigar el rendimiento de LLM en análisis financiero
Organizar información de una acción desde múltiples ángulos
Comparar diferencias entre modelos en tareas de investigación de inversión
Construir tu propio prototipo de Agent de análisis financiero
Revisar información histórica y puntos de riesgo de un activo
Practicar la división del proceso de investigación de inversión en tareas ejecutables

Si estás estudiando trading cuantitativo, ingeniería financiera, AI Agent o desarrollo de aplicaciones LLM, este tipo de proyecto puede ayudarte a entender la estructura de ingeniería detrás de un “asistente de investigación de inversión con IA”.

Para qué no es adecuado

No es adecuado tratarlo directamente como una herramienta para ganar dinero de forma segura.

Especialmente no es adecuado para:

Comprar o vender con toda la posición solo según la salida
Sustituir tu propio juicio de riesgo por la conclusión del modelo
Tratar predicciones de precio de corto plazo como resultados seguros
Ignorar costes de transacción, slippage y liquidez
Conectarlo a una cuenta real sin backtesting
Sustituir una estrategia de inversión de largo plazo por una conclusión de análisis puntual

Los LLM son buenos organizando información, generando explicaciones y simulando procesos de razonamiento, pero no poseen de forma natural una capacidad estable para predecir mercados. En los mercados financieros hay mucho ruido, eventos repentinos y juego conductual; la salida del modelo solo puede ser una referencia más.

Diferencia frente a un marco cuantitativo común

Los marcos cuantitativos tradicionales prestan más atención a datos, factores, backtesting, optimización de carteras y ejecución de trading.

Por ejemplo, puedes definir reglas de estrategia:

Ruptura de media móvil
Factor de momentum
Factor de valor
Filtro de volatilidad
Stop loss y take profit
Gestión de posición

Después usas datos históricos para hacer backtesting.

TradingAgents-CN se inclina más hacia un “marco de análisis con agentes”. Lo que le importa es cómo hacer que varios LLM Agent colaboren alrededor de una tarea financiera, cómo simular una discusión de research y cómo organizar noticias, fundamentales, análisis técnico y juicio de riesgo.

No son enfoques que se sustituyan entre sí.

Un uso más realista es: el sistema cuantitativo tradicional se encarga de reglas verificables y backtesting; el sistema de Agent se encarga de organización de información, generación de informes, comparación de opiniones y apoyo a la decisión. Que finalmente pueda entrar en trading real depende todavía de backtesting riguroso, control de riesgo y revisión humana.

Diferencia frente a preguntar directamente a ChatGPT

Preguntar directamente al modelo tiene la menor barrera de entrada, pero el proceso es muy laxo.

Preguntas una vez y responde una vez. Si cambias la forma de preguntar, la conclusión puede cambiar. Es difícil garantizar que analice siempre desde las mismas dimensiones, y también es difícil hacer que interprete de forma estable varios roles que se equilibran entre sí.

El valor de TradingAgents-CN es estructurar el flujo de análisis:

Roles más claros
Pasos más reproducibles
Fuentes de información más fáciles de organizar
Choque de opiniones más natural
Revisión de riesgo más fácil de separar
Salida más parecida al resultado de un proceso de investigación de inversión

Esto es útil para aprendizaje e investigación. Puedes observar cómo distintos Agent influyen en la conclusión final, y también sustituir modelos, ajustar prompts o modificar la división de roles para comparar cambios en los resultados.

Riesgos a vigilar al usarlo

Primero, calidad de datos.

El análisis financiero depende mucho de los datos. Si datos de mercado, reportes financieros, noticias o anuncios son incompletos o no están actualizados, por muy fluido que sea el análisis del Agent, puede estar construido sobre una base equivocada.

Segundo, alucinaciones del modelo.

Un LLM puede inventar hechos inexistentes, malinterpretar el significado de los datos o tomar información antigua como nueva. Cuando se trata de acciones concretas, hay que volver a la fuente de datos para verificar.

Tercero, sobreexplicación.

El modelo es muy bueno dando explicaciones “que parecen razonables”, pero los cambios de precio del mercado no necesariamente vienen de las razones que enumera. No confundas explicación posterior con prueba causal.

Cuarto, brecha entre backtesting y trading real.

Incluso si una estrategia se comporta bien con datos históricos, en trading real seguirá enfrentándose a slippage, comisiones, liquidez, suspensiones, límites de subida/bajada y mercados extremos.

Quinto, licencia y límites comerciales.

El README menciona que el proyecto usa una licencia mixta. Las condiciones para aprendizaje personal, investigación y uso comercial pueden ser distintas. Si planeas incorporarlo en un producto o servicio comercial, primero lee con cuidado la licencia del proyecto.

A quién le conviene estudiarlo

TradingAgents-CN es adecuado para:

Desarrolladores que quieren aprender arquitectura de AI Agent
Personas que quieren estudiar la capacidad de LLM en análisis financiero
Usuarios de trading cuantitativo que quieren incorporar análisis de lenguaje natural
Equipos que quieren construir herramientas auxiliares de investigación de inversión
Personas interesadas en cómo la colaboración multirol afecta decisiones
Usuarios que quieren experimentar con trading Agent en entorno chino

Si tu objetivo es obtener una simple sugerencia de compra o venta, este proyecto quizá no sea la mejor forma de abrirlo. Lo que más merece atención es el proceso, los roles, la colaboración y el control de riesgo, no la conclusión de una salida puntual.

Cómo puede ampliarse

Este tipo de marco tiene muchas direcciones de expansión:

Integrar más fuentes de datos fiables
Añadir soporte para modelos locales
Añadir módulo de backtesting
Afinar reglas distintas para acciones A, Hong Kong y Estados Unidos
Añadir Agent de análisis sectorial
Añadir gestión de cartera y control de posición
Reforzar citas de informes y trazabilidad de datos
Combinar conclusiones de Agent con señales cuantitativas tradicionales

Un sistema financiero de IA realmente valioso normalmente no deja que el modelo decida todo por sí solo, sino que lo inserta en un proceso verificable, trazable y controlado por riesgo.

Referencia

hsliuping/TradingAgents-CN

Una última frase

Lo que merece atención de TradingAgents-CN no es si puede predecir la siguiente vela K, sino que divide el análisis financiero en un proceso de colaboración multiagente.

Tratarlo como herramienta de aprendizaje e investigación es más razonable que tratarlo como una máquina automática de ganar dinero.

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.

Dominio de los ganchos de Claude Code: una introducción a los 13 eventos del ciclo de vida de los ganchos y al control de automatización

Fri, 01 May 2026 03:11:27 +0800

claude-code-hooks-mastery es un proyecto de aprendizaje centrado en Claude Code Hooks.

No es sólo una colección de guiones dispersos. Explica el ciclo de vida del gancho de Claude Code, los métodos de configuración, los patrones de script y los escenarios de automatización comunes en un solo lugar. Para las personas que quieren que Claude Code sea más controlable y más parecido a un asistente de ingeniería, vale la pena leer este tipo de material.

Claude Code ya puede leer código, editar archivos y ejecutar comandos de forma predeterminada. Pero si desea que verifique permisos automáticamente, bloquee operaciones riesgosas, inyecte reglas de proyecto, ejecute pruebas o le recuerde las convenciones del equipo en momentos específicos, las instrucciones de chat por sí solas no son lo suficientemente estables. El valor de los ganchos es que convierten las “reglas que necesito recordarle a la IA cada vez” en un flujo de trabajo ejecutable.

Qué problemas resuelven los ganchos

Después de usar Claude Code por un tiempo, los puntos débiles comunes incluyen:

Cada nueva sesión necesita repetir las mismas reglas del proyecto.
Te preocupa que pueda ejecutar comandos que no debería ejecutar.
Quieres verificaciones antes y después de la edición de archivos.
Quiere formatear, realizar pruebas o realizar análisis de seguridad antes de confirmar
Quieres que las convenciones del equipo sean un flujo de trabajo fijo en lugar de recordatorios verbales.
Quiere contexto antes y después de las llamadas a herramientas para iniciar sesión o bloquear
Quiere que tareas complejas activen subagentes o scripts dedicados

Los ganchos están diseñados para estas “acciones automáticas en momentos fijos”.

Puedes considerarlos como enlaces de eventos en el flujo de trabajo de Claude Code. Cuando se inicia una sesión, un usuario envía un mensaje, el modelo está a punto de llamar a una herramienta, finaliza una llamada a una herramienta o un agente está a punto de detenerse, Claude Code puede ejecutar los scripts que usted configuró.

Los 13 eventos del ciclo de vida del gancho

Uno de los puntos principales del proyecto README es que cubre sistemáticamente los 13 eventos de gancho del Código Claude.

Estos eventos abarcan varias etapas, desde el inicio de la sesión hasta las llamadas a las herramientas, y desde la entrada del usuario hasta la terminación del agente. Por finalidad, se pueden agrupar a grandes rasgos como:

Inicio de sesión: inicializa el entorno e inyecta el contexto del proyecto.
Entrada del usuario: inspeccionar indicaciones, agregar reglas y realizar auditorías
Antes de las llamadas a la herramienta: comprobaciones de permisos, bloqueo de comandos y validación de seguridad.
Después de las llamadas a la herramienta: registrar resultados, activar el formateo y ejecutar la verificación
Finalización de tareas: resumir, limpiar, notificar o guardar estado

Este diseño de ciclo de vida significa que no es necesario incluir todas las reglas en un mensaje muy largo.

Por ejemplo, el control de permisos debe realizarse antes de las llamadas a la herramienta. Las comprobaciones de formato son mejores después de editar los archivos. La inyección de reglas del proyecto es mejor al inicio de la sesión o después de la entrada del usuario. Poner reglas en el punto de enlace correcto suele ser más confiable que meter todo en un indicador del sistema.

Dónde vive la configuración

Los ganchos de Claude Code generalmente se configuran a través de archivos de configuración.

Las ubicaciones comunes incluyen:

Configuración a nivel de usuario: ~/.claude/settings.json
Configuración a nivel de proyecto: .claude/settings.json

La configuración a nivel de usuario es buena para las preferencias personales, como reglas generales de seguridad, bloqueo de comandos y rutas de registro.

La configuración a nivel de proyecto es mejor para reglas específicas del repositorio, como qué pruebas se deben ejecutar, qué directorios no se pueden editar, cómo se manejan los archivos generados y qué comprobaciones se requieren antes de la confirmación. Si usa Claude Code en un equipo, es mejor colocar la configuración a nivel de proyecto en el repositorio. De esa manera, todos inician el proyecto con las mismas limitaciones de colaboración de IA en lugar de depender de la memoria personal.

Por qué son importantes los scripts de un solo archivo

El proyecto enfatiza los scripts de un solo archivo “UV”.

El beneficio es una implementación simple. Un único archivo Python puede declarar dependencias y ejecutarse sin mantener un entorno complejo para un enlace. Esto encaja bien con los ganchos porque muchos ganchos solo hacen una pequeña cosa:

Comprobar si un comando está permitido
Determinar si la ruta de un archivo es segura
Leer las reglas del proyecto y devolvérselas a Claude.
Escanear la salida en busca de información confidencial
Ejecutar formateo o pruebas después de las ediciones.
Escribir eventos en registros.

Cuanto más pequeño sea un script de enlace, más fácil será de mantener y es menos probable que se convierta en un sistema nuevo y complicado.

¿Qué pueden hacer los ganchos con la automatización?

claude-code-hooks-mastery muestra muchas direcciones. En el trabajo real, los más comunes se encuentran a continuación.

1. Control de permisos y seguridad

Este es el uso más directo de los ganchos.

Antes de que Claude Code ejecute un comando, un gancho puede inspeccionar el contenido del comando. Si contiene acciones de alto riesgo, como eliminar, restablecer, limpiar o sobrescribir, puede bloquear la ejecución o requerir confirmación manual.

Se pueden aplicar reglas similares a las rutas de archivos:

No modificar la configuración de producción.
No escribir en archivos secretos
No eliminar scripts de migración
No tocar directorios específicos
No ejecute comandos de red no aprobados

Anteponer esta protección a las llamadas a herramientas es más confiable que escribir “no realizar operaciones peligrosas” en un mensaje.

2. Inyección de contexto

Muchos proyectos tienen información de fondo fija:

Pila de tecnología
Convenciones de codificación
Comandos de prueba
Estrategia de ramificación
Estructura del directorio
Acciones prohibidas
Reglas para archivos generados.

Decirle esto a Claude Code manualmente cada vez es molesto y fácil de olvidar. Los ganchos pueden inyectar automáticamente el contexto necesario al inicio de la sesión o después de que el usuario envía un mensaje.

Esto es como darle a Claude Code un manual de trabajo a nivel de proyecto. No reemplaza el README ni la documentación de desarrollo, pero ayuda a la IA a ingresar al estado correcto antes de ejecutar una tarea.

3. Verificación después de las ediciones

Después de que Claude Code modifica archivos, los ganchos pueden activar comprobaciones automáticamente.

Las acciones comunes incluyen:

Ejecutar formateo
Ejecutar pelusa
Ejecutar pruebas unitarias.
Verificar errores de tipo
Escanear archivos generados
Validar formato Markdown o JSON

Esto ayuda a reducir los errores de bajo nivel. Cuando la IA edita varios archivos, una verificación ligera después de la modificación puede revelar problemas antes.

Sin embargo, los ganchos no deberían ejecutar tareas pesadas de forma predeterminada. Ejecutar el conjunto de pruebas completo después de cada cambio de archivo puede ralentizar la experiencia. Un mejor enfoque es elegir comprobaciones según el tipo de archivo, el directorio y el riesgo de la tarea.

4. Validación de las reglas del equipo

Si un equipo ya tiene convenciones claras, algunas de ellas pueden colocarse en ganchos.

Por ejemplo:

Confirmar formato de mensaje
Reglas de estilo de código
No editar directamente ciertos archivos generados
La documentación debe actualizarse en conjunto.
Los cambios de API deben actualizar las pruebas.
Ciertos directorios sólo pueden ser generados por herramientas específicas Esto hace que Claude Code se parezca más a una parte del flujo de trabajo del equipo que a un asistente externo sin restricciones.

Por supuesto, los ganchos no deberían reemplazar a la CI. Son mejores para recordatorios locales y bloqueo temprano. La validación final aún debe pertenecer a los sistemas de CI, revisión y prueba.

5. Subagentes y tareas dedicadas

El archivo README también menciona contenido relacionado con subagentes.

Este tipo de uso es adecuado para enviar tareas complejas a flujos de trabajo más especializados. Por ejemplo, la conversación principal puede comprender el requisito, mientras que un enlace o una configuración desencadenan tareas dedicadas de verificación, auditoría, resumen o documentación.

Para los usuarios individuales, el primer paso útil no es la compleja orquestación de agentes. Es mejor entregar primero a los ganchos acciones repetitivas, claras y de bajo riesgo. Una vez que las reglas se estabilicen, puede producirse una automatización más compleja.

Línea de estado y estilos de salida

El proyecto también cubre la línea de estado y los estilos de salida.

Esto puede parecer un pequeño detalle de la experiencia, pero es importante para el uso a largo plazo del Código Claude. Una línea de estado puede mostrar el contexto actual, el estado de la tarea, información del entorno o sugerencias. Los estilos de salida pueden hacer que las respuestas de Claude Code se ajusten mejor a sus hábitos de trabajo.

Si colaboras con IA en el mismo terminal todos los días, estos detalles afectan la eficiencia. Las buenas sugerencias de estado reducen los errores y le ayudan a determinar rápidamente si la sesión actual se encuentra en el proyecto, rama y entorno correctos.

No hagas que los ganchos sean demasiado pesados

Los ganchos son poderosos, pero no son el lugar para poner todo.

Las buenas reglas son:

Las acciones de alta frecuencia deben ser rápidas.
El bloqueo de seguridad debe ser claro.
La salida debe ser corta.
Los motivos del fallo deben ser legibles.
Los scripts deben tener una única responsabilidad.
Las comprobaciones exhaustivas deben ser comandos explícitos o tareas de CI

Si un enlace tarda más de diez segundos cada vez, los usuarios pronto querrán desactivarlo. Si un gancho tiene reglas de bloqueo vagas, tanto Claude Code como el usuario tendrán dificultades para entender qué hacer a continuación.

Los ganchos son mejores para tareas con límites claros: permitir o rechazar, agregar contexto, registrar eventos, ejecutar comprobaciones ligeras y sugerir el siguiente paso.

¿Quién debería usarlo?

Si solo ocasionalmente le pides a Claude Code que edite un pequeño fragmento de código, es posible que aún no necesites estudiar los ganchos en profundidad.

Pero este proyecto es útil si:

Utilice Claude Code con frecuencia
A menudo deja que la IA modifique el código del proyecto real.
Preocupación por que la IA ejecute comandos peligrosos
Quiere inyectar automáticamente reglas de equipo en los flujos de trabajo de IA
Quiere que las comprobaciones se ejecuten automáticamente después de las ediciones
Quiere convertir recordatorios repetidos en configuración
Están creando un flujo de trabajo de codificación de IA más estable.

Los ganchos son especialmente significativos en proyectos colaborativos. Pueden convertir parte de la experiencia del equipo en guiones en lugar de depender de que cada persona se lo recuerde a la IA manualmente.

Notas de uso

Primero, comience con los ganchos de seguridad.

En comparación con la automatización compleja, el bloqueo de comandos, la protección de rutas y las comprobaciones de archivos confidenciales son más fáciles de implementar y reducen el riesgo de inmediato.

En segundo lugar, comprometa cuidadosamente las reglas a nivel de proyecto.

.claude/settings.json afecta a todos los que usan el repositorio. Antes de comprometer reglas, asegúrese de que no restrinjan demasiado el desarrollo normal ni dependan de rutas que solo existen en su máquina.

En tercer lugar, mantenga la salida del gancho concisa. Claude Code consume esta salida. Si es demasiado largo, contamina el contexto. Si es demasiado vago, no guía el siguiente paso. Lo mejor es devolver sólo el juicio necesario y la siguiente recomendación.

Cuarto, mantenga los ganchos depurables.

Cuando los ganchos aumentan en número, los problemas pueden provenir de la configuración, los scripts, los permisos, las rutas, las dependencias o el propio Claude Code. Los registros claros facilitan mucho la depuración posterior.

Referencia

disler/claude-code-hooks-mastery

Pensamiento final

El valor de “Claude Code Hooks” es convertir “reglas que espero que la IA recuerde siempre” en flujos de trabajo que realmente se ejecutan.

Si ya utiliza Claude Code en proyectos reales, los ganchos son un paso clave desde “un asistente de codificación que puede conversar” hasta “un colaborador de ingeniería limitado”.

Claude-Mem: Agregar memoria a largo plazo entre sesiones al código Claude

Fri, 01 May 2026 03:01:02 +0800

Claude-Mem es un sistema de memoria persistente para Claude Code.

Intenta resolver un problema muy específico: cada vez que un asistente de codificación de IA inicia una nueva sesión, a menudo olvida decisiones de arquitectura anteriores, obstáculos pasados, preferencias de proyecto y contexto de implementación.
Si un proyecto dura mucho tiempo, explicar repetidamente los mismos antecedentes se convierte en una pérdida de tiempo.

La idea detrás de Claude-Mem es comprimir las conversaciones de Claude Code en recuerdos, almacenarlas en una base de datos local y en un almacén de vectores, y luego recuperarlas a través de una herramienta de búsqueda.

¿Qué problema resuelve?

Claude Code es bueno en tareas de código, pero el contexto de la sesión aún es limitado.

Los puntos débiles comunes incluyen:

Una nueva sesión no sabe lo que hicieron las sesiones anteriores.
Las decisiones de diseño del proyecto deben explicarse repetidamente.
Los problemas que ya fueron depurados son fáciles de repetir
Las tareas de larga duración carecen de continuidad.
El conocimiento del proyecto es difícil de acumular a través de conversaciones.

Claude-Mem está diseñado en torno a estos problemas.

No se trata simplemente de guardar registros de chat. En cambio, comprime las conversaciones en fragmentos de memoria que son más fáciles de recuperar. Cuando sea necesario más adelante, la búsqueda semántica puede recuperar el contexto relevante.

Cómo funciona

Según el diseño README, “Claude-Mem” consta principalmente de varias partes.

La primera parte son los ganchos.

Se integra con el flujo de sesión de Claude Code y captura datos de la conversación en el momento adecuado.

La segunda parte es un trabajador en segundo plano.

El trabajador procesa el contenido de la conversación en bruto y lo convierte en recuerdos más breves y fáciles de buscar.

La tercera parte es el almacenamiento local.

El proyecto utiliza SQLite para metadatos estructurados y Chroma para indexación de vectores. Esto preserva la información básica de la sesión al tiempo que admite la recuperación semántica.

La cuarta parte es “mem-search”.

Este es el punto de entrada de consulta para Claude Code. Cuando se necesita un contexto antiguo, se pueden buscar recuerdos relevantes a través de esta herramienta.

El flujo general se puede entender así:

Las sesiones de Claude Code generan contenido
Los ganchos capturan datos de la sesión
El trabajador lo comprime y organiza de forma asincrónica.
Los recuerdos se escriben en SQLite y Chroma.
Las sesiones posteriores los recuperan mediante mem-search

¿Cuándo es útil?

Claude-Mem es adecuado para proyectos de larga duración, no para tareas pequeñas y puntuales.

Por ejemplo:

Un repositorio se desarrolla durante muchos días.
La estructura del código es compleja y tiene muchos antecedentes.
Es necesario recordar las convenciones del proyecto, los hábitos de nomenclatura y las elecciones de arquitectura.
Claude Code se utiliza a menudo para corregir errores, funciones y documentación.
Quieres que la IA recuerde por qué se cambió algo antes

Si solo le pide a Claude Code que haga un cambio de una línea, la memoria a largo plazo no es muy significativa.
Pero si tratas a Claude Code como un colaborador a largo plazo, resulta útil.

Instalación y puesta en marcha

El README proporciona un flujo de instalación directo:

1
2

npm install -g claude-mem
claude-mem install

Empiece con:

`1`	`claude-mem start`

Verificar estado:

`1`	`claude-mem status`

Deténgalo cuando sea necesario:

`1`	`claude-mem stop`

El objetivo detrás de estos comandos es conectar el sistema de memoria como un servicio local de larga duración al flujo de trabajo de Claude Code.

Cómo utilizar `mem-search`

mem-search es el punto de entrada clave para recuperar la memoria.

No pretende reemplazar la búsqueda ordinaria. Permite a Claude Code consultar conversaciones pasadas por significado.

Por ejemplo, Claude Code puede buscar:

Por qué un módulo fue diseñado de cierta manera
Cómo se depuró un error anteriormente
Reglas de nomenclatura acordadas en el proyecto.
Compensaciones técnicas discutidas anteriormente
El trasfondo detrás de una refactorización.

Esto es diferente de la simple búsqueda de palabras clave.
Si la compresión de memoria y la indexación de vectores funcionan bien, puede recuperar contenido semánticamente relacionado incluso si no recuerda la redacción exacta.

¿En qué se diferencia de la documentación del proyecto?

La documentación del proyecto es buena para sacar conclusiones estables.

Por ejemplo:

Notas de arquitectura
Procedimientos de implementación
Convenciones API
Estructura de la base de datos
Reglas de desarrollo

Claude-Mem es mejor para el contexto creado durante las conversaciones.

Por ejemplo:

Por qué se rechazó un plan
Cómo se solucionó un problema temporal
La discusión detrás de una implementación.
Las preferencias del proyecto aún no están escritas en los documentos.
Antecedentes de tareas acumulados en múltiples conversaciones

Los dos no se reemplazan el uno al otro.
Un buen flujo de trabajo es escribir conocimientos estables en los documentos del proyecto y utilizar el sistema de memoria para ayudar a recuperar el contexto conversacional.

Cosas a tener en cuenta

En primer lugar, una mayor memoria a largo plazo no siempre es mejor.

Si cada conversación se guarda sin distinción, la recuperación posterior puede resultar ruidosa. Los recuerdos más valiosos son las decisiones del proyecto, los antecedentes de la implementación, el historial de depuración y las preferencias a largo plazo.

En segundo lugar, la memoria no puede reemplazar el código y la documentación.

El contexto antiguo encontrado por la IA es sólo una referencia. El juicio final aún depende del código actual, los resultados de las pruebas y los requisitos más recientes.

En tercer lugar, preste atención a la privacidad y los datos locales.

Dado que almacena el contenido de la conversación, debes saber qué proyectos son adecuados para él y qué información confidencial no debe entrar en la conversación.

Cuarto, los sistemas de memoria necesitan mantenimiento.

A medida que avanza un proyecto, los viejos recuerdos pueden quedar obsoletos. Si el contexto obsoleto se reutiliza incorrectamente, puede inducir a error en tareas posteriores.

Por qué es importante este tipo de herramienta

Las herramientas de codificación de IA están pasando de preguntas y respuestas únicas a una colaboración a largo plazo.

En preguntas y respuestas únicas, el modelo solo necesita responder la pregunta actual.
En una colaboración a largo plazo, es necesario conocer el historial del proyecto, las decisiones anteriores, las preferencias del equipo y los obstáculos que ya se han encontrado.

Aquí es donde importan herramientas como Claude-Mem: convierten el “recordar el contexto” de una capacidad de chat temporal en un sistema local que puede instalarse, ejecutarse y buscarse.

Para proyectos de ingeniería reales, esto es más práctico que simplemente alargar la ventana de contexto del modelo.
No es necesario contextualizar mucha información de una sola vez; es necesario recuperarlo en el momento adecuado.

¿Quién debería intentarlo?

Quizás quieras probarlo si:

Usas Claude Code con frecuencia
A menudo trabajas en el mismo proyecto durante varios días.
El contexto del proyecto es complejo.
Explicas repetidamente los mismos antecedentes a la IA.
Quieres preservar la experiencia de las conversaciones.

Si solo usas Claude Code ocasionalmente, o el proyecto es pequeño, es posible que aún no necesites este tipo de sistema.

Referencia

thedotmack/claude-mem

Pensamiento final

El objetivo de Claude-Mem no es “guardar registros de chat”. Ayuda a Claude Code a recuperar contexto útil en tareas posteriores. A medida que la codificación de IA pase de tareas únicas a colaboraciones en proyectos de larga duración, los sistemas de memoria serán cada vez más importantes.
No pueden reemplazar la documentación y las pruebas, pero pueden reducir las explicaciones repetidas y hacer que la IA se sienta más como un asistente que comprende el historial del proyecto.

Claude.md no es mejor cuando es más largo: cómo escribir archivos de memoria global para codificación AI

Wed, 29 Apr 2026 21:07:37 +0800

Recientemente vi una discusión sobre archivos de memoria global para codificación de IA: después de que los proyectos agregan archivos como Claude.md o AGENTS.md, los resultados no necesariamente mejoran. En algunos casos, las tasas de éxito pueden incluso disminuir mientras que el costo del razonamiento aumenta.

Al principio, esto parece contradictorio. Generalmente asumimos que si le damos a la IA más antecedentes del proyecto, más reglas y más explicaciones, debería escribir el código con mayor precisión.
El verdadero problema es que Claude.md no es un documento ordinario. Es un archivo de memoria global que se inyecta en el contexto de cada conversación. Cuanto más contiene, más tiene que leer el modelo cada vez; cuanto más vago sea, más juicio tendrá que hacer el modelo; y si contiene flujos de trabajo que no siempre deberían ejecutarse, el modelo puede desencadenar acciones innecesarias en tareas no relacionadas.

Entonces, la parte difícil de escribir Claude.md es no completarlo. Se trata de decidir qué piezas de información merecen ocupar contexto de forma permanente.

¿Qué es Claude.md?

En las herramientas de codificación de IA, archivos como Claude.md y AGENTS.md son esencialmente archivos de memoria global.

La conversación normal entra en el contexto, pero la longitud del contexto es limitada. Una vez que la conversación se vuelve larga, el contenido histórico se comprime y se pierden algunos detalles. Un archivo de memoria global fija reglas importantes para que el modelo pueda verlas al comienzo de cada tarea.

Esto significa dos cosas:

El contenido escrito allí es más difícil de olvidar.
El contenido escrito allí también cuesta algo en cada tarea.

No es como un README que se lee sólo cuando es necesario. Se parece más a un conjunto de limitaciones laborales de larga duración. Una vez que algo se coloca allí, afecta el juicio del modelo por defecto.

Por lo tanto, Claude.md no es una introducción al proyecto, ni una colección de consejos, ni un lugar para deshacerse de cada proceso de desarrollo. Sólo debe almacenar reglas que el modelo probablemente viole repetidamente si no las conoce.

Por qué puede empeorar las cosas

Un archivo de memoria global mal escrito suele provocar tres tipos de problemas.

Primero, consume contexto.

Si Claude.md tiene mil líneas, esas líneas permanecen en el contexto del modelo durante mucho tiempo. Es posible que se reduzcan el código, los mensajes de error y los requisitos que realmente son relevantes para la tarea actual. El contexto no es espacio libre. Cuanto más grande sea el archivo de reglas globales, más fácil será diluir la tarea actual.

En segundo lugar, puede desencadenar comportamientos innecesarios.

Por ejemplo, un archivo global podría decir:

1
2

Before every task, fully read the project directory.
After every change, run a complete end-to-end test.

Estas líneas parecen responsables, pero en un archivo de memoria global se convierten en “hacer esto para cada tarea”. Incluso si la tarea consiste solo en cambiar una línea de copia, el modelo puede realizar exploraciones y pruebas innecesarias debido a estas reglas. El resultado es un trabajo más lento, un costo más alto y, a veces, más interferencia.

En tercer lugar, aumenta la carga del juicio.

Declaraciones como “mantener el código elegante, conciso, mantenible y extensible” suenan correctas, pero son restricciones débiles. Cada vez que el modelo genera código, tiene que decidir qué significa elegante o extensible, sin recibir un límite claro.

Un mejor enfoque es escribir prohibiciones o contraejemplos concretos en lugar de virtudes abstractas. Por ejemplo:

1
2
3

Do not add a generic abstraction for a single call site.
Do not change shared parsing logic without test coverage.
Do not put temporary scripts in the application source directory.

Estas reglas son más específicas y más fáciles de seguir.

¿Qué debería entrar?

Puedes usar un estándar simple para decidir si algo pertenece a Claude.md:

Si la IA comete repetidamente el mismo error sin ella, entonces vale la pena anotarlo.

El contenido adecuado para un archivo de memoria global suele tener estas características:

Es duradero
Está fuertemente ligado al repositorio actual.
No se puede inferir naturalmente de la estructura del código.
Cambia claramente el comportamiento del modelo.
Es preferiblemente una restricción, prohibición, regla de ruta o comando fijo.

Por ejemplo:

For all Hugo posts, only edit index.zh-cn.md and do not automatically generate other language versions.
Article front matter must include title/date/draft/tags/categories/slug/description.
Do not modify generated artifacts under public/.
On PowerShell, use scripts/deploy.ps1 for deployment.

Estas no son sugerencias vagas. Están vinculados a cómo funciona realmente el repositorio. Si el modelo no los conoce puede cometer errores; una vez que los conoce, puede evitar verdaderos errores.

¿Qué debería quedar fuera?

Mucha gente convierte Claude.md en un manual de proyecto. Esto suele ser innecesario.

El contenido que generalmente no pertenece allí incluye:

Visión y antecedentes del proyecto.
Descripciones de estructuras de directorios grandes.
Planes de tareas temporales
Pasos únicos de depuración
Lemas de calidad de código abstracto.
Flujos de trabajo largos que solo son necesarios en algunas situaciones.

Por ejemplo, una descripción como “este es un proyecto de comercio electrónico con módulos de producto, pedido y usuario” ayuda muy poco con una tarea de codificación concreta. Durante el desarrollo real, el modelo debe depender de los requisitos, especificaciones, estructura del código y pruebas actuales, no de una introducción aproximada del proyecto en la memoria global.

Lo mismo se aplica a la estructura de directorios. A menos que un directorio tenga una convención especial, como “los componentes compartidos deben importarse desde este directorio”, no es necesario escribir el árbol completo en el archivo. El modelo puede leer el directorio del proyecto. Es fácil que una descripción de directorio estática quede obsoleta.

Los flujos de trabajo pertenecen a habilidades o comandos

Si una sección dice “primero haz esto, luego aquello y luego haz la tercera cosa”, es posible que no pertenezca a Claude.md.

Los flujos de trabajo de larga duración se pueden convertir en habilidades, scripts o comandos. El beneficio es que la memoria global solo necesita conservar el nombre y la condición de activación, mientras que los pasos detallados se cargan solo cuando es necesario.

Por ejemplo:

1
2

When the user asks to translate a Hugo post, use the post-translate skill.
When the user asks to deploy the site, run the hugo-rsync-deploy workflow.

Esto es más liviano que poner los procesos completos de traducción e implementación en Claude.md. La memoria global sigue siendo corta y los flujos de trabajo detallados se encuentran en herramientas activables.

El nuevo flujo de inicialización de Claude también avanza en esta dirección. No solo genera un Claude.md; también intenta dividir los flujos de trabajo reutilizables en habilidades y los eventos fijos en ganchos. La idea subyacente es clara: la memoria global debería ser un punto de entrada, mientras que los detalles deberían cargarse según demanda.

Claude.md necesita iteración

Claude.md no debe escribirse una vez y luego ignorarse.

Un mejor enfoque es ser breve al principio y dejar que las tareas reales expongan los problemas. Si ocurre un error una vez, manéjelo manualmente. Si el mismo tipo de error aparece dos o más veces, puede merecer convertirse en una regla global.

Este tipo de iteración es más útil que escribir un enorme conjunto de reglas al principio. Al principio, no sabes qué reglas son realmente útiles o qué líneas se convertirán en ruido. A medida que el proyecto crece, la colaboración aumenta y el comportamiento del modelo se vuelve más claro, puede agregar gradualmente problemas de alta frecuencia.

También hay una tendencia importante: cuanto más fuerte sea el modelo, más corto debería ser el archivo de memoria global. Muchos requisitos que alguna vez tuvieron que escribirse en indicaciones ahora son manejados naturalmente por el modelo. Continuar poniendo esos requisitos básicos en Claude.md solo aumenta la carga de contexto. La memoria global debería reducirse a medida que mejora la capacidad del modelo, manteniendo solo lo que es exclusivo de este repositorio y no se puede inferir automáticamente.

Una forma más práctica de escribirlo

Al escribir Claude.md, piense en este orden:

¿Qué convenciones especiales tiene este repositorio?
¿Qué errores ha cometido el modelo más de una vez?
¿Qué directorios, archivos o comandos nunca deben usarse indebidamente?
¿Qué flujos de trabajo deberían convertirse en habilidades, guiones o comandos en lugar de un contexto permanente?
¿Qué partes son meras introducciones y pueden eliminarse?

El archivo final puede tener sólo unas pocas docenas de líneas. No es necesario explicar completamente el proyecto. Necesita limitar el comportamiento con precisión.

Un buen Claude.md podría verse así:

# Working Rules

- Only edit files related to the current task.
- Do not modify generated artifact directories such as public/ or resources/.
- Hugo post rewrites only process index.zh-cn.md and do not generate other language versions.
- If deployment is involved, run the Hugo build first, then execute the existing rsync script.
- When there are existing user changes, do not revert them. Continue from the current state.

Es breve, pero cada línea afecta el comportamiento real. Ese es el tipo de contenido que vale la pena mantener en contexto permanentemente.

Pensamiento final

El valor de Claude.md no es hacer que la IA “sepa más”. Se trata de hacer que la IA “evite errores corregidos”.

No es una base de conocimientos ni una enciclopedia de proyectos. Es un archivo de restricciones de larga duración para la codificación AI.
Cuanto más específico, breve y cercano a los errores reales sea, más útil será. Cuanto más genérica, más larga y más parecida a una introducción de proyecto sea, más probable será que ralentice el modelo o incluso empeore los resultados.

Trate la memoria global como un recurso escaso, no como un bloc de notas ilimitado. Ese puede ser el principio más importante para escribir un buen Claude.md.

Codex está empezando a controlar la computadora. ¿Qué significa eso para el futuro?

Wed, 29 Apr 2026 11:28:25 +0800

La parte más importante de esta actualización del Codex no es que agregó otro botón común y corriente. Es que el Codex está empezando a avanzar hacia “controlar la computadora”.

En el pasado, usar IA generalmente significaba hacer preguntas en un cuadro de chat, copiar, pegar y luego operar manualmente el software.
Ahora ese límite se está ampliando: la IA no solo te responde. Puede operar aplicaciones de escritorio según su objetivo.

A corto plazo, esta es una característica nueva. A largo plazo, puede cambiar la cantidad de personas que usan computadoras.

¿Qué es esta característica?

En pocas palabras, la capacidad de uso de computadoras de Codex le permite acceder y operar el entorno de escritorio.

Puede hacer cosas como:

seleccionar y controlar una aplicación
recibir tareas en lenguaje natural
abrir navegadores, herramientas de inteligencia artificial, archivos locales u otro software
ingrese texto, haga clic en botones y espere resultados
conectar varios pasos en una tarea
seguir ejecutándose en segundo plano sin necesidad de que el usuario siga cada paso manualmente

Su función no es solo escribir un texto para usted, sino también completar un flujo de operación para usted.

Esa es la diferencia clave entre un Agente y un chatbot común y corriente:
un chatbot da principalmente respuestas; un Agente está más cerca de “recibir un objetivo y luego ejecutarlo”.

Por qué esto es importante

En el pasado, gran parte de la automatización requería que supieras escribir guiones.

Por ejemplo, supongamos que desea completar un flujo de trabajo entre software:

abrir una página web
encontrar información
copiar contenido
pásalo a otra herramienta de IA
guardar un archivo
abre el directorio local y comprueba el resultado

Para automatizar esto de forma tradicional, es posible que necesite scripts de navegador, API, programas locales e incluso automatización de ventanas.

Pero muchos usuarios comunes y corrientes no saben cómo escribir estas cosas.
Incluso si lo hacen, puede que no valga la pena escribir un guión para una tarea temporal.

Aquí es donde importa el uso de la computadora: empuja la “capacidad similar a un script” hacia el lenguaje natural.

No es necesario que le diga exactamente dónde hacer clic.
Puede decirle qué resultado desea y dejar que intente completar la tarea.

Flujos de trabajo que pueden cambiar

Creo que los primeros flujos de trabajo que cambiarán no serán trabajos extremadamente serios o de alto riesgo, sino tareas molestas, fragmentadas, repetitivas y para las que no vale la pena escribir un programa dedicado.

1. Mover información a través del software

El caso más típico es el de mover información entre aplicaciones.

Anteriormente, podía alternar entre un navegador, un documento, una ventana de chat y una carpeta local.
En el futuro, podrás encargar este tipo de tarea a un Agente:

encontrar cierto tipo de información
resumirlo en un documento
guárdelo en un directorio específico
abre el resultado para que lo revises

Este trabajo no es difícil, pero requiere atención.
El valor de un Agente es que absorbe estas pequeñas operaciones.

2. Coordinación entre múltiples herramientas de IA

El flujo de trabajo real de muchas personas ya no se basa en una única herramienta de inteligencia artificial.

Puede verse así:

una herramienta escribe código
una herramienta busca información
una herramienta genera imágenes
una herramienta organiza documentos

Anteriormente, estas herramientas se conectaban mediante copiar y pegar manualmente.
En el futuro, un Agente puede convertirse en la capa intermedia: abre herramientas, pasa contexto, espera resultados y organiza resultados. Esto puede convertir “múltiples herramientas de IA trabajando juntas” de un proceso manual a un proceso semiautomático.

3. Automatización del software de oficina

Las hojas de cálculo, las presentaciones, los documentos y el correo electrónico comparten una característica: son potentes, pero muchas operaciones están fragmentadas.

Si los agentes pueden controlar este software de forma fiable, la barrera a la automatización de oficinas disminuirá notablemente.

No es necesario recordar dónde está un menú ni aprender atajos complicados.
Solo necesitas describir el objetivo, como por ejemplo:

convierta esta hoja de cálculo en un informe mensual
hacer un resumen de una página de este documento
combinar estos materiales en una explicación claramente estructurada

Las tediosas operaciones de los botones quedarán gradualmente ocultas detrás del lenguaje natural.

Qué significa para los usuarios comunes

Para los usuarios comunes, este tipo de característica puede tener un impacto más directo que “el modelo se volvió un poco más inteligente”.

Porque reduce la barrera operativa, no sólo la barrera del conocimiento.

Muchas personas pueden describir lo que quieren, pero no saben dónde hacer clic o cómo combinar funciones dentro del software.
Si los Agentes pueden hacerse cargo de esta parte, el uso de una computadora puede convertirse en:

1
2
3

I describe the goal
Agent operates the software
I check the result

Esto está más cerca de la productividad real que un simple chat.

Su impacto en el software

Si este tipo de capacidad del Agente continúa madurando, el software en sí también se verá afectado.

En el pasado, el diseño de software se basaba principalmente en el clic humano.
En el futuro, es posible que también sea necesario que el software sirva para la operación del Agente.

Esto significa:

los elementos de la interfaz deben ser más claros
la retroalimentación de operación debe ser más estable
los permisos locales deben ser más granulares
el software puede proporcionar interfaces más adecuadas para las llamadas de los agentes
A los usuarios les puede interesar más si la IA puede operar el software sin problemas

A largo plazo, los límites entre las aplicaciones pueden volverse más delgados.
Es posible que a los usuarios les importe menos “qué aplicación debo abrir” y más “qué tarea quiero completar”.

No lo exageres todavía

Por supuesto, todavía no es momento de dejarlo ir por completo.

Este tipo de capacidad todavía tiene varias limitaciones claras:

la estabilidad aún necesita observación
las tareas complejas pueden fallar en el medio
los límites de los permisos deben manejarse con cuidado
Las operaciones de eliminación de cuentas, pagos y archivos no deben delegarse a la ligera.
el consumo de cuotas no es algo que puedas ignorar por completo

Entonces, en esta etapa, el mejor caso de uso es no dejar que se haga cargo de toda la computadora, sino permitir que maneje tareas de bajo riesgo, revisables y con muchos pasos.

Por ejemplo:

organización de materiales
generar borradores
mover contenido entre herramientas
abrir y comprobar archivos
ejecutar flujos de trabajo semiautomáticos que pueden ser revisados por un humano

Una última línea

La verdadera importancia de esta actualización del Codex es que empuja a la IA de “responder preguntas” a “operar el entorno”.

A corto plazo, es una característica del uso de la computadora.
A largo plazo, puede marcar un cambio en la forma en que se utilizan las computadoras personales.

En el futuro, es posible que dediquemos menos tiempo a recordar botones, buscar menús y cambiar de ventana.
Más a menudo, describiremos el objetivo, dejaremos que un Agente lo ejecute y luego dejaremos que los humanos tomen el juicio final.

¿Por qué existe una habilidad del Codex en el directorio pero aún no aparece?

Wed, 29 Apr 2026 11:18:00 +0800

Este problema era fácil de pasar por alto: varias habilidades ya estaban ubicadas en ~/.codex/skills, pero después de abrir un nuevo hilo del Codex, la barra lateral todavía mostraba solo un pequeño subconjunto de ellas.

Al principio, parecía un problema de caché o de indexación. La causa real fue más específica: varios archivos SKILL.md comenzaron con una lista de materiales UTF-8. El cargador de habilidades de Codex 0.111.0 no omitió esa secuencia de bytes, por lo que calculó erróneamente que los archivos no tenían contenido YAML válido.

Síntoma

El directorio local contenía estas habilidades:

~/.codex/skills/git-commit-push/SKILL.md
~/.codex/skills/hugo-rsync-deploy/SKILL.md
~/.codex/skills/bilibili-speech-transcriber/SKILL.md
~/.codex/skills/product-cutout-normalize/SKILL.md

Pero después de abrir un hilo nuevo, las habilidades realmente expuestas fueron solo:

1
2

bilibili-speech-transcriber
product-cutout-normalize

En otras palabras, un archivo existente en el disco no significa que la sesión actual pueda cargarlo correctamente. Codex analiza primero la portada de cada SKILL.md. Si el análisis falla, esa habilidad se excluye directamente.

Investigación

Iniciar una nueva sesión con codex exec mostró un error más directo. En VS Code u otros IDE, es posible que estos registros no sean visibles:

1
2

failed to load skill C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md: missing YAML frontmatter delimited by ---
failed to load skill C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md: missing YAML frontmatter delimited by ---

Visualmente, estos archivos parecían tener un encabezado normal:

---
name: post-rewrite
description: ...
---

El verdadero problema estaba en el nivel de bytes.

El comienzo de un archivo fallido fue:

`1`	`EF-BB-BF-2D-2D-2D`

El comienzo de un archivo que se cargó correctamente fue:

`1`	`2D-2D-2D`

2D-2D-2D es ---. El EF-BB-BF anterior es la lista de materiales UTF-8.

Causa

En Codex 0.111.0, el cargador de habilidades espera que el primer byte de SKILL.md sea el primer - en ---.

Si el archivo comienza con una lista de materiales UTF-8, el comienzo real será:

`1`	`BOM + ---`

Entonces, el cargador piensa que el archivo no comienza con el delimitador inicial e informa:

`1`	`missing YAML frontmatter delimited by ---`

El contenido de la habilidad no era incorrecto y el directorio tampoco era incorrecto. Un pequeño detalle de codificación impidió que el analizador reconociera el archivo.

Arreglar

Convierta los archivos SKILL.md afectados a UTF-8 sin BOM.

En PowerShell, esto se puede hacer así:

$paths = @(
  'C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md',
  'C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md',
)

$utf8NoBom = New-Object System.Text.UTF8Encoding($false)

foreach ($p in $paths) {
  $text = [IO.File]::ReadAllText($p, [Text.Encoding]::UTF8)
  [IO.File]::WriteAllText($p, $text, $utf8NoBom)
}

Después del procesamiento, el encabezado del archivo debería cambiar de:

`1`	`EF-BB-BF-2D-2D-2D`

`1`	`2D-2D-2D`

Verificación

Después de reiniciar una sesión del Codex, las habilidades visibles se restauraron en:

git-commit-push-zh
hugo-rsync-deploy
bilibili-speech-transcriber
product-cutout-normalize

Si la barra lateral todavía muestra la lista anterior, cierre la barra lateral o ventana actual del Codex y vuelva a abrir el proyecto. La lista de habilidades generalmente se carga cuando comienza la sesión, por lo que es posible que los cambios realizados en mitad de una sesión no se actualicen inmediatamente.

Una última línea

Este tipo de problema es fácil de confundir con “El Codex no se volvió a indexar” o “la habilidad no se instaló correctamente”.

Al solucionar problemas, verifique primero estas tres cosas:

si SKILL.md está realmente en el directorio correcto
si el archivo tiene un texto inicial --- válido en la parte superior
si el archivo es UTF-8 sin BOM

La clave en este caso fue el tercer punto: el archivo se veía bien, pero su primer byte no era “-”, por lo que Codex no lo trató como una habilidad válida.

¿Cuál es la diferencia entre ~/.codex/skills y Project .codex/skills en Codex?

Wed, 29 Apr 2026 11:08:00 +0800

Al organizar las habilidades del Codex, la gente suele quedarse estancada en dos preguntas:

¿Cuál es la diferencia entre ~/.codex/skills y project/.codex/skills?
¿Por qué existe una habilidad en el directorio pero no aparece en la sesión actual?

Aquí está la versión corta.

La diferencia

La forma más sencilla de recordarlo:

~/.codex/skills es tu biblioteca de habilidades global
project/.codex/skills es la biblioteca de habilidades local para ese repositorio

`~/.codex/skills`

Úselo para:

Habilidades que reutilizas personalmente en todos los proyectos.
flujos de trabajo generales que no están vinculados a un repositorio específico
flujos de trabajo que claramente pertenecen a sus propios hábitos

Por ejemplo:

post-reescritura
post-traducir -git-commit-push -hugo-rsync-deploy
bilibili-transcriptor-de-voz

El rasgo clave de este tipo de habilidad es: todavía tiene sentido fuera del proyecto actual.

`proyecto/.codex/skills`

Úselo para:

flujos de trabajo que solo se aplican a este repositorio
reglas estrechamente acopladas a la estructura, scripts o plantillas del proyecto actual
Habilidades que deben ser compartidas por el equipo.

Por ejemplo:

un flujo de trabajo de publicación específico para este repositorio
una plantilla de generación que solo funciona en este proyecto
pasos de automatización estrechamente vinculados a scripts de proyectos privados

El rasgo clave de este tipo de habilidad es: deja de ser significativo una vez que sale de este repositorio.

Cuándo utilizar habilidades globales y cuándo utilizar habilidades de proyecto

Esta regla general es suficiente:

Si se trata de tus hábitos personales, ponlo en ~/.codex/skills
Si se trata de reglas del repositorio, colóquelo en project/.codex/skills
Si se puede reutilizar en todos los proyectos, prefiera global
Si debe ser compartido por varias personas y evolucionar con el repositorio, prefiera el nivel de proyecto

El repositorio actual

Basado en el estado actual:

su máquina tiene ~/.codex/skills
este repositorio no tiene .codex/skills

Así que ahora mismo dependes principalmente de las habilidades globales.

Eso significa que flujos de trabajo como “post-reescritura”, “post-traducción” y “git-commit-push” son actualmente más bien parte de su flujo de trabajo personal, no algo incluido explícitamente con este repositorio.

Por qué existe una habilidad en el disco pero puede no aparecer en la sesión actual

Hay dos cosas diferentes aquí:

Existente en el disco: el archivo de habilidad existe en un directorio local
Expuesto a la sesión: la sesión actual lo registró en la lista de habilidades disponibles

Estos no son lo mismo.

Entonces esto puede suceder:

ya existe una habilidad en ~/.codex/skills
pero no aparece en la lista después de /

Por lo general, esto no significa que la habilidad esté rota. Más a menudo significa: la sesión actual no la ha vuelto a indexar.

Cómo hacer que una habilidad esté disponible en la sesión actual

La lista de verificación práctica es breve.

1. Colóquelo en el directorio correcto

Mundiales:

`1`	`~/.codex/skills/<skill-name>/SKILL.md`

Nivel de proyecto:

`1`	`project/.codex/skills/<skill-name>/SKILL.md`

2. Haga que el encabezado `SKILL.md` sea reconocible

Como mínimo, necesita:

---
name: your-skill-name
description: What this skill does
---

3. Abra una nueva sesión después de crearla o editarla

En muchos casos, una habilidad no aparece porque la sesión actual ya fijó su lista de habilidades disponibles cuando comenzó.

Entonces, si crea una habilidad en medio de una sesión, es posible que ya exista en el disco, pero es posible que esta sesión no la reconozca.

El flujo de trabajo más confiable es:

Ponga en práctica la habilidad
Finalizar la sesión actual
Vuelva a ingresar al proyecto.
Abre una nueva sesión
Compruebe si aparece debajo de /

4. Implemente las habilidades para el proyecto antes de comenzar

Si desea que project/.codex/skills se reconozca de manera más confiable, coloque esas habilidades en el proyecto antes de ingresar al repositorio e iniciar la sesión.

Una última línea

La conclusión más corta es:

~/.codex/skills es tu biblioteca de habilidades personales
project/.codex/skills es la biblioteca de reglas local del repositorio
una habilidad existente en el directorio no significa que la sesión actual siempre la mostrará
la solución más común es colocarlo en el directorio correcto, escribir un SKILL.md válido y luego iniciar una nueva sesión

Ralph y la colaboración entre múltiples agentes: cómo mantener la IA funcionando de manera confiable durante tareas largas

Mon, 27 Apr 2026 08:19:02 +0800

Si ha estado utilizando agentes de codificación últimamente, rápidamente se encontrará con una pregunta muy práctica: La IA puede funcionar, claro, pero ¿cómo se puede mantener funcionando durante horas sin desviarse, olvidar requisitos o rehacer el mismo trabajo?

Ésa es la verdadera pregunta detrás de muchas discusiones sobre “Ralph” y la colaboración entre múltiples agentes. La cuestión no es simplemente comparar qué modelo es más fuerte. La pregunta más útil es esta: ¿cómo se diseña un flujo de trabajo que permita a la IA mantenerse estable durante tareas largas?

Si analizamos el problema, normalmente hay dos rutas principales:

El enfoque Ralph: seguir iniciando sesiones nuevas y conectar el contexto a través del sistema de archivos
El enfoque de múltiples agentes: dejar que un agente líder coordine mientras los agentes trabajadores dividen la ejecución

Dicho de manera más simple, la pregunta no es “qué modelo es más poderoso”, sino “¿cómo se organiza la IA para que se comporte más como un pequeño equipo que pueda seguir cumpliendo?”.

01 Por qué las tareas largas se descarrilan

En tareas breves, muchos problemas quedan ocultos. Usted da una instrucción, el modelo lee algunos archivos, cambia algunas líneas y el trabajo está hecho.

Una vez que la tarea se hace más larga, los modos de falla comunes comienzan a acumularse:

Las conversaciones se hacen más largas y el contexto comienza a abultarse.
Los requisitos anteriores quedan eliminados por la información más reciente.
Un agente tiene que planificar, implementar y probar al mismo tiempo.
Sin un paso de aceptación claro, “está hecho” a menudo significa simplemente “dice que está hecho”.

Entonces, cuando la IA funciona durante mucho tiempo, el verdadero desafío no suele ser la calidad del modelo de un solo disparo. Se trata de división de tareas, transferencia de estados, separación de roles y bucles de retroalimentación.

02 El enfoque Ralph: dividir las tareas largas en rondas cortas

Ralph encaja bien cuando el problema principal es un contexto sucio y sobrecargado.

Su patrón central es sencillo:

Sigue lanzando nuevas sesiones de agentes en bucle
Deje que cada ronda se encargue solo de una tarea lo suficientemente pequeña
Almacene el estado cruzado en archivos en lugar de forzar todo en una sola conversación

El beneficio es inmediato: cada ronda comienza con un contexto nuevo, por lo que la sesión permanece más centrada y es menos probable que se vea arrastrada por la vieja historia.

Si ya ha visto proyectos estilo “Ralph”, la estructura le resultará familiar:

Las tareas actuales viven en archivos estructurados.
Los aprendizajes intermedios van a los archivos de progreso.
Los cambios de código permanecen en el historial de git.

En otras palabras, “Ralph” no intenta que un agente recuerde todo para siempre. Exterioriza la memoria a propósito para que la sesión en sí sea más ligera.

Este tipo de configuración funciona especialmente bien cuando:

La obra ya se puede dividir en pequeñas historias.
Cada historia puede caber dentro de una ventana de contexto.
El proyecto ya cuenta con pruebas, verificación de tipos u otras comprobaciones.

Es una solución al problema de cómo hacer que la IA siga avanzando ronda a ronda.

03 El enfoque de múltiples agentes: dividir el trabajo que un agente no puede realizar solo

La otra ruta es la colaboración entre múltiples agentes.

En este tipo de diseño de flujo de trabajo, el patrón más prometedor suele ser el siguiente: el agente principal no debe hacer todo el trabajo directamente. En cambio, coordina mientras otros agentes se encargan del desarrollo, las pruebas, la verificación y la aceptación.

Esto difiere de Ralph en un aspecto importante:

Ralph se siente más como una iteración en serie
El trabajo con múltiples agentes se parece más a una división paralela del trabajo. Cuando la tarea contiene naturalmente diferentes roles, la colaboración entre múltiples agentes se vuelve más fácil de usar. Por ejemplo:
Un agente desglosa la tarea y escribe el plan de ejecución.
Un agente implementa el cambio real.
Un agente prueba y valida el resultado.
Un agente comprueba si el resultado sigue coincidiendo con el objetivo original.

La cuestión no es abrir más ventanas porque sí. El valor real es la separación de roles. Las tareas que antes recaían sobre un solo agente ahora se pueden dividir en etapas más claras.

Una vez que los límites de los roles están claros, varios problemas se aclaran:

La persona que escribe no tiene que ser la misma que revisa
La parte de pruebas no tiene que reconstruir el requisito completo cada vez.
Es menos probable que el agente principal se ahogue en los detalles de la implementación.

Esta es una solución al problema de cómo hacer que la IA coopere más como un equipo pequeño.

04 La verdadera clave no es el paralelismo, sino el diseño de tareas

Ya sea que elija Ralph o la colaboración entre múltiples agentes, lo más fácil de subestimar es esto: el diseño del flujo de trabajo importa más que abrir más agentes.

Si la división de tareas es incorrecta, agregar más agentes sólo crea un paralelismo con la confusión.

Una avería más estable suele tener algunas características:

Una tarea se asigna a un objetivo claro
Un rol posee una categoría de salida
Cada ronda tiene una condición clara de finalización.
La producción de una ronda puede ser consumida directamente por la siguiente.

Por ejemplo, en lugar de darle a la IA una instrucción gigante como “construir toda la característica”, una estructura más estable suele ser:

Primero, rompa los requisitos y los límites.
Luego dividir la implementación
Luego dividir las pruebas
Entonces haz de la aceptación su propio paso.

La ventaja es que cuando algo sale mal, resulta más fácil saber si el problema radica en los criterios de comprensión, implementación, prueba o entrega.

05 Por qué la aceptación es tan importante

Muchos flujos de trabajo de IA fallan no porque no haya sucedido nada antes, sino porque el último paso careció de un pase de confirmación genuinamente independiente.

En tareas largas, suele haber una gran brecha entre “se produjo un resultado” y “el resultado es realmente utilizable”.

Por eso, una dirección especialmente importante es separar el desarrollo de la aceptación. Incluso sin un proceso complejo, vale la pena hacerse al menos estas preguntas:

¿Realmente completó la tarea original?
¿Solo parchó la superficie sin solucionar la causa raíz?
¿Las pruebas cubrieron sólo el camino más feliz?
¿Se cambiaron silenciosamente los requisitos upstream a lo largo del camino?

Sin esa capa, la IA puede seguir declarando éxito fácilmente dentro de un flujo de trabajo prolongado.

06 Cómo elegir entre los dos

Si desea una regla general rápida:

Si su principal problema es la sobrecarga del contexto y la deriva de las sesiones largas, comience con “Ralph”
Si su principal problema es que un agente desempeña demasiadas funciones, comience con la colaboración de varios agentes.

Más específicamente:

Ralph se adapta al trabajo que es claro, granular y fácil de avanzar paso a paso
La colaboración entre múltiples agentes se adapta al trabajo con fuertes límites de roles y una necesidad de paralelismo y verificación cruzada.

En la práctica, estos dos enfoques no siempre son competidores. Una configuración madura suele combinarlos:

Utilice un bucle exterior estilo “Ralph” para impulsar la tarea más grande.
Utilice la colaboración de múltiples agentes dentro de cada ronda para investigación, implementación, prueba y aceptación.

Eso les brinda a ambos un mejor control sobre el contexto prolongado y una mejor colaboración dentro de una sola ronda.

07 Resumen de una oración

Lo que hace que valga la pena estudiar estos enfoques no es que recomienden “Ralph” o la colaboración entre múltiples agentes de forma aislada. Es que dejan muy clara una verdad práctica: mantener la IA estable durante tareas largas depende menos del modelo en sí y más de si se diseñó bien el contexto, las tareas, los roles y la aceptación.

Si ya está pidiendo a “Claude Code”, “Codex” u otros agentes de codificación que manejen tareas más largas del mundo real, este tipo de pensamiento de flujo de trabajo suele ser más valioso que simplemente cambiar a un modelo más sólido.

Qué es Ralph: convertir Claude Code y Amp en un circuito de desarrollo autónomo repetible

Mon, 27 Apr 2026 08:08:55 +0800

Si últimamente ha estado prestando atención a los flujos de trabajo de agentes de codificación de larga duración, snarktank/ralph es un proyecto que vale la pena analizar de cerca. No es otro contenedor de modelo ni otra interfaz de usuario de chat. En cambio, organiza “Claude Code” o “Amp” en un bucle autónomo que sigue recorriendo las historias en un “PRD” hasta que todo está hecho.

Su idea central es simple: no obligar al mismo agente a seguir trabajando dentro de un contexto cada vez más largo y desordenado. En su lugar, inicie una nueva sesión de codificación de IA para cada iteración. Eso evita que el contexto se hinche y hace que los límites de las tareas sean mucho más claros.

01 ¿Qué es Ralph?

Ralph se describe a sí mismo muy claramente: es un bucle de agente de IA autónomo que ejecuta repetidamente una herramienta de codificación de IA hasta que se completan los elementos de un “PRD”.

El repositorio actualmente admite dos herramientas:

Amplificador CLI
Código Claude

Cada iteración inicia una nueva instancia. En otras palabras, no depende de una conversación interminable. En cambio, mantiene la memoria en estado externo:

historia de git
progreso.txt
prd.json

Ese detalle importa mucho. Cuando la gente deja que un agente ejecute tareas grandes, el principal problema a menudo no es que el modelo no pueda codificar. Es que la sesión se vuelve más pesada con el tiempo, empieza a perder contexto, olvida requerimientos y repite trabajo. Ralph está diseñado casi exclusivamente en torno a ese problema.

02 Cómo funciona

El flujo de trabajo de Ralph tiene tres pasos.

1. Escribe primero un PRD

El archivo README sugiere comenzar con la habilidad “prd” incluida para generar un documento de requisitos y dividir la función en historias más pequeñas.

2. Convierta el PRD a `prd.json`

Luego, la habilidad ralph convierte el Markdown PRD en un prd.json estructurado. Ese archivo almacena las historias de los usuarios y si cada una ha pasado.

3. Ejecute el script de bucle

La ejecución real está a cargo de ralph.sh. Los comandos se ven así:

1
2

./scripts/ralph/ralph.sh [max_iterations]
./scripts/ralph/ralph.sh --tool claude [max_iterations]

El valor predeterminado es 10 iteraciones. En cada ronda, Ralph hace aproximadamente lo siguiente:

Crea una rama desde branchName
Elija la historia de mayor prioridad donde “pasa: falso”.
Implemente solo esa historia
Ejecute controles de calidad, como verificación de tipos y pruebas.
Comprometerse si pasan los controles
Actualiza prd.json
Adjunte lo aprendido a progress.txt
Continuar a la siguiente ronda.

Entonces Ralph no está tratando de terminar todo de una vez. Comprime el trabajo en muchos bucles pequeños que pueden caber dentro de una única ventana de contexto.

03 ¿Qué hace que Ralph sea interesante?

1. Cada ronda utiliza un contexto nuevo

Esta es la elección de diseño que define a Ralph. El archivo README enfatiza que cada iteración es una instancia de IA completamente nueva y que la memoria entre iteraciones reside solo en git, progress.txt y prd.json.

Esto es muy diferente del patrón común de mantener el “Código Claude” u otra herramienta dentro de una larga conversación. Una vez que las tareas aumentan, ese enfoque a menudo se ralentiza debido a su propia historia y gradualmente pierde enfoque. Ralph acepta que ninguna ronda debería recordar todo y, en su lugar, mueve la memoria a archivos.

2. Obliga a que las tareas sean pequeñas

Los documentos dicen explícitamente que cada elemento PRD debe ser lo suficientemente pequeño como para terminar dentro de una ventana de contexto. Tareas como agregar un filtro, actualizar una acción del servidor o agregar una columna de base de datos tienen aproximadamente el tamaño correcto. Tareas como reconstruir toda la API o crear un panel completo son demasiado grandes. Esa restricción es práctica. Muchos bucles de agentes autónomos fallan no porque el bucle sea malo, sino porque la división de tareas es demasiado burda y cada ronda lleva demasiado a la vez.

3. Preserva el aprendizaje, no solo el código

Más allá de progress.txt, el README también hace hincapié en la actualización de AGENTS.md. La razón es sencilla: las iteraciones futuras y los futuros desarrolladores leerán esas notas, por lo que los patrones, errores y convenciones descubiertos en cada ronda deben anotarse en el proyecto mismo.

Dicho de otra manera, Ralph no sólo intenta mantener a un agente codificando continuamente. También intenta ayudar al agente a desarrollar memoria de trabajo sobre el código base a lo largo del tiempo.

04 Cuando encaja mejor

Ralph encaja bien cuando su tarea se ve así:

Ya se puede dividir en un conjunto claro de historias de usuarios.
El código base tiene bucles de retroalimentación confiables, como pruebas, verificación de tipos o CI
Quiere que el agente siga avanzando sin poner todo en una larga conversación.
Estás de acuerdo con el progreso iterativo en lugar de exigir una finalización de una sola vez.

Por otro lado, si el requisito aún es vago, o el trabajo depende de discusiones frecuentes y cambios constantes de dirección, es posible que Ralph no sea el primero a quien recurrir. Se adapta mejor una vez que los requisitos ya están definidos y la ejecución debe ser constante.

05 En qué se diferencia del uso normal del código Claude

Con Claude Code simple, el patrón habitual es simple: abra una sesión y déjela seguir leyendo código, editando archivos y ejecutando comandos. Esto funciona muy bien para tareas pequeñas y medianas, pero las tareas más grandes suelen tener dos problemas:

El contexto sigue creciendo
Las decisiones intermedias son más difíciles de preservar de forma estructurada.

Ralph convierte “Claude Code” o “Amp” en algo más parecido a un ejecutor por lotes:

La fuente de la tarea es prd.json, no instrucciones de chat ad hoc.
Cada iteración reconoce solo una historia.
El estado de finalización se vuelve a escribir en los archivos.
Los aprendizajes van en progress.txt
Los cambios de código se conservan en git

Entonces, en la práctica, se siente menos como un nuevo asistente de IA y más como un controlador de iteración agregado sobre un agente de codificación.

06 Un requisito importante

Que Ralph funcione bien depende menos del bucle en sí y más de la calidad de sus bucles de retroalimentación. El archivo README dice esto de manera muy directa: sin verificación de tipo, pruebas y CI, los errores se agravarán en iteraciones posteriores.

Para tareas frontend, el repositorio incluso recomienda agregar la verificación del navegador a los criterios de aceptación. Sin una verificación real, un agente puede confundir fácilmente “parece hecho” con “realmente funciona”.

Ese punto es importante. Ralph no es una automatización mágica. Es más como un multiplicador de fuerza para la disciplina de ingeniería que ya tienes. Si su proyecto ya tiene desgloses de tareas claros y controles confiables, Ralph se vuelve mucho más útil. Si faltan esos fundamentos, el bucle sólo repetirá la confusión.

07 Resumen de una oración

Lo que hace que valga la pena estudiar “Ralph” no es que introduzca una enorme cantidad de infraestructura nueva. Toma una idea simple pero útil y la convierte en un flujo de trabajo práctico: deje que Claude Code o Amp manejen una pequeña historia por ronda, mantenga el enfoque en un contexto nuevo y preserve la continuidad a través de git, prd.json y progress.txt. Si ya está utilizando agentes de codificación en proyectos reales y sigue estancado en cómo impulsar tareas largas de manera confiable, vale la pena tomar prestado el enfoque de Ralph.

Referencias

Repositorio de GitHub: https://github.com/snarktank/ralph
Diagrama de flujo interactivo: https://snarktank.github.io

nuwa-skill: convertir "destilar a una persona" de idea en workflow ejecutable

Wed, 22 Apr 2026 16:20:00 +0800

[alchaincyf/nuwa-skill](https://github.com/alchaincyf/nuwa-skill) puede hacer pensar primero en una cosa: usar AI para responder con la voz de una persona famosa. Pero lo realmente interesante no es si suena convincente. La clave es que intenta convertir “destilar cómo piensa una persona” en un workflow repetible.

Si eso funciona, el valor va mucho más allá de unos prompts entretenidos de personaje. Significa tomar el marco de juicio de alguien, sus prioridades, heurísticas comunes y hábitos de comunicación, y convertirlos en una skill que puede invocarse una y otra vez. Lo que quieres no es una frase que suene como algo que esa persona diría, sino algo más cercano a una interfaz operativa para “si esta persona analizara el problema, qué miraría primero, cómo haría tradeoffs y qué cuestionaría”.

Resuelve modelado, no imitación

Muchos llamados persona prompts son básicamente capas de estilo.

Suelen pedir al modelo:

hablar en el tono de alguien
citar más sus frases características
imitar la formulación que usa en público

Eso luce bien en demos, pero suele caerse en trabajo real. La razón es simple: el tono es superficie, mientras la estructura de juicio es el núcleo. Una persona es memorable no porque le gusten ciertas palabras, sino porque aborda problemas de formas reconocibles y consistentes.

La dirección de nuwa-skill se acerca más a extraer esos métodos estables. Le importa menos “cómo sonar como ellos” y más “cómo pensar como ellos”.

Un workflow más completo

Según la descripción del repositorio, nuwa-skill busca construir un flujo end-to-end: introducir el nombre de una persona, hacer automáticamente la investigación, extracción y validación, y finalmente organizar el resultado como una skill usable dentro de Claude Code.

Detrás de esa idea hay varios cambios importantes.

Primero, asume que la persona destilada no tiene que ser tu compañero de trabajo. Mucha gente encuentra esta idea como “capturar cómo trabaja un compañero fuerte”. Eso es valioso, pero limitado: el pool de muestras es pequeño y normalmente cubre solo experiencia interna del equipo. nuwa-skill amplía el objetivo a un rango mucho mayor de personas, como fundadores, inversores, científicos, product managers y escritores.

Segundo, enfatiza automatización en lugar de pedir al usuario que fabrique prompts a mano. Lo que vuelve práctica esta capacidad no es una redacción bonita, sino poder hacer de forma consistente recolección de fuentes, síntesis de puntos de vista, extracción de patrones y validación de resultados. En cuanto un paso depende totalmente del trabajo manual, el coste de reutilización sube rápido.

Tercero, intenta que la salida sea una skill y no una conversación única. La primera puede reutilizarse, combinarse e iterarse. La segunda normalmente solo funciona en el contexto actual y se deshace después de unos turnos.

Por qué importa esta dirección

Si tratas la AI como máquina de preguntas y respuestas, el caso natural es “dame una respuesta”. Pero si la tratas como un banco de trabajo, la pregunta pasa a ser “dame una forma de mirar este problema”.

Ahí se inclina el valor de nuwa-skill.

Por ejemplo, ante una decisión de producto quizá no quieras una respuesta estándar. Quizá quieras varios marcos analíticos muy distintos:

una persona empieza por compounding a largo plazo
otra por restricciones de recursos
otra por consistencia de experiencia de usuario
otra por timing de entrada al mercado

Si esos marcos pueden empaquetarse de forma fiable, la AI deja de ser “algo que escribe un párrafo” y se vuelve “algo que ayuda a cambiar de perspectiva rápido”. Eso es mucho más útil que imitar citas famosas, porque afecta directamente la calidad de decisión.

Lo más convincente: convertir conocimiento tácito en activos invocables

Muchas capacidades de alto valor son difíciles de escribir como SOP.

Que alguien juzgue consistentemente mejor que otros no suele deberse a que conozca más reglas explícitas, sino a que ha construido un sistema tácito de filtrado durante años:

qué señales merecen atención primero
qué ruido debe ignorarse de inmediato
qué preguntas deben descomponerse
qué preguntas deben invertirse
qué conclusiones deben esperar más evidencia

Esta capacidad es difícil de preservar porque las personas no siempre pueden explicarla claramente. Justo por eso la extracción estructurada es valiosa. Lo atractivo de nuwa-skill es que no intenta mover conocimiento superficial, sino reorganizar hábitos cognitivos.

Dónde encaja mejor

Creo que este tipo de skill es especialmente útil en varios escenarios.

1. Revisión multiperspectiva antes de una decisión

Si ya tienes un plan pero temes estar pensando solo por el camino que conoces, cambiar a distintas “perspectivas persona” para revisar el mismo asunto es más valioso que pedir al modelo que siga expandiendo tu redacción original.

2. Aprender el marco de juicio de cierto tipo de experto

Mucha gente aprende de expertos coleccionando citas, viendo entrevistas y copiando resúmenes. Al final, a menudo solo recuerda algunas frases bonitas. Cuando un patrón de pensamiento se vuelve una skill, aprender se parece más a “invocarlo repetidamente con preguntas reales” que a “apilar notas estáticas”.

3. Compartir un estilo analítico en un equipo

Lo que muchos equipos carecen no es solo documentación, sino una respuesta compartida a “cómo solemos pensar cuando encontramos un problema”. Si este workflow madura más, también podría usarse a la inversa para preservar métodos de operadores internos fuertes. Está claro que el proyecto no quiere limitar la idea a casos internos.

La parte difícil de proyectos así

Por supuesto, una dirección atractiva no significa que los problemas difíciles ya estén resueltos.

El desafío real no es instalar una skill. Es:

si las fuentes son suficientemente fiables
si los patrones extraídos son estables y no ilusiones de textos dispersos
si el modelo realmente usa el marco de una persona o solo repite impresiones comunes
si las fronteras entre distintas personas se difuminan dentro del modelo

La pregunta clave no es “¿puede generar algo plausible?”, sino “¿puede el marco cognitivo producido por esta skill sobrevivir reutilización en muchas tareas?” Si el proyecto profundiza en validación, su credibilidad mejorará mucho.

Por qué va más allá de una librería de templates de prompt

En el pasado, muchos proyectos manejaban esta capacidad como una librería de prompts: una persona, un prompt, y el usuario lo copia al chat. El problema es que una librería de templates sigue siendo un activo estático. Se actualiza despacio, la validación es débil y cuesta convertirla en un workflow de producción.

Lo que nuwa-skill empuja más lejos es convertir “destilación de persona” de un problema de template en un problema de workflow.

Cuando el centro de gravedad cambia de “escribir un prompt” a “generar, validar e iterar sistemáticamente una skill persona”, todo empieza a parecer más ingeniería que inspiración. Para cualquiera que quiera usarlo a largo plazo, ese es el cambio más importante.

Cierre

nuwa-skill es interesante no porque convierta la AI en un show de imitación de celebridades, sino porque acerca “cómo aprender cómo piensa alguien” a algo ejecutable, reutilizable e iterable.

Si muchos persona prompts resuelven “cómo hablar como alguien”, este proyecto quiere resolver “cómo mirar problemas como alguien”. Lo primero es genial para demos. Lo segundo está mucho más cerca de una herramienta real de productividad.

Referencias

Repositorio GitHub: https://github.com/alchaincyf/nuwa-skill
README del proyecto: https://github.com/alchaincyf/nuwa-skill/blob/main/README.md
Definición de Skill: https://github.com/alchaincyf/nuwa-skill/blob/main/SKILL.md

Notas del proyecto RAGFlow: funciones y uso de un motor RAG open source

Wed, 15 Apr 2026 22:09:25 +0800

RAGFlow es un motor RAG open source de infiniflow. Su objetivo no es ofrecer una simple capa de “sube documentos y haz preguntas”, sino reunir parsing de documentos, chunking, recuperación, reranking, trazabilidad de citas, configuración de modelos, capacidades de agentes e integración API en un flujo completo.

Si estás construyendo una base de conocimiento empresarial, Q&A sobre documentos, un asistente de soporte, recuperación de información interna o una capa de contexto más fiable para un LLM, RAGFlow es una de las opciones open source que merece atención seria.

01 Qué problema resuelve RAGFlow

La mayoría de sistemas RAG tropiezan con tres problemas comunes:

El parsing de documentos es inestable, especialmente con PDFs, escaneos, tablas, imágenes y layouts complejos.
La estrategia de chunking es opaca, así que la recuperación puede parecer correcta mientras el contexto real está incompleto.
Las respuestas no tienen citas confiables, lo que dificulta verificar de dónde viene la respuesta.

RAGFlow se centra justo en esos problemas. El README del proyecto enfatiza Deep document understanding, chunking basado en plantillas, visualización de chunks, grounding de citas y recuperación multipath con reranking. En otras palabras, le importa más que una entrada de alta calidad lleve a respuestas de alta calidad que simplemente conectar una base vectorial a una UI de chat.

02 Funciones principales

1. Comprensión profunda de documentos

RAGFlow puede extraer conocimiento de datos no estructurados complejos. El README lista formatos como Word, PPT, Excel, TXT, imágenes, documentos escaneados, datos estructurados y páginas web.

Esto importa mucho para bases de conocimiento empresariales. El material real rara vez es Markdown limpio. Suele mezclar contratos, informes, tablas, PDFs escaneados, manuales de producto, capturas y contenido web. Si el parsing es débil, tanto la recuperación como las respuestas del LLM sufrirán.

2. Chunking basado en plantillas

RAGFlow ofrece chunking basado en plantillas. El valor está en que el chunking no es una caja negra: distintos tipos de documentos pueden usar estrategias distintas.

Por ejemplo, artículos, papers, tablas, documentos Q&A, explicaciones de imágenes y cláusulas contractuales necesitan límites y granularidad de chunk diferentes. El chunking por plantillas ayuda a reducir frases rotas, pérdida de contexto de tablas y separación entre títulos y cuerpo.

3. Citas trazables

RAGFlow enfatiza citas fundamentadas, es decir, respuestas que pueden rastrearse hasta pasajes fuente. También ofrece visualización de chunks, facilitando inspeccionar y ajustar resultados de parsing y chunking.

Esto es especialmente importante en producción. El Q&A interno empresarial no solo necesita producir algo que parezca correcto; también debe ser verificable. Para políticas, cumplimiento, finanzas, documentación técnica y soporte al cliente, las citas y la trazabilidad son casi obligatorias.

4. Flujo RAG automatizado

RAGFlow convierte el ciclo de vida RAG en un flujo más completo:

Crear una base de conocimiento
Subir o sincronizar datos
Parsear documentos
Revisar y ajustar chunks
Configurar modelos LLM y embedding
Ejecutar recuperación multipath y reranking
Crear asistentes de chat
Integrar mediante APIs en sistemas de negocio

Eso lo acerca más a una plataforma RAG que a una librería aislada. Para equipos importan tanto la UI como la API: personas no técnicas pueden mantener la base de conocimiento y los ingenieros pueden integrar la capacidad en sistemas existentes.

5. Extensiones de Agent, MCP y workflow

Las actualizaciones recientes de RAGFlow ya incluyen Agentic workflow, MCP, Agent Memory y componentes de ejecución de código. Eso sugiere que ya no se limita al Q&A tradicional de bases de conocimiento y también se mueve hacia escenarios orientados a agentes.

Un patrón típico es que un agente use RAGFlow como capa fiable de conocimiento empresarial: recuperar contexto cuando lo necesita, generar respuestas con citas y combinarlo con herramientas o pasos de workflow cuando sea necesario.

03 Flujo básico de uso

Según la documentación oficial de quickstart, el uso común de RAGFlow puede resumirse en estos pasos.

1. Preparar el entorno

Los requisitos básicos listados en el README oficial son:

CPU >= 4 cores
RAM >= 16 GB
Disk >= 50 GB
Docker >= 24.0.0
Docker Compose >= v2.26.1

Si quieres usar el sandbox para el ejecutor de código, también necesitas gVisor. Otra nota práctica es que las imágenes Docker oficiales apuntan principalmente a plataformas x86. Para ARM64, la documentación recomienda construir la imagen por cuenta propia.

2. Clonar el proyecto

1
2

git clone https://github.com/infiniflow/ragflow.git
cd ragflow/docker

3. Revisar `vm.max_map_count`

El despliegue de RAGFlow depende de componentes como Elasticsearch u OpenSearch, así que en Linux normalmente hay que verificar:

`1`	`sysctl vm.max_map_count`

Si el valor está por debajo de 262144, puedes configurarlo temporalmente:

`1`	`sudo sysctl -w vm.max_map_count=262144`

Si quieres que persista tras reiniciar, añádelo a /etc/sysctl.conf.

4. Arrancar con Docker Compose

Puedes iniciar directamente el modo CPU:

`1`	`docker compose -f docker-compose.yml up -d`

Si quieres aceleración GPU para tareas DeepDoc, el README muestra cómo activar DEVICE=gpu en .env antes del arranque:

1
2

sed -i '1i DEVICE=gpu' .env
docker compose -f docker-compose.yml up -d

Luego inspecciona los logs:

`1`	`docker logs -f docker-ragflow-cpu-1`

Cuando los servicios estén listos, abre la dirección de la máquina en el navegador. Con la configuración predeterminada suele ser:

`1`	`http://IP_OF_YOUR_MACHINE`

5. Configurar claves API de modelos

RAGFlow necesita configuración de LLM y modelos de embedding. El README menciona elegir la fábrica LLM predeterminada en service_conf.yaml.template y actualizar el API_KEY correspondiente.

En la práctica, necesitas configurar modelos según tu proveedor:

Modelo de chat
Modelo de embedding
Modelo de rerank
Modelo multimodal, si quieres entender imágenes dentro de PDFs o DOCX

6. Crear la base de conocimiento y subir documentos

Después de arrancar el servicio, el flujo típico es:

Iniciar sesión en la Web UI.
Crear un dataset o base de conocimiento.
Subir documentos o configurar una sincronización de fuente de datos.
Esperar a que termine el parsing.
Inspeccionar los chunks y ajustarlos si hace falta.
Crear un asistente de chat y asociar la base de conocimiento.
Probar calidad de respuesta y fuentes de cita.

Si necesitas integrarlo con un sistema de negocio, puedes continuar con la API o SDK de RAGFlow y conectar recuperación y chat a tu propia aplicación.

04 Escenarios adecuados

RAGFlow encaja con necesidades como:

Q&A de bases de conocimiento internas empresariales
Manuales de producto, documentación técnica y recuperación de FAQ
Asistentes de soporte al cliente y preventa
Q&A trazable sobre contratos, informes y políticas
Manejo unificado de materiales multiformato
Equipos que quieren mantenimiento vía UI e integración API
Sistemas que quieren usar RAG como capa de contexto para agentes

Es especialmente adecuado cuando los formatos documentales son complejos, las citas importan y las personas quieren inspeccionar o intervenir en los resultados de parsing.

05 Qué vigilar

Primero, RAGFlow no es un script ligero. Tiene requisitos reales de infraestructura. La recomendación oficial es al menos 4 cores CPU, 16 GB de RAM y 50 GB de disco. Si solo quieres Q&A sobre una pequeña cantidad de Markdown, una plataforma completa puede ser innecesaria.

Segundo, la calidad documental sigue importando. RAGFlow puede mejorar parsing y chunking, pero no puede hacer mágicamente fiable material fuente de baja calidad, obsoleto o contradictorio. El gobierno de la base de conocimiento sigue siendo importante antes de producción.

Tercero, la selección de modelos afecta directamente la calidad. Las elecciones de embedding, rerank, chat y multimodal influyen en recuperación y respuestas. RAGFlow da el flujo, pero el resultado final sigue dependiendo de datos, modelos y ajuste.

Cuarto, los despliegues en producción deben cuidar permisos y seguridad de datos. Las bases de conocimiento empresariales suelen contener documentos internos, así que el modelo de despliegue, control de acceso, logs, claves API y políticas de datos del proveedor deben diseñarse de antemano.

06 Conclusión rápida

La fortaleza de RAGFlow es convertir las partes más difíciles de RAG en capacidades de plataforma: parsing de documentos complejos, chunking explicable, grounding de citas, recuperación multipath, reranking, configuración de modelos, Web UI, acceso API y extensiones de agentes.

Si necesitas una base de conocimiento empresarial verificable y mantenible que pueda conectarse a sistemas de negocio, RAGFlow es más completo que una configuración de “base vectorial más chat UI simple”. En cambio, si solo necesitas Q&A personal a pequeña escala sobre datos simples, un framework RAG más ligero puede ser más eficiente en recursos.

Enlaces relacionados

Proyecto GitHub: https://github.com/infiniflow/ragflow
Documentación oficial: https://ragflow.io/docs/dev/
Demo online: https://cloud.ragflow.io

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 OpenHarness: qué puede hacer este agent harness open source

Sun, 12 Apr 2026 23:45:00 +0800

Si has estado siguiendo herramientas de agentes AI open source últimamente, HKUDS/OpenHarness es un proyecto que vale la pena observar. No es simplemente otro envoltorio de chat. En su lugar, separa la capa de infraestructura para un agente ejecutable, extensible y gobernable en un Agent Harness open source independiente.

Según el README oficial, OpenHarness ofrece un conjunto ligero pero bastante completo de capacidades de agente, incluidas llamadas a herramientas, carga de skills, memoria, gobierno de permisos y coordinación multi-agente. El ohmo incluido es la aplicación de asistente personal AI construida sobre esa base.

01 Qué es OpenHarness

Puedes pensar en OpenHarness como la capa de runtime que da manos, memoria y límites a un modelo fundacional.

Un modelo puede ser bueno razonando y generando texto, pero si quieres que funcione como un agente de larga duración, normalmente necesita estas capacidades alrededor:

Llamar herramientas en lugar de solo producir texto
Leer y escribir archivos, ejecutar comandos y usar búsqueda y acceso web
Preservar contexto y memoria entre sesiones largas
Aplicar controles de permisos a acciones riesgosas
Dividir tareas grandes entre varios sub-agentes en paralelo

El objetivo de OpenHarness es convertir esa capa de ingeniería alrededor del modelo en una implementación Python clara, open source e inspeccionable. Está más cerca de un sustrato operativo para agentes que de una experiencia de modelo o una interfaz de chat concreta.

02 Funciones básicas del proyecto

Según la página de GitHub y el README actuales, OpenHarness se centra en las siguientes áreas de capacidad.

1. Agent Loop

Este es el bucle de ejecución central que permite a un agente seguir trabajando durante múltiples pasos. Los puntos destacados oficiales incluyen:

Bucles de llamadas a herramientas con streaming
Reintentos de API con backoff exponencial
Ejecución paralela de herramientas
Contabilidad de tokens y seguimiento de costes

El punto práctico es que el agente no queda limitado a una respuesta única. Puede observar, razonar, llamar herramientas, leer resultados y seguir iterando dentro de la misma tarea.

2. Herramientas, Skills y Plugins

OpenHarness dedica bastante esfuerzo a la capa de herramientas. La página del proyecto dice que ya incluye herramientas integradas para archivos, Shell, búsqueda, acceso web y MCP, y que soporta carga bajo demanda de archivos de skill en Markdown.

Su valor no está solo en tener muchas herramientas, sino en que el modelo de composición es bastante abierto:

Puedes usar directamente las herramientas integradas
Puedes cargar skills para una tarea específica
Puedes extender hooks, skills y agentes mediante plugins
Es compatible con el ecosistema anthropics/skills y plugins relacionados

Si quieres convertir flujos repetidos en capacidades reutilizables en lugar de volver a describirlos en prompts cada vez, esta capa resulta especialmente útil.

3. Contexto y memoria

Este es uno de los diferenciadores más importantes de OpenHarness. Las palabras clave oficiales incluyen:

descubrimiento e inyección de CLAUDE.md
compresión automática de contexto
memoria persistente mediante MEMORY.md
recuperación de sesiones y continuación de historial

Eso significa que no solo reacciona a la entrada actual. Está diseñado para preservar convenciones de proyecto, tareas históricas y preferencias a largo plazo, lo que lo hace más adecuado para trabajo continuo en lugar de empezar siempre desde cero.

4. Gobierno de permisos y límites de seguridad

Cuando un agente empieza a interactuar con filesystem, terminal y red, el gobierno se vuelve crítico. OpenHarness ofrece:

múltiples modos de permisos
controles de reglas basados en rutas y comandos
hooks PreToolUse / PostToolUse
prompts interactivos de aprobación

En otras palabras, no se trata solo de permitir que el agente haga cosas. También define qué puede hacerse directamente y qué debería requerir confirmación primero.

5. Coordinación multi-agente

OpenHarness también soporta delegar trabajo a sub-agentes. Los materiales públicos actuales mencionan capacidades como:

creación y delegación de sub-agentes
registro de equipos y gestión de tareas
ciclo de vida de tareas en segundo plano

Para trabajo más complejo, esto significa que puede ir más allá de un único agente serial e intentar colaboración paralela.

6. Flujos multi-proveedor

OpenHarness no trata a los proveedores como simples etiquetas de API. Los abstrae como combinaciones de workflow + profile. Según el README, las direcciones actuales incluyen:

Claude / compatible con Anthropic
compatible con OpenAI
Codex Subscription
GitHub Copilot
backends compatibles como Moonshot(Kimi), GLM y MiniMax

Eso hace que se sienta más como un framework runtime multi-modelo y multi-entrada para agentes, no como algo atado a un único proveedor.

7. React TUI y modo no interactivo

OpenHarness incluye una interfaz de terminal. Ejecutar oh abre una TUI React/Ink, y el README oficial dice que soporta:

selector de comandos
confirmación de permisos
cambio de modelo
cambio de proveedor
recuperación de sesión

Si no quieres entrar en una interfaz interactiva, también puedes usar el modo no interactivo para ejecutar una tarea una vez y devolver el resultado como salida estándar, JSON o JSON en streaming, algo útil para scripting y automatización.

03 Qué es `ohmo`

Si OpenHarness es la capa de infraestructura, ohmo es la aplicación de agente personal construida encima.

La página del proyecto es muy clara sobre su posicionamiento: no es solo un chatbot genérico, sino un asistente personal que puede seguir trabajando durante conversaciones largas. La descripción oficial dice que puede interactuar contigo mediante canales como Feishu, Slack, Telegram y Discord, y realizar tareas como:

crear una rama mediante fork
escribir código
ejecutar pruebas
abrir un PR

El README también destaca que ohmo puede ejecutarse sobre tu suscripción existente de Claude Code o Codex, por lo que no necesariamente necesitas provisionar una nueva clave API. Para personas que ya usan esas suscripciones, eso reduce bastante la barrera.

04 En qué escenarios encaja

Por las capacidades públicas actuales, OpenHarness encaja bien para personas que:

Quieren estudiar de qué está hecho realmente un agente de nivel producción
Quieren construir su propio runtime de agentes open source y extensible
Quieren herramientas, skills, memoria, permisos y coordinación multi-agente en un solo framework
No quieren quedar atadas a un único proveedor de modelos o forma de cliente
Quieren construir agentes verticales o asistentes personales sobre una arquitectura existente

Si tu objetivo es simplemente encontrar un asistente terminado que pueda chatear de inmediato, OpenHarness en sí quizá no sea la opción más ligera. Pero si te importa más la infraestructura de agentes, el control de ingeniería y la extensibilidad a largo plazo, es un proyecto muy valioso para estudiar.

05 Una forma rápida de entender su posicionamiento

En una frase:

OpenHarness convierte modelos fundacionales en agentes que realmente pueden ejecutar trabajo, mientras ohmo empaqueta esa capacidad en un asistente personal que puede seguir trabajando contigo con el tiempo.

También puedes pensarlo como dos capas:

OpenHarness: un Agent Harness open source, esencialmente la capa de infraestructura
ohmo: una app de agente personal construida sobre esa infraestructura

A fecha de 12 de abril de 2026, la página de GitHub muestra que el proyecto ya había avanzado a v0.1.6 (10 de abril de 2026), con énfasis continuo en compresión automática de contexto, soporte de transporte MCP, React TUI y estabilidad de runtime para flujos multi-agente. Eso sugiere que todavía evoluciona rápido, pero su dirección ya es bastante clara.

Referencias

Repositorio GitHub: https://github.com/HKUDS/OpenHarness
README en inglés: https://github.com/HKUDS/OpenHarness/blob/main/README.md
README en chino: https://github.com/HKUDS/OpenHarness/blob/main/README.zh-CN.md

Primeros pasos con Playwright CLI: instalación, Skills, sesiones y comandos esenciales

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

Si has usado Claude Code, GitHub Copilot u otros agentes de programación para automatización de navegador, microsoft/playwright-cli es una herramienta que vale la pena observar. No es el ayudante de navegador tradicional pensado principalmente para humanos escribiendo comandos a mano. Es una CLI de Playwright diseñada para agentes de programación, con énfasis en menor sobrecarga de tokens, una interfaz de comandos más ligera e integración con flujos basados en Skills.

Según el README oficial, la idea central de Playwright CLI es clara: frente a MCP, que puede empujar grandes esquemas de herramientas y estructura de página al contexto del modelo, el enfoque CLI es más compacto y encaja mejor con flujos de agentes que alternan constantemente entre codebases grandes, pruebas y automatización de navegador.

01 Qué es Playwright CLI

playwright-cli es una herramienta open source de línea de comandos para Playwright creada por Microsoft. La descripción oficial es “CLI for common Playwright actions”. Se usa principalmente para tareas como:

Abrir páginas y controlar el navegador
Grabar y generar código Playwright
Capturar snapshots de página para obtener referencias de elementos
Tomar capturas de pantalla y exportar PDFs
Trabajar con agentes de programación para automatización de pruebas e interacción web

El README actual de GitHub es muy explícito sobre su posicionamiento: si usas agentes de programación, la CLI suele encajar mejor que Playwright MCP; si necesitas estado persistente, introspección más rica y bucles agentic de larga duración, MCP sigue teniendo su lugar.

En otras palabras, Playwright CLI se siente más como una interfaz de automatización de navegador construida para asistentes AI de programación, no solo como una herramienta para que ingenieros hagan clic manualmente.

02 Dónde destaca

1. Encaja mejor con flujos de agentes

El README oficial enumera Token-efficient como una característica clave. No obliga a meter todos los datos de la página en el contexto del LLM. En su lugar, permite que el agente opere el navegador mediante comandos más cortos y enfocados.

Esto importa mucho para agentes de programación. En proyectos reales, un agente no solo controla el navegador. También tiene que leer código, editar archivos, ejecutar pruebas e inspeccionar logs. Si la interfaz del navegador consume demasiado contexto, todo el flujo se vuelve menos eficiente.

2. Funciona bien con Skills

El README destaca específicamente playwright-cli install --skills. Eso muestra que Microsoft no lo trata solo como otra utilidad de shell, sino como algo que Claude Code, GitHub Copilot y agentes similares pueden consumir directamente mediante un flujo basado en Skills.

Si tu configuración ya depende de Skills, Playwright CLI debería encajar de forma natural.

3. La gestión de sesiones es bastante completa

Playwright CLI soporta sesiones. De forma predeterminada, el perfil del navegador permanece en memoria, así que cookies y storage state se conservan entre varias llamadas CLI dentro de la misma sesión. Si añades --persistent, el perfil puede guardarse en disco y reutilizarse tras reiniciar el navegador.

Esto lo vuelve mucho más práctico que herramientas que abren un navegador para un solo comando y luego descartan todo. También encaja mejor con ciclos largos de depuración y flujos de agentes más extensos.

4. Incluye un panel visual de monitoreo

El README ofrece playwright-cli show, que abre un panel para observar y controlar todas las sesiones de navegador en ejecución. Esto es especialmente útil cuando un agente ejecuta automatización en segundo plano, porque puedes intervenir, inspeccionar el progreso y ayudar a depurar en lugar de trabajar a ciegas.

03 Instalación y requisitos

Según el README actual de GitHub, los requisitos básicos de Playwright CLI son:

Node.js 18 o más reciente
Claude Code, GitHub Copilot u otro agente de programación

Los comandos de instalación son:

1
2

npm install -g @playwright/cli@latest
playwright-cli --help

Hay un error fácil que conviene destacar:

El paquete recomendado oficialmente ahora es @playwright/cli
No lo confundas con el antiguo paquete npm deprecado playwright-cli

Así que el paquete correcto es el scoped package, no el paquete histórico antiguo.

04 Cómo empezar a usarlo

1. Instalar skills

Si quieres que un agente de programación use Playwright CLI directamente, la recomendación oficial es instalar primero las skills:

`1`	`playwright-cli install --skills`

El README dice explícitamente que Claude Code, GitHub Copilot y herramientas similares usarán las skills instaladas localmente.

2. Dejar que el agente llame directamente a la CLI

Si no quieres manejar Skills primero, también puedes pedir al agente que lea la ayuda de la CLI directamente:

1
2

Test the "add todo" flow on https://demo.playwright.dev/todomvc using playwright-cli.
Check playwright-cli --help for available commands.

El README llama a esto “Skills-less operation”. La idea es que incluso sin skills preinstaladas, la CLI puede describirse lo bastante bien para que un agente la use.

3. Probar manualmente un flujo mínimo

El README incluye un ejemplo con TodoMVC que funciona muy bien como primera demostración práctica:

playwright-cli open https://demo.playwright.dev/todomvc/ --headed
playwright-cli type "Buy groceries"
playwright-cli press Enter
playwright-cli type "Water flowers"
playwright-cli press Enter
playwright-cli check e21
playwright-cli check e35
playwright-cli screenshot

Esta secuencia es útil porque muestra rápidamente cómo trabaja Playwright CLI:

open abre la página
type y press gestionan entrada de texto
check usa una referencia de elemento para alternar checkboxes
screenshot guarda el resultado

05 `--headed`, sesiones y panel de monitoreo

`--headed`

Playwright CLI es headless por defecto. Si quieres ver directamente la ventana del navegador, debes pasar --headed al usar open:

`1`	`playwright-cli open https://playwright.dev --headed`

Esto es especialmente útil al depurar selectores, flujos de login o cualquier interacción que sea más fácil inspeccionar visualmente.

sesiones

El README oficial da mucha importancia a las sesiones. Puedes usar distintas sesiones para aislar diferentes proyectos o sitios:

1
2
3

playwright-cli open https://playwright.dev
playwright-cli -s=example open https://example.com --persistent
playwright-cli list

Si dejas que un agente trabaje durante más tiempo, también puedes pasar la sesión mediante una variable de entorno:

`1`	`PLAYWRIGHT_CLI_SESSION=todo-app claude .`

Comandos útiles de gestión de sesiones:

1
2
3

playwright-cli list
playwright-cli close-all
playwright-cli kill-all

En la práctica:

list muestra todas las sesiones
close-all cierra todos los navegadores de forma ordenada
kill-all termina forzosamente todos los procesos de navegador

Panel de monitoreo

Si quieres ver qué está haciendo realmente el agente en el navegador, puedes ejecutar:

`1`	`playwright-cli show`

Según el README, este panel tiene dos vistas principales:

Session grid: muestra sesiones activas por workspace, con vista previa en vivo, URL y título de página
Session detail: muestra una vista en vivo de una sesión seleccionada y permite tomar control del ratón y teclado

Eso significa que Playwright CLI no solo es usable desde la línea de comandos. También tiene una capa de observabilidad bastante madura.

06 Qué comandos conviene memorizar primero

Si es tu primera vez con Playwright CLI, no necesitas memorizar todos los comandos. Estos son los principales:

Páginas e interacción

playwright-cli open [url]
playwright-cli goto <url>
playwright-cli click <ref>
playwright-cli fill <ref> <text>
playwright-cli type <text>
playwright-cli hover <ref>
playwright-cli press <key>

Obtener estructura de página

playwright-cli snapshot
playwright-cli snapshot <ref>
playwright-cli snapshot --depth=N
playwright-cli eval <func> [ref]

snapshot es especialmente importante porque muchas operaciones posteriores dependen de referencias de elementos almacenadas como ref. En la práctica, normalmente capturas un snapshot primero y luego usas los identificadores devueltos para hacer clic, rellenar, marcar o tomar capturas.

Guardar salida

1
2

playwright-cli screenshot
playwright-cli pdf

Pestañas

playwright-cli tab-list
playwright-cli tab-new [url]
playwright-cli tab-close [index]
playwright-cli tab-select <index>

07 Quién debería probarlo

Playwright CLI merece probarse especialmente en estos escenarios:

Usas Claude Code, Copilot u otro agente de programación para pruebas E2E
Quieres una interfaz de automatización de navegador más ligera sin empujar grandes estructuras de página al contexto del modelo
Quieres que una sesión de navegador persista entre múltiples comandos
Quieres monitorear tareas web impulsadas por agentes mediante un panel mientras se ejecutan

Si tu pregunta principal es cómo hacer que la automatización de navegador funcione de forma eficiente con agentes de programación, Playwright CLI probablemente se sentirá más natural que los flujos tradicionales de depuración manual.

Referencias

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

OpenClaw Dreaming: las máquinas empiezan a soñar mientras los humanos pierden el sueño

Sun, 12 Apr 2026 12:41:34 +0800

La memoria a largo plazo siempre ha sido un punto débil de los modelos grandes. A medida que crece el contexto, la memoria se vuelve más difícil de gestionar. Un agente puede parecer que lo recuerda todo y, aun así, volverse peor al juzgar qué importa y qué debería olvidarse.

El 5 de abril, OpenClaw presentó una función experimental llamada Dreaming. No es solo un nombre llamativo. Es un sistema de gestión de memoria en segundo plano, inspirado en el sueño humano, diseñado para ayudar a los agentes a despertar con una memoria más limpia y útil.

01 Una pipeline basada en sueño para consolidar memoria

Dreaming hace más que indexar datos. Divide el procesamiento de memoria en tres etapas que reflejan distintas funciones del sueño humano.

Light Sleep: el sistema escanea conversaciones recientes y trazas de recuperación, elimina duplicados y construye una lista de candidatos. En esta etapa solo almacena información temporalmente y no modifica el archivo de memoria principal MEMORY.md.

Deep Sleep: el sistema aplica filtros más estrictos para identificar información duradera. Solo avanzan las entradas que superan umbrales de puntuación, número de recuperaciones y diversidad de consultas. Antes de escribir nada, vuelve a revisar los logs más recientes para retirar contenido obsoleto. El resultado final se añade a MEMORY.md, mientras que un resumen de sueño profundo se escribe en DREAMS.md.

REM: después de consolidar la memoria, el sistema busca vínculos ocultos entre trazas de comportamiento recientes. Extrae patrones y resúmenes reflexivos, y luego los guarda en una sección REM dedicada para ayudar al agente a responder con mejor estructura y más contexto.

Dreaming también produce un diario de sueños legible por humanos. Cuando se acumula material suficiente, un sub-agente en segundo plano llama al modelo predeterminado y añade una breve entrada en lenguaje natural a DREAMS.md.

02 Un sistema de puntuación para decidir qué merece quedarse

El punto real de Dreaming no es solo organizar memoria, sino filtrarla. En lugar de conservarlo todo, OpenClaw usa un modelo de puntuación ponderado para decidir qué pertenece al almacenamiento a largo plazo.

Las seis dimensiones son:

Relevancia (30%): qué tan útil es la información cuando se recupera.
Frecuencia (24%): qué tan a menudo aparece el elemento en señales de corto plazo.
Diversidad de consultas (15%): si aparece en diferentes prompts y contextos.
Recencia (15%): si la información sigue siendo fresca y accionable.
Integración (10%): si permanece estable durante varios días.
Riqueza conceptual (6%): qué tan denso y conectado es su grafo conceptual.

En la práctica, esto significa que el sistema intenta conservar información repetida, útil, actual y ampliamente aplicable, mientras deja que el ruido de menor valor se desvanezca.

03 Por qué recuerda al enfoque de “dreaming” de Claude

Algunos desarrolladores han señalado que Dreaming se parece a la lógica de sueño automatizado descrita en materiales filtrados de Claude Code sobre el sistema KAIROS. Los enfoques antiguos que reescribían repetidamente todo MEMORY.md podían volverse desordenados con el tiempo. Al dividir el flujo en sueño ligero, sueño profundo y REM, Dreaming hace que la pipeline sea más explícita: consolidar primero, preservar después y derivar patrones de nivel superior al final.

Otros han destacado el ángulo neurocientífico. Términos como Dreaming, Light Sleep, Deep Sleep y REM no son branding aleatorio. Toman prestados directamente modelos humanos de consolidación de memoria durante el sueño.

OpenClaw ya usa archivos como IDENTITY.md, USER.md y HEARTBEAT.md para preservar identidad, contexto de usuario y continuidad. DREAMS.md completa la pieza que faltaba: decidir qué recuerdos realmente vale la pena conservar.

04 La parte más irónica: las máquinas sueñan y los humanos siguen despiertos

El valor de Dreaming no es que la AI lo recuerde todo. Es que aprende a revisar trazas de corto plazo, extraer patrones y descartar ruido. Un agente fuerte no debería comportarse como un dispositivo de almacenamiento tonto. Debería mejorar con el tiempo al entender preferencias del usuario, objetivos recurrentes y contexto de largo plazo.

Desde una perspectiva de ingeniería, lo más interesante es que el sistema no se presenta como una caja negra mística. Es un proceso backend estructurado con etapas, umbrales, reflexión y reglas de olvido. Eso hace que la memoria de AI se sienta menos como inflación de contexto sin control y más como un sistema diseñado.

Y eso también vuelve irónico todo el asunto. Estamos dedicando un esfuerzo enorme a enseñar a las máquinas a soñar, mientras muchas personas pierden el sueño por ser reemplazadas por esos mismos sistemas cada vez más capaces.

¿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.

OpenClaw y Agent Harness: por qué parece AGI

Fri, 10 Apr 2026 09:16:17 +0800

Mucha gente, al entrar en contacto por primera vez con OpenClaw, siente que “se parece más a un compañero que hace cosas que a un chatbot”.

Esa sensación no es misteriosa. La clave está en que OpenClaw no es un salto de capacidad de un único modelo, sino un Agent Harness completo.

Conclusión primero

La esencia de OpenClaw puede resumirse así:

El modelo se encarga de entender y decidir
El Harness se encarga de memoria, herramientas, disparadores, ejecución y salida
Ambos colaboran mediante un bucle, generando la experiencia de “acción continua”

Por eso la razón central de que “parezca AGI” no es que el modelo se haya vuelto omnipotente de pronto, sino que la ingeniería del sistema amplifica la ejecutabilidad del modelo.

Qué es Harness

Puedes entender Harness como un “exoesqueleto” puesto sobre el modelo.

Un LLM por sí solo normalmente solo puede dar una respuesta dentro de una solicitud. El Harness completa estas capacidades:

Gestión de sesión y estado: conecta tareas de varias rondas
Mecanismo de memoria: guarda y recupera contexto según necesidad
Sistema de herramientas: llama navegador, terminal, archivos y APIs externas
Mecanismo de disparo: se despierta por temporizador o evento, sin tener que esperar siempre una pregunta humana
Canal de salida: escribe resultados de vuelta al sistema, no solo devuelve un texto

Cuando estas capacidades se integran en un mismo bucle, el modelo pasa de “respondedor” a “ejecutor”.

Por qué OpenClaw parece distinto

El chatbot tradicional es “preguntas una vez, responde una vez”.

OpenClaw se parece más a “observa -> llama herramientas -> mira resultados -> decide de nuevo”. Una vez que el bucle se establece, muestra capacidad de avanzar tareas de forma continua.

Esto también es lo más valioso para aprender de OpenClaw:

Demuestra que la experiencia Agent viene principalmente del diseño de arquitectura
Divide la “autonomía” en módulos que pueden construirse con ingeniería

Valor y límites

La ventaja de OpenClaw es ser general y flexible, pero el coste también es claro:

Cuanto más contexto y definiciones de herramientas haya, mayor será el coste
Cuanto más general sea el sistema, más complejos serán el debugging y la gobernanza

En escenarios de producción, muchos equipos elegirán Agent más pequeños y especializados, no un “agente todopoderoso”.

Cronología completa del bloqueo de OpenClaw por Anthropic

Wed, 08 Apr 2026 19:48:42 +0800

Contexto del evento

El 4 de abril de 2026, Anthropic anunció que dejaría de cubrir herramientas de terceros como OpenClaw mediante suscripciones de Claude.

El impacto directo para los usuarios fue que los flujos de terceros que antes dependían de la ruta de suscripción para acceder a Claude tuvieron que cambiar a otros métodos de acceso o cambiar de modelo.

Cronología (enero a abril de 2026)

Enero de 2026

Según reportes públicos, Anthropic pidió al proyecto entonces llamado Clawdbot que ajustara su nombre, con el argumento de que su pronunciación era cercana a Claude.

En la misma etapa, la comunidad empezó a reportar límites en llamadas de terceros usando credenciales de suscripción.

Febrero de 2026

Las restricciones relacionadas se incorporaron a los términos de servicio, aclarando más el límite entre suscripción y llamadas automatizadas de terceros.

Ese mismo mes, OpenClaw lanzó v4.0 y cambió su arquitectura interna a backends de modelo enchufables. Es decir, el modelo dejó de ser una única entrada fija y pasó a poder alternar entre varios proveedores.

Marzo de 2026

Anthropic lanzó Claude Dispatch y Computer Use, cubriendo capacidades como ejecución de tareas remotas y operación de escritorio.

OpenClaw siguió avanzando en su capa de compatibilidad en actualizaciones posteriores, unificando diferencias entre modelos en autenticación, formato de tool calling y estructura de respuesta para reducir el coste de migración al cambiar de modelo.

Los reportes públicos también mencionaron que el equipo de OpenClaw y Anthropic se comunicaron a finales de marzo, pero la dirección estratégica final no cambió.

4 de abril de 2026

Anthropic ejecutó formalmente el corte de cobertura de suscripción para herramientas de terceros.

Esto marcó que los ajustes estratégicos de los meses anteriores entraron en fase de ejecución.

5 de abril de 2026

OpenClaw lanzó v4.5, con acciones principales como:

Ajustar la prioridad de entradas de modelo en el flujo de onboarding
Integrar rutas alternativas como GPT-5.4
Continuar adaptando flujos de tarea y experiencia interactiva

Por la fecha de lanzamiento, la capacidad de cambio de OpenClaw no fue construida totalmente de emergencia, sino sobre la base de la reforma multi-modelo iniciada desde febrero.

Dos direcciones paralelas durante el proceso

Según la cronología, ambas partes avanzaron en direcciones distintas durante el mismo periodo:

Anthropic: estrechar los límites de suscripción e impulsar la integración de capacidades en productos oficiales
OpenClaw: reforzar la sustituibilidad de modelos y mejorar compatibilidad entre modelos

Estas dos rutas no son contradictorias, pero compiten en la “propiedad de la entrada” y en dónde se acumula el flujo de trabajo del usuario.

Estado actual (hasta abril de 2026)

Con base en la información pública, se pueden confirmar estos hechos:

El corte de cobertura de suscripción ya se ejecutó
OpenClaw completó el cambio principal de rutas de modelo y mantiene iteración de versiones
Que el usuario perciba cambios claros depende de cuánto dependiera su flujo anterior de una sola capacidad de modelo

Puntos de observación posteriores

Lo que más merece seguimiento ahora no es el evento puntual en sí, sino tres cosas:

Si los límites entre suscripciones y llamadas API seguirán refinándose
El rendimiento de largo plazo de Agent multi-modelo en estabilidad, coste y experiencia
Si el flujo de trabajo del usuario terminará acumulándose en la capa de modelo, en la capa de herramienta o en una capa híbrida entre ambas