English · Español

00 — Por qué existen las herramientas

🇪🇸 Sin herramientas, el modelo solo sabe lo que aprendió en el entrenamiento. Con herramientas, el modelo puede consultar hechos en el momento (qué dijo lookup_irregular_verb('go'), qué dijo lookup_spanish('worked')) y componer la respuesta usando esos hechos. La diferencia entre adivinar y saber.

---

El techo del conocimiento cerrado

Un modelo de lenguaje puro codifica lo que aprendió durante el entrenamiento. En inferencia no puede:

1. Consultar nada. Si el corpus de entrenamiento decía "el past simple de go es went", el modelo probablemente lo sabe. Si el corpus tenía una errata y decía "goed", el modelo probablemente propaga la errata.
2. Razonar con precisión sobre casos límite. La conjugación tiene muchas reglas pequeñas (-y → -ied para study, -y → -yed para play porque la y va precedida de vocal; el doblado de e en regulares -ed es raro en nuestro conjunto de 20 verbos). El modelo tiene un conocimiento asociativo de estas; no tiene uno algorítmico. Reglas pequeñas con muchas excepciones es exactamente donde los modelos neuronales fallan en la cola larga.
3. Citar una fuente. Si el usuario pregunta por qué "He goed" está mal, el modelo dirá algo fluido. No apuntará a una tabla donde go está marcado como irregular con past_simple = "went".

Las tools arreglan las tres. Una llamada lookup_irregular_verb('go') devuelve la entrada canónica de la tabla de verdad — la que curamos a mano en el corpus de la Fase 12. El modelo ya no adivina; está consultando.

Qué es "una tool", mecánicamente

Una tool, en el sentido de function calling, son exactamente cuatro cosas:

1. Una función Python. Pura, tipada, sin efectos secundarios (en nuestro alcance). Ejemplo:

   def conjugate(verb: str, tense: str, person: str) -> str:
       """Return the conjugated form."""
       ...
   

2. Un descriptor JSON-Schema de los argumentos de la función. Ejemplo:

   {
     "name": "conjugate",
     "description": "Return the conjugated form of an English verb.",
     "input_schema": {
       "type": "object",
       "properties": {
         "verb":   {"type": "string", "enum": [...20 verbs...]},
         "tense":  {"type": "string", "enum": [...5 tenses...]},
         "person": {"type": "string", "enum": [...3 persons...]}
       },
       "required": ["verb", "tense", "person"]
     }
   }
   

3. Un contrato de valor de retorno. Qué forma vuelve. Para conjugate, un string. Para lookup_irregular_verb, un dict.
4. Un contrato de errores. Qué pasa cuando los argumentos están fuera de alcance, los datos subyacentes faltan, etc. Devueltos (no lanzados) como un objeto de error estructurado.

Eso es todo. No hay "IA (AI)" en ninguna de esas cuatro cosas. La IA es lo que elige qué tool llamar y construye los argumentos. La Fase 31 construye las tools (1-4) en el vacío. La Fase 32 las cablea al modelo.

Por qué importa ahora

El agente tutor de gramática de la Fase 32 tiene un bucle estrecho:

1. Receive English sentence from user.
2. Parse the sentence to identify the main verb and subject.
3. Decide whether the verb form matches the inferred tense/person.
4. If a mismatch: propose the correct form (and optional Spanish gloss).
5. Return a structured response.

Los pasos 2-4 son ricos en información. El modelo podría intentar hacerlos por pura asociación — y en casos comunes acertará — pero en casos límite (have, be, do — los verbos más irregulares y frecuentes del inglés) a veces confundirá formas. La capa de tools convierte el paso 4 de "el modelo produce una respuesta" a "el modelo decide qué tool llamar, luego lee la respuesta de la tool". La respuesta está garantizada correcta por construcción porque la tabla de verdad es correcta por construcción.

Este es el patrón retrieval-augmented-generation restringido a un dominio cerrado diminuto. Es el mismo patrón que el RAG de la Fase 29 (lookup → fundamentar respuesta en lookup), solo que con un schema tipado en lugar de una base de conocimiento de texto abierto.

Qué no resuelve esta fase

• Selección de tools. La Fase 31 implementa las tools; la Fase 32 decide cuál llamar. El planificador del agente es lo que hace la selección.
• Composición de resultados de tools. Si el agente llama a dos tools, ¿cómo combina sus salidas? El planificador de la Fase 32. Aquí ni lo intentamos.
• Recuperación de errores de tools. Si conjugate(verb="run", ...) devuelve {"error": "out_of_scope"}, ¿qué hace el agente? Fase 32.

Vista previa del Model Context Protocol (MCP)

Una tool, tal como se ha definido arriba, vive dentro del proceso del agente. El agente importa la función, la llama, obtiene el resultado.

MCP introduce un nivel de indirección: la tool vive en un proceso separado, expuesta sobre un transporte (stdio, SSE, HTTP en streaming). El proceso del agente es un cliente; el host de la tool es un servidor. El formato del wire es JSON-RPC 2.0, con un pequeño registro de convenciones (tools/list, tools/call).

¿Por qué molestarse con la indirección?

1. Aislamiento de procesos. Una tool con mal comportamiento cuelga el servidor de tools, no el agente. El sandbox de la Fase 32 usa esto.
2. Independencia del lenguaje. Un agente Python puede llamar a una tool Rust. Al protocolo le da igual.
3. Descubribilidad. El agente puede preguntar tools/list y aprender qué hay disponible, en vez de necesitar conocimiento previo del catálogo de tools.
4. Reutilización. El mismo servidor de tools puede servir a varios clientes agente.

La Fase 31 construye el MCP mínimo — suficiente para demostrar el protocolo sobre stdio con un cliente y un servidor. La capa de serving de la Fase 33 expondrá el agente sobre HTTP, y el servidor de tools se queda en stdio detrás.

El puente Fase 30 → Fase 31

Un mensaje de tool call se parece a (formato de Anthropic, similar al de OpenAI):

{
  "method": "tools/call",
  "params": {
    "name": "conjugate",
    "arguments": {"verb": "eat", "tense": "past_simple", "person": "3sg"}
  }
}

El objeto arguments debe conformarse al input schema de la tool. El JSONSchemaMask de la Fase 30 es exactamente el mecanismo que garantiza que el modelo emita un objeto arguments válido. Sin la máscara, el modelo a veces emite {"verb": "ate", ...} (una forma conjugada en lugar del lema) o {"tense": "past"} (un string fuera del enum). Con la máscara, el modelo queda restringido al enum en tiempo de decodificación y no puede producir un blob de argumentos inválido.

Este es el primer pago concreto de la Fase 30. El lab 03 de la Fase 31 lo demuestra explícitamente.

El cuadro general

El arco de la Fase 30 a la Fase 33 es:

• Fase 30: el modelo produce salida estructurada (restringido por máscara).
• Fase 31: la salida estructurada despacha a tools (esta fase).
• Fase 32: el bucle del agente encadena tool calls en planes multi-paso.
• Fase 33: todo el stack se expone sobre HTTP.

Cada fase es una capa fina sobre la anterior. La Fase 31 es el tejido conectivo — sin ella, el modelo emite JSON sobre el que nada actúa; sin ella, la Fase 32 no tiene nada con qué planificar.

Qué NO cubre esta fase

• Selección de tools / planificación. Fase 32.
• Ejecución en sandbox. Fase 32.
• Transportes HTTP / streaming. Fase 33.
• Caching de tools. Un conjugate(verb=eat, tense=past_simple, person=3sg) repetido se re-ejecuta desde cero. La Fase 33 podría añadir un cache LRU; fuera de alcance aquí.
• Versionado de tools. El schema de una tool puede evolucionar; no lo rastreamos hasta la Fase 38 (MLOps).

---

Siguiente: theory/01-function-calling-formats.md — la encuesta de los principales formatos de tool call y por qué todos convergen en la misma forma.