Identificar responsabilidades, riscos, antipadrões e necessidades de rastreabilidade
À medida que os agentes se tornam mais capazes, pode ser tentador imaginar que a responsabilidade muda para o sistema. Isso não acontece. Os sistemas agente podem executar o trabalho, mas os humanos permanecem responsáveis pelos resultados e pelos controles que regem a execução.
Nesta unidade, você aprenderá
Quem é responsável por ações e resultados do agente
Quais riscos comuns e antipadrões aparecem em sistemas de agente
Como os controles de GitHub reduzem esses riscos
Por que a rastreabilidade e a observabilidade são necessárias para sistemas confiáveis
A responsabilidade não se move com a execução
Quando um agente cria uma solicitação de pull, revisa o código ou responde aos comentários, ele participa do fluxo de trabalho, mas não assume a propriedade dos resultados. As partes responsável ainda são as pessoas e as equipes que:
Definido a tarefa
Definir permissões
Escolher e configurar controles
Aprovada a alteração resultante
Um modelo de revisão de pull request torna isso explícito: o sistema pode propor, mas os humanos decidem o que será aceito.
Riscos comuns e antipadrões
Os sistemas de agente em estágio inicial geralmente falham de maneiras previsíveis:
Execução sem planos O agente começa a alterar o código sem uma abordagem clara e inspecionável.
Agentes com permissão excessiva O agente (ou seu token ou credenciais de ferramentas de fluxo de trabalho) tem acesso mais amplo do que necessário.
Raciocínio oculto O fluxo de trabalho expõe apenas saídas (a diferença) sem artefatos intermediários (plano, suposições, pontos de decisão, contexto de execução).
A confiança cega na automação é perigosa. Passar nos testes de Integração Contínua importa, mas as verificações apenas validam o que foram projetadas para detectar. Uma compilação aprovada não significa automaticamente que a alteração esteja completa, apropriada ou de baixo risco.
Mapeamento de implementação: risco → mitigação de GitHub
| Risco/antipadrão | Como aparece no GitHub | Mitigação usando os controles do GitHub |
|---|---|---|
| Execução sem plano | PR tem uma diferença, mas nenhum plano ou lógica | Exigir uma seção de plano por meio do modelo de PR; exigir revisão antes da mesclagem |
| Agentes com permissão excessiva | Os fluxos de trabalho podem gravar no repositório e acessar segredos de forma abrangente. | GITHUB_TOKEN com privilégios mínimos; ambientes que requerem revisores; restringir quem pode iniciar fluxos de trabalho |
| Raciocínio oculto | Nenhuma suposição/escopo/trilha de decisão | Exigir a execução de planos e vincular fluxos de trabalho, registrando decisões em comentários de PR. |
| Confiança cega na automação | Mentalidade de "CI passou, enviar" | Combine verificações com CODEOWNERS, revisões necessárias e aprovações com base em riscos |
Rastreabilidade e observabilidade
Para supervisionar bem o desempenho de um agente, você precisa de mais do que apenas uma diferença final - você precisa de um histórico. Em GitHub, essa trilha pode incluir:
Histórico de pull requests e commits
Examinar comentários e aprovações
Execuções de processos de trabalho e artefatos carregados (relatórios de teste, registros)
Uploads e alertas de verificação de código
Alertas de verificação secretos e eventos de proteção por push
Eventos de log de auditoria da organização (disponibilidade e acesso dependem da configuração da organização/empresa)
A meta não é apenas a conformidade. É uma compreensão operacional: quando algo falha, você precisa saber o que mudou, quem a aprovou, quais evidências existiam e o que aconteceu a seguir.
Trilha de auditoria mínima para contribuições de agente
Uma meta declarada (link de problema ou descrição de PR)
Um plano inspecionável (seção ou arquivo do plano de PR)
Um conjunto de alterações limitado (branch e commits)
Evidências automatizadas (execução de workflow e artefatos)
Julgamento humano (revisão e aprovação)
Um resultado claro (mesclagem, reversão ou escalonamento)
Suponha que a correção de falhas de segurança do agente passe pelos testes de CI, mas posteriormente cause uma regressão. A questão chave não é apenas se o agente cometeu um erro. É se o sistema cometeu o erro compreensível e evitável:
Havia um plano e um escopo visíveis?
Foram solicitados os revisores certos (e eles aprovaram)?
As verificações corresponderam ao risco da alteração?
A trilha de auditoria é suficiente para reconstruir o que aconteceu?
Os sistemas agente mudam quem executa o trabalho, mas não quem possui resultados. As equipes humanas permanecem responsáveis, e é por isso que devem projetar contra os antipadrões comuns e exigir uma forte rastreabilidade por meio de artefatos e logs nativos do GitHub.
Depois de entender como a responsabilidade funciona, a etapa final é decidir como o trabalho do agente deve ser julgado. Na próxima unidade, você aplicará o modelo de contribuidor ao resultado gerado pelo agente.