Teatro de um Agente: A Direção de um Sistema Multiagente

64K+ Alcance em 30 dias Sber 365,35 Classificação 165 997 Assinantes Inscrever-se Skaslik Há 25 minutos Teatro de um Agente: A Direção de um Sistema Multiagente Simples 7 min 1.7K Blog da Empresa Sber Análise e Design de Sistemas * Inteligência Artificial Segurança da Informação * Caso de Estudo Olá, Habr! Meu nome é Mikhail Afanasyev, sou o principal especialista da equipe de cibersegurança Platform V na SberTech e estou envolvido na preparação de produtos para a certificação da FSTEC da Rússia. Gostaria de falar sobre a direção de agentes LLM e como a escolha de papéis e a escrita de prompts transformam um fluxo caótico de solicitações para uma rede neural em um sistema de engenharia confiável. A História de uma produção sobre a busca por segredos no código Tudo começou com uma simples fala na escuridão do salão: “Seria legal se alguém pudesse passear pelo repositório por mim e pescar segredos lá dentro”. No início, parecia um monodrama. Um ator (LLM), um microfone (chat), uma tarefa: “Você precisa encontrar algo perigoso nos arquivos”. Mas qualquer diretor dirá: um bom espetáculo não é construído sobre um único monólogo. Se você forçar um ator a correr pelo palco, procurar adereços, analisar pistas e escrever uma resenha para si mesmo, ele se cansará, se confundirá e começará a improvisar onde precisa seguir o roteiro. Assim nasceu a ideia de uma equipe criativa, e em vez de um ator solitário, apareceu uma trupe. Por que a analogia com o teatro? O desenvolvimento de um sistema complexo se assemelha à encenação de uma peça: há um roteiro (prompts), atores (agentes), um diretor (orquestrador), e a interface do usuário ou o log CI/CD é a plateia. Sou apaixonado por teatro há muito tempo, e me pareceu que essa metáfora explica melhor o caos que surge quando um agente tenta interpretar toda a trupe de uma vez. Portanto, usarei os termos do mundo do palco para mostrar como transformar a improvisação em um sistema bem estabelecido. Ato I. De artista a trupe A evolução do nosso projeto passou por dois estágios clássicos, familiares a qualquer pessoa que experimente redes neurais. Monodrama (“Um grande agente”) Concepção: um modelo, um prompt: “Aqui está o código, encontre segredos” Problema: o ator tenta interpretar tudo de uma vez. Ele procura, analisa e escreve um relatório em uma única respiração. O resultado é imprevisível: em algum lugar é genial, em algum lugar são alucinações, e o formato da resposta muda a cada vez. É impossível integrar isso ao CI/CD - é como construir um cronograma de uma apresentação com base no humor do ator principal. Direção (“Eu preciso de ordem”) Surge o desejo de dividir as cenas. Separe a busca, a análise e o final. Por que precisamos dessa trupe? Por que complicar a produção e chamar uma rede neural se houver scanners? O problema é o ruído. Ferramentas especiais, como GitLeaks, produzem uma tonelada de acertos. Uma pessoa não é capaz de realmente olhar para tudo e emitir um veredicto manualmente. Portanto, estamos introduzindo um agente LLM não em vez de uma ferramenta, mas como um filtro inteligente. Como nas soluções SAST modernas, isso é necessário para reduzir o tempo de análise e aumentar a completude da análise. Requisitos para a produção. O sistema assume a forma de uma trupe. Cada agente é um personagem com sua própria biografia (prompt) e tarefa. O sistema deve ter propriedades: Reprodutibilidade: a mesma peça deve soar da mesma forma. Verificabilidade: a lógica não deve se dissolver na improvisação. Escalabilidade: amanhã você pode introduzir um novo personagem (por exemplo, verificação de licenças) sem reescrever toda a peça. Para alcançar tal sistema, devem estar presentes papéis: Diretor (orquestrador): aceita um pedido do espectador e distribui os papéis. Detetive (scanner): vai aos arquivos, procura pistas. Especialista (analista): verifica se esta pista é real ou um falso rastro. Cronista (repórter): escreve um protocolo final para a história. Ato II. Elenco e papéis Se em um diagrama UML clássico as classes são apenas retângulos secos com métodos e campos, então em um sistema multiagente cada “retângulo” ganha vida. “Psicologia” é adicionada à estrutura: um prompt do sistema, estilo de comunicação, prioridades e restrições rígidas que determinam exatamente como o agente reagirá aos dados. Distribuição de papéis Papel Personagem Tarefa no palco Orquestrador Gerente calmo Aceita um pedido, divide-o em cenas, monitora o tempo. Scanner Atencioso, meticuloso Digitaliza texto e relatórios de ferramentas (por exemplo, GitLeaks), não perde detalhes. Ele recebe não apenas o código, mas também os resultados do trabalho de ferramentas especializadas. Analista Crítico, cético Não acredita no Scanner na palavra. Verifica cada descoberta. Repórter Escritor pedante Transforma o caos de dados do Analista em JSON ou Markdown estrito. Protocolo de comunicação (réplicas) Para que os atores não se interrompam, eles precisam de uma sequência de réplicas. Em nosso caso, essas são mensagens estruturadas (JSON) - algo como o texto do papel. Exemplo de réplica do Diretor para o Detetive: Um contrato claro permite substituir os atores. Se amanhã o Detetive se cansar (por exemplo, o modelo se tornar caro), você poderá substituí-lo por outro sem alterar o roteiro para o Diretor. { "role": "code_scanner", "task": "scan_files", "payload": { "root_path": "/repo", "files": [ { "path": "src/app.py", "content": "..."} ] "tool_results": [ { "source": "gitleaks", "findings": [...] } ] }, "meta": { "request_id": "123e4567", "status": "pending" } } Ato III. Roteiro como lei Um prompt em um sistema multiagente é como um roteiro completo. Ele especifica não apenas “o que dizer”, mas também “como interpretar”, “qual é a motivação” e “o que fazer em uma situação de emergência”. A estrutura de um roteiro ideal. Um bom prompt é um equilíbrio entre a liberdade do ator e a disciplina do diretor. Modelo de prompt para um agente Detetive: Papel: Você é um agente LLM especializado em detectar segredos no código-fonte. Seu personagem é atencioso, meticuloso e cauteloso. Objetivo (motivação): — Encontrar segredos em potencial (senhas, tokens). — Minimizar falsos positivos (não levantar alarme desnecessariamente). — Fornecer uma justificativa clara para cada descoberta. Contexto (cenário): — Os segredos vivem em strings, variáveis de ambiente, configurações. — Arquivos e resultados do trabalho de ferramentas especializadas são recebidos como entrada. — Strings como “TODO”, “FIXME” não são segredos, ignore-as. — Números curtos (1, 0, 123) não são segredos. Formato de saída (regulamento): Responda estritamente no formato JSON. Nenhum texto fora do JSON. json > { >   "secrets": [ >     { >       "file": "caminho/para/arquivo", >       "line": número_da_linha, >       "snippet": "string suspeita", >       "reason": "explicação curta" >     } >   ] > } Restrições (proibições): — Não invente arquivos. Use apenas os dados fornecidos. — Se não houver segredos, retorne { "secrets": []} . Direção através de cadeias (Prompt Chaining) É importante não jogar tudo em um monte. A apresentação acontece em atos: Ato 1 (Orquestrador): recebe a tarefa “analisar o repositório”; decide quais cenas (arquivos) interpretar. Ato 2 (Scanner): recebe arquivos, procura candidatos. Ato 3 (Analista): confirma ou descarta candidatos. Final (Repórter): reúne tudo em uma forma legível. Cada ato tem seu próprio prompt para que você possa depurar cada cena separadamente. Ato IV. Mecânica da ação teatral (código) Como isso se parece nos bastidores? O princípio de “um papel teatral - uma classe de programa” simplifica o desenvolvimento. Cada classe encapsula seu próprio prompt do sistema, sabe quais dados aceitar como entrada e regula estritamente o formato da resposta. Envolvemos o cliente LLM em uma classe que armazena seu prompt do sistema e sabe como interagir com a plateia. class AnalyzerAgent: def init(self, llm_client, system_prompt: str): self.llm = llm_client self.system_prompt = system_prompt # Roteiro do papel

def analyze(self, text: str) -> dict:
    # Formamos o contexto do diálogo
    messages = [
        { "role": "system", "content": self.system_prompt},
        { "role": "user", "content": f"Analise este texto:\n\n{text}"}
    ]
    # Chamada do modelo (Interpretação do ator)
    response = self.llm.chat(messages)
    
    # Validação da resposta (Controle do diretor)
    try:
        return json.loads(response["content"])
    except json.JSONDecodeError:
        return {"error": "Actor broke character", "raw": response["content"]}

Lista de verificação antes de entrar no “palco” Antes de escrever o código, fiz as seguintes perguntas, como ao preparar uma peça: O que o ator (agente) deve fazer sozinho? Quais adereços (dados) estão disponíveis para ele? Quais decisões ele toma sozinho e quais ele leva ao julgamento do espectador? E assim foi registrado na especificação: Descrição → Entrada → Saída → Restrições. Isso o salvará do caos nos prompts. Exemplos de réplicas Para que a teoria não permaneça abstrata, vamos ver como os agentes trocam “réplicas” em um exemplo específico. Digamos que estamos digitalizando o arquivo config.py .

1. Scanner (procurando pistas) Dados de entrada: fragmento de código API_KEY = "sk-1234567890" . Resposta do agente (JSON): { "secrets": [ { "file": "config.py", "line": 15, "snippet": "API_KEY = "sk-1234567890"", "reason": "Parece uma chave de acesso à API, alta entropia da string" } ] }
2. Analista (verificando pistas) Dados de entrada: o resultado do Scanner. Tarefa: confirmar se este não é um valor de teste. Resposta do agente (JSON): { "verified": true, "confidence": 0.95, "comment": "A chave tem o prefixo sk-, característico do ambiente de produção. Não parece um placeholder." }
3. Repórter (protocolo final) Dados de entrada: uma descoberta confirmada do Analista. Resposta do agente (Markdown):

Relatório de Segurança