A visão central da tecnologia MCP-B pode ser resumida da seguinte forma.
"Por meio de um intermediário confiável chamado extensão do Chrome, vamos aproveitar as informações do usuário que o navegador já gerencia com segurança — cookies, sessão, autenticação etc. — para chamar e controlar, a partir de uma janela de chat com IA e usando comandos em linguagem natural, as 'ferramentas (Tools)' previamente definidas por desenvolvedores em páginas da web."
Mas eu sinto que "não parece haver espaço para escalar", e acho que os motivos são os seguintes.
Resistência do usuário: esse é o maior obstáculo. Os usuários têm uma rejeição instintiva e preocupações de segurança em relação à instalação de extensões que acessam as informações do navegador. Se a conveniência oferecida por essa tecnologia não for esmagadoramente superior a essas preocupações, os usuários vão hesitar em instalá-la.
Carga para os desenvolvedores web: além de criar as APIs existentes, os desenvolvedores de sites também passam a ter o ônus adicional de definir e manter separadamente as 'ferramentas (Tools)' para o MCP-B. Se o benefício obtido com a ampla adoção dessa tecnologia não for grande, os desenvolvedores não vão querer fazer esse esforço em dobro.
Responsabilidade por problemas de segurança: se ocorrer um incidente de segurança por meio dessa tecnologia, pode ficar pouco claro se a responsabilidade é do desenvolvedor do site, do desenvolvedor da extensão ou do provedor do modelo de IA. Essa complexidade faz com que empresas hesitem em adotar a tecnologia.
Ausência de uma plataforma centralizada: no momento, não existe um diretório ou plataforma padronizada que informe "quais sites oferecem quais ferramentas". Até visitar um site, é difícil para o usuário saber quais recursos de IA podem ser usados.
Em conclusão,
a ideia do MCP-B em si é tecnicamente muito interessante e inovadora, mas parece não conseguir dar uma resposta clara à pergunta fundamental de usuários e desenvolvedores: "por que exatamente seria necessário usar esse método?". Em comparação com o modelo tradicional de APIs, os benefícios não são claros, enquanto as desvantagens — preocupações de segurança e complexidade de desenvolvimento — são evidentes.
Portanto, por enquanto, essa tecnologia até pode ser usada de forma experimental entre alguns entusiastas ou desenvolvedores com objetivos específicos, mas parece haver muitas dificuldades para que ela se expanda por todo o ecossistema web.
Concordo com a consciência temática fundamental deste texto, mas há partes que também me fazem inclinar um pouco a cabeça em dúvida.
Por exemplo, o site promocional de um determinado serviço operado pela nossa empresa mantém justamente a mesma simplicidade que este texto elogia. Felizmente, a maior parte dos elementos desse site é suficientemente estática. O código de frontend, como HTML e CSS, foi escrito manualmente por pessoas, sem framework algum, e de JS há apenas algo como jQuery e Google Analytics. Avisos e quadro de mensagens são implementados com AJAX usando jQuery, mas não considero isso algo irracional nem excessivamente complexo. Acho que está no nível que eu conseguia implementar com base em jQuery quando comecei a aprender desenvolvimento web básico há muito tempo. Pelo que sei, esse site já era operado desde a era do Internet Explorer, então não fui eu quem o fez, mas acho que ele não é nada mau.
Mas nele há controle de versão com Git e um pipeline de CI/CD, e os servidores de staging e de produção estão separados. Quando um Pull Request é mesclado na branch Main, o pipeline executa o bundler e faz deploy automático do artefato gerado no servidor de staging; depois que o responsável verifica o servidor de staging e aprova o deploy final, isso é implantado novamente no servidor de produção. Antigamente, o método era simplesmente sobrescrever diretamente os arquivos originais no servidor de produção via FTP, mas, depois que esse trabalho passou para a nossa equipe, mudamos para esse modelo.
Isso é realmente uma complexidade irracional? No passado, alterar a tag de título desse site era um trabalho que terminava ao entrar diretamente no arquivo HTML do servidor de produção com o AcroEdit com suporte a conexão FTP (sim, as pessoas que originalmente escreveram o HTML daquele site ainda usavam isso), modificar uma única linha e salvar, então talvez essas pessoas realmente sintam assim.
Mas, na minha opinião, esse nível de complexidade adicional era perfeitamente suportável. Nem todo trabalho é do mesmo nível de simplesmente alterar uma única tag de título. E poder apagar sem peso na consciência um código antigo que antes ficava grudado em comentários, porque agora é possível restaurá-lo a qualquer momento; ter rastreamento transparente de mudanças e rollback; e poder adicionar, se necessário, otimizações mais básicas por meio do bundler são, a meu ver, vantagens suficientes. A adição de um servidor de staging para pré-visualização antes do deploy no ambiente real também poderia ser vista como uma forma de complexidade, mas eu acho que isso era necessário.
Eu também tenho muitas queixas sobre como a estrutura interna do código de vários sites ficou excessivamente complexa e pesada. Hoje em dia, o aplicativo Outlook do Windows é baseado em web app e, ultimamente, ficou ainda mais pesado. A ponto de travar só por redigir o corpo de um e-mail na tela ou até mesmo por selecionar todo o texto do corpo, chegando inclusive a mostrar “página sem resposta”. Fui abrir as ferramentas de desenvolvedor no Outlook Web para entender por que isso acontecia e fiquei chocado. Depois de limpar o cache e recarregar, mesmo um minuto depois ainda continuavam aparecendo requisições. Quando fui verificar no navegador, havia vários gigabytes de dados armazenados só relacionados ao site do MS Office.
No entanto, este texto mistura várias coisas; há partes com as quais concordo, mas outras com as quais não concordo muito. Pelo que sei, no caso de HTML semântico e acessibilidade, o passado era na verdade ainda mais terrível. Além disso, a ideia de que melhorar a experiência do desenvolvedor piora a experiência do usuário é algo com que eu simplesmente não consigo concordar, embora talvez isso seja porque eu não sou desenvolvedor frontend web. E dizer até que todo o poder e controle ficou concentrado nos desenvolvedores soa como um absurdo. O poder na empresa não fica com a diretoria? Ou a estrutura das empresas no Ocidente é um pouco diferente da da Coreia?
Como sempre, concordo plenamente que equilíbrio e moderação, assim como simplicidade e praticidade, são valores importantes e devem ser priorizados nas decisões. Mas este texto argumenta como se “tratar todos os sites como produtos de software” fosse algo inteiramente responsabilidade dos desenvolvedores, e acho que justamente essa parte acaba obscurecendo a consciência do problema fundamental. E também acho que a parte que parece romantizar os “bons velhos tempos”, quando não havia processos bem estabelecidos, deveria sim ser criticada.
Concordo com a ideia principal deste texto. Hoje em dia o JS está sendo usado em excesso, então é comum ver sites engasgando mesmo usando um i9-9900k. Pode até ser uma configuração meio indefinida para jogos ou trabalho, mas a realidade é que existem muitos computadores de escritório com especificações ainda inferiores.
Por isso eu gosto do Astro e do Hotwired, frameworks com a filosofia de usar JS só quando ele é realmente necessário, como em partes interativas ou em navegação de páginas interativa. Também gosto de renderização no lado do servidor, ou seja, de fazer a renderização no servidor. Por outro lado, detesto CSR (incluindo os casos em que só as meta tags são renderizadas no servidor e todo o resto é tratado com CSR). Isso porque vejo isso como transferir para o cliente o trabalho que deveria ser feito pelo servidor. Pessoalmente, acho que a abordagem tradicional de SPA usando CSR deveria ser usada quando o frontend roda localmente em apps como Electron. Claro, quando o frontend é carregado a partir do servidor, aí deve-se usar SSR.
Acho que, pela própria estrutura dos LLMs, deve ser impossível garantir segurança de forma perfeita. Na minha opinião, é inevitável que os LLMs sejam instáveis, e o importante parece ser como conceder autoridade para ações físicas, como no caso de agentes ou direção autônoma.
Só de ver o nome, já parece pouco confiável.
Por que colocaram dois-pontos no meio do nome? Será que existe algum motivo semântico? Ou será que acharam mesmo que isso fica bonito?
E, se é mit:eum, então em alfabeto latino não deveria ser escrito como mid:m?
Ultimamente andei procurando coisas relacionadas a SETI por causa do jogo de tabuleiro SETI, então foi bom ver isso nas notícias também.
O jogo de tabuleiro SETI é muito divertido. Quero recomendar até para quem não conhece muito bem jogos de tabuleiro.
Ao apresentar o projeto para jovens que nem conhecem o próprio SETI, o contexto já fica interessante, e o tema do jogo combina perfeitamente.
Sendo um jogo de tabuleiro de 2025, ele já subiu até a 43ª posição no ranking geral de jogos de tabuleiro, então acho que em breve deve entrar no top 10.
Parece que dá para pensar nisso como o desempenho de um modelo que passou por menos alinhamento, mas provavelmente vão capar e o desempenho vai cair, eu acho
Bom, só dá para saber mesmo usando na prática, mas com 200 mil GPUs e esse nível de reserva de talentos, dá para crescer de forma bem agressiva assim.
Quando o Colossus chegar a 1 milhão de GPUs, até onde será que vai melhorar?
Considerando o H100 a 50 milhões de won, só o preço das GPUs dá 50 trilhões de won. Somando a construção do data center e a necessidade de energia ao redor, dizem que isso adiciona mais uns 20 trilhões de won, então dá 70 trilhões de won. A IA parece estar virando cada vez mais uma disputa de dinheiro.
> Eu acho que criar wrappers que usam APIs externas e chamar isso de serviço de IA é um trabalho sem produtividade nenhuma e só um negócio de cobrar taxa,
Complementando isso, mesmo usando API, se ela for bem aproveitada no nível do Manus, dá para considerar como resultado, mas ainda não parece haver wrappers nesse nível na Coreia.
Concordo em parte.
Eu acho que criar wrappers que usam APIs externas e chamá-los de serviços de IA é algo sem produtividade alguma e uma forma de ganhar dinheiro em cima de taxa,
mas, no fim das contas, quando empresas ao menos fazem fine-tuning de modelos e os disponibilizam, estão tornando isso público com recursos próprios, então não vejo motivo para encarar isso de forma negativa.
No entanto, se começarem a receber dinheiro de fora, por exemplo do governo, acho que aí não daria para ver isso apenas de forma positiva...
A visão central da tecnologia MCP-B pode ser resumida da seguinte forma.
"Por meio de um intermediário confiável chamado extensão do Chrome, vamos aproveitar as informações do usuário que o navegador já gerencia com segurança — cookies, sessão, autenticação etc. — para chamar e controlar, a partir de uma janela de chat com IA e usando comandos em linguagem natural, as 'ferramentas (Tools)' previamente definidas por desenvolvedores em páginas da web."
Mas eu sinto que "não parece haver espaço para escalar", e acho que os motivos são os seguintes.
Em conclusão,
a ideia do MCP-B em si é tecnicamente muito interessante e inovadora, mas parece não conseguir dar uma resposta clara à pergunta fundamental de usuários e desenvolvedores: "por que exatamente seria necessário usar esse método?". Em comparação com o modelo tradicional de APIs, os benefícios não são claros, enquanto as desvantagens — preocupações de segurança e complexidade de desenvolvimento — são evidentes.
Portanto, por enquanto, essa tecnologia até pode ser usada de forma experimental entre alguns entusiastas ou desenvolvedores com objetivos específicos, mas parece haver muitas dificuldades para que ela se expanda por todo o ecossistema web.
Concordo com a consciência temática fundamental deste texto, mas há partes que também me fazem inclinar um pouco a cabeça em dúvida.
Por exemplo, o site promocional de um determinado serviço operado pela nossa empresa mantém justamente a mesma simplicidade que este texto elogia. Felizmente, a maior parte dos elementos desse site é suficientemente estática. O código de frontend, como HTML e CSS, foi escrito manualmente por pessoas, sem framework algum, e de JS há apenas algo como jQuery e Google Analytics. Avisos e quadro de mensagens são implementados com AJAX usando jQuery, mas não considero isso algo irracional nem excessivamente complexo. Acho que está no nível que eu conseguia implementar com base em jQuery quando comecei a aprender desenvolvimento web básico há muito tempo. Pelo que sei, esse site já era operado desde a era do Internet Explorer, então não fui eu quem o fez, mas acho que ele não é nada mau.
Mas nele há controle de versão com Git e um pipeline de CI/CD, e os servidores de staging e de produção estão separados. Quando um Pull Request é mesclado na branch Main, o pipeline executa o bundler e faz deploy automático do artefato gerado no servidor de staging; depois que o responsável verifica o servidor de staging e aprova o deploy final, isso é implantado novamente no servidor de produção. Antigamente, o método era simplesmente sobrescrever diretamente os arquivos originais no servidor de produção via FTP, mas, depois que esse trabalho passou para a nossa equipe, mudamos para esse modelo.
Isso é realmente uma complexidade irracional? No passado, alterar a tag de título desse site era um trabalho que terminava ao entrar diretamente no arquivo HTML do servidor de produção com o AcroEdit com suporte a conexão FTP (sim, as pessoas que originalmente escreveram o HTML daquele site ainda usavam isso), modificar uma única linha e salvar, então talvez essas pessoas realmente sintam assim.
Mas, na minha opinião, esse nível de complexidade adicional era perfeitamente suportável. Nem todo trabalho é do mesmo nível de simplesmente alterar uma única tag de título. E poder apagar sem peso na consciência um código antigo que antes ficava grudado em comentários, porque agora é possível restaurá-lo a qualquer momento; ter rastreamento transparente de mudanças e rollback; e poder adicionar, se necessário, otimizações mais básicas por meio do bundler são, a meu ver, vantagens suficientes. A adição de um servidor de staging para pré-visualização antes do deploy no ambiente real também poderia ser vista como uma forma de complexidade, mas eu acho que isso era necessário.
Eu também tenho muitas queixas sobre como a estrutura interna do código de vários sites ficou excessivamente complexa e pesada. Hoje em dia, o aplicativo Outlook do Windows é baseado em web app e, ultimamente, ficou ainda mais pesado. A ponto de travar só por redigir o corpo de um e-mail na tela ou até mesmo por selecionar todo o texto do corpo, chegando inclusive a mostrar “página sem resposta”. Fui abrir as ferramentas de desenvolvedor no Outlook Web para entender por que isso acontecia e fiquei chocado. Depois de limpar o cache e recarregar, mesmo um minuto depois ainda continuavam aparecendo requisições. Quando fui verificar no navegador, havia vários gigabytes de dados armazenados só relacionados ao site do MS Office.
No entanto, este texto mistura várias coisas; há partes com as quais concordo, mas outras com as quais não concordo muito. Pelo que sei, no caso de HTML semântico e acessibilidade, o passado era na verdade ainda mais terrível. Além disso, a ideia de que melhorar a experiência do desenvolvedor piora a experiência do usuário é algo com que eu simplesmente não consigo concordar, embora talvez isso seja porque eu não sou desenvolvedor frontend web. E dizer até que todo o poder e controle ficou concentrado nos desenvolvedores soa como um absurdo. O poder na empresa não fica com a diretoria? Ou a estrutura das empresas no Ocidente é um pouco diferente da da Coreia?
Como sempre, concordo plenamente que equilíbrio e moderação, assim como simplicidade e praticidade, são valores importantes e devem ser priorizados nas decisões. Mas este texto argumenta como se “tratar todos os sites como produtos de software” fosse algo inteiramente responsabilidade dos desenvolvedores, e acho que justamente essa parte acaba obscurecendo a consciência do problema fundamental. E também acho que a parte que parece romantizar os “bons velhos tempos”, quando não havia processos bem estabelecidos, deveria sim ser criticada.
Bancando o desinteressado…
Na Coreia, tudo começa e termina em Java, então isso soa estranho mesmo kkk
A tecnologia de outro país != os dados de outro país
é o que eu penso
Por enquanto, não acredito até liberarem de graça. O Grok custa até 30 dólares, então dá medo assinar...
kkkkkkk o pós-graduando que levou um golpe do nada ficou sem reação ..
Use Rails, seja feliz
Apoio a tentativa, mas...
espero que não façam algo como criar uma nova organization e jogar a 1.0 fora.
(Coreia) Vida corporativa? kkk
Seria ótimo se também saísse em YCD~
Concordo com a ideia principal deste texto. Hoje em dia o JS está sendo usado em excesso, então é comum ver sites engasgando mesmo usando um i9-9900k. Pode até ser uma configuração meio indefinida para jogos ou trabalho, mas a realidade é que existem muitos computadores de escritório com especificações ainda inferiores.
Por isso eu gosto do Astro e do Hotwired, frameworks com a filosofia de usar JS só quando ele é realmente necessário, como em partes interativas ou em navegação de páginas interativa. Também gosto de renderização no lado do servidor, ou seja, de fazer a renderização no servidor. Por outro lado, detesto CSR (incluindo os casos em que só as meta tags são renderizadas no servidor e todo o resto é tratado com CSR). Isso porque vejo isso como transferir para o cliente o trabalho que deveria ser feito pelo servidor. Pessoalmente, acho que a abordagem tradicional de SPA usando CSR deveria ser usada quando o frontend roda localmente em apps como Electron. Claro, quando o frontend é carregado a partir do servidor, aí deve-se usar SSR.
Pedir ajuda também é uma habilidade.
Acho que, pela própria estrutura dos LLMs, deve ser impossível garantir segurança de forma perfeita. Na minha opinião, é inevitável que os LLMs sejam instáveis, e o importante parece ser como conceder autoridade para ações físicas, como no caso de agentes ou direção autônoma.
Só de ver o nome, já parece pouco confiável.
Por que colocaram dois-pontos no meio do nome? Será que existe algum motivo semântico? Ou será que acharam mesmo que isso fica bonito?
E, se é mit:eum, então em alfabeto latino não deveria ser escrito como
mid:m?Ultimamente andei procurando coisas relacionadas a SETI por causa do jogo de tabuleiro SETI, então foi bom ver isso nas notícias também.
O jogo de tabuleiro SETI é muito divertido. Quero recomendar até para quem não conhece muito bem jogos de tabuleiro.
Ao apresentar o projeto para jovens que nem conhecem o próprio SETI, o contexto já fica interessante, e o tema do jogo combina perfeitamente.
Sendo um jogo de tabuleiro de 2025, ele já subiu até a 43ª posição no ranking geral de jogos de tabuleiro, então acho que em breve deve entrar no top 10.
Parece que dá para pensar nisso como o desempenho de um modelo que passou por menos alinhamento, mas provavelmente vão capar e o desempenho vai cair, eu acho
Bom, só dá para saber mesmo usando na prática, mas com 200 mil GPUs e esse nível de reserva de talentos, dá para crescer de forma bem agressiva assim.
Quando o Colossus chegar a 1 milhão de GPUs, até onde será que vai melhorar?
Considerando o H100 a 50 milhões de won, só o preço das GPUs dá 50 trilhões de won. Somando a construção do data center e a necessidade de energia ao redor, dizem que isso adiciona mais uns 20 trilhões de won, então dá 70 trilhões de won. A IA parece estar virando cada vez mais uma disputa de dinheiro.
> Eu acho que criar wrappers que usam APIs externas e chamar isso de serviço de IA é um trabalho sem produtividade nenhuma e só um negócio de cobrar taxa,
Complementando isso, mesmo usando API, se ela for bem aproveitada no nível do Manus, dá para considerar como resultado, mas ainda não parece haver wrappers nesse nível na Coreia.
Concordo em parte.
Eu acho que criar wrappers que usam APIs externas e chamá-los de serviços de IA é algo sem produtividade alguma e uma forma de ganhar dinheiro em cima de taxa,
mas, no fim das contas, quando empresas ao menos fazem fine-tuning de modelos e os disponibilizam, estão tornando isso público com recursos próprios, então não vejo motivo para encarar isso de forma negativa.
No entanto, se começarem a receber dinheiro de fora, por exemplo do governo, acho que aí não daria para ver isso apenas de forma positiva...