La herramienta de shell no es una solución mágica para la ingeniería de contexto

Las herramientas más importantes con las que cuenta un agente son las herramientas de búsqueda que puede usar para construir su propio contexto. Publicaciones recientes de LlamaIndex y LangChain han desatado una discusión: ¿Son una herramienta shell y un sistema de archivos todo lo que un agente necesita para la ingeniería de contexto? Desafortunadamente, la discusión se desvió rápidamente hacia el enfoque equivocado: filesystem versus base de datos.

Esta publicación vuelve a centrarse en la pregunta:¿Cuáles son las interfaces de búsqueda adecuadas que necesita un agente para construir su propio contexto? Primero, cubre las disyuntivas entre las herramientas de shell y las herramientas de base de datos especiales. A partir de ahí, te ofrece un marco de trabajo práctico para encontrar las interfaces adecuadas a las necesidades de tu agente.

¿Qué significa realmente "construir contexto" para un agente?

En las primeras pipelines de retrieval augmented generation (RAG), el desarrollador diseñó un pipeline de recuperación fija y el modelo de lenguaje grande (LLM) era un receptor pasivo del contexto. Esta era una limitación fundamental: el contexto se recuperaba en cada consulta, fuera o no necesario, sin verificar que realmente ayudara.

Con el cambio a la RAG agéntica, los agentes ahora tienen acceso a un conjunto de herramientas de búsqueda para crear su propio contexto. Por ejemplo, tanto Claude Code [1] como Cursor [2] permiten que el agente elija entre diferentes herramientas de búsqueda e incluso las combine para consultas encadenadas, dependiendo de lo que la tarea realmente requiera.

¿Qué interfaces de búsqueda existen para la ingeniería del contexto?

El contexto puede estar en diferentes lugares, como en la web, en un sistema de archivos local o en una base de datos. Un agente puede interactuar con cada una de estas fuentes de datos fuera de contexto mediante diferentes herramientas:

• Las herramientas de shell pueden ejecutar comandos de shell y tener acceso al sistema de archivos local. Algunos ejemplos de herramientas de shell integradas son la herramienta bash de Claude API, la herramienta ejecutiva de OpenClaw y la herramienta de shell de LangChain.
• Las herramientas de base de datos especiales, como las herramientas de un servidor Model Context Protocol (MCP) (p. ej., el servidor MCP de Elastic Agent Builder) o las herramientas personalizadas (p. ej., run_esql(query) o db_list_index()), pueden consultar bases de datos.
• Las herramientas especiales de búsqueda de archivos pueden buscar y leer archivos locales (o subidos) (sin acceso completo al shell). Algunos ejemplos de herramientas de búsqueda de archivos integradas son Herramienta de búsqueda de archivos de Gemini API o Herramienta de búsqueda de archivos de OpenAI.
• Las herramientas de búsqueda web pueden recuperar información de la web.
• Las herramientas de memoria almacenan y recuperan de la memoria a largo plazo (independientemente de cómo se almacene).

Como puedes ver, la herramienta shell es versátil y se puede usar para recuperar contexto de diferentes fuentes de datos, incluyendo:

• Sistema de archivos: el agente explora la estructura de directorios (ls, find), busca contenido relevante (grep, cat) y repite hasta que ha construido suficiente contexto.
• Base de datos: el agente puede usar herramientas de interfaz de línea de comandos (CLI) para bases de datos (por ejemplo, elasticsearch-sql-cli), llamar al HTTP de la API mediante curl o ejecutar scripts, lo cual resulta especialmente útil en combinación con las habilidades del agente, que son ejemplos reutilizables y documentados que se incorporan al contexto del agente para guiar el uso correcto de las herramientas (por ejemplo, Elastic Agent Skills para Elasticsearch).
• Web: el agente puede ejecutar búsquedas web mediante un comando curl a través de la API de un proveedor de búsqueda.

Sin embargo, la herramienta de shell proporciona acceso directo al sistema y, por lo tanto, requiere medidas de seguridad, como ejecutarse en un entorno sandbox aislado y el logging de todos los comandos ejecutados.

Cuándo deberías usar ciertas interfaces de búsqueda

La interfaz de búsqueda adecuada depende de tus datos, tus patrones de consulta y tu caso de uso. Esta sección sirve como un punto de partida práctico.

Los sistemas de archivos no hacen que las bases de datos sean obsoletas.

La discusión entre sistemas de archivos y bases de datos no es sobre la capa de almacenamiento. Por ejemplo, LangChain explica que su sistema de memoria en realidad no almacena la memoria en un verdadero sistema de archivos. En su lugar, almacena la memoria en una base de datos y la representa como un conjunto de archivos para el agente [3].

Los sistemas de archivos son una opción natural para casos de uso nativos de archivos, como los agentes de codificación. También funcionan bien como bloc de notas temporal o memoria de trabajo, y en situaciones con un solo usuario o un solo agente en las que la concurrencia no es un problema. En estos casos, un sistema de archivos físico o representar los datos como un sistema de archivos te da flexibilidad antes de comprometerte con una interfaz diseñada específicamente para ello.

Pero el almacenamiento en sistemas de archivos tiene desventajas reales, como una concurrencia limitada, la aplicación manual de esquemas y las transacciones atómicas. Estos se vuelven más evidentes cuando tu aplicación necesita escalar o pasar a un escenario de múltiples agentes. Cualquiera que ignore estas desventajas está condenado a reinventar dolorosamente bases de datos peores sin las décadas de ingeniería detrás de la seguridad de transacciones o el control de acceso que las bases de datos de producción ya proporcionan. Además, en la mayoría de contextos empresariales, no eliges si usar una base de datos porque ya está ahí, almacenando datos críticos para el negocio.

Herramienta de shell + sistema de archivos

Una herramienta shell es el punto de partida natural para la búsqueda en sistemas de archivos. En la actualidad, los agentes de codificación están impulsando muchos avances en este campo. Como trabajan con código en archivos locales, son, por naturaleza, casos de uso que implican un gran volumen de archivos. Por lo tanto, los LLM se ajustan en la etapa posterior al entrenamiento para tareas de codificación. Es por eso que muchos LLMs no solo son buenos para escribir código, sino también para usar comandos de shell y navegar por sistemas de archivos.

Usar una herramienta de shell con CLI integradas, como ls y grep, para encontrar archivos es efectivo. Con grep, una consulta como "Encontrar todos los archivos que importan matplotlib" es rápida, precisa y económica. Pero cuando el agente necesita manejar consultas conceptuales, como "¿Cómo maneja nuestra app la falla de autenticación?", la coincidencia de patrones con grep puede alcanzar un límite rápidamente. Han surgido varias alternativas que incorporan capacidades de búsqueda semántica a la línea de comandos para cubrir esta carencia, incluidas jina-grep.

Sin embargo, grep y muchas de sus alternativas de búsqueda semántica se ejecutan en O(n) sobre el corpus. Para casos de uso sobre bases de código, esto podría estar bien. Sin embargo, si tus datos crecen, la latencia se notará. En este caso, un almacén de datos indexado se vuelve necesario para mantener el rendimiento.

Herramienta de shell + base de datos

Otra forma de agregar más capacidades de búsqueda, como la búsqueda semántica o híbrida, a tus datos es almacenarlos en una base de datos, como hace Cursor, por ejemplo. Además, cuando los datos requieren uniones relacionales o agregaciones complejas, una interfaz de base de datos es imprescindible.

Cuando los datos se almacenan en una base de datos en lugar de en el sistema de archivos, una herramienta de shell puede servir como una interfaz ligera de base de datos para ciertos casos de uso. Si tus consultas son lo suficientemente simples para una CLI o una llamada curl, una herramienta de base de datos especial podría añadir una complejidad innecesaria.

Este enfoque también es adecuado en las etapas iniciales de exploración, cuando aún no sabes qué patrones de consulta desarrollará tu agente. En este caso, Agent Skills puede darle al agente suficiente estructura para consultar correctamente sin comprometerse con una herramienta específica. Sin embargo, cuando el agente requiere muchas iteraciones para encontrar la forma correcta de consultar en la base de datos para tareas repetidas, la sobrecarga de tokens de usar una herramienta de línea de comandos como interfaz ya no justifica el beneficio de la simplicidad de evitar una herramienta adicional.

Herramienta especial de base de datos

Especialmente cuando los patrones de consulta repetidos son estructurados o analíticos, se hacen necesarias herramientas de base de datos especiales. Una publicación de blog de Vercel y Braintrust comparó a los agentes con diferentes conjuntos de herramientas de búsqueda para tareas de recuperación del mundo real en lugar de datos estructurados, como tickets de atención al cliente y transcripciones de llamadas de ventas (por ejemplo, “¿Cuántos problemas abiertos mencionan 'seguridad'?" o "¿Encontraste problemas en los que alguien reportó un error y luego alguien envió un PR diciendo que lo había arreglado?") [4].

Los agentes con herramientas de base de datos especiales utilizaron menos tokens, fueron más rápidos y cometieron menos errores que los agentes con solo una herramienta de shell y un sistema de archivos. La conclusión es que las herramientas de bases de datos directas son la opción correcta cuando la consulta requiere razonamiento analítico sobre datos semiestructurados.

Combinar interfaces de búsqueda

Ninguna interfaz de búsqueda gestiona bien todas las consultas. Por ejemplo, Cursor combina herramientas de shell (para búsquedas con grep) y herramientas de búsqueda semántica, y permite que el agente seleccione la herramienta correcta según el mensaje del usuario. Informa que el agente elige grep para hacer coincidir símbolos o textos específicos, búsqueda semántica para preguntas conceptuales o de comportamiento, y ambos para tareas exploratorias.

El experimento de Vercel presenta el mismo reporte: su agente híbrido con acceso tanto a una herramienta de shell como a una herramienta dedicada para bases de datos logró el mejor rendimiento de todos los agentes probados al usar primero las herramientas dedicadas para bases de datos y luego verificar los resultados mediante búsquedas con grep en el sistema de archivos. Sin embargo, este enfoque utiliza más tokens y tiempo para razonar sobre la elección de herramientas y la verificación.

El patrón en ambos ejemplos es el mismo: La combinación es superior a cualquier interfaz individual, pero conlleva un costo y una latencia adicionales.

Recomendaciones prácticas para encontrar el conjunto adecuado de herramientas

El conjunto adecuado de interfaces de búsqueda es pequeño, intencionado y específico para los patrones de consulta reales de tu agente. Las mejores prácticas actuales son tener un agente con la menor cantidad de herramientas posible en lugar de tener un agente con cientos de herramientas MCP. Esto se debe a que la desventaja de exponer todas las herramientas posibles de antemano es que infla la ventana de contexto y confunde al agente sobre qué herramienta usar realmente. Por ejemplo, se dice que Claude Code solo tiene unas 20 herramientas.

En cambio, la idea de la divulgación progresiva es comenzar con un conjunto mínimo de herramientas y dejar que el agente descubra capacidades adicionales solo cuando sea necesario. Investigaciones de Anthropic [5] y Cursor [6] demostraron que este enfoque genera un ahorro de tokens entre el 47%–85%. Claude Code, por ejemplo, implementa esto directamente, lo que permite al agente descubrir de forma incremental cómo consultar una API o una base de datos, sin que ese conocimiento consuma contexto en cada llamada al LLM.

Una vez que te familiarices con los patrones de búsqueda del agente, puedes volver a revisar el conjunto de herramientas de búsqueda a las que el agente tiene acceso de forma predeterminada. Una forma útil de pensar en este compromiso es el "principio de piso bajo, techo alto" para decidir qué herramientas son las adecuadas. Las herramientas de alto nivel no limitan el potencial del agente. Por ejemplo, una herramienta de shell versátil permite al agente escribir consultas de base de datos completas, incluidas las ambiguas, pero a costa de una mayor sobrecarga de razonamiento, latencia más alta y menor confiabilidad.

Las herramientas de bajo umbral son todo lo contrario. Son herramientas especializadas que encapsulan búsquedas específicas y son inmediatamente accesibles para el agente con una mínima sobrecarga de razonamiento, ofreciendo menor costo y mayor confiabilidad. No obstante, requieren ingeniería previa, no pueden cubrir cada posible consulta y pueden dificultar que el agente elija la herramienta correcta.

Piensa en cada herramienta en un espectro: las herramientas de bajo nivel son fáciles de usar correctamente para el agente, pero tienen un alcance limitado. Las herramientas de alto potencial son versátiles pero requieren más razonamiento para usarlas bien.

La mayoría de los agentes necesitan una combinación de diferentes herramientas de búsqueda. Pero cada herramienta necesita aportar algo. Recomendamos comenzar con una herramienta de búsqueda multiuso (por ejemplo, una herramienta search_database() o una herramienta de shell). Luego, reutiliza los registros de comandos que ya conservas por motivos de seguridad para rastrear lo que realmente hace tu agente, incluidas las llamadas a herramientas, los reintentos y el número de llamadas por consulta de usuario. Y, cuando ves que un patrón de consulta se repite o falla, esa es la señal para construir una herramienta especialmente diseñada para ello.

Resumen

El debate entre sistema de archivos y base de datos distrae de la pregunta real que los ingenieros deben hacerse: ¿Cuáles son las interfaces de búsqueda adecuadas que un agente necesita para construir su propio contexto? La respuesta es muy probable, no una sola.

Una herramienta de shell es una herramienta versátil para interactuar con diferentes fuentes fuera de contexto y, por lo tanto, un buen punto de partida. Sin embargo, resulta menos eficiente y precisa para casos de uso con consultas analíticas estructuradas que las herramientas de bases de datos especializadas.

El objetivo es encontrar el conjunto mínimo de herramientas de búsqueda que manejen bien los patrones reales de consulta de tu agente. Empieza con una herramienta de shell y registra lo que realmente hace tu agente. Cuando veas un patrón de consulta que se repite y falla, es momento de diseñar herramientas especializadas.

Referencias

1. Thariq (Anthropic). Lessons from Building Claude Code: Seeing like an Agent (2026).

2. Cursor: Documentation. Semantic & agentic search (2026).

3. Harrison Chase (LangChain). Cómo construimos el sistema de memoria de Agent Builder (2026).

4. Ankur Goyal (Braintrust) y Andrew Qu (Vercel). Testing if "bash is all you need" (2026).

5. Anthropic. Introducing advanced tool use on the Claude Developer Platform (2025).

6. Cursor. Dynamic context discovery (2026).