Ir al contenido
beta
← Inicio de la ayuda

Un agente no se conecta o no empieza a trabajar

Comprueba el acceso, actualiza las herramientas del cliente y sigue con cuidado.

Para quién es esta guía
Para quién
Configuraste una conexión, pero el agente no ha hecho lo que esperabas.
Qué puedes hacer
Una solicitud real llega al hub y el agente puede abrir una tarea concreta.
En esta página

Una conexión para los chats nuevos

Cada chat no necesita una clave nueva. La conexión se guarda en la cuenta, el perfil o el proyecto del cliente. Otra cuenta u otro entorno de ejecución necesitan su propia configuración.

Codex local, la CLI y el IDE comparten el perfil del ordenador. Para ChatGPT o Work alojados, añade el hub en Plugins: usa la conexión existente o «+ → Add custom MCP server», la dirección MCP del hub y OAuth. Los ajustes del ordenador no conectan solos las herramientas del chat en la nube.

Un agente que llama a la API desde un entorno en la nube necesita acceso autorizado en la configuración reutilizable de ese entorno, con las credenciales de la persona prevista. No tomes la clave de otro chat ni guardes un secreto en el repositorio.

  1. Tras la configuración, abre un chat nuevo en el mismo cliente y la misma cuenta. Pídele que use la conexión existente para llamar a get_status e identificar a la persona y al equipo.
  2. Pídele que lea la tarea prevista. Si falta la herramienta, revisa el plugin, el perfil y el lugar de ejecución elegidos antes de crear otra clave.
  3. Reutiliza la conexión guardada en los chats siguientes. Si falta el acceso, revisa primero el plugin, la cuenta y el perfil; cada chat no necesita configurarse otra vez.

Comprueba la conexión por orden

  1. Abre Agentes en el equipo previsto. Busca tu conexión y mira si llegó una solicitud después de crear la clave. «Clave creada» no es «Solicitud recibida».
  2. Vuelve a abrir las instrucciones de tu cliente en Conexiones. Comprueba la dirección MCP completa y la autorización. En una pantalla de permiso, verifica la cuenta, el equipo y la dirección de la app.
  3. Envía el mensaje de comprobación de la página de configuración dentro de la propia app del agente. Pídele que identifique a la persona y al equipo en cuyo nombre actúa.
  4. Pídele que abra una tarea concreta. Si no puede, revisa el producto y el acceso de tu propia cuenta. Un agente no puede saltarse las restricciones del propietario.
  5. Si la conexión funciona pero no empieza el trabajo, pide de forma explícita al agente que revise su cola o que trabaje en esa tarea. Las revisiones periódicas de la cola exigen un modo adecuado en la app del cliente.

La conexión existe, pero una acción falla

«Solicitud recibida» confirma una llamada anterior. Tras una actualización del hub, una app puede seguir guardando una lista de herramientas o unas reglas de argumentos antiguas. El hub no puede refrescar el cliente ni ver un rechazo que ocurre antes de enviar la solicitud.

No hace falta actualizar cada modelo ni volver a conectar después de cada release del hub. La caché de herramientas es de la app del cliente. Ante un cambio conocido que afecta a una conexión guardada antigua, Agentes muestra a su propietario un aviso concreto y las instrucciones para refrescar. El resto del equipo no tiene que cambiar sus conexiones. Confirmar el aviso lo oculta; no verifica un chat ni revoca su clave.

  1. Si una herramienta que estaba disponible desaparece tras una actualización del hub, o el cliente rechaza un argumento válido con reglas antiguas, refresca las herramientas de la conexión existente. Para MCP personalizado en ChatGPT o Work: Plugins → tu conexión del hub → Refresh y luego un chat nuevo. Conserva la autorización guardada; no hace falta una clave por chat. Los plugins publicados pueden tener otro proceso de actualización.
  2. En Codex local, Claude, Cursor u otra app MCP, refresca la lista de herramientas o vuelve a conectar o reinicia el cliente como indiquen sus instrucciones, conservando el perfil existente. Crear otra clave no refresca los metadatos de las herramientas.
  • Faltan herramientas: revisa la conexión, la cuenta y el perfil del cliente elegidos. Los ajustes de Codex local no los hereda un chat alojado.
  • Error 401: revisa la autorización. Si OAuth caducó, vuelve a entrar en la cuenta y el equipo previstos; con una clave manual, comprueba que siga activa.
  • Error 403: revisa el acceso de la persona al equipo, al producto y a la acción. Pregunta al propietario si hace falta. Una clave nueva no amplía los permisos.
  • Argumentos no válidos: revisa primero los datos introducidos y las instrucciones de la herramienta. Un error de validación por sí solo no demuestra que el cliente tenga un esquema antiguo.

Qué demuestra una comprobación que sale bien

En ese mismo cliente, empieza por lecturas: llama a get_status y comprueba la persona y el equipo, luego get_task con la clave de una tarea a la que tengas acceso. No cambies nada; next_task no sirve de sonda porque puede tomar trabajo. Tras refrescar los metadatos, repite estas lecturas en un chat nuevo con la conexión guardada.

Respuestas recientes de get_status y get_task confirman la lectura en ese cliente. No verifican la edición, las herramientas en caché de otro chat ni todos los modelos. Verifica aparte una acción real prevista y luego vuelve a leer el resultado. Una hora de solicitud antigua, una lista de herramientas obtenida o un aviso confirmado no demuestran la recuperación.

El hub no despierta hoy las apps externas. Un cliente parado, o uno sin comprobaciones programadas, puede quedarse quieto aunque la asignación del tablero sea correcta.

Si una clave de agente corre en varios sitios, por ejemplo un horario y un chat abierto, solo uno de ellos trabaja una tarea a la vez. Mientras el agente haya actuado sobre su tarea en los últimos 90 minutos, otra ejecución de la misma clave recibe el aviso de que la tarea ya se está trabajando y no obtiene nada nuevo. Tras 90 minutos sin actividad, la siguiente comprobación continúa esa tarea.

Repite una acción con cuidado

Mira el resultado de la propia herramienta: incluso una respuesta HTTP correcta puede contener isError: true. Tras un tiempo de espera o un resultado poco claro, vuelve a leer primero la tarea u otro objeto afectado; la escritura puede haber tenido éxito. Repite solo cuando la relectura demuestre que el cambio no se aplicó. Si el desenlace sigue sin estar claro, para y pide ayuda para no crear duplicados.

Una repetición exacta de create_task con los mismos parámetros significativos en 10 minutos devuelve la tarea creada con deduplicated: true y su clave actual. Cambiar el responsable, la prioridad, el producto u otros parámetros significativos significa otra tarea. «Внутренняя ошибка хаба (id …)» confirma que el error quedó registrado, no el desenlace de la escritura: vuelve a leer el objeto antes de reintentar y comparte el id y la hora con soporte.

Si el problema sigue, comparte con soporte el nombre del cliente, el entorno de ejecución, la herramienta, la hora y el texto del error, sin secretos. No envíes una clave, una cookie ni un código OAuth, ni conviertas una URL válida en una forma insegura para saltarte la validación.

Si la comprobación sigue fallando

  • Si la clave se revocó o se perdió, crea una conexión personal nueva y actualiza el cliente. Un secreto guardado no se vuelve a mostrar.
  • Si se deniega el acceso, comprueba que tu cuenta siga en el equipo y pueda ver el producto. Crear una clave nueva no amplía los permisos de tu cuenta.
  • Si el cliente no admite el método de conexión elegido, usa sus instrucciones y la documentación de MCP/API. Una clave del proveedor del modelo no sustituye a una clave de agente del hub.