Enrutamiento de modelos para agentes móviles: Kimi, DeepSeek, GLM y FoneClaw

Elegir una ruta, no un ganador permanente

El enrutamiento de modelos para agentes móviles es la decisión de enviar cada tarea del agente al modelo que mejor encaja con su riesgo, coste, latencia, contexto, idioma y necesidad de llamadas a herramientas. En un agente Android, la pregunta correcta no es qué modelo gana para siempre, sino qué ruta produce una acción fiable en este dispositivo, con estos permisos y con este nivel de revisión.

Una tabla estática envejece rápido porque la disponibilidad, el precio y el comportamiento de los modelos cambian. Kimi K3 puede aparecer en un selector popular, DeepSeek puede resultar atractivo por coste o razonamiento, GLM puede entrar en evaluaciones exigentes, y aun así ninguno de esos datos prueba por sí solo que el modelo maneje bien una acción de teléfono. Un benchmark de texto no mide si el agente elige el contacto correcto, prepara argumentos válidos para una herramienta, espera aprobación o se recupera cuando Android muestra una pantalla inesperada.

Por eso conviene pensar en rutas. Una nota breve puede usar un modelo rápido. Una tarea con varias apps puede necesitar un modelo más fuerte en planificación. Una acción sensible puede exigir un modelo estable en salidas estructuradas y más controles de aprobación en el runtime. En FoneClaw separamos esas capas: el modelo ayuda a comprender y planificar; FoneClaw conserva la ejecución Android gobernada.

Si lo que necesitas es configurar endpoints y no solo elegir criterios, la guía Conectar una API de modelo de IA a un agente Android en FoneClaw explica la parte operativa de conexión sin duplicarla aquí.

Fiabilidad, latencia, coste, contexto y privacidad

La primera señal es la fiabilidad. Para un phone agent, fiabilidad significa que el modelo entiende la petición, mantiene el objetivo, respeta el esquema de herramienta, entrega argumentos estables y reconoce cuándo falta información. Un modelo puede redactar muy bien y fallar en algo más importante para Android: elegir una acción no soportada, inventar un estado del dispositivo o saltarse una confirmación que el producto necesita mostrar.

La segunda señal es latencia. En el móvil, el usuario mira la pantalla mientras espera. Si la tarea es abrir una app, preparar un mensaje corto o consultar estado del dispositivo, una ruta lenta rompe la sensación de control. Las tareas más complejas toleran más tiempo si el agente muestra progreso y conserva continuidad, pero la política debe distinguir entre una interacción rápida y un plan largo.

La tercera señal es coste. El coste de LLM no se evalúa solo por llamada aislada; se evalúa por tarea completada. Un modelo barato que genera argumentos inválidos puede consumir más reintentos, más tokens y más tiempo humano que un modelo más caro pero estable. Al revés, usar siempre el modelo más potente para tareas simples infla gasto sin mejorar la acción Android.

La cuarta señal es contexto. Más contexto no siempre mejora el resultado. Si la tarea necesita la pantalla actual, un hilo largo o una instrucción previa, el modelo debe manejarlo sin perder el objetivo. Si la tarea es concreta, un contexto excesivo puede aumentar coste y ruido. En agentes móviles, el contexto útil es el que ayuda a elegir la acción correcta y a mostrar un resultado verificable.

La quinta señal es privacidad y despliegue. Una ruta local, una ruta online predeterminada y una ruta personalizada tienen límites distintos. Algunas tareas encajan con modelos soportados en el dispositivo; otras necesitan un proveedor online compatible. La política debe dejar claro qué datos salen del teléfono, qué se queda en Android y qué aprobaciones se requieren antes de una acción sensible.

Kimi, DeepSeek y GLM como candidatos actuales

Kimi, DeepSeek y GLM son buenos ejemplos para hablar de enrutamiento porque representan una etapa donde el mercado ofrece más rutas, no una sola respuesta. Kimi K3 ganó visibilidad al aparecer como modelo seleccionable en GitHub Copilot, según el anuncio de disponibilidad de Kimi K3 en GitHub Copilot. Esa señal confirma distribución en un producto de desarrollo, pero no prueba fiabilidad automática en llamadas a herramientas de Android.

DeepSeek suele entrar en conversaciones de coste, razonamiento y rendimiento práctico. Para un agente móvil, esa conversación debe aterrizarse en pruebas propias: ¿mantiene instrucciones de herramienta?, ¿pide aclaración cuando hay contactos ambiguos?, ¿se adapta al español natural?, ¿produce salidas que FoneClaw pueda convertir en pasos visibles? Sin esa validación, un modelo barato o rápido puede ser una buena hipótesis, no una política.

GLM aporta otra hipótesis: modelos que compiten por razonamiento y capacidades generales pueden ser candidatos para tareas complejas, pero la ruta real depende del endpoint, los límites del proveedor, la estabilidad de respuesta y el tipo de dato. Si el flujo requiere mucho contexto, GLM puede ser candidato; si requiere una acción breve y repetida, quizá convenga otra ruta. El punto es comparar comportamientos en tareas del teléfono, no solo nombres.

También crece la capa de infraestructura. Google Cloud anunció una API unificada para enrutamiento de modelos en vista pública, una señal clara de que los equipos quieren gestionar múltiples proveedores desde una superficie común. Para FoneClaw, esa tendencia confirma el criterio de producto: admitir rutas compatibles cuando tienen sentido, mientras la ejecución Android permanece gobernada por el runtime y no por la marca del modelo.

Responder a cambios de precio y disponibilidad

Una política de enrutamiento debe cambiar cuando cambian precio, disponibilidad, límites de uso o comportamiento del modelo. Lo importante es no cambiar de proveedor de forma invisible en tareas sensibles. Si una ruta se encarece, falla más o pierde disponibilidad, el sistema puede elegir un fallback, pero antes necesita revalidar esquema, latencia, calidad de idioma, límites de contexto y comportamiento ante herramientas.

El precio merece una lectura disciplinada. No uses precios exactos no verificados ni conviertas una oferta temporal en arquitectura. Define umbrales: cuánto puede costar una tarea de bajo riesgo, cuánto tolera una tarea compleja, cuándo se activa un modelo alternativo y cuándo se pide confirmación al usuario porque el cambio afecta coste, privacidad o calidad esperada. Para profundizar en ahorro sin reducir la calidad de acción, enlazamos Coste de tokens en agentes de IA: por qué hacer más en Android puede ahorrar dinero.

La disponibilidad también debe tener fallback. Si la ruta principal no responde, el agente puede pasar a una ruta secundaria para redactar o resumir, pero una acción Android con consecuencia necesita mantener la revisión. Cambiar de modelo no cambia el contrato: mostrar qué se hará, pedir aprobación si corresponde y comprobar el resultado.

En nuestra práctica, los fallos se registran por modo de fallo, no solo por respuesta incorrecta. Hay fallos de latencia, de argumentos, de idioma, de contexto, de permiso, de estado de pantalla y de recuperación. Esa clasificación permite ajustar el enrutamiento sin perseguir rankings cambiantes.

Medir calidad dentro del bucle Android

La calidad de un modelo para un agente Android se mide dentro del bucle completo: intención, plan, herramienta, permiso, aprobación, ejecución, resultado y recuperación. Un modelo puede resolver bien la parte conversacional y aun así producir una acción pobre si no respeta el estado real del dispositivo. Por eso el mejor modelo para agente Android se descubre probando tareas del teléfono, no solo prompts aislados.

Empieza por una tarea reversible. Pide crear una nota, preparar un mensaje sin enviarlo, revisar un evento, consultar estado del dispositivo o abrir una ruta para confirmación. Evalúa si el modelo interpreta la intención y si entrega una estructura que el agente pueda usar. Después mira la capa Android: qué permiso se solicita, qué pantalla aparece, qué confirmación se muestra y qué resultado queda visible.

La fiabilidad de llamadas a herramientas se observa en detalles pequeños. ¿El modelo distingue entre buscar un contacto y llamar? ¿Pide elegir cuando hay dos nombres parecidos? ¿Evita inventar una app instalada? ¿Entrega fechas, números, destinatarios y acciones en un formato consistente? ¿Se detiene cuando la instrucción supera las capacidades disponibles?

Para pruebas más amplias, la guía Benchmark de agentes Android: cómo evaluar un phone agent en 2026 desarrolla métricas de ejecución, no solo calidad textual. La diferencia importa: un agente telefónico fiable debe completar o detener una tarea de forma clara en el dispositivo exacto, con permisos reales y estado real.

Configurar razonamiento mientras FoneClaw gobierna la acción

En FoneClaw construimos el enrutamiento desde una frontera deliberada: el modelo razona y FoneClaw ejecuta Android. El usuario puede empezar con el modelo gratuito predeterminado, configurar una ruta online compatible o usar rutas soportadas en el dispositivo cuando encajan. Esa elección afecta comprensión, planificación, coste, latencia y privacidad; no convierte al modelo en autoridad directa sobre todas las apps.

FoneClaw aporta la capa operativa. Las acciones compatibles se realizan mediante 100+ built-in tools, con resultados visibles, permisos del sistema, aprobación en pasos sensibles, parada y recuperación. AutoAttach, Suggest y Fallback ayudan a conectar intención, contexto y capacidad, pero no omiten aprobaciones. Si una herramienta no está disponible, si el permiso falta o si Android exige intervención, el flujo debe explicarlo y dejar un siguiente paso útil.

Un ejemplo: el usuario pide preparar una respuesta a un contacto después de leer una pantalla. Una ruta de modelo puede manejar el contexto y redactar el texto. FoneClaw decide si puede usar la pantalla actual, si hay una herramienta compatible, si el contacto está claro y si el paso requiere confirmación. El modelo no envía por sí solo; FoneClaw muestra el contenido y conserva la decisión donde importa.

Esta separación nos permite mejorar el producto sin atarnos a un ganador estático. Si Kimi, DeepSeek, GLM u otra ruta encajan mejor para una clase de tareas, pueden evaluarse como motores de razonamiento. La acción Android sigue pasando por el mismo criterio: soporte real, permiso claro, resultado visible y recuperación. Para lectores que quieren ver el mapa de acciones, Control del teléfono con agente de IA: qué puede hacer de verdad un phone AI agent conecta la decisión de modelo con la ejecución práctica.

Una política práctica de enrutamiento

Una política útil empieza clasificando tareas. Divide entre conversación, redacción, resumen, lectura de pantalla, planificación multietapa y acciones con consecuencia. Después fija un piso de calidad: el modelo debe entender español natural, respetar el esquema de herramienta, pedir aclaración cuando falten datos y no inventar capacidades Android.

Luego define un techo de coste y una expectativa de latencia. Las tareas frecuentes necesitan rutas eficientes. Las tareas complejas pueden justificar modelos más fuertes. Las tareas sensibles necesitan confirmación y quizá rutas con mejores garantías de estabilidad, aunque tarden más. El fallback se define antes del fallo: qué modelo entra, qué datos recibe y qué acciones quedan bloqueadas hasta nueva aprobación.

Finalmente, prueba en el teléfono. Usa el mismo dispositivo, la misma cuenta, los mismos permisos y la misma app para comparar dos rutas. Registra fallos de herramienta, latencia, costes aproximados, aclaraciones necesarias, pasos de aprobación y recuperación. No basta con anotar si la respuesta sonó bien; anota si la tarea terminó o quedó en un punto útil.

La política no es fija. Cambia cuando cambian modelos, proveedores, precios, endpoints o capacidades Android. Lo duradero es el método: enrutar por señales, revalidar con tareas reales y mantener la ejecución gobernada. En FoneClaw, ese método nos permite aprovechar modelos actuales sin convertir cada novedad en una promesa pública de control universal del teléfono.