Nesses dois últimos anos, a empresa adquiriu diversos ferramentas de IA: assistentes de conversação, extensões para escrita, robôs de atendimento ao cliente e sistemas internos de perguntas e respostas. No entanto, poucas dessas capacidades foram efetivamente consolidadas. Os prompts ainda permanecem no computador pessoal, os fluxos de trabalho estão espalhados pelos cantos dos documentos, após a implantação dos agentes inteligentes falta feedback e revisão, e os profissionais-chave do negócio continuam tendo suas horas ocupadas por consultas do mesmo tipo. O problema muitas vezes não é que o modelo não seja suficientemente inteligente, mas simO sistema não concebeu o “trabalho” como uma competência de cargo gerenciável.。
Primeiro, vamos esclarecer: por que a janela de chat não pode ser definida como cargo?
O chatbot responde a uma pergunta e encerra a conversa. O cargo precisa assumir o trabalho de forma contínua: coletar informações, avaliar regras, chamar o sistema, atualizar o status e, em caso de exceções, elevar o caso. O reembolso de despesas de viagem é um exemplo típico — o usuário pode começar dizendo “Ajude-me a registrar a viagem”, mas, no meio do caminho, perguntar “Quanto ainda resta do meu limite deste mês” e, em seguida, anexar outra nota fiscal. Se o sistema tratar cada interação como uma nova sessão, o fluxo será interrompido, o contexto se perderá e, posteriormente, não será possível analisar se o erro ocorreu na regra ou na interface.
Na indústria, já existe a prática de construir agentes inteligentes como “funcionários digitais”: atribui‑se a eles cargos, números de funcionário, limites de competência e registros de trabalho, além de equipá‑los com SOPs revisáveis, uma base de conhecimento, ferramentas e um histórico de execução. No âmbito do código aberto, o StaffDeck, lançado por instituições como a OpenBMB, trata os agentes como conjuntos de recursos operacionais, em vez de simplesmente como um conjunto de instruções. Para empresas que desenvolvem ou personalizam soluções internamente, o que vale a pena adotar não são os termos de produto, mas sim esse modelo de objeto.
Lógica de negócios: o sistema deve conter, no mínimo, sete tipos de objetos.
Ao desenvolver o sistema de funcionários digitais, primeiro é necessário definir os objetos de negócio no escopo e, em seguida, discutir a escolha do modelo.
- Arquivo do cargo: nome ou nome de personagem, número de funcionário, responsabilidades, status online, objeto de serviço. Sem arquivo, não há onde vincular permissões e avaliações.
- Fronteira de capacidade: Quais documentos podem ser lidos, quais campos podem ser preenchidos e o que não pode ser prometido. Os limites devem poder ser alterados pelo administrador, e não estar fixos no prompt.
- SOP / Habilidades de Processo: Divide os processos complexos em nós, suportando ramificações condicionais, chamadas de ferramentas, pesquisa de conhecimento e transferência para atendimento humano.
- Ontologia do conhecimento: Os temas, as regras, as fontes e os manuais de operação devem ser armazenados separadamente; as respostas devem poder ser vinculadas à fonte correspondente, e a pesquisa deve permitir ajustes.
- Acesso a ferramentas: Interface HTTP ou MCP, utilizada para consultar limites, criar documentos e alterar status, e não apenas para gerar um texto.
- Tarefa agendada: Atividades periódicas como a compilação de relatórios diários, o acompanhamento de prazos vencidos e a inspeção de estoques não podem esperar que os usuários se manifestem primeiro.
- Rastreamento e feedback: Registra rotas, etapas, ferramentas, conhecimentos e respostas; curtidas, avaliações negativas e a tomada manual passam para a próxima rodada de revisão.
Uma solicitação real geralmente inclui várias tarefas. O funcionário digital deve primeiro entrar no SOP de reembolso, coletar todos os campos e realizar a verificação das regras, para então mudar para o SOP de consulta de limite e chamar a API. Se o usuário interromper durante o processo para perguntar sobre políticas, deve-se salvar o estado atual do nó e, após responder, retornar ao fluxo original. Para questões que ultrapassam as regras, o contexto deve ser encaminhado ao criador ou ao responsável de plantão, sendo proibida qualquer resposta imprecisa sem base sólida.
Lógica de design: papéis, máquina de estados e hierarquia do conhecimento
Como mudar o papel?
Pelo menos quatro tipos de pessoas:Criador(Consolidar a experiência nos funcionários),Administrador(gerenciar permissões, publicação, quotas),Usuário(Enviar tarefas aos funcionários digitais),Pessoa de plantão(Continuação do caso excepcional). O criador não deve ter, por padrão, permissões para alterar o estoque ou os preços; o usuário não deve visualizar os termos completos e as chaves. As interfaces abertas também devem ser estratificadas: a chave de nível de conta pode gerenciar a configuração dos recursos, enquanto a chave de nível de funcionário só pode criar sessões e ler seu próprio histórico.
O SOP utiliza uma máquina de estados; não se limite a usar apenas a memória de diálogo.
A linguagem natural pode gerar um rascunho inicial, e a execução deve seguir uma máquina de estados: nó atual, slots já coletados, ferramentas passíveis de serem chamadas, retenção em caso de falha e nós manuais. Após uma tarefa ser interrompida, é necessário serializar o contexto para que se possa retornar ao nó original e prosseguir. Vários SOPs permitem a troca em tempo real, mas essa mudança deve preservar as informações de origem e os dados já confirmados, evitando que o usuário preencha formulários repetidamente. As versões e ramificações devem ser reversíveis; basta alterar uma frase‑chave no ambiente de produção para que a mudança seja implantada, sem possibilidade futura de responsabilização.
Não transforme o conhecimento em uma grande mistura para pesquisa.
Crie um índice navegável com base em documentos, capítulos, páginas e resumos; primeiro determine em qual categoria a informação provavelmente se encontra e, em seguida, localize o texto original. Organização do conhecimento em compartimentos: separar normas, descrições de produtos, scripts de pós‑venda e casos excepcionais; a pesquisa direcionada é mais confiável do que a busca por palavras‑chave em todo o sistema. Cada resposta deve estar vinculada à fonte, às regras e ao tema do negócio; no ambiente de testes, é necessário poder ver “por que essa passagem foi acertada”. A depuração da pesquisa costuma resolver problemas com mais frequência do que recorrer a um modelo ainda maior.
Desenvolvimento e implementação: interface, isolamento, monitoramento e aceitação
No momento da execução, recomenda-se adotar uma entrada unificada, evitando que cada habilidade siga um fluxo próprio, o que pode levar à deriva de estado. A descoberta de capacidades, a execução isolada, a integridade dos artefatos e a contabilização de cotas devem ser realizadas em tempo de execução, e não por meio de acordos pré‑estabelecidos. Antes de publicar uma habilidade no mercado interno, é necessário realizar uma verificação de permissões: cabeçalhos de autenticação, variáveis de ambiente e credenciais de conexão não devem aparecer em interfaces de leitura comuns.
- Canal de execução: O fluxo síncrono é adequado para conversas; o Run assíncrono + fluxo de eventos é adequado para retomar a transmissão após desconexão e para filas de tarefas, sendo que ambos utilizam o mesmo núcleo.
- Identidade do canal: O WeChat, o WeCom, o Feishu e o DingTalk podem servir como portais, mas as identidades dos funcionários, as conversas e os rastros devem ser unificados; é proibido que cada canal mantenha seu próprio sistema de registro.
- Segurança: A configuração do modelo apenas faz referência ao número de configuração existente, não retornando a chave do fornecedor; os resultados das ferramentas são desidentificados ao serem inseridos no Trace.
- Garantia manual: Em caso de tempo esgotado, baixa confiança, acesso não autorizado ou quando o usuário solicita atendimento manual, todas as quatro condições devem permitir a transferência completa do contexto.
A aceitação não deve se limitar a testar apenas a “capacidade de conversar”. Forneça um conjunto de scripts repetíveis: ciclo fechado normal, interrupção durante o processo, saldo insuficiente, timeout da interface, escrita com privilégios indevidos e resposta negada sem origem. Para cada script, verifique: se os nós foram restaurados, se os documentos foram gravados corretamente, se o Trace está completo e se as exceções foram atribuídas a pessoas. A taxa de aprovação das amostras, a taxa de tratamento de timeouts e o número de respostas sem base são indicadores mais adequados para controlar o acesso ao sistema do que as estrelas de satisfação.
Ordem de lançamento: primeiro, uma etapa de trabalho repetitivo
Não comece imediatamente a criar um assistente universal. Escolha uma tarefa repetitiva diária que dure mais de meia hora, como o registro de acompanhamento de vendas, a cobrança de aprovações, as perguntas e respostas sobre políticas ou a pré‑avaliação de despesas; transforme a entrada, a saída, os direitos e as exceções em quatro frases, e então elabore um SOP junto com duas ou três interfaces de leitura apenas ou de escrita restrita. Quando os dados mestres estiverem inconsistentes e os nós de aprovação não estiverem claros, primeiro corrija os objetos e os status, e só depois adicione a execução inteligente — após a automação dos dados incorretos, eles se espalharão ainda mais rapidamente por toda a empresa.
Como saber se o projeto foi bem executado: aquela etapa que antes dependia de lembretes em grupo e preenchimento de formulários deixou de ser o caminho principal; atas, acompanhamentos e resumos podem ser verificados por amostragem com base nos documentos; situações difíceis de esclarecer têm um canal de escalonamento; operações sensíveis são revisadas por alguém, e os registros podem ser consultados. Para avaliar se o desenvolvimento está adequado, observeÉ possível recuperar uma mesma SOP após ela ter sido interrompida?、Resposta: Pode indicar a fonte?、O caso de fronteira pode avançar para a próxima fase de revisão?. Depois de aprovadas essas três etapas, será possível expandir os cargos, o que é mais seguro do que primeiro criar muitas entradas de chat.
A dificuldade técnica do sistema de funcionários digitais não está na geração de diálogos, mas sim em transformar cargos, processos, conhecimentos, ferramentas e trajetórias em objetos de software versionáveis. Os prompts podem ser alterados dez vezes por semana; porém, se o modelo de objeto se desfizer, cada habilidade subsequente precisará ter seu próprio conjunto. Primeiro é preciso fazer funcionar essas sete categorias de objetos e a máquina de estados; só assim será possível realizar atualizações no modelo; caso contrário, cada mudança de modelo representará um novo projeto, e não uma simples alteração de configuração.