Mencionar um agente de código num grupo do Feishu significa que um membro do grupo escreve uma mensagem no Feishu (Lark fora da China), essa mensagem é entregue a um agente Claude Code ou Codex em execução na máquina de alguém, a execução e o seu resultado regressam à mesma thread, e qualquer ação perigosa transforma-se primeiro num cartão de aprovação para o proprietário da máquina. O agente não se desloca para a cloud, as credenciais nunca saem do computador e ninguém no grupo instala nada.
Este artigo descreve a arquitetura do conector Feishu do muti: vinculação, encaminhamento, aprovações e limitação de taxa, além do que pode configurar antes do lançamento. O conector está em desenvolvimento; o que se segue é a sua especificação comportamental, e não uma funcionalidade que possa ativar hoje. O original em chinês está em /zh-CN/blog/feishu-lark-claude-code.
Porquê uma aplicação de chat em vez de outro cliente
A pessoa com quem está a partilhar é quem menos quer criar uma conta e instalar um cliente para usar o seu agente uma única vez. Para equipas na China, a conversa de trabalho já decorre no Feishu. Levar o agente até lá é mais simples do que levar as pessoas até ao agente.
O Feishu também se adequa perfeitamente à tarefa: as subscrições de eventos por ligação persistente não necessitam de um URL de callback público, os cartões de mensagem atualizam-se no próprio local, as respostas na thread mantêm o tráfego de uma tarefa reunido e as imagens podem ser descarregadas como entrada para o agente.
Duas vinculações
Grupo ↔ sala. Uma sala é a fronteira no muti: quem pode ver o quê e quem pode usar qual agente. Vincular um grupo do Feishu a uma sala faz com que a lista de membros e as permissões da sala se apliquem a esse grupo. Nas definições da sala, selecione “connect a Feishu group”, obtenha um código de seis dígitos e publique @muti bind 123456 no grupo.
Pessoa ↔ conta. Da primeira vez que um membro menciona o bot, este envia-lhe um código de curta duração num chat privado; o membro introduz o código no muti e as identidades ficam associadas. Pessoas não vinculadas são ignoradas por predefinição; uma sala pode abrir um modo de convidado, onde estas podem fazer perguntas, mas não despoletar execuções.
O objetivo da vinculação: os direitos de execução provêm das permissões da sala e das aprovações do proprietário, nunca de quem disse o quê no grupo. As mensagens de chat são tratadas como entrada não confiável.
Uma tarefa, uma thread: aceitação, cartão de aprovação, progresso e resultado no mesmo local.
Uma tarefa, uma thread
Um membro publica @muti @api rerun the failing tests and open a PR. O bot abre uma thread sob essa mensagem e responde sequencialmente:
- Aceite, com um id de pedido como
R20260906-03e o respetivo estado. - Estado de aprovação. Se esta pessoa não tiver uma permissão permanente para este agente, o proprietário recebe um cartão de aprovação visível apenas para si.
- Um cartão de progresso, atualizado no próprio local a cada etapa ou a cada 30 segundos: ficheiros alterados, testes até ao momento, as últimas linhas do output do comando. Não uma nova mensagem por etapa.
- O resultado: a resposta, acompanhada de quaisquer ficheiros, imagens ou links gerados pelo agente.
O canal principal mantém-se silencioso; qualquer pessoa que queira detalhes abre a thread.
O cartão de aprovação
Quando uma execução se depara com uma ação perigosa, o proprietário recebe um cartão: quem pediu, qual agente, o que pretende fazer, qual regra atingiu. Três botões: approve / reject / run read-only, com uma nota opcional que tem o mesmo peso que o pedido.
Quatro tipos de ação são colocados em pausa independentemente do modelo: enviar push para um branch partilhado, eliminar, gastar dinheiro, aceder a credenciais. Entradas protegidas, tais como inícios de sessão e códigos de autenticação de dois fatores, são sempre reencaminhadas para o proprietário, nunca para o autor do pedido. As aprovações expiram após 24 horas por predefinição. Tomar uma decisão no Feishu, na web ou num telemóvel aplica-se a todo o lado.
O que o grupo vê e o que nunca sai da máquina
O que configurar agora
- Coloque o agente numa sala. Ligue a sua máquina, crie um agente por diretório que pretenda partilhar e dê-lhe o nome da função (
api,site,notes), e não do modelo. - Construa a sala antes do grupo. Convide as pessoas que mais tarde farão parte do grupo vinculado e defina quem tem acesso só de leitura e quem pode editar. O conector vincula o grupo ↔ esta sala e reutiliza essas regras.
- Instale o daemon como um serviço com
muti service install, para que as tarefas do Feishu fiquem em espera pela máquina em vez de falharem quando fechar a tampa do portátil. - Registe o estilo da casa. Um STYLE.md, o modelo de apresentações, o SQL do relatório da semana passada: tudo o que o agente deve ler fica no seu diretório de trabalho.
Perguntas frequentes
O administrador do nosso Feishu precisará de aprovar algo? A cloud do muti executa uma única aplicação Feishu para todos os utilizadores; a instalação num tenant normalmente requer o consentimento único de um administrador. O modo auto-hospedado permite que o proprietário utilize as suas próprias credenciais de aplicação.
O Lark (internacional) é suportado? O Feishu e o Lark partilham a mesma plataforma aberta; o conector suporta ambos.
E quanto ao Slack e ao DingTalk? O conector do Slack já foi lançado: um bot por agente, envie-lhe uma DM ou mencione-o, com aprovações na DM do proprietário. O Feishu/Lark é o próximo; segue-se o DingTalk (modo Stream). Os três partilham as mesmas salas e permissões. Consulte um bot Slack para o Claude Code que pede autorização antes de fazer push.
E se alguém no grupo não for utilizador do muti? São ignorados por predefinição. Uma sala pode ativar o modo de convidado: os convidados podem fazer perguntas, mas nunca despoletar execuções.
Dê primeiro uma sala ao seu agente; o grupo liga-se a ela. Comece aqui.
Publicado a · Atualizado a