Mencionar a un agente de programación en un grupo de Feishu significa que un miembro del grupo escribe un mensaje en Feishu (Lark fuera de China), ese mensaje se entrega a un agente de Claude Code o Codex que se ejecuta en la máquina de alguien, la ejecución y su resultado vuelven al mismo hilo y cualquier acción peligrosa se convierte primero en una tarjeta de aprobación para el propietario de la máquina. El agente no se traslada a la nube, las credenciales nunca salen del ordenador y nadie en el grupo instala nada.
Este artículo describe el diseño del conector de Feishu para muti: vinculación, enrutamiento, aprobaciones y control de frecuencia, además de lo que puedes configurar antes de su lanzamiento. El conector está en desarrollo; lo que sigue es su especificación de comportamiento, no una función que puedas activar hoy. El original en chino está en /zh-CN/blog/feishu-lark-claude-code.
Por qué una app de chat en lugar de otro cliente
La persona con la que estás compartiendo es la que menos ganas tiene de crearse una cuenta e instalar un cliente para usar tu agente una sola vez. Para los equipos en China, la conversación de trabajo ya ocurre en Feishu. Llevar el agente allí es más fácil que llevar a la gente hacia el agente.
Feishu también encaja a la perfección: las suscripciones a eventos mediante conexión persistente no necesitan una URL pública de callback, las tarjetas de mensaje se actualizan in situ, las respuestas en hilos mantienen agrupada la actividad de cada tarea y las imágenes se pueden descargar como entrada para el agente.
Dos vinculaciones
Grupo ↔ sala. Una sala es el límite en muti: quién puede ver qué y quién puede usar qué agente. Vincular un grupo de Feishu a una sala hace que los miembros y permisos de la sala se apliquen a ese grupo. En la configuración de la sala, elige «conectar un grupo de Feishu», obtén un código de seis dígitos y publica @muti bind 123456 en el grupo.
Persona ↔ cuenta. La primera vez que un miembro menciona al bot, este le envía un código de corta duración por chat privado; lo introduce en muti y las identidades quedan vinculadas. A las personas no vinculadas se las ignora de forma predeterminada; una sala puede habilitar un modo de invitado donde pueden preguntar pero no iniciar ejecuciones.
El objetivo de la vinculación: los derechos de ejecución proceden de los permisos de la sala y de las aprobaciones del propietario, nunca de quién dijo qué en el grupo. Los mensajes de chat se tratan como entradas no fiables.
Una tarea, un hilo: aceptación, tarjeta de aprobación, progreso y resultado en el mismo lugar.
Una tarea, un hilo
Un miembro publica @muti @api rerun the failing tests and open a PR. El bot abre un hilo bajo ese mensaje y responde en orden:
- Aceptada, con un id de solicitud como
R20260906-03y su estado. - Estado de aprobación. Si esta persona no tiene un permiso permanente para este agente, el propietario recibe una tarjeta de aprobación visible solo para él.
- Una tarjeta de progreso, actualizada in situ por etapa o cada 30 segundos: archivos modificados, tests ejecutados hasta el momento, las últimas líneas de salida del comando. No un mensaje nuevo por cada paso.
- El resultado: la respuesta más los archivos, imágenes o enlaces que el agente haya generado.
El canal principal permanece despejado; quien quiera ver los detalles abre el hilo.
La tarjeta de aprobación
Cuando una ejecución topa con una acción peligrosa, el propietario recibe una tarjeta: quién lo pidió, qué agente, qué quiere hacer y qué regla activó. Tres botones: approve / reject / run read-only, con una nota opcional que tiene el mismo peso que la solicitud.
Cuatro tipos de acción se pausan independientemente de la plantilla: hacer push a una rama compartida, borrar, gastar dinero o tocar credenciales. Las entradas protegidas, como inicios de sesión y códigos de autenticación en dos pasos, siempre se dirigen al propietario, nunca al solicitante. Las aprobaciones caducan tras 24 horas de forma predeterminada. Decidir en Feishu, en la web o en un teléfono se aplica en todas partes.
Qué ve el grupo y qué nunca sale de la máquina
Qué configurar ahora
- Pon el agente en una sala. Conecta tu máquina, crea un agente por cada directorio que pienses compartir y nómbralo según su función (
api,site,notes), no según el modelo. - Configura la sala antes que el grupo. Invita a las personas que más adelante estarán en el grupo vinculado y define quién tiene acceso de solo lectura y quién puede editar. El conector vincula grupo ↔ esta sala y reutiliza esas reglas.
- Instala el daemon como servicio con
muti service install, para que las tareas de Feishu esperen a la máquina en lugar de fallar cuando la tapa del portátil esté cerrada. - Pon el estilo de trabajo por escrito. Un STYLE.md, la plantilla de diapositivas, el SQL del informe de la semana pasada: cualquier cosa que el agente deba consultar debe estar en su directorio de trabajo.
Preguntas frecuentes
¿Tendrá que aprobar algo nuestro administrador de Feishu? La nube de muti ejecuta una sola app de Feishu para todos los usuarios; instalarla en un tenant normalmente requiere una única autorización de un administrador. El modo autohospedado permite que el propietario use sus propias credenciales de aplicación.
¿Es compatible Lark (internacional)? Feishu y Lark comparten la misma plataforma abierta; el conector cubre ambos.
¿Qué pasa con Slack y DingTalk? El conector de Slack ya está disponible: un bot por agente, mensaje directo o mención, aprobaciones en el mensaje directo del propietario. Feishu/Lark es el siguiente; después vendrá DingTalk (Stream mode). Los tres comparten las mismas salas y permisos. Consulta un bot de Slack para Claude Code que pregunta antes de hacer push.
¿Qué ocurre si alguien del grupo no es usuario de muti? Se le ignora de forma predeterminada. Una sala puede abrir el modo de invitado: los invitados pueden preguntar, pero nunca iniciar tareas.
Dale primero una sala a tu agente; el grupo se conectará a ella. Empieza aquí.
Publicado el · Actualizado el