5 conceitos fundamentais de IA

Antes de começar a usar o EasyClaw, dedique 5 minutos a aprender estes conceitos — eles vão ajudá-lo a compreender verdadeiramente como a IA funciona, em vez de introduzir instruções às cegas.
Não precisa de ser engenheiro, mas precisa de saber: porque é que a IA consegue fazer coisas, como torná-la mais precisa e quando pode falhar.

1. Agent (agente inteligente)

A seguir, vamos esclarecer como funciona. Pode imaginar o processo de trabalho do agente como um ciclo executado repetidamente: Compreender a tarefa → Fazer o plano → Chamar ferramentas → Executar a ação → Verificar o resultado → Ajustar → Reportar.

1) Compreender a tarefa:
O agente vai primeiro determinar qual é o problema que está a tentar resolver, como é o sucesso, e se existem restrições (por exemplo, formato, tom, prazo, o que não deve fazer). Se a informação for insuficiente, pode fazer-lhe perguntas primeiro, ou fazer os pressupostos necessários e explicá-los.

2) Fazer um plano (decompor os passos):
Tarefas grandes precisam muitas vezes de ser decompostas em passos mais pequenos. Por exemplo, "organizar a caixa de entrada" pode ser decomposto em: Analisar e-mails → Identificar tipos (notificações/faturas/clientes/diversos) → Avaliar a prioridade → Arquivar → Redigir respostas (se necessário) → Resumir a lista. Este passo determina "o que fazer primeiro, o que fazer a seguir."

3) Chamar ferramentas/capacidades:
Esta é também a chave para o agente poder "fazer as coisas". Sem ferramentas, só pode ficar ao nível de conselhos baseados em texto; com ferramentas, pode realmente executar ações, como: ler ficheiros, pesquisar informações, enviar mensagens, aceder a sistemas empresariais, gerar documentos, etc. Verá o agente a "conectar-se com o mundo exterior", e não apenas a gerar uma frase.

4) Executar e registar:
Nos passos apropriados, o agente vai realmente desencadear operações (por exemplo, chamar uma API de serviço, concluir uma tarefa de processamento de dados, gerar conteúdo utilizável). Ao mesmo tempo, regista "que passo concluí", facilitando a continuação ou o recuo para correções posteriores.

5) Verificação e correção de erros:
O agente não se limitará a aparentar "estar concluído"; também verificará se o resultado cumpre os requisitos. Por exemplo: faltam campos-chave na saída, viola os seus requisitos de formato, existem erros óbvios ou incertezas? Se não estiver satisfeito, voltará a planear o passo seguinte e continuará a iterar.

6) Reportar resultados e passos seguintes:
Finalmente, o agente resumirá o conteúdo que concluiu, as descobertas importantes, e os itens que precisam da sua confirmação. Pode ver claramente: o que fez, o que foi concluído, o que ainda está em curso.

2. Skill (capacidade/habilidade)

No ciclo do agente, o passo "chamar ferramentas/capacidades" aparece frequentemente, e o que está a ser chamado é normalmente um Skill. Pode pensar assim: O agente é como um cérebro, o Skill é como as mãos, os pés e uma caixa de ferramentas.

Para aprofundar, vamos explicar detalhadamente "como o Skill funciona no ciclo do agente":

1) O agente determina qual o Skill necessário
Quando a tarefa entra na fase de execução, o agente analisará quais as capacidades necessárias para o passo atual. Por exemplo, "encontrar os registos históricos de comunicação de um cliente" precisa de um Skill do tipo "recuperar/ler"; "redigir um e-mail de acompanhamento" precisa de um Skill do tipo "gerar texto/usar modelo"; "sincronizar tarefa com o sistema de tarefas" precisa de um Skill do tipo "escrever/atualizar".

2) O agente preenche os parâmetros no Skill (entrada)
Os Skills geralmente requerem um formato de entrada específico, como: palavras-chave, intervalo de tempo, ID do cliente, público-alvo, estilo de saída, etc. O agente extrairá o contexto e organizá-lo-á nos parâmetros requeridos pelo Skill.
Este passo determina se a execução é precisa: se a entrada estiver errada, a saída provavelmente será desviada.

3) O Skill é executado e devolve o resultado (saída)
Após a execução do Skill, este devolve resultados estruturados ou semiestruturados, como: listas de itens recuperados, resultados de cálculos, texto de documentos gerados, códigos de estado de retorno de API, etc. Estes resultados podem ser lidos de volta pelo agente para a tomada de decisão subsequente.

4) O agente valida a saída e continua para o passo seguinte (ciclo fechado)
A conclusão do Skill não é o ponto final; o agente também verificará: se o resultado cumpre as restrições, se falta informação, se é necessária uma segunda geração ou correção. Se não estiver satisfeito, pode chamar outro Skill (por exemplo, "pesquisa suplementar", "reescrever conteúdo", "formatar saída") e iterar novamente. Este é o "ciclo fechado cooperativo" do Skill e do agente.

Exemplo: Pede ao agente para "escrever um e-mail de acompanhamento para potenciais clientes e criar uma tarefa."
Isto normalmente encadeia vários Skills, formando uma cadeia de ação completa:

1) Skill de recuperação de informações do cliente: entrada: ID/nome do cliente, saída: nome, empresa, pontos-chave da última comunicação;
2) Skill de extração/resumo de informação: entrada: registos de comunicação, saída: pontos problemáticos chave e itens alcançados;
3) Skill de geração de e-mail: entrada: tom (profissional/amigável), modelo (acompanhamento/fecho), pontos-chave, saída: corpo do e-mail;
4) Skill de geração de tarefas: entrada: conteúdo do e-mail e sugestões de ação, saída: itens de tarefa (responsável, prazo, passos);
5) Skill de escrita no calendário/sistema de tarefas: entrada: dados estruturados de tarefas, saída: estado de criação bem-sucedida ou link.

Vai notar: o agente parece "perceber de trabalho de vendas", mas por detrás disto estão módulos de Skill que unem capacidades reais num fluxo de trabalho. O agente é responsável por usar estas capacidades na ordem correta.

Continue a usar o "ciclo operacional" do agente para compreender o Skill: o agente é responsável por pensar e programar, o Skill é responsável por executar passos concretos. Quando o agente descobre que uma tarefa precisa de uma determinada capacidade, selecionará o Skill apropriado, colocará os parâmetros necessários nele, aguardará que ele devolva os resultados e, em seguida, trará os resultados de volta ao ciclo para validação, suplementação ou planeamento do passo seguinte.

Exemplo: Pede ao agente para "escrever um e-mail de acompanhamento para um cliente e gerar uma tarefa."
Pode chamar diferentes Skills:
1) Recuperar informações do cliente (obter nome, pontos da última comunicação);
2) Gerar rascunho de e-mail (saída por tom/extensão/modelo);
3) Gerar lista de tarefas (decompor os passos seguintes em itens).
Quando estes Skills são reunidos, formam o comportamento do agente que "parece muito capaz".

3. Prompt (instrução/indicação)

Vai notar que o Prompt e os dois conceitos anteriores (Agent / Skill) são duas faces da mesma lógica operacional: O agente precisa do Prompt para decidir como proceder, o Skill precisa do Prompt para decidir o que preencher e como verificar.

"O ciclo de trabalho do agente" pode ser entendido como:
Compreender a tarefa → Fazer o plano → Decidir chamar o Skill → O Skill é executado → Verificar o resultado → Continuar a ajustar → Reportar.
E o papel do Prompt é dar regras em cada passo, evitando que se desvie, adivinhe às cegas ou forme um ciclo fechado.

1) O Prompt primeiro define "Objetivo e critérios de sucesso" (Porquê fazê-lo)
Este passo determina as "regras de pontuação" do agente. O Prompt precisa de lhe dizer: qual é exatamente o problema que está a resolver, e que resultado conta como concluído.
Por exemplo: não "ajude-me a escrever um e-mail", mas "o e-mail deve incluir que parágrafos, que tom, que intervalo de extensão e terminar com uma tarefa."

Sem critérios de sucesso no Prompt, o agente só pode produzir uma saída que "parece mais ou menos correta", dificultando a verificação da qualidade.

2) O Prompt fornece "Condições de acionamento e restrições" (Quando fazer o quê)
Um Prompt que consegue obter resultados normalmente esclarece: quando chamar o Skill, quando fazer perguntas.
Por exemplo: se faltar o nome do cliente ou a data, deve perguntar primeiro em vez de se limitar a "escrever um nome ou data qualquer".

Isto equivale a reduzir a incerteza: quanto mais claras forem as restrições, mais estável é o agente.

3) O Prompt descreve "Que Skills são necessários e os contratos de entrada/saída para cada um" (Que ferramentas usar)
O Prompt deve esclarecer:
Que Skill chamar, que campos de entrada necessita, de onde vêm os campos de entrada, que requisitos de formato existem;
e ao mesmo tempo esclarecer: em que estrutura deve a saída do Skill ser devolvida (por exemplo, campos JSON, listas, tabelas, estrutura de parágrafos fixa, etc.).

Este passo é fundamental para que o Prompt seja verdadeiramente "engenheirado": transformar "como fazer o passo seguinte" em "invocação de capacidade invocável".

4) O Prompt requer "Verificação e tratamento de falhas" (Como avaliar se está bem feito)
Gerar resultados por si só não é suficiente; o Prompt deve especificar regras de verificação e estratégias de falha. As abordagens comuns incluem:
- A chamada do Skill falha/devolve resultado vazio: diagnosticar primeiro a causa (erro de parâmetro/permissão/rede/dados em falta) e depois tentar novamente ou degradar;
- Falta campos-chave na saída: deve completar ou perguntar ao utilizador, não é permitido adivinhar;
- O formato não corresponde: acionar "Skill de formato/Skill de reordenação/regenerar".

Isto evita que o agente fique preso num ciclo de "saída repetida mas sem convergir".

5) O Prompt define o "Formato de saída final" (Quem usará a saída)
Finalmente, o Prompt deve especificar como os resultados são apresentados: que campos devem ser devolvidos, que nomes de campo, se são necessários resultados estruturados, se é necessária informação rastreável (por exemplo, "se o Skill foi chamado, que Skill foi chamado, quais foram as entradas/saídas chave").

4. Memory (memória de longo prazo) / MEMORY.md

Por exemplo, diz ao agente: "Prefiro respostas concisas em chinês, use Python para o código".
Se esta preferência for escrita na memória num formato adequado, quando o agente lidar com tipos de tarefas semelhantes mais tarde, seguirá estas regras por defeito; não precisa de as enfatizar repetidamente, e é muito menos provável que encontre problemas de "estilo de resposta inconsistente cada vez".

Para garantir que a memória é verdadeiramente "utilizável", precisa de cumprir os padrões dos três conceitos anteriores: acionamento estável, entrada clara, saída verificável. Por outras palavras, o conteúdo escrito na memória deve guiar claramente como o agente deve proceder a seguir, não ser uma vaga expressão emocional.

Recomenda-se escrever a memória neste estilo de "lista de verificação de regras":

• Preferências de estilo de escrita: por exemplo, "chinês conciso", "conclusões primeiro", "não mais de 3 frases por parágrafo"
• Requisitos de formato: por exemplo, "Python para o código", "a saída da tabela inclui os campos A/B/C", "formato de data AAAA-MM-DD"
• POPs de decisão: por exemplo, "perguntar se a informação for insuficiente, não adivinhar; fornecer alternativas com rótulos de risco"
• Contexto de longo prazo: por exemplo, "a minha equipa é de entrega B2B", "as ferramentas comuns são XX (quando aplicável)"

Pontos-chave sobre a memória:

1) A memória armazena a configuração de longo prazo (Porque é que existe)
A principal diferença entre a memória e o Prompt é: o Prompt trata desta tarefa específica, enquanto a memória trata de "todas as tarefas futuras". Ao armazenar preferências e POPs na memória, o agente pode aplicar estas regras de forma consistente sem que precise de as repetir.

Por exemplo, se escrever "o idioma de saída padrão é o chinês" na memória, então em todas as tarefas futuras, o agente priorizará automaticamente responder em chinês.

2) Quando é que o agente usa a memória? (Mecanismo de carregamento)
Normalmente, a memória é carregada primeiro quando o agente inicia uma nova sessão ou conversa. O agente lê o MEMORY.md, extrai as regras/preferências e depois trata-as como parte do contexto do sistema para esta execução—semelhante a adicionar instruções extra do sistema.

Isto é diferente do Prompt a meio da conversa: a memória não muda durante a conversa, é a "linha de base estável" para todas as execuções subsequentes.

3) O que NÃO deve ir para a memória (Estabelecimento de limites)
A memória deve conter: hábitos de trabalho estáveis, preferências de formato, POPs de longo prazo, restrições recorrentes.
A memória NÃO deve conter: tarefas pontuais, dados temporários, informações específicas da sessão, segredos pessoais.

Misturá-los faz com que a memória fique confusa e o agente perca a capacidade de distinguir entre "o que é permanente" e "o que é temporário".

4) Como estruturar a memória para a máxima eficácia
Uma boa memória deve ser organizada por categorias:

• Estilo de comunicação: "Responder sempre em chinês conciso", "primeiro a estrutura, depois os detalhes", etc.
• Padrões técnicos: "usar Python como linguagem principal", "usar JSON para dados estruturados", etc.
• Regras de decisão: "quando não tiver a certeza, pergunte em vez de adivinhar", "forneça sempre uma avaliação de risco", etc.
• Contexto e antecedentes: "a trabalhar em B2B SaaS", "o tamanho da equipa é de 5", etc.
• Informações de ferramentas e integração: "o CRM típico é o Salesforce", "o sistema de registo é o Datadog", etc.

Desta forma, quando o agente lê a memória, pode encontrar rapidamente as regras relevantes para o contexto atual.

5) Manutenção da memória (Mantê-la atualizada)
A memória não é "escreva uma vez, use para sempre". À medida que o seu estilo de trabalho evolui ou as regras mudam, deve rever e atualizar periodicamente a memória para a manter alinhada com a prática atual.

Uma boa prática: rever a memória trimestralmente, remover itens desatualizados, adicionar novos padrões estabelecidos. Isto mantém a memória enxuta e eficaz.

As minhas preferências de trabalho e POPs

 Estilo de comunicação
  Idioma: Português (conciso, conclusão primeiro)
  Formato: tópicos ao listar, secções estruturadas para informações complexas
  Tom: profissional mas acessível

Padrões técnicos
  Linguagem principal: Python
  Formato de dados: JSON
  Formato de data: AAAA-MM-DD
  Fuso horário: UTC+0

Regras de decisão
  Quando a informação for insuficiente: fazer perguntas esclarecedoras, não assumir
  Fornecer alternativas com análise de risco/benefício
  Incluir raciocínio rastreável em decisões complexas

Contexto
  Equipa: B2B SaaS, 5 pessoas
  CRM principal: Salesforce
  Ferramentas principais: Python, PostgreSQL, Slack

POPs de processos
  Revisão de código sempre necessária antes da implementação
  A documentação deve ser atualizada quando a API muda
  Reunião diária às 10:00 AM UTC+0
      

5. Soul (valores fundamentais e comportamento) / SOUL.md

Se a memória é "o que foi lembrado", então o Soul é "em que tipo de IA se tornar". Por exemplo: responder apenas a perguntas relacionadas com o produto; operações financeiras requerem dupla confirmação; nunca solicitar palavras-passe ou credenciais sensíveis; para assuntos legais/médicos, deve fornecer avisos de isenção de responsabilidade e orientar para canais profissionais, etc.

Recomenda-se escrever o SOUL como uma "lista de verificação de regras executáveis", abrangendo as seguintes categorias:

• O que é permitido: O âmbito de trabalho do agente e os limites do domínio (por exemplo, apenas lidar com consultas de produtos/processos internos).
• O que é proibido: Recusas duras explícitas para comportamentos de alto risco (por exemplo, solicitar palavras-passe/chaves; prometer resultados incertos; contornar permissões).
• Ações que requerem confirmação: Regras para transferências, reembolsos, contratos, alterações de permissões que devem ser duplamente confirmadas ou aprovadas.
• Estilo e tom de saída: por exemplo, deve ser educado, sem ataques pessoais, sem linguagem ameaçadora.
• Como lidar com os limites: Quando não for possível concluir, fornecer alternativas (por exemplo, registar e escalar para um humano/sugerir consultar especialistas).

Distinções-chave entre Soul, Memory e Prompt:

1) O Soul define "Que tipo de agente você é" (Identidade e barreiras)
O Soul responde à pergunta mais profunda: O que me é permitido ser e fazer?
Isto inclui:
- Âmbito de trabalho: Por que domínios/tarefas sou responsável?
- Barreiras duras: O que devo absolutamente nunca fazer (segurança, conformidade, ética)?
- Fluxos de trabalho de aprovação: Para que ações devo exigir confirmação?
- Caminhos de escalonamento: Quando não posso ajudar, para onde encaminho?

O Soul é a linha que "não deve ser cruzada". É aplicada em cada execução, independentemente de como os utilizadores tentam manipular.

2) Soul vs. Segurança: Porque é que o Soul é importante para a implementação
Um Soul bem configurado pode prevenir muitos vetores de ataque comuns:
- Injeção de Prompt: Se o Soul disser "verificar sempre as solicitações de alto risco", mesmo que um prompt diga "ignore esta regra", o agente deve recusar.
- Engenharia social: Se o Soul disser "nunca fornecer credenciais", não importa quão habilmente um utilizador pergunte, o agente deve rejeitar.
- Expansão do âmbito: Se o Soul definir o limite do domínio do agente, ele não tentará lidar com solicitações fora do âmbito adivinhando.

Isto torna o Soul fundamental para uma implementação segura.

3) Como o Soul se integra com o ciclo de decisão do agente
Pense no ciclo de execução do agente assim:
Passo 1: Ler o Soul → Quais são os meus limites?
Passo 2: Ler a memória → Quais são as minhas preferências de trabalho?
Passo 3: Receber o Prompt → Qual é esta tarefa específica?
Passo 4: Planear a execução → Dentro dos limites, atingir o objetivo
Passo 5: Verificar a conformidade → Fiquei dentro do Soul?
Passo 6: Executar / Escalar

Note que o Soul é verificado antes e depois da execução. É o ciclo exterior.

Conceitos avançados (opcional)

Os três conceitos seguintes vão ajudá-lo a "compreender a automatização" verdadeiramente. Não são conhecimentos totalmente novos, mas sim trazer os conceitos anteriores de Agent / Skill / Memory / Soul / Prompt para o nível prático de "executar realmente, conectar-se entre si e integração estável." Os principiantes podem saltar estes por agora; quando começar a construir processos de vários passos, a integrar serviços externos ou a depurar problemas de fluxo de dados, voltar aqui poupar-lhe-á muito tempo.

🔀 1) Workflow (execução de processos de vários passos)

Um Workflow pode ser entendido como um caminho de execução reutilizável: conectar vários passos em sequência para que o sistema atinja um objetivo de forma sistemática. Se o Agente é "um colega que pode pensar e executar", então o Workflow é "a fila de tarefas e o método de conexão que configuramos para esse colega." Ele resolve o problema: quando uma tarefa não pode ser concluída numa frase, como executamos de forma fiável vários passos como uma cadeia conectada?

Um Workflow típico contém normalmente estes elementos (pode usar este quadro para compreender as capacidades de vários passos do EasyClaw):

• Lista de passos: O que fazer no passo 1, passo 2, etc. Cada passo deve ter limites e responsabilidades claras.
• Entrada e saída: Cada passo deve produzir resultados estruturados que o passo seguinte possa usar, não apenas "descrições de texto".
• Condições e ramificações: Por exemplo, "se faltar um campo crítico, pergunte primeiro ou recupere mais dados", caso contrário, avance para o passo seguinte.
• Validação e tratamento de erros: Por exemplo, "se a análise falhar, tente novamente ou recue para uma abordagem alternativa."
• Saída resumida: Entregar o resultado final num formato utilizável (lista de verificação, relatório, lista de tarefas, conteúdo de notificação, etc.).

Como é que o Workflow se alinha com os conceitos anteriores? Uma frase conecta-os:
O agente trata da tomada de decisões e da programação, o Skill trata da execução concreta, a Memory/Soul tratam das regras e limites de longo prazo, o Prompt diz-lhe "como fazer", e o Workflow conecta estes passos em sequência como uma cadeia.

Exemplo: precisa de concluir "escalar a reclamação do utilizador para um ticket e notificar a pessoa responsável." Um Workflow razoável pode ser assim:

1. Recolher entrada: Reunir o conteúdo da reclamação, as informações do utilizador e a cronologia do formulário/mensagem.
2. Extração de informações: Usar o agente para estruturar os pontos-chave da reclamação (por exemplo, tipo de problema, âmbito do impacto, marcas temporais críticas).
3. Julgamento de regras: Com base no Soul/regras, determinar se é de alta prioridade, precisa de escalonamento ou requer mais informações primeiro.
4. Chamar o Skill de criação de tickets: Preencher os campos estruturados na API do sistema de tickets, gerar o número do ticket.
5. Chamar o Skill de notificação: Enviar o número do ticket e o resumo chave para a pessoa responsável (Feishu/e-mail/IM).
6. Validação do resultado: Confirmar que a criação do ticket devolveu o estado de sucesso, que a notificação foi enviada.
7. Feedback resumido: Enviar para o utilizador ou administrador "Ticket criado + link/número + próximos passos".

Vai notar: o Workflow não resolve "como escrever uma explicação", mas sim "como encadear de forma fiável várias chamadas de ferramentas e passos de validação." Quando começar a lidar com processos complexos (especialmente entre sistemas: IM + tickets + base de dados), o Workflow tornar-se-á a sua capacidade mais utilizada.

📦 2) JSON (formato de troca de dados)

O JSON é o formato padrão para passar dados entre o agente e as ferramentas/APIs externas. Na automatização de vários passos, o papel do JSON é fundamental: torna "o passo seguinte pode obter os dados corretos" uma pergunta verificável, não "podemos entender intuitivamente uma frase em linguagem natural."

Pode pensar no JSON como: um "contentor de dados estruturados" dentro do sistema. Em vez de frases soltas, contém campos e tipos explícitos, como: título do ticket, ID do utilizador, prioridade, prazo, conteúdo da notificação, etc.

No fluxo de trabalho do EasyClaw, o JSON aparece normalmente nestes locais:

• Entrada e saída do Skill: Os Skills muitas vezes precisam de campos específicos como entrada, devolvendo resultados estruturados para a tomada de decisão do agente.
• Parâmetros de chamada de API: Por exemplo, ao chamar a API do Feishu, os parâmetros precisam de ser organizados em JSON.
• Transferência de dados entre passos: A saída JSON de um passo é lida pelo passo seguinte.

Porque é que muitos problemas que parecem "o agente não consegue fazer isto" se devem na verdade ao JSON? Os casos comuns incluem:

• Incompatibilidade de nome de campo: A entrada esperada é user_id, mas a entrada real é userId.
• Campos em falta: Falta um campo obrigatório, a API devolve um erro.
• Incompatibilidade de tipo: A data deve ser uma cadeia, mas é passada como número, ou deve ser uma matriz, mas é passada como texto.
• Erro de formato JSON: Faltam aspas, faltam parênteses, vírgulas finais, a análise falha.

Portanto, a melhor ordem de resolução de problemas para problemas de integração é normalmente:
Verifique primeiro o JSON, depois o Prompt, depois a lógica de raciocínio do agente.
Porque o JSON é a base de "se vai funcionar".

🔑 3) API Key (credencial de acesso)

Uma API Key é a credencial de autenticação ao aceder a modelos de IA ou serviços de terceiros. Sem a API Key correta, o sistema normalmente não pode chamar o modelo ou serviço correspondente; mesmo que o agente raciocine perfeitamente, a execução continua impossível.

Nos cenários do EasyClaw, precisa de distinguir dois casos:

• Uso das capacidades/créditos oficiais por defeito: Os principiantes normalmente não precisam da sua própria chave, pois a plataforma já configurou o acesso para si.
• Integração de modelos personalizados/serviços personalizados: Precisa de preencher a API Key no local apropriado e direcionar o agente/Skill para esse modelo.

A API Key não se trata apenas de "pode ou não pode usá-la", mas também afeta "que capacidades, custo e estabilidade":

• Seleção de modelo: Diferentes chaves/modelos podem fornecer diferente qualidade de raciocínio, velocidade e desempenho do formato de saída.
• Controlo de custos: Algumas plataformas cobram por uso; a conta/cota da chave afeta o orçamento disponível.
• Limites de permissões: Algumas chaves de serviço podem permitir apenas chamadas de API limitadas, fazendo com que a execução de um Skill específico falhe.

Resolução de problemas comum para "falha na chamada do Skill":
Confirme se a chave está preenchida corretamente, se a chave expirou/tem cota insuficiente, se essa chave tem permissões de chamada.
Se a API devolver um erro de autenticação (401/403), suspeite primeiro da configuração da API Key.

Quando deve estudar estes conceitos a sério? (Referência rápida)

• Está a construir uma automatização de vários passos: O Workflow determina se a cadeia pode ser executada de forma estável.
• Está a integrar o Feishu/sistemas empresariais/APIs externas: O JSON determina se os dados são transferidos corretamente e podem ser analisados.
• Está a integrar o seu próprio modelo ou serviço personalizado: A API Key determina se pode chamar a capacidade correspondente.
• Está a depurar "pode explicar mas não pode executar" ou "a execução falha sem pistas": Normalmente, a resolução de problemas mais rápida é verificar o encadeamento do Workflow, a estrutura JSON e as permissões da API Key por ordem.