Apresentação: Engenharia de Contexto no LinkedIn: Como construímos uma Camada de Contexto Organizacional para Agentes de IA com MCP
Transcrição
Ajay Prakash: O meu nome é Ajay Prakash. Sou engenheiro de software no LinkedIn. Vou falar de engenharia de contexto no LinkedIn. Imagine que você é engenheiro em uma empresa de software, uma grande empresa de software, e acontece que você está de plantão para sua equipe. Sua equipe possui um conjunto de serviços muito críticos, que é usado por milhões de usuários. De repente, você recebe um alerta de pager sobre um pico de latência em um de seus serviços. Está causando ruptura para muitos de seus usuários. Enquanto você está tentando descobrir como lidar com este problema, e como mitigá-lo mais rápido, você pega o link para esse alerta e dá-lo a um agente de codificação, como GitHub Copilot. O agente de codificação, ele busca as instruções sobre como descobrir como depurar esse problema, ou alertas de depuração em sua empresa. Identifica que esta questão vem de um dos seus serviços.
Em seguida, também obtém instruções sobre como depurar esse serviço. Com base nessas instruções, ele busca os logs, métricas e mudanças recentes, e implantações que entraram. Ele identifica que a questão está vindo por causa de um serviço diferente, que é um serviço a jusante, que está jogando um monte de erros. Em seguida, o agente de codificação também vai e obtém a instrução sobre como depurar o problema no serviço a jusante. Ele faz a mesma coisa com base nas instruções sobre como obter os logs, métricas, e identifica que houve uma mudança recente de código PR que entrou, que foi buggy, e ele foi implantado, e está causando todos os problemas. O mais impressionante é que o agente conseguiu descobrir todas estas coisas, enquanto você estava a descobrir como lidar com esse problema. Uma vez que encontra a informação, também cria um resumo detalhado para você sobre o que encontrou e qual foi a causa raiz, e quais são os passos, ou ações necessárias para ser tomada para mitigar o problema.
Uma vez que você confirmar isso e verificar, ele também irá em frente e tomar a ação para mitigar o problema. Isto acontece dentro de alguns minutos. O agente codificador não pára por aí. Ele também vai e criar um relatório detalhado e atualiza o sistema de gerenciamento de incidentes para você. Além disso, ele vai além de onde ele busca instruções sobre como fazer a codificação no serviço afetado onde o bug estava acontecendo, e também cria um PR para você. Como disse, tudo acontece dentro de alguns minutos. Isso teria sido fácil, sem agentes codificadores, algumas horas de tempo. Isto não é ficção. É assim que as equipes do LinkedIn estão usando agentes de codificação como colegas muito produtivos com um profundo conhecimento sobre Linked Em sistemas para automatizar seus fluxos de trabalho e ser muito produtivo. Este é apenas um exemplo. Temos mais de 600 fluxos de trabalho e milhares de ferramentas que ajudam as equipes a automatizar seus fluxos de trabalho. Isso é possível por causa de um sistema que construímos, estamos chamando-o de Playbooks e Ferramentas do Agente Contextual. Hoje, vou analisar por que o construímos e como construímos o sistema, e o que aprendemos construindo o sistema, e com o seu sucesso.
Agentes de codificação
Para entender por que construímos este sistema, temos que voltar no tempo dos primeiros dias de assistentes de codificação de IA. Os primeiros assistentes de codificação foram baseados principalmente LLM autocompletar inteligente, onde ele irá ajudá-lo a completar automaticamente uma frase, ou uma linha, ou um bloco de código com base no contexto que ele tem. Em seguida, o modo agente foi introduzido em diferentes ferramentas de codificação. O modo agente era realmente poderoso porque o agente agora com agentes com IA agora tem acesso a ferramentas para editar os arquivos e também executar comandos de terminal. Agora eles poderiam descobrir como fazer as mudanças e não apenas sugerir essas mudanças, eles também podem ir em frente e fazer essas mudanças. Eles podem editar vários arquivos dentro de sua área de trabalho. Isto foi muito poderoso. No início de 2025, Andrej Karpathy chamou famosamente esta codificação vibe. A ideia é que não tens de olhar para o código. Você pode apenas continuar alertando o agente sobre o que você quer e o agente vai descobrir que mudanças fazer e ele vai fazer as mudanças.
Como ele tem acesso ao terminal, ele também executará alguns comandos para verificar as alterações que ele faz. Só tens de ver a saída. Esta ideia era realmente poderosa e criou muita publicidade em torno da indústria. Tal como qualquer outra empresa, mesmo no LinkedIn, houve muita excitação em usar estes agentes codificadores. Nós fornecemos acesso às ferramentas de codificação no início para todos os engenheiros. Também queríamos que todos o usassem e fossem realmente produtivos. Muitos de nós tentamos os agentes de codificação para fazer codificação de vibração ou para se tornar codificação automatizada em nosso Linked Na base de códigos. Não estava a funcionar. A codificação da vibração não estava a funcionar. Sabes porque não estava a funcionar? A questão principal era que a base de códigos do LinkedIn é tão madura e há muito contexto interno. Os agentes não tinham o contexto de como fazer as mudanças corretamente.
Mesmo que a ideia seja realmente poderosa, mas quando você tentar em sua empresa, os agentes perdem muito do contexto e ou produzem resultados subpar ou ele vai alucinar completamente e criar código errado. Os engenheiros tinham que dar constantemente as instruções certas e dar o contexto certo aos agentes para guiá-los na direção certa. Isto foi o contrário do que você espera, porque você quer ser produtivo, mas agora você está cuidando desse agente para fazer a coisa certa e entender a base de código da sua empresa. Muitos engenheiros voltaram à codificação manual regular porque todos têm prazos para isso. Não estava a funcionar como esperávamos.
Pilha Massiva do LinkedIn
Para compreender este problema de forma mais concreta. Se você olhar para a pilha LinkedIn, é enorme. Temos milhares de acordos, milhares de microserviços e aplicativos, que dependem uns dos outros. Eles são todos construídos usando um monte de frameworks internos em cada camada. Além disso, temos um monte de infra personalizado construído. Por exemplo, temos nossos bancos de dados personalizados construídos. Temos um sistema personalizado de rastreamento e experimentação, observação e gerenciamento de configuração, que são realmente maduros. Estes são construídos para lidar com os desafios únicos da escala LinkedIn. Engenheiros, quem quer que se junte ao LinkedIn, passam mais de uma semana através de um rigoroso bootcamp, apenas para tentar entender os sistemas internos, familiarizar-se com eles. Também leva algumas semanas para eles serem realmente produtivos porque há muito para aprender e fazer as coisas direito. O mesmo problema é com os agentes de codificação também. Você simplesmente não pode jogar um agente de codificação em um sistema tão maciço e esperar que eles sejam produtivos.
Fizemos esta pergunta a nós mesmos, como fazemos esses agentes de codificação entenderem os sistemas internos do LinkedIn tão bem que eles podem enviar o código em que nossos engenheiros podem confiar? Um dos problemas com os agentes de codificação também era que os engenheiros não podiam realmente confiar no código que estava sendo produzido porque nós temos uma barra de alta qualidade para código e também a confiabilidade dos sistemas. Como os agentes não tinham o contexto certo, não podemos confiar no código que estava gerando. Nós nos perguntamos, como fazemos o código que é gerado por esses agentes realmente confiável?
Modelo de protocolo de contexto
Ao mesmo tempo, o Anthropic lançou e open-sourced Model Context Protocol, ou MCP. Tornou-se muito popular e também foi adotado como um padrão aberto. Tornou-se um padrão aberto para conectar as ferramentas aos agentes. Todos os agentes de codificação passaram a apoiar o MCP. Este foi um momento muito bom para nós, porque agora podemos conectar os agentes de codificação e ampliar sua capacidade adicionando as ferramentas para que eles possam acessar nosso sistema interno e entender nosso sistema interno. O primeiro conjunto de ferramentas que adicionamos foi a pesquisa de código. Já tínhamos um sistema de busca de código muito sofisticado, que os engenheiros usavam. Este mecanismo de busca de código, ele basicamente ingere todo o código dentro do LinkedIn através de 1.000 acordos e permite que os engenheiros para procurar código usando palavras-chave ou regex e filtros avançados como tipos de arquivos e linguagem. Agora usando o MCP, nós embrulhamos esta ferramenta de busca de código para consultar o código para trechos de código relevantes, e também obter o conteúdo do arquivo, e conectá-lo aos agentes de codificação.
Este foi um desbloqueio realmente enorme porque agora os agentes de codificação não têm apenas que confiar em seus dados pré-treinados. Porque, lembrem-se, todos estes LLMs são treinados em código de código aberto. Eles são realmente bons em gerar o código, mas eles não sabem o que o código em Linked Parece que sim. Ao adicionar capacidade de busca de código, agora os agentes de codificação foram capazes de usar as ferramentas para entender como o código se parece no LinkedIn, realizando uma consulta e obtendo os exemplos relevantes. Além disso, se precisarem, também podem ler o arquivo inteiro. Os LLMs, ou os agentes de codificação em geral, são muito bons em chamar ferramentas. Os usuários, mesmo que você dê uma consulta de linguagem natural como, me mostre como fazer um exemplo LangChain. Mesmo que a consulta seja realmente vaga e em linguagem natural, os agentes de codificação podem repetidamente usar a ferramenta de busca de código para descobrir quais consultas usar.
Eles podem repetidamente chamar a busca de código com diferentes tipos de coisas e improvisar e encontrar o contexto relevante, e então resumir isso. Isto era muito poderoso e destrancava muitas possibilidades. Com isso, também começamos a adicionar mais e mais ferramentas. Por exemplo, tornamos possível que os agentes de codificação procurassem os documentos e wikis, e também, você pode dar qualquer link para o documento ou o wiki, eles podem ler isso e colocá-lo no contexto. Da mesma forma, adicionamos ferramentas para ler as bandeiras de recursos, gerenciamento de tarefas e plataforma de dados. Cada ferramenta que nós adicionamos, o que ele desbloqueou foi agora os agentes podem obter melhor e mais rico contexto para fazer o seu trabalho. Por exemplo, usando documentos, agora você pode dar documentos de exigência de produto e também documentos de arquitetura e algumas páginas wiki, que foram criadas pela equipe, que tem um grande contexto interno. Agora os agentes de codificação têm acesso a ele.
As lacunas de contexto
Está tudo bem. Agora os agentes conseguem entender todo o contexto, mas mesmo assim, não estava funcionando. Especialmente se a tarefa se torna ainda ligeiramente complexa, os agentes não foram capazes de fazê-lo ponta a ponta. Você não podia confiar em agentes para descobrir tudo e fazer uma tarefa um pouco complexa de ponta a ponta. Os principais problemas foram, o primeiro é o conhecimento tribal. Para fazer qualquer tarefa de codificação, não se trata apenas de descobrir como encontrar os exemplos de código relevantes e apenas fazer a codificação. Também envolve descobrir como instalar as dependências e escrever comandos para compilar o código ou testar o código. Estas são todas as nuances do conhecimento. Estes foram espalhados por muitos documentos, wikis e fios Slack. É apenas conhecimento tribal, que vive na cabeça de um engenheiro sênior. Mesmo com todas essas ferramentas, os agentes codificadores não conseguiram encontrar o contexto relevante.
É como encontrar a agulha no palheiro. Este é um problema. O segundo problema é a sobrecarga de contexto. Sempre que um agente usa uma ferramenta específica, a saída da ferramenta também ocupa espaço no contexto LLMs. Todos os LLMs têm uma janela de contexto limitada. Estão cada vez maiores, mas é limitado. O que acontece quando os agentes de codificação tentam procurar o contexto relevante para fazer uma determinada tarefa? Quanto mais ferramentas usam, ficam sobrecarregados com o contexto. Finalmente, em certo ponto, eles resumem todas essas informações usando compactação. Uma vez que a janela de contexto é compactada, ela perde muita informação. Então ele tem que fazer todas as chamadas de ferramenta novamente para encontrar esse contexto relevante. Esta é uma das razões pelas quais, às vezes, agentes codificadores entram em um loop estranho onde eles fazem um monte de chamadas de ferramenta, descobrir como fazer as coisas, mas de repente, eles ficam resumidos, e eles vão esquecer o que eles estavam fazendo, e eles começam a fazer tudo de novo.
Esse é o problema de sobrecarga de contexto. Outro grande problema é que o agente não tem uma memória de longo prazo. Os agentes codificadores, agora estamos vendo alguma forma de memória, mas estes foram os primeiros dias, e não havia memória duradoura de longo prazo. O problema com isso é mesmo se o agente descobrir por todas as chamadas de ferramenta e todo o contexto que você dá à mão, da próxima vez que você quiser fazer a mesma tarefa, o agente tem que descobrir todas essas coisas novamente. Isso é realmente demorado, porque se você é um engenheiro e você está fazendo uma tarefa, você quer obtê-lo muito rápido. Se o agente está sempre começando do zero e tentando descobrir todas essas coisas novamente, não é realmente uma boa experiência. Além disso, isso é muito caro porque ele ocupa um monte de fichas.
Memória Procedural - Playbooks
Qual é a solução para tudo isto? Naturalmente, como disse, a solução é fornecer memória. Como fazemos os agentes lembrarem-se de um contexto sobre como fazer as coisas? Temos de compreender a memória processual. A memória processual é apenas o contexto de como fazer as coisas. Se o agente, por exemplo, sempre que você dá uma tarefa, ele tinha descoberto todo o contexto que ele precisa para executar um trabalho e foi capaz de chegar ao estado final, você armazenar esse contexto, armazenar todo o contexto relevante como uma memória processual. Quando o agente quer fazer a mesma tarefa da próxima vez, você serve essa memória procedimental em todos os passos e todas as informações de fundo e conhecimentos matizados para os agentes para fazer a mesma tarefa novamente. Dando esta memória processual, se você é capaz de fazer isso de forma eficiente, então você pode fazer os agentes lembrar as coisas e fazer toda a tarefa sem tomar muito tempo e também sem queimar um monte de fichas.
Esse é todo o conceito de memória processual. Essa memória procedimental é também o conceito por trás das habilidades do agente, que é de fonte aberta pela Anthropic. No LinkedIn, tivemos uma implementação semelhante. Não usávamos habilidades de agente porque não era uma coisa naquela época. Desenvolvemos o nosso próprio conceito de memória processual, chamávamos-lhe playbooks. O que são manuais? Lembre-se, construímos um MCP e conectamos as ferramentas. Usamos o mesmo MCP para servir a memória processual. Chamamos-lhe playbooks. Sempre que você quiser fazer uma determinada tarefa, temos um playbook para isso, que consiste em nome, descrição e instruções. O nome e descrição dão a dica ao agente de codificação sobre o que é essa tarefa específica. Agora os agentes de codificação podem invocar os playbooks como ferramentas regulares. Quando invoca, todas as instruções são devolvidas como uma saída de ferramenta para o agente de codificação. Por exemplo, há um playbook para escrever gasodutos offline usando Airflow.
Se um engenheiro perguntar, podes montar-me um gasoduto? Em seguida, o agente de codificação percebe que ele tem acesso ao Playbook Airflow via MCP e invoca que para obter o contexto relevante. Ele também pode obter o contexto do usuário sobre quais mudanças específicas ele precisa fazer. Ele usa todo esse contexto para executar a tarefa. Qualquer pessoa no LinkedIn pode criar um playbook e configurá-lo em um repositório central. Agora está disponível para todos no LinkedIn. Este é um conceito realmente poderoso, e tornou possível compartilhar os impulsos e compartilhar o contexto.
Como é um bom livro de jogadas? Além disso, sempre que estamos criando playbooks, temos que manter essas duas coisas em mente. Estas são as filosofias de design que tentamos impor. A primeira filosofia é o playbook deve ser auto-suficiente, o que significa que um playbook deve fazer exatamente uma coisa específica. Por exemplo, se é para criar o Airflow, deve ter todos os conceitos e instruções e tudo. Se há um playbook que está fazendo várias coisas diferentes, é melhor dividi-lo em vários playbooks. O agente pode sempre decidir escolher qual playbook usar. A segunda filosofia de design é a composibilidade, o que significa que se você tem um playbook muito longo, e há algumas tarefas que podem ser extraídas, então é melhor criar playbooks menores, que podem ser referenciados pelos playbooks maiores. Isso é semelhante a como você faz a reutilização de código, onde você quebra o código em vários lugares.
Existem duas principais vantagens desta composibilidade. O primeiro é reutilização. Como eu disse, assim como código, os playbooks também podem ser reutilizados, onde vários playbooks podem referenciar os playbooks menores para fazer uma determinada ação. A segunda maior vantagem é a progressiva divulgação do contexto. O que quero dizer com isso é, quando os agentes de codificação querem realizar uma tarefa, querem obter um contexto, se eles carregam todo o contexto de uma só vez, isso sobrecarrega o contexto. Também não é bom para o desempenho do agente. Com a progressiva divulgação do contexto, quando um grande livro de jogos referencia pequenos playbooks, e assim por diante, os agentes só podem optar por ler os playbooks menores se necessário. Se não precisarem, podem saltar isso. Trata-se de uma gestão eficiente do contexto. Com estas duas filosofias, agora podemos criar um contexto organizacional dentro do LinkedIn, onde você pode quase capturar todo o contexto dentro do LinkedIn como um gráfico de playbooks, que o agente pode agora navegar para descobrir como fazer as coisas no LinkedIn, e fazer tarefas de execução mais e mais tempo.
Como estamos criando cada vez mais playbooks, há um problema comum. Com qualquer base de conhecimento, fica desatualizado, porque esses playbooks são criados em algum momento do tempo, naquele momento você capturou certas instruções. À medida que os sistemas evoluem, as instruções nesses playbooks ficam desatualizadas. A grande coisa sobre os agentes de codificação é que eles podem improvisar, o que significa que quando eles usam um playbook, e se eles detectarem que há informações desatualizadas, eles não param por aí, eles podem improvisar e descobrir qual é a solução certa usando as ferramentas que temos. Uma vez que eles encontram a solução certa, e também, eles podem descobrir que a informação está desatualizada, e eles podem tentar encontrar quais são as últimas informações, ou eles podem sempre pedir ao usuário do agente de codificação para fornecer as informações relevantes. Isso também funciona para qualquer caso de borda. O manual não tem de ser perfeito desde o primeiro dia.
Você pode começar com um conjunto básico de instruções, e há sempre casos de borda, e os agentes, eles são realmente bons em encontrar alguns casos de borda. Temos em nosso sistema o prompt, que incentiva os agentes de codificação a sempre capturar essas aprendizagens, informações desatualizadas ou quaisquer casos de borda, e resumir isso no final da sessão. Em seguida, também encorajamos os agentes de codificação a verificar o código para os playbooks, e também capturar todas as suas informações para atualizar o playbook, que agora pode ser verificado. Isso cria um volante muito bom onde cada vez mais os playbooks são usados, os agentes, eles podem atualizá-lo com os novos aprendizados. A memória procedimental, quanto mais é usada, fica cada vez melhor.
Arquitetura
Como é que tudo parece do ponto de vista da arquitectura? Temos um servidor MCP local. Todas as ferramentas e playbooks são servidos através deste servidor MCP. Temos dois tipos de playbooks, playbooks centrais e playbooks locais. Este é apenas outro aspecto de engenharia de contexto onde certos playbooks são usados apenas ou necessários em um repositório específico. Somente quando o usuário estiver trabalhando nesse repositório, você precisará desse playbook. Como estamos usando um servidor MCP local, temos acesso ao sistema de arquivos. O servidor MCP também tem a consciência de qual diretório ele está trabalhando. Quando o servidor MCP começa, e identifica em qual espaço de trabalho ele está trabalhando, e se ele tem o diretório playbooks, então ele pode carregar todos os playbooks nesse diretório. Todos os playbooks da equipe e os playbooks específicos do repositório podem ir aqui. Eles também são verificados com o repositório onde eles existem, para que as equipes possam criar todos os seus playbooks sem ter que se preocupar em sobrecarregar o sistema.
Então nós temos os playbooks centrais, estes são os playbooks que são aplicáveis em vários repositórios. Queremos ter certeza de que apenas playbooks que são aplicáveis nos repositórios ou mesmo sem repositórios, eles entram aqui. Então temos ferramentas. Todas as ferramentas requerem autenticação. Temos uma biblioteca de autenticação perfeita onde cada ferramenta, eles se conectam ao nosso sistema interno ou ao nosso sistema externo, e eles precisariam de algum tipo de autenticação. Isso acontece usando uma autenticação sem costura onde sempre que o usuário está usando a ferramenta pela primeira vez, e ele identifica que ele requer autenticação, ele lança o fluxo de autenticação, geralmente OAuth, e o usuário pode autenticar. A camada de autenticação captura os tokens e armazena-os num chaveiro seguro. Em seguida, a execução da ferramenta continua. Na próxima vez que a ferramenta for chamada, ela pode obter os mesmos tokens, atualizar os tokens e executar a execução da ferramenta.
Este servidor MCP, também é pré-instalado em todos os laptops do LinkedIn. Também é atualizado automaticamente a cada hora sempre que há uma atualização. Isso significa que qualquer pessoa pode criar um playbook ou uma ferramenta, e uma vez que ele é implantado, ele está disponível para todos os outros dentro de uma hora. Cada ferramenta que criamos tem que passar por nossa revisão InfoSec. Porque o MCP é bastante novo, e ele pode abrir uma lata de worms para um monte de problemas de segurança, ter tudo em um lugar ajuda nossa equipe a garantir que cada ferramenta é auditada e também toda ferramenta é segura.
Quantos de vocês estão se perguntando, quantas ferramentas esse servidor MCP pode caber antes de degradar o desempenho? Alguém quer saber quantas ferramentas? Acho que este é um problema geral com o próprio MCP, onde estou falando sobre criar milhares de ferramentas. Se você está familiarizado com o MCP ou em geral ferramentas, cada ferramenta ocupa espaço no contexto, e como cada vez mais ferramentas são dadas ao agente de codificação, ele ocupa um monte de espaço em sua janela de contexto, e degrada o desempenho do próprio agente. Por exemplo, se você adicionar um monte de ferramentas e mesmo que você não precise delas, isso faz com que o agente realize compactações mais frequentemente. Geralmente, para além de 30 ferramentas, faz os agentes abrandar e também degrada o seu desempenho como eu disse. Como podemos escalar isso além de 30 ferramentas? Claro, queremos criar muitos playbooks e muitas ferramentas, e este é um sistema central.
O que fazemos é, em vez de expor todas essas ferramentas e playbooks diretamente ao MCP, substituí-los por três ferramentas. O primeiro é procurar as ferramentas e playbooks. O agente, sempre que ele precisa executar uma ação ou encontrar um playbook, ele pode usar esta ferramenta para primeiro fazer a pesquisa com base em palavras-chave e também tags como domínio e que ação a ferramenta faz. Esta ferramenta de pesquisa irá emergir resultados relevantes das ferramentas e playbooks, e então o agente pode decidir com base no nome e descrição, qual ferramenta usar, e então ele pode obter o esquema da ferramenta. Isto é para obter os argumentos de entrada, como construir os argumentos para essa ferramenta, e então ele pode executar. Desta forma, podemos dimensionar as ferramentas e catálogos de playbooks para milhares de ferramentas e playbooks. Quem mantém todas essas ferramentas e playbooks e servidor, porque todos continuam adicionando as ferramentas e todos continuam adicionando os playbooks?
Se todos continuarem a adicionar ferramentas, deve haver alguém que os mantenha. Seguimos este modelo de propriedade onde há uma equipe central que é responsável pela manutenção do próprio servidor MCP, e eles também mantêm um conjunto de ferramentas principais. Isso garante que se houver algum problema com o servidor MCP ou qualquer uma das ferramentas principais, a plataforma central que temos na chamada, eles irão ajudar e corrigir quaisquer problemas. Em seguida, temos um modelo de contribuição aberto onde, como eu disse, qualquer um pode ir e contribuir, é claro com a revisão InfoSec, mas qualquer que seja a equipe adiciona as ferramentas ou playbooks e disponibiliza para todos, eles também devem estar mantendo essas ferramentas e playbooks. Quaisquer playbooks ou ferramentas que não sejam usados ou não sejam mantidos, vamos deprecá-los ativamente e agressivamente. A questão é que queremos que cada ferramenta e tudo seja contabilizado para manter a saúde de todo o sistema.
Temos mais de 8K usuários que usam o servidor MCP e qualquer uma das ferramentas em uma base diária. Isto não são apenas engenheiros. Demos acesso a ferramentas de codificação ou agentes de codificação para outras funções, como gerentes de produtos, designers, TPMs. Eles usam todas ou algumas das ferramentas para seus fluxos de trabalho. Novamente, os agentes codificadores não são mais apenas para codificação. Você pode fazer muito mais coisas, por exemplo, depuração. Muitas pessoas usam as ferramentas de codificação, porque tem acesso a documentos e wiki, eles podem ir e criar documentos ou escrever os documentos usando as ferramentas do MCP. Nós também olhamos para o que esses playbooks são usados principalmente para. Temos mais de 600 playbooks, que estão automatizando os fluxos de trabalho. Percebemos que estes são os cinco grandes temas que as equipes estão criando para os playbooks e usá-los. A primeira é, interessantemente, depuração e investigação de questões.
Está relacionado com codificação, mas isso não é exatamente codificação. O que percebemos são todas as equipas, agora estão a converter os seus livros em livros de jogada. Os agentes, quando você lhes dá um bom conjunto de instruções sobre onde procurar os dados e ir e investigar, eles são realmente bons em ingerir todos esses dados e descobrir que agulha no palheiro. Esta é uma das áreas onde os humanos também odeiam fazer isso. Este é um aspecto muito interessante dos agentes codificadores. O segundo, claro, que era o propósito de todo este playbooks foi a codificação. Se você olhar para a codificação em grandes empresas como o LinkedIn, é um monte de código de placa de caldeira, porque temos um monte de frameworks internos e configurar as bases de dados. Ele ocupa um monte de código caldeira, que é muito manual. Dado o conjunto certo de instruções, os agentes podem fazer um trabalho muito bom de criar esse código de caldeiraplate para você e também executando os comandos e verificando se ele está configurado corretamente.
Você pode fazer uma tarefa de corrida mais longa quando você tem um monte de caldeira para configurar. Isso torna muito fácil para os engenheiros cortar todas as coisas chatas e manuais de configurar o código da placa de caldeira e focar em coisas realmente interessantes, que é, que produtos construir e que mudanças fazer e como iterar mais rápido. Em seguida, o terceiro top mais caso de uso também é limpeza de código e migrações. Se alguém está trabalhando em uma grande empresa, eles vão saber que esta é uma das dores, que é, há migrações constantes, e estes não são divertidos, mas você tem que pagar o imposto. Aqui é onde os agentes de codificação podem realmente ajudar onde você tem muita migração que você quer que as equipes dependentes para fazer. Você pode criar um playbook e você pode pedir aos agentes de codificação para ir e fazer as migrações e criar um PR.
Como os playbooks de migração são muito bons, podemos confiar nos agentes de codificação para fazer o trabalho certo. Todos os playbooks também precisam ter boas etapas de verificação onde o agente pode ir e verificar seu próprio trabalho. Então, como eu disse, há um monte de infra personalizado e requer um monte de gestão. Além disso, temos muitos oleodutos, por exemplo, oleodutos offline e treinamento de IA, e os playbooks realmente ajudam os agentes de codificação. Estas são as tarefas com que os agentes de codificação podem ajudar, onde em vez de um engenheiro ir e gerenciar esses pipelines e buscar os logs e tentar depura-los ou tentar gerenciar algumas das tarefas de longo prazo, você pode delegar isso em agentes de codificação e dar-lhes instruções através de playbooks, e eles podem fazer esse trabalho. O quinto é o ambiente e a configuração do repo. Como eu disse, qualquer novo engenheiro se junta, agora eles podem usar esses playbooks para configurar seu ambiente de desenvolvimento local e se tornar produtivo mais cedo em vez de descobrir todas as coisas no README e passar por esse processo.
E agora?
E agora? Temos um bom sistema que está a funcionar. Em que estamos a trabalhar a seguir? Até agora, como mencionei, os engenheiros foram responsáveis pela criação dos playbooks. Claro, temos playbooks para escrever playbooks, o que significa que os engenheiros não estão escrevendo manualmente os playbooks. Eles estão usando os agentes de codificação para descobrir o contexto certo e capturar isso como um playbook. Queremos automatizar isso, onde podemos ter um agente de codificação de fundo, que olha para todas as informações das RPs e também as sessões de agentes e a telemetria para entender quais são os fluxos de trabalho comuns que podem ser automatizados, e eles mesmos podem escrever os playbooks. Isso nos permite escalar todo o contexto organizacional em Linked Muito mais rápido. Outra coisa em que estamos trabalhando é também, temos um monte de playbooks. Agora, é claro, nós temos uma maneira de atualizá-los e mantê-los atualizados, mas ainda é um processo manual onde alguém tem que lembrar ou direcionar o agente para ir e atualizar os playbooks com as novas aprendizagens. Nós queremos automatizar que onde há um agente de codificação de fundo, novamente, como um trabalho offline, que olha para todas as sessões de agente e quaisquer novas aprendizagens da telemetria, e dá uma olhada nos playbooks eles mesmos, e ver se há alguma lacuna, e ele pode ir e fazer atualizações para esse playbook.
Tiras de Chaves
Deixo-vos com duas chaves. A primeira é que não é suficiente dar ferramentas de codificação de IA aos engenheiros da sua equipe e da sua empresa e esperar que sejam produtivos. A primeira é, você precisa pensar a partir do primeiro dia, como colocar guardas suficientes em torno da qualidade, como garantir que os agentes de codificação estão criando saída de qualidade. Isto é muito importante na sua empresa. O segundo, o efeito a jusante é que você precisa ter certeza de que o código que seus agentes de codificação estão gerando, não está degradando a confiabilidade de seus sistemas. Este é um problema muito comum onde, à medida que a velocidade do código sobe, irá causar alguns efeitos a jusante. Você precisa pensar desde o primeiro dia como manter a qualidade e a confiabilidade. O segundo é, os agentes de codificação e os arreios, modelos, tudo continua se atualizando.
Uma coisa que não muda é que os agentes de codificação ainda precisam de acesso ao seu contexto interno, ao seu conhecimento tribal, que não muda. Você precisa ter algum infra onde você torna mais fácil para os agentes de codificação acessar seu conhecimento tribal interno através de habilidades ou playbooks como nós fizemos. Você precisa ter algum tipo de infra para os agentes para navegar em sua empresa, só então eles serão bem sucedidos. O terceiro é a experiência do desenvolvedor. Para obter a adoção dos agentes de codificação, você precisa fazer a experiência de usar os agentes de codificação realmente sem problemas. Então a produtividade é realmente difícil. O problema é que essas ferramentas de codificação são realmente novas e as pessoas podem não gostar imediatamente do código que os agentes de codificação geram ou não querem usar isso. Você precisa colocar esforço constante como uma empresa para tornar essa experiência melhor para que eles gerem o código.
Perguntas e Respostas
Participante 1: Você tem o ponto de dados para muitos usuários usando o playbook nos últimos meses, agora 8.000 pessoas. Você pode fornecer algumas informações sobre a produtividade e qualidade ao longo do tempo?
Ajay Prakash: Eles não estão apenas usando os playbooks, mas muitas pessoas estão usando as ferramentas sozinhos. Existem usuários 8K que estão usando as ferramentas. Sobre a qualidade, como eu mencionei, colocamos os trilhos de guarda na qualidade desde o primeiro dia. Não diminuiu, o que é realmente uma coisa boa. Além disso, o que percebemos é que também mantemos a produtividade. A produtividade aumentou, cerca de 20% aumentaram a produtividade. Também medimos a produtividade contra a confiabilidade do nosso sistema. A fiabilidade não diminuiu nada.
Participante 2: Quando você está fazendo a pesquisa para as ferramentas, então você está fazendo a pesquisa, e depois retornando o esquema e, em seguida, executando, quais peças da chamada de ferramenta eram relevantes quando você estava fazendo a pesquisa? Foi como o nome e a descrição, ou incluiu partes do esquema ou partes de outra coisa?
Ajay Prakash: Como o agente descobre a ferramenta certa para usar com base no que apresentamos nos resultados? O primeiro é o nome e a descrição da própria ferramenta. Basta que o agente decida qual ferramenta usar. Além disso, temos algo chamado uma breve descrição. Temos uma descrição longa e uma descrição curta. O que percebemos é apenas a descrição curta em si é suficiente para que o agente de codificação descubra qual ferramenta usar.
Participante 3: Mencionou que os agentes seriam capazes de identificar livros de jogo ultrapassados. Como exatamente o agente é capaz de identificar que qualquer coisa ficou desatualizada e automaticamente notificar que o playbook precisa ser atualizado com base em qualquer infraestrutura ou quaisquer outras mudanças arquitetônicas? Como farias isso?
Ajay Prakash: Como os agentes detectam as informações desatualizadas nos playbooks e como improvisam? A forma como funciona é, então mesmo sem o manual, também os agentes podem tentar descobrir o que fazer. Com os playbooks, quando ele encontra qualquer informação desatualizada, suponha que o comando que você deu não está funcionando, ele tenta primeiro o comando e falha. Ele leva a saída e razões sobre isso, ok, então este é o comando dado no playbook, mas não está funcionando. Preciso de tentar outra coisa. Claro, com base no seu pré-treino, eles podem tentar coisas diferentes. Além disso, se eles não conseguem encontrá-lo, então eles sempre têm acesso às ferramentas. Por exemplo, deixe-me ir e pesquisar no Google Docs sobre as informações certas, ou eles podem usar a busca de código para ir e procurar as informações certas e eles podem improvisar.
A coisa sobre estes agentes codificadores ou modelos como Claude, eles não desistem tão facilmente. Eles continuam a tentar coisas novas até esgotarem todas as opções. Geralmente não, eles continuam. Nós também temos essas instruções no agente que se ele encontrar um beco sem saída e tiver usado um monte de tokens, eles sempre podem ir e pedir ao usuário para dirigi-los, fornecer algumas informações faltando. Em seguida, o usuário pode encontrar a informação e apontá-la na direção certa. Estes são os mecanismos para torná-los atualizados.
Participante 4: Eu queria saber qual é o processo para controlar quantos playbooks você pode ter em sua empresa, mas também como remover ou evitar a duplicação de playbooks que são criados. Qual é então o sistema para controlar isso?
Ajay Prakash: O principal mecanismo é, é claro, cada livro que criamos tem que passar por revisão de código. Geralmente, um humano vai rever antes de ser fundido. Se houver alguma duplicata, ela é marcada. Além disso, temos revisões automatizadas de código para o sistema, onde temos instruções. Por exemplo, sempre que alguém cria um PR, nós também pedimos ao agente de codificação que está fazendo as revisões para descobrir se é uma duplicata ou se não é necessário, então eles podem superfície que. Além disso, outra coisa é como a codificação, como eu mencionei, as pessoas não estão fazendo os playbooks manualmente, eles estão usando agentes de codificação para criar os playbooks. Também temos instruções sobre qual é a melhor prática de escrever um playbook e também dizer ao usuário, ou ao engenheiro que isso pode não ser necessário ou irrelevante. Eu acho que outro aspecto importante deste servidor MCP também é que nós somos capazes de usar métricas para medir o uso de todas as ferramentas e playbooks. Nós vamos e olhamos as métricas para cada um dos playbooks, e podemos deprecar as coisas que não são usadas.
Veja mais apresentações com transcrições