Del bot de QQ al banco de trabajo de Discourse: una retrospectiva honesta sobre los límites de las herramientas

General
1

TL;DR

  • El objetivo central de este periodo no es “hacer un bot de QQ”, sino mejorar la eficiencia de colaboración multitarea y la calidad de sedimentación del contexto.
  • El plugin de QQ ya completó un conjunto completo de capacidades operables: fiabilidad, control de riesgos, ranuras de conversación, multimodalidad, comandos de administración, etc.; no es un simple reenviador.
  • El valor del plugin de Discourse reside en convertir el “chat” en un “contenedor de tareas”, más adecuado para seguimiento, retrospectiva y sedimentación de conocimiento.
  • Evalué seriamente la sincronización bidireccional QQ↔Discourse: es técnicamente viable, pero en la etapa actual el ROI no es alto; la complejidad y el coste de mantenimiento son elevados.
  • Por tanto, la estrategia actual queda clara: Discourse primero (banco de trabajo principal), QQ como entrada (acceso de baja barrera).
  • El verdadero resultado de este trabajo no es solo funcionalidad, sino metodología: separación entre enrutamiento y presentación, convergencia de responsabilidades por plataforma, y decisiones de ingeniería con prioridad al valor.

De bot de QQ a banco de trabajo en Discourse: una retrospectiva real sobre los “límites de las herramientas”

Este artículo es un resumen por etapas de lo que he estado haciendo recientemente en el ecosistema OpenClaw: desarrollar el plugin de QQ, el plugin de Discourse, pensar en la sincronización entre extremos y, finalmente, converger activamente la solución. No es un texto promocional, sino un registro de decisiones de ingeniería y producto.

1. Punto de partida: al principio no estaba haciendo “un bot de QQ”

El problema que realmente quería resolver nunca fue “en qué plataforma chatear”, sino:

  • cómo procesar en paralelo múltiples tareas de forma más eficiente;
  • cómo sedimentar el contexto para que después sea buscable, revisable y colaborable;
  • cómo permitir que amigos en China, sin necesidad de VPN, puedan enviar requisitos de forma conveniente.

Estos tres objetivos generan una tensión natural dentro de un mismo sistema:

  • La ventaja de QQ es el alcance y la inmediatez;
  • La ventaja de Discourse es la estructuración, multihilo, sedimentación y gestión;
  • La ventaja de OpenClaw es unificar múltiples canales dentro de un mismo sistema de Agent y conversaciones.

Así que, en esencia, este periodo ha sido hacer una cosa: separar la “comodidad de entrada” de la “eficiencia de gestión de tareas”, y luego equilibrarlas en lo posible con medios de ingeniería, en lugar de forzar una unificación en una sola entrada.

2. ¿Qué logró realmente el plugin de QQ (no es solo “poder chatear”)?

Mucha gente subestima el plugin de QQ y cree que solo reenvía mensajes al modelo y luego devuelve texto. En realidad, mi versión del plugin de QQ ya es una capa de capacidades de canal bastante completa. Las funciones clave incluyen:

2.1 Fiabilidad del canal (una base lista para producción)

  • Conexión y reconexión OneBot v11 WebSocket (retroceso exponencial);
  • Detección de latido/inactividad para identificar “conexiones zombis”;
  • Si el envío falla, reencolar automáticamente y reenviar cuando se recupere la conexión;
  • Evitar que health-monitor diagnostique erróneamente la salida del canal y cause bucles de reinicio (el canal permanece residente hasta abort).

Esta parte decide si “el bot está realmente en línea”, y es más importante que el propio modelo.

2.2 Seguridad y control de riesgos (imprescindible para aterrizar en QQ)

  • requireMention activado por defecto para evitar que cada frase del grupo dispare el bot;
  • Lista blanca de grupos, lista negra de usuarios;
  • adminOnlyChat (solo administradores disparan) + anti-rebote de avisos a no administradores;
  • Envío fragmentado + intervalo entre envíos (reducir riesgo de control);
  • antiRiskMode para evitar/mitigar ciertos contenidos (p. ej., URL).

El control de riesgos del ecosistema QQ es mucho más agresivo que Telegram; si no haces esta capa, pronto verás “en los logs respondió, pero en el grupo no se recibió”.

2.3 Ingeniería de sesiones (el activo central de este trabajo)

  • Generación de clave de sesión bajo el enrutamiento estándar (delegado al OpenClaw core routing);
  • Ranuras de sesión temporal en grupos (/临时, /临时重命名, /临时列表, /临时结束, etc.);
  • /newsession para reiniciar con precisión la ranura de sesión actual;
  • Nombre de visualización de sesión (displayName) unificado al nuevo formato:
    • qq:<peer>-<YYYYMMDDHHmm>-<title>

Esto significa: puedo ejecutar en paralelo múltiples subtareas en un mismo grupo, en lugar de mezclar todo el contexto en un solo bloque.

2.4 Multimodalidad y extracción de información

  • Parseo de at, cadena de respuestas, imágenes, voz, archivos, mensajes reenviados;
  • Manejo de referencias de imagen URL/base64/file e inyección de prompts;
  • Completar el contexto de adjuntos a partir del mensaje respondido;
  • En el lado de envío, soporte de texto, imagen, voz, archivo con ruta fallback;
  • Soporte de mensajes de QQ 频道 (Guild).

2.5 Operabilidad

  • Comandos de administración: /status, /help, /mute, /kick;
  • Comandos de capacidad: /models, /model, /newsession, /grok_draw;
  • Visualización de estado ocupado: modificar temporalmente el sufijo de la tarjeta de grupo durante el procesamiento (p. ej., “输入中”);
  • Aviso de respaldo ante respuesta vacía para reducir falsas alarmas de “parece caído”.

En resumen: el plugin de QQ ya no es un demo, sino una ingeniería de capa de canal que puede operar de forma sostenible.

3. Qué hizo bien el plugin de Discourse: convertir “conversación” en “tarea”

El valor de la línea Discourse es muy claro:

  • entrada impulsada por webhook: naturalmente asíncrona y rastreable;
  • un topic como contenedor de tareas: estructuralmente es un modelo amigable para gestión multitarea;
  • cada respuesta, cada edición, cada repregunta tiene historial contextual revisable;
  • puede ser colaborado por varias personas y sedimentar conocimiento, en vez de que el flujo del chat lo arrastre y desaparezca.

En esta iteración completé varios puntos clave:

  • Parseo y caché del título del tema (si hace falta, recuperar /t/{topicId}.json para rellenar);
  • Regla unificada de nombre de visualización de sesión:
    • discourse:<site>-<YYYYMMDDHHmm>-<title>
  • Escribir tanto ConversationLabel como ThreadLabel, mejorando la legibilidad del panel de sesiones;
  • Script de renombrado masivo para sesiones antiguas, completando la coherencia histórica de datos.

Esto parece “optimización de nombres”, pero en realidad es empujar la gestión de sesiones de “usable por la máquina” a “legible y gestionable por personas”.

4. Por qué consideré seriamente la sincronización QQ↔Discourse y decidí no hacerla por ahora

En medio evalué seriamente una solución:

  • QQ como entrada, y al coincidir reglas, reenviar automáticamente a Discourse;
  • Discourse procesa y luego empuja de vuelta a QQ;
  • ambos extremos ven la conversación, como un “bridge”.

La idea es completamente realizable técnicamente, y ni siquiera es difícil. Pero finalmente decidí no invertir por ahora, y la razón no es “técnica”, sino “densidad de valor”.

4.1 Que se pueda hacer no significa que se deba hacer

Para que la sincronización bidireccional sea realmente estable, como mínimo hay que resolver adicionalmente:

  • bucles (A empuja a B y B vuelve a empujar a A);
  • deduplicación (replay de webhook / jitter de red que provoca entregas duplicadas);
  • consistencia de orden (timestamps y reintentos entre sistemas);
  • gobernanza de mapeo (cómo mantener a largo plazo el mapeo entre sesión QQ y topic);
  • pérdida semántica de multimedia entre extremos (archivos/voz de QQ degradados al expresarse en foro).

Cada punto no es algo que se elimine por completo con “unas líneas de glue code”.

4.2 En esta etapa, lo más escaso es la “eficiencia de tareas”, no la “consistencia omnicanal”

Mi dolor real es la eficiencia de avance multitarea, no unificar plataformas de chat.

  • Discourse ya puede soportar el flujo principal;
  • QQ solo necesita ser una entrada ligera (los amigos no necesitan VPN y pueden lanzar requisitos);
  • hacer una sincronización compleja “para que se vea más completo” tiene un ROI muy bajo a corto plazo.

4.3 Renunciar activamente no es fracasar

Cada vez estoy más de acuerdo con un principio:

La madurez de la capacidad de ingeniería no es “poder hacer más”, sino “saber qué cosa no hacer ahora”.

Así que conservo esa sincronización como una “idea interesante”, pero no sigo consumiendo energía en esta etapa.

5. Los activos de ingeniería que realmente se sedimentaron en este periodo

Aunque después se debilite el mantenimiento de QQ, este trabajo no se desperdició. Al menos dejó cinco tipos de activos de alto valor:

5.1 Experiencia de estabilidad del lado del canal

  • gestión del ciclo de vida de conexión;
  • confirmación de paquetes y fallback ante fallos;
  • latidos y juicio de vivacidad;
  • ideas de observabilidad para sistemas de conexión larga.

5.2 Metodología del sistema de sesiones

  • separación entre “routing key” y “nombre de visualización”;
  • impacto directo de la legibilidad del nombre de visualización en la eficiencia operativa;
  • tras unificar reglas de nombres, el coste de diagnóstico baja notablemente.

5.3 Comprensión de diferencias entre plataformas

  • QQ no es apto para soportar Markdown complejo y colaboración de cadena larga;
  • Forum (Discourse) es naturalmente apto para tareas y sedimentación de conocimiento;
  • que sea el mismo Agent no significa que todos los canales deban asumir responsabilidades equivalentes.

5.4 Conciencia de gobernanza de configuración

  • anti-abuso, listas blancas, fronteras de administradores deben adelantarse;
  • la granularidad de switches debe ser fina (función, permisos, estrategia de notificaciones por capas);
  • compatibilizar diferencias semánticas de entrada de configuración entre WebUI y CLI.

5.5 Capacidad de decisión de producto

  • pasar de “técnicamente viable” a “valor primero”;
  • pasar de “sumar funciones” a “convergencia de responsabilidades”;
  • con tiempo limitado, recortar activamente ramas de bajo ROI.

6. Posicionamiento final: QQ como entrada, Discourse como banco de trabajo

Hasta ahora, mi posicionamiento para estos dos canales es:

  • QQ:

    • entrada de baja barrera;
    • amigos plantean requisitos al vuelo;
    • notificación rápida, interacción simple;
    • entrada de materiales instantáneos como archivos/voz.

  • Discourse:

    • soporte de multitarea;
    • interacción principal y seguimiento del flujo;
    • sedimentación de resultados, organización del conocimiento;
    • base principal para retrospectiva y colaboración.

No es “cuál es más avanzado”, sino devolver cada plataforma a donde mejor se desempeña.

7. Tres recordatorios para mi yo futuro

  1. No confundas “capacidad del canal” con “valor del producto” en sí.
  2. Cuando empieces a apilar complejidad para escenarios marginales, pregúntate primero: ¿esto es una forma de evitar el verdadero problema principal?
  3. Cualquier plugin puede dejar de mantenerse, pero la metodología y el sentido de límites permanecerán; esa es la parte más valiosa.

8. Cierre

Este tiempo hice mucho trabajo que “parece desarrollo de herramientas”, pero al final lo que gané no fue un bot más llamativo, sino un juicio más claro:

  • en qué vale la pena seguir invirtiendo;
  • qué conviene dejar en pausa por ahora;
  • cuál es realmente la vía principal del sistema.

Si lo resumo en una frase:

En lugar de perseguir “que todas las plataformas estén completas”, es mejor primero profundizar y estabilizar el “flujo de tareas realmente importante”.

Y para mí, esta vía principal por ahora es: Discourse primero, QQ como entrada.