De “sessão de conversa” a “funcionário digital sempre ativo”: 5 mudanças fundamentais na arquitetura do openJiuwen Hyper-Agent

Nota do autor: este artigo analisa a arquitetura de agentes permanentes do openJiuwen Hyper-Agent para ajudar quem cria fluxos de trabalho a avaliar se esse modelo é adequado para sua equipe.

A comunidade de agentes de código aberto openJiuwen, apoiada pela Huawei, lançou a arquitetura de enxame Hyper-Agent, que permite aos agentes sair de sessões de chat individuais e atuar em grupos de trabalho reais como “funcionários digitais permanentes”. Em 5 de novembro de 2026, o Pandaily noticiou, citando um artigo da comunidade publicado pelo IT Home, que os recursos já estão disponíveis no openJiuwen WorkSwarm e que o código foi disponibilizado no GitHub sob o nome JiuwenSwarm.

Não se trata apenas de adicionar mais um chatbot de perguntas e respostas ao grupo. A verdadeira mudança é a inversão da relação entre agentes e sessões: a sessão deixa de ser o contêiner que abriga o agente e passa a ser um recurso que o sistema pode gerenciar.

O que você vai encontrar: o artigo reúne funcionalidades dispersas sob uma perspectiva de arquitetura para ajudar você a entender o que o openJiuwen Hyper-Agent muda e o que sua equipe deve verificar antes de adotá-lo.

openJiuwen Hyper-Agent: informações essenciais

Vale esclarecer que este artigo se baseia em uma notícia de segunda mão sobre uma publicação da comunidade. A notícia não informa quais são os modelos subjacentes, os requisitos de implantação, a licença ou a maturidade para produção. Essas informações precisam ser confirmadas no repositório do GitHub e na documentação oficial.

Como o openJiuwen Hyper-Agent transforma sessões em recursos

A maioria das aplicações de agentes segue o modelo de “um agente por sessão”: o usuário abre uma conversa e o agente começa a trabalhar, com identidade, contexto e progresso das tarefas vinculados àquela conversa. Ao mudar de grupo ou de janela, muitas vezes é preciso começar a colaboração do zero.

O Hyper-Agent faz o contrário. O Persistent Agent tem identidade e estado próprios e pode receber trabalho continuamente. As sessões passam a ser recursos subjacentes, que o sistema aloca, agenda de forma concorrente e retoma com o contexto necessário. Segundo a comunidade, esse design se baseia no trabalho anterior com Persistent Session e permite que um agente acompanhe várias tarefas ao mesmo tempo em diferentes grupos de aplicativos de terceiros.

Sobre o diagrama: à esquerda, o estado está vinculado à sessão; à direita, ao agente. Se quiser comparar o consumo de contexto usando conversas do seu próprio negócio, você pode fazer experimentos em pequena escala pela interface unificada da APIYI, em apiyi.com.

Os 5 componentes principais da arquitetura openJiuwen Hyper-Agent

Pela descrição apresentada, o sistema pode ser dividido em cinco camadas: acesso, orquestração, gestão de identidade, colaboração e observabilidade. A tabela abaixo reúne nossa interpretação das responsabilidades de cada componente; não se trata de uma divisão oficial.

Central de funcionários do Hyper-Agent e transferência de contexto

Na central de funcionários, o usuário pode configurar responsabilidades, estilo de trabalho, requisitos de entrega, habilidades, conectores, fontes de conhecimento e até um endereço de e-mail exclusivo. É como transformar a configuração do comando em uma “descrição de cargo”: ali são definidos os limites das capacidades do agente e sua identidade perante outros usuários.

Uma execução prolongada inevitavelmente chega ao limite da janela de contexto. O WorkSwarm lida com isso mudando para uma nova janela quando a atual está perto do limite e levando um resumo de transição com os objetivos, o progresso e os próximos passos. Quando precisa de detalhes, ele consulta o histórico arquivado. Assim, o trabalho pode continuar sem precisar colocar todo o histórico na janela atual.

Modos passivo e adaptativo do Hyper-Agent

Decidir se um agente deve falar em um grupo de trabalho é uma questão inevitável no modo permanente. O WorkSwarm oferece dois modos de resposta, cuja principal diferença está na previsibilidade do comportamento.

A reportagem não explica o mecanismo de decisão nem a taxa de acerto do modo adaptativo. A equipe pode começar com um experimento simplificado para entender a dificuldade desse tipo de decisão. O código abaixo é apenas uma demonstração nossa, não a implementação do WorkSwarm:

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

message = "接口今天下午还没联调通，明天的发布可能有风险。"
response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": "你是项目助理。只输出 ignore、respond 或 intervene。"},
        {"role": "user", "content": message}
    ]
)
print(response.choices[0].message.content)

import json
import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

def create_handoff_summary(history: list[str], model: str = "gpt-4o-mini") -> dict:
    """Resume os registros de trabalho em objetivos, progresso e próximos passos para simular a transferência de contexto."""
    prompt = (
        "请根据工作记录输出 JSON，字段为 goals、progress、next_steps。"
        "不要输出 JSON 以外的内容。\n\n" + "\n".join(history)
    )
    response = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        response_format={"type": "json_object"}
    )
    return json.loads(response.choices[0].message.content)

records = [
    "产品经理：周五前完成客户周报。",
    "智能体：已汇总销售数据，等待客服数据。",
    "客服主管：今天下班前提供工单统计。"
]
print(create_handoff_summary(records))

Sugestão para o experimento: você pode começar obtendo créditos gratuitos de teste pela APIYI apiyi.com e comparar as decisões de diferentes modelos usando amostras anonimizadas de conversas em grupo. Essa etapa valida a lógica de decisão, mas não significa que o WorkSwarm já ofereça suporte a essa interface.

Colaboração entre grupos e dispositivos locais com o Hyper-Agent do openJiuwen

O mesmo agente pode trabalhar em aplicativos corporativos como Feishu e DingTalk, recebendo uma solicitação em um canal e entregando o resultado em outro. O compartilhamento entre grupos não é liberado por padrão: o usuário precisa conferir o grupo de origem, o destinatário e o conteúdo antes de conceder uma autorização única ou permanente. A autorização também pode ser revogada depois.

Os membros da equipe também podem executar o WorkSwarm em seus próprios dispositivos. Os agentes no servidor em nuvem e nos computadores pessoais podem colaborar no mesmo grupo, usando arquivos e ferramentas locais já autorizados. Assim, a nuvem mantém os agentes disponíveis continuamente, enquanto os dispositivos locais fornecem dados e ferramentas do ambiente pessoal de cada usuário.

Para tarefas maiores, o chat em grupo do SwarmEngine pode reunir usuários, Persistent Agents, especialistas individuais e equipes de especialistas no mesmo espaço. Em cada equipe, um responsável recebe as tarefas, informa o andamento e organiza a entrega, enquanto os membros trabalham em segundo plano. Os especialistas também podem vir de agentes de terceiros, como Codex e Claude Code, e atuar junto com funcionários digitais criados pela própria equipe.

Análise dos impactos do openJiuwen Hyper-Agent

Impactos para desenvolvedores e criadores de fluxos de trabalho

• Mudança no foco de design: em vez de projetar uma única conversa, passa a ser necessário definir a identidade, o estado, as permissões e os mecanismos de transferência de tarefas dos agentes.
• Mais exigências operacionais: agentes permanentes precisam ser monitorados, auditados e gerenciados como serviços em produção.
• Ampliação das integrações: mensageiros, bases de conhecimento, e-mails e ferramentas locais podem fazer parte de um mesmo fluxo de tarefas.

Impactos na colaboração entre equipes

• Agentes deixam de ser apenas ferramentas e passam a colaborar: eles podem acompanhar tarefas por longos períodos, em vez de apenas responder a uma pergunta.
• Governança desde o início: é preciso definir antecipadamente quem pode compartilhar dados, quando o agente pode se manifestar e quem é responsável pelos resultados.
• Orquestração híbrida ganha importância na avaliação: a divisão de trabalho entre funcionários criados internamente e agentes de terceiros afeta a qualidade das entregas e a atribuição de responsabilidades.

Pontos para equipes avaliarem o Hyper-Agent

Perguntas frequentes sobre o openJiuwen Hyper-Agent

Pontos principais do openJiuwen Hyper-Agent

• Arquitetura: o agente mantém sua identidade e seu estado, enquanto as sessões se tornam recursos gerenciáveis pelo agendador.
• Componentes centrais: o Gateway cuida do acesso, e o AgentServer coordena os agentes e as sessões.
• Operação de longo prazo: resumos de transição permitem trocar de contexto e consultar o histórico arquivado quando necessário.
• Estratégia de resposta: o modo passivo oferece mais controle; o adaptativo é mais proativo, mas precisa ser validado.
• Permissões: o compartilhamento entre grupos exige aprovação. A autorização pode ser pontual ou permanente e também pode ser revogada.
• Colaboração híbrida: nuvem, dispositivos locais, equipes de especialistas e agentes de terceiros podem participar do mesmo espaço de colaboração.
• Caminho de validação: primeiro, confira a documentação do projeto; depois, use a APIYI apiyi.com para testar a etapa de modelos.

Conclusão: o que a arquitetura do openJiuwen Hyper-Agent nos ensina

O que chama a atenção no openJiuwen Hyper-Agent não é apenas a presença de agentes no Feishu ou no DingTalk, mas a forma como ele transforma a ideia de que “a sessão deixa de ser um contêiner e passa a ser um recurso” em uma decisão de arquitetura:

1. Identidade persistente: o Persistent Agent mantém a continuidade do trabalho mesmo após o fim de uma sessão.
2. Coordenação como peça central: o AgentServer coordena os agentes e as várias sessões de trabalho.
3. Governança como condição para adoção: aprovação de permissões, controle de participação e visibilidade do uso determinam se a solução pode ser adotada por equipes reais.

Se o seu trabalho depende de colaboração entre vários grupos, acompanhamento de longo prazo e entregas em diferentes canais, vale a pena estudar esse modelo. Se os processos envolvem dados sensíveis ou exigências rigorosas de conformidade, comece com um piloto isolado, em modo passivo e com permissões mínimas. Para avaliar a etapa de decisão dos modelos, você pode usar a APIYI apiyi.com e comparar diferentes modelos com o mesmo conjunto de interfaces, reunindo dados para orientar a escolha técnica.

📚 Referências

1. Pandaily – openJiuwen’s Hyper-Agent Swarm Puts Persistent AI Agents Into Work Chats as Digital Employees: principal fonte dos fatos apresentados neste artigo
2. Link: pandaily.com/openjiuwen-hyper-agent-swarm-architecture-persistent-agents-workswarm-digital-employees
3. Descrição: apresenta a arquitetura do Hyper-Agent, os recursos do WorkSwarm e os próximos planos da comunidade. É uma reportagem secundária baseada em material da comunidade

Autor: Equipe técnica da APIYI
Contato técnico: entre em contato pela página inicial do site da APIYI. Para mais informações, acesse a central de documentação em docs.apiyi.com