DeepSeek V3.2 con herramientas: cómo auditar el estado de razonamiento antes de mantener o migrar un agente

La pregunta operativa: ¿la integración conserva el estado correcto?

DeepSeek V3.2 incorporó compatibilidad con llamadas a herramientas en modo de pensamiento, según el anuncio del proveedor y su guía de herramientas. Esa capacidad permite plantear una pregunta concreta de ingeniería: cuando el asistente solicita una herramienta, la aplicación la ejecuta y el resultado vuelve al modelo, ¿se conserva en la siguiente petición el estado que requiere la API? La respuesta no se obtiene por el nombre del modelo ni por una demostración aislada. Hay que comprobar el contrato de mensajes y las respuestas que realmente procesa la aplicación.

El foco de este análisis es acotado: auditar una integración existente o evaluar qué evidencia falta antes de mantenerla o planificar un cambio. No se intenta medir la inteligencia general del modelo, comparar puntuaciones ni inferir cómo razona internamente. Una llamada a una herramienta que parece correcta en una prueba manual no demuestra que el servicio soporte bien los reintentos, el streaming, los resultados inesperados o el siguiente turno del usuario.

La documentación de DeepSeek indica que, cuando se usan herramientas en modo de pensamiento, las solicitudes posteriores de ese turno deben devolver el campo `reasoning_content` junto con el estado relevante. También documenta que omitirlo en las circunstancias descritas puede producir un error 400. La consecuencia práctica es importante: una capa intermedia que reconstruya el historial, filtre campos o convierta formatos puede romper la secuencia aunque la primera petición funcione.

La disponibilidad de un nombre de modelo es una comprobación distinta de la corrección del flujo. DeepSeek ofrece un endpoint para consultar los modelos disponibles; su resultado debe verificarse en el entorno y la fecha de la prueba, no deducirse de un ejemplo estático ni del nombre de una página. Del mismo modo, una referencia a V4 en el centro de transparencia no acredita por sí sola que un identificador concreto esté habilitado para una cuenta, ni que una integración pueda cambiar a él sin ajustes.

Reconstruir el ciclo sin perder mensajes

Una prueba fiable empieza por representar el flujo como una secuencia explícita. La aplicación envía mensajes al modelo; este puede devolver una solicitud de herramienta; la aplicación ejecuta la operación autorizada y añade el resultado como mensaje de herramienta; después remite la continuación al modelo. En una interacción con modo de pensamiento y herramientas, la guía de DeepSeek añade una exigencia de conservación de `reasoning_content` en las solicitudes posteriores pertinentes. El detalle exacto depende del formato de API y de la forma de la respuesta, por lo que conviene inspeccionar la referencia del endpoint que usa la integración.

No reduzcas el historial a una frase como «el modelo pidió buscar». En los registros de prueba conserva la secuencia de roles, los identificadores de llamada si los hay, los argumentos emitidos, el resultado asociado a cada llamada y los campos que la integración reenvió. Si el producto transforma la respuesta antes de guardarla, registra también esa transformación o una huella comparable. Así se puede distinguir un error del modelo de un mensaje eliminado por el middleware, una llamada mal asociada o un resultado que nunca llegó a la siguiente petición.

La API de Chat Completions no debe confundirse con otros formatos que DeepSeek documenta. La guía de herramientas diferencia cómo se insertan llamadas en Chat Completions, Anthropic API y Responses API. Una integración que cambia de formato no debe asumir que basta con renombrar campos: tiene que validar el orden, la representación de las llamadas y la manera en que cada formato expresa la continuación.

La regla de conservación tampoco implica reenviar indefinidamente todo lo generado en cualquier turno. La documentación de modo de pensamiento diferencia las solicitudes con herramientas de las conversaciones sin herramientas. Por eso el protocolo debe probar por separado una continuación del mismo turno y un nuevo turno del usuario. No se debe borrar o retener contenido por intuición; hay que seguir el formato documentado y verificarlo con peticiones controladas.

Un protocolo reproducible con herramientas simuladas

Antes de probar con herramientas reales, crea dobles controlados que devuelvan resultados conocidos. Una herramienta simulada reduce el riesgo de modificar datos, llamar servicios externos o confundir una respuesta cambiante con una regresión. Define de antemano qué cuenta como aprobado: por ejemplo, que la aplicación ejecute una sola vez una llamada válida, asocie el resultado a esa llamada y remita la continuación con los campos exigidos. La política exacta depende del producto; debe quedar escrita antes de ejecutar la prueba.

Empieza con una sola herramienta y una solicitud sencilla. Comprueba que la aplicación detecta la llamada, valida el nombre y los argumentos, ejecuta la operación simulada y añade la respuesta correspondiente. Después verifica que la siguiente petición conserva el estado requerido y que el modelo responde a partir del resultado. No basta con ver una respuesta final plausible: compara la secuencia capturada con la secuencia que la aplicación esperaba enviar.

A continuación encadena dos herramientas: la primera devuelve un dato que la segunda necesita. El caso ayuda a descubrir si la aplicación termina el turno demasiado pronto, reenvía un resultado antiguo o interpreta como nueva una llamada que ya ejecutó. No presupongas que el modelo siempre elegirá el orden deseado. El criterio es que el orquestador procese de forma segura las solicitudes recibidas y mantenga una relación inequívoca entre cada llamada y su resultado.

Prueba también el modo de streaming. La documentación de DeepSeek incluye ejemplos de streaming en modo de pensamiento, pero una integración debe validar su propio lector de eventos: una respuesta parcial no equivale necesariamente a una llamada completa y ejecutable. Acumula y analiza la salida según el formato documentado; no ejecutes una herramienta antes de haber recibido y validado la estructura necesaria. Registra los fragmentos y el evento final relevante, sin asumir que el texto mostrado en una interfaz de usuario refleja por sí solo el estado del protocolo.

Los argumentos malformados deben tratarse como entrada no confiable, incluso si los generó el modelo. Prueba campos ausentes, tipos inesperados, valores fuera de rango y nombres de herramienta desconocidos. La aplicación debe rechazar o encauzar de manera controlada lo que no cumpla el esquema propio. La salida del modelo no concede permisos: las autorizaciones, límites y validaciones pertenecen a la aplicación.

Incluye resultados vacíos, errores simulados y respuestas contradictorias. El agente no debería inventar que una operación tuvo éxito si la herramienta informó un fallo, ni repetir una acción con efectos sin una política de idempotencia. En casos contradictorios, define qué fuente prevalece y si se requiere aclaración o intervención humana. Son decisiones del producto, no propiedades garantizadas por la presencia de `reasoning_content`.

Fallos que la aplicación debe poder detectar

El primer fallo es omitir estado requerido al construir una continuación. La guía de modo de pensamiento documenta un error 400 en el caso de herramientas cuando se omite `reasoning_content` según las condiciones que describe. Registra el código de respuesta y la solicitud saliente saneada; no conviertas el mensaje de error en una excusa para reintentar sin cambios. La corrección debe derivarse de la estructura que efectivamente envía el cliente y de la especificación vigente.

El segundo es ejecutar dos veces una misma operación. Puede ocurrir si la aplicación reintenta tras un corte de red sin saber si la herramienta ya produjo efectos, o si interpreta fragmentos de streaming como solicitudes independientes. La prevención depende de la clase de herramienta: usa identificadores de operación, deduplicación o confirmación humana cuando corresponda. Una herramienta de solo lectura y una transferencia de fondos no admiten necesariamente la misma política.

También hay que buscar bucles: el modelo vuelve a pedir una acción equivalente, la herramienta devuelve un resultado que no se incorpora o el orquestador conserva un estado obsoleto. Define límites de iteraciones y de tiempo, y expón una salida controlada cuando se alcanzan. Un límite no garantiza una respuesta correcta, pero reduce la posibilidad de que un problema de integración se convierta en consumo indefinido o repetición de efectos.

Una cuarta clase de fallo aparece cuando argumentos y resultados se validan solo en la interfaz del modelo. El cliente debe comprobar el esquema, el nombre de la herramienta, los permisos del usuario y el alcance de la operación. Debe asimismo manejar resultados parciales, vacíos o incompatibles con el formato esperado. El modelo puede ayudar a interpretar la información, pero la aplicación conserva la responsabilidad de decidir qué acciones ejecuta.

Por último, diferencia un error de API de un error de negocio. Un 400 relacionado con la forma de la petición requiere revisar el contrato enviado; un fallo de la herramienta puede ser un problema de permisos, conectividad o datos. En ambos casos registra la categoría y el punto de la secuencia donde ocurrió. Evita presentar como confirmada una causa que el registro no permite distinguir.

Qué registrar y qué limitar

Para que otra persona pueda reproducir un fallo, registra la fecha, el entorno, el identificador de modelo solicitado, el modo, el formato de API, las opciones relevantes y la secuencia de mensajes. Añade las solicitudes y respuestas de herramientas, errores, duración y tokens cuando la respuesta de la API los proporcione. Anota también si hubo streaming y cómo el cliente ensambló la respuesta. Un registro sin el punto exacto donde se perdió o transformó un campo puede ocultar justo el defecto que se intenta localizar.

Minimiza los datos personales y secretos. Redacta credenciales, identificadores sensibles y contenido que no sea necesario para diagnosticar el flujo; emplea herramientas simuladas para reproducir casos cuando sea posible. Establece controles de acceso y plazos de conservación acordes con la política del equipo. No guardes de manera indiscriminada todo el historial de producción solo porque facilita una depuración puntual.

Trata `reasoning_content` con especial cautela. La documentación lo identifica como un campo relevante para el intercambio con la API en ciertos flujos, pero eso no lo convierte en una prueba fiable de que el modelo haya seguido una cadena de razonamiento completa o verdadera. Su contenido puede ser sensible y no debería mostrarse, conservarse o usarse para evaluar una explicación como si fuera una auditoría del proceso interno. Si necesitas verificar el comportamiento, usa entradas controladas, llamadas observables, resultados y criterios de aceptación.

Los registros deben separar hechos de interpretaciones. «La petición de continuación enviada no contenía el campo» es una observación comprobable si se conserva el registro correspondiente. «El modelo olvidó lo que pensaba» es una explicación especulativa y antropomórfica. Mantener esa distinción evita que una hipótesis se convierta en un diagnóstico operativo sin evidencia.

Mantener, corregir o preparar una migración

Una decisión de mantenimiento debe apoyarse en evidencia del entorno real. Consulta el endpoint oficial de listado de modelos con las credenciales y permisos que utilizará la aplicación, registra el identificador devuelto y repite la consulta en el entorno de despliegue. La página de especificación describe el endpoint, pero no reemplaza una consulta actual: un ejemplo o una referencia histórica no certifican disponibilidad en una cuenta concreta. Comprueba también el alias configurado frente a la versión fijada y documenta qué comportamiento espera la integración.

La cronología pública puede orientar la investigación, no resolverla por sí sola. El centro de transparencia de DeepSeek enumera V3.2 y V4 con información de publicación, mientras que el registro de cambios permite revisar modificaciones de alias y anuncios de discontinuación. Antes de migrar, verifica en esas fuentes qué identificador está disponible y qué cambio está anunciado, y confirma el resultado con la API de tu cuenta. La documentación aportada no justifica dar por existente una ruta de migración automática ni afirmar equivalencia funcional entre modelos.

La guía de herramientas explica diferencias entre interfaces, así que una migración de formato también debe tratarse como cambio de integración. Ejecuta la misma batería de regresión sobre la ruta actual y la candidata: una llamada, una cadena, streaming, entradas inválidas, errores de herramienta y continuación en un nuevo turno. Compara criterios propios del producto, no una impresión general. Revisa permisos, latencia, fallos y coste en los términos que la organización considere relevantes, sin confundir compatibilidad sintáctica con equivalencia de comportamiento.

Si la integración supera las pruebas y el identificador sigue disponible, mantenerla puede ser razonable, sujeto a la política de soporte y al riesgo aceptable del equipo. Si falla por pérdida de estado, corrige y vuelve a ejecutar la batería antes de decidir sobre el modelo. Si se prepara una migración, conserva una ruta de reversión probada, limita el despliegue inicial y define qué señales detendrán el cambio. Estas son recomendaciones de operación, no garantías ofrecidas por el proveedor.

La conclusión útil no es que `reasoning_content` «explique» el agente, sino que forma parte de un contrato que merece una prueba explícita en las circunstancias documentadas. Un equipo puede decidir con más rigor cuando tiene una secuencia reproducible, criterios previos, registros minimizados y una comprobación actual de disponibilidad. Si falta cualquiera de esas evidencias, la incertidumbre debe quedar escrita en la decisión.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.