Um bot do Slack para um agente de programação transforma uma mensagem no Slack num pedido para o Claude Code ou Codex a correr na máquina de alguém e publica o resultado de volta na thread. O muti dá a cada agente o seu próprio bot com o seu próprio nome. As pessoas no seu workspace enviam-lhe uma DM ou mencionam-no num canal; essa mensagem é a tarefa. Se a pessoa que faz o pedido não for o proprietário do agente, o pedido fica em espera e o proprietário aprova-o com botões na sua própria DM. Pushes, eliminações destrutivas, gastos e acesso a credenciais nunca se tornam automáticos, para ninguém.
Este artigo explica como funciona o conetor, o que o “Allow always” realmente guarda e por que razão tratar o Slack como entrada não fidedigna é o ponto essencial.
O que a maioria das pontes faz mal
A ponte típica guarda um token de bot, escuta menções e encaminha o texto para uma CLI local. Funciona, mas tem três problemas: a pertença ao canal torna-se o modelo de permissões, ninguém aprova o passo arriscado e o progresso inunda o canal com uma mensagem por cada chamada de ferramenta. Nenhum destes é um problema do Slack. São problemas de permissões que por acaso vêm à tona no Slack.
Uma thread de canal mostra o pedido e o seu estado; os botões de aprovação ficam na DM do proprietário; o agente corre na máquina do proprietário.
Um bot por agente
Cria a aplicação do Slack a partir de um manifesto que o muti gera para esse agente, pelo que o bot herda o nome do agente e os seus próprios URLs de eventos. Não há nada para associar nem comandos para aprender:
- Envie uma DM ao bot e o texto torna-se uma tarefa. A DM transforma-se numa sala partilhada por si e pelo proprietário do agente.
- Mencione-o num canal e esse canal torna-se numa sala de grupo no muti na primeira utilização. O bot responde na thread.
- Anexe ficheiros e estes chegam como anexos da sala que o agente pode ler, tal como carregamentos na web.
Os utilizadores do Slack tornam-se utilizadores do muti através do email registado no Slack, verificado pelo próprio Slack dentro do workspace do proprietário. Se o Slack ocultar o email, o bot envia um código de ligação de seis dígitos para resgatar na web uma única vez. De qualquer forma, as permissões associam-se à conta e não a um nome de exibição.
O mesmo controlo da web
Cada pedido passa pelo mesmo controlo que a web utiliza. As mensagens do próprio proprietário são executadas de imediato. Qualquer outra pessoa espera pelo proprietário, a menos que este já tenha concedido permissão permanente a essa pessoa para este agente. O estado aparece na thread: aceite com um id de pedido, em espera, em execução com resumos das chamadas de ferramentas, concluído com o resultado. Um único cartão, atualizado no próprio local, em vez de uma mensagem por cada passo.
Botões de aprovação e o que significa o “always”
Quando chega um pedido de outra pessoa, ou quando uma execução atinge uma chamada de ferramenta que precisa de intervenção humana, o proprietário recebe um cartão na sua DM com três botões: Allow, Allow always, Deny.
Allow serve para essa chamada pontual. Allow always guarda uma regra para o agente tão estrita quanto essa chamada: este domínio para WebFetch, este prefixo de comando para Bash, esta skill por nome, esta ferramenta só de leitura. Futuras chamadas correspondentes são respondidas pelo muti sem qualquer prompt. As regras estão listadas e podem ser revogadas na caixa de diálogo do agente.
Chamadas em categorias perigosas nunca são elegíveis para uma regra e nunca correspondem a nenhuma: push para ramos partilhados, eliminações destrutivas, escalada de privilégios, publicações e deploys, e leitura ou escrita em caminhos de credenciais. Ficam limitadas a uma chamada de cada vez, apenas com Allow e Deny. Esta é a versão do conetor das quatro ações que devem sempre perguntar. Aprovações sem resposta expiram ao fim de 24 horas, tal como os pedidos.
O que o canal vê
Texto do pedido, estado e id; resumos das chamadas de ferramentas; caminhos de diff e contagem de linhas; o final da saída dos comandos; ficheiros produzidos e links. Nunca: variáveis de ambiente, ficheiros de chaves, a working tree ou qualquer coisa de outra sala. Os tokens do Slack são guardados cifrados no muti; nada relacionado com o Slack reside na máquina do proprietário, que mantém a sua ligação de daemon exclusivamente de saída. Veja o que o daemon envia.
Configuração
- Na consola, abra o Slack para o agente que quer disponibilizar e crie uma aplicação do Slack a partir do manifesto gerado. Se quiser, carregue o avatar do agente como ícone da aplicação; o assistente apresenta-o.
- Cole as duas strings das definições da aplicação. O muti faz uma chamada ao Slack, encontra-o por email e associa-o como proprietário para que os botões de aprovação funcionem de imediato.
- Instale a aplicação no seu workspace. Envie uma DM ao bot ou convide-o para um canal e mencione-o.
- Aprove o primeiro pedido de um colega de equipa na sua DM. Use Allow always apenas para chamadas pontuais e rotineiras; deixe que as perigosas perguntem sempre.
Perguntas frequentes
O bot precisa do meu administrador do Slack? A instalação de uma aplicação num workspace normalmente requer a aprovação de um administrador. A aplicação é sua, criada a partir do manifesto do muti, pelo que nenhuma aplicação de terceiros fica com o token do seu workspace.
Os membros do canal podem aprovar por si próprios? Não. A aprovação pertence ao proprietário do agente e chega na DM do proprietário. Os membros podem cancelar ou acrescentar contexto.
E quanto ao Feishu, Lark e DingTalk? O Feishu/Lark é o próximo e segue o mesmo modelo de salas e aprovações; consulte o design do Feishu. O DingTalk virá a seguir.
Isto é o mesmo que o Claude Code Dispatch? O Dispatch reencaminha as suas mensagens do Telegram para a sua própria sessão. Este conetor destina-se a outras pessoas, com aprovações; consulte Dispatch vs. uma sala.
A sala trata da gestão de permissões; o Slack é apenas mais uma porta de entrada. Dê uma sala ao seu agente.
Publicado a · Atualizado a