DeepSeek Harness: configura y verifica tareas
DeepSeek-V4 Team · 8 de octubre de 2026 · 7 min read
Un recordatorio que llega a tiempo es solo la primera mitad de una tarea automatizada. La segunda mitad es el trabajo que pide al modelo que realice. DeepSeek Harness hace visible esa distinción mediante registros de entrega guardados y la conversación vinculada, pero aún debe verificar ambas.
En la versión dsh-v0.2.1-alpha.1 del 3 de octubre de 2026, Automation está integrada en el modo Web. Este tutorial sigue la guía de programación fijada por versión. Ofrece un pequeño procedimiento de validación para su propia instalación; no informa un resultado de confiabilidad medido ni promete ejecución desatendida mientras su máquina está apagada.
Verifique el modo antes de escribir el recordatorio
Configure un proveedor de modelos y use el modo Standard, Creator o PTC. Esos preajustes exponen las herramientas de recordatorio. El modo Minimal no lo hace, y los subagentes delegados tienen denegado el acceso a ellas. Una capacidad de programación faltante puede ser, por tanto, un problema de modo y no un problema de redacción.
Abra Automation tasks desde la barra lateral. La página le permite inspeccionar tareas entre conversaciones sin activar primero cada conversación. Su acción New abre una nueva sesión con una solicitud de creación ya en el cuadro de redacción. Como con cualquier borrador, inspecciónelo antes de enviar.
Para la primera prueba, elija una solicitud inofensiva con un resultado obvio. Pedir una lista de verificación fija corta hace que la entrega y la ejecución sean más fáciles de inspeccionar que pedir al modelo que busque en varios sitios web y produzca un informe. Las dependencias externas se pueden agregar después de que el mecanismo básico funcione.
Comience con una entrega que pueda reconocer
Envíe una solicitud como:
En dos minutos, recuérdame en esta conversación revisar el informe de muestra. La instrucción del recordatorio debe pedirte que respondas con las tres verificaciones: fecha de origen, filas faltantes y consistencia total. Crea un recordatorio único y luego muéstrame el nombre de la tarea guardada y la hora programada.
Esto pide un retraso único, no una tarea repetitiva. Abra los detalles de su tarea y verifique esa distinción. Mantenga el proceso Host en ejecución mientras espera. Cuando llegue el recordatorio, inspeccione la conversación para ver las tres verificaciones solicitadas y abra Records para inspeccionar la evidencia de entrega.
Un registro guardado significa que el recordatorio fue escrito duraderamente en la bandeja de entrada de la conversación. No significa que el modelo terminara la respuesta solicitada. Si existe un registro pero falta el resultado, investigue la conversación y el estado del proveedor antes de recrear el programa. De lo contrario, corre el riesgo de crear varias tareas para la misma solicitud.
Después de la entrega, una tarea única se vuelve inactiva. Encuéntrela con All o Inactive en la lista de tareas. Su desaparición de una vista que lista recordatorios activos no significa que la tarea o su historial se hayan eliminado.
Use una regla diaria para una hora local diaria
Un recordatorio diario a una hora local concreta y un intervalo transcurrido fijo expresan intenciones diferentes. "Cada 24 horas" comienza desde un ancla de intervalo. "Todos los días a las 09:00 en Asia/Shanghai" nombra una hora de reloj local y una zona. Elija la regla que coincida con su requisito real.
Por ejemplo:
Todos los días a las 09:00 en Asia/Shanghai, recuérdame en esta conversación inspeccionar el informe de muestra. Nombra la tarea Verificación diaria del informe. Usa una regla de hora local diaria. No crees un recordatorio único ni un intervalo fijo de 24 horas. Después de crearla, muestra la regla guardada y la siguiente hora programada.
En Rules, verifique la frecuencia, la hora y la zona IANA guardada. El siguiente objetivo se muestra en la zona del dispositivo, por lo que puede parecer diferente de la regla guardada si su dispositivo usa otra zona. Compare el tiempo previsto subyacente en lugar de asumir que los dos valores de reloj visibles deben coincidir.
Los programas diarios en zonas con cambios de horario de verano necesitan cuidado extra. Según la guía fijada, una hora local inexistente se omite, y una hora que se repite solo activa el recordatorio una vez, en el primero de los dos instantes. Un intervalo fijo es programación de tiempo transcurrido y no sigue esas reglas de hora local.
Edite la tarea existente en lugar de crear un duplicado
Seleccione una tarea activa y abra Rules. Puede editar su nombre, instrucción y programación. Las ediciones permanecen locales hasta que se selecciona Save changes. Una edición aceptada preserva la identidad de la tarea, la conversación original y los registros de entrega guardados.
Si cambia el intervalo, el siguiente intervalo se mide desde la hora de guardado aceptado del proceso Host. Una regla normalizada equivalente no reinicia el temporizador. Esta diferencia importa al probar un intervalo corto: cambiar solo la instrucción no debe tratarse como un programa nuevo.
Después de guardar, vuelva a abrir o actualice la tarea e inspeccione los valores almacenados. Si una actualización no puede confirmarse, inspeccione la tarea actual antes de reintentar. Una pantalla obsoleta y una escritura fallida son problemas diferentes. Las tareas inactivas son de solo lectura, así que no espere convertir una tarea única completada en una tarea recurrente editando su tarjeta inactiva.
Pruebe deliberadamente el comportamiento de reinicio del proceso Host
El programador se ejecuta en el proceso Host. Cerrar una pestaña del navegador no es lo mismo que detener el proceso del proceso Host. Identifique qué proceso o aplicación de escritorio ejecuta realmente su instalación antes de ejecutar una prueba de reinicio.
Use un recordatorio único de prueba. Detenga el proceso Host antes de que venza, luego inícielo nuevamente después de esa hora. El comportamiento documentado es verificar las tareas almacenadas y entregar una tarea única vencida. Para recordatorios recurrentes, el reinicio maneja solo la última ocurrencia perdida, no cada intervalo que transcurrió mientras el proceso Host estaba detenido.
No use una tarea con efectos secundarios externos para este experimento. La documentación no garantiza la entrega exactamente una vez: un fallo después de la persistencia de la bandeja de entrada pero antes de que se actualice el registro de la tarea puede dejar un mensaje entregado sin registrar y permitir una repetición. Un borrador de informe es una mejor prueba que un pago, envío de mensaje u operación de archivo irreversible.
Mantenga un registro de validación con dos resultados
Use una tabla corta para cada prueba. La distinción entre entrega y finalización del trabajo evita que un indicador de programación verde oculte un resultado incompleto.
| Prueba | Evidencia de entrega | Evidencia de trabajo |
|---|---|---|
| Retraso único | Registro guardado en la ocurrencia esperada | La lista de verificación solicitada aparece en la conversación |
| Regla diaria | Frecuencia, zona y siguiente objetivo correctos | La siguiente solicitud entregada usa la instrucción prevista |
| Edición | Misma identidad de tarea con los nuevos valores guardados | Una respuesta posterior sigue la instrucción editada |
| Reinicio | Recordatorio vencido esperado después del inicio del proceso Host | La conversación vinculada produce el resultado solicitado |
Los registros se retienen dentro de los límites de historial configurados. El historial antiguo faltante no se puede reconstruir simplemente mirando la instrucción actual. Trate los registros como evidencia de entrega para las entradas que realmente contienen, no como un registro de auditoría completo de la ejecución del modelo.
Elimine la prueba cuando haya terminado
Elimine una tarea de prueba a través de sus detalles y confirme la eliminación. Esto detiene la entrega futura y elimina el historial de entrega guardado de la tarea. No retracta un mensaje ya en cola en la conversación original, así que inspeccione esa conversación si el trabajo ya vencía.
La versión fijada no admite pausar tareas ni crear una nueva sesión para cada ejecución. Diseñe el flujo de trabajo alrededor de la conversación original y los controles de edición disponibles. Si necesita un servicio de funcionamiento continuo con seguimiento de ejecución duradero, establézcalo por separado en lugar de inferirlo del soporte de recordatorios.
Para el contexto de instalación y migración, lea la Revisión de la actualización de Harness 0.2.1. Comience con un recordatorio que pueda observar, luego agregue trabajo real solo después de entender cómo aparecen el programación, la entrega y la finalización en su instalación.