Pular para conteúdo

Agentes de IA

Responsabilidades separadas

O projeto possui três agentes conversacionais: Triagem, Qualificação e Coleta. São papéis de prompt acionados pelo estado da sessão, usando o mesmo contrato de saída e a mesma interface LLMClient. Não são processos autônomos com ferramentas livres: o modelo propõe um código s, e o dispatcher interpreta as ações permitidas.

Agente Estado Responsabilidade Prompt
Triagem TRIAGE Receber, identificar segmento/intenção e encaminhar src/core/agents/triagem/system_prompt.py
Qualificação QUALIFYING Identificar serviço canônico e coletar parâmetros src/core/agents/qualificacao/system_prompt.py
Coleta DATA_COLLECT, CONFIRM Coletar cadastro e pedir confirmação src/core/agents/coleta/system_prompt.py

AgentName também contém orchestrator e summary, usados no log/suporte. Isso não cria um quarto ou quinto agente selecionável pela máquina de estados. O resumo operacional é uma chamada separada com JSON puro, diferente de {JSON}Mensagem.

Invocação

src/core/application/agent_invoker.py define o Protocol AgentInvoker.invoke(...). A implementação real AgentInvokerImpl, em src/core/agents/invoker.py, recebe settings, cliente LLM, KB e repositories opcionais de prompts/configuração. Seu retorno é LLMCallResult(raw_response, model, tokens_input, tokens_output, latency_ms).

flowchart TD
    S[Estado da sessão] --> A[Selecionar agente]
    A --> P[Builder do system prompt]
    DB[Override administrativo ativo] --> P
    P --> G[Adicionar guards fixos]
    H[Histórico somente da sessão] --> M[Montar mensagens system/user/assistant]
    K[Packages solicitados] --> P
    G --> M
    M --> L[LLMClient.chat / Responses API]
    L --> R[Parser estrito e dispatcher]
    R -->|s=99| K
    R -->|próximo agente| A
    R --> O[Persistir ação e retornar resposta]

O invocador consulta todos os IDs disponíveis na KB e injeta o catálogo compacto no prompt. Somente conteúdo de packages já coletados entra integralmente. Histórico INBOUND vira user, OUTBOUND vira assistant, eventos SYSTEM e mensagens com error="superseded" são excluídos. Há dupla proteção de session_id: no repository e no invocador. A mensagem atual não é duplicada quando já consta como última entrada do usuário.

Metadados e configuração

Toda chamada recebe identidade, instância, horário comercial e catálogo/contextos. Qualificação recebe segmento, intenção e dados técnicos parciais; Coleta recebe telefone e cadastro parcial. Triagem recebe nome reconhecido e configuração de empresas estratégicas. O builder da Coleta aceita serviço e qualificação como parâmetros, mas a interpolação atual do prompt usa principalmente cadastro, segmento e histórico; não se deve assumir que cada parâmetro aceito aparece textualmente no prompt final.

OPENAI_MODEL_TRIAGE, OPENAI_MODEL_QUALIFICATION e OPENAI_MODEL_COLLECTION selecionam modelos por papel; OPENAI_MODEL_SUMMARY serve resumo e reparo de formato. Os defaults de load_settings() são gpt-4o-mini; outras fontes de configuração podem sobrescrevê-los. MAX_HISTORY_MESSAGES tem default 50, MAX_CONTEXT_ENRICHMENTS_PER_MESSAGE default 2. Consulte a referência de configuração.

Regras fixas e overrides

Prompts podem ser sobrescritos por VersionedResourceRepository. Após renderizar o override, _with_runtime_guards() acrescenta identidade única baseada em AGENT_NAME, instância/segmento/intenção, proibição de prometer prazo humano e regra de confirmar troca de assunto. Em Qualificação/Coleta, contexto GoYou ou segmento HUMANO acrescenta limites de saúde mesmo sem package injetado.

Isso torna algumas instruções resistentes à remoção pelo editor de prompt. Não é um validador semântico de toda frase do modelo: validação programática cobre formato, códigos, enums e campos específicos; veracidade clínica/comercial continua exigindo prompt, conhecimento confiável e testes.

Falhas e manutenção

Parse inválido recebe uma tentativa de reparo; código inválido não é aceito apenas porque o JSON é válido. Package desconhecido, limite de enriquecimento ou incerteza levam ao humano. O caso de uso controla persistência, CRM e envio; o invocador apenas monta e faz a chamada.

tests/unit/agents/test_invoker.py verifica modelo por agente, histórico, não duplicação, metadados e guards após override. tests/unit/agents/test_system_prompts.py verifica instruções dos builders. tests/unit/application/test_action_mapping.py e test_process_message_use_case.py verificam consequências determinísticas. Fixtures e integrações reais têm finalidade distinta; veja testes.

Ao alterar um agente, mantenha enum, dispatcher e prompt sincronizados, acrescente regressão pequena e revise a máquina de estados. Uma mudança apenas de estilo não deve introduzir um código ou estado novo. Consulte contrato e como modificar.