A startup de Wang Yunhe lança o NeoHorse, primeiro modelo nativo de agente

Após empreender, Wang Yunhe apresentou pela primeira vez os resultados do grande modelo.

A Quantum Bit informa que o ex-diretor do Laboratório Ark of Huawei, Pangu Large Model A YuanYuan Rhythm, fundada por Wang Yunhe, lançou o primeiro modelo Agent-Native, NeoHorse.

O modelo é suportado por infraestrutura e capacidades de otimização de infraestrutura fornecidas pela Wuwen Xinqiong, com equipes da Universidade Tsinghua e da Universidade de Pequim participando da pesquisa em algoritmos e métodos de treinamento, buscando conjuntamente melhorar a eficiência na utilização de dados e os resultados do pós-treinamento de Agentes.

NeoHorse-1 inclui duas versões, 4B e 9B, voltadas principalmente para um conjunto de habilidades necessárias durante o processo de agentes, incluindo chamada de ferramentas, leitura de feedback do ambiente, detecção de erros, ajuste de caminhos e conclusão final da tarefa.

Em 10 avaliações que cobrem Agente Harness, uso de ferramentas, código e adesão a instruções, o modelo de 4B, após o Agentic Post-Training, alcançou desempenho geral igual ou ligeiramente superior ao modelo base de 9B.

Uma empresa que sempre enfatizou a colaboração entre modelos, por que começou a treinar seus próprios modelos? A Primal Rhythm está prestes a entrar na mesa dos modelos base?

De acordo com a resposta dada por NeoHorse, a direção não sofreu essa mudança.

Este modelo incorpora, pela primeira vez, a experiência acumulada pelo Primordial Rhythm em execuções multi-modelo.

Ao longo do tempo, as pontuações frequentemente se tornaram o principal critério para comparar modelos.

Mas quando os modelos começam a ser integrados em sistemas de Agentes e assumem tarefas completas, a capacidade explicativa de uma única pontuação diminui.

Em uma tarefa, o modelo não apenas deve fornecer uma resposta aparentemente razoável, mas também deve, durante a execução, ler continuamente os feedbacks do ambiente, tratar erros e ajustar os caminhos subsequentes com base no progresso real; diferentes etapas exigem capacidades distintas do modelo.

Com base nisso, a equipe Primitive Rhythm chegou a uma conclusão.

O modelo não normalizado será uma estrutura persistente na indústria de IA.

Quanto mais modelos houver e quanto mais especializada for a divisão de tarefas, mais evidentes se tornam as diferenças de preço e capacidade, e mais necessário se torna um sistema para responder a algumas perguntas—

Qual modelo deve ser usado neste passo? Quais etapas podem ser atribuídas a modelos de custo mais baixo? Quando é necessário fazer upgrade para um modelo com maior capacidade de inferência e execução? Após um caminho de execução ser bloqueado, quem deve assumir? Vários modelos podem gerar soluções em paralelo e depois consolidar os resultados?

A equipe de Wang Yunhe chama este sistema de Routing Harness (o projeto de código aberto relacionado, OpenSquilla, já integrou vários modelos, realizando roteamento granular, troca de modelos e colaboração entre múltiplos modelos durante a execução do Agent, por meio de uma interface unificada).

Da mesma forma, com base nessa ideia, o Primal Rhythm parece não ter uma forte razão para treinar seu próprio modelo. Já existe uma oferta suficientemente rica de modelos no mercado, e chamar os modelos conforme a necessidade parece mais flexível.

À medida que o sistema de agendamento continua operando, outro tipo de ativo começa a se acumular, como “que tarefas exigem quais habilidades”, “em que etapa o modelo容易 falhar”, “que tipo de caminho de correção é eficaz” e “quais resultados conseguem passar na validação do ambiente”.

Essas informações, por um lado, podem melhorar a tomada de decisão de roteamento e, por outro, começam a adquirir valor de treinamento.

Isso é um pouco como uma plataforma que conecta uma grande quantidade de marcas aos consumidores. A demanda, avaliações e feedback de uso acumulados durante as transações podem ajudar os produtos a encontrar usuários mais adequados e também fornecer feedback adicional para o desenvolvimento de produtos.

O processo do mercado de serviços da plataforma torna-se assim uma fonte de dados para a próxima rodada de melhorias do produto.

NeoHorse é responsável por transformar parte da experiência de execução acumulada anteriormente no Harness em capacidades de modelo.

A fonte dos dados do NeoHorse merece menção.

Sua corpus principal consiste em combinar os sinais de execução do agente gerados pelo Routing Harness com dados públicos para construir um sistema de dados voltado para o pós-treinamento de agentes.

Agente conclui uma tarefa no Harness e deixa um registro completo da execução.

1. Inserir tarefa → O roteador determina quais habilidades são necessárias
2. → Selecione um modelo
3. → O modelo realiza inferência e chamadas de ferramentas
4. → Resultado retornado pelo ambiente
5. → O modelo continua a executar ou ocorre um erro
6. → Sistema altera modelo ou ajusta caminho
7. → Tarefa concluída ou falhou

Os dados de perguntas e respostas comuns geralmente se concentram nas extremidades “pergunta” e “resposta”.

Os dados do Routing Harness também contêm outras camadas de informações: quais habilidades a tarefa requer, quais decisões de execução o sistema tomou e qual feedback o ambiente finalmente forneceu.

Por exemplo, o roteador inicialmente julga que uma tarefa requer apenas um modelo padrão, mas, após falhas consecutivas durante a execução, ele atualiza para um modelo mais poderoso, permitindo que a tarefa seja concluída.

This trajectory contains far more information than just a failure.

O sistema pode saber se o julgamento inicial da capacidade foi muito baixo, em qual etapa o modelo apresentou problemas, que estratégia o modelo mais forte adotou, qual caminho de execução passou na verificação do ambiente e quantos tokens e tempo adicionais foram consumidos para concluir a tarefa.

Mais importante ainda, o movimento primordial observa não o julgamento de um único modelo sobre suas próprias capacidades, mas sim o desempenho transversal deixado por vários modelos diante de tarefas semelhantes.

Há registros de execução com caminhos bem-sucedidos, bem como aqueles que falharam no meio do caminho e foram posteriormente assumidos por outros modelos.

Do ponto de vista do treinamento, trajetórias de falha podem até fornecer mais informações.

A resposta final pode informar ao modelo um caminho viável, enquanto os processos de falha e correção complementam outros dois tipos de conhecimento: onde é fácil errar e como ajustar após o erro.

Além dos resultados fornecidos por vários modelos, também há os caminhos reais percorridos por esses modelos no ambiente da tarefa — isso também é um dos aspectos mais distintivos do NeoHorse.

Incorporar todos os logs no treinamento não resultará naturalmente em um modelo de agente mais forte.

As trajetórias do agente geralmente são longas, contendo prompts do sistema, solicitações do usuário, parâmetros de ferramentas, resultados de execução, tentativas repetidas, mensagens de erro e grande quantidade de saídas intermediárias.

Alguns passos têm valor de treinamento, outros são mais próximos de ruído. Há ainda fluxos de trajetória completos, mas cujos resultados não estão corretos.

O ritmo primordial primeiro precisa resolver a questão de "quais dados valem a pena o modelo aprender".

De acordo com o relatório técnico, cada trajetória passa por uma verificação estrutural para garantir a correspondência entre a solicitação, a resposta do modelo, a chamada da ferramenta e os resultados do ambiente.

Em seguida, o sistema avaliará a qualidade da execução em seis dimensões: se o objetivo do usuário foi atingido, se as instruções foram seguidas, se o uso de ferramentas foi adequado, se as conclusões são sustentadas por evidências, se o sistema pode se recuperar após erros e se o modelo encerrou a tarefa no momento apropriado.

Aqui também estão envolvidos problemas que facilmente são confundidos no treinamento de Agentes.

O término da tarefa não significa que o objetivo do usuário foi atingido — a saída do modelo “tarefa concluída” apenas indica que o fluxo de execução foi interrompido, mas não prova que o resultado atende aos requisitos do usuário.

Portanto, o estado de conclusão, o grau de atingimento dos objetivos, as evidências do ambiente e o feedback do usuário devem ser registrados como sinais distintos.

Após a conclusão da filtragem dos dados, o sinal de roteamento começa a desempenhar outro papel.

O roteador estima as capacidades necessárias para a tarefa e gera sinais em diferentes níveis de capacidade. O NeoHorse organiza a ordem das amostras durante o treinamento com base nisso, aprendendo primeiro tarefas com menor demanda de capacidade e gradualmente aumentando trajetórias de execução mais complexas, mantendo ao mesmo tempo a cobertura das tarefas básicas.

Este método é chamado de Routing-Guided Curriculum, ou seja, aprendizado curricular guiado por roteamento.

De forma mais simples, o sinal de roteamento decide online quem executa qual tarefa e, durante o treinamento, pode informar ao modelo quais tarefas são mais adequadas para serem aprendidas primeiro e quais podem ser aprendidas depois.

Além do fine-tuning supervision comum, o NeoHorse também utiliza On-Policy Distillation.

Pode-se entender como permitir primeiro que os alunos resolvam os problemas da própria maneira, e depois o professor forneça orientação com base nos passos reais que os alunos deram.

Assim, o modelo professor lida com os problemas que o modelo aluno encontrará sob sua distribuição atual, e não com um conjunto pré-definido de erros padrão.

Após essas etapas, a experiência acumulada ao longo de tarefas de execução prolongada com múltiplos modelos começa a ser utilizada no pós-treinamento do NeoHorse.

Com base nos resultados apresentados no relatório técnico atual, o Agentic Post-Training trouxe melhorias estáveis em ambas as escalas de 4B e 9B.

Entre eles, o desempenho geral do NeoHorse-1-4B (a pontuação média macro aumentou de 58,94 para 64,87) já alcançou o SOTA do mesmo tamanho — superando seu modelo base, Qwen3.5-4B, em todos os benchmarks comparáveis, e liderando globalmente entre os modelos de mesmo tamanho de 4B.

Mas SOTA não significa que a capacidade está uniformemente distribuída.

Ao analisar os resultados em detalhes, pode-se ver que as melhorias do modelo 4B estão concentradas principalmente em um tipo de tarefa.

Essas tarefas geralmente possuem fluxos de trabalho relativamente claros, feedbacks de ambiente observáveis, resultados de sucesso e falha verificáveis e critérios de entrega finais bem definidos.

Por exemplo, em uma tarefa de cronograma de projeto, o modelo básico encontrou os arquivos no diretório de trabalho, mas não continuou lendo um e-mail contendo as restrições de dependência mais recentes.

Como resultado, ele gerou o plano com base em informações já expiradas e salvou o arquivo no local incorreto.

O modelo pós-treinado continua lendo novas evidências, identifica que as restrições mudaram, recalcula o cronograma, valida os resultados e salva os artefatos no local correto.

A diferença entre ambos se manifesta na cadeia de execução do Agente.

Um modelo tem uma ideia geral de como realizar a tarefa, enquanto outro modelo já consegue integrar etapas completas de coleta de evidências, atualização de restrições, execução, validação e entrega.

Alcançar o SOTA no mesmo nível não significa que o NeoHorse-1-4B deve assumir todas as tarefas. O Primitivo Rítmo está mais interessado em como delinear cuidadosamente os limites de capacidade de diferentes modelos.

Tarefas que podem ser concluídas com estabilidade por um modelo de 4B podem reduzir a necessidade de chamar modelos maiores; tarefas que podem ser realizadas por modelos mais potentes não precisam ser continuamente migradas para o modelo旗舰 mais caro; à medida que a dificuldade aumenta, essas tarefas são encaminhadas para modelos mais capazes no pool de modelos.

Aqui se conecta exatamente a relação entre o Routing Harness e o modelo desenvolvido internamente.

O modelo continua expandindo o intervalo de custos das tarefas que pode assumir, enquanto o sistema de roteamento aloca diferentes capacidades nos locais adequados com base na dificuldade da tarefa e no desempenho.

At this point, the relationship between the various product lines of Primordial Rhythm has also become clearer.

O primeiro nível é a versão open source do OpenSquilla.

Por meio de produtos gratuitos, de código aberto, implantados localmente e de desktop, a Primal Rhythm reduz a barreira para desenvolvedores utilizarem Agentes de múltiplos modelos, conectando ao mesmo tempo desenvolvedores e pontos de entrada de tarefas.

A segunda camada é a API TokenRhythm.

Sua posição é semelhante à de uma "versão chinesa do OpenRouter", fornecendo capacidade de chamada de diferentes modelos por meio de uma interface unificada, atendendo às necessidades de desenvolvedores e empresas no uso de modelos, além de ajudar fabricantes de modelos a se conectarem a mais cenários de aplicação.

As empresas podem avaliar, escolher e alternar entre modelos com mais facilidade sem precisar adaptar separadamente várias interfaces de modelo.

O terceiro nível é o serviço e a capacidade de implantação voltados para empresas.

Setores como finanças e manufatura têm requisitos diferentes em relação a permissões, estabilidade, implantação privada e garantia de serviço, o que gera novas oportunidades comerciais.

O quarto nível é o NeoHorse.

NeoHorse primeiro validou uma conexão chave: experiências válidas geradas durante a execução do Harness, após serem filtradas e treinadas, realmente têm a chance de serem transformadas em capacidades do próprio modelo.

Assim, o modelo de negócio proposto anteriormente pelo Primitivo Rhythmic apresentou resultados pela primeira vez no nível do modelo.

Isso também traz a possibilidade de otimizar a conta econômica de inferência.

Se o NeoHorse conseguir, posteriormente, sustentar de forma estável um conjunto de tarefas de Agent de alta frequência e com critérios relativamente claros, a plataforma ganhará uma nova capacidade de alocação autônoma de recursos.

Essas tarefas podem ser ainda mais otimizadas em termos de custo de inferência, velocidade de resposta e estabilidade, além de permitir uma configuração de fornecimento de modelo mais flexível. À medida que o modelo continua a ser iterado, há potencial para expandir ainda mais a gama de tarefas que ele pode cobrir.

Do ponto de vista deste ângulo, o que o Primitive Rhythm pretende fazer é um pouco como o acúmulo de processos na manufatura.

O ecossistema de modelos externos fornece diferentes capacidades, enquanto o Harness é responsável por organizar e executar; a experiência adquirida durante a execução é incorporada à próxima rodada de aprimoramento do modelo.

Da conexão de modelos e prestação de serviços à transformação da experiência gerada nos serviços em capacidades de modelo, melhorando ainda mais a eficiência e a qualidade, este é mais um passo que o Primal Rhythm dá além da plataforma de agregação de API.

Os ciclos previstos na concepção do Princípio Rítmico podem ser conectados por algumas linhas de negócio:

1. Routing Harness conecta desenvolvedores a tarefas de Agent
2. → Modelo de conexão da API TokenRhythm para oferta e demanda de chamadas
3. → Executado pela organização Harness, acumulando rotas e trajetórias de tarefas
4. Trajetórias disponíveis foram filtradas para treinamento do modelo
5. → O modelo atualizado retorna o Harness, participe da tarefa de adaptação
6. → Melhore a experiência da tarefa, explore melhor velocidade de resposta e eficiência de custos
7. → Uso contínuo, pagamento e melhoria da eficiência operacional
8. → Suporte para a próxima rodada de aprimoramento de serviços e investimento em P&D

Uma das mudanças chave é que as trajetórias geradas pelo modelo não se limitam mais aos estágios de consumo e chamada, mas também podem se tornar fontes para o próximo ciclo de treinamento do modelo.

Quando o agente conclui uma tarefa, a Harness obtém mais uma observação sobre os limites da capacidade.

Um modelo falhou, e o sistema sabe onde pode ter ocorrido a lacuna de capacidade; outro modelo assumiu com sucesso, e o sistema obteve um novo caminho de correção; o usuário aceita ou rejeita o resultado, fornecendo um novo nível de feedback externo.

Quanto mais tarefas forem acumuladas, mais preciso poderá ser o julgamento de roteamento; com um julgamento de roteamento mais preciso, as trajetórias de treinamento selecionadas também se tornarão mais próximas das tarefas reais; à medida que o modelo se adapta melhor às tarefas, o serviço API terá novamente a oportunidade de oferecer melhores custos e experiência.

Se esse ciclo puder ser mantido a longo prazo, a diferença entre o primitivo律动 e as plataformas agregadoras de API comuns também evoluirá gradualmente para incluir o design de tarefas de treinamento, métodos de treinamento e parâmetros do modelo.

Por fim, demonstrado através do desempenho do produto.

Acima está o contexto em que o Primal Rhythm começou a discutir o RSI (Recursive Self-Improvement, Melhoria Recursiva Própria).

O Primal Rhythm atualmente valida a faixa do RSI de forma mais próxima de um ciclo de engenharia fechado, podendo ser dividido em duas partes.

O primeiro é Data-RSI.

O modelo executa tarefas continuamente no Harness, e cada roteamento, chamada de ferramenta, recuperação de falha e resultado final gera um novo registro estruturado.

Após serem filtradas e processadas, essas gravações podem ser adicionadas ao pool de dados para treinamento subsequente. Assim, os dados de treinamento não precisam depender totalmente de preparação manual antecipada e podem aumentar à medida que o sistema é continuamente utilizado.

O segundo é Model-RSI.

O sistema identifica as lacunas de capacidade do modelo atual com base nos resultados da avaliação, ajusta a distribuição dos dados de treinamento da próxima rodada, atualiza o modelo e o reintroduz no Harness para execução.

Ou seja, o modelo aprende com a experiência de execução, e o modelo atualizado realiza novas tarefas, gerando novos feedbacks para a próxima rodada de treinamento.

No entanto, com as informações atualmente públicas do NeoHorse, esse sistema ainda não pode ser considerado um RSI completo.

O relatório técnico atualmente valida um ciclo fechado de "execução-avaliação-seleção-atualização". O design do sinal, o design da recompensa e o processo de treinamento ainda são definidos por humanos; é necessário mais experimentação para confirmar se os modelos de múltiplas gerações continuarão a obter ganhos estáveis.

Portanto, uma formulação mais precisa é que este lançamento da NeoHorse concluiu duas camadas de verificação.

O primeiro nível é comercial: os dados acumulados pelo sistema podem ser utilizados para treinar modelos e se transformar em melhorias de capacidade mensuráveis.

Outro nível é técnico: Wang Yunhe liderou a equipe de startups em uma validação de engenharia única voltada para a direção RSI.

Of course, for the story of the primal rhythm to hold, several hurdles still need to be overcome.

Primeiro, o ecossistema de código aberto poderá ser continuamente convertido em uso de API e receita?

Em segundo lugar, à medida que o número de tipos de tarefas aumenta, o sistema consegue continuar obtendo trajetórias de agente suficientemente de alta qualidade para treinamento?

Terceiro, após a melhoria da capacidade do modelo, é possível converter isso de forma estável em uma melhor experiência e eficiência de execução das tarefas, refletindo-se ainda mais nos dados operacionais.

Quarto, após várias iterações do modelo, por quanto tempo ainda será possível manter o ganho de capacidade.

Essas questões exigem uma observação por um período mais longo.

E há ainda uma variável inevitável— DeepSeek 、Qwen、 MiniMax As fabricantes de modelos também estão se expandindo para produtos Harness e Agent, e a tendência de integração vertical entre modelos e infraestrutura de Agentes está se tornando cada vez mais clara.

Por exemplo, com o Primitive Rhythm, uma das diferenças atuais dessa empresa é a neutralidade de modelo e os dados de comparação horizontal formados durante a execução entre modelos.

Mas se as diferenças de capacidade entre os modelos forem suficientemente grandes, o agendamento entre modelos pode se tornar um negócio independente; se os modelos líderes forem gradualmente capazes de cobrir mais tarefas, ou se os fabricantes integrarem o roteamento, a chamada de ferramentas e os frameworks de agentes em um único pacote, o espaço disponível para a camada intermediária será comprimido.

Quando as capacidades da camada superior ficam cada vez mais fortes e mais baratas, por que ainda é necessário que esta camada intermediária exista?

Para o Primitivo Rhythmic, NeoHorse adicionou pelo menos uma nova perspectiva a essa questão.

Antes, provou que sabia “usar modelos”; agora, começa a tentar demonstrar que os dados acumulados ao longo do tempo com o uso de modelos também podem se transformar em capacidade de modelo própria.

Se este caminho for bem-sucedido, a vantagem competitiva do Elemental Rhythm não se limitará à estratégia de roteamento; se não for bem-sucedido, ainda enfrentará todos os problemas comuns às camadas intermediárias de modelos.

GitHub: https://github.com/TokenRhythm/NeoHorse

Abraço facial: https://huggingface.co/collections/TokenRhythm/neohorse-1

Este artigo é do canal oficial do WeChat "Quantum Bit", autor: Heng Yu