A Jev só está disponível publicamente há pouco tempo, mas os programadores já a integraram em agentes de programação, ciclos de navegador, ferramentas MCP, pipelines de conjuntos de dados, jogos, experiências de robótica e sistemas de negociação.
Esta não é mais uma lista de casos de utilização teóricos da Jev. Os projetos abaixo mostram algo mais útil: onde os programadores colocam um modelo de decisão dentro de software real, o que a Jev pode decidir e quais as partes que permanecem sob o controlo de código determinístico ou de um modelo generativo maior.
Se é novo no próprio modelo, comece pela nossa explicação sobre como funcionam os modelos de decisão Jev. Se procura padrões de aplicação mais abrangentes, em vez de repositórios individuais, o guia anterior sobre casos de utilização reais da Jev aborda orquestração de agentes, triagem de investigação, automação do navegador e outros tipos de cargas de trabalho.
Uma ressalva: este ecossistema é extremamente recente. Muitos repositórios são experiências, demonstrações ou projetos de um único programador. Verifique o repositório atual, a licença, o comportamento da API e os limites de segurança antes de considerar qualquer um deles software de produção.
O que estes 20 projetos Jev estão realmente a testar
Os projetos parecem muito diferentes à primeira vista, mas a maioria segue a mesma arquitetura:
estado estruturado ↓ decisão limitada ↓ política de software convencional ↓ ferramenta, modelo ou ação
O aspeto importante é que a Jev raramente é responsável por todo o fluxo de trabalho. Normalmente, substitui um único juízo impreciso e restrito que, de outra forma, exigiria outra chamada a um LLM ou um conjunto crescente de heurísticas.
| Projeto | Área | Espaço de decisão |
|---|---|---|
| fast-jev-compaction | Agentes de programação | Qual o contexto antigo que ainda é relevante |
| Winnow | Agentes de programação | Quais os blocos de saída das ferramentas relevantes |
| Jev Codex Router | Encaminhamento de modelos | Qual o modelo e nível de raciocínio a utilizar |
| Jev Review | Revisão de código | Onde deve incidir a atenção da revisão |
| Blink | Pesquisa de código | Qual o caminho a explorar em seguida |
| Canny | Guardrails de agentes | Se as evidências semânticas sustentam a conclusão |
| typesafe-mcp | MCP | Avaliações tipadas de escolha, pontuação e Noul |
| jev-mcp | MCP | Classificação, ordenação e triagem |
| SemDecide | CLI / CI | Predicados semânticos dentro de pipelines |
| jev-ultrafast | Automação do navegador | Próxima operação e elemento-alvo |
| ambiente de trabalho do agente | Utilização do computador | Qual o controlo nativo da IU a utilizar |
| json-render + Jev | IU generativa | Seleção e posicionamento de componentes |
| typesafe-mario | Jogos | Próxima ação legal do controlador |
| jev-drone | Simulação de robótica | Avaliação tática de nível superior |
| OneVOneJev | Jogos | Decisões de movimento e combate |
| jev-trader | Negociação | Direção de compra ou venda |
| Prism | Análise de mercado | Indicadores do estado do mercado |
| neo4jev | Grafos de conhecimento | Qual a relação a percorrer |
| jev-curate | Pipelines de dados | Avaliações de qualidade e relevância |
| killmyidea | Demonstração da aplicação | Pontuação estruturada de ideias para startups |
Os agentes de programação estão a tornar-se o ambiente de testes mais interessante da Jev
Coding agents generate huge amounts of intermediate state: file contents, command output, stack traces, diffs, test logs and repeated routing decisions. Much of that work does not need another paragraph from a frontier model. It needs selection.
1. fast-jev-compaction — Compress Context Without Rewriting It
fast-jev-compaction replaces the usual summarization-heavy compaction step with relevance judgments over previous tool calls and results.
Low-value history can be dropped or truncated while retained commands, paths, errors and outputs stay verbatim. That makes context compression a selection problem rather than a rewriting problem.
The value is not that Jev writes a better summary. It avoids writing one.
2. Winnow — Stop Irrelevant Tool Output Before It Enters Context
Winnow attacks the same problem earlier in the pipeline. Large Read, Bash or Grep results are split into blocks, then evaluated for task relevance before they consume more context.
A distinção em relação à compactação é importante:
- Winnow: filtra as informações à entrada do contexto de trabalho.
- fast-jev-compaction: remove informações obsoletas que já se encontram no histórico da conversa.
Em conjunto, mostram dois pontos distintos em que os agentes de programação podem substituir a sumarização intensiva em tokens por avaliações de relevância delimitadas.
3. Jev Codex Router — Decida de quanto modelo uma tarefa realmente precisa
Jev Codex Router eleva a decisão um nível: antes de o Codex tratar uma tarefa, o Jev seleciona um nível de modelo e o esforço de raciocínio.
Isto torna o Jev num controlador de tráfego, e não num modelo de programação. O trabalho simples pode permanecer numa rota mais barata, enquanto os turnos difíceis podem ser escalados.
O repositório apresenta uma simulação histórica que sugere poupanças substanciais em comparação com o encaminhamento de cada turno testado pela sua rota anteriormente mais dispendiosa, mas esse valor deve ser tratado como um backtest e não como uma poupança atual medida na quota do Codex.
A arquitetura também se liga a uma questão mais ampla que já explorámos: se um modelo pequeno consegue encaminhar pedidos para modelos maiores sem se tornar, ele próprio, o mecanismo final de raciocínio.
4. Jev Review — Dedique a atenção da revisão ao que importa
Jev Review divide a revisão de código em avaliações mais específicas, como quais ficheiros merecem atenção, que evidências são relevantes e quão grave pode ser um problema suspeito.
A parte interessante é a priorização. O Jev não precisa de gerar a análise final para melhorar o fluxo de trabalho; pode primeiro reduzir um diff grande aos locais onde vale a pena investir num raciocínio mais aprofundado ou numa análise humana.
5. Blink — Navegar numa base de código através de uma escolha semântica de cada vez
O Blink trata a pesquisa em repositórios como uma seleção de caminhos.
A cada nível de diretório, os ficheiros e as pastas visíveis tornam-se candidatos. O Jev seleciona o ramo seguinte mais promissor para a pergunta atual, e a pesquisa continua recursivamente.
Em vez de incorporar um repositório inteiro antes de cada consulta, o sistema coloca repetidamente uma pergunta muito mais específica: onde devo procurar a seguir?
6. Canny — Separar «Acho que terminei» das evidências de que o trabalho está concluído
O Canny destina-se às declarações de conclusão dos agentes.
Os registos determinísticos acompanham o que realmente aconteceu: ficheiros alterados, comandos executados, testes concluídos e resultados produzidos. O Jev pode acrescentar julgamentos semânticos em torno dessas evidências, mas o modelo não se torna a camada final de autorização.
Esta separação é importante para agentes locais que podem modificar sistemas reais. O nosso guia sobre limites de confiança na execução de ferramentas explica o mesmo princípio ao nível mais abrangente da arquitetura de agentes: decidir que uma ação parece adequada não é o mesmo que conceder permissão para a executar.
Projetos MCP e CLI transformam o Jev em infraestrutura
O grupo seguinte é menos específico de aplicações. Estes projetos disponibilizam o Jev como uma primitiva de decisão reutilizável dentro de ferramentas existentes.
7. typesafe-mcp — Dar aos agentes existentes acesso direto ao Jev
typesafe-mcp expõe o Jev através do Model Context Protocol.
Um agente compatível com Claude, Codex ou MCP pode solicitar um julgamento estruturado de Escolha, Pontuação ou Noul sem implementar uma nova integração com o Jev para cada fluxo de trabalho. O agente continua a decidir quando a ferramenta deve ser chamada e o que fazer com o resultado.
8. jev-mcp — Transformar decisões comuns em ferramentas para agentes
jev-mcp eleva o nível de abstração ao expor operações familiares, como classificação, pontuação, triagem e correspondência.
Em vez de cada agente inventar um novo prompt para o mesmo julgamento, os padrões de decisão comuns podem tornar-se interfaces reutilizáveis com resultados estruturados.
9. SemDecide — Colocar lógica semântica dentro de pipelines Unix
O SemDecide explora uma superfície de integração ainda mais pequena: a linha de comandos.
grep → jq → decisão semântica → ação de shell
Isto é útil para questões difíceis de expressar com uma regex, mas ainda demasiado limitadas para justificar um agente autónomo, como determinar se uma alteração parece sensível do ponto de vista da segurança ou se um registo pertence a uma categoria semântica.
A fronteira fundamental continua a ser determinística: as permissões, os comandos destrutivos e as verificações de segurança em produção devem permanecer em código normal.
Agentes de Browser e Desktop: Escolha ações em vez de as gerar
A automatização de browsers adapta-se particularmente bem a uma camada de decisão limitada. Depois de uma página ser convertida em elementos candidatos, grande parte do ciclo passa a ser seleção de ações, e não geração de linguagem.
10. jev-ultrafast — Geração apenas quando o browser precisa realmente de palavras
jev-ultrafast cria um espaço de ações indexado a partir da página atual e permite ao Jev escolher uma operação e o elemento-alvo.
Só é necessário um modelo generativo quando a ação selecionada requer texto novo, como preencher um campo de formulário.
A demonstração do Google Flights do projeto indica cerca de sete segundos para uma tarefa de exemplo, incluindo a geração e as esperas pelo carregamento das páginas. Isso não deve ser tratado como um benchmark universal de agentes de browser. O resultado mais importante é arquitetural: a seleção de cliques e a geração de texto não têm de usar o mesmo modelo.
11. agent-desktop — Aplicar o mesmo padrão à UI nativa
agent-desktop disponibiliza interfaces do macOS através de dados de acessibilidade e referências estáveis a elementos.
Em vez de reconstruir o ambiente de trabalho a partir de capturas de ecrã a cada passo, o sistema pode fornecer ao Jev um conjunto limitado de controlos e ações. As ferramentas nativas continuam a executar a operação efetiva de clique, foco ou teclado.
Este é um lembrete útil de que uma melhor observação é muitas vezes mais importante do que um modelo maior.
12. json-render + Jev — UI generativa sem geração arbitrária de UI
json-render experimenta usar o Jev para compor interfaces a partir de um catálogo de componentes pertencente à aplicação.
A aplicação define quais componentes, propriedades e ações são permitidos. O Jev escolhe entre esses candidatos, enquanto o código normal monta e valida a árvore resultante.
O caminho de composição do Jev continua experimental, mas demonstra uma alternativa útil à geração de JSON de UI sem restrições: deixe a aplicação definir o vocabulário e, depois, deixe o modelo escolher a partir dele.
Os jogos e a robótica mostram onde o Jev não deve estar no controlo
Os sistemas em tempo real tornam óbvios os limites arquitetónicos. A física, o tratamento de colisões, a segurança e os ciclos de controlo rápidos não podem esperar pela resposta incerta de um modelo.
13. typesafe-mario — Entrada de estado estruturado do jogo, saída de ação legal do controlador
typesafe-mario converte a telemetria do emulador e a RAM num estado estruturado compacto, em vez de enviar capturas de ecrã ao Jev.
O Jev seleciona então entre ações legais do controlador, como mover-se para a direita, saltar ou correr e saltar. A aritmética temporal, o controlo do emulador e a extração do estado do jogo permanecem no software normal.
A demonstração isola claramente o problema de decisão: o modelo não precisa de redescobrir o mundo do jogo a partir de píxeis antes de cada movimento.
14. jev-drone — Mantenha o modelo acima do ciclo de segurança
jev-drone executa um quadricóptero autónomo numa simulação MuJoCo.
O controlo geométrico rápido, a orientação e a segurança continuam determinísticos. O Jev opera muito mais lentamente, como camada tática consultiva que interpreta a situação atual.
Controlo de voo a 500 Hz, orientação + segurança a 50 Hz, câmara a 15 Hz → cena simbólica a ~2,5 Hz, avaliação tática do Jev
O projeto é uma simulação, não uma prova de que o Jev deva controlar uma aeronave real. A lição arquitetónica é mais forte do que essa afirmação: o juízo probabilístico deve ficar acima da lógica de segurança em tempo real.
15. OneVOneJev — Um ciclo de jogo consiste sobretudo em seleções repetidas
O OneVOneJev aplica o Jev a um jogo de tiros um-contra-um baseado no navegador.
O servidor controla a física, a rede e o estado legal do jogo. O Jev opera dentro desse mundo limitado, escolhendo ações de movimento ou combate.
Isto torna o projeto útil menos como produto de jogos e mais como teste de esforço para decisões repetidas e limitadas, nas quais produzir explicações em linguagem natural acrescentaria muito pouco.
Experiências de negociação: os modelos de decisão não devem controlar a carteira
As demonstrações financeiras merecem uma interpretação mais rigorosa. Uma avaliação rápida do mercado não é prova de negociação rentável, e um bot experimental não deve ser confundido com uma estratégia validada.
16. jev-trader — Uma decisão de direção por bloco da Monad
jev-trader acompanha o livro de ordens Kuru MON-USDC na Monad e pede ao Jev que escolha uma direção de compra ou venda uma vez por bloco.
O sistema envolvente trata dos dados de mercado, da construção de ordens limitadas, das restrições de posição e da execução. Também permite operar em modo de simulação sem uma chave privada.
Esse limite é a parte útil: o Jev contribui com uma avaliação do mercado; o software normal continua a controlar a mecânica de negociação.
17. Prism — Tratar o Jev como um sinal, não como a estratégia
O Prism adota uma abordagem mais consultiva. O Jev avalia condições de mercado, como a qualidade do fluxo, a pressão ou os sinais de reversão à média, enquanto as camadas de estratégia e execução permanecem separadas.
Este é um padrão geral melhor para fluxos de trabalho de alto impacto: os modelos podem contribuir com evidência probabilística sem receber autoridade sobre ações irreversíveis.
A pesquisa e os pipelines de dados mostram que o Jev não precisa de um agente
Alguns dos projetos mais fortes eliminam completamente os agentes autónomos. O Jev torna-se uma operação semântica dentro de um algoritmo convencional.
18. neo4jev — Acrescentar discernimento semântico à pesquisa em grafos
neo4jev usa o Jev ao percorrer um grafo de conhecimento Neo4j.
Em cada nó, as relações candidatas tornam-se uma escolha limitada. O Jev estima qual a aresta mais promissora para a pergunta atual, enquanto o código de pesquisa clássico trata da travessia, dos nós visitados, da largura do feixe e das condições de paragem.
Este é um padrão útil para além dos grafos: substituir uma heurística frágil num algoritmo existente em vez de reconstruir toda a aplicação à volta da IA.
19. jev-curate — Pontuar dados antes de gastar mais recursos computacionais com eles
jev-curate aplica avaliações semânticas repetidas a registos JSONL ou Parquet antes de estes entrarem em fases de treino, análise ou revisão mais dispendiosas.
A curadoria de dados é uma carga de trabalho naturalmente centrada em decisões: milhões de linhas podem precisar de avaliações de relevância, qualidade ou risco, mas quase nenhuma requer um parágrafo de texto gerado.
O modelo trata da avaliação difusa; o pipeline continua a controlar o processamento em lotes, os limiares, o armazenamento e a política final de aceitação.
20. killmyidea — Uma pequena demonstração que torna a arquitetura evidente
killmyidea pede ao Jev que avalie uma ideia de startup através de várias perguntas estruturadas.
A aplicação aplica depois pesos, portas e limiares comuns para transformar essas pontuações num veredito final de ELIMINAR, CORRIGIR ou PUBLICAR.
ideia ↓ pontuações do Jev ↓ ponderação determinística ↓ ELIMINAR / CORRIGIR / PUBLICAR
É um projeto pequeno, mas capta um princípio de design importante: a IA pode acrescentar discernimento útil sem ser responsável por gerar o resultado final do produto.
Que projeto Jev deve experimentar primeiro?
| O seu objetivo | Comece por | O que demonstra |
|---|---|---|
| Adicionar o Jev a um agente existente | typesafe-mcp / jev-mcp | Decisões tipadas como ferramentas |
| Reduzir o desperdício de contexto do agente de programação | Winnow / fast-jev-compaction | Seleção em vez de sumarização |
| Encaminhar pedidos entre modelos | Jev Codex Router | Modelo de decisão antes do modelo generativo |
| Criar um ciclo de navegador mais rápido | jev-ultrafast | Seleção de ações separada da geração |
| Automatizar software de ambiente de trabalho | ambiente de trabalho do agente | Controlo estruturado orientado para a acessibilidade |
| Explorar escolhas repetidas em tempo real | typesafe-mario | Estado estruturado para seleção de ações |
| Estudar a pesquisa semântica | neo4jev | Modelos de decisão dentro de algoritmos clássicos |
| Criar um grande pipeline de pontuação | jev-curate | Avaliação semântica em lote |
É possível executar estes projetos Jev localmente?
Em muitos casos, pode executar localmente o projeto envolvente. Isso não significa que a própria Jev esteja a ser executada localmente.
Em setembro de 2026, a Jev é acedida como um serviço TypeSafe alojado, e não através de pesos de modelo disponíveis publicamente para transferência. Por isso, um agente de programação local, um servidor MCP ou um controlador de navegador pode ser executado na sua própria máquina, enquanto envia o estado de decisão selecionado para a API Jev.
ficheiros locais / navegador / agente ↓ estrutura local ou servidor MCP ↓ estado estruturado selecionado ↓ API Jev ↓ decisão tipada ↓ o software local executa
Se for importante manter o próprio modelo de decisão no seu hardware, é aí que a arquitetura muda. O nosso guia sobre o modelo de decisão local de código aberto Laya analisa uma alternativa com pesos disponíveis para transferência, que pode ser executada em hardware local.
A distinção é útil para implementações de homelab e IA privada:
| Arquitetura | Onde é executado o fluxo de trabalho | Onde é executado o modelo de decisão |
|---|---|---|
| Projeto Jev local | Máquina / servidor local | API Jev alojada |
| Fluxo de trabalho Laya totalmente local | Máquina / servidor local | Hardware local |
| Pilha de agentes híbrida | Principalmente local | Modelos locais e na cloud por carga de trabalho |
Essa diferença é mais importante do que o facto de um README do GitHub dizer “local”. Um fluxo de trabalho pode ser alojado localmente, embora uma etapa de decisão continue a depender de um serviço de inferência externo.
O verdadeiro padrão Jev é mais pequeno do que um agente
O mais importante nestes 20 projetos não é o número de aplicações que os programadores já criaram. É a consistência com que a Jev surge num ponto estreito do ciclo.
Um navegador já sabe que elementos existem. A Jev escolhe um.
Um agente de programação já produziu milhares de linhas de resultados de ferramentas. A Jev decide o que ainda importa.
Um router já sabe que modelos estão disponíveis. A Jev escolhe uma rota.
Um grafo já contém as suas arestas. A Jev escolhe qual parece útil.
Um drone já tem um controlador de voo. A Jev fornece uma decisão tática mais lenta.
Um sistema de trading já tem lógica de ordens e restrições de risco. A Jev fornece um sinal de direção.
É isso que torna a primeira vaga de projetos Jev mais interessante do que outra coleção de demonstrações de chatbots. Os programadores estão a testar se algumas partes da atual pilha de IA devem deixar de ser generativas.
Por isso, a pergunta útil não é se a Jev pode substituir um LLM de fronteira.
É perceber quantas chamadas LLM dispendiosas e abertas presentes no software atual eram, na realidade, apenas decisões limitadas à espera de uma interface mais pequena.
Centro de Tecnologia e IA
Mais para Ler

Calibração da pontuação de pesquisa privada: como a similaridade bruta se transforma num indicador de confiança utilizável
Saiba por que razão a similaridade do cosseno não é confiança, como as consultas rotuladas calibram as pontuações e como monitorizar os limiares quando...

Localidade NUMA da IA local: por que a colocação da memória altera a taxa de alimentação do acelerador
Saiba como a topologia da CPU, da RAM e do PCIe afeta a alimentação do acelerador, por que motivo a colocação automática pode variar...

Mapeamento de ficheiros de modelos na memória: como as páginas partilhadas reduzem a utilização duplicada de RAM
Compreenda como as páginas de modelos mapeados são paginadas e partilhadas, por que motivo o RSS pode induzir em erro e que caches e...

