5 conceptos básicos de IA

Antes de empezar a usar EasyClaw, dedica 5 minutos a aprender estos conceptos: te ayudarán a entender de verdad cómo funciona la IA, en lugar de limitarte a introducir instrucciones a ciegas.
No necesitas ser ingeniero, pero sí saber: por qué la IA puede hacer cosas, cómo hacer que sea más precisa y cuándo puede fallar.

1. Agent (agente inteligente)

A continuación, aclaremos cómo funciona. Puedes imaginar el proceso de trabajo del agente como un bucle que se ejecuta repetidamente: Comprender la tarea → Elaborar un plan → Llamar a las herramientas → Ejecutar la acción → Verificar el resultado → Ajustar → Informar.

1) Comprender la tarea:
El agente primero determinará qué problema intentas resolver, cómo es el éxito y si hay restricciones (por ejemplo, formato, tono, plazo, lo que no debe hacer). Si la información es insuficiente, puede hacerte preguntas primero o hacer las suposiciones necesarias y explicarlas.

2) Elaborar un plan (desglosar los pasos):
Las tareas grandes a menudo necesitan dividirse en pasos más pequeños. Por ejemplo, "organizar la bandeja de entrada" podría desglosarse en: Analizar los correos electrónicos → Identificar los tipos (notificaciones/facturas/clientes/varios) → Evaluar la prioridad → Archivar → Redactar respuestas (si es necesario) → Resumir la lista. Este paso determina "qué hacer primero y qué hacer después".

3) Llamar a las herramientas/capacidades:
Esta es también la clave de cómo el agente puede "hacer las cosas". Sin herramientas, solo puede quedarse en el nivel de consejos basados en texto; con herramientas, puede ejecutar acciones reales, como: leer archivos, buscar información, enviar mensajes, acceder a sistemas empresariales, generar documentos, etc. Verás al agente "conectándose con el mundo exterior", no solo generando una frase.

4) Ejecutar y registrar:
En los pasos apropiados, el agente activará operaciones reales (por ejemplo, llamar a una API de servicio, completar una tarea de procesamiento de datos, generar contenido utilizable). Al mismo tiempo, registra "qué paso he completado", lo que facilita continuar o retroceder para hacer correcciones más tarde.

5) Verificación y corrección de errores:
El agente no solo buscará "parecer completado"; también comprobará si el resultado cumple los requisitos. Por ejemplo: ¿falta campos clave en la salida? ¿incumple los requisitos de formato? ¿hay errores o incertidumbres evidentes? Si no está satisfecho, volverá a planificar el siguiente paso y continuará iterando.

6) Informar de los resultados y los próximos pasos:
Finalmente, el agente resumirá el contenido que ha completado, los hallazgos importantes y los elementos que necesitan tu confirmación. Puedes ver claramente: qué ha hecho, qué se ha completado y qué está todavía en curso.

2. Skill (capacidad/habilidad)

En el bucle del agente, el paso "llamar a herramientas/capacidades" aparece con frecuencia, y lo que se llama suele ser un Skill. Puedes pensarlo así: El agente es como un cerebro, el Skill es como las manos, los pies y una caja de herramientas.

Para profundizar, expliquemos a fondo "cómo funciona el Skill en el bucle del agente":

1) El agente determina qué Skill se necesita
Cuando la tarea entra en la fase de ejecución, el agente analizará qué capacidades se necesitan para el paso actual. Por ejemplo, "encontrar los registros históricos de comunicación de un cliente" necesita un Skill de tipo "recuperar/leer"; "redactar un correo electrónico de seguimiento" necesita un Skill de tipo "generar texto/usar plantilla"; "sincronizar tarea con el sistema de tareas pendientes" necesita un Skill de tipo "escribir/actualizar".

2) El agente rellena los parámetros en el Skill (entrada)
Los Skills suelen requerir un formato de entrada específico, como: palabras clave, rango de tiempo, ID de cliente, público objetivo, estilo de salida, etc. El agente extraerá el contexto y lo organizará en los parámetros requeridos por el Skill.
Este paso determina si la ejecución es precisa: si la entrada es incorrecta, la salida probablemente será errónea.

3) El Skill se ejecuta y devuelve el resultado (salida)
Después de que el Skill se ejecuta, devuelve resultados estructurados o semiestructurados, como: listas de elementos recuperados, resultados de cálculos, texto de documentos generados, códigos de estado de retorno de API, etc. Estos resultados pueden ser leídos de nuevo por el agente para la toma de decisiones posterior.

4) El agente valida la salida y continúa al siguiente paso (bucle cerrado)
La finalización del Skill no es el punto final; el agente también comprobará: si el resultado cumple las restricciones, si falta información, si se necesita una segunda generación o corrección. Si no está satisfecho, podría llamar a otro Skill (por ejemplo, "búsqueda complementaria", "reescribir contenido", "formatear salida") e iterar de nuevo. Este es el "bucle cerrado cooperativo" del Skill y el agente.

Ejemplo: Le pides al agente que "escriba un correo electrónico de seguimiento a clientes potenciales y cree una tarea pendiente".
Esto normalmente encadena múltiples Skills, formando una cadena de acción completa:

1) Skill de recuperación de información del cliente: entrada: ID/nombre del cliente, salida: nombre, empresa, puntos clave de la última comunicación;
2) Skill de extracción/resumen de información: entrada: registros de comunicación, salida: puntos débiles clave y elementos conseguidos;
3) Skill de generación de correo electrónico: entrada: tono (profesional/amigable), plantilla (seguimiento/cierre), puntos clave, salida: cuerpo del correo electrónico;
4) Skill de generación de tareas pendientes: entrada: contenido del correo electrónico y sugerencias de acción, salida: elementos de tareas pendientes (responsable, fecha límite, pasos);
5) Skill de escritura en calendario/sistema de tareas pendientes: entrada: datos estructurados de tareas pendientes, salida: estado de creación exitosa o enlace.

Te darás cuenta: el agente parece "entender el trabajo de ventas", pero detrás de esto hay módulos de Skill que unen capacidades reales en un flujo de trabajo. El agente es responsable de usar estas capacidades en el orden correcto.

Sigamos usando el "bucle operativo" del agente para entender el Skill: el agente es responsable de pensar y programar, el Skill es responsable de ejecutar pasos concretos. Cuando el agente descubre que una tarea necesita una cierta capacidad, seleccionará el Skill apropiado, pondrá los parámetros necesarios en él, esperará a que devuelva resultados y luego traerá los resultados de vuelta al bucle para su validación, complemento o planificación del siguiente paso.

Ejemplo: Le pides al agente que "escriba un correo electrónico de seguimiento para un cliente y genere una tarea pendiente".
Podría llamar a diferentes Skills:
1) Recuperar información del cliente (obtener nombre, puntos de la última comunicación);
2) Generar borrador de correo electrónico (salida por tono/longitud/plantilla);
3) Generar lista de tareas pendientes (desglosar los siguientes pasos en elementos).
Cuando estos Skills se unen, forman el comportamiento del agente que "parece muy capaz".

3. Prompt (instrucción/indicación)

Te darás cuenta de que el Prompt y los dos conceptos anteriores (Agent / Skill) son dos caras de la misma lógica operativa: El agente necesita el Prompt para decidir cómo proceder, el Skill necesita el Prompt para decidir qué rellenar y cómo verificar.

"El bucle de trabajo del agente" se puede entender como:
Comprender la tarea → Elaborar un plan → Decidir llamar al Skill → El Skill se ejecuta → Verificar el resultado → Continuar ajustando → Informar.
Y el papel del Prompt es dar reglas en cada paso, evitando que se desvíe, adivine a ciegas o forme un bucle cerrado.

1) El Prompt primero define "Objetivo y criterios de éxito" (Por qué hacerlo)
Este paso determina las "reglas de puntuación" del agente. El Prompt necesita decirle: cuál es exactamente el problema que estás resolviendo, y qué resultado cuenta como completado.
Por ejemplo: no "ayúdame a escribir un correo electrónico", sino "el correo debe incluir qué párrafos, qué tono, qué rango de longitud y terminar con una tarea pendiente".

Sin criterios de éxito en el Prompt, el agente solo puede producir una salida que "parece más o menos correcta", lo que dificulta la verificación de la calidad.

2) El Prompt proporciona "Condiciones de activación y restricciones" (Cuándo hacer qué)
Un Prompt que puede conseguir resultados normalmente aclara: cuándo llamar al Skill, cuándo hacer preguntas.
Por ejemplo: si falta el nombre del cliente o la fecha, debe preguntar primero en lugar de limitarse a "escribir un nombre o fecha cualquiera".

Esto equivale a reducir la incertidumbre: cuanto más claras son las restricciones, más estable es el agente.

3) El Prompt describe "Qué Skills se necesitan y los contratos de entrada/salida para cada uno" (Qué herramientas usar)
El Prompt debe aclarar:
Qué Skill llamar, qué campos de entrada necesita, de dónde vienen los campos de entrada, qué requisitos de formato hay;
y al mismo tiempo aclarar: en qué estructura debe devolverse la salida del Skill (por ejemplo, campos JSON, listas, tablas, estructura de párrafos fija, etc.).

Este paso es clave para que el Prompt sea verdaderamente "ingenieril": convertir "cómo hacer el siguiente paso" en "invocación de capacidad invocable".

4) El Prompt requiere "Verificación y gestión de fallos" (Cómo juzgar si está bien hecho)
Generar resultados por sí solo no es suficiente; el Prompt debe especificar reglas de verificación y estrategias de fallo. Los enfoques comunes incluyen:
- La llamada al Skill falla/devuelve un resultado vacío: diagnosticar primero la causa (error de parámetro/permiso/red/datos faltantes) y luego reintentar o degradar;
- A la salida le faltan campos clave: debe completarse o preguntar al usuario, no se permite adivinar;
- El formato no coincide: activar "Skill de formato/Skill de reordenación/regenerar".

Esto evita que el agente se quede atascado en un bucle de "salida repetida pero sin converger".

5) El Prompt define el "Formato de salida final" (Quién usará la salida)
Finalmente, el Prompt debe especificar cómo se presentan los resultados: qué campos deben devolverse, qué nombres de campo, si se necesitan resultados estructurados, si se necesita información rastreable (por ejemplo, "si se llamó al Skill, qué Skill se llamó, cuáles fueron las entradas/salidas clave").

4. Memory (memoria a largo plazo) / MEMORY.md

Por ejemplo, le dices al agente: "Prefiero respuestas concisas en chino, usa Python para el código".
Si esta preferencia se escribe en la memoria en un formato adecuado, cuando el agente maneje tipos de tareas similares más tarde, seguirá estas reglas por defecto; no necesitas enfatizarlas repetidamente, y es mucho menos probable que encuentres problemas de "estilo de respuesta inconsistente cada vez".

Para garantizar que la memoria sea verdaderamente "utilizable", necesita cumplir con los estándares de los tres conceptos anteriores: activación estable, entrada clara, salida verificable. En otras palabras, el contenido escrito en la memoria debe guiar claramente cómo debe proceder el agente a continuación, no ser una vaga expresión emocional.

Se recomienda escribir la memoria en este estilo de "lista de comprobación de reglas":

• Preferencias de estilo de escritura: por ejemplo, "chino conciso", "conclusiones primero", "no más de 3 frases por párrafo"
• Requisitos de formato: por ejemplo, "Python para el código", "la salida de la tabla incluye los campos A/B/C", "formato de fecha AAAA-MM-DD"
• SOP de decisión: por ejemplo, "preguntar si la información es insuficiente, no adivinar; proporcionar alternativas con etiquetas de riesgo"
• Contexto a largo plazo: por ejemplo, "mi equipo es de entrega B2B", "las herramientas comunes son XX (cuando corresponda)"

Puntos clave sobre la memoria:

1) La memoria almacena la configuración a largo plazo (Por qué existe)
La principal diferencia entre la memoria y el Prompt es: el Prompt maneja esta tarea específica, mientras que la memoria maneja "todas las tareas futuras". Al almacenar preferencias y SOP en la memoria, el agente puede aplicar estas reglas de forma consistente sin que necesites repetirlas.

Por ejemplo, si escribes "el idioma de salida predeterminado es el chino" en la memoria, entonces en todas las tareas futuras, el agente priorizará automáticamente responder en chino.

2) ¿Cuándo usa el agente la memoria? (Mecanismo de carga)
Normalmente, la memoria se carga primero cuando el agente inicia una nueva sesión o conversación. El agente lee MEMORY.md, extrae las reglas/preferencias y luego las trata como parte del contexto del sistema para esta ejecución, de forma similar a añadir instrucciones adicionales del sistema.

Esto es diferente del Prompt a mitad de la conversación: la memoria no cambia durante la conversación, es la "línea base estable" para todas las ejecuciones posteriores.

3) Lo que NO debe ir a la memoria (Establecimiento de límites)
La memoria debe contener: hábitos de trabajo estables, preferencias de formato, SOP a largo plazo, restricciones recurrentes.
La memoria NO debe contener: tareas puntuales, datos temporales, información específica de la sesión, secretos personales.

Mezclarlos hace que la memoria se vuelva desordenada y que el agente pierda la capacidad de distinguir entre "lo que es permanente" y "lo que es temporal".

4) Cómo estructurar la memoria para una máxima eficacia
Una buena memoria debe organizarse por categorías:

• Estilo de comunicación: "Responder siempre en chino conciso", "primero la estructura, luego los detalles", etc.
• Valores predeterminados técnicos: "usar Python como lenguaje principal", "usar JSON para datos estructurados", etc.
• Reglas de decisión: "cuando no estés seguro, pregunta en lugar de adivinar", "proporciona siempre una evaluación de riesgos", etc.
• Contexto y antecedentes: "trabajando en B2B SaaS", "el tamaño del equipo es de 5", etc.
• Información de herramientas e integración: "el CRM típico es Salesforce", "el sistema de registro es Datadog", etc.

De esta manera, cuando el agente lee la memoria, puede encontrar rápidamente las reglas relevantes para el contexto actual.

5) Mantenimiento de la memoria (Mantenerla actualizada)
La memoria no es "escribir una vez, usar para siempre". A medida que tu estilo de trabajo evoluciona o las reglas cambian, debes revisar y actualizar periódicamente la memoria para mantenerla alineada con la práctica actual.

Una buena práctica: revisar la memoria trimestralmente, eliminar elementos obsoletos, añadir nuevos patrones establecidos. Esto mantiene la memoria ágil y eficaz.

Mis preferencias de trabajo y SOP

 Estilo de comunicación
  Idioma: Español (conciso, conclusión primero)
  Formato: viñetas al enumerar, secciones estructuradas para información compleja
  Tono: profesional pero accesible

Valores predeterminados técnicos
  Lenguaje principal: Python
  Formato de datos: JSON
  Formato de fecha: AAAA-MM-DD
  Zona horaria: UTC+1

Reglas de decisión
  Cuando la información sea insuficiente: hacer preguntas aclaratorias, no asumir
  Proporcionar alternativas con análisis de riesgo/beneficio
  Incluir razonamiento rastreable en decisiones complejas

Contexto
  Equipo: B2B SaaS, 5 personas
  CRM principal: Salesforce
  Herramientas principales: Python, PostgreSQL, Slack

SOP de procesos
  Revisión de código siempre requerida antes del despliegue
  La documentación debe actualizarse cuando cambia la API
  Reunión diaria a las 10:00 AM UTC+1
      

5. Soul (valores fundamentales y comportamiento) / SOUL.md

Si la memoria es "lo que se recordó", entonces Soul es "en qué tipo de IA convertirse". Por ejemplo: solo responder preguntas relacionadas con el producto; las operaciones financieras requieren doble confirmación; nunca solicitar contraseñas o credenciales sensibles; para asuntos legales o médicos, debe proporcionar exenciones de responsabilidad y guiar hacia canales profesionales, etc.

Se recomienda escribir SOUL como una "lista de comprobación de reglas ejecutables", que cubra las siguientes categorías:

• Lo que está permitido: El alcance del trabajo del agente y los límites del dominio (por ejemplo, solo gestionar consultas de productos o procesos internos).
• Lo que está prohibido: Rechazos duros explícitos para comportamientos de alto riesgo (por ejemplo, solicitar contraseñas o claves; prometer resultados inciertos; eludir permisos).
• Acciones que requieren confirmación: Reglas para transferencias, reembolsos, contratos, cambios de permisos que deben ser confirmados o aprobados dos veces.
• Estilo y tono de salida: por ejemplo, debe ser educado, sin ataques personales, sin lenguaje amenazante.
• Cómo manejar los límites: Cuando no se puede completar, proporcionar alternativas (por ejemplo, registrar y escalar a un humano o sugerir consultar a especialistas).

Distinciones clave entre Soul, Memory y Prompt:

1) Soul define "Qué tipo de agente eres" (Identidad y barreras)
Soul responde a la pregunta más profunda: ¿Qué se me permite ser y hacer?
Esto incluye:
- Alcance del trabajo: ¿De qué dominios o tareas soy responsable?
- Barreras duras: ¿Qué debo no hacer absolutamente nunca (seguridad, cumplimiento, ética)?
- Flujos de trabajo de aprobación: ¿Para qué acciones debo requerir confirmación?
- Rutas de escalado: Cuando no puedo ayudar, ¿a dónde dirijo?

Soul es la línea que "no se debe cruzar". Se aplica en cada ejecución, independientemente de cómo los usuarios intenten manipular.

2) Soul frente a la seguridad: Por qué Soul es importante para el despliegue
Un Soul bien configurado puede prevenir muchos vectores de ataque comunes:
- Inyección de Prompt: Si Soul dice "verificar siempre las solicitudes de alto riesgo", incluso si un prompt dice "ignora esta regla", el agente debe negarse.
- Ingeniería social: Si Soul dice "no proporcionar nunca credenciales", sin importar cuán hábilmente pregunte un usuario, el agente debe rechazarlo.
- Ampliación del alcance: Si Soul define el límite del dominio del agente, no intentará manejar solicitudes fuera de alcance adivinando.

Esto hace que Soul sea fundamental para un despliegue seguro.

3) Cómo se integra Soul con el bucle de decisión del agente
Piensa en el ciclo de ejecución del agente así:
Paso 1: Leer Soul → ¿Cuáles son mis límites?
Paso 2: Leer la memoria → ¿Cuáles son mis preferencias de trabajo?
Paso 3: Recibir el Prompt → ¿Cuál es esta tarea específica?
Paso 4: Planificar la ejecución → Dentro de los límites, alcanzar el objetivo
Paso 5: Verificar el cumplimiento → ¿Me he mantenido dentro de Soul?
Paso 6: Ejecutar o escalar

Observa que Soul se comprueba antes y después de la ejecución. Es el bucle exterior.

Conceptos avanzados (opcional)

Los tres conceptos siguientes te ayudarán a "entender la automatización" de verdad. No son conocimientos totalmente nuevos, sino que llevan los conceptos anteriores de Agent / Skill / Memory / Soul / Prompt al nivel práctico de "ejecutar realmente, conectarse entre sí e integración estable". Los principiantes pueden saltarse esto por ahora; cuando empieces a construir procesos de varios pasos, a integrar servicios externos o a depurar problemas de flujo de datos, volver aquí te ahorrará mucho tiempo.

🔀 1) Workflow (ejecución de procesos de varios pasos)

Un Workflow se puede entender como una ruta de ejecución reutilizable: conectar varios pasos en secuencia para que el sistema alcance un objetivo de forma sistemática. Si el Agente es "un colega que puede pensar y ejecutar", entonces el Workflow es "la cola de tareas y el método de conexión que configuramos para ese colega". Resuelve el problema: cuando una tarea no se puede completar en una frase, ¿cómo ejecutamos de forma fiable varios pasos como una cadena conectada?

Un Workflow típico suele contener estos elementos (puedes usar este marco para entender las capacidades de varios pasos de EasyClaw):

• Lista de pasos: Qué hacer en el paso 1, paso 2, etc. Cada paso debe tener límites y responsabilidades claras.
• Entrada y salida: Cada paso debe producir resultados estructurados que el siguiente paso pueda usar, no solo "descripciones de texto".
• Condiciones y ramas: Por ejemplo, "si falta un campo crítico, pregunta primero o recupera más datos", de lo contrario, continúa con el siguiente paso.
• Validación y gestión de errores: Por ejemplo, "si el análisis falla, reintenta o vuelve a un enfoque alternativo".
• Salida resumida: Entrega el resultado final en un formato utilizable (lista de comprobación, informe, lista de tareas, contenido de notificación, etc.).

¿Cómo se alinea el Workflow con los conceptos anteriores? Una frase los conecta:
El agente se encarga de la toma de decisiones y la programación, el Skill se encarga de la ejecución concreta, Memory/Soul se encargan de las reglas y límites a largo plazo, el Prompt le dice "cómo hacerlo", y el Workflow conecta estos pasos en secuencia como una cadena.

Ejemplo: necesitas completar "escalar la queja del usuario a un ticket y notificar a la persona responsable". Un Workflow razonable podría verse así:

1. Recopilar entrada: Recopilar el contenido de la queja, la información del usuario y el cronograma del formulario o mensaje.
2. Extracción de información: Usar el agente para estructurar los puntos clave de la queja (por ejemplo, tipo de problema, alcance del impacto, marcas de tiempo críticas).
3. Juicio de reglas: Basándose en Soul o las reglas, determinar si es de alta prioridad, necesita escalado o requiere más información primero.
4. Llamar al Skill de creación de tickets: Rellenar los campos estructurados en la API del sistema de tickets, generar el número de ticket.
5. Llamar al Skill de notificación: Enviar el número de ticket y el resumen clave a la persona responsable (Feishu, correo electrónico o mensajería instantánea).
6. Validación del resultado: Confirmar que la creación del ticket devolvió un estado exitoso, que la notificación se envió.
7. Retroalimentación resumida: Enviar al usuario o al administrador "Ticket creado + enlace/número + próximos pasos".

Te darás cuenta: el Workflow no resuelve "cómo escribir una explicación", sino "cómo encadenar de forma fiable múltiples llamadas a herramientas y pasos de validación". Cuando empieces a manejar procesos complejos (especialmente entre sistemas: mensajería instantánea + tickets + base de datos), el Workflow se convertirá en tu capacidad más utilizada.

📦 2) JSON (formato de intercambio de datos)

JSON es el formato estándar para pasar datos entre el agente y las herramientas o API externas. En la automatización de varios pasos, el papel de JSON es fundamental: hace que "puede el siguiente paso obtener los datos correctos" sea una pregunta verificable, no "podemos entender intuitivamente una frase en lenguaje natural".

Puedes pensar en JSON como: un "contenedor de datos estructurados" dentro del sistema. En lugar de frases sueltas, contiene campos y tipos explícitos, como: título del ticket, ID de usuario, prioridad, fecha límite, contenido de la notificación, etc.

En el flujo de trabajo de EasyClaw, JSON aparece normalmente en estos lugares:

• Entrada y salida del Skill: Los Skills a menudo necesitan campos específicos como entrada, devolviendo resultados estructurados para la toma de decisiones del agente.
• Parámetros de llamada a la API: Por ejemplo, al llamar a la API de Feishu, los parámetros deben organizarse en JSON.
• Transferencia de datos entre pasos: La salida JSON de un paso es leída por el siguiente paso.

¿Por qué muchos problemas que parecen "el agente no puede hacer esto" se deben en realidad a JSON? Los casos comunes incluyen:

• Discordancia en el nombre del campo: La entrada esperada es user_id, pero la entrada real es userId.
• Campos faltantes: Falta un campo obligatorio, la API devuelve un error.
• Discordancia de tipo: La fecha debe ser una cadena, pero se pasa como número, o debe ser una matriz, pero se pasa como texto.
• Error de formato JSON: Faltan comillas, faltan corchetes, comas finales, el análisis falla.

Por lo tanto, el mejor orden de solución de problemas para los problemas de integración suele ser:
Comprueba primero JSON, luego el Prompt, luego la lógica de razonamiento del agente.
Porque JSON es la base de "si funcionará".

🔑 3) API Key (credencial de acceso)

Una API Key es la credencial de autenticación al acceder a modelos de IA o servicios de terceros. Sin la API Key correcta, el sistema normalmente no puede llamar al modelo o servicio correspondiente; incluso si el agente razona perfectamente, la ejecución sigue siendo imposible.

En los escenarios de EasyClaw, debes distinguir dos casos:

• Uso de las capacidades o créditos oficiales por defecto: Los principiantes normalmente no necesitan su propia clave, ya que la plataforma ya ha configurado el acceso para ti.
• Integración de modelos personalizados o servicios personalizados: Debes rellenar la API Key en la ubicación adecuada y dirigir el agente o el Skill a ese modelo.

La API Key no se trata solo de "puede o no puede usarla", sino que también afecta a "qué capacidades, coste y estabilidad":

• Selección de modelo: Diferentes claves o modelos pueden proporcionar diferente calidad de razonamiento, velocidad y rendimiento del formato de salida.
• Control de costes: Algunas plataformas cobran por uso; la cuenta o el cupo de la clave afecta al presupuesto disponible.
• Límites de permisos: Algunas claves de servicio solo pueden permitir llamadas API limitadas, lo que provoca que falle la ejecución de un Skill específico.

Solución de problemas común para "fallo en la llamada al Skill":
Confirma si la clave está rellenada correctamente, si la clave ha caducado o tiene un cupo insuficiente, si esa clave tiene permisos de llamada.
Si la API devuelve un error de autenticación (401/403), sospecha primero de la configuración de la API Key.

¿Cuándo debes estudiar estos conceptos seriamente? (Referencia rápida)

• Estás construyendo una automatización de varios pasos: El Workflow determina si la cadena puede ejecutarse de forma estable.
• Estás integrando Feishu, sistemas empresariales o API externas: JSON determina si los datos se transfieren correctamente y se pueden analizar.
• Estás integrando tu propio modelo o servicio personalizado: La API Key determina si puedes llamar a la capacidad correspondiente.
• Estás depurando "puede explicar pero no puede ejecutar" o "la ejecución falla sin pistas": Normalmente, la solución de problemas más rápida es comprobar el encadenamiento del Workflow, la estructura JSON y los permisos de la API Key en orden.