Runtime de agentes para trabalho coordenado | Dweve Nexus

Choose the audience that matches your question

The page contains three selectable readings of the same subject.

Assistência de agente de codificação e operador. As métricas de demonstração são ilustrativas.

Terminal, pesquisa, lint, testes, git e mais.

Lembra-se da sua base de código e do contexto da equipa.

Agentes especializados colaboram em diferentes áreas.

Cada passo é registado com carimbos de data e hora.

Políticas, verificações e testes são sempre executados.

Revise diffs, peça alterações, aprovação final.

Repita qualquer sessão bit a bit quando algo precisar de revisão.

Agentes autónomos que escrevem código e mantêm registos

para lidar com timeouts de rede, respostas 5xx e condições seguras para idempotência. Helper puro, totalmente testado por unidades.

Entrada, política, raciocínio num único artefacto

Pausa antes de qualquer coisa irreversível

formado em torno de uma tarefa, e mostra o que fez

intenção, âmbito, conteúdo, ética, anomalia, execução

objetivo obj-281 · equipa de 5 especialistas · ciclo 1/1

O runtime para organizações executáveis · um objetivo, uma equipa formada, um rastreio

executar decisão · reter pagamento ao fornecedor v-281

agir · portão de aprovação · decisão #4f9e2c

em fila para operações, a aguardar aprovação

assinar · M. Bos, ops-3 · 2026-04-12 09:14 CET

conta · rastreio de restrições selado, reproduzível de ponta a ponta

Base de conhecimento operacional, episódica, semântica e processual

Traga ao Nexus um objetivo que atualmente atravessa pessoas, sistemas, regras e aprovações. Veja como o trabalho é decomposto, como a organização se forma, como a autoridade é atribuída, como a falha é contida e como cada contribuição retorna a um resultado responsável.

Pipeline, fan-out, delegação, blackboard, debate

Dweve Nexus, o runtime para Organizações Executáveis

O Nexus é um runtime multiagente em Python para trabalho que precisa de mais estrutura do que um loop de prompt. A sua implementação separa agentes, ciclo de vida de tarefas, fluxos de trabalho, memória e encaminhamento baseado em capacidades em componentes distintos. Construtores Python, DweveScript e uma CLI definem e executam esse trabalho.

Correspondência de capacidades, requisitos explícitos

Use os construtores Python, DweveScript ou CLI para definir agentes, tarefas e fluxos de trabalho para o trabalho que precisa de coordenar.

Componentes para trabalho de agentes coordenado

Construtores Python, DweveScript e a CLI

De trabalho, episódica, semântica, processual e de conhecimento

Do dedutivo ao híbrido, selecionados para a tarefa

Dweve Nexus, cada tarefa tem a sua própria equipa

A maioria das ferramentas de IA dá todos os trabalhos ao mesmo assistente. O Nexus funciona de forma diferente. Por trás do Fabric, forma uma equipa à volta do que pediu, envia cada parte ao especialista adequado e devolve um único resultado através da conversa que já abriu. Pede uma vez. O Nexus organiza tudo por trás.

Pergunte uma vez. Deixe o Nexus formar a equipa, dividir o trabalho, juntar as peças e devolver um único resultado. A organização trabalha para si. A autoridade permanece consigo.

As entregas tipadas mantêm o runtime coerente. Quem assina o trabalho lê outra coisa.

A implementação atual fornece construtores Python para agentes e um compilador DweveScript para definições declarativas de agentes e fluxos de trabalho. A sua CLI analisa, compila e executa ficheiros DweveScript. Estas são interfaces complementares para a mesma implementação Python, e não alegações de clientes Rust, TypeScript ou Go equivalentes. Uma definição escrita numa delas é a mesma definição quando lida na outra, pelo que uma equipa pode alternar entre o ficheiro declarativo e o construtor sem manter duas descrições da mesma organização.

Para além das mensagens ponto a ponto, existe um barramento de eventos tipado, que é aquilo em que um grupo de agentes realmente se coordena: pedidos e resultados de tarefas, aceitação e rejeição, reivindicações e libertações, e eventos de ciclo de vida e saúde, com subscritores capazes de filtrar, encaminhar, descartar e transformar o que recebem. Dois tipos de estado são deliberadamente mantidos fora das mensagens individuais. Um quadro-negro é uma estrutura declarada que os agentes leem e escrevem, para que uma contribuição seja legível para algo além de quem a escreveu.

Eventos e o estado que se destina a ser partilhado

Uma entrega no Nexus é um valor com uma forma, e não um parágrafo que um agente espera que outro analise. A camada de protocolo transporta tipos compatíveis com A2A para mensagens, tarefas, artefactos, capacidades, competências, funções e estados, e JSON é uma forma de os colocar na linha, e não o próprio sistema de tipos. Ferramentas e sistemas externos chegam por contrato, e o Model Context Protocol é suportado como uma dessas fronteiras onde o cliente o deseja. Um componente recetor pode validar essa forma antes de agir, e o rasto mantém a entrega inspecionável. JSON é uma escolha de transporte; não substitui o contrato.

O replay responde ao que aconteceu. O que as partes entregam umas às outras é tipado com a mesma rigidez.

O Nexus tem componentes separados para encaminhamento, execução de fluxos de trabalho, comunicação, raciocínio, memória, segurança e recuperação. Essa separação torna possível inspecionar o componente relevante quando o trabalho se comporta de forma inesperada, em vez de tratar cada falha como um problema de prompt. Cada componente regista o que decidiu no momento em que decidiu, pelo que a pergunta após um incidente é qual componente mudou, e não qual frase foi mal redigida. Esse registo é o que um replay lê de volta.

O replay capturado reutiliza os resultados registados de cada chamada externa e reconstrói a execução original, o que testa as próprias decisões do runtime com o mundo exterior mantido estático. O replay ao vivo chama as dependências novamente e compara, o que é o teste que pode falhar e, portanto, o que vale a pena executar. O replay capturado responde se o runtime tomou as mesmas decisões com o mundo exterior mantido estático. O replay ao vivo responde se as dependências atuais ainda produzem o mesmo resultado. A comparação é, portanto, um teste do ambiente, não uma segunda cópia da história.

Tudo isso pode ser observado ao vivo. O que o runtime decide por si próprio é resolvido antes de ser executado.

Eventos estruturados são emitidos por entidade, e a implementação decide qual armazenamento os recebe: memória limitada num ambiente de desenvolvimento, armazenamento persistente em produção e armazenamento somente de anexação ou à prova de adulteração onde o registo tem de resistir a alguém fora do edifício. Cada um desses é chamado pelo que é. O runtime não chama imutáveis a registos mutáveis comuns, que é a diferença entre evidência que alguém aceita e uma alegação que testam. Os eventos mantêm a sua entidade e postura de armazenamento.

Os tipos de entidade aceitam perguntas diferentes, e a assimetria é a parte útil. Perguntar a um agente como está a sua saúde faz sentido, e fazer a mesma pergunta a uma operação não faz, porque uma operação ou está bloqueada ou não está, e a sua saúde é apenas a saúde de quem está dentro dela. Uma unidade de trabalho tem um prazo e uma contagem de tentativas, e um grupo não tem nenhum dos dois: o que um grupo tem é uma adesão e um registo do que trabalhou. Como nenhum desses conjuntos coincide, um único fluxo plano de linhas responde mal a todos os quatro.

Uma pergunta de produção raramente é o que um log disse. É qual unidade de trabalho falhou o prazo, qual agente está pouco saudável, qual parte da operação está bloqueada e em quê. O Nexus reporta o estado nas mesmas coisas que executa, por isso a pergunta vai para quem detém a resposta, em vez de ser montada a partir de linhas que por acaso a mencionam. Isso torna a pergunta endereçável sem reproduzir uma conversa. O estado pertence à entidade que detém o trabalho, por isso um prazo falhado, um agente pouco saudável ou uma operação bloqueada podem ser investigados a partir do seu registo e condição atual.

A recuperação é algo que te é comunicado. Observá-la enquanto corre é uma exigência diferente.

Duas consequências que um engenheiro pode usar. Como a espera é um ponto fixo determinístico computado a partir do número da tentativa, em vez de um sorteio de uma fonte aleatória, o agendamento de uma execução falhada faz parte do que é reproduzido, por isso uma discussão sobre quanto tempo demorou ontem tem uma resposta em vez de uma teoria. E como o circuito pertence ao agente em vez do tipo de trabalho, uma dependência a falhar deixa de encaminhar para um lugar enquanto o mesmo trabalho continua encaminhável em todo o resto. Cada substituição é registada à medida que acontece: o reencaminhamento nomeia o agente substituto e o estado que viajou com ele, por isso uma execução resgatada lê-se depois como uma peça de trabalho com uma recuperação lá dentro.

Algo vai falhar, e a pergunta interessante não é qual resposta é escolhida. É o que impede a recuperação de se tornar a carga de trabalho. Cada parte dela é limitada antes de o problema começar: quantas tentativas, quanto tempo dura cada espera, quanto da margem um resgate pode gastar, e quanto do património uma dependência má leva consigo. Nada aqui termina porque um ciclo decidiu que já tinha tentado o suficiente. O runtime regista o número da tentativa, a espera computada, o estado do circuito, o substituto e o estado transportado. Isso dá a uma revisão de incidente um caminho limitado para inspecionar: uma tentativa pode ser reproduzida, uma rota fechada pode ser explicada e uma falha terminal pode ser distinguida de um resgate que terminou.