Do bot do QQ ao Discourse Workbench: uma retrospectiva sincera sobre os limites das ferramentas

Geral
1

TL;DR

  • O objetivo central deste período não é “fazer um bot de QQ”, e sim aumentar a eficiência de colaboração multi-tarefa e a qualidade da sedimentação de contexto.
  • O plugin de QQ já completou um conjunto inteiro de capacidades executáveis — confiabilidade, controle de risco, slots de sessão, multimodal, comandos de administração etc. — não é um simples encaminhador.
  • O valor do plugin do Discourse está em transformar “chat” em “contêiner de tarefas”, sendo mais adequado para rastreamento, revisão e sedimentação de conhecimento.
  • Eu avaliei seriamente a sincronização bidirecional QQ↔Discourse; é tecnicamente viável, mas na fase atual o ROI não é alto, e a complexidade e o custo de manutenção são grandes.
  • Portanto, a estratégia atual fica explicitamente: Discourse primeiro (bancada principal de trabalho), QQ como entrada (acesso de baixo atrito).
  • O verdadeiro resultado deste trabalho não é apenas funcionalidade, mas metodologia: separação entre roteamento e apresentação, convergência de responsabilidades da plataforma e escolhas de engenharia orientadas por valor.

De bot de QQ a bancada de trabalho no Discourse: uma retrospectiva real sobre “fronteiras de ferramentas”

Este artigo é um resumo por etapas do que venho fazendo recentemente no ecossistema OpenClaw: construir um plugin de QQ, construir um plugin de Discourse, pensar em sincronização multi-plataforma e, por fim, convergir ativamente para uma solução mais enxuta. Não é um texto promocional, e sim um registro de decisões de engenharia e produto.

1. Ponto de partida: no começo eu não estava fazendo “um bot de QQ”

O problema que eu realmente queria resolver nunca foi “em qual plataforma conversar”, e sim:

  • como lidar com múltiplas tarefas em paralelo com mais eficiência;
  • como sedimentar contexto para que depois seja pesquisável, revisável e colaborável;
  • como permitir que amigos na China continental, sem precisar de VPN, também consigam jogar demandas para dentro com facilidade.

Esses três objetivos têm uma tensão natural enorme dentro do mesmo sistema:

  • QQ é forte em alcance e imediatismo;
  • Discourse é forte em estruturação, multi-thread, sedimentação e gestão;
  • OpenClaw é forte em unificar múltiplos canais em um único sistema de Agent e sessões.

Então, na essência, o que eu estive fazendo neste período foi uma coisa: separar “conveniência de entrada” de “eficiência de gestão de tarefas” e então, por meios de engenharia, equilibrar o máximo possível — em vez de forçar a unificação num único ponto de entrada.

2. O que exatamente o plugin de QQ entregou (não é só “consegue conversar”)

Muita gente subestima o plugin de QQ, achando que é só passar a mensagem para o modelo e devolver o texto. Na prática, esta minha versão do plugin de QQ já é uma camada de capacidade de canal relativamente completa; os pontos-chave incluem:

2.1 Confiabilidade do canal (um chassi pronto para produção)

  • Conexão OneBot v11 WebSocket e mecanismo de reconexão (recuo exponencial);
  • detecção de heartbeat/occiosidade para identificar “conexões zumbis”;
  • falha no envio volta automaticamente para a fila, e reenvia após a conexão se recuperar;
  • evita que o health-monitor interprete erroneamente a saída do canal e cause loop de reinício (canal permanece até abort).

Essa parte, na verdade, determina se “o bot está realmente online”; é mais importante do que o próprio modelo.

2.2 Segurança e controle de risco (para realmente rodar no QQ, é obrigatório)

  • requireMention ligado por padrão, evitando que cada frase no grupo dispare;
  • whitelist de grupos, blacklist de usuários;
  • adminOnlyChat (somente admin dispara) + debounce de aviso para não-admin;
  • envio em fragmentos + intervalo de envio (reduz risco de controle);
  • antiRiskMode evita parcialmente certos conteúdos (como URL).

O controle de risco no ecossistema QQ é muito mais agressivo do que no Telegram; sem essa camada, você logo cai no “o log mostra que respondeu, mas o grupo não recebeu”.

2.3 Engenharia de sessão (este é o ativo central do trabalho)

  • geração de chave de sessão sob roteamento padrão (delegado ao core routing do OpenClaw);
  • slots de sessão temporária em grupo (/临时, /临时重命名, /临时列表, /临时结束 etc.);
  • /newsession para reset preciso do slot de sessão atual;
  • displayName da sessão unificado para novo formato:
    • qq:<peer>-<YYYYMMDDHHmm>-<title>

Isso significa: eu consigo tocar vários sub-tarefas em paralelo no mesmo grupo, sem misturar todo o contexto numa massa só.

2.4 Multimodal e extração de informação

  • parsing de at, cadeia de reply, imagens, áudio, arquivos, mensagens encaminhadas;
  • processa referência de imagem por URL/base64/file e injeta prompts;
  • completa contexto de anexos a partir da mensagem respondida;
  • no envio, suporta texto, imagem, áudio, arquivo e caminhos de fallback;
  • suporte a mensagens de QQ频道 (Guild).

2.5 Operacionalidade

  • comandos de administração: /status, /help, /mute, /kick;
  • comandos de capacidade: /models, /model, /newsession, /grok_draw;
  • visualização de estado ocupado: durante processamento, altera temporariamente o sufixo do cartão no grupo (como “输入中”);
  • fallback quando resposta vem vazia, reduzindo falsos “parece que caiu”.

Em uma frase: o plugin de QQ já não é um demo; é uma engenharia de camada de canal que roda de forma sustentável.

3. O que o plugin do Discourse acertou: transformar “diálogo” em “tarefa”

O valor desta linha do Discourse é muito claro:

  • entrada via webhook: assíncrona por natureza, rastreável por natureza;
  • topic como contêiner de tarefa: estruturalmente é um modelo amigável para gestão de múltiplas tarefas;
  • cada resposta, cada edição, cada follow-up tem histórico de contexto revisável;
  • permite colaboração multi-pessoa e sedimentação de conhecimento, em vez de um fluxo de chat que some.

Nesta iteração, eu completei alguns pontos-chave:

  • parsing e cache de título do tópico (quando necessário, puxa /t/{topicId}.json para preencher);
  • regra unificada de nome de exibição de sessão:
    • discourse:<site>-<YYYYMMDDHHmm>-<title>
  • escreve ConversationLabel e ThreadLabel simultaneamente, melhorando legibilidade no painel de sessões;
  • script de renomeação em lote para sessões antigas, finalizando consistência histórica de dados.

Isso parece “otimização de nomenclatura”, mas na prática é empurrar a gestão de sessão de “usável pela máquina” para “legível e gerenciável por humanos”.

4. Por que eu considerei seriamente sincronização QQ↔Discourse e decidi não fazer por enquanto

No meio do caminho, eu avaliei seriamente uma solução:

  • QQ como entrada; ao bater regras, encaminha automaticamente para Discourse;
  • Discourse processa e depois empurra de volta para QQ;
  • ambos os lados enxergam o diálogo, como um “bridge”.

A ideia é totalmente viável tecnicamente, e nem seria tão difícil. Mas eu decidi não investir por enquanto; o motivo não é “técnico”, e sim “densidade de valor”.

4.1 Dar para fazer não significa que valha a pena fazer

Para uma sincronização bidirecional realmente estável, no mínimo ainda precisaria resolver:

  • loop (A empurra para B, B empurra de volta para A);
  • deduplicação (replay de webhook / jitter de rede gerando entregas duplicadas);
  • consistência de ordem (timestamps e retries entre sistemas);
  • governança de mapeamento (como manter o mapeamento de longo prazo entre sessão QQ e topic);
  • perda semântica de mídia entre pontas (arquivo/áudio do QQ degradando na expressão no fórum).

Nenhum desses pontos é algo que “umas poucas linhas de glue code” eliminem de vez.

4.2 Nesta fase, o que é mais escasso é “eficiência de tarefa”, não “consistência omnicanal”

Minha dor real é eficiência para avançar múltiplas tarefas, não unificação de plataforma de chat.

  • Discourse já consegue carregar o fluxo principal;
  • QQ só precisa ser uma entrada leve (amigos sem VPN conseguem jogar demandas);
  • fazer sincronização complexa só para “parecer mais completo” tem ROI baixo no curto prazo.

4.3 Abrir mão ativamente não é fracasso

Eu concordo cada vez mais com um princípio:

Maturidade de engenharia não é “conseguir fazer mais coisas”, e sim “saber o que não fazer agora”.

Então eu deixo essa sincronização como “uma ideia interessante”, mas não continuo consumindo energia nesta fase.

5. Os ativos de engenharia que realmente se sedimentaram neste período

Mesmo que no futuro eu enfraqueça a manutenção do QQ, este trabalho não foi desperdiçado. Ele deixou pelo menos cinco tipos de ativos de alto valor:

5.1 Experiência de estabilidade no lado do canal

  • gestão do ciclo de vida da conexão;
  • confirmação de envio e fallback em falha;
  • heartbeat e julgamento de vivacidade;
  • ideias de observabilidade para sistemas de conexão longa.

5.2 Metodologia do sistema de sessões

  • separar “routing key” e “nome de exibição”;
  • impacto direto da legibilidade do nome de exibição na eficiência operacional;
  • após unificar regras de nome, o custo de troubleshooting cai significativamente.

5.3 Entendimento de diferenças entre plataformas

  • QQ não é adequado para carregar Markdown complexo e colaboração de cadeia longa;
  • Forum (Discourse) é naturalmente adequado para “tarefização” e sedimentação de conhecimento;
  • um mesmo Agent não significa que todos os canais devam ter responsabilidades equivalentes.

5.4 Consciência de governança de configuração

  • anti-abuso, whitelist e fronteiras de admin precisam vir antes;
  • granularidade de toggles deve ser fina (camadas por função, permissão, estratégia de notificação);
  • compatibilizar diferenças semânticas de entrada de config entre WebUI e CLI.

5.5 Capacidade de decisão de produto

  • de “viável tecnicamente” para “valor em primeiro lugar”;
  • de “empilhar funcionalidades” para “convergência de responsabilidades”;
  • com tempo limitado, cortar ativamente ramos de baixo ROI.

6. Posicionamento final: QQ como entrada, Discourse como bancada de trabalho

Até agora, eu posiciono estes dois canais assim:

  • QQ:

    • entrada de baixo atrito;
    • amigos jogam demandas rapidamente;
    • notificações rápidas, interação simples;
    • entrada de materiais imediatos como arquivo/áudio.

  • Discourse:

    • suporte a múltiplas tarefas;
    • interação e rastreamento do fluxo principal;
    • sedimentação de resultados, organização de conhecimento;
    • base principal para retrospectiva e colaboração.

Isso não é “qual é mais avançado”; é colocar cada plataforma de volta no lugar em que ela é boa.

7. Três lembretes para o meu eu do futuro

  1. Não confundir “capacidade do canal” com “valor do produto” em si.
  2. Quando você começar a empilhar complexidade para cenários de borda, faça primeiro uma pergunta: isso não é um jeito de fugir do verdadeiro problema principal?
  3. Qualquer plugin pode parar de ser mantido, mas a metodologia e o senso de fronteiras ficam — essa é a parte mais valiosa.

8. Conclusão

Neste período eu fiz muito trabalho que “parece desenvolvimento de ferramenta”, mas no fim o ganho não foi um bot mais chamativo, e sim um julgamento mais claro:

  • no que vale continuar investindo;
  • o que vale deixar em espera;
  • qual é a verdadeira rota principal do sistema.

Se eu resumir esta retrospectiva em uma frase:

Em vez de perseguir “todas as plataformas serem completas”, é melhor primeiro aprofundar e estabilizar o “fluxo de tarefas realmente importante”.

E, para mim, a rota principal neste momento é: Discourse primeiro, QQ como entrada.