¿De qué tipo de herramientas básicas necesita un Agente?

Viendo que todos hablan sobre el conjunto de herramientas del Agente—¿es suficiente con proporcionar un shell para resolverlo todo? Después de hacer holon, me di cuenta de que en realidad no es tan simple.
Lectura: por qué abandonamos Read/Glob, y optamos por todo con shell
El conjunto de herramientas de holon cambió varias versiones, y finalmente descartó herramientas especializadas similares a Read (leer archivos) y Glob (búsqueda por patrones) que ofrece Claude Code, confiando toda la lectura y búsqueda en shell. Esto sigue la misma línea que Codex—la función ExecCommand de Codex es simple, leer archivos con cat, buscar código con rg, sin definir herramientas específicas para cada operación de "lectura".
La razón de esto es muy sencilla: shell es el "lenguaje de programación" más familiar para los LLM. En lugar de hacer que el modelo aprenda los parámetros semánticos de tu herramienta Read, es mejor que escriba directamente comandos shell que ya han sido entrenados decenas de miles de millones de veces. Cada herramienta especializada añade una capa de carga cognitiva al modelo; en cambio, la interfaz shell, el modelo ya la domina bastante.
Pero usar solo shell tiene un costo: la truncación de salida. Para evitar que los valores retornados por shell sean demasiado largos y saturen el contexto, el marco establece límites en la salida de cada comando. Si el Agente usa cat para leer un archivo grande, solo obtendrá la primera parte, y el resto estará en un archivo artifact, requiriendo más cat para leerlo completo. La herramienta Read de Claude Code tiene un umbral de compresión mucho más alto que un shell general, permitiendo leer archivos grandes en una sola operación, evitando múltiples idas y vueltas. Es una cuestión de compromiso: definir menos herramientas reduce la carga cognitiva, pero las herramientas especializadas son más eficientes en escenarios límite.
Escribir: desde sed hasta ApplyPatch, y los desafíos de la herramienta de gramática libre
Pero las operaciones de escritura no se pueden hacer completamente solo con shell.
Si se hace que el Agente edite solo con sed, se enfrentará a dificultades con coincidencias complejas en múltiples líneas—saltos de línea, escape, indentación—cualquier error en esas capas puede hacer que la edición falle. Por eso, muchos sistemas ofrecen herramientas de edición como Replace String, que permiten que el Agente pase una gran cadena old_string para hacer coincidencias precisas y reemplazos con new_string. Aunque es torpe, es mucho más estable que sed.
Codex va aún más lejos, inventando su propia herramienta ApplyPatch, que permite al Agente generar directamente un parche, haciendo ediciones en lote en una sola operación. holon también se inspira en esta idea.
Pero al implementarlo, encontramos un problema: Codex usa un formato de parche simplificado definido por OpenAI, y combina esto con una herramienta especial llamada free grammar tool para resolver problemas de formato.
¿Por qué crear un mecanismo nuevo? Porque la definición estándar de herramientas en los LLM es tool(args) en formato JSON. Si pasamos el parche como una cadena JSON, implica muchas escapadas—los saltos de línea deben cambiarse, las comillas deben escaparse, la indentación debe manejarse con cuidado. Es fácil que el Agente cometa errores al escribir parches, y agregarle una capa de escape JSON aumenta la probabilidad de errores. La idea de free grammar tool es pasar el texto original del parche directamente como entrada de la herramienta, sin codificación JSON, permitiendo que lo que el modelo escriba sea exactamente lo que se necesita. Esto reduce significativamente los errores en la generación de parches.
Actualmente, solo la interfaz de Codex de OpenAI soporta este mecanismo. holon busca compatibilidad con múltiples proveedores de modelos, por lo que no puede depender solo de esto.
Por eso, holon adopta un enfoque: inyecta diferentes definiciones de ApplyPatch según el modelo. Para los que soportan free grammar, usa el formato de parche original; para otros, recibe el formato estándar git diff. Creo que, tras entrenar en decenas de miles de millones de diffs en GitHub, los LLM son bastante competentes en git diff. La práctica muestra resultados aceptables—aunque a veces comete errores, en la mayoría de los casos los corrige bien, y con más datos de entrenamiento, esta capacidad solo mejorará. Aún así, recomiendo que todos los proveedores de modelos soporten free grammar tool, ya que es una necesidad real para la escritura de código del Agente.
Orquestación: comandos de larga duración y abstracción de tareas
El tercer problema es que los comandos shell que ejecuta el Agente no siempre terminan rápidamente—arrancar un servidor de desarrollo, correr pruebas, construir un proyecto, pueden durar mucho tiempo o no terminar nunca. Los primeros marcos de Agentes manejaban esto de forma muy burda: o bloqueaban sincronizadamente, quedándose atascados, o enviaban todos los comandos al background, lo que provocaba que el Agente repitiera muchas veces el mismo comando.
Hoy en día, la industria ha llegado a un consenso: no exponer al Agente la opción de "delante/detrás"—porque el Agente no puede decidirlo con precisión. La mejor estrategia es establecer un umbral de tiempo, y si un comando excede ese tiempo, se pasa automáticamente al background, de forma transparente para el Agente. El Agente no necesita predecir si debe enviarlo al background, el runtime se encarga.
Pero pasar al background es solo el primer paso. Después, surgen problemas reales de ingeniería—y actualmente no hay una respuesta estándar.
Primero, cómo leer la salida. Las tareas en background pueden seguir en ejecución o ya haber terminado, y la salida puede ser muy grande. Pero las API de diferentes proveedores no son uniformes—algunas usan sondeos, otras eventos push.
Segundo, cómo detener la tarea. Todos tienen mecanismos de cancelación, pero ¿debería ser un kill instantáneo o una salida elegante? ¿Se deben conservar las salidas parciales?
Tercero, quién despierta al Agente. Cuando el Agente envía una tarea al background y entra en modo de suspensión, ¿quién lo despierta cuando termina? Esto requiere una integración profunda entre el runtime y la gestión del Agente, no puede resolverse solo con herramientas independientes.
Estas tres cosas—leer salida, detener tareas, despertar al Agente—constituyen la gestión completa del ciclo de vida de tareas en background. Aunque todos soportan "ejecución en background", aún no hay un estándar para su gestión, y esto puede ser un punto clave en la evolución futura de la cadena de herramientas del Agente.
Aún no es momento de usar un patrón predefinido sin pensar
Por eso, volviendo a la pregunta inicial: shell puede resolver el 80%, pero ese 20% restante—precisión en edición, formato de parches y capacidad del modelo para manejar tareas largas—es lo que realmente determina si un Agente puede pasar de un prototipo a un sistema verdaderamente útil.
La elección del conjunto de herramientas no es solo "envolver un shell", y todavía no estamos en un punto donde todos puedan aplicar ciegamente un patrón predefinido. Por eso, Codex y Claude Code ofrecen respuestas diferentes a estos problemas básicos, y holon hace diferentes concesiones según su escenario. Hay mucho por explorar y mejorar en este campo.