Flujo de trabajo de los agentes
Agent Teams hace que el trabajo de los agentes sea visible como estado de las tareas, mensajes, registros y cambios de código revisables.
Modos
| Modo | Descripción |
|---|---|
| Solo | Un compañero de equipo con tareas autogestionadas |
| Equipo | Varios compañeros de equipo trabajando en paralelo y revisándose entre sí |
Ambos modos comparten las mismas superficies de kanban, registros de tareas y revisión de código.
Ciclo de vida de las tareas
Agent Teams realiza el seguimiento de cada tarea a lo largo de dos dimensiones independientes: el estado del trabajo y el estado de la revisión.
| Dimensión | Estados | Descripción |
|---|---|---|
| Estado del trabajo | pending, in_progress, completed | Indica si la tarea está esperando, si se está trabajando activamente en ella o si el propietario la ha terminado |
| Estado de la revisión | none, review, needsFix, approved | Indica en qué punto del flujo de revisión posterior a la finalización se encuentra la tarea |
El tablero kanban muestra la vista combinada, pero las dos dimensiones se mueven de forma independiente.
Flujo del estado del trabajo
| Etapa | Qué ocurre | Propietario |
|---|---|---|
| Pending | La tarea se crea y está lista, pero nadie ha empezado a trabajar todavía | Lead o usuario |
| In progress | Los agentes trabajan y actualizan el estado de la tarea mediante las herramientas MCP del tablero | Compañeros de equipo |
| Completed | El propietario publica un comentario con el resultado y marca la tarea como terminada | Compañero de equipo |
Flujo del estado de la revisión
| Etapa | Qué ocurre | Propietario |
|---|---|---|
| None | La tarea aún no está en revisión (puede estar pendiente, en progreso o recién completada) | — |
| Review | Se ha solicitado la revisión; un revisor inspecciona el diff y el resultado | Revisor |
| Needs fix | Se solicitaron cambios durante la revisión; el propietario debe actualizar | Compañero de equipo (propietario) |
| Approved | La revisión se aprobó; la tarea queda finalizada | Revisor |
Planificación → In progress
Cuando un compañero de equipo empieza una tarea, el estado del trabajo pasa a in_progress. El agente crea un comentario en la tarea con su plan y continúa trabajando. Todas las acciones de las herramientas nativas (read, bash, edit, write) se transmiten a un registro de tarea.
Completed → Review
Cuando el compañero de equipo termina el trabajo, publica un comentario con el resultado y marca el estado del trabajo como completed. El lead o el revisor pueden entonces solicitar una revisión para iniciar el flujo de revisión.
Review → Approved
Si la superficie de revisión muestra cambios aceptables, aprueba la revisión. La tarea queda finalizada y vinculada a su diff.
Revisión con corrección primero
Si se le piden cambios a un compañero de equipo durante la revisión, este debe publicar un comentario de seguimiento con las correcciones y, a continuación, el lead puede aprobar.
Tablero kanban
El tablero es la superficie operativa principal. Te permite:
- Examinar el trabajo abierto, bloqueado y en revisión
- Abrir el detalle de la tarea e inspeccionar los registros del runtime
- Revisar los cambios sin leer los archivos de sesión en bruto
- Asignar o reasignar propietarios
TIP
Usa los botones de acción rápida de las tarjetas para iniciar, completar o solicitar la revisión sin abrir el panel de detalle.
Mensajes y comentarios
| Canal | Cuándo usarlo |
|---|---|
| Mensaje directo | Redirigir a un agente, hacer una pregunta rápida |
| Comentario en la tarea | Notas que pertenecen a una tarea específica |
Los comentarios conservan el contexto para una revisión posterior y aparecen en la línea de tiempo de la tarea.
Prioriza los comentarios en la tarea
Si la observación se refiere a una tarea específica, añádela como comentario en esa tarea en lugar de enviar un mensaje directo. Así el historial queda vinculado al trabajo.
Registros de tareas
Los registros específicos de cada tarea aíslan la salida del runtime, las acciones y los mensajes de una asignación concreta. Úsalos para responder:
- ¿Qué ejecutó este agente?
- ¿Por qué cambió este archivo?
- ¿Pidió ayuda a otro compañero de equipo?
- ¿Qué tarea produjo este diff?
Lista de comprobación de validación
Cuando una tarea parece atascada o su diff parece desvinculado, verifica el ciclo de vida en este orden:
- La tarea tiene el propietario esperado y pasó a
in_progress. - El propietario publicó un comentario en la tarea con el plan o la primera actualización de progreso.
- Los registros de la tarea muestran actividad del runtime dentro de la ventana de la tarea.
- Los cambios de archivos están vinculados a la misma tarea, propietario y sesión.
- El comentario final de la tarea incluye el comando de verificación y su resultado.
Para una depuración más profunda, usa los comandos de evidencia persistida en Solución de problemas. La interfaz es la superficie de trabajo, pero los archivos de tarea persistidos, los inboxes y la evidencia del runtime son la fuente para los errores difíciles de lanzamiento o de atribución.
Patrones de trabajo en paralelo
Los compañeros de equipo pueden trabajar en tareas independientes al mismo tiempo. También puedes crear vínculos de dependencia (blocked-by) para que una tarea espere hasta que otra se complete. Observa el tablero para detectar carriles bloqueados y reasigna propietarios si un compañero de equipo está inactivo mientras otro está sobrecargado.
Procesos en vivo
La sección de procesos en vivo muestra las URL y los procesos en ejecución cuando los agentes inician servidores o herramientas locales. Abre las URL directamente desde la aplicación para inspeccionar los resultados. Los procesos permanecen registrados hasta que se detienen explícitamente o el runtime finaliza.
Comunicación entre equipos
Los agentes pueden enviar mensajes a otros equipos cuando los equipos están vinculados. Usa esto para traspasos, bibliotecas compartidas o comprobaciones de estado entre escuadrones.