Ir al contenido principal

switch_mode

La herramienta switch_mode permite a AI Cockpit Reasoning cambiar entre diferentes modos operativos, cada uno con capacidades especializadas para tipos específicos de tareas. Esto permite transiciones fluidas entre modos como Code, Architect, Ask o Debug cuando la tarea actual requiere una experiencia diferente.

Parámetros​

La herramienta acepta estos parámetros:

  • mode_slug (requerido): El slug del modo al que cambiar (p. ej., "code", "ask", "architect")
  • reason (opcional): La razón para cambiar de modo, proporcionando contexto al usuario

Qué Hace​

Esta herramienta solicita un cambio de modo cuando la tarea actual sería mejor manejada por las capacidades de otro modo. Mantiene el contexto mientras cambia el enfoque de AI Cockpit Reasoning y los conjuntos de herramientas disponibles para que coincidan con los requisitos de la nueva fase de la tarea.

¿Cuándo se usa?​

  • Al hacer la transición de la recopilación de información a la implementación de código
  • Al pasar de la codificación a la arquitectura o el diseño
  • Cuando la tarea actual requiere capacidades solo disponibles en un modo diferente
  • Cuando se necesita experiencia especializada para una fase particular de un proyecto complejo

Características Principales​

  • Mantiene la continuidad del contexto entre las transiciones de modo
  • Proporciona razonamiento claro para las recomendaciones de cambio de modo
  • Requiere aprobación del usuario para todos los cambios de modo
  • Aplica restricciones de grupos de herramientas específicas para cada modo
  • Adapta perfectamente la disponibilidad de herramientas según el modo seleccionado
  • Funciona con modos estándar y personalizados
  • Muestra el cambio de modo y el razonamiento en la interfaz
  • Usa formato de estilo XML para la especificación de parámetros
  • Maneja las restricciones de tipos de archivo específicas de ciertos modos

Limitaciones​

  • No puede cambiar a modos que no existen en el sistema
  • Requiere aprobación explícita del usuario para cada transición de modo
  • No puede usar herramientas específicas de un modo hasta que el cambio esté completo
  • Aplica un retraso de 500ms después del cambio de modo para permitir que el cambio surta efecto
  • Algunos modos tienen restricciones de tipos de archivo (p. ej., el modo Architect solo puede editar archivos markdown)
  • La preservación del modo para la reanudación solo aplica a la funcionalidad new_task, no al cambio de modo general

Cómo Funciona​

Cuando se invoca la herramienta switch_mode, sigue este proceso:

  1. Validación de Solicitud:

    • Valida que el modo solicitado existe en el sistema
    • Verifica que se proporcione el parámetro mode_slug y sea válido
    • Verifica que el usuario no esté ya en el modo solicitado
    • Garantiza que el parámetro reason (si se proporciona) esté correctamente formateado

  2. Preparación de la Transición de Modo:

    • Empaqueta la solicitud de cambio de modo con la razón proporcionada
    • Presenta la solicitud de cambio al usuario para su aprobación

  3. Activación del Modo (Con Aprobación del Usuario):

    • Actualiza la interfaz para reflejar el nuevo modo
    • Ajusta las herramientas disponibles según la configuración del grupo de herramientas del modo
    • Aplica el prompt y el comportamiento específicos del modo
    • Aplica un retraso de 500ms para permitir que el cambio surta efecto antes de ejecutar la siguiente herramienta
    • Aplica cualquier restricción de archivo específica del modo

  4. Continuación:

    • Continúa con la tarea usando las capacidades del nuevo modo
    • Retiene el contexto relevante de la interacción anterior

Asociación de Grupos de Herramientas​

La herramienta switch_mode pertenece al grupo de herramientas "modes" pero también está incluida en la lista de herramientas "siempre disponibles". Esto significa:

  • Se puede usar en cualquier modo independientemente de los grupos de herramientas configurados del modo
  • Está disponible junto con otras herramientas principales como ask_followup_question y attempt_completion
  • Permite transiciones de modo en cualquier punto de un flujo de trabajo cuando cambian los requisitos de la tarea

Estructura del Modo​

Cada modo en el sistema tiene una estructura específica:

  • slug: Identificador único para el modo (p. ej., "code", "ask")
  • name: Nombre de visualización para el modo (p. ej., "Code", "Ask")
  • roleDefinition: El rol especializado y las capacidades del modo
  • customInstructions: Instrucciones opcionales específicas del modo que guían el comportamiento
  • groups: Grupos de herramientas disponibles para el modo con restricciones opcionales

Capacidades del Modo​

Los modos principales proporcionan estas capacidades especializadas:

  • Modo Code: Enfocado en tareas de codificación con acceso completo a herramientas de edición de código
  • Modo Architect: Especializado para el diseño de sistemas y la planificación de arquitectura, limitado a editar solo archivos markdown
  • Modo Ask: Optimizado para responder preguntas y proporcionar información
  • Modo Debug: Equipado para el diagnóstico sistemático de problemas y su resolución
  • Modo Orchestrator: Un orquestador estratégico de flujos de trabajo que coordina tareas complejas delegándolas a los modos especializados apropiados

Modos Personalizados​

Más allá de los modos principales, el sistema admite modos personalizados específicos del proyecto:

  • Los modos personalizados se pueden definir con grupos de herramientas específicos habilitados
  • Pueden especificar definiciones de roles e instrucciones personalizadas
  • El sistema verifica primero los modos personalizados antes de recurrir a los modos principales
  • Las definiciones de modos personalizados tienen prioridad sobre los modos principales con el mismo slug

Restricciones de Archivos​

Los diferentes modos pueden tener restricciones específicas de tipos de archivo:

  • Modo Architect: Solo puede editar archivos que coincidan con la extensión .md
  • Intentar editar tipos de archivo restringidos resulta en un FileRestrictionError
  • Estas restricciones ayudan a aplicar la separación adecuada de responsabilidades entre modos

Ejemplos de Uso​

  • Al discutir una nueva característica, AI Cockpit Reasoning cambia del modo Ask al modo Architect para ayudar a diseñar la estructura del sistema.
  • Después de completar la planificación de arquitectura en el modo Architect, AI Cockpit Reasoning cambia al modo Code para implementar las características diseñadas.
  • Al encontrar errores durante el desarrollo, AI Cockpit Reasoning cambia del modo Code al modo Debug para la resolución sistemática de problemas.

Ejemplos de Uso​

Cambiar al modo Code para la implementación:

<switch_mode>
<mode_slug>code</mode_slug>
<reason>Necesito implementar la funcionalidad de inicio de sesión basada en la arquitectura que hemos discutido</reason>
</switch_mode>

Cambiar al modo Architect para el diseño:

<switch_mode>
<mode_slug>architect</mode_slug>
<reason>Necesito diseñar la arquitectura del sistema antes de la implementación</reason>
</switch_mode>

Cambiar al modo Debug para la resolución de problemas:

<switch_mode>
<mode_slug>debug</mode_slug>
<reason>Necesito diagnosticar sistemáticamente el error de autenticación</reason>
</switch_mode>

Cambiar al modo Ask para obtener información:

<switch_mode>
<mode_slug>ask</mode_slug>
<reason>Necesito responder preguntas sobre la característica implementada</reason>
</switch_mode>

Cambiar al modo Orchestrator para una mejor delegación de tareas:

<switch_mode>
<mode_slug>orchestrator</mode_slug>
<reason>Necesito delegar las tareas al modo correcto</reason>
</switch_mode>