Workflow on KnightLi Blog

¿Cuántos tokens extra consume un subagent? Costes y estrategia de uso en flujos multi-agent

Sun, 31 May 2026 14:17:42 +0800

Usar subagents o un flujo multi-agent normalmente aumenta el uso de tokens. La pregunta no es si aumenta, sino cuánto aumenta y si la mejora en velocidad o estabilidad compensa ese coste adicional.

Para tareas pequeñas, suele ser más barato que el agent principal haga el trabajo directamente. Los subagents tienen más sentido cuando la tarea se puede dividir con claridad, o cuando merece la pena una revisión independiente.

Un subagent no es un hilo paralelo más barato

Al ver subagents por primera vez, es fácil imaginarlos como hilos paralelos: el agent principal hace una parte, el subagent hace otra, la tarea termina antes y por tanto debería ser más eficiente.

Pero no funciona así. Un subagent también es una llamada independiente al modelo. Necesita leer la tarea, entender el contexto, inspeccionar archivos, razonar sobre el problema y producir una salida. No es una copia gratuita del agent principal; es una ruta de razonamiento adicional.

Por eso la pregunta clave no es “¿puede ejecutarse en paralelo?”, sino “¿el tiempo ahorrado o la mejora de calidad justifican el coste extra en tokens?”.

Por qué aumenta el uso de tokens

Una llamada a un subagent suele añadir consumo de tokens en varias partes:

la descripción de la tarea que escribe el agent principal;
el contexto que se pasa al subagent;
los archivos y detalles que el subagent lee;
el razonamiento y la salida del propio subagent;
la revisión, integración y verificación posterior del agent principal.

Si varios agents leen los mismos archivos grandes, el desperdicio se vuelve más evidente. Esto ocurre especialmente en análisis de codebases, traducción de documentos largos y limpieza de contenido por lotes. Si la división es mala, muchos tokens se gastan en entender repetidamente el mismo contexto.

Releer contexto es el mayor desperdicio de tokens

El mayor desperdicio no suele ser “abrir un agent más”, sino hacer que varios agents lean los mismos materiales una y otra vez.

Por ejemplo, supongamos que una tarea debe procesar 6 artículos. Si 4 agents empiezan leyendo toda la estructura del sitio, toda la documentación de skills y toda la lista de artículos antes de tocar una parte pequeña, la paralelización sale cara. Una mejor opción es que el agent principal defina primero los límites y que cada subagent lea solo el directorio del artículo que le corresponde.

Una división más barata suele verse así:

cada agent se encarga de un directorio claro;
el contexto enviado a cada subagent es lo más corto posible;
varios agents no repiten la misma exploración;
el agent principal hace la revisión final una sola vez, en lugar de pedir a cada agent una revisión completa;
las comprobaciones que se pueden automatizar con scripts se ejecutan una vez, no se repiten con varios agents.

En otras palabras, controlar el coste de los subagents depende sobre todo de los límites, no solo del número de agents.

Cuánto puede aumentar

La siguiente tabla es una estimación aproximada. El consumo real depende de la longitud del contexto, el tamaño de los archivos, la complejidad de la tarea y el número de agents.

Escenario	Aumento de tokens
Un subagent procesa una tarea pequeña	Aproximadamente `1.2x - 2x`
2-4 agents procesan en paralelo una tarea bien dividida	Aproximadamente `2x - 5x`
Varios agents leen muchos archivos y hacen análisis largos	Posiblemente `5x+`
El agent principal y los subagents leen repetidamente los mismos archivos grandes	El desperdicio más evidente

No es una fórmula exacta de facturación, solo un rango práctico. El consumo real también depende de si cada agent necesita leer archivos completos, hacer razonamiento largo o esperar varias veces a que se le pase más contexto.

Cómo escribir una tarea de subagent que consuma menos tokens

Cuanto más amplia sea la instrucción, más probable es que el subagent explore por su cuenta, y eso aumenta el consumo de tokens. Una instrucción más barata define los límites con claridad.

Una buena tarea para subagent debería incluir:

qué archivos o directorios puede procesar;
qué archivos son solo de lectura y cuáles puede modificar;
si puede sobrescribir archivos existentes;
qué campos debe conservar, como date, slug y aliases;
qué debe incluir el informe final;
qué no debe hacer, por ejemplo no ejecutar una build completa ni editar archivos no relacionados.

Para una traducción, no basta con decir “traduce este artículo a varios idiomas”. Una instrucción más eficiente sería: “Procesa solo content/post/2026/05/240; lee index.zh-cn.md; crea solo los archivos que falten: index.en.md, index.zh-tw.md, index.ja.md e index.es.md; si ya existen, omítelos; conserva date y slug.”

La instrucción es un poco más larga, pero reduce las suposiciones y la exploración repetida. En conjunto suele salir más barata.

Dividir por archivo o directorio es más barato que dividir por idioma o paso

Para traducción por lotes, dividir por directorio de artículo suele ser mejor que dividir por idioma.

Supongamos que hay 6 artículos y cada uno necesita versiones en inglés, chino tradicional, japonés y español. Es mejor que un agent se encargue de todos los idiomas dentro de un directorio de artículo, en lugar de asignar un agent a todos los archivos en inglés y otro a todos los archivos en japonés.

La razón es simple: el front matter, los bloques de código, los enlaces, las tablas y el contexto semántico de un artículo solo necesitan leerse una vez. Si divides por idioma, varios agents leen el mismo texto fuente repetidamente y el consumo de tokens aumenta.

La misma lógica aplica a tareas de código. Es mejor dividir por módulo, directorio o componente que por pasos como “primero analizar, luego implementar, luego probar”. Dividir por pasos suele obligar a cada agent a releer el mismo contexto.

Cuándo merece la pena usar subagents

El valor de los subagents viene principalmente de dos cosas: paralelismo y una perspectiva independiente.

Casos adecuados:

traducir varios artículos por lotes;
editar varios directorios independientes;
separar claramente trabajo de frontend, backend y pruebas;
un agent implementa y otro revisa riesgos;
cambios de alto riesgo que necesitan una segunda perspectiva.

En estos casos, el uso de tokens aumenta, pero el tiempo total puede bajar de forma notable. Además, cada agent puede concentrarse en una parte concreta del trabajo.

Cuándo merece la pena usar un agent de revisión

Un agent de revisión no siempre vale la pena. Es más útil cuando la tarea es arriesgada, tiene mucho impacto o es fácil que el agent principal pase por alto detalles.

Casos en los que puede valer la pena añadir un agent de revisión:

cambios relacionados con inicio de sesión, pagos, permisos o borrado de datos;
contenido multilingüe que afecta categorías, URLs o enlaces internos;
refactors amplios que necesitan revisión independiente de regresiones;
el usuario pide explícitamente code review o revisión de riesgos;
el agent principal ya implementó el cambio y hace falta una segunda mirada sobre casos límite.

También hay casos claros en los que no compensa: cambios pequeños en un solo archivo, ajustes de título, correcciones simples de front matter o ejecutar un solo comando. Para eso, la autocomprobación del agent principal suele ser suficiente.

Cuándo no merece la pena

Los subagents no suelen merecer la pena en estos casos:

cambios pequeños en un solo archivo;
preguntas y respuestas simples;
ejecutar un único comando;
cambios de alcance muy pequeño;
tareas que no se pueden dividir claramente;
tareas en las que el subagent debe esperar varias veces a que el agent principal le pase contexto.

En estos casos, usar un subagent suele añadir sobrecarga. El agent principal es más rápido y más barato.

Mi estrategia por defecto: ahorrar tokens primero y añadir revisión solo por riesgo

Si el objetivo es ahorrar tokens, una estrategia conservadora funciona bien:

Tareas pequeñas: no usar subagents.
Tareas medianas: no usar subagents.
Tareas grandes por lotes: no usar subagents por defecto, salvo que el usuario pida explícitamente paralelizar para ganar velocidad.
Tareas de alto riesgo: considerar un agent adicional de revisión, intercambiando tokens por estabilidad.

Esta estrategia renuncia a parte de la velocidad paralela, pero reduce la lectura repetida de contexto y el razonamiento duplicado.

Si una tarea es grande pero no es de alto riesgo, primero conviene mirar scripts, comprobaciones por lotes y procesamiento local estructurado. Varios agents tienen más sentido cuando la división es muy clara o cuando el usuario quiere explícitamente más velocidad mediante paralelización.

Una estrategia más equilibrada

Si quieres controlar el coste sin renunciar del todo al paralelismo, una estrategia intermedia sería:

por defecto, el agent principal hace el trabajo directamente;
considerar subagents solo cuando la tarea se puede dividir claramente por archivo o directorio;
cada subagent lee solo los archivos que le corresponden;
no permitir que varios agents lean los mismos archivos grandes;
el agent principal hace la revisión final de campos clave, resultados de pruebas y Git diff;
añadir un agent de revisión independiente solo en tareas de alto riesgo.

Así se evita paralelizar por paralelizar. Los subagents deberían servir a un objetivo claro de velocidad o calidad, no convertirse en la acción por defecto.

Resumen

Los subagents y los flujos multi-agent siempre aumentan el uso de tokens. Un solo subagent puede añadir poco, pero varios agents en paralelo pueden multiplicar el coste.

Que merezca la pena depende de la tarea. Si el trabajo se puede dividir con claridad, o si el riesgo justifica una revisión independiente, los tokens extra pueden tener sentido. Para cambios pequeños en un solo archivo, preguntas simples o comprobaciones rutinarias, es más barato que el agent principal lo haga directamente.

En una frase: ahorra tokens en tareas pequeñas, divide solo cuando los límites sean claros y usa agents extra para estabilidad solo cuando el riesgo lo justifique.

El mecanismo de domain skills de browser-harness: cómo evitar que los AI Agent repitan errores de automatización web

Sun, 24 May 2026 23:43:35 +0800

Lo más interesante de browser-use/browser-harness no es solo que permite a los AI Agent controlar Chrome real. También convierte la experiencia de operación web en domain skills reutilizables.

Esto importa porque la automatización de navegador rara vez es difícil solo por hacer clic en botones. Cada sitio tiene sus propios detalles:

Qué páginas requieren login.
Qué datos pueden obtenerse directamente por API.
Qué botones no responden a clics DOM normales.
Qué iframes, shadow DOM o popups bloquean el flujo.
Qué selectores son estables y cuáles son clases temporales.
Qué acciones involucran cuentas, pagos o cambios irreversibles y requieren confirmación humana.

Si esa experiencia solo queda en un log de una tarea, el agente volverá a caer en los mismos problemas. domain skills sirve para conservarla, de modo que el agente no empiece desde cero cada vez que abre un sitio.

Qué son los domain skills

Puedes entender domain skills como manuales de operación de sitios para agentes.

No son documentación de usuario normal ni scripts de una sola vez. Son más bien conocimiento de sitio probado en campo:

Si el sitio es adecuado para usar navegador.
Qué API debe usarse primero si existe.
Qué URL conviene usar cuando el navegador es necesario.
Qué estructuras DOM, aria-labels y comportamientos de botones fueron verificados.
Qué enfoques comunes fallan.
En qué escenarios se debe detener y pedir intervención humana.

Este contenido puede ser revisado por humanos y leído por agentes durante tareas. Convierte la exploración improvisada en experiencia mantenible.

No es para que el agente haga clic a ciegas

Un buen browser agent no debería convertir todos los problemas en abrir una web, mirar capturas y pulsar botones.

Una parte importante de domain skills consiste precisamente en decirle al agente cuándo no usar el navegador.

En sitios como ArXiv, la búsqueda de papers, metadatos y resúmenes pueden obtenerse mediante Atom API o etiquetas meta HTML. Las solicitudes HTTP suelen ser más rápidas, estables y fáciles de analizar que abrir un navegador.

GitHub sigue una lógica parecida. Repositorios, usuarios y releases deberían usar primero la REST API. El contenido de archivos debería leerse desde raw.githubusercontent.com. Solo páginas como GitHub Trending, sin API equivalente, requieren navegador.

Esto muestra que browser-harness no parte de “el navegador lo resuelve todo”. Coloca el navegador en su lugar correcto: cuando API, HTTP y páginas estáticas no resuelven el problema, el agente opera una página real.

Guardan conocimiento por sitio

Los scripts tradicionales de automatización suelen escribirse alrededor de una tarea:

`1`	`Abrir página -> escribir palabra clave -> pulsar botón -> descargar archivo`

Ese script puede completar la tarea, pero la experiencia queda dispersa en el código. Si el sitio cambia, el script falla. Si cambia la tarea, gran parte de la experiencia no se reutiliza.

domain skills tiene una granularidad más cercana a una base de conocimiento por sitio. Se preocupa por:

Qué selector de contenedor es estable en resultados de Amazon.
Qué datos de GitHub deberían ir por REST API.
Cómo difieren los aria-label de botones en LinkedIn invitations.
Qué páginas de Shopify Admin son embedded apps.
Por qué los inputs de Shopify Polaris no siempre aceptan asignación JS normal de value.
Cómo crear, listar y limpiar instancias de navegador en Browser Use Cloud.

Estas experiencias no son pasos de una sola tarea. Son criterios que muchas tareas futuras pueden reutilizar.

Ejemplo: búsqueda de productos en Amazon

En Amazon, lo importante no es solo cómo buscar productos, sino qué ruta es más estable.

Un enfoque fiable es usar una URL de búsqueda directa en lugar de abrir siempre la portada y simular escritura. Los resultados pueden extraerse de un contenedor como [data-component-type="s-search-result"]. La extracción de campos también tiene matices: título, precio, rating, número de reseñas y si es patrocinado tienen fuentes DOM más estables.

Esto es valioso para un agente. Sin esa experiencia, el agente podría adivinar botones desde capturas y probar selectores una y otra vez. Con ella, puede ir directamente a una ruta de extracción más estable.

Además, un skill puede registrar trampas. Algunos selectores que parecen válidos pueden leer mal resultados patrocinados o áreas de recomendación cruzada. Eso solo se aprende probando.

Ejemplo: gestión de invitaciones en LinkedIn

LinkedIn se acerca más a flujos con cuentas reales, y por eso tiene más riesgo.

En la página de gestión de invitaciones, los botones Accept e Ignore tienen formatos de aria-label distintos. No se puede derivar uno del otro. Algunas tarjetas incluso renderizan Accept como <a> en lugar de <button>, y un clic CDP normal puede no disparar la acción.

Esto muestra que la automatización web real no termina al localizar un elemento. Etiquetas, eventos, soft navigation e implementación de componentes afectan si la acción realmente ocurre.

Para un agente, esta experiencia también tiene una implicación de seguridad. Las acciones relacionadas con cuentas sociales, invitaciones, mensajes y publicaciones no deberían delegarse por completo. El skill puede registrar rutas y trampas, pero aceptar invitaciones en lote, enviar contenido externo o cambiar datos de cuenta debería conservar confirmación humana.

Ejemplo: Shopify Admin

Shopify Admin muestra otro problema: un backend no siempre es una página única, sino una combinación de embedded apps y componentes complejos.

Muchas apps de Shopify corren dentro de iframes. Los inputs Polaris React, Web Components y embedded apps tienen comportamientos distintos. Algunos inputs no se pueden llenar solo con element.value = ...; requieren CDP keystrokes más parecidos a entrada real de teclado.

El valor de este tipo de skill es que permite al agente identificar primero qué tipo de UI está viendo y luego elegir el método correcto.

La experiencia de Shopify también enfatiza “no uses navegador si no hace falta”:

Para datos de producto e inventario de solo lectura, usar primero Storefront API.
Si hay un token de Admin API, usar primero Admin API.
Para editar código de tema, usar primero Shopify CLI.
Usar navegador solo cuando no hay API, el cambio es puntual o se está explorando el admin.

Esa es una lógica madura de elección de herramientas para agentes.

Ejemplo: Browser Use Cloud

domain skills no solo sirve para clics en páginas. También puede registrar experiencia de API alrededor del runtime del navegador.

La experiencia de Browser Use Cloud puede registrar cómo crear cloud browsers por REST API, listar navegadores activos, limpiar zombie browsers y obtener liveUrl y cdpUrl.

Esto significa que un skill no se limita a “cómo pulsar un botón”. Cualquier tarea recurrente con un método estable puede convertirse en skill:

Forma de llamar la API.
Formato de cabeceras de autenticación.
Estructura de request y response.
Códigos de estado verificados.
Modos de fallo frecuentes.
Limpieza y reciclaje de recursos.

Para agentes, todo eso son capacidades reutilizables.

Por qué es más fiable que razonar sobre la marcha

Muchas personas esperan que un modelo grande entienda la página por sí mismo cada vez. En tareas reales, depender solo del razonamiento improvisado no es estable.

Las razones son simples:

La UI web cambia con frecuencia.
El mismo botón puede tener varias implementaciones.
Visible no significa clicable.
Clicable no significa que la acción haya tenido efecto.
Algunas tareas deberían usar API, no navegador.
Algunas acciones requieren confirmación humana y no deberían decidirse solo por el modelo.

Al escribir estas experiencias en archivos, se obtienen varias ventajas:

Los humanos pueden revisarlas.
Las experiencias erróneas pueden corregirse.
El conocimiento del mismo sitio puede acumularse.
Nuevos agentes pueden heredar experiencias anteriores.
Descubrimientos temporales pueden convertirse en conocimiento duradero.

Esto es más estable que ponerlo todo en un prompt o en el contexto de chat.

Cómo puede usarlo un equipo

En un equipo, domain skills puede convertirse en una base ligera de conocimiento de automatización.

Conviene registrar cosas como:

Rutas tras login en sistemas internos.
Flujos de exportación de reportes.
Manejo de popups frecuentes.
Qué botones requieren confirmación humana.
Qué páginas tienen alternativa por API.
Qué selectores fueron probados y son fiables.
Qué tareas el agente no debe ejecutar automáticamente.

No hace falta que todo esté completo desde el inicio. Lo práctico es empezar por flujos de bajo riesgo, frecuentes y reversibles: lectura, descarga, organización y comprobación. Cuando el flujo sea estable, convertir la experiencia en skill.

Para gestores de equipo, los archivos skill hacen visible el límite de automatización. Permiten revisar qué sabe el agente, qué puede hacer y dónde debe detenerse.

Límites importantes

domain skills puede mejorar la tasa de éxito del agente, pero no debería automatizar por completo operaciones de alto riesgo.

Hay límites que conviene mantener:

No registrar contraseñas, Cookie, token, datos de clientes ni URLs internas sensibles.
Mantener confirmación humana para pagos, borrados, envíos masivos, cambios de cuenta y publicaciones externas.
Escribir fecha de verificación y alcance del skill.
Permitir que el skill caduque tras cambios del sitio y se vuelva a validar.
No usar skills para evadir controles de riesgo o límites de plataforma.

En otras palabras, domain skill hace al agente más estable, no le da permiso ilimitado.

Conclusión

El mecanismo de domain skills de browser-harness muestra que la automatización web con AI Agent no puede depender solo de improvisación del modelo.

Un browser agent útil necesita al menos tres capas:

Control de bajo nivel: capturas, clics, entrada, descargas, CDP, HTTP.
Conocimiento por sitio: prioridad de API, selectores estables, trampas de componentes, límites de login.
Reglas humanas de seguridad: no entregar credenciales al modelo, confirmar acciones de alto riesgo y no escribir información sensible en skills.

domain skills cubre la segunda capa. Permite que el agente entre a una tarea web con experiencia verificada en lugar de redescubrir todo cada vez.

Referencias:

browser-harness domain skills: https://github.com/browser-use/browser-harness/tree/main/agent-workspace/domain-skills
Amazon product-search skill: https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/amazon/product-search.md
ArXiv scraping skill: https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/arxiv/scraping.md
GitHub scraping skill: https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/github/scraping.md
LinkedIn invitation-manager skill: https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/linkedin/invitation-manager.md
Shopify admin skill: https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/shopify-admin/README.md
Browser Use Cloud skill: https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/browser-use-cloud/cloud.md

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.

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.

¿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

Usar Agent Skills para sustituir la función de Copilot en VS Code que genera mensajes de commit

Mon, 06 Apr 2026 13:09:49 +0800

La función “generar mensaje de commit” de GitHub Copilot en VS Code es muy práctica. Cuando se agota la cuota, el ciclo de reinicio puede ser muy largo. Este artículo es un intento de sustituir esa función usando Agent Skills locales.

Problema y objetivo

El objetivo de este artículo es ofrecer una alternativa que se pueda aplicar directamente: usar el skill agent git-commit-push-zh para completar commits y push estandarizados.

Alternativa: `git-commit-push-zh`

Este skill convierte los “cambios actuales” en un flujo fijo:

Revisar el estado de los cambios.
Confirmar la rama actual.
Añadir los cambios al área de staging.
Generar un mensaje de commit en chino.
Ejecutar commit.
Hacer push a la rama remota.

Los comandos correspondientes son:

git status --short
git branch --show-current
git add -A
git commit -m "<中文提交信息>"
git push origin <当前分支>

Convención recomendada para mensajes de commit

Se recomienda usar un formato unificado:

`1`	`<类型>(<范围>): <中文摘要>`

Ejemplos de tipo:

feat: nueva funcionalidad
fix: corrección de problema
docs: actualización de documentación
refactor: refactorización de código
chore: cambios de mantenimiento

Ejemplos:

feat(site): 新增全站 head 广告脚本注入
fix(i18n): 修正 relref 相关文章链接路径
chore(content): 合并 AI 工作流分类到 AI工具

Fallos habituales

nothing to commit: no hay cambios para commit; basta con detener el push.
Fallo en push: revisa primero permisos, estado de la rama remota y conflictos.
Excepción de SSH/permisos: confirma credenciales y permisos antes de reintentar.

Apéndice: `SKILL.md` original

El siguiente contenido es la documentación original de git-commit-push-zh, conservada tal cual para facilitar su reutilización y mantenimiento posteriores.

---
name: git-commit-push-zh
description: 在当前 Git 仓库中将“当前更改”完成一次标准提交流程：检查状态、暂存变更、生成中文提交信息、执行 commit 并 push 到当前分支对应远端。用户提出“提交代码”“提交当前更改”“生成中文提交信息并推送”“git commit push 中文说明”等请求时使用。
---

# 中文提交并推送

使用此技能将当前仓库改动一次性提交并推送到远端。

## 工作流程

1. 查看变更状态：`git status --short`。
2. 确认当前分支：`git branch --show-current`。
3. 暂存当前变更：`git add -A`。
4. 生成中文提交信息（简洁、可检索）。
5. 执行提交：`git commit -m "<中文提交信息>"`。
6. 执行推送：`git push origin <当前分支>`。

## 提交信息规范（中文）

1. 建议格式：`<类型>(<范围>): <中文摘要>`。
2. 类型示例：`feat`、`fix`、`chore`、`docs`、`refactor`。
3. 摘要要求：准确描述本次改动，不写空话。
4. 若仅少量变更，也保持可读性与可检索性。

示例：

- `feat(site): 新增全站 head 广告脚本注入`
- `fix(i18n): 修正 relref 相关文章链接路径`
- `chore(content): 合并 AI 工作流分类到 AI工具`

## 错误处理

1. 若无可提交变更（nothing to commit），明确告知并停止 push。
2. 若 push 失败，先回报关键错误（权限、远端不存在、冲突等）。
3. 常见 SSH/权限问题可在用户确认后重试高权限环境。

## 输出约定

1. 汇报提交哈希、分支名、提交信息。
2. 汇报 push 结果（成功或失败原因）。
3. 仅在确有失败时提供下一步最小操作建议。

Workflow on KnightLi Blog

¿Cuántos tokens extra consume un subagent? Costes y estrategia de uso en flujos multi-agent

Un subagent no es un hilo paralelo más barato

Por qué aumenta el uso de tokens

Releer contexto es el mayor desperdicio de tokens

Cuánto puede aumentar

Cómo escribir una tarea de subagent que consuma menos tokens

Dividir por archivo o directorio es más barato que dividir por idioma o paso

Cuándo merece la pena usar subagents

Cuándo merece la pena usar un agent de revisión

Cuándo no merece la pena

Mi estrategia por defecto: ahorrar tokens primero y añadir revisión solo por riesgo

Una estrategia más equilibrada

Resumen

El mecanismo de domain skills de browser-harness: cómo evitar que los AI Agent repitan errores de automatización web

Qué son los domain skills

No es para que el agente haga clic a ciegas

Guardan conocimiento por sitio

Ejemplo: búsqueda de productos en Amazon

Ejemplo: gestión de invitaciones en LinkedIn

Ejemplo: Shopify Admin

Ejemplo: Browser Use Cloud

Por qué es más fiable que razonar sobre la marcha

Cómo puede usarlo un equipo

Límites importantes

Conclusión

Claude-Mem: Agregar memoria a largo plazo entre sesiones al código Claude

¿Qué problema resuelve?

Cómo funciona

¿Cuándo es útil?

Instalación y puesta en marcha

Cómo utilizar mem-search

¿En qué se diferencia de la documentación del proyecto?

Cosas a tener en cuenta

Por qué es importante este tipo de herramienta

¿Quién debería intentarlo?

Referencia

Pensamiento final

Codex está empezando a controlar la computadora. ¿Qué significa eso para el futuro?

¿Qué es esta característica?

Por qué esto es importante

Flujos de trabajo que pueden cambiar

1. Mover información a través del software

2. Coordinación entre múltiples herramientas de IA

3. Automatización del software de oficina

Qué significa para los usuarios comunes

Su impacto en el software

No lo exageres todavía

Una última línea

¿Cuál es la diferencia entre ~/.codex/skills y Project .codex/skills en Codex?

La diferencia

~/.codex/skills

proyecto/.codex/skills

Cuándo utilizar habilidades globales y cuándo utilizar habilidades de proyecto

El repositorio actual

Por qué existe una habilidad en el disco pero puede no aparecer en la sesión actual

Cómo hacer que una habilidad esté disponible en la sesión actual

1. Colóquelo en el directorio correcto

2. Haga que el encabezado SKILL.md sea reconocible

3. Abra una nueva sesión después de crearla o editarla

4. Implemente las habilidades para el proyecto antes de comenzar

Una última línea

Usar Agent Skills para sustituir la función de Copilot en VS Code que genera mensajes de commit

Problema y objetivo

Alternativa: git-commit-push-zh

Convención recomendada para mensajes de commit

Fallos habituales

Apéndice: SKILL.md original

Cómo utilizar `mem-search`

`~/.codex/skills`

`proyecto/.codex/skills`

2. Haga que el encabezado `SKILL.md` sea reconocible

Alternativa: `git-commit-push-zh`

Apéndice: `SKILL.md` original